[Kubernetes] Pod 파해치기 2 - livenessProbe, readlinessProbe, initContainers

"[K8s] Pod 파해치기 1"에 이어서 Pod에 대한 내용을 학습합니다.

상태 확인

Pod가 정상적으로 동작하고 있는지 확인하는 상태 확인 기능을 알아봅시다.

livenessProbe

쿠버네티스는 컨테이너가 정상 작동하는지 livenessProbe property를 이용해 확인하며 자가치유를 위한 판단 기준으로 활용합니다.

위처럼 specs에 livenessProbe를 통해 설정 해줄 수 있습니다.

위 YAML 파일은 GET 메서드로 /live위치의 80번 포트를 지속 호출합니다.

이때  HTTP 리턴 코드가 200~300번 대인 응답코드는 정상 이외는 비정상으로 판단하고 컨테이너가 종료 및 재시작 됩니다.

 

위 YAML로 Pod를 생성하고 로그를 확인해보면 아래와 같이 나오게 됩니다.

 

Pod가 실행되고 /live호출에 404를 반환해주는 로그가 있습니다.

이를 통해 Pod가 정상적이지 않다고 판단 후 Pod를 강제 재시작 하고 있는걸 볼 수 있지요.

(기본적인 nginx는 /live API가 없으니까~)

 

live 파일을 생성 후 다시 로그를 직어보면 정상 응답이 됩니다.

 

정상적으로 200 응답으로 더이상 Pod는 재시작 하지 않게 된거죠. 굿

 

readlinessProbe

livenessProbe는 Pod가 살았는지 확인하는 용도라면,

readinessProbe은 Pod가 생성 직후, 트래픽을 받을 준비가 완료되었는지 확인하는 property입니다.

Jenkins서버와 같이 처음 구동하는데 시간이 오래 걸리는 웹 서비스라면 구동이 완료된 이후에 트래픽을 받아야 합니다.

이런 경우 readinessProbe을 통해 해당 Pod의 초기화가 완료되었다는 것을 알리는 용도로 씁니다.

 

livenessProbe와 동일한 방법으로 설정이 가능합니다.

 

처음 생성 후 로그를 찍어보면 

 

계속 /read 경로의 80포트로  GET 요청을 보내 확인을 계속 하고 있습니다.

livenssProbe과는 다르게 재시작하지 않고있죠, 켜질 때까지 기다리는 겁니다.

readinessProbe의 상태를 다음의 READY 0/1 표시를 통해 확인 할 수 있습니다.

 

그럼 위 /read 경로가 200 반환을 해주게 조치한다면 READY가 1/1로 바뀌겠죠?

해봅시다.

바로 READY 상태로 된 것을 볼 수 있습니다.

 

위 두 livenessProbe와 readinessProbe은 HTTP 통신 뿐만 아니라 명령 실행을 통해서도 정상 여부를 확인할 수 있습니다.

 

# readiness-cmd.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-cmd
spec:
  containers: 
  - name: nginx
    image: nginx
    readinessProbe:
      exec:
        command:
        - cat
        - /tmp/ready

 

위 YAML파일은 readinessProbe의 확인 방법으로 cat /tmp/ready 명령어를 사용하게 되는거죠

 

이는 명령의 리턴값이 0이면 정상, 아니면 비정상으로 인식합니다.

위 YAML기준으론 /tmp/ready 파일이 존재하면 0반환되어 READY상태로 되지만,

없으면 Pod의 준비가 덜 되었다고 판단합니다.

 

컨테이너 2개 실행

지금까진 하나의 Pod에 하나의 컨테이너만 사용했지만 Pod는 여러개의 컨테이너를 실행 할 수 있습니다.

한 번 봅시다.

 

기본적인 nginx 컨테이너와

쉘 스크립트로 루프를 돌며 5초간 대기 후 localhost를 호출하는 curl 컨테이너가 두 개 정의 되어있습니다.

위 YAML 기준으로 Pod를 만들고 log를 봐봅시다.

kubectl logs second

단순 위 명령으로 로그를 보려하면 애러가 납니다.

second라는 Pod 안에는 2개의 컨테이너가 존재하기 때문에 어떤 컨테이너의 로그를 볼지 명시해줘야 합니다.

-c 옵션으로 지정 가능하지요

# nginx 컨테이너 지정
kubectl logs second -c nginx

여기서 그럼 curl 컨테이너에서 5초 대기를 왜 했을까?

쿠버네티스는 Pod 내부 컨테이너끼리의 실행 순서를 보장하지 않습니다.

그래서 nginx 컨테이너 업 이후 curl을 하도록 노린거지요.

 

사이드카 패턴
1개의 Pod에 여러 컨테이너를 실행하는 이유는 뭘까?
대표적으로 사이드카 패턴이 있습니다. 메인 컨테이너가 본연의 임무를 수행하고 사이드카 컨테이너가 보조 역할을 담당할 때 사용하지요. 예로 웹서빙과 웹 서버의 로그를 중앙 로그 시스템으로 전송 할 때 이 패턴을 이용하면 됩니다.
Springboot, Promtail 로 예를 들 수 있을 것 같습니다.

 

초기화 컨테이너

앞에서 잠깐 말했듯 컨테이너끼리는 실행 순서가 보장되지 않습니다.

그럼 순서가 필요한 경우엔 어떡하죠?

아래 YAML처럼 initContainers property를 이용해 먼저 초기화 작업이 가능합니다.

 

이렇게 메인 컨테이너 실행에 앞서 초기화를 위해 먼저 실행되는 컨테이너를 정의합니다.

 

이러면 메인 컨테이너가 실행되기 전에 먼저 git 컨테이너를 실행하여 git clone이 먼저 진행 후 

메인 컨테이너가 실행됩니다.

여기서 전에 다뤘던 emptyDir을 통해 git 컨테이너의 볼륨을 busybox 컨테이너와 공유하게 됩니다.