前言

昨日的延伸问题：如何跟 k8s 丛集互动？

主要就是透过今天要讲的 Control Plane Components 来达成

Control Plane Components

Control Plane 负责管理所有 Node Components,

主要由以下几个元件组成：

kube-api-server

Control Plane 元件中, kube-api-server 负责处理所有来自客户端服务发来的请求

属於 Control Plane 对外的接口, 验证所有客户端的请求

然後交给对应的处理元件(例如：kube-scheduler)继续处理

处理流程如下图:

kube-scheduler

Control Plane 元件中, kube-scheduler 负责做分派任务给 Node 来执行

假设今天要新增一个 Container, kube-scheduler 会依序当下资源状态,

决定要分派给哪个 Node 的 kubelet 做执行

处理流程如下图：

kube-controller-manager

Control Plane 元件中, kube-controller-manager 负责侦测 k8s 丛集的状态变化

其中可以分成以下几种类别：

1 侦测 Node 关闭的状态

2 侦测 Job 状态： 察看 Job 物件中的一次性任务, 产生 Pod 去完成这个 Job

3 广播端点状态： 更新 cluster 中的 Service, Pod 状态

4 Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.

处理流程如下：

etcd

Control Plane 元件中, etcd 是一个 key-value 的储存资料, 用来纪录 k8s 丛集的运行状态

kube-controller-manager 以及 kube-scheduler 都需要透过 etcd 维持运作

另外 etcd 属於分散式存储, 因此再一个 k8s 丛集中可以同时有多个 Control Plane 元件

cloud-controller-manager

Control Plane 元件中, cloud-controller-manager 是一个内嵌云端规格操作的元件

cloud-controller-manager 让 k8s 丛集可以连接到云服务商的操作 api

用来隔离 k8s 元件操作与云服务商的 api, 降低 k8s 元件与云服务商的 api 的相依性

特别要注意的是, 如果 k8s 丛集运行的环境是本机电脑没有连结到云服务商(例如： minikube local),

则不会有这个元件

後记

一般的 k8s 丛集为了确保高可用性, 通常会有至少2个以上的 Control Plane 如下图

其中 kube-api-server 与 etcd 都可以做平衡负载, 因为 etcd 是属於分散式存储

所以多个 Control Plane 仍然是共享一个丛集状态