EBS 卷预配不足导致 IOPS 等待时间过长
如果您使用kops在Amazon Web Services中预配Kubernetes集群，并且遇到性能差和IOPS等待时间长的情况，则您的弹性块存储 (EBS) 卷可能预配不足。
要提高性能，请增加 EBS 卷的存储与 IOPS 的比率。示例，如果数据库大小为 500 GB，请将 IOPS 增加到 1500，即每GB的比率为 3:1。要学习；了解有关提高 IOPS 的更多信息，请参阅Amazon Web Services文档。
ConfigMap 名称mongodb-enterprise-operator-member-list 已硬编码
当您运行kubectl mongodb插件时（例如在多 Kubernetes 集群快速启动过程中），该插件会创建一个名为mongodb-enterprise-operator-member-list的默认 ConfigMap。 此 ConfigMap 包含多 Kubernetes 集群 MongoDB 部署的所有成员。 您无法更改 ConfigMap 的名称。 要了解有关插件标志和操作的更多信息，请参阅MongoDB 插件参考。
mongos 禁用身份验证后实例无法进入就绪状态
注意
此问题仅适用于满足以下条件的分片集群：
使用 Kubernetes 操作符 1.13.0 进行部署
使用 X.509 身份验证
使用 kubernetes.io/tlsMongoDB 助手的 TLS 证书密钥
如果您通过将spec.security.auth.enabled设置为false来禁用身份验证，则mongos Pod 永远不会达到ready状态。
作为一种变通方法，请删除部署中的每个mongos Pod。
运行以下命令列出所有 Pod：
kubectl get pods
对于名称中包含mongos的每个 Pod，使用以下命令将其删除：
kubectl delete pod <podname>
当您删除一个 Pod 时，Kubernetes 会重新创建它。 Kubernetes 重新创建的每个 Pod 都会收到更新的配置，并且可以达到READY状态。 要确认所有mongos Pod 均为READY ，请运行以下命令：
kubectl get pods -n <metadata.namespace>
如下所示的响应表示所有mongos Pod 均为READY ：
NAME READY STATUS RESTARTS AGE mongodb-enterprise-operator-6495bdd947-ttwqf 1/1 Running 0 50m my-sharded-cluster-0-0 1/1 Running 0 12m my-sharded-cluster-1-0 1/1 Running 0 12m my-sharded-cluster-config-0 1/1 Running 0 12m my-sharded-cluster-config-1 1/1 Running 0 12m my-sharded-cluster-mongos-0 1/1 Running 0 11m my-sharded-cluster-mongos-1 1/1 Running 0 11m om-0 1/1 Running 0 42m om-db-0 2/2 Running 0 44m om-db-1 2/2 Running 0 43m om-db-2 2/2 Running 0 43m
更新 Google 防火墙规则以修复 Webhook 问题
将Kubernetes Operator部署到 GKE (Google Kubernetes Engine) 私有集群时，MongoDB 资源或 MongoDBOpsManager资源创建可能会超时。日志中可能会显示以下消息：Error setting state
to reconciling: Timeout: request did not complete within requested
timeout 30s。
Google 会配置其防火墙来限制对 Kubernetes Pod 的访问权限。要使用 Webhook 服务，请添加新的防火墙规则，授予GKE (Google Kubernetes Engine)控制平面访问权限Webhook 服务的权限。
Kubernetes 操作符 Webhook 服务在端口 443 上运行。
正确配置持久存储
如果在您创建资源时没有可用的持久卷，则生成的Pod将处于暂时状态，并且 Operator 会失败（重试 20 次后），并显示以下错误：
Failed to update Ops Manager automation config: Some agents failed to register
要防止此错误，请执行以下任一操作：
提供持久卷或
为资源设置
persistent : false
仅出于测试目的，您也可以设置persistent : false 。 不得在生产环境中使用此方法，因为在重启之间不会保留数据。
在删除 Kubernetes 之前删除资源
有时，Ops Manager 可能与 Kubernetes 不同。 这主要发生在手动删除 Kubernetes 资源时。 Ops Manager 可以继续显示已关闭的自动化代理。
如果要删除 Kubernetes 上的 MongoDB 部署，请先使用资源规范删除资源，以免留下失效的自动化代理。
要解决可能出现的任何问题，请参阅：
为 Kubernetes 操作符 和 MongoDB 资源创建单独的命名空间
最佳策略是在不同的命名空间中创建 Kubernetes 操作符及其资源，以便以下操作正常运行：
kubectl delete pods --all
or
kubectl delete namespace mongodb
如果Kubernetes Operator 和资源位于同一 mongodb命名空间中，则操作符也会在同一操作中删除。这平均值它无法清理配置，而清理配置必须在MongoDB Ops Manager应用程序中完成。
部署后启用 HTTPS
我们建议您在部署 Ops Manager 资源 之前 启用 HTTPS 。但是，如果在部署后启用HTTPS ，托管资源将无法再与 Ops Manager 通信，并且 Kubernetes Operator 会将资源状态报告为Failed 。
要解决此问题，您必须为每个 Pod运行以下命令来删除Pod：
kubectl delete pod <replicaset-pod-name>
删除后，Kubernetes 会自动重启已删除的 Pod。 在此期间，资源无法访问并导致停机。
无法更新应用程序数据库 Pods 上的 MongoDB Agent
您无法使用MongoDB Ops Manager升级在应用程序数据库 Pod 上运行的MongoDB Agent助手。 在这些 Pod 上运行的MongoDB Agent版本嵌入在应用程序数据库Docker映像中。
当 MongoDB 发布新映像时，您可以使用 Kubernetes Operator 升级应用程序数据库 Pod 上的 MongoDB Agent 版本。
无法从 IBM Cloud Paks 中提取 Enterprise Kubernetes Operator 映像
如果您从IBM Cloud Paks托管的容器注册表中拉取Kubernetes Operator 映像，则IBM Cloud Paks 会通过在正式映像名称中添加摘要 SHA 来更改映像的名称。此动作会导致Kubernetes Operator 发出类似于以下内容的错误消息：
Failed to apply default image tag "cp.icr.io/cp/cpd/ibm-cpd-mongodb-agent@ sha256:10.14.24.6505-1": couldn't parse image reference "cp.icr.io/cp/cpd/ ibm-cpd-mongodb-agent@sha256:10.14.24.6505-1": invalid reference format
作为一种变通方法，请更新spec.applicationDatabase.podSpec. podTemplate中的 Ops Manager 应用程序数据库资源定义，为包含摘要 SHA 的 Kubernetes 操作符映像指定新名称，类似于以下示例。
applicationDatabase: The version specified must match the one in the image provided in the `mongod` field version: 4.4.11-ubi8 members: 3 podSpec: podTemplate: spec: containers: - name: mongodb-agent image: 'cp.icr.io/cp/cpd/ibm-cpd-mongodb-agent@sha256:689df23cc35a435f5147d9cd8a697474f8451ad67a1e8a8c803d95f12fea0b59'
机器内存与container内存
Cloud Manager 和 Ops Manager 中的自动化代理会报告主机内存 (RAM) 使用情况，而不是 Kubernetes container 内存使用情况。