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

マルチクラスター配置の前提条件

クイック スタートまたは配置手順を使用して、複数の Kubernetes クラスター MongoDB 配置を作成する前に、次のタスクを完了してください。

クイック スタートに固有の前提条件の詳細については、「クイック スタートの前提条件 」を参照してください。

サポートされているハードウェア アーキテクチャを参照してください。

Kubernetes Operatorリポジトリ用のMongoDBコントロール をクローンします。

git clone https://github.com/mongodb/mongodb-kubernetes.git

以下の例のように、クラスターを配置するクラスター名を含む環境変数を設定します。

export MDB_CENTRAL_CLUSTER_FULL_NAME="mdb-central"
export MDB_CLUSTER_1_FULL_NAME="mdb-1"
export MDB_CLUSTER_2_FULL_NAME="mdb-2"
export MDB_CLUSTER_3_FULL_NAME="mdb-3"

次のツールをインストールします。

  1. Go v1.17 をインストール以降に更新します。

  2. Helm をインストールします。

マルチ Kubernetes クラスターMongoDBデプロイを使用するには、Kubernetesロール、ClusterRolesRoleBindings、ClusterRoleBindings、およびServiceAccountの特定のセットが必要です。これらは、次のいずれかの方法で構成できます。

  • マルチKubernetes-クラスター クイック スタート 」では、 を使用して必要なオブジェクトを自動的に作成し、それをマルチ KubernetesMongoDB クラスターMongoDB 配置内の適切なクラスターに適用する方法について説明しています。

  • Helm を使用して、必要なKubernetesロールとサービス アカウントを各ノード クラスターに構成します。

    helm template --show-only \
    templates/database-roles.yaml \
    mongodb/mongodb-kubernetes \
    --set namespace=mongodb | \
    kubectl apply -f - \
    --context=$MDB_CLUSTER_1_FULL_NAME \
    --namespace mongodb
    helm template --show-only \
    templates/database-roles.yaml \
    mongodb/mongodb-kubernetes \
    --set namespace=mongodb | \
    kubectl apply -f - \
    --context=$MDB_CLUSTER_2_FULL_NAME \
    --namespace mongodb
    helm template --show-only \
    templates/database-roles.yaml \
    mongodb/mongodb-kubernetes \
    --set namespace=mongodb | \
    kubectl apply -f - \
    --context=$MDB_CLUSTER_3_FULL_NAME \
    --namespace mongodb
  • Kubernetes オブジェクト.yamlファイルを手動で作成し、 kubectl applyコマンドを使用して必要な Kubernetes クラスターの MongoDB 配置に必要な Kubernetes ロールとサービス アカウントを追加します。 これは、特定の高度に自動化されたワークフローで必要になる場合があります。 MongoDB はサンプル構成ファイルを提供します。

    名前空間のサブセットにスコープが設定されたカスタム リソースの場合:

    クラスター全体の名前空間にスコープが設定されたカスタム リソースの場合:

    各ファイルは複数のリソースを定義します。 配置をサポートするには、次のフィールドのプレースホルダー値を置き換える必要があります。

    • subjects.namespaceRoleBindingまたはClusterRoleBindingリソース

    • metadata.namespaceServiceAccountリソース

    定義を変更したら、各ファイルに対して次のコマンドを実行してそれらを適用します。

    kubectl apply -f <fileName>

デフォルトで、マルチクラスター Kubernetes 演算子は、インストした名前空間にスコープされます。Kubernetes Operator は、Kubernetes Operator と同じ名前空間に配置された MongoDBMultiCluster リソースを調整します。

マルチクラスター クイックスタート の一部として MongoDB kubectl プラグイン を実行し、kubectl mongodb プラグイン設定を変更しない場合、プラグインは次のようになります。

Kubernetes 演算子がマルチ Kubernetes クラスターMongoDB配置を作成すると、Kubernetes 演算子はmongodb 名前空間内の MongoDB リソースの監視を開始します。

サブセットまたはすべての名前空間に配置するための正しい権限で Kubernetes Operator を構成するには、次のコマンドを実行し、Kubernetes Operator が監視する名前空間を指定します。

kubectl mongodb multicluster setup \
--central-cluster="${MDB_CENTRAL_CLUSTER_FULL_NAME}" \
--member-clusters="${MDB_CLUSTER_1_FULL_NAME},${MDB_CLUSTER_2_FULL_NAME},${MDB_CLUSTER_3_FULL_NAME}" \
--member-cluster-namespace="mongodb2" \
--central-cluster-namespace="mongodb2" \
--create-service-account-secrets \
--cluster-scoped="true"

マルチ Kubernetes クラスターMongoDBデプロイを複数またはすべての名前空間 にインストールすると、 Kubernetes演算子を次のように構成できます。

注意

1 つの Kubernetes Operator インスタンスをインストールして設定し、別の名前空間の重複しないサブセット内の 1 つ、複数、またはすべてのカスタム リソースを監視するように構成します。 「 MongoDB は複数の Kubernetes Operator インスタンスの実行をサポートしていますか」も参照してください。

マルチKubernetesクラスターMongoDB配置のスコープを多数の 名前空間 に設定すると、Kubernetes Operatorを構成して、マルチKubernetesクラスターMongoDB配置内のこれらの名前空間にあるMongoDBリソースを監視できます。

Kubernetes spec.template.spec.containers.name.env.name:WATCH_NAMESPACEOperator Githubリポジトリ用のMongoDBコントロールから mongodb-kubernetes.YAMLファイルの を、 Kubernetes Operator に監視する名前空間のカンマ区切りリストに設定します。

WATCH_NAMESPACE: "$namespace1,$namespace2,$namespace3"

次のコマンドを実行し、最後の行の値を Kubernetes Operator が監視する名前空間に置き換えます。

helm upgrade \
--install \
mongodb-kubernetes-operator-multi-cluster \
mongodb/mongodb-kubernetes \
--namespace mongodb \
--set namespace=mongodb \
--version <mongodb-kubernetes-operator-version>\
--set operator.name=mongodb-kubernetes-operator-multi-cluster \
--set operator.createOperatorServiceAccount=false \
--set operator.createResourcesServiceAccountsAndRoles=false \
--set "multiCluster.clusters={$MDB_CLUSTER_1_FULL_NAME,$MDB_CLUSTER_2_FULL_NAME,$MDB_CLUSTER_3_FULL_NAME}" \
--set operator.watchNamespace="$namespace1,$namespace2,$namespace3"

マルチ Kubernetes クラスター MongoDB 配置のスコープをデフォルトの mongodb 名前空間ではなく、すべての 名前空間に設定すると、 Kubernetes Operator を構成して、マルチ Kubernetes クラスター MongoDB 配置内のすべての名前空間で MongoDB リソースを監視できます。

mongodb-kubernetes.YAMLspec.template.spec.containers.name.env.name:WATCH_NAMESPACE"*" に設定します。YAMLファイル内のアスタリスク(*)の前後に二重引用符(")を含める必要があります。

WATCH_NAMESPACE: "*"

次のコマンドを実行します:

helm upgrade \
--install \
mongodb-kubernetes-operator-multi-cluster \
mongodb/mongodb-kubernetes \
--namespace mongodb \
--set namespace=mongodb \
--version <mongodb-kubernetes-operator-version>\
--set operator.name=mongodb-kubernetes-operator-multi-cluster \
--set operator.createOperatorServiceAccount=false \
--set operator.createResourcesServiceAccountsAndRoles=false \
--set "multiCluster.clusters={$MDB_CLUSTER_1_FULL_NAME,$MDB_CLUSTER_2_FULL_NAME,$MDB_CLUSTER_3_FULL_NAME}" \
--set operator.watchNamespace="*"

サービス メトリクスは、異なる Kubernetes クラスターに配置されたレプリカセット ノード間のクラスター間通信を可能にします。 サービス メトリクスを使用すると、複数の Kubernetes クラスター MongoDB 配置の作成が大幅に簡素化され、MongoDB を複数の Kubernetes クラスターに配置する推奨方法になります。 ただし、IT 組織でサービス メトリクスを使用していない場合は、Kubernetes クラスターの MongoDB 配置にレプリカセットを使用せずに配置できます。

環境に応じて、次の操作を行います。

配置のタイプに関係なく、Kubernetes に MongoDB を配置するには次の接続を確立する必要があります。

  • ポッドのMongoDB Ops Manager MongoDB Agentからその mongod プロセスへ、 MongoDB配置のライフサイクル管理とモニタリングを有効にします。

  • ポッドのMongoDB Ops Manager MongoDB AgentからMongoDB Ops Managerインスタンスへ、自動化を有効にします。

  • すべてのmongodプロセス間で、レプリケーションを許可します。

Kubernetes Operator が MongoDB リソースを配置する際、配置のタイプに応じて、これらの接続要件を次の方法で処理します。

  • 単一の Kubernetes クラスター配置では、Kubernetes 演算子はレプリカセット内のホスト名を ヘッドレスサービス の FQDN として構成します。これは、MongoDB インスタンスをホストする各 Pod の直接 IP アドレスの DNS を Pod の FQDN で解決する単一のサービスです(次のように: <pod-name>.<replica-set-name>-svc.<namespace>.svc.cluster.local)。

  • サービス メトリクスを使用する複数の Kubernetes クラスター MongoDB 配置では、Kubernetes Operator は Kubernetes クラスター内の各 MongoDB レプリカセット ノードに対して個別の ステートメントを作成します。 サービス キャッシュを使用すると、個別の Kubernetes クラスター全体でmongodプロセス間の通信が可能になります。

    サービス メトリクスを使用すると、マルチ Kubernetes クラスター MongoDB 配置で次のことが可能になります。

    • Kubernetes クラスター間でグローバル DNS ホスト名解決を実現し、クラスター間の接続性を確立します。各 Kubernetes クラスターの各 MongoDB 配置 Pod について、Kubernetes 演算子は MongoDBMultiCluster リソースの spec.duplicateServiceObjects: true 設定を使用して ClusterIP サービスを作成します。各プロセスには、このサービスの FQDN に定義されたホスト名があります: <pod-name>-svc.<namespace>.svc.cluster.local。これらのホスト名は、DNS から各ノード クラスターのサービスの ClusterIP に解決されます。

    • 異なる Kubernetes クラスターのポッド間の通信を確立します。 その結果、異なるクラスターでホストされているレプリカセット ノードは、これらのクラスター全体で単一のレプリカセットを形成します。

  • サービス メッシュを使用しない複数の Kubernetes クラスター MongoDB 配置では、Kubernetes 演算子は、次の MongoDBMultiCluster リソース設定を使用してすべての mongod プロセスを外部に公開します。これにより、個別の Kubernetes クラスター間でホスト名の DNS 解決が可能になります。また、これらのクラスターを接続するネットワークを介してルーティングされる Pod 間の接続が確立されます。

Istio のドキュメントを使用して、異なるネットワーク に Istio をマルチプライマリモードでインストールします。Istio は、DNS 解決を簡素化し、 MongoDBデプロイでノードKubernetesクラスター間のクラスター間通信を確立するのに役立つサービス メトリクスです。サービス メトリクスを使用する場合は、それをインストールする必要があります。サービス メトリクスを利用できない場合は、このセクションをスキップして、外部ドメインを使用し、DNS を設定して外部接続を有効にします。

さらに、Install_istio_個別_例スクリプトを提供しています。このスクリプトは Istio のドキュメントに基づいており、さまざまなネットワークでマルチプライマリモードを使用するインストールの例を示しています。今後の Istio リリースでスクリプトのメンテナンスを保証することはありません。スクリプトを使用する場合は、 マルチクラスターのインストール に関する最新の Istio ドキュメントを確認し、必要に応じてドキュメントと配置が一致するようにスクリプトを調整します。別のサービス キャッシュ ソリューションを使用する場合は、DNS 解決を容易にするために個別のネットワークを構成するための独自のスクリプトを作成します。

サービス メッシュを使用しない場合は、次の操作を行って、 mongodプロセスと MongoDB Ops Manager MongoDB Agent との間で外部接続を有効にします。

  • MongoDB の複数の Kubernetes クラスター配置を作成する場合は、 spec.clusterSpecList.externalAccess.externalDomainの 設定で外部ドメインを指定し、Kubernetes Operator に次のパターンでmongodプロセスのホスト名を構成するように指示します。

    <pod-name>.<externalDomain>

    注意

    外部ドメインは新しい配置でのみ指定できます。 マルチ Kubernetes クラスター MongoDB 配置を構成した後は、外部ドメインを変更できません。

    この方法で外部ドメインを構成すると、MongoDB Ops Manager MongoDB エージェントとmongodプロセスはこのドメインを使用して相互に接続します。

  • Kubernetes Operator が Kubernetes クラスター内の各ポッドに対して作成する外部サービスをカスタマイズします。 spec.externalAccessでのグローバル構成の使用 設定と Kubernetes クラスター固有のオーバーライド( spec.clusterSpecList.externalAccess.externalService 内) 設定。

  • DNSゾーンで ポッド ホスト名を設定して、 mongodプロセスをホストする各 Kubernetes ポッドが、マルチ Kubernetes クラスター MongoDB 配置で他のmongodプロセスへの外部接続を確立できるようにします。 ポッドは「外部で公開されている」と見なされ、ポート27017 (デフォルトのデータベース ポート)とポート27018 <pod-name>.<externalDomain>ホスト名を使用してmongodプロセスに接続できる場合、(これはデータベース ポート + 1 )。 また、ポート27017と27018で TCP トラフィックを許可するようにファイアウォール ルールを構成する必要がある場合があります。

これらの前提条件を完了したら、サービス メトリクスなしでマルチ Kubernetes クラスターを配置できます。

この手順の手順に従って、Kubernetes クラスター全体でサービスFQDNにアクセスできることを確認します。

この例では、sample-service.YAML で定義されたサンプルアプリケーションを 2 つのKubernetesクラスターにわたって配置します。

1

各 Kubernetes クラスターに名前空間を作成して、 sample-service.yamlを配置します。

kubectl create --context="${CTX_CLUSTER_1}" namespace sample
kubectl create --context="${CTX_CLUSTER_2}" namespace sample

注意

特定のサービス メッシュ ソリューションでは、名前空間に注釈を付けたりラベルを付けたりする必要がある場合があります。

2
kubectl apply --context="${CTX_CLUSTER_1}" \
-f sample-service.yaml \
-l service=helloworld1 \
-n sample
kubectl apply --context="${CTX_CLUSTER_2}" \
-f sample-service.yaml \
-l service=helloworld2 \
-n sample
3
kubectl apply --context="${CTX_CLUSTER_1}" \
-f sample-service.yaml \
-l version=v1 \
-n sample
4

CLUSTER_1ホスティング ポッドがRunning状態であることを確認します。

kubectl get pod --context="${CTX_CLUSTER_1}" \
-n sample \
-l app=helloworld
5
kubectl apply --context="${CTX_CLUSTER_2}" \
-f sample-service.yaml \
-l version=v2 \
-n sample
6

CLUSTER_2ホスティング ポッドがRunning状態であることを確認します。

kubectl get pod --context="${CTX_CLUSTER_2}" \
-n sample \
-l app=helloworld
7

CLUSTER_1で ポッドを配置し、 CLUSTER_2のサンプル アプリケーションにアクセスできることを確認します。

kubectl run --context="${CTX_CLUSTER_1}" \
-n sample \
curl --image=radial/busyboxplus:curl \
-i --tty \
curl -sS helloworld2.sample:5000/hello

この例のような出力が表示されます。

Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
8

CLUSTER_2で ポッドを配置し、 CLUSTER_1のサンプル アプリケーションにアクセスできることを確認します。

kubectl run --context="${CTX_CLUSTER_2}" \
-n sample \
curl --image=radial/busyboxplus:curl \
-i --tty \
curl -sS helloworld1.sample:5000/hello

この例のような出力が表示されます。

Hello version: v1, instance: helloworld-v1-758dd55874-6x4t8

クイック スタートの一部として、中央クラスターにMongoDB Ops Managerリソースを配置します。

TLS暗号化を使用して複数の Kubernetes クラスター MongoDB 配置を保護する場合は、次のタスクを実行して内部クラスター認証を有効にし、ノードクラスターと MongoDB Agent のTLS証明書を生成します。

注意

CA証明書と、 TLS証明書の署名に使用したキーが必要です。

1

次のいずれかのオプションを使用します。

  • Kubernetes Operator が配置内の各ポッドに対して作成するサービスのホスト名をカバーするワイルドカードTLS証明書を生成します。

    ワイルドカード証明書を生成した場合、障害復旧など、Kubernetes ノードクラスター内のノードをスケールアップまたは再バランス化する際にも、同じ証明書を使用し続けることができます。

    たとえば、次の形式のようなホスト名をSANに追加します。

    *.<namespace>.svc.cluster.local
  • Kubernetes Operator が各ノードクラスター内の各ポッドに対応するように生成する Kubernetes サービスごとに、証明書にSANを追加します。 TLS証明書では、各 Kubernetes サービスのSANは次の形式を使用する必要があります。

    <metadata.name>-<member_cluster_index>-<n>-svc.<namespace>.svc.cluster.local

    ここで、 n0からclusterSpecList[member_cluster_index].members - 1の範囲です。

2

MongoDB Agent TLS証明書の場合:

  • TLS証明書のコモン ネームは空であってはなりません。

  • TLS証明書内の組織と組織単位の組み合わせは、レプリカ セット ノードのTLS証明書内の組織および組織単位と異なる必要があります。

Kubernetesクラスターの TLS 証明書の作成を高速化するために、 set_tlsスクリプト を提供します。スクリプトのメンテナンスは保証されません。スクリプトを使用する場合は、テストして、ニーズに合わせて調整してください。スクリプトは、次の処理を実行します。

  • cert-manager接続されたクラスターに 名前空間を作成し、 cert-manager名前空間の Helm を使用して証明書マネージャーをインストールします。

  • mkcert を使用してローカル CA をインストールします。

  • downloads.mongodb.comからTLS証明書をダウンロードし、 CAファイル名とca-chainに連結します。

  • ca-chainファイルを含む ConfigMap を作成します。

  • 証明書マネージャーが証明書の生成に使用するIssuerリソースを作成します。

  • 証明書マネージャーが証明書のキー オブジェクトを作成するために使用するCertificateリソースを作成します。

スクリプトを使用するには、次のようにします。

1

このスクリプトを実行する予定のマシンに mkcert をインストールします。

2
kubectl --context $MDB_CENTRAL_CLUSTER_FULL_NAME \
--namespace=<metadata.namespace> \
3
curl https://raw.githubusercontent.com/mongodb/mongodb-kubernetes/master/scripts/release/kubectl-mongodb/setup_tls.sh -o setup_tls.sh

出力には、次のものが含まれます。

  • ca-key-pairという名前のCAを含むシークレット。

  • 中央 n clustercert-${resource}-certのサーバー証明書を含むシークレット。

  • issuer-caという名前のCA証明書を含む ConfigMap

4

MongoDB Agent TLS証明書の場合:

  • TLS証明書のコモン ネームは空であってはなりません。

  • TLS証明書内の組織と組織単位の組み合わせは、レプリカ セット ノードのTLS証明書内の組織および組織単位と異なる必要があります。

1

次のいずれかのオプションを使用します。

2

MongoDB Agent TLS証明書の場合:

  • TLS証明書のコモン ネームは空であってはなりません。

  • TLS証明書内の組織と組織単位の組み合わせは、レプリカ セット ノードのTLS証明書内の組織および組織単位と異なる必要があります。

重要

Kubernetes演算子は kubernetes.io/tls を使用しますMongoDB Ops Manager とMongoDBリソースの TLS 証明書と秘密キーを保存するためのシークレット。Kubernetes Operator1 17バージョン..0 以降、 Kubernetes Operator は Opaque シークレットとして保存される連結 PEM ファイルをサポートしていません。

GitOps 環境で MongoDBMultiCluster リソースの配置に必要なリソース ファイルを作成および維持することを選択できます。

GitOps ワークフローを使用する場合、 kubernetl MongoDBプラグイン は使用できません。これは、ロールベースのアクセス制御(RBAC)を自動的に構成し、演算子クラスターがノードクラスターと通信できるようにする kubeconfigファイルを作成します。代わりに、GitOps のリソース構成 の手順と例に基づいて、RBAC と kubeconfig ファイルを構成するための独自のオートメーションを手動で構成またはビルドする必要があります。

次の前提条件セクションでは、GitOps を使用しない場合は kubernetl MongoDB プラグインをインストールする方法、または GitOps を使用する場合は GitOps 用のリソースを構成する方法について説明します。

kubectl mongodbプラグインを使用して次の操作を行います。

注意

GitOps を使用する場合、kubectl mongodb プラグインは使用できません。代わりに、「GitOps のリソースの構成」の手順に従ってください。

kubectl MongoDB プラグインをインストールするには、次の手順で操作します。

1

Kubernetes Operator リポジトリ用のMongoDBコントロールのリリース ページから、ご希望のKubernetes Operatorパッケージバージョンをダウンロードします。

パッケージの名前には次のパターンが使用されます: kubectl-mongodb_{{ .Version }}_{{ .Os }}_{{ .Arch }}.tar.gz

次のいずれかのパッケージを使用します。

  • kubectl-mongodb_{{ .Version }}_darwin_amd64.tar.gz

  • kubectl-mongodb_{{ .Version }}_darwin_arm64.tar.gz

  • kubectl-mongodb_{{ .Version }}_linux_amd64.tar.gz

  • kubectl-mongodb_{{ .Version }}_linux_arm64.tar.gz

2

次の例のように、 パッケージを解凍します。

tar -zxvf kubectl-mongodb_<version>_darwin_amd64.tar.gz
3

解凍された ディレクトリでkubectl-mongodbバイナリを見つけ、次の例に示すように、Kubernetes Operator ユーザーの PATH 内にある目的の宛先に移動します。

mv kubectl-mongodb /usr/local/bin/kubectl-mongodb

これで、次のコマンドを使用してkubectl mongodbプラグインを実行できるようになります。

kubectl mongodb multicluster setup
kubectl mongodb multicluster recover

サポートされているフラグの詳細については、 MongoDB kubernetes プラグイン リファレンス を参照してください。

GitOps ワークフローを使用する場合は、 kubernetl MongoDBプラグイン を使用して、オペレータークラスターがノードクラスターと通信できるようにするロールベースのアクセス制御(RBAC)または kubeconfigファイルを自動的に構成することはできません。代わりに、次のリソースファイルを手動で構成して適用するか、以下の情報に基づいて独自のオートメーションをビルドする必要があります。

注意

kubectl MongoDB プラグインが次の手順を自動化する方法については、Githubでコードを表示します。

GitOps 用に RBAC とkubeconfigを構成する方法は、次のとおりです。

1

これらの RBACリソースの例を使用して、独自のリソースを作成します。これらの RBAC リソースの詳細については、「 Kubernetesロールとロール バインディングの理解 」を参照してください。

GitOps を使用して中央クラスターとノード クラスターにこれらを適用するには、Argo CD などのツールを使用できます。

2

Kubernetes Operator は、ConfigMapファイルを使用してノード クラスターを追跡します。次の例の ConfigMap をコピー、変更、および適用します。

apiVersion: v1
kind: ConfigMap
data:
cluster1: ""
cluster2: ""
metadata:
namespace: <namespace>
name: mongodb-kubernetes-operator-member-list
labels:
multi-cluster: "true"
3

演算子クラスター内で実行されるKubernetes演算子 は、 Kubernetes APIを介してノードクラスター内のポッドと通信します。これを機能させるには、 Kubernetes Operator は、ノードクラスターのサービス アカウント トークンを含む kubeconfigファイル を必要とします。この kubeconfigファイルを次の手順で作成します。

  1. Kubernetes Operator の名前空間に構成されたサービス アカウントのリストを取得します。例、デフォルトのmongodb名前空間を使用することを選択した場合は、次のコマンドを使用してサービス アカウントを取得できます。

    kubectl get serviceaccounts -n mongodb
  2. ノードクラスターに属する各サービス アカウントのシークレットを取得します。

    kubectl get secret <service-account-name> -n mongodb -o yaml
  3. 各サービス アカウント シークレットで、 CA証明書とトークンをコピーします。 たとえば、次の例に示すように、シークレットから<ca_certificate><token>をコピーします。

    apiVersion: v1
    kind: Secret
    metadata:
    name: my-service-account
    namespace: mongodb
    data:
    ca.crt: <ca_certificate>
    token: <token>
  4. 演算子クラスターの次の kubeconfig の例をコピーし、以下に示すコマンドを実行中、プレースホルダーをサービス アカウントのシークレットからコピーした <ca_certificate><token> に置き換えます。

    apiVersion: v1
    clusters:
    - cluster:
    certificate-authority:
    server: https://
    name: kind-e2e-cluster-1
    - cluster:
    certificate-authority:
    server: https://
    name: kind-e2e-cluster-2
    contexts:
    - context:
    cluster: kind-e2e-cluster-1
    namespace: mongodb
    user: kind-e2e-cluster-1
    name: kind-e2e-cluster-1
    - context:
    cluster: kind-e2e-cluster-2
    namespace: mongodb
    user: kind-e2e-cluster-2
    name: kind-e2e-cluster-2
    kind: Config
    users:
    - name: kind-e2e-cluster-1
    user:
    token:
    - name: kind-e2e-cluster-2
    user:
    token:

    次の kubectl コマンドに正しい値を入力し、実行して kubeconfigファイルの例を更新します。

    kubectl config --kubeconfig=kubeconfig set-cluster kind-e2e-cluster-1 --certificate-authority=<cluster-1-ca.crt>
    kubectl config --kubeconfig=kubeconfig set-cluster kind-e2e-cluster-2 --certificate-authority=<cluster-2-ca.crt>
    kubectl config --kubeconfig=kubeconfig set-credentials kind-e2e-cluster-1 --token=<cluster-1-token>
    kubectl config --kubeconfig=kubeconfig set-credentials kind-e2e-cluster-2 --token=<cluster-2-token>
  5. 参照Helmチャートに示されているように、 Kubernetes Operator にマウントする演算子クラスターにシークレットを作成します。(例: )。

    kubectl --context="${CTX_CENTRAL_CLUSTER}" -n <operator-namespace> create secret --from-file=kubeconfig=<path-to-kubeconfig-file> <kubeconfig-secret-name>