Kubernetes 演算子のトラブルシューティング

配置されたリソースのステータスを取得する

Kubernetes Operator を使用して配置されたリソースのステータスを見つけるには、次のいずれかのコマンドを呼び出します。

• MongoDB Ops Managerのリソース配置の場合:

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

  • status.applicationDatabase.phaseフィールドには、アプリケーション データベースのリソースの配置状態が表示されます。

  • [ status.backup.phaseにはバックアップデーモンのリソースの配置状態が表示されます。

  • [0} status.opsManager.phaseフィールドには リソースの配置状態が表示されます。MongoDB Ops Manager

  注意

  Cloud ManagerまたはMongoDB 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

ログの確認

十分なログを保持して確認し、問題のデバッグとクラスターのアクティビティの監視に役立ちます。 推奨される ロギング アーキテクチャ を使用する ポッド を保持するため は、ポッドが削除された後でもログに記録されます。

{ "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

検証 Webhook からのメッセージを確認する

Kubernetes Operator は検証 Webhook を使用する ユーザーが無効なリソース定義を適用するのを防ぐため。Webhook は無効なリクエストを拒否します。

ClusterRole および ClusterRoleBinding Webhook は、インストール中に適用するデフォルトの構成ファイルに含まれています。ロールとバインディングを作成するには、 クラスター管理者特権が必要です。

無効なリソース定義を作成すると、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 は必要ありません。

検証 Webhook を省略する場合、またはデフォルト設定から 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

配置に失敗したステートメントを復元する

ステートフルセット ポッド 配置中にエラーが発生した場合、 は のステータスでハングする可能性があります。Pending

Pending ポッド エラーを解決するために構成の変更を行っ て適用し た場合でも、自動的に終了することは ありません 。

ステートメントを正常な状態に戻すには、 Pending状態の MongoDB リソースに構成の変更を適用してから、それらのポッドを削除します。

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

変更を反映するためのコンフィギュレーションマップの置き換え

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

新しい 永続ボリューム要求 の作成 ポッドの削除後

MongoDB レプリカセット ポッドとその 永続ボリューム要求 を誤って削除した場合 に設定されている場合、Kubernetes Operator は MongoDB ポッドの再スケジュールに失敗し、次のエラー メッセージが表示されます。

scheduler error: pvc not found to schedule the pod

このエラーから回復するに は、新しい API を手動で作成するdata-<replicaset-pod-name> 必要があります このレプリカセット ポッドに対応する API オブジェクトの名前（例: 。

MongoDB Ops Manager機能制御の無効化

Operator MongoDB Ops Managerを通じて プロジェクトを管理する場合、KubernetesKubernetes OperatorEXTERNALLY_MANAGED_LOCK はプロジェクトに 機能制御ポリシー を配置します。このポリシーは、MongoDB Ops Manager KubernetesOperator 構成を損なう可能性のある アプリケーション内の特定の機能を無効にします。これらのブロックされた機能を使用する必要がある場合は、機能制御APIを通じてポリシーを削除し、 MongoDB Ops Managerアプリケーションで変更を加えてから、 APIを通じて元のポリシーを復元できます。

1. プロジェクト の機能制御ポリシーを取得し ます。MongoDB 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 が返す応答を保存します。 MongoDB 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.versionフィールドと同様に、 externalManagementSystemオブジェクトに指定する値は、ステップ 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": []
          }'

   以前にブロックされた機能は、 MongoDB Ops Managerアプリケーションで利用できるようになりました。

3. MongoDB Ops Managerアプリケーションで変更を行います。

4. 元の機能制御ポリシーを使用してpolicies配列を更新します。

   注意

   externalManagementSystem.versionフィールドと同様に、 externalManagementSystemオブジェクトに指定する値は、ステップ 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"
              }
            ]
          }'

   機能が再度ブロックされ、 MongoDB Ops Managerアプリケーションを通じてさらに変更が加えられなくなります。 ただし、 Kubernetes Operator は、機能が利用可能である間にMongoDB Ops Managerアプリケーションで行った変更を保持します。

Kubernetes Operator が失敗した場合のリソースの削除

Operator MongoDBを通じて カスタム リソースを削除すると、KubernetesKubernetes Operator はCloud Manager またはMongoDB Ops Manager の配置の削除を処理します。詳しくは、「 MongoDBリソースを削除する 」を参照してください。

ただし、Kubernetes ではリソースの削除が失敗する可能性があります。 たとえば、Kubernetes MongoDBリソースを削除する前に Operator が失敗した場合は、Cloud Manager またはMongoDB Ops Manager で配置を手動で削除し、プロジェクトを削除する必要があります。

MongoDB Ops ManagerまたはCloud Managerのリソースを手動で削除するには:

1. MongoDB Ops Managerの機能制御を無効にします。

2. MongoDB Ops ManagerCloud ManagerUIAPI または を使用して、プロジェクト内の または から配置を削除します。

   MongoDB Ops ManagerまたはCloud Manager UI で配置を削除します。 MongoDB Ops Managerで、オートメーション から配置を削除し、 モニタリング から配置を削除します。

   Cloud Manager で、オートメーションから配置を削除し、モニタリングから配置を削除します。

   APIMongoDB Ops Managerまたは、Cloud Manager MongoDB Ops ManagerAPIリクエスト、または リクエストを使用して、空の構成を持つCloud 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. MongoDB Ops ManagerまたはCloud Managerからプロジェクトを削除するには、UI またはAPIを使用します。 Cloud Managerで プロジェクトを削除するか、 でプロジェクトを削除します。MongoDB Ops 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はクラスター ノードの ポッドに誤って指定されたドメイン名です。

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

各証明書には有効なドメイン名を含める必要があります。

レプリカセットまたはシャーディングされたクラスターの各ノードについて、そのノードの証明書のコモン ネーム（別名: ドメイン名）は、このクラスター ノードが配置されるポッドのFQDNと一致する必要があります。

各証明書のFQDN名の構文は次のとおりです: pod-name.service-name.namespace.svc.cluster.local 。 この名前は、レプリカセットのノードまたはシャーディングされたクラスターをホストする各ポッドによって異なります。

たとえば、デフォルトのmongodb名前空間で作成されるmongo-0という名前の Kubernetes Operator サービスにある、 rs-mongos-0-0という名前のポッドに配置されたレプリカセットのノードの場合、 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タブで前提条件を参照してください。

ローカル モードで実行中に MongoDB バージョンを確認する

MongoDBCustomResourceRunningMongoDB Ops ManagerMongoDB が ローカル モードMongoDB で実行中に、存在しないバージョンの またはローカルに配置された の有効なバージョンの を指定した場合、 はMongoDB 状態に達しない可能性があります。モードでは、対応するMongoDB Ops Manager MongoDBアーカイブがダウンロードされませんでした。

存在しないMongoDB バージョン、またはMongoDB MongoDB Ops ManagerがMongoDB アーカイブをダウンロードできなかった有効な バージョンを指定した場合、ポッドはREADY 状態に達しても、 OperatorKubernetes ログ にはエラー メッセージが含まれます。次のようになります。

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

これは、MongoDB Agent が対応する MongoDB バイナリを/var/lib/mongodb-mms-automationディレクトリに正常にダウンロードできないことを意味します。 MongoDB Agent が指定された MongoDB バージョンの MongoDB バイナリを正常にダウンロードできる場合、このディレクトリには MongoDB バイナリ フォルダー（ mongodb-linux-x86_64-4.4.0など）が含まれます。

MongoDB バイナリ フォルダーの有無を確認するには

1. このコマンドにポッドの名前を指定します。

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

2. MongoDB バイナリ フォルダーが/var/lib/mongodb-mms-automationディレクトリに存在するかどうかを確認します。

3. MongoDBバイナリ フォルダーが見つからない場合は、 MongoDBアーカイブを配置された各MongoDB Ops ManagerレプリカセットのMongoDB Ops Manager永続ボリュームにコピーします。

または を使用したアップグレードは失敗kubectloc

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. Kubernetes Operator の新しいバージョンにアップグレードするには、 kubectl applyコマンドを繰り返します。

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. Kubernetes Operator の新しいバージョンにアップグレードするには、 helmコマンドを繰り返します。

アップグレード後の 2 つの演算子インスタンス

Kubernetes Operator バージョン 1.10 以前からバージョン 1.11 以降にアップグレードすると、Kubernetes クラスターに Kubernetes Operator の 2 つのインスタンスが配置される可能性があります。

Kubernetes Operator ポッドを表示するには、 get podsコマンドを使用します。

kubectl get pods

レスポンスに ポッドとenterprise-operator mongodb-enterprise-operatorポッドの両方が含まれている場合、クラスターには 2 つの 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 リソースを自動的に回復します。 これにより、無効なオートメーション構成の以前のプッシュが原因で Atlas App Services がPending状態のままになっている場合に、MongoDB Agent が更新されたオートメーション構成の変更をプッシュできない場合に、デッドロックが発生するのを防ぎます。

自動リカバリを構成するには、 mongodb-enterprise.YAML で次の環境変数を定義します。 ファイル:

• MDB_AutoMATIC_RECOVERY_enableを使用して、ポッドごとに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

環境変数を定義する方法については、「 コンテナの環境変数の定義 」を参照してください。