前提条件
項目一覧
- サポートされているハードウェア アーキテクチャの確認
- MongoDB Enterprise Kubernetes Operatorリポジトリのクローン
- 環境変数を設定する
- Go と Helm のインストール
- Kubernetes のロールとロール バインディングの理解
- 配置のスコープを設定する
- 外部接続の計画: サービス メッシュを使用する必要がありますか?
- クラスター間の接続を確認
- MongoDB Ops Managerの配置要件の確認
- TLS 暗号化接続の準備をする
- GitOps または kubernetes MongoDB プラグインを選択する
- kubernetes MongoDB プラグインをインストールする
- GitOps のリソースを構成する
クイック スタートまたは配置手順を使用して、複数の Kubernetes クラスター MongoDB 配置を作成する前に、次のタスクを完了してください。
クイック スタートに固有の前提条件の詳細については、「 クイック スタートの前提条件 」を参照してください。
サポートされているハードウェア アーキテクチャの確認
MongoDB Enterprise Kubernetes Operatorリポジトリのクローン
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"
Go と Helm のインストール
次のツールをインストールします。
Kubernetes のロールとロール バインディングの理解
マルチ Kubernetes クラスター MongoDB 配置を使用するには、Kubernetes ロール、 ClusterRoles の特定のセットが必要です 、 RoleBindings、ClusterRoleBindings 、 、および ServiceAccounts は、次のいずれかの方法で構成できます。
「 マルチKubernetes-クラスター クイック スタート 」では、 を使用して必要なオブジェクトを自動的に作成し、それをマルチ KubernetesMongoDB クラスターMongoDB 配置内の適切なクラスターに適用する方法について説明しています。
ヘルムの 使用 各ノード クラスターに必要な 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.namespace
各RoleBinding
またはClusterRoleBinding
リソースmetadata.namespace
各ServiceAccount
リソース
定義を変更したら、各ファイルに対して次のコマンドを実行してそれらを適用します。
kubectl apply -f <fileName>
配置のスコープを設定する
デフォルトでは、マルチクラスター Kubernetes Operator のスコープは 名前空間 です。 にインストールします。Kubernetes Operator は、Kubernetes Operator と同じ名前空間に配置されたMongoDBMultiCluster
リソースを調整します。
マルチクラスター クイック スタート の一部として MongoDB kubernetes プラグイン を実行し、kubectl mongodb
プラグイン設定を変更しない場合、プラグインは次のようになります。
MongoDB のマルチ配置のすべてのノードクラスターを含む、
mongodb-enterprise-operator-member-list
という名前のデフォルトの ConfigMap を作成します。 この名前はハードコードされており、変更することはできません。 「既知の問題点 」を参照してください。ServiceAccount の 作成 、 ロール、クラスターロール 、 RoleBindings、および ClusterRoleBindings 中央クラスターと各ノード クラスターに含まれます。
サービス アカウントに適切な権限を適用します。
前述の設定を使用して、マルチ Kubernetes クラスター MongoDB 配置を作成します。
Kubernetes Operator が複数の Kubernetes クラスター MongoDB 配置を作成すると、Kubernetes OperatorMongoDB
は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 インスタンスの実行をサポートしていますか」も参照してください。
複数の名前空間でリソースを監視する
MongoDB のマルチ Kubernetes クラスター配置のスコープを多数の 名前空間 に設定すると、 は、マルチMongoDB
Kubernetes クラスター MongoDB 配置でこれらの名前空間内の リソースを監視するように Kubernetes Operator を構成できます。
spec.template.spec.containers.name.env.name:WATCH_NAMESPACE
mongodb-enterprise.YAML で を設定するMongoDBEnterprise Kubernetes OperatorGithub リポジトリからの ファイルで、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"
すべての名前空間でリソースを監視する
MongoDB のマルチ Kubernetes クラスター配置のスコープをすべての 名前空間 mongodb
に設定すると、 デフォルトの 名前空間の代わりに、Kubernetes Operator を構成して、マルチMongoDB
Kubernetes クラスター MongoDB 配置内のすべての名前空間の リソースを監視できます。
spec.template.spec.containers.name.env.name:WATCH_NAMESPACE
mongodb-enterprise.YAML で を設定する"*"
から まで。YAML ファイル内のアスタリスク(*
)の前後にdouble引用符("
)を含める必要があります。
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 配置にレプリカセットを使用せずに配置できます。
環境に応じて、次の操作を行います。
サービス メトリクスを使用できる場合は、 Istio をインストールします。
サービス メトリクスを使用できない場合
Kubernetes Operator はどのように接続を確立しますか。
配置のタイプに関係なく、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 のドキュメントを使用します。Istio は、 DNS解決を簡素化し、Kubernetes クラスター MongoDB のマルチ配置におけるノード Kubernetes クラスター間のクラスター間通信を確立するのに役立つサービス メトリクスです。 サービス メトリクスを使用する場合は、それをインストールする必要があります。 サービス メトリクスを利用できない場合は、このセクションをスキップして、外部ドメインを使用し、DNS を設定して外部接続を有効にします。
さらに、 Install_istio_個別_ネットワーク サンプル スクリプト が提供されています 。このスクリプトは Istio のドキュメントに基づいており、 さまざまなネットワークでマルチプライマリ モード を使用するインストールの例を示しています。 。今後の Istio リリースでスクリプトのメンテナンスを保証することはありません。 スクリプトを使用する場合は、マルチクラスターの インストール に関する最新の Istio ドキュメントを確認してください。 、必要に応じて、ドキュメントと配置に一致するようにスクリプトを調整します。別のサービス キャッシュ ソリューションを使用する場合は、DNS 解決を容易にするために個別のネットワークを構成するための独自のスクリプトを作成します。
外部ドメインと 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 クラスターにわたる場合
CLUSTER_1
がCLUSTER_2
に接続できることを確認します。
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
CLUSTER_2
がCLUSTER_1
に接続できることを確認します。
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の配置要件の確認
クイック スタートの一部として、中央クラスターにMongoDB Ops Managerリソースを配置します。
TLS 暗号化接続の準備をする
TLS暗号化を使用して複数の Kubernetes クラスター MongoDB 配置を保護する場合は、次のタスクを実行して内部クラスター認証を有効にし、ノードクラスターと MongoDB Agent のTLS証明書を生成します。
注意
CA証明書と、 TLS証明書の署名に使用したキーが必要です。
Kubernetes サービスの TLS 証明書を生成します。
次のいずれかのオプションを使用します。
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 ここで、
n
は0
からclusterSpecList[member_cluster_index].members - 1
の範囲です。
メンバー Kubernetes クラスターの TLS 証明書の作成を高速化するために、 set_tls スクリプト を提供します 。スクリプトのメンテナンスは保証されません。 スクリプトを使用する場合は、テストして、ニーズに合わせて調整してください。 スクリプトは、次の処理を実行します。
cert-manager
接続されたクラスターに 名前空間を作成し、 証明書マネージャー をインストールします Helm を使用するcert-manager
( 名前空間内)mkcert を使用してローカル CA をインストールします。
downloads.mongodb.com
からTLS証明書をダウンロードし、 CAファイル名とca-chain
に連結します。ca-chain
ファイルを含む ConfigMap を作成します。証明書マネージャーが証明書の生成に使用する
Issuer
リソースを作成します。証明書マネージャーが証明書のキー オブジェクトを作成するために使用する
Certificate
リソースを作成します。
スクリプトを使用するには、次のようにします。
SAN ホスト名の TLS 証明書を生成します。
次のいずれかのオプションを使用します。
SAN で作成したすべての externalDomain を含むワイルドカード TLS 証明書を生成します。たとえば、次の形式のようなホスト名をSANに追加します。
*.cluster-0.example.com, *.cluster-1.example.com ワイルドカード証明書を生成した場合、障害復旧など、Kubernetes ノードクラスター内のノードをスケールアップまたは再バランス化する際にも、それらの証明書を引き続き使用できます。
SAN 内の各 MongoDB レプリカセット ノード ホスト名に対して TLS 証明書を生成します。たとえば、次のようなホスト名をSANに追加します。
my-replica-set-0-0.cluster-0.example.com, my-replica-set-0-1.cluster-0.example.com, my-replica-set-1-0.cluster-1.example.com, my-replica-set-1-1.cluster-1.example.com 特定のホスト名をすべて含む個別のTLS証明書を生成する場合は、障害復旧など、Kubernetes ノードクラスター内のノードをスケールアップまたは再バランス化するたびに新しい証明書を作成する必要があります。
重要
Kubernetes 演算子は kubernetes.io/tls を使用しますMongoDB Ops Manager と MongoDB リソースのTLS証明書と秘密キーを保存するためのシークレット。 Kubernetes Operator バージョン1 以降。17 。0 、Kubernetes Operator は Opaque シークレット として保存される連結 PEM ファイルをサポートしていません。
GitOps または kubernetes MongoDB プラグインを選択する
GitOps 環境でMongoDBMultiCluster
リソースの配置に必要なリソース ファイルを作成して維持することを選択できます。
GitOps ワークフローを使用する場合、 ロールベースのアクセス制御(RBAC) を自動的に構成する kubernetlMongoDB プラグイン は使用できません および は、中央クラスターがそのノード クラスターと通信できるようにする kubeconfig ファイルを作成します。代わりに、 GitOps のリソース構成の手順と例に基づいて、RBAC とkubeconfig
ファイルを構成するための独自のオートメーションを手動で構成またはビルドする必要があります。
次の前提条件セクションでは、GitOps を使用しない場合は kubernetl MongoDB プラグインをインストールする方法、または GitOps を使用する場合は GitOps 用のリソースを構成する方法について説明します。
kubernetes MongoDB プラグインをインストールする
kubectl mongodb
プラグインを使用して次の操作を行います。
注意
GitOps を使用する場合、 kubectl mongodb
プラグインは使用できません。 代わりに、 「 GitOps のリソースの構成 」の手順に従ってください。
kubectl mongodb
プラグインをインストールするには次の手順に従います。
ご希望の Kubernetes Operator パッケージ バージョンをダウンロードします。
リポジトリのリリースMongoDBEnterprise 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
kubectl mongodb
プラグインバイナリを見つけて、目的の宛先にコピーします。
解凍された ディレクトリで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 のリソースを構成する
GitOps ワークフローを使用している場合、 kubernetlMongoDB プラグイン を使用して ロールベースのアクセス制御(RBAC) を自動的に構成することはできません または、中央クラスターがノード クラスターと通信できるようにする kubeconfig ファイル。代わりに、次のリソース ファイルを手動で構成して適用するか、以下の情報に基づいて独自のオートメーションをビルドする必要があります。
注意
kubectl mongodb
プラグインが次の手順を自動化する方法については、次 のコードを参照してください Github.
GitOps 用に RBAC とkubeconfig
を構成する方法は、次のとおりです。
RBAC リソースを作成して各クラスターに適用します。
これらの RBAC リソースの例 を使用します を使用して、独自の を作成します。これらの RBAC リソースの詳細については、 「 Kubernetes ロールとロール バインディングの理解 」を参照してください。
GitOps を使用して中央クラスターとノード クラスターにこれらを適用するには、 Argo CD などのツールを使用できます。
ConfigMap ファイルを作成して適用します。
Kubernetes Operator は、 ConfigMap を使用してノードクラスターを追跡します ファイル。次の例の ConfigMap をコピー、変更、および適用します。
apiVersion: v1 kind: ConfigMap data: cluster1: "" cluster2: "" metadata: namespace: <namespace> name: mongodb-enterprise-operator-member-list labels: multi-cluster: "true"
Kubernetes Operator のkubeconfig
シークレットを構成します。
中央クラスターで実行される Kubernetes Operator は、Kubernetes API を介してノードクラスターのポッドと通信します。 これを動作させるには、Kubernetes 演算子に kubeconfig が必要です。 ノード クラスターのサービス アカウント トークンが含まれるファイル。このkubeconfig
ファイルを次の手順で作成します。
サービス アカウント のリストを取得する は、Kubernetes Operator の名前空間で構成されています。たとえば、デフォルトの
mongodb
名前空間を使用することを選択した場合は、次のコマンドを使用してサービス アカウントを取得できます。kubectl get serviceaccounts -n mongodb ノードクラスターに属する各サービス アカウントのシークレットを取得します。
kubectl get secret <service-account-name> -n mongodb -o yaml 各サービス アカウント シークレットで、 CA証明書とトークンをコピーします。 たとえば、次の例に示すように、シークレットから
<ca_certificate>
と<token>
をコピーします。apiVersion: v1 kind: Secret metadata: name: my-service-account namespace: mongodb data: ca.crt: <ca_certificate> token: <token> 中央クラスターの次の
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> 参照 Helm チャート に示すように、Kubernetes Operator にマウントする中央クラスターにシークレットを作成する 。例:
kubectl --context="${CTX_CENTRAL_CLUSTER}" -n <operator-namespace> create secret --from-file=kubeconfig=<path-to-kubeconfig-file> <kubeconfig-secret-name>