Kubernetes 架构详解
导读：本文讲解Kubernetes的原理以及架构，提炼的比较清晰，希望对大家有价值。
下面这张图显示我们在托管应用程序时，应用程序是如何存在于服务器内部的。
当这些主机上没有安装 Kubernetes 时是这种情况的：
让我们再考虑将这些应用程序存储在容器中的情形。Kubernetes正在我们的服务器上运行，通过考虑现实情况来理解Kubernetes 之架构。
再来看图 2 所示，当 Kubernetes 安装在机器上时，它会将这些机器分成两组。
一个主节点（Master Nodes）
其余机器分配为工作节点（Worker Nodes）
工作节点是运行我们实际工作负载的机器。另一方面，主节点是我们的逻辑所在，它知道如何控制集群中运行的其他工作节点。
图3 显示了这些节点与用户之间的交互过程。
问题：假设我们在 Azure、阿里云或腾讯云等提供商之一上运行 Kubernetes，那么场景是什么？
解决方案：从前面的讨论中，我们可以得出结论，如果通过任何一个云提供商使用 Kubernetes 服务，那么 Master 主节点就在他们的控制之下，我们只需要照顾 Worker 节点即可。
好的，到目前为止，我们了解了 Kubernetes。接下来要了解有关其架构的更多信息，我们需要查看主节点和工作节点的内部状态。
图-4 简要描述了 Kubernetes 架构的所有组件以及它们之间的连接方式。
主节点（Master Node）
第 1 部分：我们可以使用名为Kubectl的 CLI 工具或任何UI 界面与 Kubernetes 进行交互。
第 2 部分：API 服务器向最终用户公开 Kubernetes API，因此我们能够与 Kubernetes 进行通信。例如，如果我们想创建一个 pod，那么我们告诉API 服务器需要这个特定集群中的一个 pod。它还对用户进行身份验证并检查他是否有在集群中进行更改的用户的权限。
第 3 部分：API 服务器从用户那里获得的所有必要细节，所有与集群相关的数据，以及由于 Kubernetes 正在协调许多任务，例如配置、部署、服务发现、负载平衡、作业调度和健康状况跨所有集群进行监控。为了实现这种协调，Kubernetes 将这些信息以键值格式存储在etcd 中，并具有一致且高可用性。
第 4 部分： 计划管理器 Scheduler的主要任务是监视没有分配节点的新创建 的 Pod，并选择一个节点让它们运行。例如，我们创建了一个需要 1GB 内存的 Pod，并且在我们的集群中运行了 3 个名为 A、B、C 的工作节点。现在调度程序需要决定它可以在哪个节点上运行这个新创建的 Pod。A 和 B 工作节点没有足够的内存，但 C 节点仅使用了 2GB 中的 500MB，因此调度程序会将 Pod 安排在工作节点 C 上。
第 5 部分：控制管理器会感知 Kubernetes 集群中运行的每个对象，检查它们是否以健康状态运行。Kubernetes 中的每个对象都有单独的控制器。例如，有节点控制器负责在节点宕机时进行通知和响应，作业控制器、端点控制器、服务帐户和令牌控制器等。
工作节点（Worker Node）
工作节点中有 3 个主要组件，即Kubelet、Kube-Proxy 和 Container-runtime。
第 6 部分：Kubelet是在集群中的每个节点上运行的代理。它确保容器在 Pod 中运行。
第 7 部分：Kube-Proxy维护节点上的网络规则。这些网络规则帮助 Pod 相互通信，即便它们位于不同的节点中。
请看图 5，它清晰地体现了存在于两个不同节点中的 Pod A 和 Pod E 可以通过Kube-Proxy 设置的网络规则进行通信。
第 8 部分：容器运行时是负责运行容器的软件。Kubernetes 支持比 Docker 更多的容器运行时，例如 CRI-O、containerd 等。
小结
希望本文能帮助您了解 Kubernetes 架构并熟悉其组件。
参考资料：
对于图 4，感谢@tkssharma
https://kubernetes.io/docs/concepts/
作者：洛逸
相关阅读：