*해당 내용은 edX 및 Linux Foundation에서 제공하는 강의 LinuxFoundationX LFS158x - Introduction to Kubernetes의 내용을 해석 및 요약한 것입니다.
** 본문 내 모든 이미지의 출처는 해당 강의 내 자료 입니다.

TL;DR
k8s는 크게 2가지 영역으로 구분된다: control plane node, worker node
control plane의 구성 요소(component)에는 여러가지가 있는데, 그중 API Server와 Scheduler를 다룬다.
API Server는 모든 외부 RESTful 통신의 처리를 담당하며, key-value store를 통해 state를 관리한다.
Scheduler는 API Server로 부터 현재 상태 및 요구사항을 받아 요구사항에 맞게 workload를 배정(state를 변경)한다.

High level에서, k8s는 두가지의 분리된 역할로 구분된다.

• 한개 이상의 control plane node
• 한개 이상의 worker node

Control Plane Node

control plane node는 control plane agents의 running environment를 제공한다. control plane agents는 k8s 클러스터의 상태(state)를 관리한다.
control plane components는 매우 특정한 역할을 가지고 있는 agent다.

니는 컴퓨터의 CPU와 같은 레벨의 구성요소라고 생각한다. (기능 및 역할은 다르지만)
이제 보니 메인보드 같기도...

유저들은 k8s 클러스터와 통신하기 위해서, control plane에 요청(request)을 보낸다. 이를 위한 방법으로는, CLI, Web UI 대시보드, API 등이 있다.

K8s 클러스터 운영의 핵심적인 역할을 담당하고 있기 때문에, control plane node는 항시 작동중일 수 있게 유지하는 것이 매우 중요하다. Downtime이 발생한다면, 이는 곧 클라이언트 문제 및 비즈니스적 손해로 직결되기 때문이다.

Control plane node의 fault tolerance를 확보하기위해, control plane node의 replica가 클러스터에 추가될 수 있다. (High-Availability mode)

클라우드(AWS, GCP)등에서 제공하는 관리형 K8s 서비스(EKS,GKE)는 HA mode가 기본적으로 적용되어 있다.

k8s의 state를 유지하기 위하여, 모든 클러스터 구성 데이터는 etcd라는 key-value store에 저장된다. (클라이언트 데이터는 저장되지 않는다)

Control Plane Node Components

control plane node에서 작동하는 핵심적인(필수적인) component는 다음과 같다.

• API Server
• Scheduler
• Controller Managers
• Key-Value Data Store

추가적으로,

• Container Runtime
• Node Agent
• Proxy
• (Optional) add-ons for cluster-level monitoring and logging

등이 control plane node에서 작동한다.

API Server(kube-apiserver)

유저, 관리자, 개발자등으로 부터의 외부 RESTful 요청을 검증 및 처리한다.

• 처리중에 key-value store로 부터 현재 클러스터의 state를 읽어온다.
• 처리후에 결과 상태를 key-value store에 저장한다.

API Server는 유일하게 kev-value store에 접근할 수 있는 컴포넌트다.

API Server는 커스터마이징등에 매우 유연하다. Scale out이 가능한 동시에, 커스텀 secondary API Server도 지원한다. 기존 API server를 프록시와 같이 작동시켜 모든 요청을 커스텀 API 서버로 라우팅 할 수 있다.

Scheduler(kube-scheduler)

Scheduler는 pod(container를 encapsulate하는 object)를 node(주로 worker node)에 배정하는 등, workload object를 배정하는 역할을 가지고 있다.

역할 배정등의 결정(decision)은 클러스터의 현재 state와 새로운 workload object의 요구사항(둘 다 API Server로 부터 받아온다)을 기반으로 만들어진다.

요구사항은 특정 라벨을 지닌 node에 workload 배정 (ex. disk==ssd)등과 같은 제한사항(constraints)을 포함할 수 있다.

또한, scheduler는 다음과 같은 Quality of Service(QoS) 관련 요구사항들도 관리한다.

• data locality
• affinity
• anti-affinity
• taints
• toleration
• cluster topology

본인도 아직 위의 요구사항이 정확히 무엇을 의미하는지 모른다. 눈에 담아두는 정도로 우선 넘어가도 좋을 듯 하다.

모든 클러스터 관련 정보를 수집한 이후에, 스케쥴링 알고리즘이 요구사항들을 충족하는 node 후보를 필터링하고, 우선순위(점수)를 매겨 workload를 배정할 node를 선택한다.

모든 사항이 결정되면, 결과를 API Server로 다시 전달하고, API Server는 다른 agents와 함께 해당 워크로드 배포를 위임한다.

Scheduler는 API Server와 마찬가지로 커스터마이징에 매우 유연하다. 기본적으로 scheduling policy, plugin, profile 등으로 커스터마이징을 할 수 있으며, 아예 커스텀 scheduler를 추가하는 것도 가능하다. 단, object configuration data(후에 다룰예정)에 해당 커스텀 scheduler의 이름을 포함시켜야 한다. 따로 포함시키지 않는다면 default scheduler가 선택된다.

다음글 : https://velog.io/@gwangjogong/Kubernetes-Architecture-2