[Kubernetes] Component 동작으로 이해하기

전체 개요

VM영역

VM영역은 각 노드들의 영역이고 노드안에 Kubernetes가 동작하기 위한 설치파일들이 설치되는 공간입니다.

 

물리적인 서버가 넉넉하다면 가능한한 Master Node에는 일을 시키지 않는 것이 좋습니다.
그 이유는 마스터 노드가 일을하다 리소스가 부족하여 Master Node가 죽게된다면 하위에 있는 Worker Node전부 동작을 멈추게 되기 때문이지요.

Kubernetes Cluster

각 Pod들이 올라가게되는 공간입니다. 이 부분을 Component라고 하는데 Master Node에서 담당하는 Control Plane Component가 있고 Worker Node들이 담당하는 Worker Component가 있습니다.

Resource

cluster level

cluster level은 Cluster전체를 대상으로 적용되는 개념입니다.

 

Node, ClusterRole, ClusterRoleBinding, PersistentVolume, StorageClass, Namespace 등이 여기에 포함됩니다.

namespace level

namespace level은 Cluster안의 특정 Namespace에만 적용되는 개념입니다.
리소스를 논리적으로 분리하는 단위이며, 동일한 Cluster안에서도 Namespace마다 별도의 정책, 자원 할당, 권한 관리가 가능합니다.

 

Pod, Service, Deployment, Role, RoleBinding, HPA 등이 여기에 포함됩니다.

---

Pod의 생성 및 probe

Deployment를 생성하는 과정을 예로 들겠습니다.

생성 과정

1. kubectl

다음 명령어를 통해 kube-apiserver에 Deployment를 생성하도록 API요청을 보냅니다.
또는 Dashboard를 통해 .yaml파일을 직접 업데이트 시켜주어도 됩니다.

kubectl apply [-f] ...

2. kube-apiserver

생성 API요청을 보내면 kube-apiserver는 etcd에 있는 데이터베이스에 데이터를 입력합니다.

3. kube-controller-manager

kube-controller-manager는 데이터베이스를 계속 모니터링을 하고 있는데 데이터의 변경이 이뤄지면 kube-apiserver에 ReplicaSet 생성 API요청과 Pod 생성 API요청을 보냅니다.

 

이렇게 데이터베이스에 ReplicaSet과 Pod이 생성되었습니다.
주의해야 할것은 아직 데이터베이스에 데이터가 생성된 것이지 아직 Pod이 생성된 것은 아닙니다!!

4. kube-scheduler

kube-scheduler는 보통 kube-apiserver에 의해 노드들의 자원을 모니터링하고 있다가 데이터베이스에 띄울 Pod이 있다면 스케쥴링 해줍니다.

5. kubelet

kubelet은 kube-apiserver로 자신의 노드정보가 있는 Pod를 모니터링하고 있다가 CRI(ex. containerd)에 컨테이너 생성 요청을 하게 됩니다.

6. CRI

컨테이너 생성

7. kubelet

probe기반으로 container의 Health Check를 주기적으로 실행

---

Service 동작

위 내용을 이어서 설명하겠습니다.

동작 과정

1. kubelet

kubelet이 kube-proxy에게 Network 생성요청을 합니다.

2. kube-proxy

kube-proxy는 iptables를 업데이틀하게 되는데 아래 이미지와 같이 port와 Service를 연결 시킵니다.

이 전에 Service의 name으로 API요청을 보내는 것을 확인해본적이 있습니다. 그런식으로 동작하는 것이죠.

3. iptables

iptables은 Linux로 들어오는 모든 패킷을 관리하는데, 입력된 데이터를 기반으로 API요청이 들어왔을 때 Container에 트래픽을 전달하게 됩니다. 이 구간의 기능은 CNI가 담당하게 되는데, 우리가 설치했던 것으로 보자면 calico가 이것을 담당하게 되는것이죠.

 

아래 이미지를 기반으로 보자면 Service에 있는 nodePort를 통해 31231포트로 요청이 오면 api-tester-1231로 맵핑되어 해당 서비스로 요청을 보내라는 동작을 하게 됩니다.

---

Secret 동작

위 내용을 이어서 설명하겠습니다.

우선 우리가 만들어 놓았던 postgresql-info.yaml파일을 기억하시나요??
Secret을 통해 stringData속성에서 해당 파일을 만들었던 것을 기억하셔야 합니다.

 

자! 그러면 이 파일은 Node의 메모리 영역에 마운팅되게 됩니다.
그 말은 무엇이냐?? 전원이 꺼지면 날아가는 휘발성 정보라는 이야기죠.

 

디스크를 누가 훔쳐가도 데이터가 날아가니 문제는 없겠지만, 다른 문제가 있겠죠??
문제는 메모리에 올라가는 데이터이기 때문에 무분별하게 Secret을 사용하면 Memory Leak이 발생 할 수 있다는 것입니다.

 

또한 Secret을 수정하게 되면 즉각 반영되지 않고 kubelet이 주기적으로 모니터링을 하고 있다가 변경사항이 감지되었을 때 적용시킵니다. 딜레이가 발생할 수 있다는 것이죠.

---

HPA 동작

위 내용을 이어서 설명하겠습니다.

동작 과정

1. CRI

현재 동작중인 Container의 자원 상황은 CRI가 인지하고 있습니다.
kubelet은 10초마다 조회하여 cpu, memory를 조회하여 이것을 파악하는 것이죠.

 

하지만, 우리가 아무리 HPA에 metrics속성을 명시해도 Pod에 부하가 발생하더라도 아무런 일도 일어나지 않습니다.

2. addon Pod(metrics-server)

addon Pod이란 Kubernetes를 편하게 사용하기 위한 추가적인 라이브러리 또는 프레임워크를 말하게 됩니다.

 

때문에 스켈링관리를 하고 싶다면 metrics-server를 설치해 두어야 합니다.

metrics-server는 kubelet에서 주기적으로 자원 사용량을 수집합니다.(60초)

3. kube-controller-manager

kube-controller-manager는 metrics-server에서 수집한 데이터를 기반으로 임계값 및 매트릭을 확인하여 부하가 증가하거나 감소할 때 Pod을 스케일링 하게 됩니다.

 

스케일링에 반응하는 시간은 최소 1최 ~ 최대 86초 까지 걸릴 수 있습니다.

---

유효한 커멘드

▶ Resource 확인

kubectl api-resources

​

▶ Cluster 주요 컴포넌트 로그 확인

# 주요 컴포넌트 로그 보기 (kube-system)
kubectl get pods -n kube-system
kubectl logs -n kube-system etcd-k8s-master
kubectl logs -n kube-system kube-scheduler-k8s-master
kubectl logs -n kube-system kube-apiserver-k8s-master
...

▶ Master Node 파일 위치

# 쿠버네티스 인증서 위치
cd /etc/kubernetes
ls /root/.kube/config

#Control Plane Component Pod 생성 yaml 파일 위치
ls /etc/kubernetes/manifests

#전체 Pod 로그
/var/log/pods/<namespace_<pod-name>_<uid>/<number>.log
/var/log/containers/<pod-name>_<namespace>_<container-name>_<container-id>.log

​

트러블 슈팅

▶ kubelet 상태 확인

상태 확인 -> 상세 로그 확인 -> 10분 구글링 -> VM 재기동 -> Cluster 재설치 -> 답을 찾을 때 까지 구글링

1) systemctl status kubelet       // systemctl (restart or start) kubelet
2) journalctl -u kubelet | tail -10

▶ Containerd 상태 확인

systemctl status containerd
journalctl -u containerd | tail -10

▶ Node 상태 확인

kubectl get nodes -o wide
kubectl describe node k8s-master

▶ Pod 상태 확인

kubectl get pods -A -o wide

▶ Event 확인 (기본값: 1h)

kubectl get events -A
kubectl events -n anotherclass-123 --types=Warning  (or Normal)

▶ Log 확인

# 10줄 만 조회하기
kubectl logs -n anotherclass-123 <pod-name> --tail 10
# 실시간으로 조회 걸어 놓기
kubectl logs -n anotherclass-123 <pod-name> -f
# 1분 이내에 생성된 로그만 보기
kubectl logs -n anotherclass-123 <pod-name> --since=1m