Kubernetes 操作符中的已知问题

EBS 卷预配不足导致 IOPS 等待时间过长

如果您使用kops在Amazon Web Services中预配Kubernetes集群，但遇到性能差和IOPS等待时间长的情况，则您的弹性块存储 (EBS) 卷可能预配不足。

要提高性能，请增加 EBS 卷的存储与 IOPS 的比率。例如，如果数据库大小为500 GB，请将 IOPS 增加到1500 ，即每 GB 3 : 1的比率。要了解有关提高 IOPS 的更多信息，请参阅Amazon Web Services 文档。

ConfigMap 名称 `mongodb-kubernetes-operator-member-list` 是硬编码的

当您运行kubectl mongodb插件时（例如在多 Kubernetes 集群快速启动过程中），该插件会创建一个名为mongodb-kubernetes-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 来禁用身份验证，则 Podmongos 永远不会达到ready 状态。

作为一种变通方法，删除部署中的每个 mongos Pod。

运行以下命令列出所有 Pod：

kubectl get pods

对于名称中包含mongos的每个 Pod，使用以下命令将其删除：

kubectl delete pod <podname>

当您删除一个 Pod 时， Kubernetes会重新创建它。 Kubernetes重新创建的每个 Pod 都会收到更新的配置，并且可以达到READY 状态。要确认所有 Podmongos 均为READY ，运行以下命令：

kubectl get pods -n <metadata.namespace>

如下响应表示您的所有 mongos Pod 均处于 READY状态：

NAME                                           READY   STATUS    RESTARTS   AGE
mongodb-kubernetes-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

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。在此期间，资源无法访问并导致停机。

提示

无法从 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'

机器内存与容器内存

Cloud Manager 和 Ops Manager 中的自动化代理会报告主机内存 (RAM) 使用情况，而不是 Kubernetes container 内存使用情况。

在 MacOS 上，使用Docker Desktop OpsManager 的主机无法下载数据库映像

如果您在 OpsManager 日志中看到如下错误：

['desiredState.FullVersion' is not a member of 'currentState.VersionsOnDisk' ('desiredState.FullVersion'={"trueName":"8.0.4","gitVersion":"bc35ab4305d9920d9d0491c1c9ef9b72383d31f9","modules":null,"major":8,"minor":0,"patch":4}, 'currentState.VersionsOnDisk'=[])] (err=<nil>). Outcome=Failure

以下Docker Desktop 设置组合可能会解决此问题：

后退

故障排除