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 のドキュメントを参照してください。

ConfigMap Name `mongodb-kubernetes-operator-member-list` is Hard-Coded

マルチ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 証明書のシークレット

If you disable authentication by setting spec.security.auth.enabled to false, the mongos Pods never reach a ready state.

As a workaround, delete each mongos Pod in your deployment.

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

kubectl get pods

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

kubectl delete pod <podname>

When you delete a Pod, Kubernetes recreates it. Each Pod that Kubernetes recreates receives the updated configuration and can reach a READY state. To confirm that all of your mongos Pods are READY, run the following command:

kubectl get pods -n <metadata.namespace>

A response like the following indicates that all of your mongos Pods are 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 ファイアウォールルールの更新

When you deploy Kubernetes Operator to GKE (Google Kubernetes Engine) private clusters, the MongoDB resources or MongoDBOpsManager resource creation could time out. The following message might appear in the logs: 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 の配置を削除する場合は、リソース仕様を使用してまずリソースを削除し、機能しないオートメーションエージェントが残りませんようにします。

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

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

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

kubectl delete pods --all

kubectl delete namespace mongodb

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

配置後に HTTPS を有効化

We recommend that you enable HTTPS before deploying your Ops Manager resources. However, if you enable HTTPS after deployment, your managed resources can no longer communicate with Ops Manager and the Kubernetes Operator reports your resources' status as 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 設定の次の組み合わせによって、問題が解決される可能性があります。

戻る

トラブルシューティング