[kubernetes] 쿠버네티스 인사이드

3.1 쿠버네티스 구성요소 확인(+EKS, AKS, GKE, 관리형 쿠버네티스)

쿠버네티스를 이루는 것들

구역을 나누는 네임스페이스(Namespace)

• 서로의 구역을 나눈 단위
• 우리가 배포했던 것들은 default라는 네임스페이스에 배포 되었음.
• 쿠버네티스는 kube-system이라는 네임스페이스에 배포 되어 있다.

네이티브 쿠버네티스 구성 요소 확인

[root@m-k8s ~]# kubectl get pods -n kube-system
NAME                                       READY   STATUS    RESTARTS   AGE
calico-kube-controllers-744cfdf676-7xr6t   0/1     Error     3          12d
calico-node-4ckvp                          0/1     Running   2          12d
calico-node-bd75c                          0/1     Error     3          12d
calico-node-qg8d2                          0/1     Running   2          12d
calico-node-ssls5                          0/1     Error     1          12d
coredns-74ff55c5b-twzlf                    0/1     Error     3          12d
coredns-74ff55c5b-vmjmv                    0/1     Error     3          12d
etcd-m-k8s                                 1/1     Running   3          12d
kube-apiserver-m-k8s                       0/1     Running   4          12d
kube-controller-manager-m-k8s              0/1     Running   4          12d
kube-proxy-422sj                           0/1     Error     3          12d
kube-proxy-dnq2l                           1/1     Running   2          12d
kube-proxy-jc9gr                           1/1     Running   2          12d
kube-proxy-p4rpt                           1/1     Running   2          12d
kube-scheduler-m-k8s                       1/1     Running   3          12d

• EKS, AKS, GKE의 관리형 쿠버네티스에도 kube-system이 있는 것을 확인할 수 있다.

3.2 쿠버네티스의 기본 철학

• 쿠버네티스는 MSA(MicroService Architecture)로 구성되어 있다.
• 이와 반대되는 개념이 Monolithic Architectur

파드가 배포되면?

1. 파드 생성 요청: 사용자가 API 서버에게 파드 생성을 요청
   3-1. 파드의 생성 감시: API 서버는 컨트롤러 매니저가 파드가 생성되는지 감시를 한다.
   3-2. 파드의 생성: 컨트롤러 매니저는 파드를 생성하고, API 서버의 값 (replicaSet 등)을 업데이트 한다.
   4-1. 새로운 파드가 워커 노드에 들어갔는지 감시: API 서버는 스케줄러가 새로운 파드가 워커노드에 들어갔는지 감시한다
   4-2. 새로운 파드를 워커 노드에 넣도록 스케줄함: 스케줄러는 API 서버에 와서 파드가 새로 생성되어서 assign 되어야 하는 값을 보고 새로운 파드를 워커노드에 넣도록 스케줄만 한다.
   5-1. 새로운 파드가 노드에 잘 소속되어 있는지 감시: API 서버는 kubelet을 감시
2. 파드의 동작 관리: kubelet은 컨테이너 런타임을 통해서 파드에 동작이나 생성을 하도록 명령
3. 컨테이너 생성: 컨테이너 런타임이 컨테이너를 생성한다.
   5-2. 파드 상태 정보 전달: kubelet이 API 서버에게 파드가 생성되었음을 알려준다.
4. 파드 사용가능: API는 사용자에게 파드가 사용 가능함을 알려준다.

선언적인 시스템

• 추구하는 상태: API 서버에 kubectl로 선언한 상태
• 현재 상태: 현재의 구성요소가 가지고 있는 상태
• 쿠버네티스는 추구하는 상태와 현재 상태를 계속 맞추려고 한다.

API 서버와 ETCD

2-1. (매번) 클러스터의 업데이트 된 정보 기록: API 서버는 kubectl로 명령을 내린 상태를 etcd에 저장한다.
2-2. (매번) API 서버에 업데이트 되었음을 알림

2가지만 기억합시다.

• 쿠버네티스는 선언적인 구조이며 각 구성요소는 자기 일만 한다.
  • API 서버는 상태 값만 업데이트하고 가만히 있음.
  • kubectl은 업데이트 할 값(리플리카 셋 등)을 선언해 현재 상태를 맞추려고 하는 것에 초점이 놓여있음
  • 스케줄러는 배포한 파드가 잘 노드에 assign 되어있는지의 상태 값을 계속 업데이트 하는 일만 한다.
• 쿠버네티스는 현재 상태를 추적해서 추구하는 상태와 현재 상태를 계속 맞추려고 한다.

3.3 실제 쿠버네티스의 파드 배포 흐름

현재 쿠버네티스의 파드 배포 흐름을 살펴보기

• 관리자, 개발자: kubectl을 통해서 API 서버에 명령을 내린다.
• API 서버는 etcd에 해당 정보를 업데이트 한다. (1:1 동기화)
• API 서버의 값을 컨트롤러 매니저가 보고 이에 맞게 자신의 값을 바꾸고 API 서버에 알림
• 스케줄러는 워커노드 파드를 어싸인, 로드밸런싱(파드가 각각의 워커노드에 밸런싱 되게 들어가게 하는 역할)을 한다. API 서버와 통신하면서 상태 값을 업데이트한다
• API 서버를 보고 kubelet이 컨테이너 런타임에게 파드 생성을 명령한다.
• 컨테이너 런타임이 파드를 생성한다.
• 생성된 파드들은 kube-proxy 통해 사용자와 통신한다.
• 쿠버네티스 클러스터가 통신하는 모든 것에 API 서버가 존재한다. 즉 API 서버는 굉장히 중요한 요소다.
• CoreDNS: IP를 사용자가 들어갈 수 있는 이름으로 제공