部署 Kubernetes 时，您将获得一个集群。您在部署时获得的集群将包含一个或多个称为节点的工作机器（虚拟或物理），供您在 pod 中运行容器化应用程序。
对于每个运行容器化应用程序的工作节点，它必须包含一个用于运行容器的容器运行时，一个用于确保一切运行的 kubelet，以及用于处理网络的kube - proxy 。
在本文中，您将详细了解上述每个组件如何在 Kubernetes 集群中运行容器化应用程序。
先决条件
要正确理解本文，您应该对 Kubernetes 控制平面有所了解。
容器运行时
工作节点中的容器运行时负责运行容器。容器运行时还负责从存储库中拉取容器镜像、监控本地系统资源、隔离系统资源以供容器使用以及管理容器生命周期。
在 Kubernetes 中，支持容器运行时，例如：
- containerd：一个行业标准的容器运行时，强调简单性、健壮性和可移植性。
- CRI-O：专为 Kubernetes 构建的轻量级容器运行时。
- 以及Kubernetes 容器运行时接口 (CRI)的任何其他实现——一个使 kubelet 无需重新编译即可使用其他容器运行时的插件。
您可能想知道为什么在上面的列表中没有看到 Docker（一个主要的容器运行时）。Docker 不存在是因为在 Kubernetes 版本 v1.24 中删除了 dockershim（允许将 Docker 用作容器运行时的组件）。
不过不用担心，您仍然可以使用cri-dockerd适配器在 Kubernetes 中将 Docker 用作容器运行时。cri-dockerd 为 Docker Engine 提供了一个shim，让您可以通过 Kubernetes CRI 控制 Docker。****
kubelet
kubelet是主要的 Kubernetes 节点代理。kubelet负责为调度到其节点的 pod 运行容器。kubelet在集群中的每台机器（也是控制平面）上运行。
每个节点的kubelet都会监视控制平面的kube-apiserver 中的 pod 资源。每当kube-scheduler将 pod 分配给节点时，该节点的kubelet都会读取 PodSpec（描述 pod 的 YAML 或 JSON 对象）并使用 CRI 指示容器运行时启动容器以满足该规范。如果容器图像不存在于节点中，容器运行时将拉取容器图像并启动它们。
需要注意的是，kubelet是一个不在容器中运行的 Kubernetes 组件。kubelet与容器运行时一起安装并直接在构成集群节点的机器上运行，这就是它们负责管理容器化工作负载的原因。
kube-proxy
与kubelet一样，kube-proxy运行在集群中的每个节点上，但与 kubelet 不同的是，kube-proxy 通常作为 Kubernetes DaemonSet 的一部分在 Kubernetes pod 中运行。
kube-proxy实现了 Kubernetes 服务的基本功能。 kube-proxy维护网络规则，允许从集群内部或外部的网络会话与 Pod 进行通信。
要深入挖掘 kube-proxy 的作用，您必须了解Service资源在 Kubernetes 中是如何工作的。
Kubernetes 中的服务 Service提供了一个稳定的 IP 地址来连接 Pod。Kubernetes中有Service资源，因为没有它们：
- 当客户端应用程序需要连接到集群中的服务器 Pod 时，它需要检索和维护每个 Pod 的 IP 地址列表，这会给客户端带来负担。
- 而且，很难维护这些连接，因为在 Kubernetes 中，Pod 会因扩展、更新或硬件故障而来来去去。
通过使用服务资源的上述设置，客户端将只需要服务的地址，其余的将自动为您处理。
自动处理的方式是，当您创建一个引用应用到一组 pod 的a 的服务时， kube-controller-manager中的Endpoints 控制器将创建一个带有 pod IP 地址的Endpoints资源。在Endpoints资源中，地址被维护；如果它们发生变化，它们将自动更新，并相应地路由客户端的请求。selector label
在上图中，您可能会觉得Service是一个文字代理，它将请求负载平衡到 Nginx 等后端。但在现代 Kubernetes 集群中几乎不是这种情况。
现在随着您对服务资源的理解，让我们深入了解kube-proxy如何实现 Kubernetes 服务的基本功能。
kube-proxy 如何为 Kubernetes 服务资源实现功能。kube-controller-manager中
有一个Endpoints 控制器来管理端点资源。Endpoints 控制器还管理服务和 Pod 之间的关联。
在集群中的每个节点上运行kube-proxy ，它会监视Service和Endpoint资源。因此，当发生需要更新的更改时，kube-proxy将更新 iptables 中的规则。iptables 是一个网络包过滤实用程序，它允许在 Linux 内核的网络堆栈中设置规则。
现在，当客户端 Pod 向Service 的IP 发送请求时，Linux 内核根据kube-proxy设置的规则将请求路由到 Pod 的 IP 之一。
注意：kube-proxy 支持使用 iptables 来管理网络数据包路由的替代方案。但 iptables 是最常见的，适用于大多数安装。
另外，请注意，使用 iptables，pod 选择将是随机的。它不会是循环或其他常见的负载平衡策略。对于负载平衡，您将需要使用 IPVS（IP 虚拟服务器），它是 iptables 的替代方案，它在 Linux 内核中实现了一个负载平衡层。
此外，重要的是要指出，服务的IP 是“虚拟 IP”，因此如果您尝试 ping 该 IP，您将不会像平时 ping pod 的 IP 那样得到响应，这是一个网络上的实际端点。
服务的IP本质上是 iptables 设置的规则中的一个键，它向主机内核提供网络数据包路由指令。但重要的部分是客户端 pod 可以像往常一样使用服务IP，并获得预期的行为，就好像它正在调用实际的 pod IP。
结论
本文解释了容器运行时、kubelet和kube-proxy组件在 Kubernetes 工作节点中的作用。关于这三个节点组件还有很多需要了解。
