쿠버네티스 - Probe

쿠버네티스에 대해 공부하다보니 학습량이 무지하게 많아졌다.

하지만 재밌어 보여서...ㅋㅋㅋㅋ 공부해보자

 

---

 

Probe란 무엇일까?

Probe는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단이다.

그 진단은 health check라고도 부르는데 뭐 그렇다.

 

주기적으로 진단하는 이유가 뭐야??

주기적으로 체크한 후

문제가 있는 컨테이너를 자동으로 재시작하거나 문제가 있는 컨테이너를 서비스에서 제외시키기 위한 것이다.

컨테이너 자동 재시작으로 다시 원활히 돌아간다면 다행이지만 문제가 생긴다면 그 즉시 그 컨테이너를 서비스에서 제외시켜야 한다.

그 컨테이너가 동작하지 않음에도 계속 접근해서 무엇인가 제공받으려고 한다면 그것이 문제기 때문이다.

 

kubelet은 컨테이너 상태를 진단하기 위한 핸들러를 호출해서 이용한다.

1. ExecAction

2. TCPScoketAction

3. HttpGetAction

 

---

 

Handler란 각 컨테이너의 상태를 진단하기 위한 방법을 명시한 것이다.

 

예를 들어

ExecAction은 지정된 명령어를 컨테이너에서 수행하고 exit code가 0일 때만 성공으로 분류

TCPAction은 지정된 포트로 TCP 소켓 연결을 시도

HttpGetAction은 지정된 포트와 url로 HTTP Get요청을 전송하며 응답상태가 200~400 구간에 속해야 성공으로 분류

 

 

---

 

그렇다면 Probe를 수행하는 방법은 몇가지가 있을까?

대표적으로 3가지다.

kubelet은 실행 중인 컨테이너에 대해 3가지 프로브를 지정할 수 있음

• Liveness
  • 애플리케이션의 상태를 체크해서 서버가 제대로 응답하는지 혹은 컨테이너가 제대로 동작중인지를 검사한다. Pod은 정상적인 Running 상태이지만, 애플리케이션에 문제가 생겨서 접속이 안되는 경우를 감지한다. (메모리 오버플로우 등) 문제를 감지하면 Pod을 죽이고 재실행하여 애플리케이션의 문제를 해결한다. (Restart Count 증가)
• Readiness
  • 컨테이너가 요청을 처리할 준비가 되었는지 확인하는 probe이다. Pod이 새로 배포되고 Running 상태여도 처음에 로딩하는 시간이 있기 때문에 이 시간 동안은 애플리케이션에 접속하려고 하면 오류가 발생한다. Readiness probe는 어플리케이션이 구동되기 전까지 서비스와 연결되지 않게 해준다. (Readiness Probe가 실패할 때 엔드포인트 컨트롤러가 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. ) Liveness Probe와 비교했을 때 어떤 차이가 있냐면, Liveness Probe는 probe 핸들러 조건 아래 fail이 나면 pod을 재실행 시키지만 Readiness Probe는 pod을 서비스로부터 제외시킨다. (Restart Count 증가 x)
• Startup
  • 컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. startup probe가 주어진 경우, 성공할 때 까지 다른 나머지 prob는 활성화 되지 않는다. 만약 startup probe가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다.

 

---

Probe를 쓰는 방법은 알았는데.. 어떤 상황일 때 쓰는건데?

• Liveness Probe
  • 컨테이너 속 프로세스가 unhealthy 상태가 되어 프로세스가 중단되면 원래는 kubelet이 파드의 restartPolicy에 따라 이미 자동으로 수행된다. => 이미 unhealthy에 관한 policy는 정해져 있음
  • Liveness는 어플리케이션이 데드락 상태에 머무르는 것을 감지하여 재시작할 때 유용
• Readiness Probe
  • probe가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면 Readiness probe를 지정하면 된다. 왜냐하면 그 전까지는 애플리케이션이 로드되지 않은 상황에서도 트래픽이 해당 애플리케이션으로 라우팅될 수 있기 때문
  • 혹은 컨테이너의 지속적인 유지 및 관리를 위해서 자체적으로 중단을 수행하는 경우는 pod을 죽이는 Liveness probe말고 Readiness probe를 사용할 수 있음
• Startup Probe
  • Startup Probe 서비스를 시작하는 데 오랜 시간이 걸리거나 불규칙적인 컨테이너에 설정하는 데 사용
  • 예를 들면 third party 에서 특정 데이터를 다운받는 등의 경우 startup probe가 성공하고 나서 liveness, readiness probe가 동작하기 때문에 기동시간이 불규칙적인 애플리케이션이 liveness probe에 의해 기동되기도 전에 재시작 되는 것을 방지

 

 

---

 

실전적으로는 HPA가 Scale Out 할 때도 유용하다.

 

Scale Out 과정일 때는 파드가 점점 증가한다.

Deployment로 파드와 ReplicaSet을 관리하고

Service와 Ingress를 사용하여 애플리케이션을 외부로 노출한다.

때로는 파드의 컨테이너가 어플리케이션이 준비가 되지 않았음에도 status가 Running으로 표시되어 파드도  Running이 되었고 트래픽이 유실될 수 있음.

=> 모든 컨테이너의 준비가 끝나고 트래픽이 유입되어야함

Container probes를 설정하자

 

 

 

HPA의 Scale In에도 이용할 수 있다.

 

파드의 종료를 요청했을 때 Pod는 Terminating이 되어 컨테이너에 정의된 container lifecycle hooks의 preStop이 실행되어 동시에 Service와 Ingress에서는 파드를 제거해서 추가 트래픽 유입이 없다.

preStop이 정의되지 않았거나 실행이 끝났다면 컨테이너 이미지에 정의된 STOPSIGNAL, SIGTERM 신호를 컨테이너의 기본 프로세스에 전송하여 안전하게 종료되도록 요청 후 파드가 삭제된다.

이러한 과정에서 파드와 컨테이너가 terminationGracePeriodSeconds 로 정의된 시간 또는 기본 값인 30초가 지난 후에도 동작하고 있다면 SIGKILL 시그널을 컨테이너의 모든 프로세스에 전송하고 파드를 강제 종료한다.

kubectl이 관리하는 컨테이너는 container lifecycle hooks의 postStart와 preStop을 통해 컨테이너 라이프사이클의 특정 지점에서 실행할 이벤트를 트리거할 수 있으며, 그 중 preStop은 컨테이너가 Terminated 상태에 들어가기 전에 실행된다.

preStop이 끝난 컨테이너는 이미지에 정의된 STOPSIGNAL 또는 SIGTERM 신호를 전송받고 프로세스가 안전하게 종료되어 파드가 종료되므로 Service와 Ingress에서 파드가 제거되어 트래픽이 차단된 후 파드의 종료가 시작되도록 하면 된다.

충분히 안전한 파드 종료를 위해서 terminationGracePeriodSeconds와 .lifecyccle.preStop을 추가하자.

 

---

 

다시 Probe를 꼭 설정해야 하느냐???에 대한 필요성을 다시 어필하자면

서비스를 제대로 제공하려면 예외처리가 필요하듯이

얘도 그렇다. Probe가 있어야 예외 상황을 처리할 수 있다.