试图了解将Kubernetes Worker节点和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部署文件。

问题

• 每个“容器”都有自己的IP，因此我应该为每个容器创建一个容器。（是的，一个Pod可以有多个容器，对我来说，这就像说“在同一台计算机上安装这些软件产品”）
• “工作节点”是我们要复制/扩展的对象，因此应根据扩展方案将其Pod放入Node。例如，后台任务主机应合而为一，Node因为它们不应该缩放。而且，该节点的硬件要求确实很小。虽然Web Api应该将放入另一个，Node以便可以将它们复制/缩小

如果我按照上面的理解走上了正确的道路，那么我将有很多节点和豆荚……感觉……很奇怪？

Answer 1

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

Pod主要是一种会计构造，与基础docker没有直接的平行关系。它类似于docker-compose的Service。吊舱在创建后几乎不变。像kubernetes中的每个资源一样，pod是所需状态的声明-容器将在某个地方运行。窗格中定义的所有容器都一起调度，并共享资源（IP，内存限制，磁盘卷等）。

ReplicaSet中的所有Pod都是可替代的并且是凡人的-ReplicaSet中的任何Pod都可以满足请求，并且可以随时替换任何Pod。每个Pod确实都有自己的IP，但是替换Pod可能会获得不同的IP。而且，如果您有一个Pod的多个副本，那么它们都将具有不同的IP。您不想管理或跟踪Pod IP。Kubernetes Services提供发现（如何找到这些Pod的IP）和路由（无需关心其身份即可连接到任何Ready Pod）和负载平衡（在该Pod组上循环）。

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

所有Pod已在节点上调度。当在一个节点上计划一个Pod（带有容器）时，负责并在该节点上运行的kubelet会执行操作。Kubelet与dockerd对话以启动容器。

一旦在节点上进行了调度，则窗格不会移动到另一个节点。但是，节点也是可替代的和致命的。如果某个节点出现故障或正在退役，则将逐出/终止/删除该容器。如果该Pod是由ReplicaSet（或Deployment）创建的，则ReplicaSet Controller将创建该Pod的新副本，以计划在其他地方进行调度。

通常，您在同一节点+ kubelet + dockerd上启动许多（1-100）个容器+容器。如果您有更多的Pod（或者它们需要大量的cpu / ram / io），则需要更多的节点。因此，节点也是规模单位，尽管非常间接地使用Web应用程序。

通常，您不必关心将Pod安排在哪个Node上。您让kubernetes决定。