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
• 制御プレーン / ワーカー ノードのスペック（class）： best-effort-xsmall
  • ラボなのでリソースの少ないものを指定しています。
• CNI： Antrea を使用。
  • 今回は、あえて「antrea」を指定しています。他に「calico」が指定できます。
  • services / pods ネットワークで使用するネットワーク（CIDR 表記）は、省略もできますが、
    デフォルトの CIDR が今回のラボ構成にあっていなかったので指定しています。

tanzu-cluster-41.yml · GitHub

---

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 ラボ環境構築の様子でした。