【云原生技术】- Kubernetes 控制平面API Server、Etcd、Controller Manager、Scheduler、Cloud Controller Manager简介

Kubernetes 控制平面（也称为主节点或 master 节点）是 Kubernetes 集群的核心，负责整个集群的管理和协调。它由几个关键组件组成，每个组件都有其独特的作用：

1. API Server (kube-apiserver API服务器)

• 这是 Kubernetes 控制平面的前端，暴露了 Kubernetes API。
• kube-apiserver 是集群内所有服务交互的中心点，负责接收和处理 REST 请求，更新对象的状态等。

API Server 作为 Kubernetes API 的入口点，不仅是集群内部组件交互的枢纽，也是用户与集群交互的主要接口。它的设计确保了集群的声明式配置、状态管理和安全性，是 Kubernetes 架构中的关键组件。

Kubernetes 的 API Server（kube-apiserver）作为控制平面的前端，处理来自用户、内部组件以及外部系统的各种 REST 请求。这些请求涉及到 Kubernetes 集群中各种资源和对象的创建、读取、更新和删除（CRUD）操作。

（1）一些典型的 REST 请求和它们的用途

1. 创建资源:

   • 创建新的 Kubernetes 资源对象，如 Pods、Deployments、Services 等。
   • 例如，使用 POST 请求 /api/v1/namespaces/default/pods 来创建一个新的 Pod。

2. 读取资源信息:

   • 获取现有资源的信息。
   • 例如，使用 GET 请求 /api/v1/namespaces/default/pods 来获取默认命名空间中所有 Pod 的列表。

3. 更新资源:

   • 修改现有资源的状态或配置。
   • 例如，使用 PUT 请求来更新一个特定的 Deployment 的副本数量或更新其镜像。
   • 例如，更新特定 Deployment 的副本数：
     • 请求类型：PUT
     • URL 示例：/apis/apps/v1/namespaces/{namespace}/deployments/{deployment_name}
     • 请求体可能包含更新后的副本数。

4. 删除资源:

   • 删除现有的资源。
   • 例如，使用 DELETE 请求来移除一个特定的 Pod 或 Service。
   • 例如，删除一个特定的 Pod：
     • 请求类型：DELETE
     • URL 示例：/api/v1/namespaces/{namespace}/pods/{pod_name}

5. 监控资源变化:

   • 使用 watch 操作来实时监控资源状态的变化。
   • 例如，通过设置 watch 参数在 GET 请求中监听特定资源的变化。
   • 监听特定资源的变化：
     • 请求类型：GET
     • URL 示例：/api/v1/namespaces/{namespace}/pods?watch=true
     • 这个请求会持续打开，直到客户端断开连接。

6. 执行特定操作:

   • 对资源执行特定的操作，如 Pod 的缩放、回滚等。
   • 例如，通过 POST 请求到特定的 API 端点来触发 Deployment 的回滚。
   • 触发 Deployment 的回滚：
     • 请求类型：POST
     • URL 示例：/apis/apps/v1/namespaces/{namespace}/deployments/{deployment_name}/rollback
     • 请求体包含回滚的具体细节。

7. 提供认证和授权:

   • 确保对集群的访问和操作符合安全策略，如 RBAC（基于角色的访问控制）。
   • 处理请求的认证信息，决定是否授权请求的操作。

• 这通常不是通过一个特定的 API 接口完成的，而是通过 API Server 处理所有请求时的内部机制。例如，用户或服务通过证书、令牌或其他认证机制来验证身份，API Server 根据配置的角色和策略来授权请求。

  请注意，这些 URL 示例需要根据具体的 Kubernetes 环境和资源名称进行替换和调整。它们提供了一个关于如何与 Kubernetes API Server 交互的基本概念，但在实际应用中，你可能需要根据你的 Kubernetes 集群的配置和你的需求进行适当的调整。

2. Etcd

• Etcd 是一个轻量级、分布式的键值存储，用于保存所有集群数据，包括集群配置、状态和元数据。
• 它是 Kubernetes 数据的单一来源，保证了集群配置的一致性和可靠性。

etcd 作为 Kubernetes 的核心数据存储，保存了集群的各种关键数据。这包括了集群的配置、状态和元数据。以下是一些具体的例子：

（1）集群状态

集群状态涉及到 Kubernetes 集群中各种资源的当前状态信息。例如：

1. 节点状态：记录了每个节点的状态信息，如是否可用（Ready）、资源使用情况（CPU、内存）、节点上运行的 Pod 列表等。
2. Pod 状态：存储了关于 Pod 的实时状态信息，如 Pod 是否正在运行、容器的健康状况、Pod 的重启次数等。
3. ReplicaSet 和 Deployment 状态：记录了这些资源的当前状态，如期望的副本数与当前运行的副本数，更新状态等。

（2）集群元数据

元数据是关于集群资源的描述性数据，它帮助 Kubernetes 理解资源是什么以及如何管理它们。例如：

1. 资源定义：包括 Pod、Service、Deployment、StatefulSet 等资源的定义信息，如容器镜像、环境变量、卷挂载信息等。
2. 标签和注解：资源对象的标签（Labels）和注解（Annotations）信息，用于组织、标识和存储关于资源的额外信息。
3. 网络配置：如 Service 定义的网络策略、Ingress 规则等。
4. 角色和权限配置：RBAC（基于角色的访问控制）配置信息，包括角色定义、角色绑定等。

（3）集群配置

此外，etcd 还存储了集群的配置信息，例如：

1. 调度信息：包括 Pod 的调度约束、优先级等。
2. 资源配额：各个命名空间的资源配额限制。
3. 网络配置：集群的网络配置，如子网、IP 范围等。

etcd 作为一个分布式键值存储，为 Kubernetes 提供了一个可靠、一致且高效的数据存储方案，确保了集群状态的一致性和可靠性。通过这些存储的数据，Kubernetes 能够管理和调度集群中的资源，响应状态变化，以及维护集群的整体健康。

3. Controller Manager (kube-controller-manager 控制管理服务器)

• 该组件包含了多个控制器，如节点控制器、副本控制器、端点控制器等。
• 控制器负责监测集群状态，并确保当前状态与用户定义的期望状态一致。例如，如果某个节点失效，节点控制器会响应并采取行动。

kube-controller-manager 是 Kubernetes 控制平面的一个关键组件，它运行了多个控制器，这些控制器共同负责维护集群的期望状态。每个控制器监控集群的特定方面，并在必要时采取行动以纠正或调整状态。

（1）一些主要控制器及其职责

1. 节点控制器 (Node Controller):

   • 负责监测节点的状态。
   • 如果节点失效，节点控制器负责注意这种情况，并在需要时响应，例如通过标记节点状态为不可用。

2. 副本控制器 (Replication Controller):

   • 确保指定数量的 Pod 副本始终在运行。
   • 如果有 Pod 失败，副本控制器会替换它，保持应用的可用性。

3. 端点控制器 (Endpoints Controller):

   • 管理 Service 对象和 Pod 之间的连接。
   • 更新 Service 的端点信息（即与服务相关的 Pod 的 IP 地址和端口），以确保网络流量能够正确路由到后端 Pod。

4. 服务账户和令牌控制器 (Service Account & Token Controllers):

   • 为新的命名空间创建默认服务账户和 API 访问令牌。
   • 确保每个 Pod 可以通过服务账户自动访问 Kubernetes API。

5. Deployment 控制器 (Deployment Controller):

   • 管理 Deployment 对象，提供 Pod 的声明性更新。
   • 控制 Pod 和 ReplicaSet（Pod 的集合）的创建、更新和删除。

6. 状态副本集控制器 (StatefulSet Controller):

   • 用于管理 StatefulSet，它为每个 Pod 维护一个稳定的标识符和存储。
   • 确保在有状态应用中 Pod 的部署和扩缩操作有序和平稳。

7. 守护进程集控制器 (DaemonSet Controller):

   • 确保所有（或某些）节点上运行守护进程 Pod 的副本。
   • 当有新节点加入集群时，会自动在这些节点上添加 Pod。

8. 作业控制器 (Job Controller):

   • 处理 Job 对象，确保指定数量的 Pod 成功完成。

9. 资源配额控制器 (Resource Quota Controller):

   • 监控资源使用情况，确保它不超过命名空间的资源配额。

这些控制器的共同目标是确保集群始终处于预期状态。它们通过不断地监测集群状态，并在需要时自动进行调整来实现这一点。通过这种方式，Kubernetes 可以自动管理其资源，无需人工干预，从而大大提高了运维效率和系统的可靠性。

4. Scheduler (kube-scheduler 调度器)

• 调度器负责决定将新创建的 Pod 放置在哪个节点上。
• 它根据资源需求、策略约束、亲和性要求等因素选择最适合的节点。
  Kubernetes 的调度器 (kube-scheduler) 负责决定将新创建的 Pod 放置在哪个节点上。为了做出这个决策，调度器考虑了一系列复杂的因素，

（1）调度器为每个 Pod 找到最佳的节点，考虑因素可大致分为以下几类：

1. 资源需求和限制:

   • CPU 和内存需求：调度器会检查每个节点上的可用 CPU 和内存资源，确保 Pod 的资源请求（requests）能够得到满足。
   • 存储资源：调度器还考虑 Pod 需要的存储卷（如 PersistentVolumeClaims）以及存储资源的可用性。

2. 质量服务 (QoS) 约束:

   • 根据 Pod 的 QoS 级别（如 Guaranteed、Burstable、BestEffort），调度器会优先考虑确保高优先级 Pod 的资源需求。

3. 亲和性和反亲和性约束:

   • 节点亲和性：可以指定 Pod 应该（或不应该）调度到满足特定条件的节点上。
   • Pod 亲和性和反亲和性：基于其他 Pod 的位置，可以指定 Pod 之间的亲和性和反亲和性。

4. 污点和容忍度 (Taints and Tolerations):

   • 节点可以有污点，这是阻止某些 Pod 调度到这些节点的标记。
   • Pod 可以有容忍度，这是允许（或容忍）它们被调度到带有特定污点的节点上。

5. 节点选择器和标签:

   • Pod 定义中可以包含节点选择器（NodeSelector），指定 Pod 只能在具有特定标签的节点上运行。

6. 节点条件:

   • 调度器检查节点的条件，例如是否是 Ready 状态，是否存在网络或存储问题等，以确保 Pod 被调度到健康的节点上。

7. 节点的其他约束:

   • 例如，节点上可能有特定的硬件加速器（如 GPU）、特定的软件或版本要求等。

8. 调度策略和优先级:

   • 调度器还考虑 Pod 的优先级，以及根据集群管理员定义的自定义调度策略。

   通过综合考虑这些因素，调度器尝试为每个 Pod 找到最佳的节点，以确保集群资源的高效利用，同时满足 Pod 的特定需求和偏好。这是 Kubernetes 高度灵活和可配置性的关键部分之一，使其能够适应各种不同的部署需求和环境。

5. Cloud Controller Manager (kube-cloud-controller-manager)

• 这个组件让你能够将集群链接到云提供商的 API，并抽象出云提供商和 Kubernetes 之间的差异。
• 它管理云特定的控制器，如节点控制器、路由控制器、服务控制器等。

Cloud Controller Manager (CCM) 在 Kubernetes 中扮演着将集群与云服务提供商的特定功能整合的角色。它通过管理一系列特定于云的控制器来实现这一点。

（1）这些控制器包括但不限于：

1. 节点控制器 (Node Controller):

   • 管理与云服务提供商相关的节点信息。
   • 负责在节点停止响应时检查云服务提供商，以确定节点是否已被删除或终止。

2. 路由控制器 (Route Controller):

   • 为云基础设施设置路由，这在很多云服务提供商中是必要的，以使容器跨节点通信。

3. 服务控制器 (Service Controller):

   • 负责监听创建、更新和删除 Kubernetes Service 对象的请求。
   • 负责设置云服务提供商的负载均衡器，确保 Service 的外部访问。

4. 卷控制器 (Volume Controller):

   • 管理与云服务提供商相关的存储卷。
   • 负责创建、附加、挂载和删除存储卷，以及管理存储类资源。

   这些控制器允许 Kubernetes 利用云服务提供商提供的特定功能，如自动扩展节点、路由设置、负载均衡和持久存储等。通过 CCM，云特定的代码和 Kubernetes 核心代码被分离开来，使得 Kubernetes 能够更容易地适应不同的云服务提供商，同时保持核心代码的整洁和可维护性。

API Server（kube-apiserver）位于中心，作为主要的通信枢纽。Etcd 被描述为中心数据存储。控制器管理器（Controller Manager）、调度器（Scheduler）和云控制器管理器（Cloud Controller Manager）围绕着 API Server，分别指示它们在管理、调度和与云服务集成方面的角色。