티스토리 뷰

쿠버네티스가 제공해주는 기능 10가지

쿠버네티스 공식 사이트에 들어가면 쿠버네티스가 제공해주는 10가지 기능에 대해 설명되어 있다. 이중에서도 자가 치유(Self-healing)에 대한 부분을 이번 포스팅에서 다루도록 한다.

 

https://kubernetes.io/ko/

 

자가 치유(Self-healing)

오류가 발생한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교체하기 위해 다시 스케줄 하고, 사용자 정의 상태 체크에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에 해당 컨테이너를 알리지 않는다. 즉, 정상적인 컨테이너들만을 대상으로 애플리케이션을 운영해 주겠다는 의미이다.

 

Self-handling 기능중에 포함된 것이 'livenessProbe'이다. livenessProbe는 컨테이너를 진단해서 정상적인지 검증하고 정상적이지 않다면 restart한다. 쿠버네티스 이전에는 개발자가 직접 모니터링을 해서 애플리케이션 상태를 확인하거나 스크립트를 통해 확인했지만 이제는 쿠버네티스가 자동으로 알아서 컨테이너를 관리해주는 셈이다.

 

 

livenessProbe가 추가된 Pod와 그렇지 않은 Pod

기본적인 Pod 정의

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

 

 

livenessProbe Pod 정의 (Self-healing 기능 추가)

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /
        port:80

- livenessProbe는 pod에 대한 건강검진과 비슷한 의미이다. 위 예시에서는 nginx pod가 web기반의 컨테이너이기 때문에 'httpGet Porbe'를 기반으로 제대로 동작하고 있는지를 확인한다.

 

cf. 'httpGet' Porbe

- 주기적으로 80포트, / path에 접속하여 컨테이너가 정상적으로 동작하는지 확인한다.

- 이때 응답이 정상적으로 나오면 건강한 컨테이너로 간주하고 그렇지 않으면 컨테이너를 재시작한다.

 

 


livenessProbe 메커니즘

컨테이너의 특성에 따라 Porbe를 해줄 방식은 다를 것이다. 위 예시처럼 nginx 컨테이너라면 http 요청과 응답을 기반으로 Probe 할 수 있지만 이는 웹 기반 컨테이너에 한정된 Probe이다. 만약 sshd와 관련된 컨테이너라면 주기적으로 ssh에 접속하는 Probe를 설정해야 할 것이다.

 

1) httpGet probe

- 지정한 IP주소, Port, path에 HTTP GET 요청을 보내서 해당 컨테이너가 응답하는지를 확인한다. 응답 코드가 200이 아닌 값이 오면 컨테이너를 재시작한다.

 

예시)

livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3

 

2) tcpSocket probe

- 지정된 포트에 TCP 연결을 시도하고 Connection이 맺어지지 않으면 컨테이너를 재시작한다.

 

예시)

livenessProbe:
  tcpSocket:
    port: 22

 

- httpGetProb와 tcpSocket probe가 비슷해 보일 수 있으나 httpGetProb는 HTTP 응답 코드를 기반으로 probe 하며 tcpSocket probe는 TCP connection을 기반으로 probe 한다.

 

 

3) exec probe

- 명령을 전달하고 명령의 종료 코드가 0이 아니면 컨테이너를 재시작한다.

 

예시)

livenessProbe:
  exec:
    command:
      - ls
      - /dev/file

probe 기준이 될 커맨드를 전달하는 방식을 활용할 수 있다. 해당 커맨드는 컨테이너 안에서 실행된다는 점을 주의해야 한다. probe로 삼을 상황은 아래와 같은 경우가 있을 것이다.

 

- 특정 프로세스가 동작중인가?

- 특정 유저가 존재하는가?

- 특정 파일이 존재하는가?

 

exec probe는 커맨드를 주기적으로 실행시켜 컨테이너의 상태를 확인한다. 만약 조건에 해당하지 않는다면 컨테이너를 재시작한다. exec probe를 사용할 때 시스템에 큰 작업 로드를 줄 커맨드는 작성하지 말아야 한다. 대부분 probe는 짧은 주기로 반복되기 때문이다. 따라서 반드시 가벼운 작업만을 부여해야 한다.

 

 

 

* 주의: livenessProbe는 '컨테이너'를 재시작한다. Pod를 재시작하는 게 아니라는 점을 알아두자. 따라서 컨테이너가 재시작되는 것이기 때문에 컨테이너로 접속하는 IP 주소는 변하지 않는다.

 

 


livenessProbe 추가 정보

예시)

livenessProbe:
  httpGet:
    path: /
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 20
  timeoutSeconds: 1
  successThreshold: 1
  failureThreshold: 3

-  initialDelaySeconds: 15 -> 컨테이너 시작 후 15초 뒤부터 probe진행 시작
- periodSeconds: 20 -> 20초마다 probe 진행
- timeoutSeconds: 1 -> 요청을 보낸 후 1초 동안 응답이 오지 않으면 실패로 간주
- successThreshold: 1 -> 1번만 성공해도 성공으로 간주
- failureThreshold: 3 -> 3번 실패하면 그때서야 실패로 간주

 

위 추가 정보들은 넣어주지 않아도 default 값으로 설정된다.

 

적용된 livenessProbe 추가정보 확인

$ kubectl get pod <pod name> -o yaml

 

 

실습 예제

동작하는 Pod내의 컨테이너에 /tmp/healthy 파일이 존재하는지 5초마다 확인한다. 그리고 pod 실행 후 10초 후부터 검사하며 성공 횟수는 '연속' 1번, 실패 횟수는 '연속' 2회로 구성한다.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    args;
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
      timeoutSeconds: 1
      successThreshold: 1
      failureThreshold: 2

 

 

 

 

 

Reference

- 따배쿠, https://youtu.be/-NeJS7wQu_Q

- kubernetes docs, https://kubernetes.io/ko/

- configure liveness, readiness and startup probes for containers, https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/

 

 

 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/11   »
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
글 보관함