vSphere with Tanzu にて、NSX-T なしでの Tanzu Kubernetes クラスタのラボを構築していきます。
今回は、スーパーバイザー クラスタに名前空間と、Tanzu Kubernetes クラスタ（TKC）を作成します。
前回はこちら。
vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理 有効化編
TKC の作成は、基本的に vSphere 7.0 の頃と変わらないので、
主に以前の投稿へのリンクと、その補足をお伝えします。
スーパーバイザー クラスタ 制御プレーンのアドレス確認。
前回の作業で、vSphere クラスタで「ワークロード管理」が有効化されています。
vSphere Client で「メニュー」→「ワークロード管理」→「クラスタ」を開くと、
「構成ステータス」が「実行中」になっています。
「制御プレーン ノード」に表示されている IP アドレスは、
「プライマリ」ワークロード ネットワーク（network-1）で指定した IP 範囲のうち、
最初の IP アドレスが割り当てられているはずです。
制御プレーンの IP アドレス（この環境では 192.168.21.128）は、
Kubernetes を操作するクライアント（kubectl）の接続先になります。
また、kubectl（と vSphere 接続用のプラグイン）のダウンロード サイトも提供されます。
ネットワーク構成と、HAProxy デプロイとワークロード管理の有効化で指定した IP レンジが間違っていなければ、
下記のページを表示することができるはずです。
スーパーバイザー 名前空間の作成。
vSphere with Tanzu での Tanzu Kubernetes クラスタは、
NSX-T の利用の有無にかかわらず、スーパーバイザー名前空間に作成します。
そこで、まずスーパーバイザー名前空間を作成しておきます。
「ワークロード管理」メニュー →「名前空間」を開いて、「名前空間の作成」をクリックします。
名前空間の情報を入力して「作成」をクリックします。
今回は下記のように入力しています。
- クラスタ： wcp-cluster-04
- 名前： lab-ns-41
- ネットワーク： network-2
- プライマリ ネットワーク（network-1）も選択できるはずです。
- 今回は、ラボ構成の都合上 2つめのワークロード ネットワークを選択しています。
名前空間が作成されました。
はじめに表示されていう説明は、閉じてしまってかまいません。
この画面で、「権限の追加」と「ストレージの追加」を実施しておきます。
権限の追加
「権限の追加」では、vCenter Single Sign-on に登録された ID ソースのユーザー / グループに対して、
名前空間への権限（表示可能 または 編集可能）を追加できます。
ID ソースには vCenter 組み込みのディレクトリが持つドメイン（デフォルトは vsphere.local）、
Active Directory、LDAP サーバなどが利用できます。
しかし今回は vCenter に ID ソースを追加登録していないので、権限の追加は省略します。
そして、この後のスーパーバイザークラスタへの接続では、
デフォルトの vCenter 管理ユーザ（administrator@vsphere.local）を使用してしまいます。
ストレージの追加
ストレージの追加では、データストアのレイアウトを決定できる「仮想マシン ストレージ ポリシー」を選択します。
このポリシーは、ワークロード管理の有効化（前回の投稿）で指定したものが利用できます。
「ストレージの管理」をクリックします。
ポリシーを選択します。
ポリシーが選択されました。
これにより、スーパーバイザー クラスタで vSphere のデータストアを利用するための
StorageClass、ResourceQuota リソースが作成されます。
（のちのど）kubectl でスーパーバイザー クラスタに接続した際に、下記のようなリソースが確認できるはずです。
StorageClass の名前は、ストレージ ポリシーの名前から自動生成されます。
$ kubectl get storageclasses
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
vm-storage-policy-wcp csi.vsphere.vmware.com Delete Immediate true 3d
$ kubectl get resourcequotas
NAME AGE REQUEST LIMIT
lab-ns-41-storagequota 3d vm-storage-policy-wcp.storageclass.storage.k8s.io/requests.storage: 0/9223372036854775807
スーパーバイザー クラスタ / 名前空間への接続。
kubectl を入手して、スーパーバイザー クラスタに接続し、使用する名前空間を選択します。
接続方法は、vSphere 7.0 の頃と同様なので、下記の投稿を参考にしてください。
vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編
ただし、vSphere Networking を利用する（NSX-T がない）構成のため、vSphere Pod を起動することはできません。
そのため、スーパーバイザー 名前空間で Pod を起動しようとするとエラーになります。
$ kubectl run --image=centos:7 --generator=run-pod/v1 pod-01
Flag --generator has been deprecated, has no effect and will be removed in the future.
Error from server (workload management cluster uses vSphere Networking, which does not support action on kind Pod): admission webhook "default.validating.license.supervisor.vmware.com" denied the request: workload management cluster uses vSphere Networking, which does not support action on kind Pod
Tanzu Kubernetes クラスタ（TKC）の作成。
TKC は「Cluster API」を利用しており、マニフェスト（YAML 形式の定義）で Kubernetes クラスタを作成できます。
TKC 作成も vSphere 7.0 の頃と同様です。下記の投稿も参考にして下さい。
vSphere with Kubernetes ラボ環境構築。Part-13: Supervisor Namespace での Tanzu Kubernetes Cluster 作成編
Pod の接続されるネットワークに変更があり、
デフォルトの CNI が、Calico から Antrea になりました。
今回は下記のような YAML ファイルで、TKC を作成してみます。
- Kubernetes のバージョン： v1.18.5
- これは、コンテンツ ライブラリ（今回は cl-tkg-01）にある OVF テンプレートの名前から、利用可能なバージョンが分かります。
- バージョンは、完全な文字列（v1.18.5+vmware.1-tkg.1.c40d30d）や省略（v1.18）での指定も可能です。
- 制御プレーン（controlPlane）ノード数： 1
- ワーカー（workers）ノード数： 1
- CNI： Antrea を使用。
- 今回は、あえて「antrea」を指定しています。他に「calico」が指定できます。
- services / pods ネットワークで使用するネットワーク（CIDR 表記）は、省略もできますが、
デフォルトの CIDR が今回のラボ構成にあっていなかったので指定しています。
---
kind: TanzuKubernetesCluster
apiVersion: run.tanzu.vmware.com/v1alpha1
metadata:
name: tanzu-cluster-41
spec:
distribution:
version: v1.18.5
topology:
controlPlane:
count: 1
class: best-effort-xsmall
storageClass: vm-storage-policy-wcp
workers:
count: 1
class: best-effort-xsmall
storageClass: vm-storage-policy-wcp
settings:
network:
cni:
name: antrea
services:
cidrBlocks: ["10.21.0.0/16"]
pods:
cidrBlocks: ["10.22.0.0/16"]
kubectl で、スーパーバイザー クラスタに接続して、
スーパーバイザー名前空間「lab-ns-41」を使用するコンテキストに切り替えておきます。
$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.21.129
$ kubectl config use-context lab-ns-41
現在のコンテキストは、下記のように確認できます。
$ kubectl config current-context
lab-ns-41
YAML ファイルを指定して、TKC を作成します。
$ kubectl apply -f tanzu-cluster-41.yml
tanzukubernetescluster.run.tanzu.vmware.com/tanzu-cluster-41 created
自動的に Kubernetes ノードとなる VM がデプロイされていきます。
kubectl で、VM のデプロイ処理が開始されたことが確認できます。
$ kubectl get machine
NAME PROVIDERID PHASE
tanzu-cluster-41-control-plane-cpl82 Provisioning
tanzu-cluster-41-workers-54xhz-764f586457-f2mk8 Pending
vSphere Client でも、VM がデプロイされる様子が見られます。
しばらく待つと、YAML で定義した台数の制御プレーン ノード、ワーカー ノードの VM が起動され、
Kubernetes クラスタが作成された状態になります。
kubectl でも、最終的にすべての Machine が Running になるはずです。
$ kubectl get machine
NAME PROVIDERID PHASE
tanzu-cluster-41-control-plane-pmrcw vsphere://420c5f79-20b4-6e57-6cc8-bd079195e5aa Running
tanzu-cluster-41-workers-7mbf2-544d847df6-hh6nz vsphere://420c69bf-89a9-9697-4b10-66d7dbdf3012 Running
名前空間の「コンピューティング」→「Tanzu Kubernetes」でも
Tanzu Kubernetes クラスタの情報が確認できます。
TKC の制御プレーンの VIP も、HAProxy で提供されます。
「tanzu-cluster-41-control-plane-service」が、HAProxy の VIP レンジから払い出されていることが分かります。
$ kubectl get service -n lab-ns-41
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tanzu-cluster-41-control-plane-service LoadBalancer 10.96.0.79 192.168.21.129 6443:31848/TCP 1d2h
ちなみに、TKC で「type: LoadBalancer」の Service リソースを作成した場合も、この名前空間で、同じレンジから VIP が払い出されます。
たとえば、TKC の中で「tkc-ns-01」という名前空間を作成して、そこで LoadBalancer を作成すると下記のようになります。
（HAProxy による VIP 192.168.21.131 が提供されている様子です）
$ kubectl get service --context tanzu-cluster-41 -n tkc-ns-01
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
web-svc-a LoadBalancer 10.21.172.149 192.168.21.131 80:32456/TCP 3d1h
$ kubectl get service --context lab-ns-41 -n lab-ns-41
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tanzu-cluster-41-24f36e6c691ea3608647d LoadBalancer 10.96.0.102 192.168.21.131 80:32012/TCP 3d1h
tanzu-cluster-41-control-plane-service LoadBalancer 10.96.0.79 192.168.21.129 6443:31848/TCP 3d2h
TKC への接続 / Pod 起動。
TKC への接続や、Pod などのリソース管理も、vSphere 7.0 の頃と同様です。
下記を参考にしてください。
vSphere with Kubernetes ラボ環境構築。Part-14: Tanzu Kubernetes Cluster への接続 / Pod 起動編
vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編
Tanzu Kubernetes Cluster への接続。（実験編）
一連の流れをとおして vSphere 7.0 の頃と同じ手順がほとんどですが、
実際に環境構築してみても、事前準備とネットワーク構成では以前より省略できる部分が多い印象を受けました。
vSphere 環境での Kubernetes 利用について、ハードルが下がったのではないかと思います。
以上、vSphere 7.0 U1 での with Tanzu ラボ環境構築の様子でした。
