k8s graceful deploy

K8S 환경에서 pod을 안전하게 배포하는 방법

2022-05-27
Table of Contents

개요

k8s 환경에서 pod를 배포할 때 순간적으로 5XX 에러가 발생하는 경우가 있다. 별다른 문제가 아니라고 생각할 수도 있지만, 배포가 진행될 때마다 사용자 중 일부가 오류를 경험할 수 있기 때문에, k8s 옵션을 적절하게 설정하여 5XX에러를 줄이는 것이 좋다. deployment yml 설정에서 이런 옵션들을 살펴보고 안전하게 pod를 종료/시작하는 방법을 살펴보았다.

Step1. 기본적인 Deployment

k8s 환경에서 배포를 위한 방법은 여러가지가 있지만 기본적인 Deployment Yml 은 다음과 같은 형태라고 가정해보자.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 4
  selector:
    matchLabels:
      stage: production
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
  template:
    metadata:
      labels:
        stage: production
        app: my-app
    spec:
      containers:
        - name: my-app
          image: my-org/my-app:latest
          imagePullPolicy: Always
          ports:
            - containerPort: 8080

기본적인 Deployment 설정을 하고 나면 배포할 때 마다 순간적으로 5XX 오류를 확인할 수 있다. 이유는 POD는 시작하자마자 트래픽을 처리할 수 없기 때문이다. POD가 정상적으로 트래픽을 받을 수 있는지 없는지 확인하기 위해서 Probe 설정을 추가해보자.

deployment phase
K8S deployment

Step2. Probe 설정

기본적인 Deployment 설정을 했다면 Probe 설정을 추가해야한다.

  • livenessProbe : 컨테이너가 정상적으로 동작중인지 확인하는데 사용한다. 주로 HTTP 요청을 보내서 응답 결과가 정상적으로 200OK 가 반환되는지 확인해서 동작 유무를 판단한다. 응답이 200OK가 아니라면 k8s 클러스터는 pod를 죽이고 재시작하게 된다. 설정하지 않으면 기본값이 Success 로 간주된다.
  • readinessProbe : 컨테이너가 시작할 때 요청을 받을 준비가 되었는지 확인하는데 사용한다. 응답이 200 OK 가 아니라면 k8s 클러스터는 이 pod에 트래픽을 전달하지 않는다. 설정하지 않으면 기본값이 Success 로 간주한다.
          readinessProbe:
            httpGet:
              path: /actuator/health/liveness  #굳이 actuator 경로를 쓸 필요는 없다.
              port: 8080
            timeoutSeconds: 3 # 타임아웃 시간 설정
            periodSeconds: 30 # 확인 주기
            successThreshold: 1 #성공 기준 횟수
            failureThreshold: 5 #실패 기준 횟수
          livenessProbe:
            httpGet:
              path: /actuator/health/readiness #굳이 actuator 경로를 쓸 필요는 없다.
              port: 8080
            timeoutSeconds: 3
            periodSeconds: 30
            successThreshold: 1
            failureThreshold: 5

Probe 라는 건 중학교 건전지 회로 실험에서 사용해보았던, 전류가 흐르는지 확인하는 도구라고 생각하면 이해가 쉽다. 탐침, 조사하다는 의미로 해석할 수 있다.

what is probe
오늘쪽 바늘 모양 도구가 probe

pod 가 실행되어 rediness 가 success 가 되더라도 바로 트래픽을 전달받으면 안되는 상황이 있을 수 있다. Spring 과 같은 경우에는 애플리케이션 내부에서 일종의 Warm up (애플리케이션이 구동하기 위한 준비 작업들)이 더 필요할 수도 있기 때문이다. 특히 단순히 redinessProbe를 path: /_probe/readiness 와 같이 설정한뒤에 200 OK를 반환하는 형태로 설정해둔 경우라면 트래픽의 일부가 여전히 오류를 반환할 수 있다. 이런 경우에는 initialDelaySeconds 를 설정할 수 있다.

    @GetMapping(value = "/_probe/readiness")
	public ResponseEntity<String> healthCheck() {
		return ResponseEntity.ok().body("ok");
	}

Step 3 initialDelaySeconds 설정

          readinessProbe:
            httpGet:
              path: /actuator/health/readiness #굳이 actuator 경로를 쓸 필요는 없다.
              port: 8080
            initialDelaySeconds: 10
            timeoutSeconds: 3
            periodSeconds: 30
            successThreshold: 1
            failureThreshold: 5
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness  #굳이 actuator 경로를 쓸 필요는 없다.
              port: 8080
            initialDelaySeconds: 10
            timeoutSeconds: 3 # 타임아웃 시간 설정
            periodSeconds: 30 # 확인 주기
            successThreshold: 1 #성공 기준 횟수
            failureThreshold: 5 #실패 기준 횟수

initialDelaySeconds 를 설정하면 pod 가 생성되고 난 뒤에 딜레이를 줘서 pod 가 트래픽을 처리할 준비가 된 후에 응답을 반환할 수 있게한다.

하지만 여기서 끝내면 안되고 한가지 작업이 더 남았다. 바로 종료시점에 대한 고려가 필요하다. pod 가 준비되고 트래픽을 처리하기 까지는 위의 설정으로도 충분하지만, pod 가 종료될 때 즉각적으로 pod를 제거해버리면, 처리하고 있던 응답을 완료하기 전에 프로세스가 종료되어 사용자가 5XX 에러를 볼 수 있다. 이를 막기 위해서 preStop 설정을 추가해보자.

Step 4 preStop 설정 추가

          ports:
            - containerPort: 8080
          lifecycle:
            preStop:
              exec:
                command: [ "sh", "-c", "sleep 10" ]
          readinessProbe:
          ... 생략 ...

preStop 설정을 추가하면 Pod 가 종료를 처리할 때 즉각적으로 종료하지 않고 preStop 에 설정된 명령을 수행한 뒤에 pod 종료를 수행한다. 따라서 위와 같이 약 10초의 딜레이를 주어서 현재 처리중이던 응답을 반환할 충분한 시간을 주면 사용자에게는 5XX에러 상황이 발생하지 않을 수 있다.

전체 시퀀스 도식화

말로만 하면 이해가 잘 안될것 같아, 그림으로 도식화 해보았다.

graceful shutdown
전체 pod 전환 순서

최종 yml 파일

최종적으로 production 에서 사용하는 deployment yml 파일음 다음과 같은 형태를 가지고 있다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  replicas: 4
  selector:
    matchLabels:
      stage: production
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 50%
  template:
    metadata:
      labels:
        stage: production
        app: my-app
    spec:
      containers:
        - name: my-app
          image: my-org/my-app:latest
          imagePullPolicy: Always
          resources:
            requests:
              memory: 2Gi
            limits:
              memory: 2Gi
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: "production"
          ports:
            - containerPort: 8080
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 8080
            initialDelaySeconds: 10
            timeoutSeconds: 3
            periodSeconds: 30
            successThreshold: 1
            failureThreshold: 5
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 8080
            initialDelaySeconds: 10
            timeoutSeconds: 3
            periodSeconds: 30
            successThreshold: 1
            failureThreshold: 5
          lifecycle:
            preStop:
              exec:
                command: [ "sh", "-c", "sleep 10" ]
      terminationGracePeriodSeconds: 120

결론

K8s에서 pod를 배포하는 과정에서는 pod 가 시작할 때 준비과정(rediness), warmup (initialDelay)에 대한 고민이 필요하고 pod 가 종요할 때 처리하던 응답을 정상적으로 반환할 때까지 기다리기 위한 preStop 과 같은 설정이 필요하다. 이를 잘 이해하고 사용한다면 배포과정에서 사용자가 5XX 에러를 확인하는 일은 없을꺼라고 생각한다.

참고자료

보다 정확한 내용을 이해하려면 pod 의 라이프사이클에 대한 이해가 필요하다. 다음의 참고자료에서 관련 내용을 확인할 수 있다.

comments powered by Disqus
FEATURED TAGS
accesscontrol adaptive growth alpine linux ansible ansible tower apache2.4 architecture argocd asgi aws awx backoffice beautiful goodbye begining docker benchmark blockhound blocking code blog book brew cask build cache collaboration communication composer confluence cronjob curl customizing customlog data.sql database developer difference docker docker desktop dockerize dos attack eks elasticsearch empty string environment to do well errorlogformat event driven experience file upload filebeat fluentd forwarded option framework fuse.js golang graceful deploy happy new year haproxy haproxy 1.8 haproxy acl logging haproxy custom variable logging haproxy metric haproxy reload fail haproxy stat heap memory hedgehog sharp how do i work hugo index alias install installation instance type inverted index istio iterm java jdk 21 jekyll jekyll to hugo jetbrains json k8s k8s api kmooc kubernetes leadership learning in 2019 let's encrypt letsencrypt limit_req_zone litestar logstash m1 macbook pro macro macro key mapping mapping match match_phrase maven microservice 설계 및 구현 migration mm multi datasource mysql nginx nginx ingress nginx regexp ngram node drain null openjdk partial matching phpstorm poddisruptionbudget poeaa portfolio expansion product strategy python query dsl rate limit rate litmiting rds reindex rss template seamless reload search on hugo service account & role sidebar search speed up speedup spring spring boot spring camp spring camp 2023 spring event ssh struct study system manager systemd reload template term throughput timezone tips traffic management ulid unused plugins uuid ux consideration virtual thread vm options webflux wildcard zero downtime 만들면서 배우는 클린 아키텍처 시작하세요 도커 엔터프라이즈 애플리케이션 아키텍처 패턴 쿠버네티스 시작하기