Kubernetes 配置管理：Kustomize 和覆盖

另一个要做的决定是是否将基本的Kubernetes清单与应用程序源代码保持在一起，还是将它们移动到部署仓库中。我决定选择第一种方法来进行Polar Bookshop示例，就像我们在默认配置属性中所做的那样。其中一个好处是在开发过程中可以简单地在本地Kubernetes集群上运行每个应用程序，可以直接运行，也可以使用Tilt进行运行。根据您的需求，您可能会决定使用其中一种方法。两种方法都是有效的，并且在现实世界的场景中使用。\n\nKustomize的配置定制方法是基于应用补丁的。这与Helm的工作方式完全相反（https://helm.sh）。Helm要求您对每个要更改的清单的每个部分进行模板化（导致非有效的YAML）。之后，您可以为每个环境提供这些模板的不同值。如果一个字段没有模板化，您就无法自定义其值。因此，很常见的情况是在Helm和Kustomize之间连续使用它们，以克服彼此的缺点。这两种方法都有优点和缺点。\n\n在本书中，我决定使用Kustomize，因为它在Kubernetes CLI中本地可用，它使用有效的YAML文件，并且是纯声明性的。Helm更强大，还可以处理Kubernetes本身不支持的复杂应用程序发布和升级。另一方面，Helm有一个陡峭的学习曲线，它的模板化解决方案有一些缺点，并且它不是声明性的。\n\nCarvel套件中的另一个选项是Carvel套件中的ytt（https://carvel.dev/ytt）。它提供了更好的体验，支持补丁和模板，它使用有效的YAML文件，并且其模板化策略更加健壮。熟悉ytt可能需要更多的努力，但这是值得的。由于它将YAML视为一类一流的公民，ytt可以用于配置和自定义任何YAML文件，甚至是在Kubernetes之外。您是否使用GitHub Actions工作流程？Ansible Playbooks？Jenkins管道？您可以在所有这些场景中使用ytt。\n\n让我们考虑一下目录服务。我们已经使用Kustomize组合了基本的部署配置。它位于项目仓库的专用文件夹（catalog-service / k8s）中。现在让我们定义一个覆盖来自定义分期部署。\n\n在前面的章节中，我们使用Kustomize来管理本地开发环境中目录服务的配置。这些清单将代表基础，用于每个环境的多个自定义覆盖。由于我们将在polar-deployment仓库中定义覆盖，而基础在catalog-service仓库中，因此所有目录服务清单都必须在主远程分支中可用。如果您还没有这样做，请将到目前为止对目录服务项目所做的所有更改推送到GitHub上的远程仓库。\n\n注意：正如我在第2章中解释的那样，我希望您为Polar Bookshop系统中的每个项目在GitHub上创建一个不同的仓库。在本章中，我们仅使用polar-deployment和catalog-service仓库，但您还应该为edge-service、order-service和dispatcher-service创建仓库。\n\n如预期的那样，我们将任何配置覆盖存储在polar-deployment仓库中。在本节和后续的章节中，我们将为分期环境定义一个覆盖。下一章将覆盖生产环境。\n\n继续在polar-deployment仓库中创建一个新的kubernetes/applications文件夹。我们将使用它来保存Polar Bookshop系统中所有应用程序的自定义。在新创建的路径中，添加一个catalog-service文件夹，其中将包含用于自定义目录服务在不同环境中部署的覆盖。特别是，我们希望在分期中准备部署，因此为目录服务创建一个“分期”文件夹。\n\n任何自定义（基本或覆盖）都需要一个kustomization.yml文件。让我们为目录服务的分期覆盖（polar-deployment/kubernetes/applications/catalog-service/staging）创建一个。首先要配置的是对基本清单的引用。\n\n如果您遵循了上述步骤，您应该已经在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。\n\n注意：我假设您为Polar Bookshop创建的所有GitHub仓库都是公开可访问的。如果不是这种情况，您可以转到GitHub上的特定仓库页面，并访问该仓库的设置部分。然后滚动到设置页面的底部，点击“更改可见性”按钮，使包公开可见。\n\n现在，我们可以使用Kubernetes CLI从分期覆盖部署目录服务，但结果与直接使用基本部署没有什么区别。让我们开始应用一些专门针对分期部署的自定义。\n\n我们可以应用的第一个自定义是设置用于激活目录服务的分期Spring配置文件的环境变量。大多数自定义都可以通过合并策略来应用补丁。就像Git从不同分支合并更改一样，Kustomize使用一个或多个基础和一个覆盖的Kustomization文件来生成最终的Kubernetes清单。\n\n在目录服务的分期覆盖（kubernetes/applications/catalog-service/staging）中创建一个patch-env.yml文件来自定义环境变量。我们需要指定一些上下文信息，以便Kustomize可以确定在哪里应用补丁以及如何合并更改。当补丁用于自定义容器时，Kustomize要求我们指定Kubernetes资源（即部署）的种类和名称以及容器的名称。这种自定义选项称为策略合并补丁。\n\n接下来，我们需要指示Kustomize应用补丁。在目录服务的分期覆盖的kustomization.yml文件中，将patch-env.yml文件列出如下。\n\n您可以使用相同的方法自定义部署的许多方面，例如副本数、活动探针、就绪探针、优雅关闭超时、环境变量、卷等。在下一节中，我将向您展示如何自定义ConfigMaps。\n\n目录服务的基础Kustomization指示Kustomize从application.yml文件生成catalog-config ConfigMap。要自定义该ConfigMap中的值，我们有两个主要选项：替换整个ConfigMap或仅覆盖在分期中应不同的值。在这种情况下，我们通常可以依靠一些高级的Kustomize修补策略来覆盖ConfigMap中的特定值。\n\n在使用Spring Boot时，我们可以利用Spring配置文件的功能。与其更新现有ConfigMap中的值，我们可以添加一个application-staging.yml文件，我们知道当分期配置文件处于活动状态时，它会优先于application.yml。最终的结果将是一个包含这两个文件的ConfigMap。\n\n首先，让我们在目录服务的分期覆盖中创建一个application-staging.yml文件。我们将使用此属性文件为polar.greeting属性定义一个不同的值。由于我们将使用与之前相同的minikube集群作为分期环境，因此指向后端服务和凭据的URL将与开发环境中的一样。在现实世界的场景中，此阶段将涉及更多自定义。\n\n接下来，我们可以依靠Kustomize提供的ConfigMap Generator来将application-staging.yml文件（在分期覆盖中定义）与application.yml文件（在基础Kustomization中定义）组合到同一个catalog-config ConfigMap中。继续更新分期覆盖的kustomization.yml文件，如下所示。\n\n这就是关于ConfigMaps的内容。下一节将介绍如何配置要部署的镜像名称和版本。\n\n在目录服务仓库（catalog-service/k8s/deployment.yml）中定义的基础Deployment清单被配置为使用本地容器镜像，并且没有指定版本号（这意味着使用最新标签）。这在开发阶段很方便，但它不适用于其他部署环境。\n\n如果您遵循了上述步骤，您应该已经在GitHub上为Catalog Service源代码创建了一个catalog-service仓库，并且已将ghcr.io/<your_github_username>/catalog-service:latest容器镜像发布到GitHub Container Registry（根据Commit Stage工作流程）。下一章将介绍发布策略和版本控制。在此之前，我们将继续使用最新标签。但是，关于镜像名称，现在是时候开始从注册表拉取容器镜像，而不是使用本地镜像了。\n\n注意：发布到GitHub Container Registry的镜像将与相关的GitHub代码仓库具有相同的可见性。我假设我们为Polar Bookshop构建的所有镜像都可以通过GitHub Container Registry公开访问。如果不是这种情况，您可以转到GitHub上的特定仓库页面，并访问该仓库的“包”部分。然后从侧边栏菜单中选择“包设置”，滚动到设置页面的底部，点击“更改可见性”按钮，使包公开可见。\n\n与我们对环境变量所做的一样，我们可以使用补丁来更改目录服务Deployment资源使用的镜像。但是，由于这是一个非常常见的自定义，并且需要在每次交付应用程序的新版本时更改，因此Kustomize提供了一种更方便的方法来声明我们要为每个容器使用的镜像名称和版本。此外，我们可以直接更新kustomization.yml文件，也可以依靠Kustomize CLI（作为Kubernetes CLI的一部分安装）。让我们尝试后者。\n\n打开一个终端窗口，导航到目录服务的分期覆盖（kubernetes/applications/catalog-service/staging），并运行以下命令来定义要为catalog-service容器使用的镜像和版本。请记住用您的GitHub用户名（小写）替换<your_github_username>：