Docs 菜单
Docs 主页
/
MongoDB Enterprise Kubernetes Operator

对 Kubernetes Operator 进行故障排除

在此页面上

  • 获取已部署资源的状态
  • 查看日志
  • 检查来自验证网络钩子的消息
  • 查看所有 MongoDB资源规范
  • 恢复无法部署的 StatefulSet
  • 替换 ConfigMap 以反映更改
  • 删除 Kubernetes 组件
  • 删除 Pod 后创建新的 持久卷声明
  • 禁用 Ops Manager 功能控制
  • 在 Kubernetes Operator 失败时删除资源
  • 调试故障容器
  • 验证 TLS 证书中域名的正确性
  • 在本地模式下运行时验证 MongoDB 版本
  • 使用 kubectloc 升级失败
  • 使用 Helm Charts 升级失败
  • 升级后的两个 Operator 实例
  • 恢复因自动化配置损坏而造成的资源损失

重要

本部分仅适用于单个Kubernetes集群部署。 对于多 Kubernetes集群MongoDB部署,请参阅对具有多个Kubernetes集群的部署进行故障排除

要查找使用 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 控制器会监视以下设置中定义的数据库资源:

  • 对于 MongoDB 资源部署:

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

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

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

message
解释资源为何处于 PendingFailed 状态的消息。
phase
状态
含义
Pending

Kubernetes Operator 无法协调资源部署状态。在协调超时或 Kubernetes Operator 要求您采取措施以使资源进入运行状态时,就会发生这种情况。

如果资源由于协调超时而处于待处理状态,Kubernetes Operator 在 10 秒内尝试协调资源状态。

Pending

Kubernetes Operator 正在协调资源状态。

创建或更新资源后,或者 Kubernetes Operator 尝试协调之前处于 Failed 状态的资源时,资源就会进入这种状态。

Kubernetes Operator 尝试在 10 秒内协调资源状态。

Running
资源正常运行。
Failed

资源未正确运行。message 字段提供额外详细信息。

Kubernetes Operator 尝试在 10 秒内协调资源状态。

lastTransition
ISO8601 格式的时间戳 上次核对发生时的日期和时间格式(采用 UTC 格式)。
link
中的部署URL MongoDB Ops Manager
backup.statusName
如果您在 Kubernetes 中使用 spec.backup.mode 为 MongoDB 资源启用了连续备份,则该字段指示备份状态,例如 backup.statusName:"STARTED"。可能的值为 STARTEDSTOPPEDTERMINATED
资源特定字段
有关这些字段的说明,请参阅 MongoDB 数据库资源规范

例子

要查看 developer命名空间中名为 my-replica-set 的副本集的状态,请运行以下命令:

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

如果 my-replica-set 正在运行,您应该会看到:

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

如果my-replica-set未运行,您应该会看到:

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 之后。

Kubernetes Operator 使用包装器写入 Pod 日志,该包装器将来自数据库部署 Pod 上的MongoDB Agent助手和mongod组件的日志转换为以下JSON格式的结构化日志记录条目:

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

Kubernetes Operator 支持以下日志类型:

  • automation-agent-verbose

  • automation-agent-stderr

  • mongodb

  • mongodb-audit

  • agent-launcher-script

  • automation-agent

  • monitoring-agent

  • backup-agent

当您从数据库容器读取日志时,Kubernetes Operator 会返回包含不同来源日志的结构化 JSON 条目。

要查看 Kubernetes Operator 日志,请调用以下命令:

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

您还可以检查 Ops Manager 日志,查看是否向 Ops Manager 报告了任何问题。

要查找哪些 pod 可用,请先调用此命令:

kubectl get pods -n <metadata.namespace>

提示

另请参阅:

有关 kubectl get 的 Kubernetes 文档。

如果要将查看范围缩小到特定 Pod,您可以调用以下命令:

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

例子

如果您的副本集标记为myrs ,请运行:

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

此命令将返回该副本集的自动化代理日志

您可以将审核范围缩小到特定的日志类型。例如,以下命令可以通过指定 mongodb-audit 日志类型,从指定 Pod 的 Kubernetes 日志中返回审核日志:

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}}}

要在 Kubernetes Pod 的日志中包含审核日志,请将以下additionalMongodConfig.auditLog配置添加到资源定义中。 您可以根据需要更新提供的文件名。

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

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

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

如果创建的资源定义无效,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

注意

GKE (Google Kubernetes Engine) 部署

GKE (Google Kubernetes Engine) 部署到私有集群时,Webhook 存在已知问题。要了解详情,请参阅更新 Google 防火墙规则以修复 Webhook 问题。

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

kubectl get mdb -n <metadata.namespace>

例子

要读取有关 dublin 独立运行资源的详细信息,请运行以下命令:

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 Pod Pending如果在部署期间遇到错误,则可能会挂起,状态为 。

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

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

例子

主机系统具有很多运行的 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

my-replica-set-2 停滞在 Pending 阶段。要收集有关该错误的更多数据,请运行:

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.

输出会指示内存分配错误。

更新 MongoDB 资源中的内存分配并不足够,因为应用配置更新后 Pod 不会自动终止。

要修复该问题,请更新配置,应用配置,然后删除挂起的 Pod:

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

删除该挂起的 Pod 后,作为 Statefulset 滚动升级的一部分,其他 Pod 会使用新配置重新启动。

注意

要了解有关此问题的更多信息,请参阅 Kubernetes 问题67250 。

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

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

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

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

重要

要删除任何组件,都需要以下权限:

  • mongodb-enterprise-operator-mongodb-webhook

  • mongodb-enterprise-operator-mongodb-certs

  • mongodb-enterprise-operator-mongodb-webhook-binding

  • mongodb-enterprise-operator-mongodb-certs

要删除 Kubernetes 部署的任何实例,您必须使用 Kubernetes。

重要

  • 您只能使用 Kubernetes Operator 删除 Kubernetes 部署的实例。如果您使用 Ops Manager 删除实例,Ops Manager 将引发错误。

  • 删除MongoDB资源时,并不会将其从MongoDB Ops Manager用户界面中删除。 您必须手动从MongoDB Ops Manager中删除资源。 要了解更多信息,请参阅从监控中删除进程。

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

例子

要删除您使用 Kubernetes 创建的单个 MongoDB 实例,请运行以下命令:

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

要删除使用 Kubernetes 创建的所有 MongoDB 实例:

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

要删除 Kubernetes Operator,请运行以下命令:

  1. 删除所有 Kubernetes 资源:

    kubectl delete mdb --all -n <metadata.namespace>
  2. 删除 Kubernetes Operator:

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

要删除 CustomResourceDefinitions,请运行以下命令:

  1. 删除所有 Kubernetes 资源:

    kubectl delete mdb --all -n <metadata.namespace>
  2. 删除 CustomResourceDefinition

    kubectl delete crd mongodb.mongodb.com
    kubectl delete crd mongodbusers.mongodb.com
    kubectl delete crd opsmanagers.mongodb.com

删除命名空间

  1. 删除所有 Kubernetes 资源:

    kubectl delete mdb --all -n <metadata.namespace>
  2. 删除命名空间

    kubectl delete namespace <metadata.namespace>

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

scheduler error: pvc not found to schedule the pod

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

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

警告

以下步骤让您能够使用 Ops Manager 应用程序中 Kubernetes Operator 本会阻止的功能。

  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 应用程序中所做的任何更改。

当您通过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 证书无效,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 加密连接)选项卡上的先决条件。

如果 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 持久卷中。

升级 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。

升级 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。

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

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

注意

如果您将 Kubernetes Operator 部署到 OpenShift,请将本部分的 kubectl 命令替换为 oc 命令。

kubectl get pods

如果响应同时包含 enterprise-operatormongodb-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

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

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

例子

1spec:
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

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

后退

版本说明