[Container 이론] 5. 컨테이너 파드(pod)와 사이드카

목차

1. pod란?
2. 여러 프로세스를 실행하는 하나의 컨테이너 VS 하나의 프로세스를 실하는 다중 컨테이너
3. 하나의 파드 안에 하나의 컨테이너 사용을 권장하는 이유
4. 파드의 특징
5. 사이드카?

---

pod란?

Kubernetes 파드는 Kubernetes 개체 모델에서 가장 작고 간단한 배포 가능한 단위입니다. 파드는 동일한 네트워크 네임스페이스와 스토리지 볼륨을 공유하는 하나 이상의 컨테이너를 포함할 수 있는 클러스터에서 실행 중인 프로세스의 단일 인스턴스를 나타냅니다.

 

쿠버네티스 파드는 항상 두 개 이상의 컨테이너를 포함하지는 않습니다  보통은 파드 하나에 컨테이너 하나가 포함되어 있습니다. 파드는 노드 중 한 곳에서 작동하고 여러 개의 컨테이너를 가질 수 있지만, 반대로 여러 노드에 걸쳐서 작동하는 것은 불가능합니다.

Pod는 설계가 일시적으로 되어있습니다. 즉, 전체 애플리케이션에 영향을 주지 않고 언제든지 생성, 삭제 및 교체할 수 있습니다. 또한 애플리케이션 워크로드의 요구 사항을 충족하기 위해 자동으로 확장 또는 축소할 수 있습니다.

Kubernetes 클러스터의 각 파드에는 고유한 IP 주소가 할당되며 공유 네트워크를 통해 동일한 클러스터의 다른 파드와 통신할 수 있습니다. 이를 통해 파드가 함께 작동하여 응집력 있는 서비스를 제공할 수 있으며 각 파드는 전체 애플리케이션 아키텍처에서 특정 기능을 수행합니다.

Kubernetes 파드는 원하는 파드 상태를 관리하는 선언적 방법을 제공하는 배포라는 상위 수준 객체에 의해 관리됩니다. 이를 통해 다운타임 없이 애플리케이션의 손쉬운 확장, 롤링 업데이트 및 롤백이 가능합니다.

---

여러 프로세스를 실행하는 하나의 컨테이너 VS 하나의 프로세스를 실하는 다중 컨테이너

컨테이너가 격리된 가상 머신과 비슷한 느낌이라 한 컨테이너에 여러 프로세스를 실행하는 것이 더 효율적이지 않을지 생각할 수 있을 것 같습니다. 하지만 컨테이너는 설계될 당시에 단일 프로세스를 실행하도록 제작되었습니다. 물론 프로세스가 자기 자신의 자식 프로세스를 만드는 경우를 제외한다면 말이죠.

하나의 컨테이너에 여러 프로세스를 작동시킬 경우 어떠한 문제가 발생했을 때 로그를 추적하는 것이 쉽지가 않습니다. 따라서 하나의 컨테이너에는 하나의 프로세스만 작동시키게 된 것이죠. 이외의 사항들은 밑에서 더 자세히 살펴보도록 하겠습니다.

---

하나의 파드 안에 하나의 컨테이너 사용을 권장하는 이유

단순성, 확장성 및 결함 격리의 핵심 원칙을 중심으로 하는 여러 가지 이유로 인해 Kubernetes에서 파드당 하나의 컨테이너만 보유하는 것이 좋습니다. 이러한 이유는 다음과 같습니다.

1. 단일 책임 원칙
   단일 책임 원칙에 따라 각 파드(Pod)에는 관심사를 명확하게 분리할 수 있는 특정 작업 또는 기능이 있어야 합니다. 단일 파드(Pod)에 기능이 다른 여러 컨테이너가 있는 경우 시스템을 관리하고 유지하기가 더 어려워집니다.
   
   
2. 손쉬운 확장
   Kubernetes에서 확장은 일반적으로 포드 수준에서 수행됩니다. 포드당 하나의 컨테이너가 있으면 애플리케이션의 개별 구성 요소를 독립적으로 확장하기가 더 쉬워집니다. 이는 시스템의 전반적인 확장성과 응답성을 개선하는 데 도움이 됩니다.
   
   
3. 오류 격리
   포드당 단일 컨테이너를 실행하면 오류를 더 잘 격리하고 계단식 오류를 방지할 수 있습니다. 다중 컨테이너 파드(Pod)에서 컨테이너가 실패하면 동일한 파드(Pod)의 다른 컨테이너에 잠재적으로 영향을 미칠 수 있습니다. 단일 컨테이너 포드를 사용하면 장애가 특정 포드로 제한되므로 문제 해결 및 복구가 더 쉬워집니다.
   
   
4. 리소스 관리
   Kubernetes는 CPU, 메모리 및 스토리지 할당을 포함하는 포드 수준에서 리소스 관리를 제공합니다. 포드당 하나의 컨테이너를 사용하면 애플리케이션의 각 구성 요소에 대한 리소스를 개별적으로 효과적으로 관리할 수 있습니다. 이렇게 하면 최적의 리소스 사용이 보장되고 동일한 포드 내의 컨테이너 간 리소스 경합이 방지됩니다.
   
   
5. 간소화된 모니터링 및 로깅
   포드당 단일 컨테이너가 있을 때 모니터링 및 로깅이 더욱 간단해집니다. 이 접근 방식을 사용하면 로그 및 메트릭을 특정 구성 요소와 쉽게 연결하여 문제를 식별하고 성능을 분석하기가 더 쉬워집니다.
   
   
6. 수명 주기 관리
   Pod의 각 컨테이너는 동일한 수명 주기를 공유합니다. 단일 포드에 여러 컨테이너가 있는 경우 개별 컨테이너의 수명 주기를 관리하는 데 문제가 발생할 수 있습니다. 포드당 단일 컨테이너를 실행하면 각 구성 요소의 수명 주기를 개별적으로 관리하기가 쉬워져 필요할 때 원활한 업데이트 및 롤백이 보장됩니다.

사이드카 패턴 또는 밀접하게 결합된 서비스와 같은 다중 컨테이너 포드에 대한 유효한 사용 사례가 있지만 포드당 하나의 컨테이너 권장 사항을 준수하면 Kubernetes 배포에서 단순성, 확장성 및 복원력을 유지하는 데 도움이 됩니다.

---

파드의 특징

여러 프로세스를 컨테이너 하나로 묶지 않기 때문에, 컨테이너를 함께 묶고 하나의 단위로 관리할 수 있는 또 다른 상위 구조가 필요합니다. 이 때문에 파드가 필요한 것입니다.

 

컨테이너 모음을 사용해 밀접하게 연관된 프로세스를 함께 실행하고 단일 컨테이너 안에서 모두 함께 실행하고 단일 컨테이너 안에서 모두 함께 실행되는 것처럼 거의 동일한 환경을 제공할 수 있으면서도 이들을 격리된 상태로 유지할 수 있습니다. 이런 방식으로 두 가지의 장점을 모두 활용합니다. 컨테이너가 제공하는 모든 기능을 활용하는 동시에 프로세스가 함께 실행되는 것처럼 보이게 할 수 있습니다.

 

1. 같은 파드에서 컨테이너 간 부분 격리
   개별 컨테이너가 아닌 컨테이너 그룹으로 생각해 봅시다. 그룹 안에 있는 컨테이너가 특정한 리소스를 공유하기 위해 각 컨테이너가 완벽하게 격리되지 않도록 합니다. 쿠버네티스는 파드 안에 있는 모든 컨테이너가 자체 네임스페이스가 아닌 동일한 리눅스 네임스페이스를 공유하도록 도커를 설정합니다.
   
   파드의 모든 컨테이너는 동일한 네트워크 네임스페이스와 UTS 네임스페이스(UNIX Timesharing System Namespace) 안에서 실행되기 때문에, 모든 컨테이너는 같은 호스트 이름과 네트워크 인터페이스를 공유합니다. 비슷하게 파드의 모든 컨테이너는 동일한 IPC 네임스페이스 아래에서 실행돼 IPC를 통해 서로 통신할 수 있습니다. 최신 쿠버네티스와 도커에서는 동일한 PID 네임스페이스를 공유할 수 있지만, 기본적으로 활성화돼 있지는 않습니다.
   
   그러나 파일시스템에 한해서는 사정이 조금 다릅니다. 대부분의 컨테이너 파일 시스템은 컨테이너 이미지에서 나오기 때문에, 기본적으로 파일 시스템은 다른 컨테이너와 완전히 분리됩니다. 그러나 쿠버네티스의 볼륨 개념을 이용해 컨테이너가 파일 디렉터리를 공유하는 것이 가능합니다.
   
   
2. 컨테이너가 동일한 IP와 포트 공간을 공유
   여기서 중요한 한 가지는 파드 안의 컨테이너가 동일한 네트워크 네임스페이스에서 실행되기 때문에, 동일한 IP 주소와 포트 공간을 공유한다는 것입니다. 이는 동일한 파드 안 컨테이너에서 실행 중인 프로세스가 같은 포트 번호를 사용하지 않도록 주의해야 함을 의미합니다. 그렇지 않으면 포트 충돌이 발생하기 때문입니다.
   
   이는 동일한 파드일 때만 해당되고 다른 파드에 있는 컨테이너는 서로 다른 포트 공간을 갖기 때문에 포트 충돌이 일어나지 않습니다. 파드 안에 있는 모든 컨테이너는 동일한 루프백 네트워크 이너페이스를 갖기 때문에, 컨테이너들이 로컬 호스트를 통해 서로 통신할 수 있습니다.
   
   
3. 파드 간 플랫 네트워크
   쿠버네티스 클러스터의 모든 파드는 하나의 플랫 한 공유 네트워크 주소 공간에 상주하므로 모든 파드는 다른 파드의 IP 주소를 사용해 접근하는 것이 가능합니다. 둘 사이에는 어떠한 NAT도 존재하지 않습니다. 두 파드가 서로 네트워크 패킷을 보내면, 상대방의 실제 IP 주소를 패킷 안에 있는 출발지 IP 주소에서 찾을 수 있습니다.
   
   결과적으로 파드 사이에서 통신은 항상 단순합니다. 두 파드가 동일 혹은 서로 다른 워커 노드에 있는지는 중요하지 않으며, 두 경우 모두 파드 안에 있는 컨테이너는 NAT 없는 플랫 네트워크를 통해 서로 통신하는 것이 가능합니다. 이것은 실제 노드 간 네트워크 토폴로지에 관계없이, 근거리 네트워크(LAN)에 있는 컴퓨터 간의 통신과 비슷합니다. LAN상에 있는 컴퓨터처럼 각 파드는 고유 IP를 가지며 모든 다른 파드에서 이 네트워크를 통해 접속할 수 있습니다. 이는 일반적으로 물리 네트워크 위에 추가적인 소프트 웨어 정의 네트워크 계층을 통해 달성됩니다.

---

사이드카?

사이드카는 보조 컨테이너가 동일한 포드 내에서 기본 컨테이너와 함께 실행되는 디자인 패턴을 나타냅니다. 사이드카 컨테이너는 기본 컨테이너의 핵심 기능을 변경하지 않고 추가 기능 또는 지원을 제공하여 기본 컨테이너를 보완합니다. 이 패턴은 관심사를 분리하고 애플리케이션의 모듈성을 향상시킵니다.

사이드카 컨테이너의 일반적인 사용 사례는 다음과 같습니다.

1. 로그 관리
   사이드카 컨테이너는 로그 집계, 처리 및 중앙 로깅 서비스로의 전달을 담당할 수 있습니다. 이렇게 하면 기본 컨테이너가 로그 관리에 대한 걱정 없이 핵심 기능에 집중할 수 있습니다.
   
   
2. 모니터링
   사이드카 컨테이너는 기본 컨테이너에서 애플리케이션별 메트릭을 수집하고 이를 Prometheus와 같은 모니터링 시스템에 노출할 수 있습니다. 이는 애플리케이션 논리에서 모니터링 작업을 분리하는 데 도움이 됩니다.
   
   
3. 프록시
   사이드카 컨테이너는 기본 컨테이너에 대한 수신 또는 발신 네트워크 트래픽을 처리하는 프록시 역할을 할 수 있습니다. 예를 들어 사이드카는 트래픽 라우팅, 부하 분산 및 보안 정책과 같은 서비스 메시 기능을 구현할 수 있습니다.
   
   
4. 보안
   사이드카 컨테이너를 사용하여 보안 정책을 시행하거나 비밀 및 자격 증명을 관리하여 중요한 데이터를 기본 컨테이너와 분리할 수 있습니다.

사이드카 패턴은 파드(Pod)에 둘 이상의 컨테이너를 포함하지만 사이드카 컨테이너가 기본 컨테이너와 밀접하게 결합되어 해당 기능을 직접 지원하기 때문에 파드당 하나의 컨테이너를 권장하는 사항에 대해 예외입니다.