[K8S] k8s 정리 - (2) Kubernetes Architecture - Master

 

 

Kubernetes Component

쿠버네티스를 구성하는 Component에는 크게 전체 클러스터를 관리하는 마스터(Master), 컨테이너가 배포되는 노드(Node), 에드원 노드로 총 3가지 종류의 Component가 있으며, 각각의 Component는 다음과 같은 역할을 수행한다.

 

• Master Component : 클러스터 관리 역할에 필수적인 컴포넌트
• 일반 노드 Component : Worker, 애플리케이션 작업 관리 하는 주체 역할
• addon 노드 Component : 필수는 아닌 추가 모듈 역할, ex. 네트워킹 에드온 등

 

또한 Kubernetes Master내에 속한 모듈들은 확장성을 위해 기능별로 나누어졌으며, etcd, kube-apiserver, kube-scheduler, kube-controller-manager, kublet, kube-proxy 등이 있다.

 

• etcd : key-value 타입의 노드 상태 정보 저장소
• kube-apiserver : 운영자 및 내부 노드와 통신하기 위한 인터페이스
• kube-scheduler : kube-apiserver로 부터 받은 etcd 정보를 바탕으로 최적의 노드 판단 및 할당
• kube-controller-manager : 각 노드에 배포된 Controller들을 생성하고 관리하는 역할
• CoreDNS : 클러스터 내부 리소스의 endpoint를 DNS로 매핑하여 관리하는 역할

 

 

 

Master Component

마스터 Component (Master)는 클러스터들 (worker node) 을 관리하는 역할을 수행하며, 모든 명령은 마스터의 kube-apiserver를 호출하고 worker node(node)들은 Master와 직접적으로 통신하면서 진행된다. 

 

만약 특정 노드에 명령하더라도, 노드에 바로 전달 되는 것이 아닌, Master에 우선 전달되고, Master에서 노드로 전달한다.

 

이미지 출처 : https://twofootdog.tistory.com/7

 

👉 Kubernetes Master 운영

만약 서비스 중 Master가 죽게 되면, 클러스터들을 관리 할 수 없기 때문에 Master는 3대로 구성 하여 운영하는 것이 일반적(고가용성을 위한 3중화, 리더마스터1 ,대기2) 

 

AWS의 EKS같은 경우는 Master를 AWS에서 직접 관리하기 때문에 안정성이 비교적 높음

소규모 환경에서는 Master와 Worker node를 분리하지 않고 같은 서버(인프라) 내에서 구성하기도 함

 

 

 

etcd

etcd는 kubernetes cluster의 데이터베이스 역할을 수행하며, 노드 상태 정보를 저장 및 관리한다. 

 

👉 etcd 특징

• key-value 기반 노드 상태 정보 저장소로 읽고 쓰는데 속도가 빠르다.
• 노드 상태 정보 : Container 동작 상태, Pods 정보, H/W 리소스 사용 현황 등이 있다.
• 분산 시스템에서 노드 사이의 상태를 공유하는 consensus raftd 알고리즘으로 구현됨
• etcd는 여러개로 복제되어 관리할 수 있기 때문에 안정성이 높다.
• key-value를 조회시 상태가 변경되면 체크하여 로직 실행도 가능
• 클러스터의 모든 설정, State 데이터는 etcd에 저장되어 있고, 나머지 모듈은 stateless 하게 동작하기 때문에 etcd만 잘 백업해두면 언제든지 클러스터를 복구 할 수 있다.
• etcd는 오직 kube-apiserver와 통신하고 다른 모듈은 kube-apiserver를 거쳐 etcd데이터에 접근한다.

 

 

kube-apiserver

Client (사실상 운영자) 및 내부 노드와 통신하기 위한 인터페이스로, Kubernetes의 모든 기능등을 REST API로 제공하고 해당 명령을 처리하는 역할을 수행한다.

 

👉 kube-apiserver (API Component) 의 특징

• kubectl의 요청과 내부 모듈의 요청을 처리한다.
• 클러스터가 받는 모든 API 요청의 문법, 변환 등의 유효성 검사 및 처리하는 핵심 모듈
• 선언된 state를 key-value로 etcd 저장소에 저장하고, 저장된 상태를 조회
  apiserver 실행(요청)시 다른 컴포넌트들과 소통하면서 통신  (ex. etcd에게 노드들의 상태 정보를 얻어오고, api가 다시 scheduler에게 전달)
• 수평적으로 확장 가능하게 설계되어 서버 여러대서 운용 가능

 

 

kube-scheduler

kube-apiserver로 부터 받은 etcd 정보를 바탕하여 최적의 노드 (리소스 상황에 맞는)를 판단하고 할당하는 역할

 

👉 kube-scheduler의 특징

• scheduler가 판단 및 할당 시 고려하는 정보는 자원, 하드웨어 요구사항, 파드들 동일 노드 존재 필요 여부(어피티니 조건), 다양한 노드로 분산 필요 여부 (안티 어피니티 조건) 등 이 있다. 
• scheduler가 판단 후 적합한 실행 노드의 kubelet에 명령을 보낸다.

 

 

kube-controller-manager

kube-controller-manager는 각 노드에 배포된 Controller들 (Replica Controller, Service Controller, Volume Controller, Node Controller 등)을 생성하고 관리 (ex. 파드의 갯수 보장)하는 역할

 

👉 kube-controller-manager 특징

• Kubernetes에 있는 모든 object, 컨트롤러(복제, 배포, 상태, 크론) 등 상태를 관리
  ex) 동작중인 Container 중 1개가 다운될시 API에게 요청 보내고 API가 Scheduler를 통해 다시 노드 할당 및 생성
  ex) Replica Controller : 파드(k8s의 가장 작은 단위)를 관찰하며 개수를 보장해주는 역할

• 새로운 컨트롤러 사용시 컨트롤러에 해당하는 구조체를 만들고, 이 구조체를 kube-controller-manager에서 관리하는 Queue에 넣어서 실행

 

 

DNS(coreDNS)

coreDNS는 리소스의 endpoint를 DNS로 매핑하여 관리하는 역할을 수행한다.

 

👉 CoreDNS 특징

• Pod나 Service가 부여 받은 IP는 기본적으로 동적으로 생성되는 리소스이기 때문에 생성/삭제에 따라 IP주소가 변경된다
• 리소스의 변경되는 IP주소의 내부 위치정보(endpoint)를 DNS로 매핑하여 관리한다
• 최종적으로 새로운 리소스가 생성되더라도, DNS 이름 기반 리소스로 접근 가능

 

 

마무리 

이번 글에서는 Kuberenetes의 Architecture 중 Master Component의 구성에 대해 알아보았다. 다음 시간엔 Worker Node와, addon Node의 구성에 대해 알아보려고 한다.

 

이미지 출처 : https://www.youtube.com/watch?v=Iue9TC13vPQ