请翻译：Currently the Secrets are configured to be provided to the container but Spring Boot is not aware of them yet In the next section I’ll show you how to instruct Spring Boot to load those Secrets as
当前，机密信息已配置为提供给容器使用，但是Spring Boot尚未意识到它们。在下一节中，我将向您展示如何指示Spring Boot将这些机密信息加载为配置树。
Catalog Service的基本Kustomization指示Kustomize生成一个以application.yml文件开头的catalog-config ConfigMap。正如您在前一章中学到的，我们可以要求Kustomize向该相同的ConfigMap添加一个附加文件application-prod.yml，我们知道它会覆盖基本的application.yml文件。这就是我们将如何为生产环境自定义应用程序配置的方式。
首先，在Catalog Service的生产覆盖层（kubernetes/applications/catalog-service/production）中创建一个名为application-prod.yml的文件。我们将使用此属性文件来配置自定义的问候语。我们还需要指示Spring Boot使用spring.config.import属性将机密信息加载为配置树。有关配置树的更多信息，请参阅第14章。
接下来，我们可以依靠Kustomize提供的ConfigMap生成器将application-prod.yml文件（在生产覆盖层中定义）与application.yml文件（在基本Kustomization中定义）合并到同一个catalog-config ConfigMap中。请根据以下方式更新生产覆盖层的kustomization.yml文件。
下一步是更新镜像名称和版本，采用与前一章相同的步骤。这次，我们将能够为容器镜像（我们的发布候选版本）使用正确的版本号。
首先，请确保您的计算机上安装了kustomize CLI。您可以参考https://kustomize.io上的说明。如果您使用的是macOS或Linux，可以使用以下命令安装kustomize：brew install kustomize。
然后打开一个终端窗口，导航到Catalog Service的生产覆盖层（kubernetes/applications/catalog-service/production），并运行以下命令来定义要在catalog-service容器中使用的镜像和版本。请记住将<your_github_username>替换为您的GitHub用户名（小写）。还要将
这个命令将自动更新kustomization.yml文件的新配置，如下面的清单所示。
发布到GitHub容器注册表的映像将具有与相关的GitHub代码存储库相同的可见性。我假设您为Polar Bookshop构建的所有映像都可以通过GitHub容器注册表公开访问。如果不是这种情况，您可以转到GitHub上的特定存储库页面，访问该存储库的“Packages”部分。然后从侧边栏菜单中选择“Package Settings”，滚动到设置页面的底部，并通过单击“Change Visibility”按钮将包设置为公开。
目前，我们在两个地方使用发布候选版本的唯一标识符：远程基础的URL和镜像标签。每当有新的发布候选版本升级到生产环境时，我们需要记住更新这两个地方。更好的做法是自动化更新。当我们实现部署流水线的生产阶段时，我将在稍后进行描述。
云原生应用程序应该具有高可用性，但默认情况下只部署了一个Catalog Service实例。与我们为分期环境所做的操作类似，让我们自定义应用程序的副本数。打开Catalog Service的生产覆盖层中的kustomization.yml文件（kubernetes/applications/catalog-service/production），并为catalog-service容器定义两个副本。
在实际场景中，您可能希望Kubernetes根据当前的工作负载动态地缩放应用程序，而不是提供一个固定的数量。动态扩展是任何云平台的一个关键特性。在Kubernetes中，它是通过一个名为Horizontal Pod Autoscaler的专用组件实现的，该组件基于明确定义的指标（例如每个容器的CPU消耗）进行扩展。有关更多信息，请参阅Kubernetes文档（https://kubernetes.io/docs）。
下一节将介绍在Kubernetes中运行的Spring Boot容器的配置CPU和内存。
在处理容器化应用程序时，最好明确指定资源限制。在第1章中，您学到了容器是利用Linux功能（如命名空间和cgroups）进行分区和限制进程之间资源的隔离上下文。但是，假设您没有指定任何资源限制。在这种情况下，每个容器将可以访问主机机器上的整个CPU集和内存，有可能其中一些容器占用的资源超过应有的限制，导致其他容器由于资源不足而崩溃。
对于像Spring Boot这样基于JVM的应用程序，定义CPU和内存限制尤为重要，因为它们将用于适当地调整JVM线程池、堆内存和非堆内存等项目的大小。配置这些值对于Java开发人员始终是一个挑战，并且至关重要，因为它们直接影响应用程序性能。幸运的是，如果您在Spring Boot中使用Paketo实现的Cloud Native Buildpacks，您就不需要担心这个问题。当您在第6章中使用Paketo打包Catalog Service应用程序时，Java Memory Calculator组件会自动包含在内。当您运行容器化应用程序时，该组件将根据分配给容器的资源限制配置JVM内存。如果您没有指定任何限制，结果将是不可预测的，这并不是您想要的结果。
还有一个经济方面需要考虑。如果您在公共云中运行应用程序，通常是根据您消耗的资源来收费。因此，您可能希望控制每个容器可以使用多少CPU和内存，以避免账单到来时出现不愉快的惊喜。
当涉及到像Kubernetes这样的编排器时，还有另一个与资源相关的关键问题需要考虑。Kubernetes将Pods调度到任何集群节点中进行部署。但是，如果将Pod分配给资源不足以正确运行容器的节点怎么办？解决方案是声明容器所需的最小CPU和内存（资源请求）。Kubernetes将使用该信息仅在可以保证容器至少获得所请求的资源的情况下将Pod部署到特定节点。
资源请求和限制是针对每个容器定义的。您可以在部署清单中指定请求和限制。由于我们一直在本地环境中操作，并且不希望在资源需求方面对其进行太多限制，因此在Catalog Service的基本清单中我们没有定义任何限制。然而，在生产工作负载中，应始终包含资源配置。让我们看看如何为Catalog Service的生产部署实施这一点。
毫不奇怪，我们将使用补丁来将CPU和内存配置应用于Catalog Service。在Catalog Service的生产覆盖层（kubernetes/applications/catalog-service/production）中创建一个名为patch-resources.yml的文件，并为容器资源定义请求和限制。即使我们考虑的是生产场景，我们也将使用较低的值来优化集群中的资源使用，并避免产生额外的成本。在实际场景中，您可能需要仔细分析哪些请求和限制对于您的用例来说是合适的。
接下来，打开Catalog Service的生产覆盖层中的kustomization.yml文件，并配置Kustomize应用补丁。
在清单15.14中，内存请求和限制是相同的，但对于CPU来说并非如此。接下来的部分将解释这些选择背后的原因
原文地址: https://www.cveoy.top/t/topic/iuOG 著作权归作者所有。请勿转载和采集!