このトピックでは、同じブートストラップ マシンから複数の管理クラスタを管理する方法について説明します。これには、Tanzu Kubernetes Grid によって vSphere、Azure、または Amazon Web Services (AWS) に展開された管理クラスタと、Tanzu Kubernetes Grid 管理クラスタとして指定された vSphere with Tanzu スーパーバイザーが含まれます。
重要Tanzu Kubernetes Grid v2.4.x は、AWS および Azure でのスタンドアローン TKG 管理クラスタの管理をサポートする TKG の最後のバージョンです。AWS および Azure でスタンドアローン TKG 管理クラスタを管理する機能は、Tanzu Kubernetes Grid v2.5 リリースで削除される予定です。
以降、VMware では、Tanzu Mission Control を使用してネイティブの AWS EKS クラスタと Azure AKS クラスタを作成することをお勧めします。ただし、AWS および Azure 上の既存のスタンドアローン TKG 管理クラスタの管理は、TKG v2.4.x までのすべての TKG リリースで完全にサポートされます。
詳細については、『VMware Tanzu Kubernetes Grid v2.4 Release Notes』の「AWS および Azure での TKG 管理クラスタとワークロード クラスタの廃止」を参照してください。
使用可能な管理クラスタを一覧表示し、現在ログインしているクラスタを確認するには、ブートストラップ マシンで tanzu context use
を実行します。
tanzu context use
注コンテキストにログインするには、
tanzu context create
コマンドを使用してコンテキストを作成する必要があります。
たとえば、my-vsphere-mgmt-cluster
と my-aws-mgmt-cluster
の 2 つの管理クラスタがある場合、現在 my-vsphere-mgmt-cluster
にログインしています。
$ tanzu context use
? Select a server [Use arrows to move, type to filter]
> my-vsphere-mgmt-cluster ()
my-aws-mgmt-cluster ()
+ new server
kubectl
、および kubeconfig
Tanzu Kubernetes Grid では、Tanzu CLI コンテキストを変更するために tanzu context use
を実行しても、kubectl
コンテキストは自動的に変更されません。また、ワークロード クラスタの作成時に、Tanzu Kubernetes Grid は kubectl
コンテキストをそのクラスタに設定しません。kubectl
コンテキストを変更するには、kubectl config use-context
コマンドを使用します。
デフォルトでは、Tanzu Kubernetes Grid はブートストラップ マシンの次のファイルにクラスタ コンテキスト情報を保存します。
~/.kube-tkg/config
~/.kube/config
管理クラスタの詳細を表示するには、次の手順を実行します。
「管理クラスタの一覧表示とコンテキストの変更」の説明に従って、tanzu context use
を実行して管理クラスタにログインします。
tanzu context use
tanzu mc get
を実行します。
tanzu mc get
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR
mc-test-cli tkg-system running 3/3 3/3 v1.26.8+vmware.1 management prod v1.26.8---vmware.2-tkg.1
Details:
NAME READY SEVERITY REASON SINCE MESSAGE
/mc-test-cli True 2d1h
├─ClusterInfrastructure - VSphereCluster/mc-test-cli-jjtpf True 2d1h
├─ControlPlane - KubeadmControlPlane/mc-test-cli-mffw9 True 2d1h
│ ├─Machine/mc-test-cli-mffw9-5zcbj True 2d1h
│ ├─Machine/mc-test-cli-mffw9-fs6zh True 2d1h
│ └─Machine/mc-test-cli-mffw9-jlwnm True 2d1h
└─Workers
├─MachineDeployment/mc-test-cli-md-0-tnz59 True 15h
│ └─Machine/mc-test-cli-md-0-tnz59-64bdc75d94-gtg54 True 2d1h
├─MachineDeployment/mc-test-cli-md-1-2d26b True 15h
│ └─Machine/mc-test-cli-md-1-2d26b-776885b84-6hzkj True 2d1h
└─MachineDeployment/mc-test-cli-md-2-fs824 True 15h
└─Machine/mc-test-cli-md-2-fs824-7bfd7b9c7b-c7n95 True 2d1h
Providers:
NAMESPACE NAME TYPE PROVIDERNAME VERSION WATCHNAMESPACE
caip-in-cluster-system infrastructure-ipam-in-cluster InfrastructureProvider ipam-in-cluster v0.1.0
capi-kubeadm-bootstrap-system bootstrap-kubeadm BootstrapProvider kubeadm v1.2.8
capi-kubeadm-control-plane-system control-plane-kubeadm ControlPlaneProvider kubeadm v1.2.8
capi-system cluster-api CoreProvider cluster-api v1.2.8
capv-system infrastructure-vsphere InfrastructureProvider vsphere v1.5.1
その他のオプションを表示するには、tanzu mc get --help
を実行します。tanzu CLI エイリアス mc
は、management-cluster
の省略形です。
Tanzu CLI を使用して、他のユーザーが作成した管理クラスタにログインできます。ログインするには、ローカル kubeconfig の詳細またはサーバ エンドポイント オプションを使用します。
ローカル kubeconfig を使用して既存の管理クラスタにログインするには、次の手順を実行します。
tanzu context use
を実行し、下矢印キーを使用して [+ 新規サーバ (+ new server)] を強調表示し、Enter キーを押します。
tanzu context use
? Select a server + new server
プロンプトが表示されたら、ログイン タイプとして [ローカル kubeconfig (Local kubeconfig)] を選択し、ローカル kubeconfig ファイルのパス、コンテキスト、およびサーバの名前を入力します。例:
✔tanzu context use
? Select a server + new server
? Select login type Local kubeconfig
? Enter path to kubeconfig (if any) /Users/exampleuser/examples/kubeconfig
? Enter kube context to use new-mgmt-cluster-admin@new-mgmt-cluster
? Give the server a name new-mgmt-cluster
successfully logged in to management cluster using the kubeconfig new-mgmt-cluster
[サーバ エンドポイント (Server endpoint)] オプションを使用して既存の管理クラスタにログインするには、次の手順を実行します。
tanzu context use
を実行し、下矢印キーを使用して [+ 新規サーバ (+ new server)] を強調表示し、Enter キーを押します。
tanzu context use
? Select a server + new server
プロンプトが表示されたら、ログイン タイプとして [サーバ エンドポイント (Server endpoint)] を選択します。
successfully logged in to management cluster by using the kubeconfig <server name>
他のユーザーが作成した管理クラスタを Tanzu CLI のインスタンスに追加しましたが、それはある時点で不要になる場合があります。同様に、管理クラスタを展開し、その管理クラスタが tanzu mc delete
を実行する以外の方法でターゲット プラットフォームから削除された場合、その管理クラスタは、tanzu context use
の実行時に CLI が追跡する管理クラスタのリストに引き続き表示されます。このような場合は、Tanzu CLI が追跡する管理クラスタのリストから管理クラスタを削除できます。
tanzu context list
を実行して、Tanzu CLI が追跡する管理クラスタのリストを表示します。
tanzu context list
自分で展開した、または Tanzu CLI に追加したすべての管理クラスタ、kubeconfig ファイルの場所、およびそれらのコンテキストが表示されます。
tanzu context delete
コマンドを実行して、管理クラスタを削除します。
tanzu context delete my-vsphere-mc
tanzu context delete
コマンドを実行すると、クラスタの詳細が ~/.config/tanzu/config.yaml
および ~/.kube-tkg/config.yaml
ファイルから削除されます。管理クラスタ自体が存在する場合は、削除されません。単に Tanzu CLI 構成に含めないようにするのではなく、管理クラスタを完全に削除するには、「管理クラスタの削除」を参照してください。
ブートストラップ マシンで、Tanzu CLI はローカルに保存されている証明書を使用して管理クラスタで認証します。証明書の有効期限が切れると、tanzu
CLI コマンドの実行時に失敗したというエラー メッセージが表示されます。
したがって、証明書の有効期限前に、次の手順に従って証明書を更新します。
tanzu mc get
を使用して管理クラスタの名前を取得します。
tanzu mc get
クラスタ構成データを取得します。
kubectl -n tkg-system get secrets CLUSTER-NAME-kubeconfig -o 'go-template={{ index .data "value"}}' | base64 -d > mc_kubeconfig.yaml
ここで、CLUSTER-NAME
は管理クラスタの名前です。例:
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBD<redacted>
server: https://192.168.100.90:6443
name: tkg-mgmt
contexts:
- context:
cluster: tkg-mgmt
user: tkg-mgmt-admin
name: tkg-mgmt-admin@tkg-mgmt
current-context: tkg-mgmt-admin@tkg-mgmt
kind: Config
preferences: {}
users:
- name: tkg-mgmt-admin
user:
client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZ<redacted>
client-key-data: LS0tLS1CRUdJTiBSU<redacted>`
Tanzu CLI が現在追跡している管理クラスタのリストから、既存の管理クラスタ エントリを削除します。
tanzu context delete CLUSTER-NAME
tanzu context create
コマンドを使用して、更新された kubeconfig
を持つ新しい管理クラスタ エントリを追加します。
tanzu context create --kubeconfig mc_kubeconfig.yaml --name CLUSTER-NAME --context CLUSTER-NAME-admin@CLUSTER-NAME
管理クラスタを展開した後、含まれるノード仮想マシンの数を増減することで、スケール アップまたはスケール ダウンできます。管理クラスタをスケーリングするには、次のオプションのいずれかまたは両方を指定して tanzu cluster scale
コマンドを使用します。
--controlplane-machine-count
は、管理クラスタ制御プレーン ノードの数を変更します。--worker-machine-count
は、管理クラスタ ワーカー ノードの数を変更します。管理クラスタは、default
名前空間ではなく tkg-system
名前空間で実行されるため、管理クラスタをスケーリングする場合は --namespace
オプションも指定する必要があります。
tanzu cluster scale
を実行する前に tanzu context use
を実行して、スケーリングする管理クラスタが Tanzu CLI の現在のコンテキストであることを確認します。最初に 3 台の制御プレーン ノードと 5 台のワーカー ノードを使用して展開した本番用の管理クラスタをそれぞれ 5 ノードと 10 ノードにスケーリングするには、次のコマンドを実行します。
tanzu cluster scale MANAGEMENT-CLUSTER-NAME --controlplane-machine-count 5 --worker-machine-count 10 --namespace tkg-system
最初に 1 台の制御プレーン ノードを使用して開発用管理クラスタを展開し、3 台の制御プレーン ノードにスケール アップした場合、Tanzu Kubernetes Grid は制御プレーン上でスタック HA を自動的に有効にします。
重要Tanzu Kubernetes Grid 操作の実行中は、コンテキストを変更したり、
.kube-tkg/config
ファイルを編集したりしないでください。
管理クラスタ、および必要に応じてすべての管理するワークロード クラスタで使用される vSphere 認証情報を更新するには、『Tanzu CLI を使用した TKG 2.3 ワークロード クラスタの作成と管理』の「クラスタ認証情報の更新」を参照してください。
インストーラ インターフェイスまたは CLI を使用して管理クラスタを展開する場合、オプトアウトするオプションを指定しない限り、VMware カスタマー エクスペリエンス向上プログラム (CEIP) への参加はデフォルトで有効になります。プログラムへのオプトインを継続している場合、管理クラスタは、今後のバージョンで改善できるように Tanzu Kubernetes Grid の使用に関する情報を定期的に VMware に送信します。
CEIP の詳細については、「CEIP への参加の管理」を参照してください。
管理クラスタを展開したときに CEIP をオプトアウトし、オプトインしたい場合、またはオプトインした後でオプトアウトしたい場合は、「CEIP への参加の管理」の「VMware CEIP のオプトインまたはオプトアウト」を参照して、展開後に CEIP 参加設定を変更します。
開発プロジェクトの編成と管理をしやすくするため、必要に応じて管理クラスタを Kubernetes 名前空間に分割できます。その後、Tanzu CLI を使用して、管理クラスタ内の特定の名前空間にワークロード クラスタを展開できます。たとえば、専用の名前空間に異なるタイプのクラスタを作成できます。追加の名前空間を作成しない場合、Tanzu Kubernetes Grid は default
名前空間にすべてのワークロード クラスタを作成します。Kubernetes 名前空間の詳細については、Kubernetes のドキュメントを参照してください。
現在のコンテキストを表示して、kubectl
が正しい管理クラスタ コンテキストに接続されていることを確認します。
kubectl config current-context
管理クラスタに現在存在する名前空間を一覧表示します。
kubectl get namespaces
管理クラスタには、提供されるさまざまなサービスに対していくつかの名前空間がすでに含まれていることが表示されます。
capi-kubeadm-bootstrap-system Active 4m7s
capi-kubeadm-control-plane-system Active 4m5s
capi-system Active 4m11s
capi-webhook-system Active 4m13s
capv-system Active 3m59s
cert-manager Active 6m56s
default Active 7m11s
kube-node-lease Active 7m12s
kube-public Active 7m12s
kube-system Active 7m12s
tkg-system Active 3m57s
kubectl create -f
を使用して、開発環境や本番環境などのための新しい名前空間を作成します。
これらの例では、Kubernetes ドキュメントの production
および development
名前空間を使用しています。
kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
kubectl get namespaces --show-labels
を実行して、新しい名前空間を表示します。
development Active 22m name=development
production Active 22m name=production
管理クラスタ内のワークロード クラスタの名前空間を削除する前に、ワークロード クラスタ自体を削除する必要があります。管理クラスタの名前空間を削除してワークロード クラスタを削除することはできません。
管理クラスタ内のワークロード クラスタの名前空間を削除するには、次の手順を実行します。
kubectl
のコンテキストを管理クラスタに設定します。
kubectl config use-context MY-MGMT-CLUSTER@MY-MGMT-CLUSTER
ここで、MY-MGMT-CLUSTER
は管理クラスタの名前です。
削除する名前空間で実行されているクラスタを一覧表示します。
tanzu cluster list -n NAMESPACE
「ワークロード クラスタの削除」の手順に従ってボリュームとサービスを削除し、必要に応じてワークロードを移行し、名前空間内のクラスタを削除します。
kubectl
を使用して名前空間を削除します。
kubectl delete namespace NAMESPACE
管理クラスタを削除するには、tanzu mc delete
コマンドを実行します。
tanzu mc delete
を実行すると、Tanzu Kubernetes Grid はブートストラップ マシンに一時的な kind
クリーンアップ クラスタを作成して削除プロセスを管理します。kind
クラスタは、削除プロセスが完了すると削除されます。
AWS:TKG で使用される AWS 認証情報がまだ有効であることを確認します。これらは、「AWS アカウントの認証情報の構成」で説明しているように、認証情報プロファイルまたはローカルの静的な環境変数のいずれかになります。
すべての管理クラスタを表示するには、「管理クラスタの一覧表示とコンテキストの変更」の説明に従って tanzu context use
を実行します。
不要になった管理クラスタがある場合は、tanzu mc delete
を実行します。
削除する管理クラスタにログインしている必要があります。
tanzu mc delete my-mgmt-cluster
tanzu mc delete
を実行するときに yes/no
検証手順をスキップするには、--yes
オプションを指定します。
tanzu mc delete my-mgmt-cluster --yes
管理クラスタで実行されているワークロード クラスタがある場合、削除操作は実行されません。
この場合、次の 2 つの方法で管理クラスタを削除できます。
tanzu cluster delete
を実行して実行中のすべてのクラスタを削除してから、もう一度 tanzu mc delete
を実行します。--force
オプションを使用して tanzu mc delete
を実行します。tanzu mc delete my-mgmt-cluster --force
重要Tanzu Kubernetes Grid 操作の実行中は、コンテキストを変更したり、
.kube-tkg/config
ファイルを編集したりしないでください。
Tanzu Kubernetes Grid を使用して、異なる Tanzu Kubernetes Grid インスタンスへのワークロード クラスタの展開を開始できます。詳細については、『Tanzu CLI を使用した TKG 2.3 ワークロード クラスタの作成と管理』の「ワークロード クラスタの作成」を参照してください。
スーパーバイザーを使用する vSphere 8 がある場合は、Tanzu CLI を使用して TKG 2.x クラスタを展開できます。詳細については、『Tanzu CLI を使用した TKG 2.3 クラスタの作成と管理』を参照してください。