AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu
Docs Home
/
管理
/
Kubernetes 演算子のコントローラー
Docs Home
/
管理
/
Kubernetes 演算子のコントローラー
Docs Home
/
管理
/
Kubernetes 演算子のコントローラー

Kubernetes 演算子の既知の問題

EBS ボリュームがプロビジョニングされていない場合は、IOPS 待機時間が長くなります

If you used kops を使用してAmazon Web ServicesでKubernetesクラスターをプロビジョニングし、パフォーマンスが低下し、 IOPS 待機時間が高い場合は、EBS（Elastic Block Store）ボリュームがプロビジョニングされていない可能性があります。

パフォーマンスを向上させるには、EBS ボリュームのストレージと IOPS の比率を増やします。例、データベースが 500 GBの場合、IOPS を 1500 に増やします。これは 1 GBあたり 3:1 の比率です。IOPS の増加の詳細については、Amazon Web Services のドキュメント を参照してください。

コンフィギュレーションマップ名 mongodb-kubernetes-operator-member-list はハードコードされています

マルチKubernetes クラスターのクイック スタート手順中になど、 kubectl mongodbプラグインを実行すると、プラグインはmongodb-kubernetes-operator-member-listという名前のデフォルトの ConfigMap を作成します。 この ConfigMap には、マルチ Kubernetes クラスター MongoDB 配置のすべてのメンバーが含まれています。 ConfigMap の名前を変更することはできません。 プラグインのフラグとアクションの詳細については、 MongoDBリファレンス を参照してください。

mongos 認証を無効にした後、インスタンスが準備完了状態に達しない

注意

この問題は、次の条件を満たすシャーディングされたクラスターにのみ適用されます。

  • Kubernetes Operator 1.13.0 を使用して配置

  • X.509 認証の使用

  • kubernetes.io/tls の使用MongoDB Agent の TLS 証明書のシークレット

spec.security.auth.enabledをfalse に設定して認証を無効にすると、mongos ポッドはready 状態に達することはありません。

回避策として、配置から各 mongos Pod を削除します。

次のコマンドを実行して、すべてのポッドを一覧表示します。

kubectl get pods

名前にmongosが含まれる各ポッドについて、次のコマンドで削除します。

kubectl delete pod <podname>

ポッドを削除すると、 Kubernetes はそれを再作成します。 Kubernetes が再作成する各ポッドは更新された構成を受け取り、READY 状態に達する可能性があります。すべてのmongos ポッドが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

Webhook の問題を修正するための Google ファイアウォール ルールの更新

Kubernetes Operator を GKE（Google Kubernetes Engine）プライベートクラスターに配置すると、 MongoDBリソースまたは MongoDPOsManagerリソースの作成がタイムアウトする可能性があります。ログに次のメッセージが表示される場合があります：Error setting state to reconciling: Timeout: request did not complete within requested timeout 30s 。

Google は、Kubernetesポッド へのアクセスを制限するようにファイアウォールを構成します。Webhook サービスを使用するには、新しいファイアウォールルールを追加して、GKE（Google Kubernetes Engine）の Webhook サービスへのコントロールプレーンのアクセスを許可します。

Kubernetes Operator Webhook サービスはポート 443 で実行されます。

永続ストレージの正しく構成

リソースを作成するときに使用できる永続ボリュームがない場合、結果の ポッド は一時的な状態のままになり、 演算子は（20 の再試行後）に失敗し、次のエラーが発生します。

Failed to update Ops Manager automation config: Some agents failed to register

このエラーを防ぐには、次のいずれかを実行します。

テスト専用で、 persistent : falseを設定することもできます。 再起動間ではデータが保持されないため、これは 本番環境 では使用しないでください。

Kubernetes を削除する前にリソースを削除する

場合によっては、 MongoDB Ops ManagerがKubernetesと異なる場合があります。 これはほとんど、Kubernetes リソースが手動で削除された場合に発生します。 MongoDB Ops Managerは、シャットダウンされたオートメーションエージェントを引き続き表示できます。

Kubernetes 上の MongoDB の配置を削除する場合は、 リソース仕様 を使用してまずリソースを削除し、機能しないオートメーションエージェントが残りませんようにします。

発生する可能性のある問題のトラブルシューティングを行うには、以下を参照してください。

Kubernetes Operator と MongoDB リソースに個別の名前空間を作成

最良の戦略は、次の操作が正しく機能するように、Kubernetes Operator とそのリソースを異なる名前空間に作成することです。

kubectl delete pods --all

or

kubectl delete namespace mongodb

Kubernetes Operator と リソースが同じmongodb 名前空間 にある場合 に設定されている場合、 演算子も同じ操作で削除されます。これは構成をクリーンアップできないことを意味します。これは、 MongoDB Ops Managerアプリケーションで実行する必要があります。

配置後に HTTPS を有効化

Ops Manager リソースを配置する前に、HTTPS を有効にすることをお勧めします。ただし、配置後に HTTPS を有効にすると、管理対象のリソースは Ops Manager と通信できなくなり、 Kubernetes演算子はリソースのステータスを Failed と報告します。

この問題を解決するには、 ポッド を削除する必要があります 各ポッドに対して次のコマンドを実行します。

kubectl delete pod <replicaset-pod-name>

削除後、Kubernetes は削除されたポッドを自動的に再起動します。 この期間はリソースにアクセスできなくなり、ダウンタイムが発生します。

Tip

Cloud Platform Enterprise Kubernetes Operatorから イメージを取得できないIBM

IBM Cloud Platform でホストされているコンテナ レジストリから Kubernetes Operator イメージをプルする場合 、 IBM Cloud Platform は、公式のイメージ名にダイジェスト 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 Application Database のリソース定義を更新して、ダイジェスト SHA を含む Kubernetes Operator イメージの新しい名前を指定します。

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 ManagerMongoDB Ops Managerおよび のオートメーションエージェントは、RAM コンテナのメモリ使用量ではなく、ホスト メモリ（ ）の使用量を報告します。Kubernetes

MacOS では、 Docker Desktop Ops Manager を使用するホストがデータベースイメージをダウンロードできない

Ops Manager ログに次のようなエラーが表示された場合:

['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 設定の次の組み合わせによって、問題が解決される可能性があります。

戻る
トラブルシューティング
このページを評価

項目一覧