MongoDB Enterprise Kubernetes Operatorの既知の問題

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

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

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

ConfigMap 名mongodb-enterprise-operator-member-list はハードコードされています

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

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

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

回避策として、配置内の各mongosポッドを削除します。

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

kubectl get pods

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

kubectl delete pod <podname>

ポッドを削除すると、Kubernetes はそれを再作成します。 Kubernetes が再作成する各ポッドは更新された構成を受け取り、 READY状態に達する可能性があります。 すべてのmongosポッドがREADYであることを確認するには、次のコマンドを実行します。

kubectl get pods -n <metadata.namespace>

次のような応答は、すべてのmongosポッドがREADYであることを示します。

NAME                                           READY   STATUS    RESTARTS   AGE
mongodb-enterprise-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に配置する場合 プライベートクラスターでは、 リソースまたは MongoDPOpsManager リソースの作成がタイムアウトする可能性があります。ログに次のメッセージが表示される場合があります: 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を設定

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

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

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

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

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

• MongoDBリソースを削除する

• MongoDB Ops Manager機能制御の無効化

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

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

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

kubectl delete pods --all

or

kubectl delete namespace mongodb

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

配置後に HTTPS を有効化

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

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

kubectl delete pod <replicaset-pod-name>

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

アプリケーション データベース ポッド上の MongoDB Agent を更新できません

MongoDB Ops Managerを使用して、アプリケーションデータベースポッドで実行されるMongoDB Agentをアップグレードすることはできません。 これらのポッドで実行される MongoDB Agent のバージョンは、アプリケーション データベース Docker イメージに埋め込まれています。

MongoDB が新しいイメージを公開すると、Kubernetes Operator を使用してアプリケーションデータベースポッド上の MongoDB Agent バージョンをアップグレードできます。

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