[1-8] Component 동작으로 이해하기

📑 전반적인 작동 과정

• kubeadm이 /etc/kubernetes/manifests 경로에 있는 yaml 파일을 통해 컴포넌트들을 생성함
• kubectl이 인증서를 사용하여 kube-apiserver로 API를 날려 etcd에 데이터를 저장
• -> 많은 오브젝트들이 데이터로 들어가져 있어 조회를 하면 나옴
• Worker Component에는 kube-proxy만 추가로 만들어 놓음 -> 사용자가 앱을 올리기 위한 공간
• Addon Pod :  대시보드, 매트릭스 서버와 같이 k8s 기본 기능을 확장시키기 위한 앱
• 실제 컨테이너는 containerd가 만들어 줌
• k8s(kubelet)는 컨테이너 생성 요청만 함
• 전체 리소스들은 Control Plane Component의 파드들에 의해 동작을 함
• 스토리지 개념을 알아야 PV를 잘 쓸 수 있고 PV만으로 할 수 있는게 없어 볼륨 솔루션도 알아야 됨

 

Resource

• cluster level과 namespace level로 나누어짐

 

Controller

• HPA, Deployment, ReplicaSet
• 타 controller나 Object를 제어
• 오브젝트들을 자동화 시킬 목적으로 만듦

Object

• Service, Pod, Configmap, Secret, PVC
• 하나의 인프라 개념으로서 단독 기능을 함

 

---

 

 

🔎 세부 동작 과정

Pod

• kubectl로 Deployment 생성 API -> kube-apiserver -> etcd저장
• kube-controller-manager는 계속 데이터베이스를 모니터링 -> Deployment 조회되면 -> ReplicaSet 생성 API -> 레플리카셋 조회되면 -> 파드 생성 API -> 파드 생성
• kube-scheduler는 kube-apiserver를 통해 노드 자원 모니터링 -> 파드 조회되면 파드 띄울 노드를 스케줄링(nodeSelector, resources 참고)
• kubelet은 kube-apiserver를 통해 자신의 노드 정보가 있는 파드를 모니터링 -> 발견 후 컨테이너 런타임에 컨테이너 생성 요청
• probe 설정에 맞게 kubelet이 컨테이너로 헬스체크 API를 주기적으로 날려줌

 

Service

• nodePort 타입으로 서비스를 만들어서 파드에 연결
• -> kubelet이 kube-proxy한테 네트워크를 생성해 달라고 요청
• -> kube-proxy는 iptables에 내용을 추가

 

iptables

• iptables는 리눅스로 들어오는 모든 패킷을 관리
• 따라서 사용자가 API를 호출하면 컨테이너로 트래픽을 전달해줌(CNI로 설치했던 calio가 해줌)

 

Secret

• 보안 기능이 있지만 크게 체감은 안됨
• 파일들은 노드의 메모리 영역에 마운팅됨
• 그런데 이 메모리는 전원이 꺼졌을 때 지워지는 영역
• -> 물리적으로 디스크를 변경해야 하는 일이 생겼을 때 실수로 디스크에 데이터를 남겨놓거나 복구를 하더라도 일반 데이터처럼 살릴 수가 없음
• 시크릿을 많이 만들게 되면 노드의 메모리가 부족해짐
• 시크릿의 data 내용을 수정하게 되면 바로 변경되지 않고 kubelet이 주기적으로 체크하고 있다가 변경사항이 생기면 업데이트를 해줌(딜레이가 발생)

 

HPA

• 컨테이너에 대한 자원 사용량은 containerd가 알고 있음 -> kubelet이 CPU와 메모리를 10초에 한 번씩 조회
• 이 상황에서 HPA에 metircs를 설정하고 Deployment에 연결한다고 해도 파드에 부하가 발생했을 때 아무런 일이 발생하지 않음
• Addon Pod로 metircs-server를 별도로 설치
• -> 60초 단위로 kubelet를 통해 사용량 수집
• -> kube-controller-manger가 15초 단위로 HPA의 임계값과 metrics-server를 통한 사용량을 비교하여 스케일링을 발생
• 스케일링 반응시간 : 1~85초

 

 

---

 

 

💻 관련 명령어

 

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

// 인증서 내용을 이 위치에 k8s를 설치할 때 복사를 함
// kubectl이 이곳을 참조해서 API를 날림
ls /root/.kube/config

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

// 전체 Pod 로그
// 마스터 노드 위에 올라가는 모든 파드들의 로그가 저장
/var/log/pods/<namespace_<pod-name>_<uid>/<number>.log

// 두 위치에 파일을 중복 저장X, 파드 폴더에 있는 데이터 링크로 연결
/var/log/containers/<pod-name>_<namespace>_<container-name>_<container-id>.log

// 파드, 컨테이너 파일은 로키의 프롬테일이 이 파일들을 대신 읽기 때문에 직접 볼 일 별로 X

 

트러블 슈팅

// kubelet 상태 확인
// running 상태가 아니라면 systemctl (restart or start) kubelet 실행
1) systemctl status kubelet       

// 재시작해도 문제가 있다면 이 명령어를 통해 상세 로그를 봐야함
// 에러가 구글링해도 나오지 않는다면 VM 재부팅
// 에러가 반복되면 VM 모두 삭제하고 k8s 재설치
2) journalctl -u kubelet | tail -10

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

// containerd 상태 확인
1) systemctl status containerd
2) journalctl -u containerd | tail -10

// 노드 상태 확인
1) kubectl get nodes -o wide
2) kubectl describe node k8s-master

// Pod 상태 확인
1) kubectl get pods -A -o wide
// Event 확인 (기본값: 1h)
2-1) kubectl get events -A

// 네임스페이스랑 타입을 지정해서 이벤트 확인
// 이런 이벤트도 없다면 리소스 문제는 아니고 앱이 기동을 하면서 생기는 문제일 수 있음
2-2) kubectl events -n anotherclass-123 --types=Warning  (or Normal)

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

 

 

iptables에서 nodePort 매핑 내용 확인

iptables -t nat -L KUBE-NODEPORTS -n  | column -t

• 선언한 포트, 목적지, 주석으로 service 이름  확인가능 (이 또한 k8s가 알아서 잘 해주는 부분)

 

 

---

 

 

 

🤔 K8S 여러 질문 사항 

1. worker node를 master node에 join 시킨 다는 게 무엇인지?
A  : 마스터 노드 = 쿠버네티스 주요 컴포넌트가 돌아가는 곳
워커노드 = 우리가 만든 App들이 올라가는 공간
마스터 노드 + 워커 노드 = 쿠버네티스 클러스터
마스터 노드(vm) 생성 -> 워커 노드(vm)를 만들어서 마스터 노드에 연결
이 과정이 join이고 자원이 부족할 때마다 워커노드를 계속 join 시키는 방식으로 클러스터 규모가 커지게 됨

2. worker component와 worker node는 동일한 개념인지? worker component에 application을 올리기 위한 공간이라면, kubelet은 왜 worker component에 포함이 되지 않는지?
A : worker node = vm과 같은 단위의 개념
component = application 이기 때문에 다른 개념이다..
worker node 위에 worker 로써의 역할을 하기 위해 올라가는 모든 Application을 worker component라고 함
그러면 엄말히 말해서 kubelet Worker Component라고 할 수 있기 한데, 위 그림에게 단계적으로 나눠져 있어 Worker Component에 포함이 안되는 것처럼 보일 수 있지만 kubelet도 worker component이다..
그림의 경우 VM 영역은 사용자가 직접 설치하는 영역, 파란색 Kubernetes Cluster는 쿠버네티스 셋업을 하면 자동으로 생성되는 영역으로 이해.

3. Addon은 어디에 설치되는 것인지, 검색해보니 addon은 control plane component와 구분되는 개념인 것 같은데, 그림 상에서는 control plane component 내부에 있어서 관련되어 있는지?
A : 쿠버네티스 기본 컴포넌트들만으로는 제한 되는 기능들이 많다.
Pod의 자원(cpu,memory) 사용량을 보려면 꼭 metrics-server를 별도 addon으로 설치 필요.
이 addon은 마스터나 워커노드 모두에 설치 될 수 있으며, 어디에 설치되는지는 addon별로 기능마다 다름.
calico의 경우 각 워커노드마다 통신을 지원 해줘야하는 기능을 위해 각 워커노드 별로 Pod가 설치되는 기능도 있고, 그냥 마스터 위에서 설치되는 Pod도 있다..

 

 

---

출처

[인프런] 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2

저자 : 일프로