请翻译： Every time you update the input to the generators Kustomize creates a new manifest with a different hash which triggers a rolling restart of the containers where the updated ConfigMaps or Secrets

每次更新生成器的输入时，Kustomize都会创建一个具有不同哈希值的新清单，这会触发容器的滚动重启，其中更新的ConfigMaps或Secrets作为卷挂载。这是一种非常方便的方法，可以实现自动配置刷新，而无需实施或配置任何其他组件。

让我们验证一下这是真的。首先，在Kustomize用于生成ConfigMap的application.yml文件中更新polar.greeting属性的值。

然后再次应用Kustomization（kubectl apply -k k8s）。Kustomize将生成一个具有不同后缀哈希的新ConfigMap，触发所有Catalog Service实例的滚动重启。在这种情况下，只运行一个实例。在生产环境中会有更多。实例逐个重新启动意味着更新会在零停机时间下进行，这是我们在云中的目标。Catalog Service的根终端点现在应该返回新消息：

如果你好奇的话，你可以将这个结果与在没有Kustomize的情况下更新ConfigMap时会发生的情况进行比较。Kubernetes将更新挂载到Catalog Service容器的卷，但应用程序不会重新启动，仍然返回旧值。

根据您的需求，您可能需要避免滚动重启，并在运行时重新加载应用程序的配置。在这种情况下，您可以使用disableNameSuffixHash: true生成选项禁用哈希后缀策略，可能依赖于类似Spring Cloud Kubernetes Configuration Watcher的东西，以在更改ConfigMap或Secret时通知应用程序。

当您完成Kustomize设置的实验后，可以停止端口转发过程（Ctrl-C）并取消部署Catalog Service（kubectl delete -k k8s）。

由于我们从普通的Kubernetes清单迁移到了Kustomize，我们仍然需要更新一些内容。在第7章中，我们使用Tilt在本地Kubernetes上进行开发工作流程时实现了更好的开发工作流程。Tilt支持Kustomize，因此我们可以将其配置为通过Kustomization资源部署应用程序，而不是通过普通的Kubernetes清单。继续更新Catalog Service项目中的Tiltfile，如下所示。

最后，我们需要更新Catalog Service的提交阶段工作流中的清单验证步骤，否则下次推送更改到GitHub时将失败。在Catalog Service项目中，打开commit-stage.yml文件（.github/workflows）并进行以下更新。

到目前为止，我们从Kustomize中获得的最重要的好处是当更新ConfigMap或Secret时，应用程序会自动滚动重启。在接下来的部分中，您将了解更多关于Kustomize的信息，并探索其强大的功能，以管理根据部署环境不同的Kubernetes配置。

在开发过程中，我们遵循了15因素方法论，并将应用程序的每个可能在不同环境中发生更改的方面的配置外部化。您了解了如何使用属性文件、环境变量、配置服务和ConfigMap。我还向您展示了如何使用Spring配置文件来根据部署环境自定义应用程序配置。现在我们需要更进一步，根据我们部署应用程序的位置定义一种策略来自定义整个部署配置。

在前一节中，您学习了如何通过Kustomization资源组合和处理Kubernetes清单。对于每个环境，我们可以指定要应用的更改或附加配置的补丁。在本节中，您将看到的所有自定义步骤都将应用于不更改应用程序源代码，而是使用先前生成的相同发布构件。这是一个非常强大的概念，也是云原生应用程序的主要特性之一。

Kustomize配置自定义的方法基于基础和覆盖的概念。我们在Catalog Service项目中创建的k8s文件夹可以被视为一个基础：一个具有kustomization.yml文件的目录，将Kubernetes清单和自定义组合在一起。覆盖是另一个具有kustomization.yml文件的目录。它的特殊之处在于它定义了与一个或多个基础相关的自定义，并将它们组合在一起。从相同的基础开始，您可以为每个部署环境（如开发、测试、暂存和生产）指定一个覆盖。

如图14.3所示，每个Kustomization都包含一个kustomization.yml文件。作为基础的那个将多个Kubernetes资源（如部署、服务和ConfigMap）组合在一起。此外，它不知道覆盖，因此完全独立于它们。覆盖使用一个或多个基础作为基础，并通过补丁提供额外的配置。

基础和覆盖可以在同一个存储库或不同的存储库中定义。对于Polar Bookshop系统，我们将在每个应用程序项目中使用k8s文件夹作为基础，并在polar-deployment存储库中定义覆盖。与您在第3章中了解的应用程序代码库类似，您可以决定是否将部署配置保留在与应用程序相同的存储库中。我决定选择一个单独的存储库有几个原因：

它使得可以从一个地方控制系统组件的部署。

在将任何内容部署到生产环境之前，它允许进行版本控制、审计和合规性检查。

它符合GitOps的方法，其中交付和部署任务是解耦的。

作为示例，图14.4显示了在Catalog Service的情况下，Kustomize清单如何结构化，其中基础和覆盖分别位于两个不同的存储库中