self-healing
Kubernetes는 자체적으로 self-healing이 가능한데요.
시스템이 영향을 받을 때마다 pod, container 단위로 상태를 감지하고, 비정상적인 경우 자체적으로 교체하여 안정적인 서비스를 유지할 수 있도록 도와줍니다.
Self-healing Kubernetes restarts containers that fail, replaces containers, kills containers that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve.
livenessProbe
컨테이너가 동작 중인지 여부를 나타낸다.
만약 활성 프로브(liveness probe)에 실패한다면, kubelet은 컨테이너를 죽이고, 해당 컨테이너는 재시작 정책의 대상이 된다.
만약 컨테이너가 활성 프로브를 제공하지 않는 경우, 기본 상태는 Success 이다.
k8s가 아무런 설정없이 자체적으로 모든 실패한 케이스에 대해 식별할 수는 없습니다.
배포나 운영 중에 container, pod가 죽는 경우 k8s가 식별할 수 있어서 바로 replica와 교체하면서 운영 pod를 유지하며 빠르게 교체가 가능하지만, pod내 사용자가 만든 application에서 panic 등 실제 application이 죽지 않는 경우의 여러 가지 상황의 에러를 감지할 수 없습니다..
예를 들어봅시다, Get /backend/api/actuator/health가 500에러가 나는 경우는 어떻게 파악할까요?
k8s는 liveness라는 probe를 통해 pod의 상태를 식별할 수 있도록 제공합니다.
사용자가 정의해둔 로직에 따라 구별할 수 있는데요.
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-http
spec:
containers:
- name: livenessTest
image: imageAddress
livenessProbe:
httpGet:
path: /backend/api/actuator/health
port: 8080
httpHeaders:
- name: X-API-Key
value: IfHaveAPIKeyWriteThis
initialDelaySeconds: 1
periodSeconds: 3periodSeconds에 따라 3초마다 livenessProbe를 수행하고요. 시작 전 1초의 딜레이를 가집니다.
livenessProbe가 시작되면 Get host:8080/backend/api/actuator/health로 웹 요청이 발생합ㄴ디ㅏ.
이 때 header는 지정된 X-API-Key: IfHaveAPIKeyWriteThis 가 포함되어 전송 됩니다.
성공 시 pass, 실패 시 container를 재시작합니다.
여기서 하나 주의깊게 봐야할 점은 HTTP Response Code가 200~399번때 까지는 Success, 나머지는 Fail 로 본다는 점입니다.
추가로 livenessProbe에 httpGet 으로 지정된 부분은 livenessProbe에서 HTTPGetAction 액션 사용을 위한 내용이며, 다른 액션을 사용하면 TCP 기반이나 Exec 기반으로도 점검이 가능합니다.
livenessProbe Action
총 3가지를 지원하며 내용은 아래와 같습니다.
Action
- HTTPGetAction
지정된 포트와 URL로 GET 요청 후 Response Status Code가 200~399까지 성공으로 판단 - ExecAction
컨테이너 내부에서 명령 실행 후 Return이 0이면 성공으로 판단 - TCPSocketAction
특정 IP에 대해 TCP Connection 수행, 포트가 활성화 되어 있다면 성공으로 판단
Other Probe
- livenessProbe
컨테이너의 동작 여부 판단. 만약 실패로 판단되면 kubelet은 container를 재 시작함 - readinessProbe
컨테이너가 준비되었는지 판단. 만약 실패라면 Pod의 IP가 연관된 Service에서 제거됨 - startupProbe
컨테이너 내 어플리케이션이 시작되었는지 판단. 실패하면 재시작
readinessProbe
컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
만약 준비성 프로브(readiness probe)가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP 주소를 제거한다.
준비성 프로브의 초기 지연 이전의 기본 상태는 Failure이다. 만약 컨테이너가 준비성 프로브를 지원하지 않는다면, 기본 상태는 Success 이다.
startupProbe
컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다.
스타트업 프로브(startup probe)가 주어진 경우, 성공할 때 까지 다른 나머지 프로브는 활성화 되지 않는다. 만약 스타트업 프로브가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다. 컨테이너에 스타트업 프로브가 없는 경우, 기본 상태는 Success 이다.
언제 활성 프로브(liveness probe)를 사용
- 만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 반드시 필요한 것은 아니다. 이러한 경우에는 kubelet이 파드의 재시작 정책(restart policy)에 따라서 올바른 대처를 자동적으로 수행한다.
- 프로브가 실패한 후 컨테이너가 종료되거나 재시작 되기를 원한다면, 활성 프로브를 지정하고, 재시작 정책을 항상(Always) 또는 실패 시(OnFailure)로 지정한다.
언제 준비성 프로브(readiness probe)를 사용
- 프로브가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면, 준비성 프로브를 지정하기를 바란다. 이 경우에서는, 준비성 프로브가 활성 프로브와 유사해 보일 수도 있지만, 스팩에 준비성 프로브가 존재한다는 것은 파드가 트래픽을 받지 않는 상태에서 시작되고 프로브가 성공하기 시작한 이후에만 트래픽을 받는다는 것이다. 만약 컨테이너가 대량의 데이터, 설정 파일들, 또는 시동 중 마이그레이션을 처리해야 한다면, 준비성 프로브를 지정하기 바란다.
- 만약 당신의 컨테이너가 유지 관리를 위해서 자체 중단되게 하려면, 준비성 프로브를 지정하길 바란다. 준비성 프로브는 활성 프로브와는 다르게 준비성에 특정된 엔드포인트를 확인한다.
- 파드가 삭제될 때 단지 요청들이 흘려 보낼(drain) 목적으로, 준비성 프로브가 필요하지 않다는 점을 유념해야한다. 삭제 시에, 파드는 프로브의 존재 여부와 무관하게 자동으로 스스로를 준비되지 않은 상태(unready)로 변경한다. 파드는 파드 내의 모든 컨테이너들이 중지될 때 까지 준비되지 않은 상태로 남아있는다.
언제 스타트업 프로브(startup probe)를 사용
- 컨테이너가 보통 초기 지연 시간 + 실패 임계 값 대기 초(initialDelaySeconds + failureThreshold periodSeconds) 이후에 기동된다면, 스타트업 프로브가 활성화 프로브와 같은 엔드포인트를 체크하도록 명시해야 한다.
- periodSeconds의 기본 값은 30초 이다. 이 때 컨테이너가 활성화 프로브의 기본 값 변경 없이 기동되도록 하려면 failureThreshold를 충분히 높게 설정해주어야 한다. 그래야 데드락(deadlock)을 방지하는데 도움이 된다.
