Kubernetes 컴포넌트
- 쿠버네티스 클러스터는 마스터 노드와 워커 노드로 구성
- 마스터 노드에는 클러스터 관리 및 기능 실행을 위한 관리 컴포넌트들이 위치
- 워커 노드에는 컨테이너화된 애플리케이션을 실행하는 시스템, Api Server와 통신하기 위한 Kubelet, Kube-Proxy가 위치
Master Node 컴포넌트
Master Node는 관리, 계획, 스케줄링, 모니터링을 담당
다음과 같은 컴포넌트로 구성되어 있다
- 클러스터의 정보를 저장하는 엣시디 ( etcd ) 라는 고가용 키 값 스토어
- 어떤 워커 노드에 컨테이너를 배포할지 결정하는 스케줄러
- 컨트롤러들을 생성하고 관리하는 컨트롤러 매니저
- 모든 클라이언트 및 컴포넌트로부터 요청을 받아 수행해주는 Kube Api Server
- Kubeadm을 이용해 Kubernetes를 설치하면, Master 노드에도 Pod를 관리하는 Kubelet과 Pod & Service의 네트워크 동작을 관리하는 Kube-Proxy가 존재한다
모든 컴포넌트의 의사 소통은 Kube Api Server를 통해 한다
- Kubernetes는 모든 명령과 통신을 API를 통해서 한다
모든 컴포넌트는 기본적으로 쿠버네티스 릴리스 페이지에서 바이너리 파일을 다운 받아 Linux Daemon으로 설치하는 방법과 Kubeadm을 이용해 Static Pod로 배포하는 방법이 있다. 이외에도 여러 방법이 있다
- Kubeadm을 이용해 Kubernetes를 설치하면, 각 Master Node 컴포넌트는 ApiServer 없이 Kubelet Daemon에 의해 관리되는 Static Pod로 배포된다
| 컴포넌트 | 형태 | Node |
|---|---|---|
| Api Server | Static Pod | Master Node |
| Kube Scheduler | Static Pod | Master Node |
| Controller Manager | Static Pod | Master Node |
| ETCD | Static Pod | Master Node |
| Kubelet | Linux Daemon | Master Node, Worker Node |
| KubeProxy | DaemonSet | Master Node, Worker Node |
물론 Kubeadm을 통해 클러스터를 구성할 때, Daemon으로 설치한 컴포넌트를 사용하는 방법도 있다
- Kubeadm init 시 --control-plane-endpoint 옵션을 통해 직접 설치한 Kube Api Server의 엔드포인트를 지정하면 된다.
ETCD
ETCD란?
-
etcd는 분산되고, 신뢰성이 높은 key value 스토어 이다. 쿠버네티스 노드, 포트, 계정, 역할 등 클러스터 정보를 저장한다
-
클러스터에 변화가 있을 때 etcd가 업데이트 된다. etcd 가 업데이트 될때 해당 작업이 완료되는 것
Key-Value 스토어?
- key - value 스토어는 문서나 페이지 형태로 정보를 저장. 한 파일의 변화가 다른 파일에 영향을 주지 않으며, 파일의 구조에 제약이 없다
- 단순히 키와 값을 저장하고 회수할 수 있으며, 데이터가 복잡해지면 json 데이터 포맷 같은 걸 사용
HA 구성 ETCD
- 고가용성 구성에서는 마스터 노드가 여러개 이며, etcd도 여러개 일 것이다. 이때, 각 etcd 인스턴스들이 서로에 대해 알아야 한다. 매개변수 설정을 통해서 말이다
ETCD 설치 방법
-
바이너리 압축 파일을 다운 받아 설치하고, ETCD 서비스를 실행하는 방법
- 실행하면 2379 포트를 듣는 서비스가 시작된다
- 실행시 ETCD 제어 클라이언트가 같이 설치된다 → ETCD 에 대한 명령 실행 → etcdctl
-
kubeadm : kube system 네임스페이스에 포함된 파드로서 etcd를 배포. 이 etcd 파드를 접속해서 데이터를 가져오려면 아래와 같이 사용
kubectl exec etcd-master -n kube-system etcdctl get / --prefix -keys-only # etcd 파드에 접근하여 key만 가져오게 명령을 내린다- k8s 는 특정 디렉토리 구조에 데이터를 저장. 루트 디렉토리는 registry 이다. 이 아래에 k8s 구성체들이 존재
바이너리란?
- 바이너리 패키지란 프로그램 설치와 관리를 용이하게 하기 위해 개발된 패키지
- 바이너리란 실행 가능한 형식의 데이터 파일
ETCD 버전
-
ETCD 는 2013년에 처음 출시
-
2015년에 REFT 알고리즘을 이용하는 리뉴얼된 V2 출시
-
2017년에 V3 출시
버전 확인 명령어 → 첫번째 줄은 etcd 유틸리티 버전, 두번째 줄은 api 버전
./etcdctl --versionETCD API 버전 변경을 위한 명령어
export ETCDCTL_API=3간단한 etcd 명령어
# 버전 2
etcdctl backup # 백업
etcdctl cluster-health # 클러스터 상태 정보
etcdctl mk
etcdctl mkdir
etcdctl set
# 버전 3
etcdctl snapshot save
etcdctl endpoing health
etcdctl get
etcdctl put
!!!
export ETCDCTL_API=3Controller Manager
Controller Manager란?
쿠버네티스의 다양한 컨트롤러를 생성하고 관리한다
- 쿠버네티스의 컨트롤러는 시스템 내 다양한 구성 요소의 상태를 모니터링하고,시스템 전체를 원하는 기능 상태로 제어한다
- Relicaset 상태를 모니터링하여 set에 설정된 Pod 개수를 유지하는 ReplicaSet Controller, 노드를 모니터링하여 관리하는 Node Controller 등 다양한 컨트롤러를 관리한다
Node Controller 모니터링 과정
- kubelet 으로부터 받은 노드의 상태를 node controller 에서 수집하여 모니터링한다. 일정 주기마다 노드의 상태를 동기화한다. 만약 일정 시간 상태 정보가 안오면 노드가 작동하지 못한다고 상태를 변경하고, 5분 뒤 파드를 삭제하고, 다른 노드에 다시 배포한다.
- kubelet에서 node status update frequency 마다 노드의 상태를 apiserver에 전달 → node controller에게 전달
- node 컨트롤러는 api server 를 통해 노드의 상태 모니터링 → node monitor period 마다 노드의 상태를 검사하여, apiserver에 전달
- 노드가 작동을 중지하면, node monitor grace period 에 설정한 시간 후 노드의 상태를 Not Ready로 변경
- 해당 노드가 Not Ready라면, pod-eviction-timeout 에 설정한 시간만큼 대기한 후, 해당 노드에 배포된 Pod를 삭제하고, 다른 노드에 다시 배포한다
Node Controller 설정
-
node monitor period : node 컨트롤러에서 노드 상태를 동기화 하는 시간
- 주기마다 노드의 상태를 체크하여 apiserver에 전달
- 기본 5초 / etcd분리시 20초
-
node monitor grace period : node 로부터 해당 시간 동안 응답 받지 못하면, 상태를 not ready로 변경 시킨다
- 기본 40초 / 제안 20초
-
pod-eviction-timeout : 기본이 5분, 노드에서 pod 를 삭제하기 위해 대기하는 시간
kubelet 설정
- node status update frequency : 해당 주기마다 api server에 노드의 상태를 게시
- 기본 4초
만약 기본 구성이라면 노드의 가용성 확보에 5분 40초가 걸린다
Controller Manager 설치
- 모든 컨트롤러는 Kubenetes Controller Manager라는 하나의 프로세스로 패키지화 되어있다. 따라서 Controller Manager를 설치하면, 다른 컨트롤러도 설치된다
-
Kube-Controller-manager를 쿠버네티스 릴리스 페이지에서 다운 받아서 설치
- 설치 과정에서 위에서 다룬 옵션 및 기타 옵션 설정 가능
- /etc/systemd/system/kube-controller-manager.service 에서 설정 확인 가능
- ps -aux | grep kube-controller-manager로도 옵션 확인 가능
- ps -aux 란 시스템의 동작중인 모든 프로세스를 소유자 정보와 함께 다양한 정보를 출력하는 것으로, grep을 통해 특정 시스템에 대한 정보만 출력 가능하다.
-
Kubeadm 으로 설치
- Kube-System 네임스페이스에 파드로서 배포
- /etc/kubernetes/manifests/kube-controller-manager.yaml 에서 옵션 확인 및 설정 가능
Kube Scheduler
Kube Scheduler란?
어떤 포드가 어떤 노드에 들어갈지를 결정한다
- 스케줄러는 노드가 할당되지 않은 새로 생성된 파드를 감시하여, 스케줄링을 통해 해당 파드가 실행될 최상의 노드를 찾는다
스케줄링이란 Kubelet이 Pod를 실행할 수 있도록, 파드가 노드에 적합한지 확인하는 과정
주의! 노드에 파드를 생성하는 것은 Kube Scheduler가 아닌 Kubelet의 일이다! Scheduler는 파드 실행에 적합한 노드를 선택해서 할당해주는 일만 한다!
노드를 선택하는 작업
-
필터링
- 파드를 스케줄링 할 수 있는 노드 셋을 찾는 단계
- 필터를 통해 후보 노드가 파드를 실행하기에 조건을 충족시키는지 검사한다
- 필터링 단계가 끝나면 노드 목록에는 파드 실행이 가능한 노드들로만 구성되어 있으며, 노드 목록이 비어있다면 해당 파드는 스케줄링이 불가능 한 것이다
-
스코어링
- 목록에 남아있는 노드의 순위를 지정하여, 파드 실행에 가장 적합한 노드를 선택하기 위해 노드에 대한 점수를 지정한다
-
할당
- Kube Scheduler는 파드를 순위가 가장 높은 노드에 할당한다
- 노드의 점수가 같다면, 임의로 배정한다
Kubelet & Kube-Proxy in Master Node
참고 : https://stackoverflow.com/questions/58481709/why-kubelet-is-running-on-kubernetes-master-node
참고 : https://velog.io/@squarebird/Worker-Node-Kubelet
-
Kubelet은 Pod를 관리하는 Kubernetes Agent이다. Kubeadm을 이용해 Kubernetes를 설치하게되면, ETCD / Api Server 등 Master Node Component 들이 Kubelet Daemon에 의해 Static Pod로 배포되어지고, 관리되어진다. 따라서 Master Node에도 Kubelet이 존재한다
- Kubelet은 Pod가 아닌 리눅스 Daemon으로 동작한다
[master@userhong]$ systemctl status kubelet ● kubelet.service - kubelet: The Kubernetes Node Agent Loaded: loaded (/usr/lib/systemd/system/kubelet.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/kubelet.service.d └─10-kubeadm.conf Active: active (running) Docs: https://kubernetes.io/docs/ Main PID: ~~~~ (kubelet) Tasks: ~~ Memory: 135.2M CGroup: /system.slice/kubelet.service └─~~~~ /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --- Kubelet은 Pod를 관리해주는 Agent이기에 Daemon으로 존재해야 한다. Kubelet이 Pod 형태로 존재하면, 해당 Pod를 관리해줄 것이 없기 때문이다
-
Master Node는 일반적으로 클러스터 내의 Worker Node로도 구성되어진다. 따라서 Master Node에도 Kubelet, Kube-Proxy, Container Runtime 이 실행된다
멋진 엔지니어가 될 때까지