[쿠버네티스] 포드를 안정적으로 유지하기 위한 기술들

쿠버네티스에서 사용하는 3가지 프로브

• Liveness probe: 컨테이너가 정상적으로 실행 중인지 확인하여 비정상 시 재시작
• Readiness probe: Pod가 트래픽을 처리할 준비가 되었는지 확인하여 준비되지 않은 Pod는 서비스에서 제외
• Startup probe: 컨테이너 애플리케이션이 성공적으로 시작되었는지 확인.

Liveness Probe의 4가지 메커니즘

• HTTP GET Probe: 지정된 HTTP 엔드포인트에 GET 요청을 보내 응답 상태로 컨테이너의 건강 상태를 확인. 가장 범용적인 방법.
• TCP Socket Probe: 컨테이너의 특정 포트에 TCP 연결을 시도해 성공 여부로 상태를 점검.
• Exec Probe: 컨테이너 내에서 명령을 실행해 그 반환 값을 통해 상태를 판단.
• gRPC Probe: gRPC 서비스의 헬스 체크 엔드포인트를 호출해 상태를 확인하며, Kubernetes 1.27부터 안정화(stable)됨.

liveness probe 사용 예시

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http # liveness probe name
spec:
  containers:
  - name: liveness
    image: registry.k8s.io/e2e-test-images/agnhost:2.40
    args:
    - liveness
    livenessProbe: # livenessProbe 설정
      httpGet:
        path: /healthz # 헬스체크용으로 정의한 api 정보
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    duration := time.Now().Sub(started)
    if duration.Seconds() > 10 {
        w.WriteHeader(500)
        w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
    } else {
        w.WriteHeader(200)
        w.Write([]byte("ok"))
    }
})

kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml

# 동작 중인 라이브니스 프로브 조회
kubectl describe po ${liveness_probe_name}

 

리눅스에서 exit code는 일반적으로 0부터 255까지의 범위를 가집니다. 이 범위 내의 숫자는 종료 상태를 나타내며, 각 값은 특정한 의미를 지닙니다.

프로세스가 종료될 때 exit code는 두 가지 주요 방법으로 설정됩니다:

1. 정상 종료: 0 (성공)부터 125까지의 값을 사용합니다.
2. 신호로 종료: 128에 신호 번호를 더한 값을 사용합니다. 예를 들어, SIGKILL 신호는 번호 9이므로, 128 + 9 = 137이 됩니다.

이러한 방식으로 신호로 종료된 프로세스의 종료 코드를 나타낼 수 있습니다. 128은 신호 종료 코드를 구분하기 위해 예약된 기본 값입니다. 프로세스가 특정 신호로 종료되면, 이 값에 신호 번호를 더하여 exit code를 계산합니다.

따라서 exit code 137은 신호 9 (SIGKILL)로 인해 프로세스가 종료되었음을 나타내며, 이는 128 + 9 = 137으로 계산됩니다.

128을 사용하는 이유

• 0 ~ 125 : 정상 종료를 나타냄
• 126: 명령을 실행할 수 없음
• 127: 명령을 찾을 수 없음 ⇒ 128부터 정상종료가 아닌 신호로 인한 종료로 구분하기 위해 사용

 

 

---

Replication Controller

• 원하는 수의 포드 복제본을 항상 유지시켜줌
• 3요소
  • 라벨 셀렉터: 레플리케이션 컨트롤러 범위에 있는 포드를 결정
  • 복제본 수: 실행해야 하는 포드의 원하는 수를 지정
  • 포드 템플릿: 새로운 포드 복제본을 만들 때 사용
• 사용 시 이점
  • 포드가 없는 경우 새 포드를 시작해 포드(또는 여러 포드 복제본)가 항상 실행되도록 유지
  • 클러스터 노드에 장애 발생 시 장애가 발생한 노드에서 실행 중인 모든 포드의 대체 복제본을 생성
  • 수동 or 자동으로 포드를 쉽게 수평 스케일링 가능
• 라벨 셀렉터와 일치하는 포드를 관리
• 포드 템플릿을 통해 새 포드 생성. 포드템플릿 변경 시 기존 포드엔 영향 X. 신규 포드부터 적용

Replica Set

• 레플리카셋은 레플리케이션 컨트롤러를 계승하였음.
• 둘은 동일한 용도로 유사하게 동작함.
• 레플리카셋에서 더 풍부한 표현식 포드 셀렉터를 갖는다는 점을 제외하면 매우 유사함
• Replication Controller보다는 ReplicaSet 사용을 권장함
• 일반적으로 레플리카셋을 직접 생성하지 않고 상위 수준의 Deployment 리소스를 만들 때 자동으로 생성

ReplicaSet 사용 예시

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  # 케이스에 따라 레플리카를 수정한다.
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

# 레플리카셋 생성
kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml

# 배포된 레플리카셋 확인
kubectl get rs

# 레플리카셋 상태 확인
kubectl describe rs/frontend

# pod 올라갔는지 확인
kubectl get pods

NAME             READY   STATUS    RESTARTS   AGE
frontend-b2zdv   1/1     Running   0          6m36s
frontend-vcmts   1/1     Running   0          6m36s
frontend-wtsmm   1/1     Running   0          6m36s

# pod에 해당하는 레플리카셋 확인
kubectl get pods frontend-b2zdv -o yaml

---

Daemon Set

• 레플리케이션 컨트롤러, 레플리카셋은 쿠버네티스 클러스터의 임의의 위치에서 포드가 실행되는 것에 반해, 데몬셋은 클러스터의 각 노드에서 포드를 실행
• 레플리카 수의 개념이 없음
• 새 노드가 클러스터에 추가되면 데몬셋은 즉시 새 포드 인스턴스를 배포

데몬셋의 대표적인 용도

• 모든 노드에서 클러스터 스토리지 데몬 실행
• 모든 노드에서 로그 수집 데몬 실행
• 모든 노드에서 노드 모니터링 데몬 실행

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd-elasticsearch
  namespace: kube-system
  labels:
    k8s-app: fluentd-logging
spec:
  selector:
    matchLabels:
      name: fluentd-elasticsearch
  template:
    metadata:
      labels:
        name: fluentd-elasticsearch
    spec:
      tolerations:
      # 이 톨러레이션(toleration)은 데몬셋이 컨트롤 플레인 노드에서 실행될 수 있도록 만든다.
      # 컨트롤 플레인 노드가 이 파드를 실행해서는 안 되는 경우, 이 톨러레이션을 제거한다.
      - key: node-role.kubernetes.io/control-plane
        operator: Exists
        effect: NoSchedule
      - key: node-role.kubernetes.io/master
        operator: Exists
        effect: NoSchedule
      containers:
      - name: fluentd-elasticsearch
        image: quay.io/fluentd_elasticsearch/fluentd:v2.5.2
        resources:
          limits:
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 200Mi
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      terminationGracePeriodSeconds: 30
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml

[daemon 용어의 유래]
이 용어는 MIT의 Project MAC에서 프로그래머들에 의해 만들어졌습니다. 1963년에 Project MAC에서 작업했던 페르난도 J. 코르바토(Fernando J. Corbató)에 따르면, 그의 팀은 Maxwell의 악마(Maxwell's demon)에서 영감을 받아 "daemon"이라는 용어를 처음 사용하였다고 합니다. Maxwell의 악마는 물리학과 열역학에서 분자를 정렬하는 상상의 존재로, 코르바토는 "우리는 시스템 작업을 끊임없이 수행하는 백그라운드 프로세스를 설명하기 위해 'daemon'이라는 단어를 상상력 있게 사용하기 시작했습니다"라고 설명했습니다. Unix 시스템은 이 용어를 계승하였습니다. Maxwell의 악마는 그리스 신화에서의 daemon이 배경에서 활동하는 초자연적 존재로 해석되는 것과 일치합니다.
https://en.wikipedia.org/wiki/Daemon_(computing)

---

Job

• 완료 가능한 단일 태스크를 수행하는 포드 실행
• ex) 잡 오브젝트를 하나 생성해서 포드 하나를 안정적으로 실행하고 완료. 첫번째 포드가 실패 또는 삭제된 경우 잡 오브젝트는 새로운 포드를 재기동
• 잡을 사용하면 여러 포드를 병렬로 실행 가능
• 스케쥴에 따라 구동하고 싶은 경우 CronJob 사용

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    spec:
      containers:
      - name: pi
        image: perl:5.34.0
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
  backoffLimit: 4

kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml

 

 

---

참고

• https://product.kyobobook.co.kr/detail/S000001804912
• https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
• https://kubernetes.io/ko/docs/concepts/workloads/controllers/replicaset/
• https://kubernetes.io/ko/docs/concepts/workloads/controllers/daemonset/