[도커/쿠버네티스 기초] Kubernetes Pod - 개념, Lifecycle, Node Scheduling

1. Pod
Pod 안에는 하나의 독립적인 서비스를 구동할 수 있는 컨테이너가 존재하고 그 컨테이너들은 서비스가 연결될 수 있도록 포트를 가지고 있습니다. 각 Pod는 동일한 Host를 사용하고 있고 각각의 컨테이너는 같은 Pod 안에서는 같은 포트는 가질 수가 없습니다. 그리고 Pod가 생성될 때 고유의 IP가 생성이 되는데 쿠버네티스 클러스터 안에서 해당 IP로 접근이 가능하며 외부에서는 해당 IP로는 접근을 할 수가 없습니다. 따라서 Pod에 문제가 생기게 되면 해당 IP는 변경이 될 가능성이 있어 휘발성을 가지고 있습니다.

2. Label
라벨은 Pod뿐 아니라 모든 오브젝트에 생성 가능하며 Pod에서 가장 많이 사용이 됩니다. 라벨을 사용하는 이유는 목적에 따라 오브젝트들을 분류하고 분류된 오브젝트들만 골라서 연결을 하기 위함입니다. 라벨의 구성은 key와 value가 한쌍이고 한 Pod에는 여러 개의 라벨을 달 수가 있습니다. 예를 들면 서버의 기능에 따라 web, was, db로 라벨을 달 수도 있고 거기에 추가하여 개발, 테스트, 운영 환경에 대한 라벨을 달아서 분류가 가능합니다. 마치 해시태그를 달아서 검색을 하여 사용하듯이 사용할 수 있습니다.

3. NodeSchedule
- 직접 선택: Node에 라벨을 달고 Pod에 Node를 지정할 수 있습니다.
- 쿠버네티스 스케줄러: Node에는 전체 사용 가능한 자원의 양이 정해져 있고, 이를 스케줄러가 판단하여 Node를 지정하게 됩니다. Memory의 경우 초과 시 Pod를 즉시 종료시키게 되고, CPU가 자원을 초과할 경우 request를 낮추는 역할을 합니다.

4. Pod - Lifecycle
* Pending > Running > Succeeded > Failed
 - Pending: ReadinessProbe, Policy
 - Running: LivenessProbe, Qos
 - Succeeded, Failed: Poicy

Pod의 Status 구조를 보면 Phase는 단계를 의미하며 Condition 상태와 그에 대한 상세 정보로 Reason을 확인해볼 수 있습니다. 또한 ContainerStatuses를 통해 컨테이너의 상태와 상세 정보를 확인해볼 수 있습니다.

 

5. ReadinessProbe, LivenessProbe
- ReadinessProbe
Pod가 Fail이 되어 Autohealing 기능에 의해서 Pod가 재생성될 경우, 재생성된 Pod와 Container는 Running 상태이지만 아직 App이 부팅 중인 상태가 될 수 있습니다. 이럴 경우 사용자는 App이 구동되기 전까지 오류를 발생할 수 있어 ReadinessProbe는 App이 구동되기 전까지 연결이 되지 않게 해 줍니다. 따라서 App 구동 순간에 대한 트래픽 실패를 없앨 수 있습니다.

- LivenessProbe
Pod는 Running 상태이지만 App이 다운될 경우, App에 대한 장애 상황을 감지하는 것이 LivenessProbe입니다. 따라서 App 장애 시 지속적인 트래픽 실패를 없앨 수 있습니다.

- Qos: Quality of Service
노드에 있는 Pod가 모든 자원을 사용하고 있을 때, 특정 Pod에서 추가 자원 사용이 필요할 경우, 앱의 중요도에 따라 3단계로 자원에 대한 배정을 관리합니다. BestEffort < Burstable < Guarnteed 순서로 자원이 할당되므로 BestEffort의 자원이 가장 먼저 사라지고 자원이 계속 부족할 경우 Guarnteed 가 최종적으로 남아있게 됩니다. 각각은 Request와 limits를 설정하여 관리됩니다.

6. Node Scheduling
[Node 선택]
- NodeName: 스케줄러와는 상관없이 명시적으로 노드를 할당할 때 사용합니다. 하지만 이는 노드 이름이 삭제/생성되면서 변경될 수 있기 때문에 사용률이 적습니다.
- NodeSelector: Key와 Value가 매칭이 되는 노드 중 자원이 많은 노드에 Pod가 할당되도록 합니다. 하지만 Key와 Value가 맞는 노드가 하나도 없을 경우 에러를 발생시킬 수 있습니다.
- NodeAffinity: Key만 설정을 하여도 스케줄러를 통해서 자원이 많은 노드에 Pod가 할당이 되고 만약 조건이 맞는 노드가 없더라도 옵션을 통해 자원이 많이 남아있는 노드에 할당되도록 설정이 가능합니다.

[Pod 간 집중/ 분산]
여러 노드를 한 노드에 집중해서 할당을 하거나 Pod 간 겹치는 노드 없이 분산하여 할당 가능
- Pod Affinity: 꼭 같이 사용이 필요한 Pod는 Pod Affinity를 통해 할당해야 하는데 이는 PV를 통해 할 수 있습니다. 한 노드에 Pod를 할당하면 그 노드에 PV를 생성하고 PV는 같이 할당이 필요한 Pod에 라벨을 붙여 동일한 노드에 Pod 가 생성되도록 합니다.
- Anti-Affinity: 다른 노드에 꼭 분산하여 Pod의 배치가 필요한 경우 사용하며 한 Pod가 노드에 할당이 되면 동일 Anti-Affinity를 주어 할당된 Pod의 Key, Value를 설정을 하면 이 Pod는 다른 노드에 할당이 됩니다.

[Node에 할당 제한]
특정 Nod에는 아무 Pod가 할당되지 않도록 제한을 하기 위해서 사용
- Toleration / Taint: Taint 설정을 하게 되면 일반적인 Pod 들은 스케줄러가 이 노드로 할당을 시키지 않습니다. 이 노드에 할당을 하기 위해서는 Toleration이 달려있는 Pod만 할당이 가능합니다.