✔️ Readiness Probe (준비성 프로브)
- 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타낸다.
- 만약 준비성 프로브(
readiness probe
)가 실패한다면, 엔드포인트 컨트롤러는 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. - 준비성 프로브의 초기 지연 이전의 기본 상태는
Failure
이다. - 만약 컨테이너가 준비성 프로브를 지원하지 않는다면, 기본 상태는
Success
이다.
vagrant@node1 ~/svc/readiness kubectl explain rs.spec.template.spec.containers
readinessProbe <Object>
Periodic probe of container service readiness. Container will be removed
from service endpoints if the probe fails. Cannot be updated. More info:
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle#container-probes
✔️ Readiness Probe Test
myweb-svc-lb.yaml
apiVersion: v1
kind: Service
metadata:
name: myweb-svc-lb
spec:
type: LoadBalancer
selector:
app: web
ports:
- port: 80
targetPort: 8080
myweb-rs.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: myweb-rs
spec:
replicas: 3
selector:
matchLabels:
app: web
env: dev
template:
metadata:
labels:
app: web
env: dev
spec:
containers:
- name: myweb
image: ghcr.io/c1t1d0s7/go-myweb
ports:
- containerPort: 8080
protocol: TCP
readinessProbe:
exec:
command:
- ls
- /tmp/ready # 해당 파일은 존재하지 않음
readinessProbe
는 반드시 실패할 것이다.
vagrant@node1 ~/svc/readiness kubectl get rs,po,svc,ep
NAME DESIRED CURRENT READY AGE
replicaset.apps/myweb-rs 3 3 0 4s
NAME READY STATUS RESTARTS AGE
pod/myweb-rs-7dkjl 0/1 ContainerCreating 0 4s
pod/myweb-rs-gbslj 0/1 ContainerCreating 0 4s
pod/myweb-rs-xqrt7 0/1 ContainerCreating 0 4s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.233.0.1 <none> 443/TCP 136m
service/myweb-svc-lb LoadBalancer 10.233.5.132 192.168.100.240 80:30408/TCP 4s
NAME ENDPOINTS AGE
endpoints/kubernetes 192.168.100.100:6443 136m
endpoints/myweb-svc-lb <none> 4s
파드의 READY
가 안되고 ENDPOINTS
가 없는 상태이다.
vagrant@node1 ~/svc/readiness curl 192.168.100.100
<html>
<head><title>404 Not Found</title></head>
<body>
<center><h1>404 Not Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
404 Not Found가 뜬다. 엔드포인트가 없기 때문에 갈 수 있는 경로가 없다.
vagrant@node1 ~/svc/readiness kubectl get po
NAME READY STATUS RESTARTS AGE
myweb-rs-7dkjl 0/1 Running 0 16s
myweb-rs-gbslj 0/1 Running 0 16s
myweb-rs-xqrt7 0/1 Running 0 16s
vagrant@node1 ~/svc/readiness kubectl exec myweb-rs-7dkjl touch /tmp/ready
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
vagrant@node1 ~/svc/readiness kubectl get po,ep
NAME READY STATUS RESTARTS AGE
pod/myweb-rs-7dkjl 1/1 Running 0 63s
pod/myweb-rs-gbslj 0/1 Running 0 63s
pod/myweb-rs-xqrt7 0/1 Running 0 63s
NAME ENDPOINTS AGE
endpoints/kubernetes 192.168.100.100:6443 137m
endpoints/myweb-svc-lb 10.233.90.64:8080 63s
pod/myweb-rs-7dkjl
가 READY
상태가 됐고 ENDPOINTS
10.233.90.64:8080가 등록되었다.
vagrant@node1 ~/svc/readiness kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myweb-rs-7dkjl 1/1 Running 0 2m30s 10.233.90.64 node1 <none> <none>
myweb-rs-gbslj 0/1 Running 0 2m30s 10.233.96.75 node2 <none> <none>
myweb-rs-xqrt7 0/1 Running 0 2m30s 10.233.92.104 node3 <none> <none>
ENDPOINTS
값이 myweb-rs-7dkjl
의 ip와 일치한다.
vagrant@node1 ~/svc/readiness curl 192.168.100.240
Hello World!
myweb-rs-7dkjl
vagrant@node1 ~/svc/readiness curl 192.168.100.240
Hello World!
myweb-rs-7dkjl
vagrant@node1 ~/svc/readiness curl 192.168.100.240
Hello World!
myweb-rs-7dkjl
myweb-rs-7dkjl
에만 트래픽이 전달된다.
vagrant@node1 ~/svc/readiness kubectl exec myweb-rs-7dkjl rm /tmp/ready
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
vagrant@node1 ~/svc/readiness kubectl get po,ep
NAME READY STATUS RESTARTS AGE
pod/myweb-rs-7dkjl 0/1 Running 0 4m55s
pod/myweb-rs-gbslj 0/1 Running 0 4m55s
pod/myweb-rs-xqrt7 0/1 Running 0 4m55s
NAME ENDPOINTS AGE
endpoints/kubernetes 192.168.100.100:6443 141m
endpoints/myweb-svc-lb 4m55s
READY
상태가 해제되며 ENDPOINTS
가 사라진다.
vagrant@node1 ~/svc/readiness kubectl exec myweb-rs-7dkjl touch /tmp/ready
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
vagrant@node1 ~/svc/readiness kubectl exec myweb-rs-gbslj touch /tmp/ready
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
vagrant@node1 ~/svc/readiness kubectl get po,ep
NAME READY STATUS RESTARTS AGE
pod/myweb-rs-7dkjl 1/1 Running 0 6m16s
pod/myweb-rs-gbslj 1/1 Running 0 6m16s
pod/myweb-rs-xqrt7 0/1 Running 0 6m16s
NAME ENDPOINTS AGE
endpoints/kubernetes 192.168.100.100:6443 142m
endpoints/myweb-svc-lb 10.233.90.64:8080,10.233.96.75:8080 6m16s
exec
명령으로 두 파드의 컨테이너를 실행해 /tmp/ready
파일을 생성한다.
앞서 yaml 파일에서 readinessProbe
는 이제 실패하지 않을 것이다.
pod/myweb-rs-7dkjl
, pod/myweb-rs-gbslj
두개 모두 READY
가 되며
vagrant@node1 ~/svc/readiness curl 192.168.100.240
Hello World!
myweb-rs-gbslj
vagrant@node1 ~/svc/readiness curl 192.168.100.240
Hello World!
myweb-rs-7dkjl
vagrant@node1 ~/svc/readiness curl 192.168.100.240
Hello World!
myweb-rs-gbslj
vagrant@node1 ~/svc/readiness curl 192.168.100.240
Hello World!
myweb-rs-7dkjl
두 파드로 접근이 가능하다.
SVC가 존재하고 엔드포인트와 파드가 연결이 되는 일반적인 형태에서 만약 readinessProbe
설정을 하지 않는다면SVC 입장에서는 파드의 유무에 상관없이 무조건 상태가 Success
이다.
따라서 SVC의 엔드포인트로 무조건 파드를 등록시킨다.
만약 3개의 파드중에 파드 1, 2는 정상 작동하지만 파드 3은 비정상이라고 해보자
요청이 들어왔을 때 누군가의 요청은 파드 1, 2로 들어가 정상 응답이 돌아오고 누군가의 요청은 파드 3으로 들어가 응답이 돌아오지 않을 것이다.
readinessProbe
는 App의 정상 상태를 확인해서 엔드포인트에 등록해주는 개념이다.
즉, 건강 상태를 체크해서 어플리케이션이 정상 작동한다고 판단하면 엔드포인트에 등록시키고 비정상이라고 판단하면 엔드포인트에 등록하지 않아서 트래픽을 라우팅하지 않도록 한다.
readiness
이므로 준비가 되었는지 App이 Serving
할 준비가 되었는지를 파악하고 Serving
할 준비가 된 파드만 엔드포인트에 등록 시켜준다.
보통 Web App의 경우 httpGet
체크 메커니즘 방식을 이용해서 작업한다.
따라서 RS이나 파드를 구성할 때 프로브 설정을 꼭 해줘야 한다. 하지 않을 이유가 없다.
📌 컨테이너 테스트시 Tip
vagrant@node1 ~/svc/readiness kubectl get po -A
kube-system kube-scheduler-node1 1/1 Running 15 (15h ago) 7d8h
vagrant@node1 ~/svc/readiness kubectl exec -n kube-system kube-scheduler-node1 -- bash
error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "9e708fda2cd8b5c8c80ef6f8d01830cce9510f9379c286be95a5bd00759d3e6b": OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "bash": executable file not found in $PATH: unknown
vagrant@node1 ~/svc/readiness kubectl exec -n kube-system kube-scheduler-node1 -- sh
error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "64b77c261816c4ffa846f514a934974852e38f6d3643348c98a2a6ea49955aa2": OCI runtime exec failed: exec failed: container_linux.go:380: starting container process caused: exec: "sh": executable file not found in $PATH: unknown
bash
를 실행하려고 하면 없고 shell
도 없다. binary
밖에 없다.
vagrant@node1 ~/svc/readiness kubectl get po
NAME READY STATUS RESTARTS AGE
myweb-rs-7dkjl 1/1 Running 0 20m
myweb-rs-gbslj 1/1 Running 0 20m
myweb-rs-xqrt7 0/1 Running 0 20m
vagrant@node1 ~/svc/readiness kubectl exec myweb-rs-7dkjl -- sh
하지만 우리가 배포한 myweb-rs-7dkjl
에 shell
을 실행하면 shell
이 존재한다.
vagrant@node1 ~/svc/readiness kubectl exec -it myweb-rs-7dkjl -- sh
/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.13.2
PRETTY_NAME="Alpine Linux v3.13"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
/ #
알파인 리눅스다.
/ # ls
bin dev etc home lib media mnt myweb opt proc root run sbin srv sys tmp usr var
/ # ./myweb
2022/05/23 15:48:03 Start MyWeb Application
2022/05/23 15:48:03 Listen: 0.0.0.0:8080
2022/05/23 15:48:03 listen tcp 0.0.0.0:8080: bind: address already in use
/ #
웹 어플리케이션이다.
:alpine
태그를 떼어내고 동일 명령을 실행하면 bash
와 shell
모두 없다.
따라서 컨테이너에 직접 접속해 디버깅하거나 로그를 봐야할 필요가 있다면 알파인 리눅스를 사용하면 편리하다.
'DevOps > Kubernetes' 카테고리의 다른 글
[Kubernetes] PV(PersistentVolume), PVC(PersistentVolumeClaim) (0) | 2022.05.29 |
---|---|
[Kubernetes] Volume (emptyDir, gitRepo, initContainer, hostPath) (0) | 2022.05.29 |
[Kubernetes] Ingress Challenge (0) | 2022.05.29 |
[Kubernetes] Ingress (인그레스) (0) | 2022.05.29 |
[Kubernetes] Service - ExternalName (0) | 2022.05.23 |
영차영차 성장 블로그
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!