쉽게 시작하는 쿠버네티스 CH4 문제를 통해 배우는 쿠버네티스

쿠버네티스 파드에 문제가 생겼다면 (GKE에서 실습 됨)

파드를 실수로 지웠다면?

• 파드만 배포된 경우, 문제가 생긴다. 파드는 단일 객체이다.
• 디플로이먼트 형태로 배포된 파드는 괜찮다. 파드가 지워지게 되면 파드를 다시 만든다.
• 쿠버네티스가 파드를 대하는 자세
  • 죽을 수도있지.. 라고 생각함. 그리고, 파드 옮길 때 실제로 옮기는게 아니라, 파드를 삭제하고 만든다.

  kubectl apply -f ~/_Lecture_k8s_starter.kit/ch4/4.1 // 두개의 yaml에 대한 deployment 만든다.
  kubectl get pods
  kubectl delete pod del-pod //파드를 지운다.
  kubectl get pods // 파드가 지워진다. 
  kubectl delete pod del-deploy-574f..~ // 배포의 파드를 지운다.
  kubectl get pods // 파드가 새로운 것이 생성된다. 
  kubectl delete deployment del-deploy //deployment 지운다. 
  kubectl get pods // 다른거 생성한다. 
  

쿠버네티스 워커 노드의 구성요소에 문제가 생겼다면 (GKE에서 실습 X)

<aside> 💡 Google Kubernetes Engine (GKE)에서는 개별 노드에 대한 저수준 접근 (예: **systemctl**을 사용하여 서비스를 중지)이 제한되어 있습니다. GKE는 완전 관리형 쿠버네티스 서비스로, 노드 관리 및 유지보수 작업은 GKE에 의해 자동으로 처리됩니다. 이는 사용자가 직접 kubelet 프로세스를 중지하거나 관리할 필요가 없다는 것을 의미합니다.

</aside>

쿠버렛에 문제 생기면 배포가 제대로 이루어지지 않는다.

• API 그대로 안 가져오는 곳은 kubelet이다. 따라서 문제가 생기는 경우, 바로 복구가 되지 않는다. 즉 제대로 배포가 이루어 지지 않는다.

systemctl stop kubelet // 쿠버랫 종료
// 배포한다. 
kubectl get pods // 파드 확인
kubectl get pods -o wide // w1-k8s 는 배포가 이루어지지 않는다.
systemctl start kubelet // 쿠버랫 살린다.
kubectl get pods -o wide -w // w1-k8s 는 배포가 된다. 

컨테이너 런타임(ContainerD) 중단이 되면, 해당 워커 노드에 배포할 수 없다.

파드 세 개가 배포 되어 있는 상황

systemctl stop containerd // 중지
systemctl status containerd // 상태 확인 -> inactive 상태이다. 
kubectl scale deployment del-deploy --replicas=6 
kubectl get pods -o wide // 1번 런타임 종료 했기 때문에 워커 노드 1번으로는 배포되지 않는다. 

그렇다면 워커노드 1번은 어떻게 되나? 컨테이너 런타임 종료한 이후로 5분 정도 지나면 evict라고 해서, 런타임 동작하지 않는 것을 인식하여 다른 곳으로 옮기게 된다. 중단되면, 파드를 해당 워커 노드에 배포할 수 었다.

추가 배포를 통해 스케줄러 역할 확인

스케줄러 배포 균등하게 하는지 확인한다.

kubectl scale deployment del-deploy --relicas=9 
// 9로 바꾸어주게 되면, 가능한 균등하게 스케줄러가 배포하려고 할 것이다.
kubectl get pods -o wide // (가능한!) 균등하게 배포한다.

쿠버 네티스 마스터 노드의 구성 요소에 문제가 생겼다면, (GKE에서 실습 X)

스케줄러를 삭제한다면, 삭제 되면 다시 생성된다.

kubectl get pods -n kube-system
kubectl get pods -n kube-system - wide // 스케줄러 이름 알수있다.(master에 있음..)
kubectl delete pod kube-scheduler-m-k8s -n kube-system // 네임스페이스를 지정하고, 스케줄러를 삭제함. 

마스터노드에 쿠버렛이 중단되면 어떻게 동작하는지 확인한다.

 

 

systemctl stop kubelet 

kubectl delete pod kube-scheduler-m-k8s -n kube-system
kubectl get pods -n kube-system
// 삭제 수행 되지 않는다. 
// 워커 노드에 애플리케이션 제대로 배포할 수 있을지? 의문이 든다. 
kubectl create deployment nginx --image=nginx // 정상적으로 생성된다. 

// 생성은 되는데 스케일이 안되지 않을까?
kubectl scale deployment nginx --replicas=3 // 스케일 된다. -> 스케줄러 제대로 동작
kubectl get pods 

// 스케줄러는 terminating이라고 나와있지만, 쿠버렛을 통해 전달되지 않아서 문제가 생기지 않는다. 
systemctl start kubelet // 쿠버렛을 살린다. 
kubectl get pods -n kube-system -w // 스케줄러가 다시 Running 된다.  

kubelet 중단되면 마스터 노드 영향받지 않고, 애플리케이션 배포 되고, 워커 노드도 영향을 받지 않는다.

 

마스터 노드에 있는 컨테이너 런타임 d를 중단해 보고 동작을 확인한다.

• 1.2 도커에서 동작이 좀 차이가 있다. (vs 컨테이너d) 컨테이너d가 도커보다 훨씬 안정적임.

systemctl stop containerd // 컨테이너 d를 삭제한다. inactive 
kubectl delete deployment nginx // 지운다.
kubectl get pods //지워졌음을 확인한다.

kubectl delete deployment nginx
kubectl get pods 

kubectl get pods -n kube-system // 소속되어 있는 애들 중에, 
kubectl delete pod kube-scheduler-m-k8s -n kube-system // 이렇게 한다면, 컨테이너 런타임 
// 이 중단되었기 때문에 전달하지도, 받지도 않는다. 
// 다시 containerd를 시작시키면, termination -> 다시 올리도록 한다.

kubectl create deployment nginx --image=nginx
kubectl get pods -n kube-system

 

쿠버네티스 컨테이너 런타임이 컨테이너 d로 변경되면서 시스템 더 안정화 되고, 조회, 워커 노드에 있는 deployement 지우고 생성하는 것도 가능하다.

 

컨테이너d가 문제가 있음에도, 상태를 유지하고 있으니 nginx 지우는 것이 가능하다.

 

쿠버시스템에 해당하는 컴포넌트 문제 생겼을 경우, 이를 제대로 인식하고 복구가 안됨. → 마스터 노드를 안정적으로 구성하는 것이 올바른 방법이다.