/ /

Kubernetesへの移行のトラブルシューティング

このページでは、プラグインのインポートの失敗、ドライバーと接続の問題、認証の不一致、検証エラーなど、自己管理型のレプリカセットまたはシャーディングされたクラスターを仮想マシンからKubernetes Operator の下のKubernetesに移行する中に発生する可能性のある問題を診断することができます。移行ワークフローの背景については、「自己管理型配置のKubernetesへの移行」を参照してください。

移行中はどこにありますか？

最初に status.conditions[type=Migrating] 条件の reasonフィールドを読み取ります。

理由	ステータス	意味
`Validating`	`True`	ドライバーによる注釈が設定されています。
`Extending`	`True`	目的のKubernetesノード数が最後に調整された数を超えています。
`Pruning`	`True`	`externalMembers` のカウントは `status.migrationObservedExternalMembersCount` を下回りました。
`InProgress`	`True`	外部メンバーは存在しますが、変更はありません。これは、最初の調整の理由でもあります。
`MigrationComplete`	`False`	すべての外部メンバーが削除されました。

優先順位は Validating > です。 Extending> Pruning> InProgress。 Kubernetesサイドも生成するプルーニングが Extending と報告する

同時にプルーニングと拡張は許可されていません。

移行完了をスクリプトするには、status.phase をポーリングするのではなく kubectl wait --for=condition=Migrating=False を使用します。

理由が Extending のままの場合、 Kubernetes Operator が追加しているKubernetesノードは引き続きをプロビジョニングます。これらが目的の状態に達するまで待ちます。
理由が InProgress のままで、外部ノード数が変更されていない場合、リソースへの最後の編集は操作なしでした。Kubernetes Operatorはアクションを必要とする変更を検出しませんでした。

プラグインのインポートの失敗

kubectl mongodb migrate-to-mckプラグインは、リソースを生成する前にソースオートメーション構成を検証します。次のいずれの場合にも、不完全または誤ったリソースを生成するのではなく、エラーで終了します。

Ops Manager またはCloud Managerプロジェクトには複数の配置があります。
プロジェクトには複数のシャーディングされたクラスターがあります。
プロジェクトには、シャーディングされたクラスターの一部ではないレプリカセットがあります。
プロジェクトにはレプリカセットまたはシャーディングされたクラスターはありません。プラグインは、レプリカセットとシャーディングされたクラスターの配置のみを移行できます。
オートメーション構成にはプロセスがありません。
シャーディングされたクラスター内のシャードは、コンフィギュレーションサーバーと同じレプリカセットによってバックアップされます。この埋め込みコンフィギュレーションサーバーのトポロジーは、移行ではサポートされていません。
プラグインは、レプリカセット内で投票権のある優先順位のあるノードを見つけることができないため、そのレプリカセットのソースプロセスを決定できません。
プロセスに mongod または mongos 以外の processType がある。

構成以外のパスと設定の不一致

プラグインは、 Kubernetes Operator が期待するものと一致しない場合、次のオートメーション構成設定にフラグを付けます。

auth.keyFile Kubernetes Operator がspec.downloadBase から派生するパスとは異なります。
auth.keyFileWindows が設定されています。
monitoringAgentConfig.logPath または backupAgentConfig.logPath がデフォルト以外のパスに設定されている。
プロセスには、 Kubernetes Operator のデフォルトとは異なる authSchemaVersion があります。

認証エラー

auth.autoUser 認証が有効になっている間は、は空です。
auth.autoUser はデータベースの auth.usersWanted に一致するエントリがありません。一致するエントリがないと、移行後にエージェント認証が失敗します。
MONGODB-X509 tls.autoPEMKeyFilePathエージェント認証では、オートメーション構成でを設定する必要があります。詳しくは、spec.security.authentication.agents.autoPEMKeyFilePath を参照してください。
移行では、simple 以外の LDAP bindMethod はサポートされていません。

ノードの異種性

Kubernetes Operatorspec.additionalMongodConfig spec.agent.mongod.systemLogは、単一のソースプロセスからとを取得します。レプリカセットメンバーの構成が異なる場合は、移行する前にすべてのメンバーを確認し、違いを調整してください。生成されたリソースは、すべてのKubernetesメンバーに 1 つの構成を適用します。

警告

以下のプロセスごとのオートメーションの構成設定は、新しいKubernetesノードには継承されません。移行する前に、以下を計画してください。

secondaryDelaySecs
非表示メンバー
buildIndexes: false

ソース配置に分析ノードまたは遅延ノードがある場合は、開始する前にKubernetesでそれらを表現する方法を計画してください。

レビューする追加の項目:

プラグインは無効なプロセスをスキップします。外部ノードとしては表示されません。
プロセスで TLSnet.tls.mode disabledが構成されていない場合は、移行する前に、既存の仮想マシンの配置で Ops Manager またはCloud ManagerでをMongoDB に設定します。これは、生成されたリソースでは設定しないでください。そうしないと、 Kubernetesノードの TLS 設定がソースプロセスと一致せず、移行予定されていない配置の変更が発生します。
プロセスの logRotate または auditLogRotate の設定がプロジェクトレベルの構成と異なる場合、 Kubernetes Operator はプロジェクトレベルの値を使用します。

バージョンの不一致

mongodb.com/migrate-tool-version 注釈は、リソースを生成した kubectl mongodb migrate-to-mckプラグインバージョンを記録します。 Kubernetes Operator は、ドライバーの実行中など、すべての調整でこの注釈を独自のバージョンに対して検証します。バージョンに互換性がない場合は、互換性のあるプラグインバージョンでリソースを再生成します。

ドライバーが改善する問題

ドライバーの実行が停止しているように見えます

<resourceName>-connectivity-check ジョブを削除します。次の調整では、それが再作成されます。

ジョブが作成されない場合は、 Kubernetes RBAC 権限に batch/jobs が含まれていることを確認します。 batch/jobs 権限がない場合、 Kubernetes Operator は接続検証ジョブを作成できません。

接続の失敗

バリデータージョブ終了コード	状態	理由	意味
ジョブはまだ実行中	`Unknown`	`Running`	`status.phase` は `ConnectivityCheckRunning` です。
`0`	`True`	`NetworkValidationPassed`	すべての外部ノードはアクセス可能であり、認証されます。
`2`	`False`	`AuthenticationFailed`	認証情報、認証メカニズム、または欠落している `__system@local` ロール。
`3`	`False`	`NetworkFailed`	DNS、TLS、タイムアウト、または到達不能なノード。ジョブポッドログを確認します。
`1` またはその他	`False`	`UnknownError`	クラス化されていない障害。ジョブポッドログを確認します。

ジョブが開始される前に発生する失敗には、OperatorImageUnknown、BuildStatefulSetOptions、AgentCertSecretFailed、AgentCertSubject という理由が使用されます。

Kubernetes Operator は、外部ノードがなくなると、status.conditions から NetworkConnectivityVerified 条件を完全に削除します。

ジョブ実行前の失敗

Kubernetes Operator は、次のいずれかの理由で、接続検証ジョブが開始される前に失敗することがあります。

OperatorImageUnknown
BuildStatefulSetOptions
AgentCertSecretFailed
AgentCertSubject

TLS CA の不一致

Kubernetesノードの証明書は、仮想マシンノードの証明書に署名したのと同じ認証局によって発行される必要があります。そうでない場合、仮想マシンとKubernetesノード間の接続検証とレプリケーションは失敗します。

`memberConfig` 問題

spec.memberConfig spec.membersはよりもエントリが少ないです。ノードごとに 1 つのエントリを追加します。
Kubernetes Operator は、シャーディングされたクラスターの最上位の spec.memberConfigフィールドを無視します。

警告

ノード数を増やす前にspec.memberConfigを設定する

デフォルトでは、新しいKubernetesノードは投票ノードとして参加します。 CRD のデフォルトは votes: 1 と priority: "1" です。これでは、まだ同期中のノードが最初の同期を完了する前に選挙に参加することができます。

MongoDB、ノード数を増加させる前に、新しいKubernetesノードごとに 1spec.memberConfig つのvotes: 0 priority: "0"エントリを書込むことを推奨します。これにより、同期中のノードは選挙で選出されなくなります。votes は整数です。priority は string です。

命名の問題

リソース名またはレプリカセット名が長すぎ、有効な RFC1123 spec.replicaSetNameOverride--resource-name-override名ではありません。有効なKubernetes名を指定するには、またはを使用します。

検証の追加

検証は、実際の移行を開始した後だけでなく、ドライバードキュメント（mongodb.com/migration-dry-run）が設定されているときに起動する可能性があります。
投票ノードの制限検証は、制限を超える変更が直接適用される場合、開始時ではなく調整時に表示されることがあります。
多くの変更を 1 回の編集にバッチすると、配置がクォーラムを失う可能性があります。一度に 1 種類の変更のみを行います。Kubernetes ノードの追加、外部ノードのプルーニング、または投票と優先順位の変更を行います。

収集する診断

上記のセクションを構成しても問題が解決しない場合は、サポートに連絡する前に以下を収集してください。

MongoDBリソースYAML（status.conditions を含む） :
kubectl get mdb <resource-name> -n <namespace> -o yaml
配置用の MongoDBUser リソース。
Kubernetes Operator ログ。
接続バリデータージョブのポッドログ。
Ops Manager またはCloud Managerからのオートメーション構成JSON 。