K8s入门基础篇：Master组件的介绍

Master组件是集群的控制平台（control plane）：  

• master 组件负责集群中的全局决策（例如，调度）  
• master 组件探测并响应集群事件（例如，当 Deployment 的实际 Pod 副本数未达到 replicas 字段的规定时，启动一个新的 Pod）  

Master组件可以运行于集群中的任何机器上。但是，为了简洁性，通常在同一台机器上运行所有的 master 组件，且不在此机器上运行用户的容器。   参考安装Kubernetes高可用。  

kube-apiserver

kube-apiserver 是 Kubernetes 的控制平面组件之一，它充当 Kubernetes API 的前端。所有来自 Kubernetes API 的请求都将发送到 kube-apiserver，然后由它转发到适当的组件进行处理。kube-apiserver 还负责执行对 Kubernetes 资源的验证、授权和准入控制，并记录所有 API 请求的审计日志。此外，kube-apiserver 还可以对外部系统进行认证和授权，以便与 Kubernetes 进行交互。  

kube-apiserver 支持同时提供 https（默认监听在 6443 端口）和 http API（默认监听在 127.0.0.1 的 8080 端口），其中 http API 是非安全接口，不做任何认证授权机制，不建议生产环境启用。两个接口提供的 REST API 格式相同，参考 Kubernetes API Reference 查看所有 API 的调用格式。

kube-apiserver 的架构

kube-apiserver 的架构是一个多层的系统，由以下组件组成：  

• HTTP Server  

kube-apiserver 作为 HTTP Server 提供 HTTP(S) 服务。所有的 API 请求都通过 HTTP(S) 进行传输，并由 kube-apiserver 处理。  

• Authentication

kube-apiserver 可以使用多种身份验证机制，包括基于令牌、证书和用户名/密码的身份验证。当客户端发起 API 请求时，kube-apiserver 会根据请求中的认证信息来验证其身份。  

• Authorization

kube-apiserver 在处理 API 请求之前会执行授权检查，以确保请求的发起者有足够的权限执行该请求。kube-apiserver 使用 RBAC(Role-Based Access Control) 机制来管理 Kubernetes 资源的授权

• Admission Control

kube-apiserver 在创建、修改和删除 Kubernetes 资源之前会执行准入控制检查，以确保这些操作符合 Kubernetes 系统的规范和限制。kube-apiserver 支持插件化的准入控制机制，可以通过插件来实现自定义的准入控制规则。

• API Registration

kube-apiserver 负责注册所有 Kubernetes API，包括 core API 和扩展 API。通过注册 API，kube-apiserver 使得所有的 Kubernetes 资源都可以通过 API 进行访问和管理。

• Etcd Storage

kube-apiserver 使用 Etcd 作为持久化存储，将 Kubernetes 资源的元数据保存在 Etcd 中。kube-apiserver 和 Etcd 之间使用一致性协议来保证数据的一致性和可靠性。

• Controller Manager

kube-apiserver 还包括一个 Controller Manager 组件，用于管理和运行 Kubernetes 的控制器。控制器是 Kubernetes 系统中的核心组件，用于确保 Kubernetes 系统的自愈能力。Controller Manager 负责监控 Kubernetes 中各种资源的状态，并根据需要执行自动化操作来保持系统的状态正确性。

• API Server Plugins

kube-apiserver 可以通过插件来扩展其功能。例如，kube-apiserver 支持 Webhook 插件，可以用于在 API 请求处理之前或之后执行自定义的操作。kube-apiserver 还支持 Admission Controller 插件，可以用于自定义准入控制规则。

kube-apiserver 的启动参数

kube-apiserver 启动时需要提供一系列参数来配置其行为。以下是一些常用的启动参数：

• --advertise-address：指定 kube-apiserver 使用的 IP 地址。
• --allow-privileged：是否允许容器运行在特权模式下。
• --authorization-mode：指定 kube-apiserver 使用的授权模式，支持 RBAC、Node、Webhook 等多种授权模式。
• --etcd-servers：指定 Etcd 的地址列表。
• --insecure-bind-address：指定 kube-apiserver 监听的 IP 地址。
• --service-account-key-file：指定服务账户的公钥文件路径。
• --tls-cert-file：指定 TLS 证书文件路径。
• --tls-private-key-file：指定 TLS 私钥文件路径

在实际使用中，通常通过 kubectl 来访问 apiserver，也可以通过 Kubernetes 各个语言的 client 库来访问 apiserver。在使用 kubectl 时，打开调试日志也可以看到每个 API 调用的格式，比如:kubectl --v=8 get pods

可通过 kubectl api-versions 和 kubectl api-resources 查询 Kubernetes API 支持的 API 版本以及资源对象。

etcd

支持一致性和高可用的名值对存储组件，Kubernetes集群的所有配置信息都存储在 etcd 中。

• Etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现，它通过Raft一致性算法处理日志复制以保证强一致性，我们可以理解它为一个高可用强一致性的服务发现存储仓库。  
• 在kubernetes集群中，etcd主要用于配置共享和服务发现  
• Etcd主要解决的是分布式系统中数据一致性的问题，而分布式系统中的数据分为控制数据和应用数据，etcd处理的数据类型为控制数据，对于很少量的应用数据也可以进行处理。  

关于 etcd 的更多信息，可参考

• ETCD
• k8s的核心组件etcd功能详解【含etcd各类参数详细说明】_k8s中etcd组件的作用_/*守护她的笑容的博客-CSDN博客
• 核心组件 - etcd - 《Kubernetes指南（Kubernetes Handbook）(202005)》 - 书栈网 · BookStack

kube-scheduler

kube-scheduler，它是 k8s 的默认调度器，负责为新创建出来的 pod寻找一个最合适的节点，这里的“最合适”指两种最优解：从集群中的所有节点中找出的全局最优解和从集群中的部分节点中找出的局部最优解。 它们分别可以解决调度器在小型和大型 k8s 集群规模上的性能问题，比如集群中有几百台主机时 kube-scheduler 采用全局最优解，当集群规模大时采用局部最优解。  

那“最合适”的含义是指什么呢？它主要是通过两种调度算法的筛选：  

• Predicate(预选)：过滤掉不满足条件的节点，选出所有可以运行该 pod 的节点。
• Scheduler(优选)：给上一步得到的结果中的每个节点打分，选出得分最高的节点为最终调度结果。

影响调度的因素有：

• 单个或多个 Pod 的资源需求
• 硬件、软件、策略的限制
• 亲和与反亲和（affinity and anti-affinity）的约定
• 数据本地化要求
• 工作负载间的相互作用

kube-scheduler详细的工作原理参考如下文章

kubernetes kube-scheduler 调度器_kube-scheduler.yaml_ghostwritten的博客-CSDN博客

kube-controller-manager

此 master 组件运行了所有的控制器

逻辑上来说，每一个控制器是一个独立的进程，但是为了降低复杂度，这些控制器都被合并运行在一个进程里。

kube-controller-manager 中包含的控制器有：

• 节点控制器： 负责监听节点停机的事件并作出对应响应
• 副本控制器： 负责为集群中每一个 副本控制器对象（Replication Controller Object）维护期望的 Pod 副本数
• 端点（Endpoints）控制器：负责为端点对象（Endpoints Object，连接 Service 和 Pod）赋值
• Service Account & Token控制器： 负责为新的名称空间创建 default Service Account 以及 API Access Token

kube-controller-manager 启动示例

kube-controller-manager \
  --enable-dynamic-provisioning=true \
  --feature-gates=AllAlpha=true \
  --horizontal-pod-autoscaler-sync-period=10s \
  --horizontal-pod-autoscaler-use-rest-clients=true \
  --node-monitor-grace-period=10s \
  --address=127.0.0.1 \
  --leader-elect=true \
  --kubeconfig=/etc/kubernetes/controller-manager.conf \
  --cluster-signing-key-file=/etc/kubernetes/pki/ca.key \
  --use-service-account-credentials=true \
  --controllers=*,bootstrapsigner,tokencleaner \
  --root-ca-file=/etc/kubernetes/pki/ca.crt \
  --service-account-private-key-file=/etc/kubernetes/pki/sa.key \
  --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt \
  --allocate-node-cidrs=true \
  --cluster-cidr=10.244.0.0/16 \
  --node-cidr-mask-size=24

核心组件 - kube-controller-manager - 《Kubernetes指南（Kubernetes Handbook）(202005)》 - 书栈网 · BookStack

kube-Controller Manager 原理_阿尔托利雅-潘德拉贡的博客-CSDN博客

cloud-controller-manager

cloud-controller-manager 中运行了与具体云基础设施供应商互动的控制器。这是 Kubernetes 1.6 版本中引入的特性。

cloud-controller-manager 只运行特定于云基础设施供应商的控制器。默认不安装 cloud-controller-manager。