请翻译： When a ConfigMap is mounted as a volume to a container it generates two possible outcomes figure 142If the ConfigMap includes an embedded property file mounting it as a volume results in the prop

当将ConfigMap作为容器的卷挂载时，会产生两种可能的结果（图14.2）：

如果ConfigMap包含嵌入的属性文件，则将其作为卷挂载将在挂载路径中创建属性文件。Spring Boot会自动查找并包含位于应用可执行文件所在根目录或子目录中的/config文件夹中的任何属性文件，因此这是挂载ConfigMap的完美路径。您还可以通过spring.config.additional-location=配置属性来指定要搜索属性文件的其他位置。

如果ConfigMap包含键/值对，则将其作为卷挂载将在挂载路径中创建一个配置树。对于每个键/值对，都会创建一个文件，文件名与键相同，并包含值。Spring Boot支持从配置树中读取配置属性。您可以通过spring.config.import=configtree:属性指定应从哪里加载配置树。

在配置Spring Boot应用程序时，第一个选项是最方便的，因为它使用与应用程序中的默认配置相同的属性文件格式。让我们看看如何将先前创建的ConfigMap挂载到Catalog Service容器中。

打开Catalog Service项目（catalog-service），并转到k8s文件夹中的deployment.yml文件。我们需要应用三个更改：

删除我们在ConfigMap中声明的值的环境变量。

声明从catalog-config ConfigMap生成的卷。

为catalog-service容器指定一个卷挂载，将ConfigMap作为application.yml文件从/workspace/config加载。/workspace文件夹是由Cloud Native Buildpacks创建和使用的，用于托管应用程序可执行文件，因此Spring Boot将自动查找相同路径下的/config文件夹，并加载其中包含的任何属性文件。无需配置其他位置。

我们之前将ConfigMap应用于集群。现在让我们对Deployment和Service清单执行相同的操作，以验证Catalog Service是否正确从ConfigMap读取配置数据。

首先，我们必须将应用程序打包为容器镜像并加载到集群中。打开一个终端窗口，导航到Catalog Service项目（catalog-service）的根文件夹，并运行以下命令：

现在，我们可以通过应用Deployment和Service清单在本地集群中部署应用程序：

您可以使用以下命令验证Catalog Service何时可用并准备好接受请求：

在内部，Kubernetes使用我们在前一章中配置的活性和就绪探针来推断应用程序的健康状况。

接下来，通过运行以下命令将流量从本地机器转发到Kubernetes集群：

由kubectl port-forward命令启动的进程将一直运行，直到您使用Ctrl-C显式停止它。

现在，您可以从本地机器上的端口9001调用Catalog Service，请求将被转发到Kubernetes集群中的Service对象。打开一个新的终端窗口，调用应用程序公开的根端点以验证ConfigMap中指定的polar.greeting值是否替代了默认值：

还可以尝试检索目录中的书籍，以验证ConfigMap中指定的PostgreSQL URL是否正确使用：

完成测试应用程序后，停止端口转发过程（Ctrl-C）并删除到目前为止创建的Kubernetes对象。打开一个终端窗口，导航到Catalog Service项目（catalog-service），然后运行以下命令，但保持集群运行，因为我们将很快再次使用它：

ConfigMaps对于向在Kubernetes上运行的应用程序提供配置数据非常方便。但是，如果我们需要传递敏感数据怎么办？在下一节中，您将了解如何在Kubernetes中使用Secrets。

配置应用程序的最关键部分是管理密码、证书、令牌和密钥等机密信息。Kubernetes提供了一个Secret对象来存储和管理这些数据，并将其传递给容器。

Secret是用于存储和管理敏感信息（如密码、OAuth令牌和ssh密钥）的API对象。Pod可以将Secret作为环境变量或配置文件在卷中使用（https://kubernetes.io/docs/concepts/configuration/secret）。

使该对象保密的是用于管理它的过程。就本身而言，Secrets与ConfigMaps没有什么不同。唯一的区别是Secret中的数据通常是Base64编码的，这是为了支持二进制文件而做出的技术选择。任何Base64编码的对象都可以以非常直接的方式解码。错误地认为Base64是一种加密方法是一个常见的错误。如果您只记住Secrets的一件事，请记住：Secrets不是秘密！

我们一直在使用的配置在本地Kubernetes集群上运行Polar Bookshop依赖于开发中使用的相同默认凭据，因此我们尚不需要Secrets。在下一章中，当部署应用程序时，我们将开始使用它们。现在，我想向您展示如何创建Secrets。然后，我将介绍一些选项，以确保它们得到充分保护。

创建Secret的一种方法是使用Kubernetes CLI进行命令式方法。打开一个终端窗口，并为一些虚构的测试凭据（用户名/密码）生成一个test-credentials Secret对象