이전 장에서는 애플리케이션을 컨테이너화하는 방법에 대해 설명했지만, 컨테이너화된 애플리케이션의 실제 배포에서는 여러 애플리케이션을 하나의 원자 단위로 코로케이션하여 단일 머신에 스케줄링하는 경우가 많습니다.
이러한 배포의 일반적인 예는 그림 5-1에 나와 있으며, 웹 요청을 처리하는 컨테이너와 파일 시스템을 원격 Git 리포지토리와 동기화하는 컨테이너로 구성되어 있습니다.
그림 5-1. 두 개의 컨테이너와 공유 파일시스템이 있는 예시 파드
처음에는 웹 서버와 Git 동기화기를 모두 하나의 컨테이너로 묶고 싶을 수도 있습니다. 하지만 자세히 살펴보면 분리해야 하는 이유가 분명해집니다. 첫째, 두 컨테이너는 리소스 사용량 측면에서 상당히 다른 요구 사항을 가지고 있습니다. 메모리를 예로 들어보면, 웹 서버는 사용자 요청을 처리하기 때문에 항상 사용 가능하고 응답성이 좋아야 합니다. 반면에 Git 동기화 도구는 실제로 사용자를 대면하지 않으며 "최선의 노력"으로 서비스 품질을 유지해야 합니다.
Git 동기화 도구에 메모리 누수가 있다고 가정해 봅시다. 이 경우 성능에 영향을 미치거나 서버가 다운될 수도 있으므로 Git 동기화 프로그램이 웹 서버에 사용하려는 메모리를 모두 사용하지 못하도록 해야 합니다.
이러한 종류의 리소스 격리는 컨테이너의 목적에 정확히 부합하는 기능입니다. 두 애플리케이션을 두 개의 개별 컨테이너로 분리하면 안정적인 웹 서버 운영을 보장할 수 있습니다.
물론 두 컨테이너는 매우 공생 관계에 있으므로 한 컴퓨터에서 웹 서버를 예약하고 다른 컴퓨터에서 Git 동기화기를 예약하는 것은 의미가 없습니다. 따라서 Kubernetes는 여러 컨테이너를 파드라는 단일 원자 단위로 그룹화합니다. (파드는 고래의 그룹이기도 하므로, 이 이름은 Docker 컨테이너의 고래 테마를 따서 붙인 것이다).
참고
여러 컨테이너를 하나의 파드로 그룹화하는 것은 Kubernetes에 처음 도입되었을 때는 논란의 여지가 있거나 혼란스러워 보였지만, 이후 다양한 애플리케이션에서 인프라 배포를 위해 채택되었습니다. 예를 들어, 여러 서비스 메시 구현은 두 번째 사이드카 컨테이너를 사용하여 네트워크 관리를 애플리케이션의 파드에 주입한다.
Kubernetes의 파드
파드는 동일한 실행 환경에서 실행되는 애플리케이션 컨테이너와 볼륨의 모음이다. 컨테이너가 아닌 파드는 배포 가능한 가장 작은 아티팩트입니다. 즉, 파드의 모든 컨테이너는 항상 동일한 머신에 배치됩니다.
파드 내의 각 컨테이너는 자체 cgroup에서 실행되지만 여러 개의 리눅스 네임스페이스를 공유한다.
동일한 파드에서 실행되는 애플리케이션은 동일한 IP 주소와 포트 공간(네트워크 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month, and much more.
