Autoscaling+HPA - Kubernets Probes with Sprint Boot App

Configure Liveness, Readiness, and Startup Probes

Configure Liveness, Readiness and Startup Probes

• 각 노드에서 Agent 방식으로 동작하는 kubelet을 통해 컨테이너의 상태를 체크하고 컨테이너를 재시작할지(livenessProbe), 컨테이너에 트래픽을 보낼지(readinessProbe)를 결정
• kubelet에 의해 주기적으로 수행되며 컨테이너에 의해서 구현된 핸들러를 호출
  • ExecAction : 컨테이너 내에서 지정된 명령어를 실행(예. health.sh)
  • TCPSocketAction : 포트활성화 여부를 체크
  • HTTPGetAction : HTTP GET 요청 수행. 응답코드가 200 이상 400미만이면 성공으로 간주
• livenessProbe : 컨테이너가 동작중인지 여부를 확인. 실패 시 재시작(활성화하지 않을 경우 기본 상태는 Success, Use Liveness Probe to remove unhealthy pods)
• readinessProbe : 컨테이너가 요청을 처리할 준비가 되어있는지 여부를 확인. 실패 시 엔드포인트에서 해당 Pod의 iP를 제거(트래픽 보내지 않음, Use Readiness Probe to detect partial unavailability)
• startupProbe: v1.16 이후로 추가된 feature로 컨테이너 내의 애플리케이션이 시작되었는지를 체크. 한 번만 실행. 해당 feature가 있는 경우 성공할 때까지 다른 프로브는 비활성. 실패 시 컨테이너 Kill 후 재시작. 논리 및 구성 관점에서는 livenessProbe와 동일하지만 livenessProbe보다 컨테이너를 재시작하기 위한 오차를 좀 더 크게 주고 싶은 경우 사용(Use Startup Probe)
•  

• Parameters
  • initialDelaySeconds
  • periodSeconds
  • timeoutSeconds
  • successThreshold
  • failureThreshold
• Pod Lifecycle
  • PodStatus 오브젝트로 정의
  • 단계 : Pending - Running - Succeeded - Failed - Unkown
  •  

파드 라이프사이클

• Pod 시작

 

• Pod 종료
  
  

 

Production-ready Features in Spring

• 설정
  
  

# build.gradle  dependencies {     implementation 'org.springframework.boot:spring-boot-starter-actuator' }

• Endpoints : web, jmx 2개의 Endpoint 제공
• Kubernetes Probes
  • liveness와 readiness endpoint 그룹을 제공

•  
• db 커넥션 장애시
• actuator를 사용하여 db등 다른 컴퍼넌트들과의 상태도 probe를 통해 같이 체크할 수 있어 해당 pod로 트래픽을 보내지 않음
•  

# application.yaml management:   endpoint:     health:       group:         readiness:           include: "readinessState,db"

• spring boot에서 자동 구성해주는 healthindicators : Auto-configured HealthIndicators

Production-ready Features

 

Summary

• HTTP 엔드포인트를 제공하는 MSA의 경우 Readiness Probe를 필수로 구성
• Spring boot actuator를 사용할 경우 health 체크용 management 포트를 별도로 구성 권장
  • 메인 포트와 동일 포트를 사용시에는 health 또는 metric 수집 등 endpoint를 메인 포트에서 노출할 때 외부구간에는 노출되지 않도록 설정 필요(API G/W, Istio 등에서)
• livenessProbe는 컨테이너가 stuck 상태일 때(deadlock 등) 재시작을 위해 만들어놓은 설정으로 잘못 설정 시 잠재적으로 로드 관련 오류를 계속 유발 시킬 수 있음 --> 예측 못한 상황이 발생하여 livenessState가 실패할 시 컨테이너는 무한 재구동됨 
• 특정 Application의 상태(DB 연결 등)에 따라 Circuit Breaking을 구성하기 위해서는 단순 RestController 보다는 Spring Actuator등을 활용하여 컨트롤 할 수 있음 → readinessProbe 설정을 통해 해당 Pod로 트래픽을 흘러보내지 않게 설정할 수 있지만  DB 자체의 장애시 모든 Pod가 트래픽을 수신 받을 수 없어 EKS BP 가이드에서 권장하지는 않음
• Kafka의 경우 readinessProbe 상태로는 active consumer pod에 DB 커넥션 장애등이 발생할 경우에도 standby pod로 넘어가지 않음 → livenessProbe를 설정하여 해당 Pod를 재부팅 시켜 자연스럽게 standby pod로 active consumer가 바뀌도록 구성 할 수 있으나 readiness Probe와 마찬가지로 DB 자체의 장애시 모든 Pod가 계속 재시작되는 상황이 발생할 수 있어 EKS BP 가이드에서는 강력하게 비권장
• Kafka Connection 장애에 따라 Pod의 동작을 결정하기 위해서는 kafka health check를 위한 Customizing 필요 (참고 : #14088, #12225)

기타 참고 링크

• Liveness and Readiness Probes with Spring Boot
• EKS Best Practice: Probe Recommendations
• LIVENESS PROBES ARE DANGEROUS
• Spring Boot Actuator: Production-ready Features
• Spring Boot Actuator
• Spring Boot HealthIndicator
• Spring Boot Actuator Proerty(2.3.3)