Pod probe

Pod Probe

Liveness Probe

• 기본적으로 Pod의 생존 여부를 확인하기 위한 방법이다
• 우리가 알기로 pod이 죽었을 경우 kubelet이 알아서 재시작으로 시켜주고 다시 pod이 할당된다. 하지만 죽어있느 pod에 때문에 deadlock이 발생한다면 어찌 해야될지 모른다! 그러므로 liveness probe를 사용하여 주기적으로 체크!
• 방법으로는 HTTP request, TCP socket, exec command가 있다

HTTP Request

• 지정된 IP, Port, Path에 HTTP Get을 요청한다.
• probe에 대한 에러, 미응답의 경우 실패로 간주

ex)

apiversion: v1
kind: Pod
metadata: 
    labels:
        test: liveness
        name: liveness-http
spec:
    container:
        - name: liveness
        image: k8s.gcr.io/liveness
    args:
        - /server
        livenessProbe:
            httpGet:
                path: /healthz
                port: 8080
                httpHeaders:
                    -name: Custom-Header
                    value: Awesome
            initailDelaySecond: 3
            periodSeconds: 3

위의 예시를 보면 내부 port 8080으로 접속해 healthz에 접속한다. 이 후 3초마다 pod의 생존여부를 확인하다.

TCP socket

• 지정된 port에 대해서 connection을 맺기위해 요청을 보낸다.
• 만약 연결이 생성이 된다면 생존, 이외의 경우 실패로 간주
• one way handshacking 정도로 생각하면 맞을듯??
• 위의 http의 경우 7 layer까지 가지만 이것의 경우 4 layer에서 끝나니까 뭔가 더 효율적일지 않을까??

....
livenessProbe:
    tcpSocket:
        port:8080
    initalDelaySecond: 15
    periodSecond: 20

Http 와 다르게 port로 접속만 되면 끝!

Exec Command

• 특정한 명령의 수행 뒤, 그 결과를 가지고 생존여부를 판단.
• 만약 생존했다면 0, 아니라면 1

livenessProbe:
    exec:
        command:
        - cat
        - /tmp/healthy

위의 예시를 보면 cat/tmp/healthy 명령을 수행할 수 있다면 0, 아니라면 1이라는 신호를 받게 되고 이를 통해 pod의 생존여부 판다

Readiness Probe

• Liveness probe와 비교하였을때 구동 방식은 똑같다.
• 하지만 사용되어지는 부분에서는 조금 차이가 존재
• liveness probe의 경우에는 pod의 생존여부를 가늠하기 위한 방법이지만 Readness 의 경우 configuration 로딩 혹은 많은 데이터를 로딩해야 하는 경우 일시적으로 서비스가 불가능한 상태가 되기때문에 재부팅 하더라도 서비스가 불가능해질 수 있다. 그러므로 일시적으로 서비스 불가능 상태라고 마킹해준다.