当我通过创建部署来扩展应用程序时。假设我在 3 个集群上运行 nginx 服务。 Nginx 在多个 pod 的容器中运行。 如果我在其中一个 pod 中更改 nginx 配置，它是否会传播到所有节点和 pod，因为它在集群中运行并进行了扩展。
【问题讨论】：
它是否会传播到所有节点和 Pod，因为它正在运行 集群和扩展。
没有。仅当您更改部署 yaml 时。然后它会使用新配置一个一个地重新创建 pod。
【讨论】：
我想在已经说过的基础上再补充一些内容。首先，您甚至不应该对由ReplicaSet、ReplicationController 或Deployment 管理的Pods 进行任何更改。这是提供额外抽象层的对象，它们有责任确保在您的 kubernetes 集群中运行特定数量的Pods。
无论您的集群由多少个节点组成，正如提到的控制器跨越集群中的所有节点一样。
在单个Pod 中所做的更改不仅不会传播到其他Pods，而且如果新创建的具有更改配置的Pod 崩溃，则很容易丢失。
请记住，Deployment 的任务之一是确保给定类型的一定数量的Pods（在Deployment 的Pod template 部分中指定）始终处于运行状态并且跑步。当您手动重新配置的Pod 关闭时，您的Deployment（实际上是由Deployment 创建的ReplicaSet）在幕后运行并重新创建这样的Pod。但它如何重新创建它？它是否考虑到您对此类 Pod 所做的更改？当然不是，它会根据Deployment中给出的template重新创建它。
如果你想在你的Pods 中进行更改，kubernetes 允许你通过提供所谓的rolling update 机制来做到这一点。
Here 您可以阅读有关使用 ReplicationController 的老式方法的信息，该方法已不再使用，因为它已被 Deployments 和 ReplicaSets 取代，但我认为为了掌握这个概念仍然值得一读.
目前部署是要走的路。关于更新Deployment，您可以阅读here。请注意，默认的更新策略是RollingUpdate，这样可以确保更改不会一次应用到所有 Pod，而是一个一个地应用。
【讨论】：
Deployment，例如通过应用编辑过的 yaml 文件，您可以在其中设置更新版本的图像。是的，您应该构建新映像，但不必创建新部署。您可以更新现有的。 Deployment 控制器将自动创建新的副本集（因为它由部署管理，因此您也不必手动创建它）并且如果使用默认更新策略（替代方案是: Recreate 删除所有当前的Pods 然后重新创建它们）。