Kubernetes组件

当部署完 Kubernetes 之后，便拥有了一个完整的集群。

一组工作机器，称为 节点 （node）， 会运行容器化应用程序。每个集群至少有一个工作节点。

工作节点会托管 Pod，而 Pod 就是作为应用负载的组件。 控制平面管理集群中的工作节点和 Pod。 在生产环境中，控制平面通常跨多台计算机运行， 一个集群通常运行多个节点，提供容错性和高可用性。

控制平面组件（Control Plane Components）

控制平面组件会为集群做出全局决策，比如资源的调度。 以及检测和响应集群事件，例如当不满足部署的 replicas 字段时，要启动新的 Pod。

kube-apiserver

该组件负责公开了 Kubernetes API，负责处理接受请求的工作。

kube-apiserver的最关键的作用是提供REST API接口，作为Kubernetes集群管理的核心入口点。它允许集群内外的客户端通过HTTP/HTTPS协议访问和操作集群资源，执行对Kubernetes资源的增删改查（CRUD）操作，如Pod、Service、Deployment等。这一功能使得Kubernetes集群能够被有效地管理和监控，同时也为各种客户端工具和控制平面组件提供了与集群交互的基础。

etcd

一致且高可用的键值存储，用作 Kubernetes 所有集群数据的后台数据库。

etcd最关键的作用是作为一个高可用的分布式键值存储系统，用于持久化存储和管理Kubernetes集群的关键配置数据和状态信息，确保集群状态的一致性和持久性。

kube-scheduler

负责监视新创建的、未指定运行 node的 Pods， 并选择节点来让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。

kube-scheduler在Kubernetes集群中最关键的作用是负责Pod的调度，确保Pod被合理地分配到集群中的最优节点上运行。

kube-controller-manager

 kube-controller-manager 是 控制平面 的组件， 负责运行 控制器 进程。

1. 管理和控制集群控制器

kube-controller-manager是一个核心组件，运行在Kubernetes的主节点（Master节点）上，负责管理和控制集群中的多个控制器。这些控制器各自负责不同的任务，如副本控制、节点管理、服务管理、命名空间管理等，确保集群中的资源按照预期状态运行。

2. 维护集群期望状态

kube-controller-manager通过其管理的控制器，持续监控集群内各种资源对象（如Pods、Nodes、Services等）的状态，确保集群的实际状态与用户的期望状态一致。当集群状态发生变化时，相应的控制器会采取必要的措施来恢复或维持期望状态。

3. 自动化故障恢复和自愈能力

kube-controller-manager通过管理健康检查控制器和自愈控制器等，具备自动化故障恢复和自愈能力。当检测到集群中的节点故障、Pod失败等情况时，它能够自动执行恢复操作，如重新启动失败的Pod、迁移运行在不健康节点上的Pod等，确保集群的稳定性和可用性。

部分类型的Controller：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pod 来运行这些任务直至完成
• 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）。
• 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。

cloud-controller-manager

嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中， 供你以同一进程的方式运行。 你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

Node 组件

节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境。

kubelet

kubelet 会在集群中每个节点（node）上运行。 它保证容器（containers）都运行在 Pod 中。

PodSpec是一个YAML或JSON格式的对象，它包含了Pod运行所需的所有信息，如容器配置、存储卷挂载、环境变量设置等。

kubelet 接收一组通过各类机制提供给它的 PodSpec，确保这些 PodSpec 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

kubelet通过Kubernetes API Server获取PodSpec信息。当API Server接收到创建或更新Pod的请求时，它会将PodSpec信息存储到etcd数据库中。kubelet通过监听etcd的变化或定期查询API Server来获取最新的PodSpec信息，并根据这些信息来管理和维护节点上的Pod和容器。

kube-proxy

kube-proxy 是集群中每个节点（node）上所运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。

kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

kube-proxy通过实现Service的网络代理和负载均衡功能、提供动态的服务发现和更新机制、支持网络策略实施以及具备高可用性和伸缩性等特点。

容器运行时（Container Runtime）

这个基础组件使 Kubernetes 能够有效运行容器。 它负责管理 Kubernetes 环境中容器的执行和生命周期。

容器运行时通过命名空间（Namespaces）和控制组（Cgroups）等技术实现容器的隔离性，确保容器间的资源使用互不干扰，提高系统的安全性。

Kubernetes支持多种容器运行环境，包括Docker（通过第三方解决方案）、Containerd、CRI-O以及其他多种容器运行时。

插件（Addons）

Deployment本身并不是一个插件（Addon），而是Kubernetes的一个核心资源对象。

• 声明式管理：Deployment提供了一种声明式的方式来管理Pod，用户只需声明应用程序的期望状态，Kubernetes将自动确保Pod的数量和状态与期望状态一致。
• 副本控制：Deployment通过ReplicaSet来管理Pod的副本数量，确保应用程序的高可用性。当Pod因为某种原因失败时，Deployment会自动创建新的Pod来替换它。

插件使用 Kubernetes 资源（DaemonSet、 Deployment 等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

DNS

虽然其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都有集群 DNS， 因为很多示例都需要 DNS 服务。

集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。

Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。

Web 界面（仪表盘）

Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身， 并进行故障排除。

容器资源监控

容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中， 并提供浏览这些数据的界面。

集群层面日志

集群层面日志机制负责将容器的日志数据保存到一个集中的日志存储中， 这种集中日志存储提供搜索和浏览接口。

网络插件

网络插件 是实现容器网络接口（CNI）规范的软件组件。它们负责为 Pod 分配 IP 地址，并使这些 Pod 能在集群内部相互通信。