请翻译： Another decision to make is whether to keep the base Kubernetes manifests together with the application source code or move them to the deployment repository I decided to go with the first approa

另一个要做的决定是是否将基本的Kubernetes清单与应用程序源代码保持在一起，还是将它们移动到部署仓库中。我决定选择第一种方法来进行Polar Bookshop示例，就像我们在默认配置属性中所做的那样。其中一个好处是在开发过程中可以简单地在本地Kubernetes集群上运行每个应用程序，可以直接运行，也可以使用Tilt进行运行。根据您的需求，您可能会决定使用其中一种方法。两种方法都是有效的，并且在现实世界的场景中使用。

Kustomize的配置定制方法是基于应用补丁的。这与Helm的工作方式完全相反（https://helm.sh）。Helm要求您对每个要更改的清单的每个部分进行模板化（导致非有效的YAML）。之后，您可以为每个环境提供这些模板的不同值。如果一个字段没有模板化，您就无法自定义其值。因此，很常见的情况是在Helm和Kustomize之间连续使用它们，以克服彼此的缺点。这两种方法都有优点和缺点。

在本书中，我决定使用Kustomize，因为它在Kubernetes CLI中本地可用，它使用有效的YAML文件，并且是纯声明性的。Helm更强大，还可以处理Kubernetes本身不支持的复杂应用程序发布和升级。另一方面，Helm有一个陡峭的学习曲线，它的模板化解决方案有一些缺点，并且它不是声明性的。

Carvel套件中的另一个选项是Carvel套件中的ytt（https://carvel.dev/ytt）。它提供了更好的体验，支持补丁和模板，它使用有效的YAML文件，并且其模板化策略更加健壮。熟悉ytt可能需要更多的努力，但这是值得的。由于它将YAML视为一类一流的公民，ytt可以用于配置和自定义任何YAML文件，甚至是在Kubernetes之外。您是否使用GitHub Actions工作流程？Ansible Playbooks？Jenkins管道？您可以在所有这些场景中使用ytt。

让我们考虑一下目录服务。我们已经使用Kustomize组合了基本的部署配置。它位于项目仓库的专用文件夹（catalog-service / k8s）中。现在让我们定义一个覆盖来自定义分期部署。

在前面的章节中，我们使用Kustomize来管理本地开发环境中目录服务的配置。这些清单将代表基础，用于每个环境的多个自定义覆盖。由于我们将在polar-deployment仓库中定义覆盖，而基础在catalog-service仓库中，因此所有目录服务清单都必须在主远程分支中可用。如果您还没有这样做，请将到目前为止对目录服务项目所做的所有更改推送到GitHub上的远程仓库。

注意：正如我在第2章中解释的那样，我希望您为Polar Bookshop系统中的每个项目在GitHub上创建一个不同的仓库。在本章中，我们仅使用polar-deployment和catalog-service仓库，但您还应该为edge-service、order-service和dispatcher-service创建仓库。

如预期的那样，我们将任何配置覆盖存储在polar-deployment仓库中。在本节和后续的章节中，我们将为分期环境定义一个覆盖。下一章将覆盖生产环境。

继续在polar-deployment仓库中创建一个新的kubernetes/applications文件夹。我们将使用它来保存Polar Bookshop系统中所有应用程序的自定义。在新创建的路径中，添加一个catalog-service文件夹，其中将包含用于自定义目录服务在不同环境中部署的覆盖。特别是，我们希望在分期中准备部署，因此为目录服务创建一个“分期”文件夹。

任何自定义（基本或覆盖）都需要一个kustomization.yml文件。让我们为目录服务的分期覆盖（polar-deployment/kubernetes/applications/catalog-service/staging）创建一个。首先要配置的是对基本清单的引用。

如果您遵循了上述步骤，您应该已经在GitHub上为Catalog Service源代码创建了一个catalog-service仓库。对于远程基础的引用，需要指向包含kustomization.yml文件的文件夹，对于我们来说就是k8s。此外，我们应该引用特定的标签或摘要以用于我们要部署的版本。我们将在下一章中讨论发布策略和版本控制，所以现在我们只需指向主分支。最终的URL应该类似于github.com/<your_github_username>/catalog-service/k8s?ref=main。例如，在我的情况下，它将是github.com/polarbookshop/catalog-service/k8s?ref=main。

注意：我假设您为Polar Bookshop创建的所有GitHub仓库都是公开可访问的。如果不是这种情况，您可以转到GitHub上的特定仓库页面，并访问该仓库的设置部分。然后滚动到设置页面的底部，点击“更改可见性”按钮，使包公开可见。

现在，我们可以使用Kubernetes CLI从分期覆盖部署目录服务，但结果与直接使用基本部署没有什么区别。让我们开始应用一些专门针对分期部署的自定义。

我们可以应用的第一个自定义是设置用于激活目录服务的分期Spring配置文件的环境变量。大多数自定义都可以通过合并策略来应用补丁。就像Git从不同分支合并更改一样，Kustomize使用一个或多个基础和一个覆盖的Kustomization文件来生成最终的Kubernetes清单。

在目录服务的分期覆盖（kubernetes/applications/catalog-service/staging）中创建一个patch-env.yml文件来自定义环境变量。我们需要指定一些上下文信息，以便Kustomize可以确定在哪里应用补丁以及如何合并更改。当补丁用于自定义容器时，Kustomize要求我们指定Kubernetes资源（即部署）的种类和名称以及容器的名称。这种自定义选项称为策略合并补丁。

接下来，我们需要指示Kustomize应用补丁。在目录服务的分期覆盖的kustomization.yml文件中，将patch-env.yml文件列出如下。

您可以使用相同的方法自定义部署的许多方面，例如副本数、活动探针、就绪探针、优雅关闭超时、环境变量、卷等。在下一节中，我将向您展示如何自定义ConfigMaps。

目录服务的基础Kustomization指示Kustomize从application.yml文件生成catalog-config ConfigMap。要自定义该ConfigMap中的值，我们有两个