쿠버네티스 이론 : 파드 (Life cycle, Probe, QoS classes)

이번 포스팅에는 파드에 대해서 더 자세히 알아보도록 하겠습니다. 이번 포스팅은 생명주기, Probe, QoS class에 대해서 정리해봤습니다. 

 

파드의 생명주기

파드의 상태에는 파드의 전체적인 상태를 나타내는 Phase가 있고 세부적인 상태를 나타내는 Condition이 있습니다. 그리고 파드안에는 컨테이너가 여러개 들어가있고 이 컨테이너들의 상태를 볼 수 있는 State라는 속성이 있습니다. 

 

파드의 전체적인 상태를 나타내는 Phase에는 Pending, Running, Succeeded, Failed, Unkown 이렇게 다섯가지가 있습니다. 

 

• Pending : Pending은 파드의 최초 상태입니다. 이때 파드를 구동하기위해 필요한 작업을 진행합니다. 
  
  1. 컨테이너의 초기 상태를 세팅하기 위해 initContainer가 작동합니다. initContainer의 성공과 실패 여부에 따라 initialized 속성이 True가 되기도 하고 False가 되기도 합니다. 
  2. 이후 파드가 어느 노드에 올라갈지 수동으로 정해주거나 노드스케줄러에 의해 자동으로 올라간다면 PodScheduled 속성이 True 혹은 False가 됩니다. 
  3. 이후 파드가 올라갈 노드가 정해지면 파드를 구동하기 위해 템플릿에 정해놓은 이미지를 다운로드합니다. 이때, 컨테이너의 State는 Waiting이 되고 Reason은 ContainerCreating이 됩니다. 
• Running : Running은 파드가 실행되는 과정입니다. 파드가 실행되는 과정에서 다양한 문제가 발생할 수 잇꼬 이를 상태값으로 관리합니다. 
  
  1. 파드에 컨테이너가 올라가면서 생기는 다양한 문제들을 Reason에 적습니다. 이 때, 파드가 재시작될 수 있고 상태는 Waiting, Reason은 CrashLoopbackup이 됩니다. 
  2. 파드들이 정상적으로 동작하면 ContainerStatus의 State는 Running이 되고 이에 따라 속성들을 모두 True로 바꿉니다. 
• Failed / Succeeded : 만약 Job이나 CronJob에 의해 파드가 생성되는 경우 파드의 할 일이 끝나고 나면 해당 상태로 돌입하게 됩니다. 파드가 하나라도 에러에 의해 종료되는 경우 Failed가 되고 정상적으로 모든 파드가 종료되는 경우 Succeeded가 됩니다. 

 

만약 파드가 정상적으로 동작한다면 생명주기는 Pending -> Running (계속 동작해야 하는 파드) -> Failed or Succeeded 가 됩니다.

 

하지만 만약 Pending 상태에서 파드를 생성할 수 없어 바로 Failed로 넘어갈 수도 있고 네트워크 장애가 발생해서 Unkown으로 변경될 수도 있습니다. 

 

 

Probe

Probe에는 ReadinessProbe가 있고 LivenessProbe가 있습니다. 이 두개가 왜 사용되는지 언제 사용되는지 먼저 짚고 넘어가도록 하겠습니다. 

 

만약 서로 다른 두 노드에 파드가 생성되어있고 서비스가 이 두파드를 바라보고 있다고 했을 때, 정상적인 상황에선 양쪽에 트래픽이 50:50 으로 흐르게 될 것입니다. 

 

이때 하나의 파드에 장애가 생겼고 쿠버네티스가 자동으로 이 파드를 재시작한다면 파드가 생성되자마자 곧바로 서비스에 바로 파드가 연결됩니다. 

 

하지만 이 파드의 앱이 구동중이라 파드는 생성되었지만 컨테이너 내부의 앱은 접근할 수 없다면 500 Server Internal Error가 뜨게 됩니다. 스프링부트만 하더라도 서버에서 구동되는 동안 외부에서 접근할 수 없는 것과 같은 이치입니다. 

 

그럼 이 컨테이너의 앱이 부팅중일 때 사용자는 에러 페이지를 보게 되겠죠. 

 

이를 해결하기 위해 ReadinessProbe가 사용됩니다. ReadinessProbe는 파드 내부의 컨테이너에 정상적으로 앱이 이용 가능한지 체크합니다. ReadinessProbe가 컨테이너 내부에 헬스체크를 해서 외부에 연결해도 되는지 체크하는 역할을 합니다. 

 

그리고 이후 상황에서 파드가 정상적으로 작동은 하고 있지만 앱이 다운되는 경우도 Probe가 필요합니다. 

 

파드는 정상인데 앱이 다운되는 경우는 어떤 경우가 있을까요? 

 

흔치 않지만 Tomcat은 정상 작동 중인데 내부의 앱이 정상적으로 작동하지 않을 때 생길 수 있는 문제입니다. 이때 우리는 LivenessProbe를 이용하면 이 앱이 살아있는지 죽어있는지 체크해서 파드 전체를 재시작해줄 수 있습니다. 

 

ReadinessProbe, LivenessProbe의 설정들

ReadinessProbe와 LivenessProbe는 하는 역할은 다르지만 기본적으로 비슷하게 동작합니다. ReadinessProbe와 LivenessProbe 모두 파드내 컨테이너안에 앱의 상태를 확인한다는 점에서 같은 설정을 공유합니다. 

 

ReadinessProbe와 LivenessProbe는 세가지 설정 중 하나는 무조건 있어야합니다. 

 

• httpGet : 컨테이너 내부 앱에 HTTP요청을 보냄으로써 앱의 상태를 확인합니다. httpGet의 속성으로 가질 수 있는 값들은 Port (어떤 포트로), Host (어떤 주소로), Path (어떤 API로), HttpHeader (어떤 HTTP header를), Scheme(HTTP 혹은 HTTPS로) 보낼지 설정할 수 있습니다. 
• Exec : 앱에 직접 HTTP요청을 보내는 httpGet과 다르게 컨테이너 내부의 특정 파일이나 명령어가 동작하는 경우 사용할 수 있ㅅ브니다. 사용할 수 있는 속성은 Command 하나뿐이지만 cat /tmp/ready.txt 처럼 어떤 파일이 있는지 확인하는 용도로 확인할 수 있습니다. 
• tcpSocket : tcpSocket은 Host와 Port를 설정해 소켓통신으로 지속적으로 앱의 상태를 확인합니다. 

ReadinessProbe와 LivenessProbe는 위의 세가지 설정 중 반드시 하나는 있어야하고 세부적으로 아래와 같은 설정을 가질 수 있습니다. 

 

• initialDelaySeconds : Probe들이 파드 구동 후 몇초부터 시작할지 정하는 설정입니다. 디폴트 값은 0초입니다. 
• periodSeconds : Probe들이 어느정도의 기간을 가지고 앱의 상태를 확인할지 설정합니다. 디폴트 값은 10초입니다. 
• timeoutSeconds : 만약 타임아웃이 난다면 몇초동안 몇초동안 타임아웃이 나면 죽었다고 판단할지 정하는 설정입니다. 디폴트 값은 1초입니다. 
• successThreshold : 주요 세가지 설정들이 몇 번 성공해야 이 앱이 살아있다고 판단할 것인지 정하는 설정입니다. 디폴트 값은 1번입니다. 
• failureThreshold : 주요 세가지 설정들이 몇 번 실패해야 앱이 죽었다고 판단할 것인지 정하는 설정입니다. 디폴트 값은 3번입니다. 

 

예시로 Probe 체험하기

ReadinessProbe와 LivenessProbe는 주요한 세가지 설정 중 최소 하나와 나머지 부가 설정들에 의해 앱의 상태를 확인합니다. 이번 섹션에선 한 가지 예시로 ReadinessProbe와 LivenessProbe를 정리하도록 하겠습니다. 

 

ReadinessProbe

• 주요 설정은 Exec로 Command는 cat /tmp/ready.txt입니다. 
• initialDelaySeconds : 5
• periodSeconds : 10
• successThreshold : 3

LivenessProbe

• 주요 설정은 httpGet으로 path에 /health입니다. 
• initialDelaySeconds : 5
• periodSeconds : 10
• failureThreshold : 3

이 설정대로 ReadinessProbe 시나리오를 가정해보겠습니다. 

1. 파드를 생성한다. 
2. 컨테이너가 생성된다. 컨테이너의 상태가 ContainerReady: False, Ready: False로 설정된다. 
3. intialDelaySeconds에 의해 컨테이너 생성 5초 뒤 상태를 체크한다. 
4. Exec로 컨테이너 내부로 들어가 cat /tmp/ready.txt를 입력한다. 
5. periodSeconds에 의해 10초 간격으로 재실행한다. 
6. successThreshold에 의해 3번 성공하면 성공적으로 앱이 구동됐다는 것으로 인지한다. 
7. 앱의 구동이 완료되기 전까지 ContainerReady와 Ready 속성은 False로 되어있다가 완료가 되면 두 속성을 모두 True로 바꾼다. 
8. 서비스는 그제서야 해당 파드를 엔드포인트로 설정한다. 

다음 LivenessProbe 시나리오를 가정해보겠습니다. 

1. LivenessProbe는 initialDelaySeconds에 의해 컨테이너 생성 후 5초뒤부터 앱의 상태를 점검한다.
2. periodSeconds에 의해 앱의 상태를 점검하기 시작한 뒤로부터 10초간격으로 지속적으로 점검한다. 
3. 만약 200 OK라면 넘어간다. 
4. 앱이 죽어버려서 헬스체크가 500 Server Internal Error로 변경된다. 
5. periodSeconds에 의해 10초간격으로 지속적으로 요청한다. 
6. failureThreshold에 의해 3번 실패하는 경우 파드를 재실행한다. 
7. 이후 ReadinessProbe의 상황을 다시 반복된다. 

 

QoS classes

QoS는 Quality of Service의 약자로서 파드별로 어떤 파드가 중요하게 관리해야하는지 쿠버네티스에게 알려주는 용도로 사용됩니다. 

 

QoS class는 Guaranteed, Burstable, BestEffort가 있고 오른쪽으로 갈수록 중요하지 않은 파드입니다. 

 

만약 노드의 자원을 동일하게 사용하고 있는 세게의 파드가 있고 각각 Guaranteed, Burstable, BestEffort일 때 Guaranteed 파드에서 자원이 더 필요한 경우 BestEffort파드를 죽이고 BestEffort에 할당된 자원을 반납합니다. 그리고 그 자원을 Guaranteed에 분배해줍니다. 

 

Burstable의 파드는 BestEffort만큼은 아니지만 노드의 자원보다 더 많은 자원을 사용하는 경우나 Guaranteed파드가 다른 파드에 분배된 자원보다 더 많이 사용해야하는 경우 차선책으로 파드를 내리고 자원을 회수합니다. 

 

QoS는 따로 설정하는 것이 아니라 컨테이너의 resource 속성에 적힌 requests와 limits의 설정값에 의해 결정됩니다. 

 

• Guaranteed : 쿠버네티스 입장에서 가장 안정적으로 운영되어야한다고 판단되는 파드입니다. 쿠버네티스가 Guaranteed파드로 인식하기 위해서는 다음과 같은 조건이 충족되어야합니다. 
  
  1. 모든 컨테이너에 requests와 limits가 설정되어 있어야합니다. 
  2. requests와 limits에는 모두 Memory와 CPU가 설정되어있어야합니다. 
  3. 각 컨테이너 내의 Memory와 CPU의 requests와 limits의 값이 같아야합니다. 
• Burstable : 쿠버네티스 입장에서 두번째로 안정적으로 운영되어야한다고 판단되는 파드입니다. 쿠버네티스가 Burstable 파드로 인식하기 위해서는 requests와 limits의 크기가 다르거나, requests는 설정되어있는데 limits는 설정이 되어있지 않거나, 파드안에 컨테이너 중 어떤 것은 requests와 limits가 설정되어있지만 어떤 것은 설정 되어있지 않은 경우 (불규칙한 경우) 에 해당 파드는 Burstable 파드로 인식합니다. 
• BestEffort : BestEffort는 컨테이너 내부에 자원 설정을 전혀 하지 않는 경우 쿠버네티스가 해당 파드를 BestEffort로 인식합니다. 

 

마치며

원래였으면 쿠버네티스 파드편으로 묶어서 포스팅하려고 했지만 양이 너무 많아 두개로 나누게 되었습니다. 다음 포스팅에선 쿠버네티스 실전 : 파드 편이 포스팅됩니다.