有关内部部署容器的常见问题 (FAQ)

查找与 IBM® Sterling Intelligent Promising 容器、 IBM OMS Gateway Operator、 IBM Sterling Intelligent Promising 操作员、信托商店、外部服务等相关的常见问题的答案。

运算符

我可以在任何 Kubernetes 集群上 IBM Sterling Intelligent Promising 安装吗？例如 Red Hat® OpenShift® Container Platform 原生 Kubernetes ，或云托管集群如EKS、 GKE 或 AKS？: 是的， IBM Sterling Intelligent Promising 的设计与平台无关，您可以将其安装在任何云原生计算基金会（CNCF）的 Kubernetes 集群上。

我正在受限环境中使用 Kubernetes 或 Red Hat OpenShift Container Platform 集群，该环境无法访问互联网，因此无法使用 Operator Lifecycle Manager （ OLM ）。是否支持气隙设置？如果是，如何安装 IBM Sterling Intelligent Promising？: 是， IBM Sterling Intelligent Promising 支持气隙设置。更多信息，请参阅操作员实用程序概述。

Sterling Intelligent Promising 内部部署的容器部署涉及两个操作员，即 IBM Sterling Intelligent Promising 操作员和 IBM OMS Gateway Operator。将两者安装在两个不同的命名空间中是否可行？: 编号在两个不同的命名空间中安装两个操作器并不可取。更多信息，请参阅使用命令行界面 (CLI) 安装操作器。

我正试图将 IBM Sterling Intelligent Promising Operator 和 IBM OMS Gateway Operator 版本从 v1 升级到 v2 ，但我发现没有为 v2 版本的相应订阅创建安装计划。在正常情况下，当更新的操作员版本可用时，会自动生成新的安装计划。在这种情况下，未创建安装计划的原因可能是什么？

当监控、安全或服务网格工具

注入一个初始容器或
会修改群集中 pod 的行为，包括由 Operator Lifecycle Manager ( OLM ) 管理的 pod，如目录源 pod。

如果发生这种注入，就会干扰目录操作器检测操作器图像更新的能力。因此，新版本可用时，无法自动创建安装计划。

为了解决这个问题、

确保没有第三方工具在目录源 pod 中修改或注入 init 容器。
移除 init 容器或禁用注入后， OLM 会检测更新的 Operator 版本并生成安装计划。

在您将Operator部署到集群 Red Hat OpenShift Container Platform 时，我注意到Operator Hub上列出了多个版本，包括旧版本和最新版本。在这种情况下，是否可以安装特定的旧版本操作器，而不是最新版本？如果是，建议采用什么方法来帮助确保正确的版本得到正确的安装和管理？还有，升级这些操作员的方法是什么？: 是的，如果需要，您可以选择安装特定版本的操作员。不过，最佳做法是使用最新的可用版本，以利用最新的功能、改进和增强。保持更新可确保最佳的兼容性和支持体验。有关最新版本的更多信息，请参阅 "最新功能"中的"本地容器增强功能"部分。

我已将操作员升级策略配置为 "自动"，因此只要有新版本发布，操作员就会更新到最新版本。不过，我注意到，虽然操作员版本会自动升级，但库存、许诺、实用程序和优化等应用程序仍在使用旧的镜像版本。在这种情况下，这是否是一个潜在的问题？如何有效管理这一问题？: 编号支持向后兼容某些版本。不过，建议使用与 Operator 兼容的图像。有关更多信息，请参阅操作系统版本列表和应用程序映像标签。

信托机构与安全

我有多个中间件服务信任库，如 Cassandra、 Kafka 和 Elasticsearch。在这种情况下，如何配置 SIPEnvironment 以支持多个信任存储，确保每个服务都使用正确的信任配置？安全管理多个信任源（如证书和信任库）的最佳做法有哪些？

是， SIPEnvironment 支持使用统一信任配置。要处理多个信任库，必须将单个信任库合并为一个信任库，其中包括所有所需中间件服务的证书，即 Cassandra、 Kafka 和 Elasticsearch。合并后的信任存储必须提供给 Sterling Intelligent Promising。有关更多信息，请参阅安全参数。

合并信托存储时，请确保完成以下操作。

对合并后的信任库使用单一密码。
通过适当的配置（如环境变量或密文）将此密码提供给 Sterling Intelligent Promising 。
验证是否已正确导入并信任所有必要的证书。

我知道向 Sterling Intelligent Promising 提供信任证书有三种可能的方式，即使用秘密、 ConfigMaps, 或挂载存储。从最佳实践和安全角度来看，建议采用哪种方法最适合向 Sterling Intelligent Promising 提供信任证书，为什么？: 从安全和操作最佳实践的角度来看，使用 Kubernetes 保密是向 Sterling Intelligent Promising 提供信任证书的推荐方法。不过，您可以自由选择最适合您的操作设置或限制的方法。有关更多信息，请参阅 additionalMounts 参数。

一旦构建了信任库并将其挂载到 Sterling Intelligent Promising 部署中，在每次升级或重新部署 Sterling Intelligent Promising 时，是否需要重新创建或生成信任库？在什么情况下（如果有）需要重建信托存储？: 不需要，只要信任配置保持不变，在每次 Sterling Intelligent Promising 升级或重新部署时都不需要重新创建或生成信任存储。有关重建 truststore 的条件的更多信息，请参阅重建 truststore 的条件。

对于我的一个外部中间件服务，例如 Cassandra, Kafka, 和 Elasticsearch, 我的一个信任证书过期了，我应该采取什么步骤在我的 Sterling Intelligent Promising 设置中用更新的证书安全地替换过期的证书？如何确保所有从属组件或 pod 都能正确获取新证书？: 使用与最初使用的相同方法挂载更新后的信任证书，即通过 Secrets、 ConfigMaps, 或挂载存储。加载更新的证书后，重建信任存储，以包含更新的证书。有关重建 truststore 的注释的更多信息，请参阅 apps.sip.ibm.com/import-certificate-to-truststore 注释。

我了解到，最终的信任存储是在 /sip-external-certs/client.truststore.jks 上创建的，存储类型始终是 JKS。这种信任库类型是固定为 JKS，还是可以灵活配置为使用其他类型（如 PKCS12 ）？: 是。信任存储类型的可用选项为 PKCS12 和 JKS。有关更多信息，请参阅安全参数。

在 Sterling Intelligent Promising 部署中，我注意到有一个 trustJavaCACerts 标志。设置为 "true "或 "false "会有什么影响？: 根据是否希望服务器信任默认 Java TrustStore 中的证书，将 ssl.trust.trustJavaCACerts 属性配置为 true 或 false 。有关更多信息，请参阅安全参数。

中间件或外部服务

我依靠操作员设置中间件服务，如 Cassandra、 Kafka 和 Elasticsearch。如何确保保存中间件数据，使其在重新启动后也能持续存在？

如果要依靠操作员来设置中间件服务，就必须为每个中间件服务配置持久存储。持久存储的配置可确保在 pod 重启或节点故障时保留数据。这通常是通过在每个中间件组件的 SIPEnvironment 中定义 storage 属性来实现的。

示例：

  storage:
    name: persist_PVC
     accessMode: ReadWriteMany
     capacity: 40Gi
     storageClassName: default

有关更多信息，请参阅外部服务中的存储和存储属性。

Sterling Intelligent Promising 内部部署容器正式支持哪些版本的中间件组件（如 Cassandra、 Kafka 和 Elasticsearch ）？

官方支持以下中间件版本

Cassandra 4.1.0
Kafka 3.9.1
Elasticsearch 8.19.8

有关更多信息，请参阅《在生产环境中安装中间件服务》。

安装 SIPEnvironment 后，我需要更改其中一个中间件服务的端点，如 Cassandra、 Kafka 和 Elasticsearch。安装 Sterling Intelligent Promising 后，更新中间件配置的推荐方法是什么？: 不支持在 Sterling Intelligent Promising 安装后更改中间件服务的端点，也不鼓励这样做。 Sterling Intelligent Promising 安装完成后，每个中间件服务都会填充与其在平台中的角色相关的运行数据。这些组件协同工作，其数据往往处于相互依存的状态。修改任何一个中间件服务的端点都可能导致数据不一致、关键状态信息丢失或系统不稳定。新配置的中间件将不具备其他组件所需的同步数据或预期数据。

Sterling Intelligent Promising 正式支持作为处理数据存储的中间件依赖之一。 Apache Cassandra 我正在探索使用 Astra DB（由 DataStage, 提供的云原生 Cassandra -as-a-Service）来替代自托管 Cassandra 部署的可能性。 Sterling Intelligent Promising 与 Astra DB 兼容吗？: 不支持。

我观察到，在开发模式下， Sterling Intelligent Promising 能够自动创建 Kafka 主题，但在生产模式下，自动创建并不发生。这种行为背后的原因是什么？: 在开发模式下， Sterling Intelligent Promising 被配置为按需自动创建 Kafka 主题，以简化设置并减少测试期间的人工干预。通过放宽 Kafka 配置和内部逻辑，可以在开发过程中加快迭代速度并方便使用。不过，在生产模式下， Kafka 主题的自动创建被有意禁用，以执行更严格的控制、一致性和可靠性。允许在生产中自动创建主题可能会导致主题配置错误、数据流不一致，或在消息处理过程中产生意想不到的副作用。因此，在生产中， Kafka 主题应按照部署最佳实践，提前或通过供应机制明确创建和管理。

在 Sterling Intelligent Promising 部署期间，如果与任何中间件服务（如 Kafka ）的连接失败，部署本身也会失败。是否有建议的方法在早期阶段验证与所有所需中间件服务的连接性，以便在实际部署开始前发现并解决问题？: 是，使用 apps.sip.ibm.com/validate-external-services-connections 注解来验证中间件服务的连接性。有关更多信息，请参阅 Sterling Intelligent Promising 运算符中使用的注释。

能否 Sterling Intelligent Promising 通过配置禁用 SSL 或 TLS ，确保与外部中间件服务的通信通过非安全或明文通道进行？: 是的，您可以通过配置参数禁用 SSL 或 TLS。更多信息，请参阅配置参数。

我在环境中安装了 Sterling Intelligent Promising 。在运行过程中， Sterling Intelligent Promising 与各种中间件服务交互，如 Kafka, PostgreSQL, ActiveMQ, ，这些中间件服务填充了配置和运行时数据。之后， Sterling Intelligent Promising 被卸载，但中间件服务及其数据在环境中保持不变。对于现有的中间件数据和配置，有哪些注意事项？: Sterling Intelligent Promising 在卸载过程中不会对中间件服务的数据进行任何清理或删除。即使 Sterling Intelligent Promising 从环境中移除，存储在 Cassandra, Kafka, Elasticsearch 等服务中的所有配置和运行时数据仍保持不变。如果打算在新安装或其他应用程序中重复使用或重新利用这些中间件服务，则必须手动审查和清理现有数据。因此，可以防止冲突、陈旧配置或意外行为。

对于其中一个外部中间件服务，如 Cassandra、 Kafka 或 Elasticsearch ，要更改凭据、用户名或密码。在 Sterling Intelligent Promising 容器设置中，我应该采取哪些步骤来安全地使用这些更新的凭据？如何确保所有从属组件或 pod 都能正确接收新凭证？

您必须使用新凭证更新 SIPEnvironment 中使用的密文。有关更多信息，请参阅创建密钥。然后，添加以下注释，以确保所有 pod 重新启动并获取更新后的凭据。

apps.sip.ibm.com/restart

存储器

在安装 Sterling Intelligent Promising 之前，我是否需要手动创建所需的 PVC？如果在未创建必要的 PVC 的情况下触发 Sterling Intelligent Promising 安装，会发生什么情况？: 是。有关更多信息，请参阅手动创建持久卷要求的选项。

在我的环境中，我计划使用动态持久卷 (PV) 进行 Sterling Intelligent Promising 部署。鉴于信任证书需要在部署开始前可用，我如何确保在部署开始前将证书放在动态调配卷上？有没有处理这种情况的推荐方法？: 在启动 Sterling Intelligent Promising 部署之前，必须手动确保将信任证书放置在动态调配卷上，因为应用程序不会自动处理此过程。有关详细信息，请参阅手动创建 Kubernetes 持久卷。

在 Sterling Intelligent Promising 部署中，持久卷 (PV) 中到底存储了什么？哪些组件或数据需要持久存储？: Sterling Intelligent Promising 部署中的持久卷用于为中间件服务（如 Cassandra, Kafka, Elasticsearch ）存储信任存储和数据，特别是在开发模式下和配置了存储的情况下。有关更多信息，请参阅 SIPEnvironment 自定义资源清单。

日志记录

我在 Kubernetes 集群设置上使用 Sterling Intelligent Promising ，默认情况下， Sterling Intelligent Promising pod 的日志通过标准输出提供。收集日志的其他方法是什么？: Sterling Intelligent Promising 支持两种日志模式，包括通过默认的控制台模式和用于集中日志收集的模式。 stdout Kafka 有关更多信息，请参阅日志参数。

升级

在部署应用程序服务（如 Inventory Visibility、Promising、Optimizer 和 Utility Service）的设置中，如何覆盖或更改特定组件的默认映像版本？

您可以使用图像标记和摘要在以下三个级别上覆盖服务的图像版本。

环境或全球层面
服务组级别
应用服务器或后端服务器级别

更多信息，请参阅图像配置优先级。

在操作员版本和应用程序映像版本不同步的情况下，这会导致兼容性问题或意外行为吗？操作员和应用程序映像之间的建议版本兼容性矩阵是什么，应该如何管理升级以确保整个堆栈的稳定性和兼容性？: 是的，因为每个新版本都可能包括操作员映像和应用程序映像的协调更改。最佳做法是使用最新的支持版本更新操作员和应用程序映像，以确保稳定性和兼容性。有关更多信息，请参阅操作系统版本列表和应用程序映像标签。

在最近的一次升级中，我尝试将 Sterling Intelligent Promising Operator 更新到最新版本。然而，由于不可预见的问题，升级失败了，环境也不稳定。为确保业务连续性，我想回滚到之前的操作员工作版本，以便在调查升级问题的同时，系统能继续按预期运行。我该怎么做？: 只要不更新应用程序映像，就可以回滚到 Sterling Intelligent Promising Operator 的上一版本。在回滚之前，确保没有应用程序组件升级到依赖于较新操作器的版本，因为这可能导致兼容性问题。建议首先在较低的环境中彻底测试升级，以避免出现这种情况。只有在一切都通过验证后，才能进行生产升级。如果出现任何问题，即使是在较低的环境中，最好也要及时报告，并向支持人员寻求指导。

在最近的一次升级中，我尝试将应用程序映像更新到最新版本。然而，由于不可预见的问题，升级失败了，环境也不稳定。为了确保业务连续性，我想回滚到以前的工作应用程序映像，以便在调查升级问题的同时，系统能继续按预期运行。我该怎么做？: 应用程序映像升级到较新版本后，不支持将应用程序映像回滚到旧版本，因为应用程序升级可能涉及对数据库和其他内部组件进行不可逆转的更改。建议先在较低的环境中彻底测试升级，以避免出现这种情况。只有在验证稳定性和兼容性后，才能进行生产升级。如果出现问题，即使是在测试环境中，也应立即报告，并在进一步操作前联系支持人员寻求指导。

证书管理

我需要配置 SIPEnvironment 环境，以便在OMS网关层使用自定义的 TLS 证书，以此替换默认证书。如何才能做到这一点？: 是的，您可以在OMS网关层配置自定义 TLS 证书。有关详细信息，请参阅 OMS 网关中的自定义 TLS 证书配置。

我能否配置 SIPEnvironment 为特定服务使用自定义证书，而不是依赖共享或默认证书？: 不支持， SIPEnvironment 不支持在单个服务级别配置自定义证书。自定义证书只能应用于网关或入口级，而不能应用于部署内的特定服务。

SIPEnvironment 是否支持自动处理证书到期、轮换和更新？: 是。 CertificateManager 的重点是自动进行证书再生、改进所有权管理和到期跟踪，以确保顺利、不间断地运行。它具有自动证书更新、确保零停机时间的证书再生、集中 CA 保密、及时状态跟踪等功能。有关更多信息，请参阅 CertificateManager 的关键功能和优势。

在某种情况下，我需要通过自定义域（如 sip.example.com ）发布 Sterling Intelligent Promising 容器服务，以便进行集成或外部访问。如何配置 SIPEnvironment 以支持此功能？: 要配置自定义域，请在 common 配置的 ingress 部分中定义 customDomains 属性。有关更多信息，请参阅《在SIP环境中配置 customDomains 》。

复原力和可扩展性

目前，我在开发或暂存环境中部署了 Sterling Intelligent Promising 的单集群。在准备转向生产时，我想过渡到多集群设置，以确保跨区域或数据中心的高可用性、容错和灾难恢复。我该如何继续？: 在 Sterling Intelligent Promising 容器中使用多集群支持，从单一集群过渡到多集群设置。有关更多信息，请参阅《从单集群迁移到多集群》。

常规

我想使用不同的身份验证系统，而不是产品提供的默认网关身份验证。我可以这样做吗？如果是，如何禁用内置身份验证以使用自己的系统？: 是的，您可以禁用内置网关身份验证，以集成自己的身份验证系统。有关更多信息，请参阅 omsGateway 参数。

在产品安装过程中，入职作业作为 Kubernetes 作业运行。如果这些工作失败，安装将无法继续。由于 Kubernetes 作业在失败后不会自动重启，因此在修复问题后，我该如何重启这些作业？: 您可以使用 apps.sip.ibm.com/restart 注释重新启动失败的作业。有关更多信息，请参阅 Sterling Intelligent Promising 运算符中使用的注释。

我必须确保机密、 configMaps, 和存储卷等一些资源只挂载给指定的 pod 或容器，而不会暴露给整个集群或意外的工作负载。应遵循哪些最佳实践来维护安全性、资源隔离和清洁配置管理？: 通过使用基于标签的 additionalMounts ，您可以动态挂载资源。有关更多信息，请参阅 additionalMounts 参数。

我在开发模式下部署了 SIPEnvironment ，目前面临一个问题。我想启用调试模式来收集更详细的日志。为有效排除故障，推荐的方法是什么？: 是的，您可以在调试模式下启用日志记录。有关更多信息，请参阅日志参数。