k8s组件（详细版）

参考kubernetes官方文档：Kubernetes 组件 | Kubernetes

一、Control Plane Components

The control plane's components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events (for example, starting up a new pod when a deployment's replicas field is unsatisfied).

Control plane components can be run on any machine in the cluster. However, for simplicity, set up scripts typically start all control plane components on the same machine, and do not run user containers on this machine. See Creating Highly Available clusters with kubeadm for an example control plane setup that runs across multiple machines.

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

控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。

1、kube-apiserver

The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane.

The main implementation of a Kubernetes API server is kube-apiserver. kube-apiserver is designed to scale horizontally—that is, it scales by deploying more instances. You can run several instances of kube-apiserver and balance traffic between those instances.

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 旨在水平扩展，即通过部署更多实例来扩展。您可以运行多个 kube-apiserver 实例并平衡这些实例之间的流量。

2、etcd

Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.

If your Kubernetes cluster uses etcd as its backing store, make sure you have a back up plan for the data.

You can find in-depth information about etcd in the official documentation.

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

如果您的 Kubernetes 集群使用 etcd 作为其后备存储，请确保您有数据备份计划。

3、kube-scheduler

Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on.

Factors taken into account for scheduling decisions include: individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines.

控制平面组件，用于监视新创建的没有分配节点的 Pod，并选择一个节点供它们运行。

调度决策考虑的因素包括：个体和集体资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据局部性、工作负载间干扰和最后期限。

4、kube-controller-manager

Control plane component that runs controller processes.

Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.

There are many different types of controllers. Some examples of them are:

- Node controller: Responsible for noticing and responding when nodes go down.
- Job controller: Watches for Job objects that represent one-off tasks, then creates Pods to run those tasks to completion.

- EndpointSlice controller: Populates EndpointSlice objects (to provide a link between Services and Pods).

- ServiceAccount controller: Create default ServiceAccounts for new namespaces.
The above is not an exhaustive list.

从逻辑上讲，每个控制器都是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件并在单个进程中运行。

有许多不同类型的控制器。其中一些例子是：

节点控制器：负责在节点出现故障时进行通知并做出响应。
作业控制器：监视代表一次性任务的作业对象，然后创建 Pod 来运行这些任务直至完成。
EndpointSlice 控制器：填充 EndpointSlice 对象（以提供服务和 Pod 之间的链接）。
ServiceAccount 控制器：为新命名空间创建默认 ServiceAccount。
以上并不是详尽的列表。

5.cloud-controller-manager

A Kubernetes control plane component that embeds cloud-specific control logic. The cloud controller manager lets you link your cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster.

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

The cloud-controller-manager only runs controllers that are specific to your cloud provider. If you are running Kubernetes on your own premises, or in a learning environment inside your own PC, the cluster does not have a cloud controller manager.

云控制器管理器仅运行特定于您的云提供商的控制器。如果您在自己的场所或自己的 PC 内的学习环境中运行 Kubernetes，则集群没有云控制器管理器。

As with the kube-controller-manager, the cloud-controller-manager combines several logically independent control loops into a single binary that you run as a single process. You can scale horizontally (run more than one copy) to improve performance or to help tolerate failures.

与 kube-controller-manager 一样，cloud-controller-manager 将多个逻辑上独立的控制循环组合到一个二进制文件中，并作为单个进程运行。您可以水平扩展（运行多个副本）以提高性能或帮助容忍故障。

The following controllers can have cloud provider dependencies:

• Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding
• Route controller: For setting up routes in the underlying cloud infrastructure
• Service controller: For creating, updating and deleting cloud provider load balancers

• 节点控制器（Node Controller）：用于在节点终止响应后检查云提供商以确定节点是否已被删除
• 路由控制器（Route Controller）：用于在底层云基础架构中设置路由
• 服务控制器（Service Controller）：用于创建、更新和删除云提供商负载均衡器

二、Node Components

Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.

1、kubelet

An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod.

The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn't manage containers which were not created by Kubernetes.

kubelet 采用通过各种机制提供的一组 PodSpec，并确保这些 PodSpec 中描述的容器正在运行且健康。 kubelet 不管理不是由 Kubernetes 创建的容器。

2、kube-proxy

kube-proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept.

kube-proxy maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.

kube-proxy uses the operating system packet filtering layer if there is one and it's available. Otherwise, kube-proxy forwards the traffic itself.

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

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

kube-proxy 使用操作系统数据包过滤层（如果有且可用）。否则，kube-proxy 会自行转发流量。

3、Container runtime

A fundamental component that empowers Kubernetes to run containers effectively. It is responsible for managing the execution and lifecycle of containers within the Kubernetes environment.

Kubernetes supports container runtimes such as containerd, CRI-O, and any other implementation of the Kubernetes CRI (Container Runtime Interface).

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

Kubernetes 支持容器运行时，例如 containerd、CRI-O 以及 Kubernetes CRI（容器运行时接口）的任何其他实现。

三、Addons

Addons use Kubernetes resources (DaemonSet, Deployment, etc) to implement cluster features. Because these are providing cluster-level features, namespaced resources for addons belong within the kube-system namespace.

插件使用 Kubernetes 资源（DaemonSet、Deployment 等）来实现集群功能。由于它们提供集群级功能，因此插件的命名空间资源属于 kube-system 命名空间。

Selected addons are described below; for an extended list of available addons, please see Addons.

1、DNS

While the other addons are not strictly required, all Kubernetes clusters should have cluster DNS, as many examples rely on it.

Cluster DNS is a DNS server, in addition to the other DNS server(s) in your environment, which serves DNS records for Kubernetes services.

Containers started by Kubernetes automatically include this DNS server in their DNS searches.

集群 DNS 是环境中其他 DNS 服务器之外的 DNS 服务器，它为 Kubernetes 服务提供 DNS 记录。

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

2、Web UI(Dashboard)

Dashboard is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself.

3、Container Resource Monitoring

Container Resource Monitoring records generic time-series metrics about containers in a central database, and provides a UI for browsing that data.

容器资源监控在中央数据库中记录有关容器的通用时间序列指标，并提供用于浏览该数据的 UI。

4、Cluster-level Logging

A cluster-level logging mechanism is responsible for saving container logs to a central log store with search/browsing interface.

集群级日志记录机制负责将容器日志保存到具有搜索/浏览界面的中央日志存储中。

5、Network Plugins

Network plugins are software components that implement the container network interface (CNI) specification. They are responsible for allocating IP addresses to pods and enabling them to communicate with each other within the cluster.

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