【云原生技术】- Kubernetes 控制平面API Server、Etcd、Controller Manager、Scheduler、Cloud Controller Manager简介
Kubernetes 控制平面API Server、Etcd、Controller Manager、Scheduler、Cloud Controller Manager简介
- 1. API Server (kube-apiserver API服务器)
-
- （1）一些典型的 REST 请求和它们的用途
- 2. Etcd
-
- （1）集群状态
- （2）集群元数据
- （3）集群配置
- 3. Controller Manager (kube-controller-manager 控制管理服务器)
-
- （1）一些主要控制器及其职责
- 4. Scheduler (kube-scheduler 调度器)
-
- （1）调度器为每个 Pod 找到最佳的节点，考虑因素可大致分为以下几类：
- 5. Cloud Controller Manager (kube-cloud-controller-manager)
-
- （1）这些控制器包括但不限于：
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 请求和它们的用途
-
创建资源:
- 创建新的 Kubernetes 资源对象，如 Pods、Deployments、Services 等。
- 例如，使用 POST 请求
/api/v1/namespaces/default/pods来创建一个新的 Pod。
-
读取资源信息:
- 获取现有资源的信息。
- 例如，使用 GET 请求
/api/v1/namespaces/default/pods来获取默认命名空间中所有 Pod 的列表。
-
更新资源:
- 修改现有资源的状态或配置。
- 例如，使用 PUT 请求来更新一个特定的 Deployment 的副本数量或更新其镜像。
- 例如，更新特定 Deployment 的副本数：
- 请求类型：
PUT - URL 示例：
/apis/apps/v1/namespaces/{namespace}/deployments/{deployment_name} - 请求体可能包含更新后的副本数。
- 请求类型：
-
删除资源:
- 删除现有的资源。
- 例如，使用 DELETE 请求来移除一个特定的 Pod 或 Service。
- 例如，删除一个特定的 Pod：
- 请求类型：
DELETE - URL 示例：
/api/v1/namespaces/{namespace}/pods/{pod_name}
- 请求类型：
-
监控资源变化:
- 使用 watch 操作来实时监控资源状态的变化。
- 例如，通过设置 watch 参数在 GET 请求中监听特定资源的变化。
- 监听特定资源的变化：
- 请求类型：
GET - URL 示例：
/api/v1/namespaces/{namespace}/pods?watch=true - 这个请求会持续打开，直到客户端断开连接。
- 请求类型：
-
执行特定操作:
- 对资源执行特定的操作，如 Pod 的缩放、回滚等。
- 例如，通过 POST 请求到特定的 API 端点来触发 Deployment 的回滚。
- 触发 Deployment 的回滚：
- 请求类型：
POST - URL 示例：
/apis/apps/v1/namespaces/{namespace}/deployments/{deployment_name}/rollback - 请求体包含回滚的具体细节。
- 请求类型：
-
提供认证和授权:
- 确保对集群的访问和操作符合安全策略，如 RBAC（基于角色的访问控制）。
- 处理请求的认证信息，决定是否授权请求的操作。
-
这通常不是通过一个特定的 API 接口完成的，而是通过 API Server 处理所有请求时的内部机制。例如，用户或服务通过证书、令牌或其他认证机制来验证身份，API Server 根据配置的角色和策略来授权请求。
请注意，这些 URL 示例需要根据具体的 Kubernetes 环境和资源名称进行替换和调整。它们提供了一个关于如何与 Kubernetes API Server 交互的基本概念，但在实际应用中，你可能需要根据你的 Kubernetes 集群的配置和你的需求进行适当的调整。
2. Etcd
- Etcd 是一个轻量级、分布式的键值存储，用于保存所有集群数据，包括集群配置、状态和元数据。
- 它是 Kubernetes 数据的单一来源，保证了集群配置的一致性和可靠性。
etcd 作为 Kubernetes 的核心数据存储，保存了集群的各种关键数据。这包括了集群的配置、状态和元数据。以下是一些具体的例子：
（1）集群状态
集群状态涉及到 Kubernetes 集群中各种资源的当前状态信息。例如：
- 节点状态：记录了每个节点的状态信息，如是否可用（Ready）、资源使用情况（CPU、内存）、节点上运行的 Pod 列表等。
- Pod 状态：存储了关于 Pod 的实时状态信息，如 Pod 是否正在运行、容器的健康状况、Pod 的重启次数等。
- ReplicaSet 和 Deployment 状态：记录了这些资源的当前状态，如期望的副本数与当前运行的副本数，更新状态等。
（2）集群元数据
元数据是关于集群资源的描述性数据，它帮助 Kubernetes 理解资源是什么以及如何管理它们。例如：
- 资源定义：包括 Pod、Service、Deployment、StatefulSet 等资源的定义信息，如容器镜像、环境变量、卷挂载信息等。
- 标签和注解：资源对象的标签（Labels）和注解（Annotations）信息，用于组织、标识和存储关于资源的额外信息。
- 网络配置：如 Service 定义的网络策略、Ingress 规则等。
- 角色和权限配置：RBAC（基于角色的访问控制）配置信息，包括角色定义、角色绑定等。
（3）集群配置
此外，etcd 还存储了集群的配置信息，例如：
- 调度信息：包括 Pod 的调度约束、优先级等。
- 资源配额：各个命名空间的资源配额限制。
- 网络配置：集群的网络配置，如子网、IP 范围等。
etcd 作为一个分布式键值存储，为 Kubernetes 提供了一个可靠、一致且高效的数据存储方案，确保了集群状态的一致性和可靠性。通过这些存储的数据，Kubernetes 能够管理和调度集群中的资源，响应状态变化，以及维护集群的整体健康。
3. Controller Manager (kube-controller-manager 控制管理服务器)
- 该组件包含了多个控制器，如节点控制器、副本控制器、端点控制器等。
- 控制器负责监测集群状态，并确保当前状态与用户定义的期望状态一致。例如，如果某个节点失效，节点控制器会响应并采取行动。
kube-controller-manager 是 Kubernetes 控制平面的一个关键组件，它运行了多个控制器，这些控制器共同负责维护集群的期望状态。每个控制器监控集群的特定方面，并在必要时采取行动以纠正或调整状态。
（1）一些主要控制器及其职责
-
节点控制器 (Node Controller):
- 负责监测节点的状态。
- 如果节点失效，节点控制器负责注意这种情况，并在需要时响应，例如通过标记节点状态为不可用。
-
副本控制器 (Replication Controller):
- 确保指定数量的 Pod 副本始终在运行。
- 如果有 Pod 失败，副本控制器会替换它，保持应用的可用性。
-
端点控制器 (Endpoints Controller):
- 管理 Service 对象和 Pod 之间的连接。
- 更新 Service 的端点信息（即与服务相关的 Pod 的 IP 地址和端口），以确保网络流量能够正确路由到后端 Pod。
-
服务账户和令牌控制器 (Service Account & Token Controllers):
- 为新的命名空间创建默认服务账户和 API 访问令牌。
- 确保每个 Pod 可以通过服务账户自动访问 Kubernetes API。
-
Deployment 控制器 (Deployment Controller):
- 管理 Deployment 对象，提供 Pod 的声明性更新。
- 控制 Pod 和 ReplicaSet（Pod 的集合）的创建、更新和删除。
-
状态副本集控制器 (StatefulSet Controller):
- 用于管理 StatefulSet，它为每个 Pod 维护一个稳定的标识符和存储。
- 确保在有状态应用中 Pod 的部署和扩缩操作有序和平稳。
-
守护进程集控制器 (DaemonSet Controller):
- 确保所有（或某些）节点上运行守护进程 Pod 的副本。
- 当有新节点加入集群时，会自动在这些节点上添加 Pod。
-
作业控制器 (Job Controller):
- 处理 Job 对象，确保指定数量的 Pod 成功完成。
-
资源配额控制器 (Resource Quota Controller):
- 监控资源使用情况，确保它不超过命名空间的资源配额。
这些控制器的共同目标是确保集群始终处于预期状态。它们通过不断地监测集群状态，并在需要时自动进行调整来实现这一点。通过这种方式，Kubernetes 可以自动管理其资源，无需人工干预，从而大大提高了运维效率和系统的可靠性。
4. Scheduler (kube-scheduler 调度器)
- 调度器负责决定将新创建的 Pod 放置在哪个节点上。
- 它根据资源需求、策略约束、亲和性要求等因素选择最适合的节点。
Kubernetes 的调度器 (kube-scheduler) 负责决定将新创建的 Pod 放置在哪个节点上。为了做出这个决策，调度器考虑了一系列复杂的因素，
（1）调度器为每个 Pod 找到最佳的节点，考虑因素可大致分为以下几类：
-
资源需求和限制:
- CPU 和内存需求：调度器会检查每个节点上的可用 CPU 和内存资源，确保 Pod 的资源请求（requests）能够得到满足。
- 存储资源：调度器还考虑 Pod 需要的存储卷（如 PersistentVolumeClaims）以及存储资源的可用性。
-
质量服务 (QoS) 约束:
- 根据 Pod 的 QoS 级别（如 Guaranteed、Burstable、BestEffort），调度器会优先考虑确保高优先级 Pod 的资源需求。
-
亲和性和反亲和性约束:
- 节点亲和性：可以指定 Pod 应该（或不应该）调度到满足特定条件的节点上。
- Pod 亲和性和反亲和性：基于其他 Pod 的位置，可以指定 Pod 之间的亲和性和反亲和性。
-
污点和容忍度 (Taints and Tolerations):
- 节点可以有污点，这是阻止某些 Pod 调度到这些节点的标记。
- Pod 可以有容忍度，这是允许（或容忍）它们被调度到带有特定污点的节点上。
-
节点选择器和标签:
- Pod 定义中可以包含节点选择器（NodeSelector），指定 Pod 只能在具有特定标签的节点上运行。
-
节点条件:
- 调度器检查节点的条件，例如是否是 Ready 状态，是否存在网络或存储问题等，以确保 Pod 被调度到健康的节点上。
-
节点的其他约束:
- 例如，节点上可能有特定的硬件加速器（如 GPU）、特定的软件或版本要求等。
-
调度策略和优先级:
- 调度器还考虑 Pod 的优先级，以及根据集群管理员定义的自定义调度策略。
通过综合考虑这些因素，调度器尝试为每个 Pod 找到最佳的节点，以确保集群资源的高效利用，同时满足 Pod 的特定需求和偏好。这是 Kubernetes 高度灵活和可配置性的关键部分之一，使其能够适应各种不同的部署需求和环境。
5. Cloud Controller Manager (kube-cloud-controller-manager)
- 这个组件让你能够将集群链接到云提供商的 API，并抽象出云提供商和 Kubernetes 之间的差异。
- 它管理云特定的控制器，如节点控制器、路由控制器、服务控制器等。
Cloud Controller Manager (CCM) 在 Kubernetes 中扮演着将集群与云服务提供商的特定功能整合的角色。它通过管理一系列特定于云的控制器来实现这一点。
（1）这些控制器包括但不限于：
-
节点控制器 (Node Controller):
- 管理与云服务提供商相关的节点信息。
- 负责在节点停止响应时检查云服务提供商，以确定节点是否已被删除或终止。
-
路由控制器 (Route Controller):
- 为云基础设施设置路由，这在很多云服务提供商中是必要的，以使容器跨节点通信。
-
服务控制器 (Service Controller):
- 负责监听创建、更新和删除 Kubernetes Service 对象的请求。
- 负责设置云服务提供商的负载均衡器，确保 Service 的外部访问。
-
卷控制器 (Volume Controller):
- 管理与云服务提供商相关的存储卷。
- 负责创建、附加、挂载和删除存储卷，以及管理存储类资源。
这些控制器允许 Kubernetes 利用云服务提供商提供的特定功能，如自动扩展节点、路由设置、负载均衡和持久存储等。通过 CCM，云特定的代码和 Kubernetes 核心代码被分离开来，使得 Kubernetes 能够更容易地适应不同的云服务提供商，同时保持核心代码的整洁和可维护性。
API Server（kube-apiserver）位于中心，作为主要的通信枢纽。Etcd 被描述为中心数据存储。控制器管理器（Controller Manager）、调度器（Scheduler）和云控制器管理器（Cloud Controller Manager）围绕着 API Server，分别指示它们在管理、调度和与云服务集成方面的角色。