쿠버네티스의 pod에 대해서 조금 더 깊이 있는 글을 작성해 보려고 한다.

Lifecycle

Phase

순차적으로 다음과 같이 진행

Pending

init 하는 단계
Initialized: True
Container 상태는 waiting이며 이때 컨테이너 생성 및 이미지를 다운로드 하게 된다

Running

pod이 running 상태이더라도 안에 container가 실행되는건 별도
Container 상태가 성공을 하면 running 실패하면 waiting(CrashLoopBackOff)
운영 단계에선 계속 이 상태를 유지해야 된다.

ReadinessProbe, LivenessProbe

쿠버네티스는 프로세스의 정상 상태를 확인하고 pod의 프로세스가 정상 기동 중이 아니면 pod을 재시작한다.
하지만 어플리케이션이 응답을 할 수 없는 상태일 경우 프로세스가 계속 떠있으면 장애가 발생할 수 있다.
이걸 방지하기 위해 LivenessProbe와 Readiness Probe로 어플리케이션의 상태를 점검하고 쿠버네티스가 조취할 수 있게 해준다.

LivenessProbe

주기적으로 수행되면 어플리케이션의 생존 상태 점검
통과에 실패하는 경우 컨테이너를 재시작

ReadinessProbe

실패시 컨테이너를 대체하지 않고 기다린다.
어플리케이션이 정상 실행될 때 까지 대기할때 설정

QOS

한 pod에서 많은 리소스를 소모할 경우 다른 pod에서 리소스를 빌려서 정상 작동하게 해주는 것
별도 설정은 아니고 pod의 resource를 보고 조절해준다.

• guaranteed가 가장 중요한 서비스라 판단해 bestEffort나 burstable에서 리소스를 빌려올 수 있다. 이를 위해 모든 컨테이너에 request limimit에 memory, cpu 값을 모두 설정해야 한다
• bestEffort 어떤 컨테이더에서도 request와 limit을 설정해 주지 않는다
• burstable 일부 컨테이너만 혹은 일부 값만 설정이 되었을때 oom score에 맞게 제거가 된다
  

Node Scheduling

Node 선택

NodeName

노드 네임을 지정해 주어 이에 맞는 노드에 pod을 생성

NodeSelector

pod의 키와 밸류에 맞는 노드에 생성
일치 하는 키와 밸류가 없으면 pod이 생성되지 않아 오류가 발생할 수 있음

NodeAffinity

키만 설정했을 때 스케쥴러가 자동으로 이 키값에 맞게 pod을 생성
matchExpression에서 key 값은 일치하게 operator은 'Exists'하면 이에 맞는 노드에 스케쥴링 해준다.
required를 설정했을땐 반드시 key값이 일치해야 할당되지만 preferred일 경우 일치하지 않아도 적절하게 할당해준다.
preferred일 경우 어느 노드를 우선적으로 할당할지 weight를 줄 수 있다.

PodAffinity

한 노드에 같이 있어야 작동하는 pod 끼리 엮어서 같은 node 안에 스케쥴링 해주는 것

AntiAffinity

Pod Affinity와 반대 개념 master과 slave를 생성해 master과 slave는 다른 노드에 들어가게 스케쥴링 된다.
다양한 node에 컨테이너가 존재하게하여 트래픽이 몰린 경우에도 서비스를 안정적으로 할 수 있게할때 사용한다.

Toleration/Taint

특정 하드웨어 혹은 소프트웨어가 요구되는 작업(ex. gpu)을 하는 pod만 해당 스케쥴링 할때 할당하고 싶을때 toleration을 갖고 있는 pod만 스케쥴링 될 수 있게 해준다.