重要
このページの設定は、Kubernetes 演算子の下で自己管理型配置を Kubernetes へ移行することをサポートするために存在します。付随する移行を伴わずに Kubernetes に直接配置する MongoDBリソースでは設定しないでください。
このページでは、自己管理型の仮想マシン配置から Kubernetes への移行中にのみ適用される MongoDB リソースフィールド、ステータス条件、およびアノテーションについて説明します。MongoDB リソース設定の全セットについては、MongoDB データベース リソース仕様を参照してください。
外部ノード
これらのフィールドは、移行がKubernetesに拡張するソースの仮想マシンまたはベアメタルプロセスを識別します。これらはMongoDBリソースapiVersion: mongodb.com/v1に適用されます。
重要
これらのフィールドは移行のためにのみ存在します。グリーンフィールド Kubernetes 配置の場合、MongoDB リソースにこれらを設定しないでください。
spec.externalMembers型:
ExternalMemberオブジェクトの配列移行の一部であるバーチャル マシンまたはベアメタル ソース プロセス。このフィールドは移行専用です。
このリストからエントリーを除くことはできます。ただし、移行が開始した後はエントリーを追加してはなりません。
spec.externalMembersリストが空の場合、移行は完了しています。
spec.externalMembers[].processName型: string
必須
このフィールドは移行専用です。オートメーション構成の
processes配列内に表示されるプロセス名と完全に同じもの。
名前の上書き
これらのフィールドは移行専用であり、Kubernetes 演算子がそれ以外の場合に使用または生成するリソースまたはオートメーションの構成名を上書きします。
spec.replicaSetNameOverride型: string
このフィールドは移行専用です。Kubernetesリソース名と異なる場合、またはオートメーション構成のレプリカセット名が有効なKubernetes名でない場合の、オートメーション構成のレプリカセット名。
kubectl mongodb migrate-to-mckプラグインは、その--resource-name-overrideフラグを通じてこのフィールドを自動的に設定します。
spec.configServerNameOverride型: string
このフィールドは移行専用です。オートメーションコンフィギュレーションに表示されるコンフィギュレーションサーバーのレプリカセット名。
spec.shardNameOverrides型:
ShardNameOverrideオブジェクトの配列このフィールドは移行専用です。シャードごとのオートメーション構成には、レプリカセット名とシャード
_idが含まれます。注意
spec.shardNameOverridesとspec.shardOverridesを混同しないでください。spec.shardOverridesはシャードごとのリソース設定を行いますが、移行名命とは無関です。Kubernetes
StatefulSet名は、これらの上書きによって影響を受けることはありません。
構成可能な オートメーション Config パス
Kubernetes 演算子は以前、これらのオートメーション構成設定をハードコードしていました。移行には、Kubernetes の配置が、既にソースの仮想マシン上で使用されているパスと一致させることができるように、それらを構成可能にする必要があります。
spec.downloadBase型: string
デフォルト:
/var/lib/mongodb-mms-automationMongoDB Agent がエージェント バイナリをダウンロードするディレクトリ。Kubernetes 演算子は、この設定からキーファイルのパスを
<downloadBase>/keyfileとして導出します。
spec.security.tls.caFilePath型: string
デフォルト:
/mongodb-automation/tls/ca/ca-pemKubernetes演算子がポッド内のCA証明書をプロジェクトする絶対パス。このパスには、少なくとも2つのパスセグメントが含まれている必要があります。アプリケーションデータベースではサポートされていません。
注意
ポッドテンプレートがこのパス以上でボリュームをマウントする場合、マウントによって投影されたCAファイルが隠れる可能性があります。カスタム値を設定する前に、
podTemplateボリュームマウントを検討してください。
spec.security.authentication.agents.autoPEMKeyFilePath型: string
データベースポッド内のMongoDB Agentの結合PEMファイルの絶対パス。このフィールドを設定すると、MongoDB Ops ManagerまたはCloud Managerの
tls.autoPEMKeyFilePath値が設定され、spec.security.authentication.agents.clientCertificateSecretRefによって参照されるシークレットがそのパスにマウントされます。spec.security.authentication.agents.clientCertificateSecretRefが必要です。移行されていない配置に対してKubernetes演算子が使用するハッシュされたエージェント証明書のマウントパスにデフォルト設定されます。
状態条件
status.conditionsType: Kubernetes Conditionsの配列
typeをキーとしている標準的な Kubernetes の状態。このフィールドはMongoDBリソースに新しく追加され、移行をサポートします。
status.conditions[type=Migrating]タイプ: Kubernetes condition
移行がアクティブかどうかを示す最上位のインジケーター。
spec.externalMembersが空でない間はstatusはTrueであり、最後の外部ノードを除くと理由MigrationCompleteでFalseに切り替わります。理由ステータス意味ValidatingTrueドライラン アノテーションが設定されています。
ExtendingTrue目的のKubernetesノード数が、最後に調整された数を超えています。
PruningTrueexternalMembersの数がstatus.migrationObservedExternalMembersCountを下回りました。InProgressTrue外部ノードは存在しますが、何も変わっていません。これも最初の調整時の理由です。
MigrationCompleteFalseすべての外部ノードが削除されました。
優先順位は
Validating>Extending>Pruning>InProgressです。Kubernetes 側の削除と拡大の両方を行うプルーンはExtendingを報告します。これもまた、変更を1つずつ行う別の理由です。Pruningとextendingを同時に行うことはできません。
移行の完了をスクリプトで処理するには、
status.phaseをポーリングするのではなく、kubectl wait --for=condition=Migrating=Falseを使用してください。
status.conditions[type=NetworkConnectivityVerified]タイプ: Kubernetes condition
ドライラン接続チェックの結果。Kubernetes 演算子は、外部ノードがなくなると、
status.conditionsからこの状態を完全に除きます。バリデーター ジョブ 終了コード条件ステータス理由意味ジョブが実行中です
UnknownRunningstatus.phaseはConnectivityCheckRunningです。0TrueNetworkValidationPassedすべての外部ノードは到達可能であり認証済みです。
2FalseAuthenticationFailed認証情報、認証メカニズム、または不足している
__system@localロール。3FalseNetworkFailedDNS、TLS、タイムアウト、または到達不能なノード。ジョブPodのログを確認します。
1またはその他FalseUnknownError未分類の障害。ジョブ Pod ログを確認する。
ジョブの開始前に発生する失敗は、
OperatorImageUnknown、BuildStatefulSetOptions、AgentCertSecretFailed、AgentCertSubjectの理由を使用します。Kubernetes 演算子は、外部ノードがなくなると、
status.conditionsからNetworkConnectivityVerified状態を完全に除きます。
status.migrationObservedExternalMembersCountタイプ: 整数
Kubernetes 演算子が前回の調整で確認した
spec.externalMembersエントリの数。Kubernetes Operatorは、次の調整時にこの値を現在のspec.externalMembersカウントと比較して、外部ノードを削除したことを検出します。外部ノードが残っていない場合、このフィールドは設定されません。注意
Go 構造体の埋め込みの副作用として、このフィールドは
MongoDBOpsManagerカスタム リソース スキーマにも表示されます。MongoDBOpsManagerリソース上では、フィールドは常に null です。そこでは無視してください。
注釈
移行固有の注意が必要な関連フィールド
次の存在する MongoDB リソース フィールドは、移行専用ではありませんが、移行中に特定の値または検討する必要があります。
spec.members、spec.mongodsPerShardCount、spec.configServerCount、およびspec.mongosCountはすべて、kubectl mongodb migrate-to-mckプラグインが生成するリソースの0から始まります。spec.memberConfig[].votes(整数、デフォルトでは1)とspec.memberConfig[].priority(浮動小数点数を含む string、デフォルトでは"1")。少なくとも と同じ数の エントリを提供する必要があります。spec.memberConfigspec.membersKubernetes Operatorspec.memberConfigspec.topologyは、 が の場合にのみ、シャーディングされたクラスターの最上位MultiClusterを無視します。単一クラスターのシャーディングされたクラスターの場合、最上位の は、spec.memberConfigspec.shardOverridesエントリに一致するなしでコンフィギュレーションサーバーノードとすべてのシャードのノードを構成します。kubectl mongodb migrate-to-mckプラグインは を生成せず、spec.memberConfigKubernetes Operator は新しいノードをデフォルトで非投票にしないため、新しいノードの同期中は CRD1"1"のデフォルトである と は誤りです。警告
spec.memberConfig を設定するノード数を増やす前に
デフォルトでは、新しい Kubernetes ノードは投票ノードとして参加します。CRD デフォルトは
votes: 1とpriority: "1"です。これらのデフォルトにより、同期中のノードは最初の同期が完了する前に選挙に参加できます。MongoDB は、ノード数を増やす前に、
votes: 0とpriority: "0"を使用して、新しい Kubernetes ノードごとにspec.memberConfigエントリを 1 つ書き込み (write)することを推奨します。これにより、まだ同期中のノードが選挙に勝つことができなくなります。votesは整数です。priorityは string です。ソース配置と完全に一致する必要があるフィールド:
spec.version、spec.featureCompatibilityVersion、spec.additionalMongodConfig.net.port、spec.security.authentication.modes、およびspec.security.authentication.internalCluster。