기본 Object - Pod

Pending 단계

Conditions

• PodScheduled
  • Pod가 위치할 Node 선정을 먼저 동작 후 Initialized
• Initalized
  • 설정을 하지 않으면 True
  • initContainer를 설정 했는데 성공적으로 끝났다면 True

 Container

• Waiting 상태
• Reason: ContainerCreating

Running 단계

Conditions

• ContainerReady: True
• Ready: True

Container

• Running 상태

Succeeded & Failed 단계

Conditions

• ContainerReady: False
• Ready: True

컨테이너에 문제가 생겨서 하나라도 Reason이 에러가 나면, Failed 단계

컨테이너가 전부 Completed 된다면 Succeeded 단계

Unknown 단계

통신 장애 발생시 생김

 

initalDelaySeconds: 최초 Probe 전에 Delay 시간

periodSconds: Probe를 체크하는 시간 간격

timeoutSeconds: 지정된 시간까지 결과가 도착

successThreshold: 몇번 성공 결과를 받아야 인정

failureThreshold: 몇번 실패 결과를 받아야 실패

 

ReadinesProbe 동작

initaldelaySeconds: 5

periodSeconds: 10

successThreshold: 3

• Pod Running단계에서 Conditions가
  ContainerReady: false
  Ready: false
  이면, Service의 Endpoint는 “NotReadyAddr” 로 간주하고 서비스를 pod와 연결하지 않습니다.
• initaldelaySeconds: 5, 최초 5초 동안 지연하고 있다가, 상태체크를 해보고
  상태체크 실패를 하면, periodSeconds: 10 10초 후에 다시 재시도 합니다.
  계속 실패한다면, 컨디션의
  ContainerReady: false
  Ready: false
  는 계속 false로 유지 됩니다.
• successThreshold: 3, 3회 성공시
  ContainerReady: True
  Ready: True
  가 되고, Endpoint도 정상적으로 “Address”로 간주하고 Service를 Pod와 연결합니다.

LivenessProbe

initaldelaySeconds: 5

periodSeconds: 10

failureThreshold: 3

• Pod가 동작중인 상태에서 initaldelaySeconds: 5, 5초 후에 상태체크를 합니다.
  periodSeconds: 10 10초 마다 반복적으로 상태체크를 재시도 합니다.
• failureThreshold: 3 상태 체크 3회 실패시 문제가 있다고 판단하고, 해당 pod를 재시작 합니다.

Qos 자원 부족시 제거 되는 순서

Guaranteed > Burstable > BestEffort

Guaranteed

• 모든 Container에 Request와 Limit 설정
• Request와 Limit에는 Memory와 CPU가 모두 설정
• 각 Container 내에 Memory와 CPU의 Request와 Limit 값이 같을 경우

Burstable

• Request 설정이 Limit보다 작은 경우
• Request 설정 했지만, Limit을 설정 안한 경우
• 파드 내에 컨테이너는 2개인데, 파드 1개는 설정을 했지만, 다른 컨테이너는 설정을 안했을 경우

BestEffort

• 어떤 Container 내에도 Request와 Limit 미설정

Burstable의 경쟁

• App 사용량이 동일할 경우 4GB일 경우, Request 가 낮은 쪽이 먼저 제거 됨
  (Request를 기준으로 사용량 측정시 높은쪽이 먼저 제거됨)

Node Scheduling

• 쿠버네티스 스케줄러는 CPU 자원이 가장 많은 노드에 pod를 할당한다.
• NodeName 노드 이름으로 Pod가 할당 됩니다.
  노드네임은 변경 될 수 있어서 사용하지 않습니다.
• NodeSelector key와 vaule가 일치하는 노드에 pod를 배치합니다.
  매칭이 되는 라벨이 없으면, pod는 배치되지 않고 에러가 발생합니다.
• NodeAffinity pod에 key만 설정해도, 해당 key를 가진 노드에 할당이 되고,
  만약 해당 조건에 맞는 노드가 없어도, 자원이 많은 노드에 할당 됩니다.

 

• Pod Affinity 두 파드가 같은 노드에 할당하려고 할 때 사용
  key value가 일치 할때 Affinity 동작
• Anti-Affinity 두 파드가 다른 노드에 위치 해야 할 때 사용

 

• 노드가 Taint 설정이 되면 일반적인 pod는 노드에 접근이 불가능하다
  pod가 Toleration을 달고 오면 접근이 가능해진다.

Taint

• Toleration 파드가 Taint된 노드에 할당 할때는
  key, value, effect가 전부 일치해야 할당될 수 있다.
• Toleration은 Taint노드에 접근하는 설정이고, Taint 설정이 안된 다른 노드에도 스케줄링이 될 수도 있다.
  taint된 노드의 노드셀렉터가 필요하다.

 

• NoSchedule은 노드에 설정해도, 기존 Pod가 쫓겨나지 않는다.
• NoExcute는 노드에 설정하면, 기존 Pod가 삭제 된다.
• Master 노드는 NoSchedule 설정이 되어 있다.

 

• Operator: Equal, Exists
• Effect: NoSchedule, PreferNoSchedule, NoExecute