请翻译： The 15-Factor methodology recommends keeping code configuration and credentials always separate Kubernetes fully embraces that principle and defines two APIs to handle configuration and credentia

15因素方法论建议始终将代码、配置和凭据分开。Kubernetes完全拥抱这一原则，并定义了两个API来独立处理配置和凭据：ConfigMaps和Secrets。本节将介绍这种新的配置策略，它由Kubernetes原生提供。

Spring Boot对ConfigMaps和Secrets都提供了本地和灵活的支持。我将向您展示如何使用ConfigMaps以及它们与环境变量的关系，环境变量在Kubernetes中仍然是一种有效的配置选项。您将了解到Secrets实际上并不是真正的秘密，以及如何使它们真正保密。最后，我将介绍一些处理配置更改并将其传播到应用程序的选项。

在进一步进行之前，让我们先设置场景并启动一个本地的Kubernetes集群。转到您的Polar Deployment项目（polar-deployment），导航到kubernetes/platform/development文件夹，并运行以下命令以启动一个minikube集群并部署Polar Bookshop使用的后台服务：

如果您没有按照前几章中实现的示例进行操作，您可以参考附带本书的存储库（https://github.com/ThomasVitale/cloud-native-spring-in-action），并使用第14章/14-begin中的项目作为起点。

该命令将需要几分钟才能完成。完成后，您可以使用以下命令验证所有后台服务是否已准备就绪和可用：

让我们首先介绍ConfigMaps。

在第7章中，我们使用环境变量将硬编码的配置传递给在Kubernetes中运行的容器，但它们缺乏可维护性和结构。ConfigMaps允许您以结构化、可维护的方式存储配置数据。它们可以与您的Kubernetes部署清单一起进行版本控制，并具有专用配置存储库的相同优点，包括数据持久性、审计和问责。

ConfigMap是“用于存储非机密数据的API对象，以键值对的形式提供。Pod可以将ConfigMap作为环境变量、命令行参数或卷中的配置文件使用”（https://kubernetes.io/docs/concepts/configuration/configmap）。

您可以使用文字键值对字符串、文件（例如.properties或.yml）或二进制对象构建ConfigMap。在使用Spring Boot应用程序时，构建ConfigMap的最简单方法是从属性文件开始。

让我们看一个例子。在之前的章节中，我们通过环境变量配置了Catalog Service。为了更好地维护和结构化，让我们将其中一些值存储在ConfigMap中。

打开Catalog Service项目（catalog-service），在k8s文件夹中创建一个名为configmap.yml的新文件。我们将使用它来应用以下配置，这将覆盖打包在应用程序中的application.yml文件中包含的默认值：

配置自定义问候语。

配置PostgreSQL数据源的URL。

配置Keycloak的URL。

与我们迄今为止使用的其他Kubernetes对象一样，ConfigMaps的清单可以使用Kubernetes CLI应用于集群。打开一个终端窗口，导航到Catalog Service项目（catalog-service），并运行以下命令：

您可以使用此命令验证ConfigMap是否已正确创建：

ConfigMap中存储的值可以用于以几种不同的方式配置运行的容器：

使用ConfigMap作为配置数据源将命令行参数传递给容器。

使用ConfigMap作为配置数据源为容器填充环境变量。

将ConfigMap作为容器中的卷挂载。

正如您在第4章中学到并在此之后进行的练习中了解到的，Spring Boot支持以多种方式外部化配置，包括通过命令行参数和环境变量。将配置数据作为命令行参数或环境变量传递给容器具有其缺点，即使它存储在ConfigMap中也是如此。例如，每当向ConfigMap添加属性时，都必须更新部署清单。当ConfigMap更改时，Pod不会得到通知，必须重新创建以读取新的配置。将ConfigMaps作为卷挂载解决了这两个问题