Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets. Learn more >
MongoDB Event
Docs Menu
Docs Home
/
Enterprise Kubernetes 演算子
/

前提条件

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

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

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

MongoDB Enterprise Kubernetes Operatorリポジトリをクローンします。

git clone https://github.com/mongodb/mongodb-enterprise-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 1v.17 以降をインストールします。

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

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

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

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

    helm template --show-only \
    templates/database-roles.yaml \
    mongodb/enterprise-operator \
    --set namespace=mongodb | \
    kubectl apply -f - \
    --context=$MDB_CLUSTER_1_FULL_NAME \
    --namespace mongodb
    helm template --show-only \
    templates/database-roles.yaml \
    mongodb/enterprise-operator \
    --set namespace=mongodb | \
    kubectl apply -f - \
    --context=$MDB_CLUSTER_2_FULL_NAME \
    --namespace mongodb
    helm template --show-only \
    templates/database-roles.yaml \
    mongodb/enterprise-operator \
    --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 Operator は、それがインストールされている名前空間にスコープが設定されています。 Kubernetes Operator は、MongoDBMultiCluster Kubernetes Operator と同じ名前空間に配置された リソースを調整します。

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

Kubernetes Operator が マルチ Kubernetes クラスターMongoDBデプロイを作成すると、 Kubernetes OperatorMongoDBmongodb 名前空間内の リソースの監視を開始します。

サブセットまたはすべての名前空間に配置するための正しい権限で 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 インスタンスの実行をサポートしていますか」も参照してください。

MongoDBデプロイのスコープを多数の 名前空間 に設定すると、 Kubernetes Operator を構成して、MongoDB MongoDBデプロイでこれらの名前空間の リソースを監視できます。

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

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

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

helm upgrade \
--install \
mongodb-enterprise-operator-multi-cluster \
mongodb/enterprise-operator \
--namespace mongodb \
--set namespace=mongodb \
--version <mongodb-kubernetes-operator-version>\
--set operator.name=mongodb-enterprise-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デプロイのスコープを、デフォルトの 名前空間ではなく、すべての名前空間に設定すると、 Kubernetes Operator を構成して、マルチmongodbMongoDB Kubernetes クラスターMongoDBデプロイ内のすべての名前空間で リソースを監視できます。

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

WATCH_NAMESPACE: "*"

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

helm upgrade \
--install \
mongodb-enterprise-operator-multi-cluster \
mongodb/enterprise-operator \
--namespace mongodb \
--set namespace=mongodb \
--version <mongodb-kubernetes-operator-version>\
--set operator.name=mongodb-enterprise-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 Operator はレプリカセット内のホスト名を ヘッドレス サービス の FQDN として構成します。これは、 MongoDBインスタンスをホストしている各ポッドの直接IPアドレスの DNS をポッドの 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 配置ポッドに対して、Kubernetes Operator はMongoDBMultiClusterリソース内のspec.duplicateServiceObjects: true構成を介して ClusterIP サービスを作成します。 各プロセスには、このサービスのFQDN : <pod-name>-svc.<namespace>.svc.cluster.localにホスト名が定義されています。 これらのホスト名は、DNS から各ノードクラスター内のサービスの ClusterIP に解決されます。

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

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

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-enterprise-kubernetes/master/tools/multicluster/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 Operator は kubernetes.io/tls シークレット を使用して、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

MongoDB Enterprise Kubernetes Operator リポジトリのリリース ページから、ご希望の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を構成する方法は、次のとおりです。

2

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

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

中央クラスターで実行されるKubernetes Operator は、 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>

戻る

サービスとツール