쿠버네티를 롤링 업데이트를 사용해도 중단 시간이 발생하는 것을 해결하기 위해 알아본 내용입니다.
AS-IS
쿠버네티스 상태가 업데이트 되는 동안, 502(Bad Gateway) 에러가 발생
kind: Deployment
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 34%
maxUnavailable: 34%
template:
spec:
terminationGracePeriodSeconds: 60
containers:
- image:
ports:
- containerPort: 8000
위의 Deployment 설정을 통해 AWS에서 3개의 pod로 운영중인환경이다. rollingUpdate의 maxSurge/maxUnavailable가 설정되어 있으며, terminationGracePeriodSeconds도 설정되어 있다.
TO-BE
쿠버네티스의 헬스체크를 위해 여러가지 설정이 있지만, 무중단 배포에서 필요한 설정은 readinessProbe이다. readinessProbe 설정은 실제로 컨테이너가 서비스 요청을 처리할 준비가 되어있는지 확인하는데 사용한다. readinessProbe가 ok 상태가 되면 실제로 트래픽을 받을 수 있다. 자바 프로세스는 초기화 과정이 오래 걸리기 때문에 readinessProbe 잘 설정해줘야 한다.
kind: Deployment
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 34%
maxUnavailable: 34%
template:
spec:
terminationGracePeriodSeconds: 60
containers:
- image:
ports:
- containerPort: 8000
readinessProbe: -- 추가 설정
tcpSocket:
port: 8000
initialDelaySeconds: 30
periodSeconds: 5
timeoutSeconds: 3
successThreshold: 1
failureThreshold: 3
readinessProbe: 종종 어플리케이션은 일시적으로 트래픽을 받을 수 없다. 이런 경우 어플리케이션을 종료하고 싶지도 요청을 보내고 싶지도 않다. 쿠버네티스는 이런 상황을 발견하고 완화하기 위해 readinessProbe 제공한다. 준비가 되지 않은 pod는 쿠버네티스 서비스를 통해 트래픽을 받지 못하도록 한다. 헬쓰체크를 위한 별도의 path가 없기 때문에 TCP 소켓 포트를 이용해 설정했다.
- initialDelaySeconds: 컨테이너가 시작하고 어플리케이션이 시작하기 전에 시간(초)
- periodSeconds
- timeoutSeconds
- successThreshold: 조사가 성공한 최소 연속 횟수
- failureThreshold: 조사가 연속적으로 실패 한 후, 쿠버네티스가 전체적으로 실패했다고 생각하는 횟수
추가로 테스트를 진행하면서 pod 상태를 확인하기 위해 사용한 명령어이다.
kubectl describe pod <pod-name> -n <namespace-name>
readinessProbe 관련 심화 내용