请翻译： Kubernetes provides many useful features for running cloud native applications Still it requires writing several YAML manifests which are sometimes redundant and not easy to manage in a real-worl

Kubernetes为运行云原生应用程序提供了许多有用的功能。然而，它需要编写多个YAML清单，有时这些清单是冗余的，并且在实际情况下不容易管理。在收集部署应用程序所需的多个清单之后，我们面临额外的挑战。我们如何根据环境更改ConfigMap中的值？我们如何更改容器镜像版本？秘密和卷呢？是否可以更新健康检查的配置？

过去几年中引入了许多工具来改进在Kubernetes中配置和部署工作负载的方式。对于Polar Bookshop系统，我们希望有一种工具，可以将多个Kubernetes清单作为单个实体处理，并根据应用程序部署的环境自定义配置的部分。

Kustomize（https://kustomize.io）是一种声明性工具，通过分层方法帮助配置不同环境的部署。它生成标准的Kubernetes清单，并且它是在Kubernetes CLI（kubectl）中本地构建的，因此您不需要安装其他任何内容。

注意 Kubernetes中管理部署配置的其他流行选项是来自Carvel套件的ytt（https://carvel.dev/ytt）和Helm（https://helm.sh）。

本节将向您展示Kustomize提供的关键功能。首先，您将了解如何组合相关的Kubernetes清单并将它们作为单个单元处理。然后，我将向您展示Kustomize如何从属性文件为您生成ConfigMap。最后，我将指导您在部署工作负载到暂存环境之前对基本清单进行一系列自定义。下一章将进一步扩展并涵盖生产场景。

继续之前，请确保您的本地minikube集群仍在运行，并且已正确部署了Polar Bookshop的后备服务。如果没有，请从polar-deployment/kubernetes/platform/development 运行 ./create-cluster.sh。

注意 平台服务仅在集群内部公开。如果您想从本地计算机访问其中任何服务，可以使用您在第7章中学到的端口转发功能。您可以利用Octant提供的GUI，也可以使用CLI（kubectl port-forward service/polar-postgres 5432:5432）。

现在，我们已经有了所有的后备服务，让我们看看如何使用Kustomize管理和配置Spring Boot应用程序。

到目前为止，我们一直通过应用多个Kubernetes清单来将应用程序部署到Kubernetes。例如，部署Catalog Service需要将ConfigMap、Deployment和Service清单应用到集群中。使用Kustomize时，第一步是将相关清单组合在一起，以便我们可以将它们作为单个单元处理。Kustomize通过Kustomization资源来实现这一点。最终，我们希望让Kustomize管理、处理和生成Kubernetes清单。

让我们看看它是如何工作的。打开Catalog Service项目（catalog-service），并在k8s文件夹内创建一个kustomization.yml文件。它将是Kustomize的入口点。

首先，我们将指示Kustomize使用哪些Kubernetes清单作为未来自定义的基础。现在，我们将使用现有的Deployment和Service清单。

你可能想知道为什么我们没有包含ConfigMap。我很高兴你问了！我们可以包含我们之前在本章中创建的configmap.yml文件，但是Kustomize提供了更好的方法。我们可以提供一个属性文件，让Kustomize使用它来生成ConfigMap。让我们看看它是如何工作的。

首先，将我们之前创建的ConfigMap的内容（configmap.yml）移动到k8s文件夹中的一个新的application.yml文件中。

然后删除configmap.yml文件。我们不再需要它了。最后，更新kustomization.yml文件，从我们刚刚创建的application.yml文件生成一个catalog-config的ConfigMap。

让我们暂停一下，验证到目前为止我们所做的是否正确。您的本地集群应该已经具有之前的Catalog Service容器镜像。如果不是这样，请构建容器镜像（./gradlew bootBuildImage）并将其加载到minikube（minikube image load catalog-service --profile polar）。

接下来，打开一个终端窗口，导航到您的Catalog Service项目（catalog-service），并使用熟悉的Kubernetes CLI部署应用程序。当应用标准的Kubernetes清单时，我们使用-f标志。当应用Kustomization时，我们使用-k标志：

最终的结果应该与我们直接应用Kubernetes清单时得到的结果相同，但这次是通过Kustomization资源由Kustomize处理的。

为了完成验证，使用端口转发策略将Catalog Service应用程序暴露给本地计算机（kubectl port-forward service/catalog-service 9001:80）。然后打开一个新的终端窗口，并确保根端点返回通过Kustomize生成的ConfigMap配置的消息：

由Kustomize生成的ConfigMaps和Secrets在部署时会被分配一个唯一的后缀（哈希）。您可以使用以下命令验证分配给catalog-config ConfigMap的实际名称