请翻译： Creates a generic secret with Base64-encoded valuesThe name of the SecretAdds a secret value for the test usernameAdds a secret value for the test passwordWe can verify that the Secret has been c

使用Base64编码值创建一个通用的秘密

秘密的名称

为测试用户名添加一个秘密值

为测试密码添加一个秘密值

我们可以使用以下命令验证秘密是否成功创建：

我们还可以使用以下命令以熟悉的YAML格式检索秘密的内部表示：

请注意，我重新排列了前面的YAML以增加可读性，并省略了与我们讨论无关的其他字段。

我想重申一下：秘密并不是秘密！我可以使用简单的命令解码存储在test-credentials秘密中的值：

与ConfigMaps一样，秘密可以作为环境变量或通过卷挂载传递给容器。在第二种情况下，您可以将它们作为属性文件或配置树进行挂载。例如，test-credentials秘密将被挂载为配置树，因为它由键/值对组成，而不是文件。

由于秘密未加密，我们不能将它们包含在版本控制系统中。平台工程师需要确保秘密得到充分的保护。例如，可以配置Kubernetes将秘密加密存储在其内部etcd存储中。这可以确保数据在静止时的安全性，但无法解决在版本控制系统中管理秘密的问题。

Bitnami推出了一个名为Sealed Secrets的项目（https://github.com/bitnami-labs/sealed-secrets），旨在加密秘密并将其放入版本控制。首先，您可以从字面值生成一个加密的SealedSecret对象，类似于我们为普通Secret所做的操作。然后，您可以将其包含在存储库中并安全地将其放入版本控制。当SealedSecret清单应用于Kubernetes集群时，Sealed Secrets控制器解密其内容并生成一个可以在Pod中使用的标准Secret对象。

如果您的秘密存储在类似HashiCorp Vault或Azure Key Vault的专用后端中怎么办？在这种情况下，您可以使用像External Secrets（https://github.com/external-secrets/kubernetes-external-secrets）这样的项目。顾名思义，该项目允许您从外部源生成一个Secret。ExternalSecret对象可以安全地存储在存储库中并放入版本控制。当ExternalSecret清单应用于Kubernetes集群时，External Secrets控制器会从配置的外部源获取值并生成一个可以在Pod中使用的标准Secret对象。

如果您想了解有关如何保护Kubernetes Secrets的更多信息，可以查阅Billy Yuen、Alexander Matyushentsev、Todd Ekenstam和Jesse Suen撰写的《GitOps和Kubernetes》第7章和Alex Soto Bueno和Andrew Block撰写的《Kubernetes Secrets管理》。由于这通常是平台团队的任务，我在这里不提供更多信息。

当我们开始使用ConfigMaps和Secrets时，我们必须决定使用哪种策略来更新配置数据以及如何使应用程序使用新值。这是下一节的主题。

当使用外部配置服务时，您可能希望在配置更改时重新加载应用程序。例如，使用Spring Cloud Config时，我们可以使用Spring Cloud Bus来实现这样的机制。

在Kubernetes中，我们需要采用不同的方法。当您更新ConfigMap或Secret时，Kubernetes会负责在挂载为卷时为容器提供新版本。如果您使用环境变量，它们将不会替换为新值。这就是为什么我们通常更喜欢卷解决方案。

更新的ConfigMaps或Secrets在挂载为卷的Pod中提供，但刷新配置是特定应用程序的责任。默认情况下，Spring Boot应用程序只在启动时读取配置数据。当通过ConfigMaps和Secrets提供配置时，有三种主要选项可用于刷新配置：

滚动重启-更改ConfigMap或Secret后，可以对所有受影响的Pod进行滚动重启，使应用程序重新加载所有配置数据。使用此选项，Kubernetes Pod将保持不可变。

Spring Cloud Kubernetes配置监视器- Spring Cloud Kubernetes提供了一个名为Configuration Watcher的Kubernetes控制器，用于监视作为卷挂载到Spring Boot应用程序的ConfigMaps和Secrets。利用Spring Boot Actuator的/actuator/refresh端点或Spring Cloud Bus，当更新任何ConfigMap或Secret时，Configuration Watcher将为受影响的应用程序触发配置刷新。

Spring Cloud Kubernetes配置服务器-Spring Cloud Kubernetes提供了一个配置服务器，支持使用ConfigMaps和Secrets作为Spring Cloud Config的配置数据源之一。您可以使用这样的服务器从Git存储库和Kubernetes对象加载配置，并且可以为两者使用相同的配置刷新机制。

对于Polar Bookshop，我们将使用第一种选项，并依靠Kustomize在应用程序应用新更改时触发应用程序的重启。我将在本章的下一节进一步描述该策略。在这里，我们将重点介绍Spring Cloud Kubernetes及其子项目提供的功能。

Spring Cloud Kubernetes（https://spring.io/projects/spring-cloud-kubernetes）是一个令人兴奋的项目，它将Spring Boot与Kubernetes API集成在一起。它最初的目标是使基于Spring Cloud的微服务架构向Kubernetes过渡变得更容易。它为与Kubernetes集成的标准Spring Cloud接口提供了实现，并添加了对从ConfigMaps和Secrets加载配置的支持。

如果您正在进行一个全新的项目，您不需要使用Spring Cloud Kubernetes。Kubernetes原生支持服务发现和负载平衡，正如您在第7章中体验到的那样。此外，Spring Boot原生支持通过ConfigMaps和Secrets进行配置，因此即使在这种情况下也不需要Spring Cloud Kubernetes。

当将一个既有项目迁移到Kubernetes时，如果该项目使用了诸如Spring Cloud Netflix Eureka用于服务发现和Spring Cloud Netflix Ribbon或Spring Cloud Load Balancer用于负载平衡的库，您可以使用Spring Cloud Kubernetes来实现更平滑的过渡。然而，我建议重构您的代码，以利用Kubernetes的本机服务发现和负载平衡功能，而不是将Spring Cloud Kubernetes添加到您的项目中。

我建议不在标准应用程序中使用Spring Cloud Kubernetes的主要原因是它需要访问Kubernetes API Server以管理Pod、服务、ConfigMaps和Secrets。除了与授予应用程序访问Kubernetes内部对象相关的安全问题外，这还会将应用程序与Kubernetes不必要地耦合在一起，并影响解决方案的可维护性。

什么时候使用Spring Cloud Kubernetes才有意义？作为一个例子，Spring Cloud Gateway可以通过Spring Cloud Kubernetes进行增强，以更好地控制服务发现和负载平衡，包括基于服务元数据的新路由的自动注册和负载平衡策略的选择。在这种情况下，您可以依赖于Spring Cloud Kubernetes Discovery Server组件，将对Kubernetes API的访问限制在发现服务器上。

当涉及到实现Kubernetes控制器应用程序以完成集群内的管理任务时，Spring Cloud Kubernetes非常出色。例如，您可以实现一个控制器，监视ConfigMaps或Secrets的更改，然后触发使用它们的应用程序的配置刷新。事实上，Spring团队就是使用Spring Cloud Kubernetes构建了一个正是这样做的控制器：Configuration Watcher。

注意 Spring Cloud Kubernetes Configuration Watcher在Docker Hub上作为容器映像可用。如果您想了解更多关于它的工作原理和如何部署它的信息，可以参考官方文档（https://spring.io/projects/spring-cloud-kubernetes）。

除了Configuration Watcher之外，Spring Cloud Kubernetes还提供了其他方便的现成应用程序，用于解决Kubernetes中分布式系统的常见问题。其中一个是构建在Spring Cloud Config之上并扩展其功能以支持从ConfigMaps和Secrets读取配置数据的配置服务器。它被称为Spring Cloud Kubernetes Config Server。

您可以直接使用此应用程序（容器映像已发布在Docker Hub上），并根据官方文档（https://spring.io/projects/spring-cloud-kubernetes）中提供的说明在Kubernetes上部署它。

作为替代方案，您可以使用其在GitHub上的源代码作为构建自己的Kubernetes-aware配置服务器的基础。例如，正如我在本章前面解释的那样，您可能希望通过HTTP基本身份验