对 Kubernetes 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 控制器会监视以下设置中定义的数据库资源:
spec.backup.s3Stores
对于 MongoDB 资源部署:
kubectl get mdb <resource-name> -n <metadata.namespace> -o yaml status.phase
字段显示 MongoDB 资源部署状态。
以下键值对描述了资源部署状态:
键 | 值 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
message | 解释资源为何处于 Pending 或 Failed 状态的消息。 | ||||||||||
phase |
| ||||||||||
lastTransition | ISO8601 格式的时间戳 上次核对发生时的日期和时间格式(采用 UTC 格式)。 | ||||||||||
link | 中的部署URL MongoDB Ops Manager。 | ||||||||||
backup.statusName | 如果您在 Kubernetes 中使用 spec.backup.mode 为 MongoDB 资源启用了连续备份,则该字段指示备份状态,例如 backup.statusName:"STARTED" 。可能的值为 STARTED 、STOPPED 和 TERMINATED 。 | ||||||||||
资源特定字段 | 有关这些字段的说明,请参阅 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 的日志
要查看 Kubernetes Operator 日志,请调用以下命令:
kubectl logs -f deployment/mongodb-enterprise-operator -n <metadata.namespace>
您还可以检查 Ops Manager 日志,查看是否向 Ops Manager 报告了任何问题。
查找特定 Pod
要查找哪些 pod 可用,请先调用此命令:
kubectl get pods -n <metadata.namespace>
查看来自特定 Pod 的日志
如果要将查看范围缩小到特定 Pod,您可以调用以下命令:
kubectl logs <podName> -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 的 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
。
注意
GKE (Google Kubernetes Engine) 部署
GKE (Google Kubernetes Engine) 部署到私有集群时,Webhook 存在已知问题。要了解详情,请参阅更新 Google 防火墙规则以修复 Webhook 问题。
MongoDB
查看所有 资源规范
要查看所提供命名空间中的所有 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
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 。
替换 ConfigMap 以反映更改
如果无法使用 kubectl apply 命令修改或重新部署已部署的资源 ConfigMap
文件,请运行以下命令:
kubectl replace -f <my-config-map>.yaml
这将删除并重新创建 ConfigMap
资源文件。
在需要立即进行递归更改,或需要更新初始化后无法更新的资源文件时,该命令非常有用。
删除 Kubernetes 组件
重要
删除MongoDB
资源
要删除 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
要删除 Kubernetes Operator,请运行以下命令:
kubectl delete mdb --all -n <metadata.namespace> 删除 Kubernetes Operator:
kubectl delete deployment mongodb-enterprise-operator -n <metadata.namespace>
删除 CustomResourceDefinitions
要删除 CustomResourceDefinitions,请运行以下命令:
kubectl delete mdb --all -n <metadata.namespace> kubectl delete crd mongodb.mongodb.com kubectl delete crd mongodbusers.mongodb.com kubectl delete crd opsmanagers.mongodb.com
删除命名空间
删除命名空间:
kubectl delete mdb --all -n <metadata.namespace> 删除命名空间:
kubectl delete namespace <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恢复原始策略。
警告
以下步骤让您能够使用 Ops Manager 应用程序中 Kubernetes Operator 本会阻止的功能。
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" } 使用空列表更新
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 应用程序中使用之前被阻止的功能。
在 Ops Manager 应用程序中进行更改。
使用原始特征控制策略更新
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资源,请执行以下操作:
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中删除快照。
使用 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 循环重新启动该容器。
您可能需要与该容器进行交互,以检查文件或运行命令。为此,您需要阻止容器重新启动。
在您首选的文本编辑器中,打开需要修复的 MongoDB 资源。
在该资源中添加一个类似于以下内容的
podSpec
集合。podSpec: podTemplate: spec: containers: - name: mongodb-enterprise-database command: ['sh', '-c', 'echo "Hello!" && sleep 3600' ] 睡眠
spec.podSpec.podTemplate.spec
中的命令指示容器等待您指定的秒数。在此示例中,容器将等待1小时。将该更改应用于资源。
kubectl apply -f <resource>.yaml 调用容器内的 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 证书,请执行以下操作:
运行:
kubectl logs -f <pod_name> 检查 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 二进制文件夹是否存在:
为此命令指定 Pod 的名称:
kubectl exec --stdin --tty $<pod_name> /bin/sh 检查 MongoDB 二进制文件夹是否在
/var/lib/mongodb-mms-automation
目录中。如果找不到 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
要解决该错误,请执行以下操作:
删除旧 Kubernetes Operator 部署。
kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace> 注意
删除 Kubernetes Operator 部署不会影响 MongoDB 资源的生命周期。
重复
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
要解决该错误,请执行以下操作:
删除旧 Kubernetes Operator 部署。
kubectl delete deployment/mongodb-enterprise-operator -n <metadata.namespace> 注意
删除 Kubernetes Operator 部署不会影响 MongoDB 资源的生命周期。
重复
helm
命令以升级到新版本的 Kubernetes Operator。
升级后的两个 Operator 实例
从 Kubernetes Operator 版本 1.10 或更早版本升级到版本 1.11 或更高版本后,您的 Kubernetes 集群中可能部署了两个 Kubernetes Operator 实例。
使用get pods
命令查看您的 Kubernetes Operator Pod:
注意
如果您将 Kubernetes Operator 部署到 OpenShift,请将本部分的 kubectl
命令替换为 oc
命令。
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
要了解如何定义环境变量,请参阅 为容器定义环境变量。