vm.gowatana.jp

NEOにほんごVMware（仮）

Tanzu Kubernetes Grid と NSX ALB でのラボ構築。

Tanzu Kubernetes Grid (TKG) Avi (NSX ALB) Lab-Entrance

Tanzu Kubernetes Grid で NSX Advanced Load Balancer（NSX ALB）を利用するラボ環境を構築してみます。

 

今回の内容です。

 

今回の環境

利用するソフトウェアは下記です。

  • Tanzu Kubernetes Grid 1.6.1
  • NSX Advanced Load Balancer 22.1.2

 

NSX ALB は、事前に下記のように構築しておきます。

 

そして TKG は、下記の投稿で用意した TKG ラボ環境を利用します。今回は kube-vip のかわりに NSX ALB を選択して Management / Workload Cluster を作成します。

 

構築するラボのイメージ図です。

 

1. NSX ALB のコントローラ証明書 入れ替え

TKG から NSX ALB に接続する場合、NSX ALB のコントローラ 証明書に SAN（サブジェクトの別名）が必要ですが、デフォルトで生成される証明書には設定されていません。そこで、NSX ALB の Web UI でコントローラ証明書を作成して置き換えます。

 

1-1. コントローラ証明書の作成

「テンプレート」→「セキュリティ」→「SSL/TLS 証明書」を開いて、「作成」→「コントローラ証明書」をクリックします。

 

「全般」で、名前とタイプを入力して下にスクロールします。

  • 名前： cert_lab-avi-02.go-lab.jp
  • タイプ： 自己尾署名済み

 

証明書のフィールドを入力して、さらに下にスクロールします。ちなみにここでいくつかフィールドを入力していますが、実際は「共通名」以外はデフォルトのままでも大丈夫です。

  • 共通名： lab-avi-02.go-lab.jp

 

「サブジェクトの別名 (SAN)」で「追加」をクリックして、NSX ALB Controller VM の FQDN と IP アドレスを入力して、「保存」をクリックします。すでに「共通名」で FQDN を入力している場合でも、ここであらためて FQDN の入力が必要です。

  • lab-avi-02.go-lab.jp（FQDN）
  • 192.168.10.62

 

これでコントローラ証明書が作成されました。

 

1-2. コントローラ証明書の置き換え

「管理」→「設定」→「アクセス設定」を開いて、編集ボタンをクリックします。

 

「SSL/TLS 証明書」で、もともと設定されている2件を削除して、作成したコントローラ証明書を選択して「保存」をクリックします。

  • SSL/TLS 証明書： cert_lab-avi-02.go-lab.jp


設定が保存されてから Web ブラウザを更新すると証明書エラーの画面になるので、初回アクセス時と同様にエラーを無視してページを開きます。

 

Web ブラウザで、証明書の情報を確認してみます。

 

証明書が入れ替えられたことが確認できます。

 

2. NSX ALB 側でのデプロイ準備

構築済みの NSX ALB の Web UI にログインして、この TKG むけの設定を追加します。

 

2-1. DHCP ネットワークの設定

TKG では、Kubernetes ノード仮想マシンに DHCP で IP アドレスを設定します。そこで、NSX ALB が DHCP ネットワークのポートグループを利用できるように設定します。ついでに、今回は NSX ALB Service Engine の Kubernetes ノード仮想マシン側のインターフェースでも DHCP を利用します。

「インフラストラクチャ」→「クラウド リソース」→「ネットワーク」を開いて、DHCP が利用できるようになっているネットワークのポートグループの編集ボタンをクリックします。

 

「DHCP が有効」のチェックをオンにして、「サブネットの追加」をクリックします。

 

ネットワーク アドレスを入力して、「保存」をクリックします。

  • IP サブネット： 192.168.11.0/24

 

ひとつ前の画面に戻るので、IP サブネットのタイプが「構成済み」になったことを確認して「保存」をクリックします。

 

これで「構成されたサブネット」にネットワーク アドレスが表示されるようになります。

 

2-2. IPAM プロファイルの準備

NSX ALB の Default-Cloud に、VIP を配置するネットワークの IPAM プロファイルを設定します。この手順で選択するネットワーク（ポートグループ）では、以前の NSX ALB 環境構築で IP プールを設定ずみです。

  • ネットワーク： 192.168.61.0/24
  • ポートグループ： dvpg-0061-avi-01

 

IPAM プロファイルの作成

「テンプレート」→「プロファイル」→「IP アドレス管理 / DNS プロファイル」を開いて、「作成」→「IP アドレス管理プロファイル」をクリックします。

 

プロファイルのパラメータを入力して、「保存」をクリックします。

  • 名前： ipam-profile-61
  • クラウド： Default-Cloud
  • ネットワーク：「追加」をクリックして「dvpg-0061-avi-01」を選択。

 

IPAM プロファイルの割り当て

Default-Cloud に、IPAM プロファイルを割り当てます。

「インフラストラクチャ」→「クラウド」を開いて、「Default-Cloud」の編集ボタンをクリックします。

 

IPAM プロファイルを選択して、「保存」をクリックします。

  • IP アドレス管理プロファイル： ipam-profile-61

 

2-3. スタティック ルートの追加

VIP ネットワークのスタティック ルートを追加しておきます。

「インフラストラクチャ」→「クラウド リソース」→「VRF コンテキスト」を開いて、「global」の編集ボタンをクリックします。

 

サブネットの「追加」をクリックして、スタティック ルートを入力して「保存」をクリックします。

  • ゲートウェイ サブネット： 0.0.0.0/0
  • ネクスト ホップ： 192.168.61.1

 

2-4. ダミー Virtual Service の作成

NSX ALB では、Virtual Service を作成することで自動的に Service Engine VM がデプロイされるのですが、TKG での Kubernetes クラスタ作成は、時間がかかるとタイムアウトで失敗してしまうことがあります。

そこで、あえて事前に何か Virtual Service を作成して Service Engine VM を事前デプロイしておきます。

適当な Virtual Service を作成してしばらく待ち、「インフラストラクチャ」→「クラウド リソース」→「サービス エンジン」画面などで、Service Engine VM がデプロイされたことを確認しておきます。

 

2. TKG Management Cluster の作成

TKG の Management Cluster を作成します。

まず、今回の Management Cluster と Workload Cluster の仮想マシンをデプロイする仮想マシン フォルダを作成しておきます。

 

TKG の Bootstrap マシンで、下記の手順（kube-vip を選択）と同様に「tanzu management-cluster create」または「tanzu mc create」コマンドを実行てウィザードを進めます。

 

Management Cluster を作成します。

demo-01 [ ~ ]$ tanzu mc create --ui --bind=0.0.0.0:8080 --browser=none

 

ここでは、kube-vip の場合と異なる部分を説明します。

 

Wizard: 2. Cluster Settings

Control Plane の Endpoint Proider として、kube-vip のかわりに NSX ALB を選択します。

  • CONTROL PLANE ENDPOINT PROVIDER として、「NSX Advanced Load Balancer」を選択します。
  • CONTROL PLANE ENDPOINT の IP アドレスは、kube-vip 選択時とは異なり、空欄のままでも進めるようになります。


Wizard: 3. VMware NSX Advanced Load Balancer

この画面は、kube-vip 選択時とは異なり入力必須になります。

  • CONTROLLER HOST： NSX ALB Controller VM のアドレスを入力します。ラボ用途であれば、NSX ALB Controller のクラスタの VIP は設定していなくても TKG では利用できます。
  • USERNAME： admin など
  • PASSWORD
  • CONTROLLER CERTIFICATE AUTHORHITY： 先ほど作成したコントローラ証明書のテキストを入力します。

ここまでを入力したら、「VERIFY CREDENTIALS」をクリックします。

 

ここで入力するコントローラ証明書のテキストについては、NSX ALB の Web UI から取得します。

「テンプレート」→「セキュリティ」→「SSL/TLS 証明書」を開き、さきほど作成したコントローラ証明書の「↓」ボタンをクリックします。

 

「証明書」→「クリップボードにコピー」ボタンをクリックすると証明書のテキストをコピーできるので、TKG のウィザードにペーストします。

 

「VERIFY CREDENTIALS」のクリックによる確認が通ると、CLOUD NAME で NSX ALB の 「Default-Cloud」が選択できるようになります。そのまま、（ここで作成するのは Management Cluster ですが）Workload Cluster と Management Cluster のパラメータを入力します。

今回は、ここで指定するすべての VIP アドレスを同じネットワークに配置します。

 

Workload Cluster

  • SERVICE_ENGINE_GROUP: Default-Group
  • WORKLOAD CLUSTER - CONTROL PLANE VIP NETWORK NAME: dvpg-0061-avi-01
  • WORKLOAD CLUSTER CONTROL PLANE VIP NETWORK CIDR: 192.168.61.0/24
  • WORKLOAD CLUSTER - VIP NETWORK NAME: dvpg-0061-avi-01
  • WORKLOAD CLUSTER VIP NETWORK CIDR: 192.168.61.0/24

Management Cluster

  • MANAGEMENT CLUSTER - SERVICE ENGINE GROUP: Default-Group
  • MANAGEMENT CLUSTER - CONTROL PLANE VIP NETWORK NAME: dvpg-0061-avi-01
  • MANAGEMENT CLUSTER CONTROL PLANE VIP NETWORK CIDR: 192.168.61.0/24
  • MANAGEMENT CLUSTER - VIP NETWORK NAME: dvpg-0061-avi-01
  • MANAGEMENT CLUSTER VIP NETWORK CIDR: 192.168.61.0/24

下記のようにパラメータを入力したら、さらに画面下にスクロールします。

 

そして「NEXT」をクリックして、「4. Metadata」画面に進みます。

 

YAML ファイルの取得

ウィザードを進めて「REVIEW CONFIGURATION」をクリックします

 

その直後に表示される設定確認画面の末尾にある、「EXPORT COFIGURATION」をクリックしてここまでの入力から生成された YAML ファイルを保存しておきます。

このファイルを「tanzu mc create」の「-f」オプションで指定することで、CLI から Management Cluster を作成できるようになります。

そして、「DEPLOY MANAGEMENT CLUSTER」をクリックすると、クラスタの作成処理が開始されます。

 

tanzu mc create でのタイムアウト時間指定

本来であれば、このまま Management Cluster が作成できます。しかし、仮想マシンのクローンなどで時間がかかると、クラスタの作成が失敗になることがあります。

 

例えば、下記のようにエラーが出力されたりします。

unable to set up management cluster, : unable to initialize providers on management cluster: timed out waiting for the condition, this can be possible because of the outbound connectivity issue. Please check deployed nodes for outbound connectivity.

 

エラーによって中断されてしまった場合、作成途中のまま残された Management Cluster は下記のコマンドなどで削除します。

demo-01 [ ~ ]$ tanzu mc delete -y

 

この場合、さきほど「EXPORT COFIGURATION」ボタンでダウンロードした YAML ファイル（tkg16mc02.yml として保存）を指定しておき、あらためて Tanzu CLI から作成することもできます。このとき、作成された YAML ファイルに「DEPLOY_TKG_ON_VSPHERE7: "true"」を追記しておくと、vSphere 7 へのデプロイを確認するメッセージをスキップできます。

ついでに、「--timeout」でタイムアウトを長め（デフォルトは 30m）に指定しておきます。

demo-01 [ ~ ]$ tanzu mc create -f tkg16mc02.yml --timeout=60m

 

3. TKG Workload Cluster の作成

 Management Cluster（tkg16mc02）を定義した YAML ファイルをもとに、Workload Cluster（tkg16wc02）の YAML ファイルを作成します。ここでは sed を利用して YAML 内のクラスタ名を書き換えます。

tkg16mc02 → tkg16wc02

demo-01 [ ~ ]$ cat tkg16mc02.yml | sed s/tkg16mc02/tkg16wc02/g > tkg16wc02.yml

 

ファイルの差分です。

demo-01 [ ~ ]$ diff tkg16mc02.yml tkg16wc02.yml
21c21
< CLUSTER_NAME: tkg16mc02
---
> CLUSTER_NAME: tkg16wc02
61c61
< VSPHERE_FOLDER: /infra-dc-01/vm/05-Lab-k8s/k8s_lab-tkg-02_demo-01/vm_tkg16mc02
---
> VSPHERE_FOLDER: /infra-dc-01/vm/05-Lab-k8s/k8s_lab-tkg-02_demo-01/vm_tkg16wc02

 

Workload Cluster を作成します。

demo-01 [ ~ ]$ tanzu cluster create -f tkg16wc02.yml

 

しばらく待つと Kubernetes クラスタが作成されます。

demo-01 [ ~ ]$ tanzu cluster list --include-management-cluster
  NAME       NAMESPACE   STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES       PLAN  TKR
  tkg16wc02  default     running  1/1           1/1      v1.23.10+vmware.1  <none>      dev   v1.23.10---vmware.1-tkg.1
  tkg16mc02  tkg-system  running  1/1           1/1      v1.23.10+vmware.1  management  dev   v1.23.10---vmware.1-tkg.1

 

kubeconfig を取得します。

demo-01 [ ~ ]$ tanzu cluster kubeconfig get tkg16wc02 --admin
Credentials of cluster 'tkg16wc02' have been saved
You can now access the cluster by running 'kubectl config use-context tkg16wc02-admin@tkg16wc02'

 

コンテキストを切り替えます。

demo-01 [ ~ ]$ kubectl config use-context tkg16wc02-admin@tkg16wc02
Switched to context "tkg16wc02-admin@tkg16wc02"

 

Workload Cluster に接続できるようになりました。

demo-01 [ ~ ]$ kubectl get nodes
NAME                             STATUS   ROLES                  AGE     VERSION
tkg16wc02-control-plane-26h4f    Ready    control-plane,master   5h35m   v1.23.10+vmware.1
tkg16wc02-md-0-7c9498c97-tfgct   Ready    <none>                 5h29m   v1.23.10+vmware.1

 

NSX ALB を操作する AKO（Avi Kubernetes Operator）がインストールされています。

demo-01 [ ~ ]$ kubectl api-resources --api-group=ako.vmware.com
NAME                    SHORTNAMES    APIVERSION                NAMESPACED   KIND
aviinfrasettings                      ako.vmware.com/v1alpha1   false        AviInfraSetting
hostrules               hostrule,hr   ako.vmware.com/v1alpha1   true         HostRule
httprules               httprule      ako.vmware.com/v1alpha1   true         HTTPRule
multiclusteringresses   mci           ako.vmware.com/v1alpha1   true         MultiClusterIngress
serviceimports          si            ako.vmware.com/v1alpha1   true         ServiceImport
demo-01 [ ~ ]$ kubectl -n avi-system get pods
NAME    READY   STATUS    RESTARTS   AGE
ako-0   1/1     Running   0          5h35m

 

Pod を起動してみます。

demo-01 [ ~ ]$ kubectl run hello --image=gcr.io/google-samples/node-hello:1.0
pod/hello created
demo-01 [ ~ ]$ kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
hello   1/1     Running   0          4m20s

 

そして、LoadBalancer Service を作成します。例では、VIP アドレスが 192.168.61.220 になりました。

demo-01 [ ~ ]$ kubectl expose pod hello --type=LoadBalancer --port=80 --target-port=8080
service/hello exposed
demo-01 [ ~ ]$ kubectl get service hello
NAME    TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
hello   LoadBalancer   100.70.94.41   192.168.61.220   80:30120/TCP   14s

 

下記のように、VIP 経由でコンテナにアクセスできるようになりました。

demo-01 [ ~ ]$ curl -s http://192.168.61.220:80 | more
Hello Kubernetes!

 

NSX ALB の Web UI でも LoadBalancer Service に対応する Virtual Service（VIP が 192.168.61.220）が確認できます。

 

以上、TKG + NSX ALB のラボ構築でした。