Cloud/Kubernetes
Pod probe
yellowmarine
2020. 6. 17. 15:42
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 로딩 혹은 많은 데이터를 로딩해야 하는 경우 일시적으로 서비스가 불가능한 상태가 되기때문에 재부팅 하더라도 서비스가 불가능해질 수 있다. 그러므로 일시적으로 서비스 불가능 상태라고 마킹해준다.