# はじめに VMware vSphere環境ではTanzu Kubernetes Grid(通称: TKG)を使用することで簡単にKubernetes環境を構築することができます。本記事で紹介するTKGはStandalone版であり、マルチクラウドに対応可能なTKGmです。また、NSX ALBはEssentialsライセンスを使用していきます。本記事では事前準備およびBootStrapマシンの構築方法を記述しています。本記事ではTanzu Kubernetes Gridの構築として、ManagementクラスタおよびWorkloadクラスタの構築手順を記述しています。 # 前回今回はNSX ALBの構築、事前準備、BootStrapマシンの構築がしてあることを前提に進んでいきます。構築がまだな方は以下の記事を参考に事前準備およびBootStrapマシンの構築をよろしくお願いします。 https://www.munenick.me/blog/tkg-nsx-alb-02 # 環境 | 環境 | | --------------------------------- | | VMware ESXi 8 | | VMware vCenter 8 | | Tanzu Kubernetes Grid 2.1.1 | | NSX Advanced Load Balancer 22.1.3 | # 前提条件 - VMware ESXiの構築及びvCenterを使用してDatacenterの管理ができていること - 2つ以上のVLAN環境が構築できていること - 本環境ではマネジメントネットワーク:VM Network(VLAN0)とKubernetes用ネットワーク:VLAN100(VLAN100)を用意しています。 - 十分なリソースのあるサーバ、ストレージ - NSX ALBでCPU:8, RAM:24GB, ROM:128GB使用します。 - 要件によりますが、デプロイするKubernetesノードでもCPU:2, RAM:8GB, ROM:40GBの仮想マシンが4~12個デプロイされます。 # Managementクラスタの構築 ## デプロイ用WebUIの起動デプロイにはyamlを記述する方法とWebUIを使用する方法があります。今回、Managementクラスタを作成する際にはWebUIを使用します。 - TeratermなどでBootStrapマシンにSSH接続してください。また、前回作成した一般ユーザでログインしてください。 - 以下のコマンドを入力し、WebUIを起動してください。 ```bash MuNeNiCK [ ~ ]$ tanzu management-cluster create --ui --bind=0.0.0.0:8080 --browser=none Validating the pre-requisites... Serving kickstart UI at http://[::]:8080 ``` - ブラウザを起動し、「[https://BootStrapマシンのIPアドレス:8080](https://BootStrapマシンのIPアドレス:8080)」にアクセスしてください。 ## Managementクラスタのデプロイ ### デプロイ先の選択 - WebUIにアクセスしたら、まずデプロイ先を選択することができます。今回は「VMware vSphere」の「Deploy」をクリックしてください。 ![](https://www.munenick.me/hackmd/uploads/upload_d9ec93f70f9878d7ced6ecc541b82eef.png) ### IaaS Providerの設定 - 以下の項目を設定し、「CONNECT」をクリックし、vCenter Serverに接続します。 - VCENTER SERVER: vCenter ServerのIPアドレスまたはFQDNを指定してください。 - USERNAME: vCenterのadministratorアカウント名を入力してください。 - PASSWORD: vCenterのadministratorのパスワードを入力してください。 - SSL THUMBPRINT VERIFICATION: vCenterが自己証明書の場合、チェックを入れてください。 ![](https://www.munenick.me/hackmd/uploads/upload_3a8f1b9afd4198637df2368a827ff641.png) - デプロイ方法の指定ができます。「CONFIGURE VSPHERE WITH TANZU」はTKGsと呼ばれており、vSphere環境に組み込む形でデプロイされます。「DEPLOY TKG MANAGEMENT CLUSTER」はTKGmと呼ばれおり、マルチクラウドに対応したスタンドアロンクラスタを構築します。今回は「DEPLOY TKG MANAGEMENT CLUSTER」をクリックし、TKGmを構築します。 - vCenterに接続すると追加で以下の項目を設定できるようになります。 - DATACENTER: クラスタをデプロイするデータセンタを指定してください。 - SSH PUBLIC KEY: [前回記事](/blog/tkg-nsx-alb-02#ssh%E9%8D%B5%E3%83%9A%E3%82%A2%E3%81%AE%E4%BD%9C%E6%88%90)でBootStrapマシンのセットアップ時に作成したSSH鍵を指定します。これらの設定を終えたら「NEXT」をクリックしてください。 ### Cluster Settingsの設定 - 以下の項目を設定します。 - デプロイタイプ: デプロイタイプは「Development」と「Production」の２つから選択することができます。名前の通り、開発環境では「Development」、本番環境では高可用性の「Production」を指定するといいでしょう。今回は「Development」を選択します。 - Development: 1つのcontrol-planeノードと1つのworkerノード、計2つの仮想マシンが作成されます。 - Production: 3つのcontrol-planeノードと3つのworkerノード、計6つの仮想マシンが作成されます。 ![](https://www.munenick.me/hackmd/uploads/upload_a8af4b6cab7765fa8b29c3eb3e2cb880.png) - INSTANCE TYPE: Managementクラスタでデプロイさるノードのスペックを「small」、「medium」、「large」、「extra-large」の4つから選択することができます。デプロイタイプで指定した仮想マシンの台数分選択したINSTANCE TYPEのスペックの仮想マシンがデプロイされます。今回は「medium」を選択します。 - small: cpu: 2, ram: 4GB, disk: 20GB - medium: cpu: 2, ram: 8GB, disk: 40GB - large: cpu: 4, ram: 16GB, disk: 20GB - extra-large: cpu: 2, ram: 4GB, disk: 20GB ![](https://www.munenick.me/hackmd/uploads/upload_8be7696dc1728051f5cd486961c8dc61.png) - MANAGEMENT CLUSTER NAME: デプロイするManagementクラスタの名前を指定します。今回は「tkg21mc01」としました。 - MACHINE HEALTH CHECKS: デプロイされたノードのヘルスチェックを行います。 - CONTROL PLANE ENDPOINT PROVIDER: 「kube-vip」と「NSX Advanced Load Balancer」の2つから選択することができます。今回は「NSX Advanced Load Balancer」を選択します。 - CONTROL PLANE ENDPOINT: control-planeノードのVIPアドレスを指定することができます。今回は指定しません。 - WORKER NODE INSTANCE TYPE: Workloadクラスタでデプロイされるノードのスペックを設定します。項目はINSTANCE TYPEと同様です - ACTIVATE AUDIT LOGGING: 監査ログを有効化します。今回は以下のような設定になりました。これはあくまで1例であり、ご自身の環境や要件によって変更してください。 ![](https://www.munenick.me/hackmd/uploads/upload_cc346b2cf63536c6d48fadd54b384860.png) すべての設定を終えたら「NEXT」をクリックしてください。 ### VMware NSX Advanced Load Balancerの設定 - 以下の項目を設定し、「VERIFY CREDENTIALS」をクリックすることで、NSX ALBに接続します。 - CONTROLLER HOST: NSX ALBのIPアドレスまたはFQDNを指定してください。 - USERNAME: NSX ALBにログインするためのアカウント名を指定してください。デフォルトの場合、「admin」になります。 - PASSWORD: アカウントに対するパスワードを指定してください。 - CONTROLLER CERTIFICATE AUTHORITY: NSX ALB構築時の[証明書の取得](/blog/tkg-nsx-alb-01#証明書の取得)にて取得した証明書をペーストします。 ![](https://www.munenick.me/hackmd/uploads/upload_83959bb6dcc3790a25412063d56109b4.png) - NSX ALBに接続すると追加で以下の項目を設定することができます。 - CLOUD NAME: 「Default-Cloud」を指定してください。 - Workload Cluster: Workloadクラスタの設定になります。 - SERVICE ENGINE GROUP NAME: 「Default-Group」を指定してください。 - WORKLOAD CLUSTER - DATA PLANE VIP NETWORK NAME: Kubernetes用ネットワークを指定してください。 - WORKLOAD CLUSTER - CONTROL PLANE VIP NETWORK NAME: Kubernetes用ネットワークを指定してください。 - WORKLOAD CLUSTER - DATA PLANE VIP NETWORK CIDR: Kubernetes用ネットワークアドレスを入力してください。 - WORKLOAD CLUSTER - CONTROL PLANE VIP NETWORK CIDR: Kubernetes用ネットワークアドレスを入力してください。 - Management Cluster: Managementクラスタの設定になります。基本的にはWorkload Clusterの設定と同じになります。 - MANAGEMENT CLUSTER - SERVICE ENGINE GROUP NAME: 「Default-Group」を指定してください。 - MANAGEMENT CLUSTER - DATA PLANE VIP NETWORK NAME: Kubernetes用ネットワークを指定してください。 - MANAGEMENT CLUSTER - CONTROL PLANE VIP NETWORK: Kubernetes用ネットワークを指定してください。 - MANAGEMENT CLUSTER - DATA PLANE VIP NETWORK CIDR: Kubernetes用ネットワークアドレスを入力してください。 - MANAGEMENT CLUSTER - CONTROL PLANE VIP NETWORK CIDR: Kubernetes用ネットワークアドレスを入力してください。 - CLUSTER LABELS: クラスタにラベルを付与することができます。今回の設定は以下のようになります。この設定は1例であり、ネットワーク設計やNSX ALBの設定が異なる場合はご自身の環境に合わせて設定をしてください。 ![](https://www.munenick.me/hackmd/uploads/upload_653e57730199bba67f6d0bee431be59b.png) すべての設定を終えたら「NEXT」をクリックしてください。 ### Metadataの設定ここではManagementクラスタのメタデータを指定することができます。今回は設定しません。設定を終えたら「NEXT」をクリックしてください。 ![](https://www.munenick.me/hackmd/uploads/upload_9bf20ed493757da2728efb8381e95e8c.png) ### Resourcesの設定 - 以下の項目を設定します。 - VM FOLDER: Managementクラスタをデプロイするフォルダを選択します。今回の場合、[事前準備](/blog/tkg-nsx-alb-02#フォルダの作成)にて作成したフォルダである「/Datacenter/vm/TKG/Management」になります。 - DATASTORE: Managementクラスタのノードとしてデプロイされる仮想マシンの保存先データストアを指定してください。 - CLUSTERS, HOSTS, AND RESOURCE POOLS: Managementクラスタのノードとしてデプロイされる仮想マシンの作成先クラスタまたはホスト、リソースプールを指定してください。 ![](https://www.munenick.me/hackmd/uploads/upload_b21600b3d54546d1c25efdd5a5aa74bc.png) すべての設定を終えたら「NEXT」をクリックしてください。 ### Kubernetes Networkの設定 - 以下の項目を設定します。 - NETWORK NAME: Managementクラスタのノードとしてデプロイされる仮想マシンに割り当てられるネットワークを指定してください。Kubernetes用ネットワークを指定しても問題ありません。 - CLUSTER SERVICE CIDR: クラスタのサービスで使用されるネットワークアドレスです。デフォルトのままで構いません。 - CLUSTER POD CIDR: クラスタのPodで使用されるネットワークアドレスです。デフォルトのままで構いません。 - Proxy Settings: ネットワーク接続にプロキシが必要な場合は設定してください。今回は設定しません。 ![](https://www.munenick.me/hackmd/uploads/upload_dd0d5056c5416c32d2b97ee30b07a6c0.png) すべての設定を終えたら「NEXT」をクリックしてください。 ### Identity Managementの設定 - 必要に応じてOIDCやLDAPを使用した認証管理を行います。今回は使用しないので無効のまま進みます。 ![](https://www.munenick.me/hackmd/uploads/upload_35c5f12f130e923a59ab0b9aa4f3771c.png) ### OS Imageの設定 - TKRの指定を行います。TKRが正常にテンプレート化されている場合、プルダウンメニューに表示されます。今回はPhoton v3を指定します。 ![](https://www.munenick.me/hackmd/uploads/upload_1866dd6929ba39c14319284b5d0339bb.png) 設定を終えたら「NEXT」をクリックしてください。 ### CEIP Agreementの設定 - 情報提供を行うかの確認です。今回はオフにしています。 ![](https://www.munenick.me/hackmd/uploads/upload_6f56e63dddf5c6c7c4b5516b7ec95f80.png) ### 設定の確認 - 必要な設定を終えている場合、各項目の横に緑色のチェックマークがつき、「REVIEW CONFIGURATION」が押せるようになっているはずです。「REVIEW CONFIGURATION」をクリックしてください。 ![](https://www.munenick.me/hackmd/uploads/upload_e5f3b5a24a76b39b22fc2814057ed573.png) - 「Tanzu Kubernetes Grid - Confirm Settings」にて設定の確認を行うことができます。設定が正しいことを確認したら「DEPLOY MANAGEMEMT CLUSTER」をクリックシてください。やり直しがある場合は「EDIT CONFIGURATION」をクリックしてください。また、今回設定した内容をyamlで保存するには、「EXPORT CONFIGURATION」をクリックしてください。 ![](https://www.munenick.me/hackmd/uploads/upload_ac8e3647530fa96200aa8243a6771928.png) ### デプロイの待機環境のデプロイが始まるとWebUIおよびSSH上のBootStrapマシンにログとして表示されます。項目が完了するまでお待ち下さい。環境や設定によって異なりますが、50分程度デプロイにかかることもあります。 ![](https://www.munenick.me/hackmd/uploads/upload_7128b495a126ecc4c8e8236975783558.png) ![](https://www.munenick.me/hackmd/uploads/upload_290c6f549ca293b86914cc0143d1a2a8.png) また、WebUIの下部にはデプロイの作業をCUI上で実行するためのコマンドが記述されています。デプロイに失敗した際の再試行等で使用するのでメモを取っておくといいでしょう。 ![](https://www.munenick.me/hackmd/uploads/upload_de9ba50b605b441a6bc7431a83875e9d.png) ### クラスタのデプロイに失敗した場合クラスタのデプロイに失敗した場合の手順を紹介します。今回はStart creating management cluster...のプロセスで失敗したようです。 ![](https://www.munenick.me/hackmd/uploads/upload_94144758e5dcbda9d855efe17a957a92.png) ![](https://www.munenick.me/hackmd/uploads/upload_dbe7f7cbef8df6b25e25ab6db2814082.png) - 原因の特定を行うには、エラーログにある「debug」以下のコマンドを実行します。今回の場合は以下のようになります。 ```bash MuNeNiCK [ ~ ]$ kubectl get po,deploy,cluster,kubeadmcontrolplane,machine,machinedeployment -A --kubeconfig /home/MuNeNiCK/.kube-tkg/tmp/config_uzpk20OX MuNeNiCK [ ~ ]$ kubectl logs deployment.apps/ -n manager --kubeconfig /home/MuNeNiCK/.kube-tkg/tmp/config_uzpk20OX ``` - 作成されたクラスタの削除を行うために以下のコマンドを実行します。 ```bash MuNeNiCK [ ~ ]$ tanzu management-cluster delete -y ``` - WebUIからは再作成は行えないため、[デプロイの待機](/blog/tkg-nsx-alb-03#デプロイの待機)にて取得したコマンドを使用します。今回の場合は以下のコマンドを使用することでクラスタの再作成を行えます。 ```bash MuNeNiCK [ ~ ]$ tanzu management-cluster create tkg21mc01 --file /home/MuNeNiCK/.config/tanzu/tkg/clusterconfigs/ii252b9tt1.yaml -v 6 ``` - また、クラスタ作成の失敗の原因がタイムアウトな場合、「--timeout 時間」オプションを使用することで、タイムアウトまでの時間を延長させることができます。この時、デフォルトのタイムアウト時間は「30m」となっています。 ```bash MuNeNiCK [ ~ ]$ tanzu management-cluster create tkg21mc01 --file /home/MuNeNiCK/.config/tanzu/tkg/clusterconfigs/ii252b9tt1.yaml -v 6 --timeout 60m ``` ![](https://www.munenick.me/hackmd/uploads/upload_3bfe4b27bc3e678a24d4fd38b97d3b60.png) ## Managementクラスタのデプロイの確認 WebUIまたはBootStrapマシンのログにて成功の旨が表示されていればデプロイの完了です。 ![](https://www.munenick.me/hackmd/uploads/upload_166e7fb73bd439c86dd3b3e4b2bcb5d6.png) ![](https://www.munenick.me/hackmd/uploads/upload_8cbf0c19bf33e65cf04268deec498b92.png) ### kubectlを用いたデプロイの確認 BootStrapマシンのログにあるように以下のコマンドを実行することでデプロイの確認ができます。 ```bash MuNeNiCK [ ~ ]$ kubectl get apps -A ``` ### vCenterにアクセスして確認 vCenter Serverにログインし、「TKG」→「Management」内に仮想マシンが作成されていることを確認してください。 ![](https://www.munenick.me/hackmd/uploads/upload_420593167e34657ca27641f59d8e503e.png) ### NSX ALBにアクセスして確認 NSX ALBにログインし、「アプリケーション」→「ダッシュボード」にアクセスすることでデプロイを確認できます。画像のように表示するには左上の「VS リスト」を「VS ツリー」に変更してください。 ![](https://www.munenick.me/hackmd/uploads/upload_d40a0471caa30850031cb23dd46c5c66.png) ## Managementクラスタのyamlの保存今回作成されたyamlはWorkloadクラスタでも使用します。そのため、以下の手順で保存してください。 - 以下のコマンドを実行し、yamlファイルの存在を確認してください。 ```bash MuNeNiCK [ ~ ]$ ls -al $HOME/.config/tanzu/tkg/clusterconfigs/ total 20 drwx------ 2 MuNeNiCK users 4096 May 9 22:07 . drwx------ 7 MuNeNiCK users 4096 May 9 23:00 .. -rw------- 1 MuNeNiCK users 4459 May 9 22:00 ii252b9tt1.yaml -rw------- 1 MuNeNiCK users 3317 May 10 00:13 tkg21mc01.yaml ``` - 以下のコマンドを実行し、yamlファイルをホームディレクトリに保存します。※yamlファイル名は環境によって変わるので適宜読み替えてください。 ```bash MuNeNiCK [ ~ ]$ cp $HOME/.config/tanzu/tkg/clusterconfigs/ii252b9tt1.yaml tkg21mc01.yaml ``` - 以下のコマンドを実行し、コピーされたことを確認してください。 ```bash MuNeNiCK [ ~ ]$ ls -l $HOME total 313612 drwxr-x--- 2 MuNeNiCK users 4096 May 9 20:27 bin drwxr-x--- 3 MuNeNiCK users 4096 Mar 9 09:42 cli -rwxrwxrwx 1 MuNeNiCK users 46067712 Apr 23 20:34 kubectl-linux-v1.24.10+vmware.1 -rwxrwxrwx 1 root root 275052656 Apr 23 20:34 tanzu-cli-bundle-linux-amd64.tar.gz -rw------- 1 MuNeNiCK users 4459 May 10 08:49 tkg21mc01.yaml ``` # Managementクラスタへの接続 Managementクラスタに接続し、クラスタの管理を行うためいくつかの操作が必要になります。 - まず、以下のコマンドを実行してkubeconfigを取得してください。 ```bash MuNeNiCK [ ~ ]$ tanzu mc kubeconfig get --admin Credentials of cluster 'tkg21mc01' have been saved You can now access the cluster by running 'kubectl config use-context tkg21mc01-admin@tkg21mc01' ``` - 次にログに出力されている通り、以下のコマンドを実行します。 ```bash MuNeNiCK [ ~ ]$ kubectl config use-context tkg21mc01-admin@tkg21mc01 Switched to context "tkg21mc01-admin@tkg21mc01". ``` - 以下のコマンドを実行して現在のコンテキストを確認してください ```bash MuNeNiCK [ ~ ]$ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * tkg21mc01-admin@tkg21mc01 tkg21mc01 tkg21mc01-admin ``` - コンテキストを使用してクラスタのノードを確認します。以下のコマンドを実行してください。 ```bash MuNeNiCK [ ~ ]$ kubectl get nodes NAME STATUS ROLES AGE VERSION tkg21mc01-f5zvz-tq8wn Ready control-plane 8h v1.24.10+vmware.1 tkg21mc01-md-0-n85gx-6f5bf77dc8-lv58j Ready 8h v1.24.10+vmware.1 ``` 以上でManagementクラスタの構築および接続が完了となります。 # Workloadクラスタの構築 ## Workloadクラスタ用yamlの作成 - 先程ホームディレクトリにコピーしたManagementクラスタ用のyamlをコピーしてします。以下のコマンドを実行してください。 ```bash MuNeNiCK [ ~ ]$ cp tkg21mc01.yaml tkg21wc01.yaml MuNeNiCK [ ~ ]$ ls -l total 313620 drwxr-x--- 2 MuNeNiCK users 4096 May 9 20:27 bin drwxr-x--- 3 MuNeNiCK users 4096 Mar 9 09:42 cli -rwxrwxrwx 1 MuNeNiCK users 46067712 Apr 23 20:34 kubectl-linux-v1.24.10+vmware.1 -rwxrwxrwx 1 root root 275052656 Apr 23 20:34 tanzu-cli-bundle-linux-amd64.tar.gz -rw------- 1 MuNeNiCK users 4459 May 10 08:49 tkg21mc01.yaml -rw------- 1 MuNeNiCK users 4459 May 10 08:57 tkg21wc01.yaml ``` - viエディタなどで以下の項目を書き換えます。※これはあくまで一例であり、自身の環境に合わせて変更してください。 - CLUSTER_NAME: Workloadクラスタ名に書き換えてください。今回は「tkg21wc01」としています。 - VSPHERE_FOLDER: Workloadクラスタ用フォルダに書き換えてください。今回は「/Datacenter/vm/TKG/Workload」としています。 - オプション1: 今回はWorkloadクラスタのデプロイタイプを「Development」から「Production」に変更します。以下の項目を書き換えてください。※この設定を適用すると仮想マシンが6台デプロイされます。十分なリソースがある場合のみ実行してください。 - CLUSTER_PLAN: 「dev」から「prod」に変更してください。 - オプション2: 今回は[AutoScaler](https://github.com/kubernetes/autoscaler)を使用して、Kubernetesクラスタを自動的に最適なサイズに調整できるようにします。yamlファイルの末尾に以下のコードを記述します。※このAutoScalerはWorkloadクラスタのみ設定可能です。 ```yaml #! --------------------------------------------------------------------- #! Autoscaler related configuration #! --------------------------------------------------------------------- ENABLE_AUTOSCALER: true AUTOSCALER_MAX_NODES_TOTAL: "0" AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD: "10m" AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE: "10s" AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE: "3m" AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME: "10m" AUTOSCALER_MAX_NODE_PROVISION_TIME: "15m" # Each min/max pair (0,1,2) corresponds to an availability zone. # If you have a 'dev' cluster, you only need to fill in the min/max size for '0'. # If you have a 'prod' cluster, you need to fill in all three pairs. AUTOSCALER_MIN_SIZE_0: 1 AUTOSCALER_MAX_SIZE_0: 5 AUTOSCALER_MIN_SIZE_1: 1 AUTOSCALER_MAX_SIZE_1: 5 AUTOSCALER_MIN_SIZE_2: 1 AUTOSCALER_MAX_SIZE_2: 5 ``` - ENABLE_AUTOSCALER: 「Autoscaler」を有効化/無効化を決定します。 - AUTOSCALER_MAX_NODES_TOTAL: control-planeノードとworkerノードの合計の数を制限します。0に指定することで制限を解除することができます。 - AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD: スケールアップ操作後にクラスタオートスケーラがスケールダウンスキャンを再開するまで待機する時間です。 - AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE: ノードの削除後にクラスタオートスケーラがスケールダウンスキャンを再開するまで待機する時間です。 - AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE: スケールダウンの失敗後にクラスタオートスケーラがスケールダウンスキャンを再開するまで待機する時間です。 - AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME: クラスタオートスケーラが対象ノードをスケールダウンするまでに待機する必要がある時間です。 - AUTOSCALER_MAX_NODE_PROVISION_TIME: クラスタオートスケーラがノードのプロビジョニングを待機する最長時間です。 - AUTOSCALER_*_SIZE: 「dev」クラスタなど、単一のワーカーノードを持つクラスタの場合は、「AUTOSCALER_MIN_SIZE_0」と「AUTOSCALER_MAX_SIZE_0」のみを設定します。「prod」など複数のcontrol-planeノードが存在する場合は、control-planeノード分設定します。 - AUTOSCALER_MIN_SIZE_*: workerノードの最小個数です。今回は「1」に設定しています。 - AUTOSCALER_MAX_SIZE_*: 自動スケーリングが実行された際のworkerノードの最大個数です。今回は「5」に設定しています。 - 設定ファイルの確認として以下のコマンドを実行してください。 ```bash MuNeNiCK [ ~ ]$ diff tkg21mc01.yaml tkg21wc01.yaml 21,22c21,22 < CLUSTER_NAME: tkg21mc01 < CLUSTER_PLAN: dev --- > CLUSTER_NAME: tkg21wc01 > CLUSTER_PLAN: prod 59c59 < VSPHERE_FOLDER: /Datacenter/vm/TKG/Management --- > VSPHERE_FOLDER: /Datacenter/vm/TKG/Workload 71a72,91 > #! --------------------------------------------------------------------- > #! Autoscaler related configuration > #! --------------------------------------------------------------------- > ENABLE_AUTOSCALER: true > AUTOSCALER_MAX_NODES_TOTAL: "0" > AUTOSCALER_SCALE_DOWN_DELAY_AFTER_ADD: "10m" > AUTOSCALER_SCALE_DOWN_DELAY_AFTER_DELETE: "10s" > AUTOSCALER_SCALE_DOWN_DELAY_AFTER_FAILURE: "3m" > AUTOSCALER_SCALE_DOWN_UNNEEDED_TIME: "10m" > AUTOSCALER_MAX_NODE_PROVISION_TIME: "15m" > > # Each min/max pair (0,1,2) corresponds to an availability zone. > # If you have a 'dev' cluster, you only need to fill in the min/max size for '0'. > # If you have a 'prod' cluster, you need to fill in all three pairs. > AUTOSCALER_MIN_SIZE_0: 1 > AUTOSCALER_MAX_SIZE_0: 5 > AUTOSCALER_MIN_SIZE_1: 1 > AUTOSCALER_MAX_SIZE_1: 5 > AUTOSCALER_MIN_SIZE_2: 1 > AUTOSCALER_MAX_SIZE_2: 5 ``` ## Workloadクラスタのデプロイ - 以下のコマンドを実行してください。しかし、デプロイされないと思います。これはTKG2.1からの変更点で、yamlのフォーマットが古いために起こります。 ```bash MuNeNiCK [ ~ ]$ tanzu cluster create -f tkg21wc01.yaml Validating configuration... Warning: Pinniped configuration not found; Authentication via Pinniped will not be set up in this cluster. If you wish to set up Pinniped after the cluster is created, please refer to the documentation. Legacy configuration file detected. The inputs from said file have been converted into the new Cluster configuration as '/home/MuNeNiCK/.config/tanzu/tkg/clusterconfigs/tkg21wc01.yaml' To create a cluster with it, use tanzu cluster create --file /home/MuNeNiCK/.config/tanzu/tkg/clusterconfigs/tkg21wc01.yaml ``` - ログに表示されている「To create a cluster with it, use」以下のコマンドを実行してください。これによりWorkloadクラスタのデプロイが開始します。 ```bash MuNeNiCK [ ~ ]$ tanzu cluster create --file /home/MuNeNiCK/.config/tanzu/tkg/clusterconfigs/tkg21wc01.yaml Validating configuration... Warning: Pinniped configuration not found; Authentication via Pinniped will not be set up in this cluster. If you wish to set up Pinniped after the cluster is created, please refer to the documentation. creating workload cluster 'tkg21wc01'... ``` ### Workloadクラスタのデプロイに失敗したら。 - 以下のコマンドを実行し、Workloadクラスタの削除をします。 ```bash MuNeNiCK [ ~ ]$ tanzu cluster delete tkg21wc01 Deleting workload cluster 'tkg21wc01'. Are you sure? [y/N]: y successfully deleted autoscaler resources from management cluster Workload cluster 'tkg21wc01' is being deleted ``` - 以下のコマンドを実行し、削除の確認をしてください。 ```bash MuNeNiCK [ ~ ]$ tanzu cluster list NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR ``` - 設定やサーバの状態を見直し、再度クラスタのデプロイを実行してください。この際、「--timeout 時間」オプションを指定することもできます。 ## Workloadクラスタのデプロイの確認 ### BootStrapマシンでのログの確認 - BootStrapマシン上のログに「Workload cluster 'tkg21wc01' created」と表示されていれば正常にデプロイできています。 ![](https://www.munenick.me/hackmd/uploads/upload_ee5726a7f90aa166d3819d4d8635d73c.png) ### Tanzu CLIコマンドで確認 - BootStrapマシンにアクセスし、以下のコマンドを実行してください。 ```bash MuNeNiCK [ ~ ]$ tanzu cluster list NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR tkg21wc01 default running 3/3 3/3 v1.24.10+vmware.1 prod v1.24.10---vmware.1-tkg.2 ``` ### vCenterにアクセスして確認 - vCenter Serverにアクセスし、「TKG」→「Workload」フォルダ内に仮想マシンが作成されていることを確認してください。 ![](https://www.munenick.me/hackmd/uploads/upload_7e844caaa6704ff15119e06b872b2b8b.png) ### NSX ALBにアクセスして確認 - NSX ALBにログインし、「アプリケーション」→「ダッシュボード」にアクセスすることでデプロイを確認できます。 ![](https://www.munenick.me/hackmd/uploads/upload_5ef9637ca1229bc4ed5a65063fe6fc49.png) # Workloadクラスタへの接続 Workloadクラスタに接続し、クラスタの管理を行うためいくつかっも操作が必要になります。 - まず、以下のコマンドを実行してkubeconfigを取得してください。 ```bash MuNeNiCK [ ~ ]$ tanzu cluster kubeconfig get tkg21wc01 --admin Credentials of cluster 'tkg21wc01' have been saved You can now access the cluster by running 'kubectl config use-context tkg21wc01admin@tkg21wc01' ``` - 次にログに出力されている通り、以下のコマンドを実行します。 ```bash MuNeNiCK [ ~ ]$ kubectl config use-context tkg21wc01-admin@tkg21wc01 Switched to context "tkg21wc01-admin@tkg21wc01". ``` - 以下のコマンドを実行して現在のコンテキストを確認してください ```bash MuNeNiCK [ ~ ]$ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE tkg21mc01-admin@tkg21mc01 tkg21mc01 tkg21mc01-admin * tkg21wc01-admin@tkg21wc01 tkg21wc01 tkg21wc01-admin ``` - コンテキストを使用してクラスタのノードを確認します。以下のコマンドを実行してください。 ```bash MuNeNiCK [ ~ ]$ kubectl get nodes NAME STATUS ROLES AGE VERSION tkg21wc01-md-0-bzhsf-7876ffdcb7-8nkg8 Ready 8h v1.24.10+vmware.1 tkg21wc01-md-1-hxlzn-7cbf69bd58-4tqjc Ready 8h v1.24.10+vmware.1 tkg21wc01-md-2-nrn7z-6bb84c66c-gxjgx Ready 8h v1.24.10+vmware.1 tkg21wc01-mdcg5-52ld6 Ready control-plane 8h v1.24.10+vmware.1 tkg21wc01-mdcg5-n46zx Ready control-plane 7h53m v1.24.10+vmware.1 tkg21wc01-mdcg5-zkqg8 Ready control-plane 8h v1.24.10+vmware.1 ``` # Podの動作確認 WorkloadクラスタおよびNSX ALBが正常に動作することを確認するために以下の手順を実行してください。 - 以下のコマンドを実行してテストを作成してください。 ```bash MuNeNiCK [ ~ ]$ kubectl run hello --image=gcr.io/google-samples/node-hello:1.0 pod/hello created ``` - 以下のコマンドでPodの起動を確認してください。(起動までに数分かかります) ```bash MuNeNiCK [ ~ ]$ kubectl get pods NAME READY STATUS RESTARTS AGE hello 1/1 Running 0 101s ``` - NSX ALBのLoad Balancerからアクセスできるように以下のコマンドを実行してPodに対応したServiceを作成してください。 ```bash MuNeNiCK [ ~ ]$ kubectl expose pod hello --type=LoadBalancer --port=80 --target-port=8080 service/hello exposed ``` - 以下のコマンドでServiceの起動と割り当てられたExternal-IPアドレスを確認してください。 ```bash MuNeNiCK [ ~ ]$ kubectl get service hello NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello LoadBalancer 100.65.13.125 192.168.100.105 80:31362/TCP 108s ``` - ブラウザを起動し、先程確認したIPアドレスにアクセスしてください。アクセスできましたら、正常にWorkloadクラスタおよびNSX ALBのロードバランサが動作していることがわかります。 ![](https://www.munenick.me/hackmd/uploads/upload_159ea5bfda2f659d6a7167626c195388.png) - NSX ALBにログインし、「アプリケーション」→「ダッシュボード」でも確認することができます。 ![](https://www.munenick.me/hackmd/uploads/upload_0a1e9cdbfc84c08d09e5df7b651c4405.png) - 最後に以下のコマンドを実行し、作成したPodとServiceを削除してください。これらの削除を行うとNSX ALBの仮想サービスも自動的に削除されます。 ```bash MuNeNiCK [ ~ ]$ kubectl delete pod hello pod "hello" deleted MuNeNiCK [ ~ ]$ kubectl get pod No resources found in default namespace. MuNeNiCK [ ~ ]$ kubectl delete service hello service "hello" deleted MuNeNiCK [ ~ ]$ kubectl get service hello Error from server (NotFound): services "hello" not found ``` ![](https://www.munenick.me/hackmd/uploads/upload_f23a59bda25a36952a697a3121a81e07.png) # AutoScalerの設定(オプション) [AutoScalerの設定](/blog/tkg-nsx-alb-03#workloadクラスタ用yamlの作成)を行っている場合、この項目を実施してください。 - 以下のコマンドを実行してマネジメントクラスタのコンテキストに切り替えてください。 ```bash MuNeNiCK [ ~ ]$ kubectl config use-context tkg21mc01-admin@tkg21mc01 Switched to context "tkg21mc01-admin@tkg21mc01". ``` - 以下のコマンドを実行し、MachineDeploymentの名前を確認してください。 ```bash MuNeNiCK@BootStrap [ ~ ]$ kubectl get md NAME CLUSTER REPLICAS READY UPDATED UNAVAILABLE PHASE AGE VERSION tkgwc01-md-0-24cdt tkgwc01 1 1 1 0 Running 14h v1.25.7+vmware.2 tkgwc01-md-1-85fmf tkgwc01 1 1 1 0 Running 14h v1.25.7+vmware.2 tkgwc01-md-2-wfhc7 tkgwc01 1 1 1 0 Running 14h v1.25.7+vmware.2 ``` - 以下のコマンドを使用して、すべてのMachineDeploymentの最小デプロイ数を指定してください。 ```bash kubectl annotate machinedeployment MD-NAME cluster.k8s.io/cluster-api-autoscaler-node-group-min-size="MIN-SIZE" ``` ![](https://www.munenick.me/hackmd/uploads/upload_191566b5d9164dfd28321d1e69f6933c.png) - 以下のコマンドを使用して、すべてのMachineDeploymentの最小デプロイ数を指定してください。 ```bash kubectl annotate machinedeployment MD-NAME cluster.k8s.io/cluster-api-autoscaler-node-group-max-size="MAX-SIZE" ``` ![](https://www.munenick.me/hackmd/uploads/upload_ed81d0fc7a0d9e8b68cb9bdc9ca58412.png) - 以下のコマンドを実行してAutoScalerの動作のReadyが1/1になっていることを確認してください。 ```bash MuNeNiCK@BootStrap [ ~ ]$ kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE tkgwc01-cluster-autoscaler 1/1 1 1 14h ``` 以上でTKGクラスタおよびNSX ALBの動作確認は完了です。 # 次回 BootStrapマシンは一時的なマシンであるため、基本的にManagementクラスタおよびWorkloadクラスタをデプロイしたら削除するそうです。そのため、Tanzu CLIを実行し、2つのクラスタを管理するマシンを別途作成する必要があるようです。次回は別マシンでTanzu CLIを実行し、クラスタを管理する方法を紹介します。この段階ではまだBootStrapマシンを削除しないでください。 https://www.munenick.me/blog/tkg-nsx-alb-04 # 参考にさせていただいたサイト - [はじめての Tanzu Kubernetes Grid。Part-04：Management Cluster の作成](https://vm.gowatana.jp/entry/2023/01/09/165420) - [はじめての Tanzu Kubernetes Grid。Part-05：Workload Cluster の作成](https://vm.gowatana.jp/entry/2023/01/09/165724) - [Tanzu Kubernetes Grid と NSX ALB でのラボ構築。](https://vm.gowatana.jp/entry/2023/01/17/033606) - [vSphere環境への TKG 1.4.0 with NSX-ALB の簡易展開手順](https://blogs.vmware.com/vmware-japan/2021/10/tkg-1-4-0-install.html) - [クラスタのスケーリング](https://docs.vmware.com/jp/VMware-Tanzu-Kubernetes-Grid/2.1/using-tkg-21/workload-clusters-scale.html)

Tanzu Kubernetes Grid2.1とNSX ALBでKubernetes環境を構築する方法(Tanzu Kubernetes Grid構築編)

目次