![[쿠버네티스] Pod](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FlPGOn%2FbtrX2YpZANR%2FM7TCncK5j997e63zc6MRTk%2Fimg.png)
본 포스팅은 김태민 님의 대세는 쿠버네티스 [초급~중급] 섹션 5를듣고 요약한 내용입니다.
Pod
status:
phase: Pending
conditions:
- type: Initialized
status: 'True'
lastProbeTime: null
lastTransitionTime: '2019-09-26T22:07:56Z'
- type: ContainersReady
status: 'False'
lastProbeTime: null
lastTransitionTime: '2019-09-26T22:08:11Z'
reason: ContainersNotReady
containerStatuses:
- name: container
state:
waiting:
reason: ContainerCreating
lastState: {}
ready: false
restartCount: 0
image: tmkube/init
imageID: ''
started: false
Phase : pod의 전체 속성을 대표합니다.
Conditions : pod가 생성되면서 실행하는 단계와 상태를 알려줍니다. status가 'false' 일 경우, 그 이유를 알기 위해서 세부 사항인 reason이 추가됩니다.
*Reason : Conditions의 세부 내용을 알려줍니다.
containers 안의 State : 컨테이너의 상태를 대표합니다.
Pending : pod의 최초상태입니다. pod가 pending상태일 경우, 본 컨테이너가 기동되기 전에 초기화할 내용을 InitContainer에 담아
본 컨테이너보다 먼저 실행합니다. 이때, Initialized가 true이면 초기화가 완료된 상태를 뜻합니다.
Running : 컨테이너가 기동될 때의 pod의 상태를 의미합니다. 만약 컨테이너에 문제가 발생했다면, Container의 status는 waiting이 되고, crashLoopBackOff와 같은 Reason이 생성됩니다.
Failed : 작업을 하는 중에, 하나라도 문제가 발생하면 pod의 상태는 failed로 변하게 됩니다.
Succeeded : 작업이 성공적으로 마무리 되었으면 pod의 상태는 Succeeded로 변하게 됩니다.
ReadinessProbe , LivenessProbe
ReadinessProbe : App 구동 순간에 트래픽 실패를 없앱니다. 예를 들어, Pod1과 Pod2가 각각의 노드에서 돌아가고 있는 상황이라고 했을 때, Pod2에 문제가 생기면 쿠버네티스는 오토힐링 기능을 통해 Pod2를 재시작할 것입니다. 이때, Pod2가 부팅되는 동안 Pod2로 가는 트래픽은 실패가 뜰 것인데, 이때 트래픽 실패를 없애기 위해 ReadinessProbe가 사용됩니다. ReadinessProbe가 사용되면, 앱이 구동되는 동안은 트래픽들을 전부 Pod1으로 보내서 트래픽 실패를 없애게 됩니다. 앱이 구동이 완료되면, 다시 Pod1과 Pod2가 각각 50%의 트래픽을 가지게 됩니다.
LivenessProbe : App 장애시 지속적인 트래픽 실패를 없앱니다. App에서 장애가 발생하면, Pod가 재실행하게 만들어서, 잠시동안은 트래픽 실패가 일어나지만, 지속적으로 에러 상태가 되는 것을 방지합니다.
Qos classes
앱의 중요도에 따라 자원을 반환시킵니다. BestEffort , Burstable, Guaranteed 순으로 자원이 반환이 이루어집니다.
pod의 resource에 request와 limits 양에 따라 중요도가 결정됩니다.
Guaranteed : 모든 Container에 Request와 Limit가 설정되어 있고, Request와 Limit에는 Memory와 CPU가 모두 설정되어 있어야 합니다. 또한 각 Containter 내에 메모리와 CPU의 Request와 Limit의 값이 같아야 쿠버네티스는 이 pod를 guaranteed 클래스로 판단합니다.
Burstable : Guaranteed와 BestEffort의 사이로 Request와 Limit모두 설정되어 있지만 Request가 더 적은 경우, Request만 설정되어 있는 경우, Pod에 컨테이너가 두개인데 한개만 Request와 Limit이 설정되어 있는 경우 등이 Burstable에 해당됩니다.
BestEffort : 어떤 컨테이너 내에도 Request와 Limit이 미설정되어 있어야 합니다.
Node Scheduling
1. 원하는 노드에 pod를 할당하고 싶을 때, pod를 특정 노드에 할당되도록 선택하기 위한 용도로 사용합니다.
- NodeName : NodeName의 이름으로 Pod가 바로 할당됩니다. 노드 이름이 변경될 수 있기 때문에 권장되지 않습니다.
- NodeSelector : pod에 키와 value를 달면, 해당 라벨이 달려있는 노드에 할당이 됩니다. 두 노드가 같은 라벨을 가진 경우, 스케줄러가 자원이 많은 쪽으로 할당하게 도비니다.
- NodeAffinity : Pod에 키만 설정해두면, 해당 그룹중에 스케줄러를 통해 자원이 많은 곳에 할당을 합니다.
- matchExpressions : 키 값이 일치하는 노드에 할당합니다.
- required : NodeAffinity로 required 속성을 가진다면, pod의 키 값과 일치하지 않는 노드에는 스케줄링 되지 않습니다.
- preferred : 키 값이 일치하는 것이 선호된다는 의미로, pod의 키 값과 node의 키 값이 달라도 스케줄링 될 수 있습니다. weight는 가중치를 의미하며, 가중치가 큰 것이 먼저 스케줄링 됩니다.
2. 한 Pod에 집중해서 할당하거나, 분산하기 위한 용도로 사용합니다.
- Pod Affinity : Pod를 만들때 라벨과 Pod Affinity를 지정하면, 한 노드에 집중해서 할당하게 됩니다. Pod Affinity가 지정되어 있을 경우, values가 같은 pod를 찾아 그 노드에 할당됩니다.
- Anti-Affinity : 두 개의 Pod를 만들때 Anti-Affinity를 지정하면, 두 개의 Pod는 각각 다른 Node로 할당되게 됩니다. Anti-Affinity가 지정되어 있을 경우, values가 같은 pod에는 할당되지 않습니다.
3. 아무 Pod에나 할당되지 않도록 제한하기 위한 용도로 사용합니다.
- Toleration / Taint : Taint가 설정된 노드에는 Toleration이 설정된 Pod만이 할당될 수 있습니다. Taint의 라벨과 Toleration의 키 value가 맞는 Pod만이 Taint가 설정된 노드에 할당될 수 있습니다. 하지만 Toleration이 설정된 Pod는 Taint가 없는 노드에도 할당될 수 있는데, 이를 막기위해 NodeSelector를 사용합니다. NoSchedule은 더 이상 Pod가 할당되지 않게 하고(이미 할당된건 유지), NoExecute는 이미 할당된 Pod도 중지시킵니다. 이때 NoExecute에 추가로 tolerationSeconds를 추가하면 60초 후에 중지되게 할 수 있습니다.
