[K8s] Controller 와 Workload

 

> Deployment 컨트롤러를 통해 Pod 실행

(pod만 독립적으로 실행하고 싶다면? --restart=Never) 즉, pod가 정지됐을 때 자동으로 재기동해야 하는지에 따라 옵션을 선택하면 된다.만약 해당 옵션을 생략하는 경우 디폴트로 Always가 적용되어 디플로이먼트에 의해 파드가 기동 된다. 

 

$ kubectl create deploy --image=hello-world hello-world

 

 

 

 

 

 

 

 

 

 

 

👉 deployment 생성 후, deployment가 생성한 모든 오브젝트를 확인할 수 있다: pod, replicaset.
👉 레플리카 셋과 파드 뒤에 해시 문자열이 추가되어 고유한 이름이 주어진 것을 확인할 수 있다.
👉 레플리카셋과 디플로이먼트는 지정된 pod의 개수가 유지될 수 있도록 관리하는 역할을 한다. 

 

💡  kubectl run 명령어가 미치는 영향의 범위가 과하게 커지지 않도폭 pod 기동시에만 사용하는 것이 권장된다.
따라서 deployment를 생성에 kubectl create deploy ~ 명령어를 사용하는 것이 권장된다. 

 

🔎 Deployment 를 통해 생성된 pod의 상태가 CrachLoopBackOff인 이유는 무엇일까?
 먼저 CrashLoopBackOff 상태란, 해당 pod가 어떠한 문제로 인해서 restart를 반복하며 다음 재시작 전에 대기하는 중임을 의미한다. Deployment로 기동되는 pod는 웹 서버와 같이 항상 기동되는 경우가 많은데, hello-world 컨테이너는 메세지를 출력하자마자 바로 종료되는 단발성의 특징을 가진다. 그래서 Deployment 입장에서는 어차피 짧게 살고 죽는 hello-world 컨테이너를 '항상' 기동시키기 위해서 계속 재시작하다가 대기 상태에 빠져버린 것이다. 즉, hello-world 의 워크로드는 Deployment 컨트롤러에 적절하지 않는 것이다.

 

 

> Deployment Controller 에 맞는 워크로드 실행: Web Server 

 

$ kubectl create deployment --image=nginx webserver --replicas=5

 

 

$ kubectl get deploy,po 

 

 지정된 갯수를 채우기 위해 pod가 추가된다는 것은 이 전의 그 pod가 되살아난 것이 아니라 새롭게 생성된 pod가 그 자리를 채우는 개념이다. 그렇기 때문에 컨테이너의 어플리케이션은 기본적으로 stateless여야 한다. 

 

> JOB을 통한 Pod 실행 

그렇다면, deployment 컨트롤러에 어울리는건 웹서버나 앱서버라는 것은 알았고hello-world와 같이 단발성으로 끝나는 컨테이너에 어울리는 컨트롤러는 무엇일까?그것은 바로 Job Controller! 

 

$ kubectl create job hello-world --image=hello-world

 

 

👉 조금 시간이 지나고나면, Completed 상태가 되어있다 

 

이 컨트롤러는 컨테이너의 프로세스 종료 코드 값을 통해 성공과 실패를 판정하는데만약 pod가 비정상적으로 종료되면 재시작하고, 정상 종료될때까지 지정한 횟수만큼 재실행한다.

 

$ kubectl create job job1 --image=ubuntu -- /bin/bash -c "exit 0"

$ kubectl create job job2 --image=ubuntu -- /bin/bash -c "exit 1"

 

 

👉비정상 종료하도록 설정된(exit 1) job2의 pod는 계속 재시작을 시도하는 안쓰러운 모습을 확인할 수 있다.