팀 동료분이 질문주신 내용 중에 pod Running상태와 Ready가 뭐가 다른지 물어봤습니다. 저는 정확하게 몰라 같이 공부해보자고 답변을 하고 어떤 차이가 있는지 공부했습니다.
이 글에서 다루는 예제코드는 github에 공개되어 있습니다.
1. 선수지식: pod의 컨테이너
pod는 1개 이상 컨테이너를 갖습니다. 예를 들어 아래 pod는 컨테이너 2개(nginx, busybox)를 갖습니다. 컨테이너 갯수는
kubectl get pod 결과에서 READY필드에 표시됩니다.
예제코드: https://github.com/choisungwook/pod_running_and_ready/tree/main/example1_nginx
2. pod running과 ready 비교
running(실행중)은 pod에 정의한 컨테이너 이미지가 실행되었는지 확인합니다. ready(준비)는 조건을 검사하여 pod를 사용할 수 있는지 확인합니다.
pod의 컨테이너가 실행되었다는 의미와 사용가능한지 검사하는 것은 무슨 차이가 있을까요?
pod의 컨테이너가 실행되더라도 여러가지 이유로 의도한 동작이 실행되지 않을 수 있습니다. 예를 들어 부팅과정이 느린 웹 애플리케이션을 pod로 실행하면, 컨테이너가 실행되더라도 부팅이 끝날 때까지 컨테이너는 아무런 동작을 하지 않습니다.
컨테이너가 실행되고 있지만, 애플리케이션 부팅 등으로 컨테이너가 비정상이라면 pod를 사용할 수 없습니다. 그래서 pod를 사용할 수 있는지 검사하게 되는데, 검사 통과 유무를 표시하는 필드가 ready입니다. 검사조건은 livenessprobe, readinessprobe 등이 있습니다.
정리하면, pod running은 pod를 사용할 수 있다라는 것을 보장하지 않습니다. 이 개념에 익숙하지 않으면 pod 장애분석에 걸림돌이 됩니다.
3. pod running 상세내용
3.1 running이 되는 조건
pod가 running라는 것은 무엇을 의미할까요? pod에 정의한 컨테이너 모두 생성이 되었고 1개 이상 컨테이너가 running인 상태입니다.
컨테이너가 생성되는 조건은 init container, prestart hook, 컨테이너 이미지 다운로드 성공 등이 있습니다. 컨테이너 running은 컨테이너 이미지를 실행했다는 의미입니다.
3.2 running 조회 방법
예제코드: https://github.com/choisungwook/pod_running_and_ready/tree/main/example4_invalid_containers
pod running상태는 kubectl describe pod에서 조회할 수 있습니다. 아래 예제는 모든 컨테이너가 생성되었고 running상태입니다. 그러므로 pod도 running상태입니다.
존재하지 않는 컨테이너 이미지가 있으면 컨테이너가 생성이 안됩니다. 그러므로 pod는 pending상태에 있습니다.
4. pod ready 상세내용
4.1 ready가 되는 조건
pod ready는 pod를 사용할 준비가 되었다는 의미로, pod에 정의한 모든 컨테이너가 ready이면서 커스텀 조건을 통과해야 합니다. 이 글은 커스텀 조건은 제외하고 컨테이너 ready상태에 집중적으로 살펴보겠습니다.
4.2 ready 조회 방법
kubectl describe pod명령어로 pod가 ready되었다는 것을 확인할 수 있습니다. Conditions.Ready필드는 pod가 ready되었는지 표시합니다. conditions.ContainersReady는 pod에 정의한 컨테이너가 모두 ready상태인지 표시합니다.
예제코드: https://github.com/choisungwook/pod_running_and_ready/tree/main/example1_nginx
컨테이너 ready갯수는 kubectl get pod로 쉽게 조회할 수 있습니다. 컨테이너 ready 검사조건은 livenessprobe, readinessprobe 등이 있습니다.
5. pod가 not ready일때 미치는 영향
pod가 not ready라는 말은 pod를 사용할 수 없는 상태라는 의미입니다. 그러므로 pod를 참조하는 쿠버네티스 리소스에 영향을 미칩니다. 대표적으로 replicaset, service가 있습니다.
replicaset은 pod가 not ready이면, 새로운 pod를 선택(selector)하지 못합니다. replicaset pod spec을 수정하여 새로운 pod가 생성되더라도, pod가 not ready이면 새로운 pod를 사용하지 못한다는 의미입니다.
예제코드: https://github.com/choisungwook/pod_running_and_ready/tree/main/example3_containers
service는 엔드포인트(endpoints)에 pod가 추가되지 않습니다. 그러므로 service를 사용하여 pod에 접근하지 못합니다.
6. 마치며
running과 ready를 공부한 후 2가지를 느꼈습니다.
첫번째, 안전하게 pod를 배포하기 위해 probe를 적극적으로 사용해야겠다는 마음을 가졌습니다. running은 pod를 사용할 수 있다는 의미가 아니므로 pod가 정상적이라는 것을 보장하지 못합니다. 그리고 서비스 장애까지 발생하는 최악의 상황을 만날 수 있습니다.
두 번째, ready는 쿠버네티스 리소스뿐만 아니라 쿠버네티스 오픈소스에 많은 영향을 있다는 것을 알았습니다. 예를 들어 argo rollout의 promote조건은 replicaset가 ready여야 합니다. ready라는 의미를 정확히 해석하지 못하면, 안전하게 pod를 배포하지 못해 서비스 장애를 만날 수 있습니다.
참고자료
'전공영역 공부 기록' 카테고리의 다른 글
| 게임으로 배우는 AWS S3(부제 S3 game) (0) | 2023.08.27 |
|---|---|
| aws 환경변수 초기화 (0) | 2023.08.21 |
| Dockerfile ENTRYPOINT에 arg를 사용가능한지 테스트 (0) | 2023.08.08 |
| Argocd rbac 테스트 (0) | 2023.08.06 |
| NLB를 장애상황 퀴즈 (1) | 2023.08.06 |