Kubernestes 쿠버네티스 포드 관련 이론 및 유형 정리

<Pod Network>

• Container to Container network
  • 여러 컨테이너가 동일한 Pod에 있는 경우, 컨테이너는 network namespace를 공유
  • Pause container에 의해 공유되어 localhost 및 port 통신 가능
  • 단, 동일한 Pod의 각 컨테이너에는 포트 충동을 방지하기 위해 고유한 통신 포트가 있어야 함
• Node to Node network
  • 클러스터는 대부분의 경우 노드에 할당된 IP 주소가 포함된 라우팅 테이블을 저장
  • 라우팅 테이블은 bridge가 요청을 해결할 수 없을 때 연결된 Node에 대해 IP 주소 확인
  • 일치하는 network 콘텐츠는 적절한 Node에 연결되고 연결은 Node 수준에서 지속

<Pod 관리>

• Pod 삭제
  • 포드 삭제 요청이 API 서버에 수신되면 우선 etcd 상태를 수정, 요청을 진행하는 kubelet(A)과 Endpoints controller(B)에 알림.
  • 이 이벤트는 API 서버에 의해 병렬로 처리
  • Pod 삭제 시 APIserver는 Node의 kubelet에게 지시를 내려 포드에 SIGTERM 신호를 보냄
  • SIGTERM을 받으면 처리 중이던 작업을 완료하고, 새로운 요청을 받지 않도록 개발
  • kubelet에서 포드에 SIGTERM를 보낸 후에 일정 시간 동안 graceful shutdown이 되지 않는다면 강제로 SGIKILL을 보내 포드 강제 종료

<Pod lifecycle>

• 포드는 정의된 lifecycle에 따라 구동되는데, 실행되는 동안 오류가 있다면 kubelet은 오류 처리를 위해 restart 수행
• 실행 중인 포드는 명세(spec)와 실제 상태(status)를 모두 보유
• 포드는 포드의 수명 중 한번만 스케줄되고, 포드가 노드에 스케줄되면, 포드는 중지되거나 종료될 때까지 해당 노드에서 실행

 

<runtime container in Pod>

• runtime container: 포드가 포함하는 일반적인 애플리케이션 컨테이너
• 포드는 애플리케이션 코드가 포함된 단일 컨테이너에 대한 포장지 역할
• 포드가 예기치 않게 종료되면 쿠버네티스는 이를 수정하지 않고 그 자리에 새로운 포드를 생성하고, 새로 시작된 포드는 DNS 및 IP 주소를 제외한 기존 포드의 복제본
• 쿠버네티스 아키텍처의 유연한 특성으로 인해 애플리케이션은 더이상 지정된 포드에만 연결될 필요가 없음
• 대신 클러스터 내 어디에서나 생성된 완전히 새로운 포드가 원활하게 자리잡을 수 있도록 애플리케이션 설계 필요

<intitial container in Pod>

• 한 포드에 있는 애플리케이션 컨테이너 이전에 실행되는 특수 컨테이너
• 다양한 목적으로 사용될 수 있지만 모두 기본 프로세스인 애플리케이션 컨테이너가 원하는 방향으로 실행될 수 있도록 준비하는데 엤음
• 어떤 방식으로든 메인 프로세스의 환경 초기화 수행
• 포드에 대한 모든 네트워팅 및 스토리지가 프로비저닝된 후에 실행
• 포드의 intitial container가 실패하면 kubelet은 성공할 때까지 해당 init 컨테이너를 반복적으로 재시작
• 단, Pod restartPolicy: Never가 지정되었다면 해당 포드를 시작하는 동안 initial container가 실패하면 쿠버네티스는 전체 포드를 실패한 것으로 간주한 뒤 종료 
  • MAS 애플리케이션에 원격지의 소스로부터 최신 구성 파일을 가져오는 작업을 구성하면 initial container에 의해 애플리케이션 컨테이너는 항상 최신 구성 파일 사용 가능
  • 데이터베이스를 초기화하거나 애플리케이션 컨테이너가 연결되기 전에 초기(기본) 데이터를 채우는 작업을 구성하면 initial container는 스키마 생성이나 데이터 마이그레이션과 같은 데이터 베이스 설정 작업을 처리하며 데이터베이스가 애플리케이션 컨테이너와 상호 작용할 준비가 되었는지 확인
  • initial container 사례

  Local volume에 공유 영역 생성

  init container는 외부 리소스에 curl 요청을 보내고 해당 데이터를 Local volume에 기록

  Application container는 시작과 함께 동일한 Local volume에서 필요한 데이터를 읽음

 

<Sidecar container in Pod>

• application container와 함께 작동하여 특정 추가 기능과 애플리케이션의 관찰 가능성 향상을 위해 로깅 및 모니터링 서비스 구현
• 코드 분리를 촉진하고 관찰 가능성을 개선하며 확장성과 보안을 단순화하여 쿠버네티스 배포 향상
• application container에는 원래 목적의 기능에만 충실하고 나머지 부가적인 공통 기능들은 Sidecar container를 추가해 사용

• 웹서버 컨테이너는 웹서버로서의 역할에 충실하고 자신의 로그는 포드의 파일로 남길 수 있음
• 그러면 Sidecar container 역할인 로그 수집 컨테이너가 파일 시스템에 쌓이는 로그를 수집해서 외부의 로그 수집 시스템으로 보내는 역할 수행

<사례>

• 여러 MAS 환경의 application container는 들어오는 요청 처리와 같은 서비스의 핵심 기능 처리
• 애플리케이션에 대한 로깅 및 모니터링 기능을 Sidecar container로 구현
• Sidecar container는 수집된 로그를 중앙 로깅 시스템으로 전달하거나 생성된 로그를 캡처하여 적정한 대상으로 전달하는 역할만 담당
• 로깅 기능을 Sidecar container로 분리하여 application container가 본연의 작업에 집중하도록 하여 application container의 성능 유지
• 리소스 모니터링을 위해 Sidecar container는 Prometheus 같은 도구와 통합되어 지표를 수집하고, 리소스 사용량을 모니터링 하고, 마이크로서비스에 대한 성능 데이터 수집