对 Kubernetes Operator 进行故障排除

获取已部署资源的状态

要查找使用 Kubernetes Operator 部署的资源的状态，请调用以下命令之一：

• 对于 Ops Manager 资源部署：

  kubectl get <resource-name> -n <metadata.namespace> -o yaml

  • status.applicationDatabase.phase 字段显示应用程序数据库的资源部署状态。

  • status.backup.phase 显示备份守护程序资源部署状态。

  • status.opsManager.phase 字段显示 Ops Manager 资源部署状态。

  注意

  Cloud Manager 或 Ops Manager 控制器会监视以下设置中定义的数据库资源：

  • spec.backup.opLogStores

  • spec.backup.s3Stores

  • spec.backup.blockStores

• 对于 MongoDB 资源部署：

  kubectl get mdb <resource-name> -n <metadata.namespace> -o yaml

  status.phase字段显示 MongoDB 资源部署状态。

以下键值对描述了资源部署状态：

kubectl get mdb my-replica-set -n developer -o yaml

status:
    lastTransition: "2019-01-30T10:51:40Z"
    link: http://ec2-3-84-128-187.compute-1.amazonaws.com:9080/v2/5c503a8a1b90141cbdc60a77
    members: 1
    phase: Running
    version: 4.2.2-ent

status:
  lastTransition: 2019-02-01T13:00:24Z
  link: http://ec2-34-204-36-217.compute-1.amazonaws.com:9080/v2/5c51c040d6853d1f50a51678
  members: 1
  message: 'Failed to create/update replica set in Ops Manager: Status: 400 (Bad Request),
    Detail: Something went wrong validating your Automation Config. Sorry!'
  phase: Failed
  version: 4.2.2-ent

查看日志

保留并查看足够多的日志，以帮助调试问题和监控集群活动。使用建议的日志架构保留 Pod 日志，甚至在删除 Pod 之后。

{ "logType": "<log-type>", "contents": "<log line from a log file>" }

kubectl logs -f deployment/mongodb-enterprise-operator -n <metadata.namespace>

kubectl get pods -n <metadata.namespace>

kubectl logs <podName> -n <metadata.namespace>

kubectl logs myrs-0 -n <metadata.namespace>

kubectl logs -c mongodb-enterprise-database replica-set-0 | jq -r 'select(.logType == "mongodb-audit") | .contents'

{{{ "atype":"startup","ts":{"$date":"2023-08-30T20:43:54.649+00:00"},"uuid":{"$binary":"oDcPEY69R1yiUtpMupaXOQ==","$type":"04"},"local":{"isSystemUser":true},"remote":{"isSystemUser":true},"users":[],"roles":[],"param":{"options":{"auditLog":{"destination":"file","format":"JSON","path":"/var/log/mongodb-mms-automation/mongodb-audit.log"},"config":"/data/automation-mongod.conf","net":{"bindIp":"0.0.0.0","port":27017,"tls":{"mode":"disabled"}},"processManagement":{"fork":true},"replication":{"replSetName":"replica-set"},"storage":{"dbPath":"/data","engine":"wiredTiger"},"systemLog":{"destination":"file","path":"/var/log/mongodb-mms-automation/mongodb.log"}}},"result":0}
{"atype":"startup","ts":{"$date":"2023-08-30T20:44:05.466+00:00"},"uuid":{"$binary":"OUbUWC1DQM6k/Ih4hKZq4g==","$type":"04"},"local":{"isSystemUser":true},"remote":{"isSystemUser":true},"users":[],"roles":[],"param":{"options":{"auditLog":{"destination":"file","format":"JSON","path":"/var/log/mongodb-mms-automation/mongodb-audit.log"},"config":"/data/automation-mongod.conf","net":{"bindIp":"0.0.0.0","port":27017,"tls":{"mode":"disabled"}},"processManagement":{"fork":true},"replication":{"replSetName":"replica-set"},"storage":{"dbPath":"/data","engine":"wiredTiger"},"systemLog":{"destination":"file","path":"/var/log/mongodb-mms-automation/mongodb.log"}}},"result":0}}}

spec:
   additionalMongodConfig:
      auditLog:
         destination: file
            format: JSON
            path: /var/log/mongodb-mms-automation/mongodb-audit.log

检查来自验证网络钩子的消息

Kubernetes Operator 使用验证 Webhook 防止用户应用无效的资源定义。Webhook 拒绝无效的请求。

Webhook 的 ClusterRole 和 ClusterRoleBinding 包含在安装过程中运用的默认配置文件中。要创建角色和绑定关系，必须具有集群管理员特权。

如果创建的资源定义无效，Webhook 将返回一条类似以下内容向 Shell 描述错误的消息：

error when creating "my-ops-manager.yaml":
admission webhook "ompolicy.mongodb.com" denied the request:
shardPodSpec field is not configurable for application databases as
it is for sharded clusters and appdb replica sets

Kubernetes Operator 协调每个资源时，也会验证该资源。Kubernetes Operator 创建或更新资源时不需要验证 Webhook。

如果您省略了验证网络钩子，或从默认配置中删除了网络钩子的角色和绑定，或没有足够的权限运行配置，则 Kubernetes Operator 会发出警告，但这些都不是严重错误。如果 Kubernetes Operator 遇到严重错误，则会将资源标记为 Failed。

MongoDB查看所有 资源规范

要查看所提供命名空间中的所有 MongoDB 资源规范，请运行以下命令：

kubectl get mdb -n <metadata.namespace>

kubectl get mdb dublin -n <metadata.namespace> -o yaml

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"mongodb.com/v1","kind":"MongoDB","metadata":{"annotations":{},"name":"dublin","namespace":"mongodb"},"spec":{"credentials":"credentials","persistent":false,"podSpec":{"memory":"1Gi"},"project":"my-om-config","type":"Standalone","version":"4.0.0-ent"}}
  clusterDomain: ""
  creationTimestamp: 2018-09-12T17:15:32Z
  generation: 1
  name: dublin
  namespace: mongodb
  resourceVersion: "337269"
  selfLink: /apis/mongodb.com/v1/namespaces/mongodb/mongodbstandalones/dublin
  uid: 7442095b-b6af-11e8-87df-0800271b001d
spec:
  credentials: my-credentials
  type: Standalone
  persistent: false
  project: my-om-config
  version: 4.2.2-ent

恢复无法部署的 StatefulSet

StatefulSet Pod Pending如果在部署期间遇到错误，则可能会挂起，状态为 。

Pending Pod 不会自动终止，即便您执行并应用配置更改来解决此错误也是如此。

要将 StatefulSet 返回到正常状态，请将配置更改应用到处于 Pending 状态的 MongoDB 资源，然后删除这些 Pod。

kubectl get pods
my-replica-set-0     1/1 Running 2 2h
my-replica-set-1     1/1 Running 2 2h
my-replica-set-2     0/1 Pending 0 2h

kubectl describe pod my-replica-set-2
<describe output omitted>
Warning FailedScheduling 15s (x3691 over 3h) default-scheduler
0/3 nodes are available: 1 node(s) had taints that the pod
didn't tolerate, 2 Insufficient memory.

vi <my-replica-set>.yaml
kubectl apply -f <my-replica-set>.yaml
kubectl delete pod my-replica-set-2

替换 ConfigMap 以反映更改

如果无法使用 kubectl apply 命令修改或重新部署已部署的资源 ConfigMap 文件，请运行以下命令：

kubectl replace -f <my-config-map>.yaml

这将删除并重新创建 ConfigMap 资源文件。

在需要立即进行递归更改，或需要更新初始化后无法更新的资源文件时，该命令非常有用。

删除 Kubernetes 组件

kubectl delete mdb <name> -n <metadata.namespace>

kubectl delete mdb --all -n <metadata.namespace>

删除 Pod 后创建新的持久卷声明

如果您不小心删除了 MongoDB 副本集 Pod 及其 永久卷声明，Kubernetes 操作员将无法重新安排 MongoDB Pod 并发出以下错误消息：

scheduler error: pvc not found to schedule the pod

要从此错误中恢复，您必须 手动创建一个新的 PVC 替换为与此副本集 Pod 对应的 PVC 对象的名称，例如data-<replicaset-pod-name> 。

禁用 Ops Manager 功能控制

当您通过MongoDB Ops Manager KubernetesOperator 管理 项目时，Kubernetes OperatorEXTERNALLY_MANAGED_LOCK 会对项目实施 功能控制策略 。此策略会禁用MongoDB Ops Manager应用程序中的某些功能，这些功能可能会损害Kubernetes Operator 配置。 如果需要使用这些被阻止的功能，可以通过功能控制API删除策略，在MongoDB Ops Manager应用程序中进行更改，然后通过API恢复原始策略。

1. 检索适用于 Ops Manager 项目的功能控制策略。

   curl --user "{USERNAME}:{APIKEY}" --digest \
        --header "Accept: application/json" \
        --header "Content-Type: application/json" \
        --include \
        --request GET "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true"

   保存 API 返回的响应。在 Ops Manager 应用程序中进行更改后，您必须将这些策略添加回项目中。

   重要

   请注意以下示例响应中突出显示的字段和值。 当您删除和添加功能控制策略时，您必须在后续步骤中发送这些相同的字段和值。

   externalManagementSystem.version 字段对应 Kubernetes Operator 版本。您必须稍后在此任务的请求中发送完全相同的字段值。

   您的响应应类似于：

   {
    "created": "2020-02-25T04:09:42Z",
    "externalManagementSystem": {
      "name": "mongodb-enterprise-operator",
      "systemId": null,
      "version": "1.4.2"
    },
    "policies": [
      {
        "disabledParams": [],
        "policy": "EXTERNALLY_MANAGED_LOCK"
      },
      {
        "disabledParams": [],
        "policy": "DISABLE_AUTHENTICATION_MECHANISMS"
      }
    ],
    "updated": "2020-02-25T04:10:12Z"
   }

2. 使用空列表更新policies数组：

   注意

   您为 externalManagementSystem 对象提供的值（如 externalManagementSystem.version 字段）必须与您在第 1 步响应中收到的值相匹配。

   curl --user "{USERNAME}:{APIKEY}" --digest \
        --header "Accept: application/json" \
        --header "Content-Type: application/json" \
        --include \
        --request PUT "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true" \
        --data
          '{
            "externalManagementSystem": {
              "name": "mongodb-enterprise-operator",
              "systemId": null,
              "version": "1.4.2"
            },
            "policies": []
          }'

   现在可在 Ops Manager 应用程序中使用之前被阻止的功能。

3. 在 Ops Manager 应用程序中进行更改。

4. 使用原始特征控制策略更新policies数组：

   注意

   您为 externalManagementSystem 对象提供的值（如 externalManagementSystem.version 字段）必须与您在第 1 步响应中收到的值相匹配。

   curl --user "{USERNAME}:{APIKEY}" --digest \
        --header "Accept: application/json" \
        --header "Content-Type: application/json" \
        --include \
        --request PUT "https://{OPSMANAGER-HOST}:{PORT}/api/public/v1.0/groups/{PROJECT-ID}/controlledFeature?pretty=true" \
        --data
          '{
            "externalManagementSystem": {
              "name": "mongodb-enterprise-operator",
              "systemId": null,
              "version": "1.4.2"
            },
            "policies": [
              {
                "disabledParams": [],
                "policy": "EXTERNALLY_MANAGED_LOCK"
              },
              {
                "disabledParams": [],
                "policy": "DISABLE_AUTHENTICATION_MECHANISMS"
              }
            ]
          }'

   现已重新阻止这些功能，以防止通过 Ops Manager 应用程序进行进一步更改。但是，当功能可用时，Kubernetes Operator 会保留您在 Ops Manager 应用程序中所做的任何更改。

在 Kubernetes Operator 失败时删除资源

当您通过MongoDB KubernetesOperator 删除 自定义资源时，Kubernetes Operator 会处理在Cloud Manager 或MongoDB Ops Manager 中删除部署的操作。要了解更多信息，请参阅删除MongoDB资源。

但是，在Kubernetes中删除资源可能会失败。 示例，如果Kubernetes Operator 在您删除MongoDB资源之前发生故障，则必须手动删除部署并在Cloud Manager或MongoDB Ops Manager中删除其项目。

要手动删除MongoDB Ops Manager或Cloud Manager资源，请执行以下操作：

1. 禁用MongoDB Ops Manager功能控制。

2. MongoDB Ops ManagerCloud Manager使用 UI 或 从项目中的 或API 中删除部署。

   在MongoDB Ops Manager或Cloud Manager用户界面中删除部署。 在MongoDB Ops Manager中，从自动化中删除部署，并从监控中删除部署。

   在 Cloud Manager 中，从自动化中删除部署，并从监控中删除部署。

   或者，通过使用API MongoDB Ops ManagerCloud Manager请求或 请求，使用用于更新MongoDB Ops ManagerAPICloud ManagerAPI 或 中具有空配置的自动化配置的 来删除部署。

   运行与以下MongoDB Ops Manager示例类似的命令：

   curl --user "{USERNAME}:{APIKEY}" --digest \
        --header "Content-Type: application/json" \
        --include \
        --request PUT "https://{OPSMANAGER-HOST}/api/public/v1.0/groups/{PROJECT-ID}/automationConfig" \
        --data '{}'

   注意

   删除已启用备份的 MongoDB 资源不会删除该资源的快照。 您必须在MongoDB Ops Manager中删除快照，或在Cloud Manager中删除快照。

3. 使用 UI 或 从MongoDB Ops Manager 或Cloud ManagerAPI 中删除项目。在MongoDB Ops Manager中删除项目，或在Cloud Manager中删除项目。

   或者，使用MongoDB Ops Manager API请求或Cloud Manager API请求删除项目。

   运行与以下MongoDB Ops Manager示例类似的命令：

   curl --user "{USERNAME}:{APIKEY}" --digest \
        --request DELETE "{OPSMANAGER-HOST}/api/public/v1.0/groups/${PROJECT-ID}"

调试故障容器

容器可能会失败并出现错误，导致 Kubernetes 循环重新启动该容器。

您可能需要与该容器进行交互，以检查文件或运行命令。为此，您需要阻止容器重新启动。

1. 在您首选的文本编辑器中，打开需要修复的 MongoDB 资源。

2. 在该资源中添加一个类似于以下内容的 podSpec 集合。

   podSpec:
     podTemplate:
       spec:
         containers:
         - name: mongodb-enterprise-database
           command: ['sh', '-c', 'echo "Hello!" && sleep 3600' ]

   睡眠 spec.podSpec.podTemplate.spec中的命令指示容器等待您指定的秒数。在此示例中，容器将等待1小时。

3. 将该更改应用于资源。

   kubectl apply -f <resource>.yaml

4. 调用容器内的 shell。

   kubectl exec -it <pod-name> bash

验证 TLS 证书中域名的正确性

如果 TLS 证书无效，MongoDB 副本集或分片集群可能无法变为 READY 状态。

为 MongoDB 副本集或分片集群配置 TLS 时，请验证是否指定有效的证书。

如果没有为每个TLS证书指定正确的域名，Kubernetes Operator日志可能会包含类似以下内容的错误消息，其中foo.svc.local是为集群成员 Pod 指定的错误域名：

TLS attempt failed : x509: certificate is valid for foo.svc.local,
not mongo-0-0.mongo-0.mongodb.svc.cluster.local

每个证书都应包含一个有效的域名。

对于每个副本集或分片集群节点，该节点证书的公用名（也称为域名）必须与部署此集群节点的 Pod 的 FQDN 相匹配。

每个证书中的 FQDN 名称具有以下语法：pod-name.service-name.namespace.svc.cluster.local。对于托管副本集节点或分片集群的每个 Pod，该名称是不同的。

例如，在默认 mongodb 命名空间创建的名称为 mongo-0 的 Kubernetes Operator 服务中，部署在名称为 rs-mongos-0-0 的 Pod 上的副本集成员的 FQDN 是：

rs-mongos-0-0.mongo-0.mongodb.svc.cluster.local

要检查是否正确配置了 TLS 证书，请执行以下操作：

1. 运行：

   kubectl logs -f <pod_name>

2. 检查 Kubernetes Operator 日志文件中是否有与 TLS 相关的消息。

要了解有关 TLS 证书要求的更多信息，请参阅部署副本集或部署分片集群中的 TLS-Encrypted Connections（TLS 加密连接）选项卡上的先决条件。

在本地模式下运行时验证 MongoDB 版本

如果 Ops Manager 在本地模式下运行，并且您指定了不存在的 MongoDB 版本，或者指定了有效的 MongoDB 版本，但在本地模式下部署的 Ops Manager 未为其下载相应的 MongoDB 存档，则 MongoDB CustomResource 可能无法达到 Running 状态。

如果您指定的 MongoDB 版本不存在，或者您指定了有效的 MongoDB 版本，但在该版本下 Ops Manager 无法下载 MongoDB 存档，则即使 Pod 可以达到 READY 状态，Kubernetes Operator 日志也会包含类似以下内容的错误消息：

Failed to create/update (Ops Manager reconciliation phase):
Status: 400 (Bad Request), Detail:
Invalid config: MongoDB <version> is not available.

这可能意味着 MongoDB 代理无法成功将相应的 MongoDB 二进制文件下载到/var/lib/mongodb-mms-automation目录。如果 MongoDB 代理可以成功下载指定 MongoDB 版本的 MongoDB 二进制文件，则此目录包含一个 MongoDB 二进制文件夹，例如mongodb-linux-x86_64-4.4.0 。

检查 MongoDB 二进制文件夹是否存在：

1. 为此命令指定 Pod 的名称：

   kubectl exec --stdin --tty $<pod_name> /bin/sh

2. 检查 MongoDB 二进制文件夹是否在 /var/lib/mongodb-mms-automation 目录中。

3. 如果找不到 MongoDB 二进制文件夹，则对于每个已部署的 Ops Manager 副本集，都将 MongoDB 存档复制到 Ops Manager 持久卷中。

使用kubectl 或 升级失败oc

升级 Kubernetes Operator 时，您可能会收到以下错误：

Forbidden: updates to statefulset spec for fields other than
'replicas', 'template', and 'updateStrategy' are forbidden

要解决该错误，请执行以下操作：

1. 删除旧 Kubernetes Operator 部署。

   kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace>

   注意

   删除 Kubernetes Operator 部署不会影响 MongoDB 资源的生命周期。

2. 重复kubectl apply命令以升级到新版本的 Kubernetes Operator。

使用 Helm Charts 升级失败

升级 Kubernetes Operator 时，您可能会收到以下错误：

Error: UPGRADE FAILED: cannot patch "mongodb-enterprise-operator"
with kind Deployment: Deployment.apps "mongodb-enterprise-operator"
is invalid: ... field is immutable

要解决该错误，请执行以下操作：

1. 删除旧 Kubernetes Operator 部署。

   kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace>

   注意

   删除 Kubernetes Operator 部署不会影响 MongoDB 资源的生命周期。

2. 重复helm命令以升级到新版本的 Kubernetes Operator。

升级后的两个 Operator 实例

从 Kubernetes Operator 版本 1.10 或更早版本升级到版本 1.11 或更高版本后，您的 Kubernetes 集群中可能部署了两个 Kubernetes Operator 实例。

使用get pods命令查看您的 Kubernetes Operator Pod：

kubectl get pods

如果响应同时包含 enterprise-operator 和 mongodb-enterprise-operator，则集群中会存在两个 Kubernetes Operator 实例：

NAME                                           READY   STATUS    RESTARTS   AGE
enterprise-operator-767884c9b4-ltkln           1/1     Running   0          122m
mongodb-enterprise-operator-6d69686679-9fzs7   1/1     Running   0          68m

您可以安全地删除 enterprise-operator 部署。运行以下命令将其删除：

kubectl delete deployment/enterprise-operator

恢复因自动化配置损坏而造成的资源损失

如果自定义资源在较长时间内保持 Pending 或 Failed 状态， Kubernetes Operator 会通过将自动化配置推送到MongoDB Ops Manager来自动恢复您的 MongoDB 资源。 当MongoDB Agent无法推送更新的自动化配置更改时，这可以防止死锁，因为 StatefulSet 由于之前推送了无效的自动化配置而陷入 Pending 状态。

要配置自动恢复，请在 mongodb-enterprise.yaml 文件中定义以下环境变量：

• MDB_AUTOMATIC_RECOVERY_ENABLE 为每个 Pod 启用或禁用 MongoDB 资源的自动恢复。

• MDB_AUTOMATIC_RECOVERY_BACKOFF_TIME_S，用于设置在 Kubernetes Operator 自动恢复 MongoDB 资源之前，自定义资源可保持 Pending 或 Failed 状态的秒数。

1
spec:
2
  template:
3
     spec:
4
        serviceAccountName: mongodb-enterprise-operator
5
        containers:
6
          - name: mongodb-enterprise-operator
7
            image: <operatorVersionUrl>
8
            imagePullPolicy: <policyChoice>
9
            env:
10
             - name: MDB_AUTOMATIC_RECOVERY_ENABLE
11
               value: true
12
             - name: MDB_AUTOMATIC_RECOVERY_BACKOFF_TIME_S
13
               value: 1200

要了解如何定义环境变量，请参阅 为容器定义环境变量。