试图了解 Kubernetes 工作节点和 Pod 与 Docker“服务”的比较

Question

我正在尝试学习 Kubernetes，以便将我的微服务解决方案推送到云中的一些 Kubernetes（例如 Azure Kubernetes 服务等）

作为其中的一部分，我试图理解主要概念，特别是 Pods + Workers 和（在 yml 文件中）Pods + Services。为此，我尝试将我的 docker-compose 文件中的内容与新概念进行比较。

上下文

我目前有一个 docker-compose.yml 文件，其中包含大约 10 个图像。我将解决方案分为两个“网络”：frontend 和backend。 backend 网络包含 3 个微服务，根本无法通过浏览器访问。 frontend 网络包含一个反向代理（又名 Traefik，就像 nginx），用于将所有请求路由到适当的 backend 微服务和一个简单的 SPA Web 应用程序。所有作品都 100% 很棒。

每个后端微服务至少有以下之一：

• Web API 主机
• 后台任务主机

所以这意味着，如果需要的话，我可以横向扩展 WebApi 主机。但我永远不应该横向扩展后台任务主机。

这是解决方案的简单示意图：

因此，如果 SPA 应用尝试使用以下路由请求一些数据：

https://api.myapp.com/account/1 这将命中反向代理并匹配规则，然后转发到<microservice b>/account/1

所以从这里开始，我正在尝试学习如何根据这些 docker-compose 概念编写 Kubernetes 部署文件。

问题

• 每个“Pod”都有自己的 IP，所以我应该为每个容器创建一个 Pod。 （是的，一个 Pod 可以有多个容器，对我来说，这就像说“在同一台机器上安装这些软件产品”）
• “工作节点”是我们复制/扩展的，因此我们应该根据扩展场景将Pods 放入Node。例如，后台任务主机应该进入一个Node，因为它们不应该被缩放。此外，该节点的硬件要求非常小。虽然Web Api 应该进入另一个Node，以便它们可以被复制/横向扩展

如果我按照上面的理解走在正确的道路上，那么我会有很多节点和 pod ......这感觉......很奇怪？

Answer 1

pod 是 Workload 的单位，有一个或多个容器。正好一个容器是正常的。您可以通过更改 ReplicaSet（或 Deployment）中 Pod 副本的数量来扩展该工作负载。

Pod 主要是一种会计结构，与基本 docker 没有直接平行关系。它类似于 docker-compose 的 Service。 pod 在创建后大部分是不可变的。就像 kubernetes 中的每个资源一样，pod 是所需状态的声明——容器在某处运行。一个 pod 中定义的所有容器都被调度在一起并共享资源（IP、内存限制、磁盘卷等）。

ReplicaSet 中的所有 Pod 都是可替代的和永久的 - ReplicaSet 中的任何 pod 都可以处理请求，并且可以随时替换任何 pod。每个 pod 都有自己的 IP，但替换的 pod 可能会获得不同的 IP。如果你有一个 pod 的多个副本，它们都会有不同的 IP。您不想管理或跟踪 pod IP。 Kubernetes 服务提供发现（我如何找到这些 pod 的 IP）和路由（连接到任何 Ready pod 而不关心其身份）和负载平衡（轮询该组 Pod）。

节点是运行内核、kubelet 和 dockerd 的计算机（VM 或物理）。 （这有点简化了。除了 dockerd 之外还存在其他容器运行时，virtual-kubelet 项目旨在颠覆这一假设。）

所有 pod 都安排在节点上。当一个 pod（带有容器）被调度到一个节点上时，负责在该节点上运行的 kubelet 会做一些事情。 kubelet 与 dockerd 对话以启动容器。

一旦在一个节点上调度，Pod 就不会移动到另一个节点。不过，节点也是可替代的和致命的。如果某个节点出现故障或正在退役，则该 pod 将被驱逐/终止/删除。如果该 pod 是由 ReplicaSet（或 Deployment）创建的，那么 ReplicaSet 控制器将创建该 pod 的新副本以安排在其他地方。

您通常在同一个节点+kubelet+dockerd 上启动许多 (1-100) 个 pod+容器。如果你有更多的 pod（或者它们需要大量的 cpu/ram/io），你需要更多的节点。所以节点也是一个规模单位，虽然非常间接地写在 web 应用程序中。

您通常不关心 pod 安排在哪个节点上。你让 Kubernetes 来决定。