쿠버네티스 - 2

쿠버네티스를 공부한 내용을 작성한다.

---

네임스페이스 (Namespace)

• 어플리케이션을 배포하는 과정에서 서로 격리된 구역
• 아파트의 101호 - 102호와 같이 서로에게 일어나는 일을 알 수 없음

> kubectl get pods -n kube-system

위 명령어를 통해 현재 쿠버네티스를 구성하고 있는 구성 요소들을 확인

• calico, coredns, kube-apiserver, kube-controller, kube-proxy, kube-scheduler 등이 존재

• AWS에서 제공하는 EKS, Azure에서 제공하는 AKS, Google에서 제공하는 GKE도 마찬가지로 kube-system 밑에 주요 구성요소가

---

쿠버네티스의 기본 철학

• 마이크로서비스 아키텍처 (MSA, Microservices Architecture)
  : 각자가 맡은 바를 열심히 진행

파드의 배포 과정

1. 사용자, 관리자가 pods 생성 명령어 작성
2. API 서버 및 etcd로 pods 생성 요청
3. API 서버가 컨트롤러 매니저로 생성 요청 전달 후, 실제로 만들었는지 감시
4. 컨트롤러 매니저가 pods 생성
5. API 서버가 스케줄러에게 새로 생성된 pods 워커 노드 포함 요청
6. 스케쥴러가 새로운 pods를 워커 노드에 포함되도록 스케쥴링 진행
7. API 서버가 워커 노드에 있는 kubelet에 pods가 있는지 감시
8. kubelet은 컨테이너 런타임에 pods의 동작 관리 요청
9. 컨테이너 런타임이 컨테이너 생성
10. kubelet은 pods 운영 상태 정보를 API 서버에게 전달
11. 사용자는 kube-proxy를 통해 pods를 조작 및 통신

• API 서버가 쿠버네티스 중앙에서 상태 값을 가지고 있고, 그 상태를 컨트롤 매니저, 스케쥴러, kubelet 등이 상태 값을 변경하려는 방식으로 동작

• 사용자가 명령어로 전달한 내용을 API 서버가 공지하고 있으면, 다른 구성요소들이 이를 참고하여 사용자의 요구사항을 만족할 수 있도록 함
  (선언적인 시스템)

• 감시 -> 차이발견 -> 상태변경 -> 반복

---

API 서버와 etcd

• 가지고 있는 정보의 저장을 위해 매번 클러스터의 업데이트된 정보를 etcd에 기록 (구성 정보를 백업)
• etcd는 기록이 완료되었음을 API 서버에게 매번 알림
• 문제가 생긴 경우 etcd 내용을 확인하는 것이 정답
• API 서버는 쿠버네티스 클러스터를 구성하는 모든 요소의 게이트웨이

---

쿠버네티스 발생 가능한 문제

1. 파드를 실수로 지운 경우

   • 파드만 배포된 경우: 파드가 사라짐, 복구 불가

   • deployment 형태로 배포된 경우: 파드가 지워지더라도 새로 생성

• 단일 pod와 deployment를 생성한 후, 1개씩 지워봄
• 단일 pod는 지워지고 아무런 후속조치가 없지만, deployment에 포함된 pod는 삭제하자마자 새로운 pod를 생성 (2tkxn 삭제, rqjb1 생성)
• deployment를 삭제하고 싶으면 kubectl delete deployment 이름의 형태로 작성

2. 쿠버네티스 구성요소에 문제가 생긴 경우
   • 구성요소의 대부분은 문제가 발생한 경우에 자동 복구 등이 가능하지만, kubelet에 문제가 발생하면 자동 복구가 어려움

워커 노드 w1-k8s에서 kubelet을 중단하고 deployment배포를 진행하면 어떻게 될까?

pod의 상태가 Pending으로 나타남, 생성 안됨

즉, kubelet에 문제가 생기면 배포 과정에 문제 발생

워커 노드에서 kubelet 서비스를 시작하고, 마스터 노드에서 -w 옵션을 부여해 pods의 변경 상태를 확인해보면, 서비스를 시작하자마자 자동으로 pod를 생성함

---

워커 노드에서 컨테이너 런타임인 containerd 서비스를 중단하고 replicas를 6으로 올려 더 많은 pod를 생성해보려 함

containerd 서비스를 중단한 w1 쪽으로는 새로운 pod가 생성되지 않고, w2,w3 쪽으로 새로운 pod가 생김

기존 w1이 가지고 있는 pod는 일정 시간이 지나도 containerd가 살아나지 않을 경우 다른 워커 노드로 옮겨지게 됨

---

• 마스터 노드에 있는 스케줄러를 삭제하기 위해 kube-system 하위 항목을 나열하고 kubectl delete pod kube-scheduler-m-k8s -n kube-system 명령을 이용해 삭제 (-n 옵션은 namespace를 알려주기 위함)

• 쿠버네티스의 스케쥴러는 pod로써 관리되고 있지만, 없어서는 안될 주요 구성요소 이기 때문에, 삭제하자마자 새롭게 생성해버림

• kubelet 서비스를 중지하고 다른 내용을 삭제하면, TERMINATING 상태로 표시되지만, 실제로는 수행되지 않기에 정상적으로 작동

---

• containerd는 docker보다 훨씬 안정적으로 컨테이너 런타임을 운영함

• containerd 서비스를 중단해도, 스케쥴러, API 서버, kubelet 등은 모두 살아있기 때문에 배포, 삭제 등이 가능