vm.gowatana.jp

NEOにほんごVMware(仮)

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-04 TKC 作成編

vSphere with Tanzu にて、NSX-T なしでの Tanzu Kubernetes クラスタのラボを構築していきます。今回は、スーパーバイザー クラスタに名前空間と、Tanzu Kubernetes クラスタ(TKC)を作成します。

 

前回はこちら。

 

TKC の作成は、基本的に vSphere 7.0 の頃と変わらないので、主に以前の投稿へのリンクと、その補足をお伝えします。

 

スーパーバイザー クラスタ 制御プレーンのアドレス確認

前回の作業で、vSphere クラスタで「ワークロード管理」が有効化されています。vSphere Client で「メニュー」→「ワークロード管理」→「クラスタ」を開くと、「構成ステータス」が「実行中」になっています。

「制御プレーン ノード」に表示されている IP アドレスは、「プライマリ」ワークロード ネットワーク(network-1)で指定した IP 範囲のうち、最初の IP アドレスが割り当てられているはずです。

f:id:gowatana:20201109104305p:plain

 

制御プレーンの IP アドレス(この環境では 192.168.21.128)は、
Kubernetes を操作するクライアント(kubectl)の接続先になります。

また、kubectl(と vSphere 接続用のプラグイン)のダウンロード サイトも提供されます。ネットワーク構成と、HAProxy デプロイとワークロード管理の有効化で指定した IP レンジが間違っていなければ、下記のページを表示することができるはずです。

f:id:gowatana:20201109104356p:plain

 

スーパーバイザー 名前空間の作成

vSphere with Tanzu での Tanzu Kubernetes クラスタは、NSX-T の利用の有無にかかわらず、スーパーバイザー名前空間に作成します。そこで、まずスーパーバイザー名前空間を作成しておきます。

 

「ワークロード管理」メニュー →「名前空間」を開いて、「名前空間の作成」をクリックします。

f:id:gowatana:20201109104426p:plain

 

名前空間の情報を入力して「作成」をクリックします。今回は下記のように入力しています。

  • クラスタ: wcp-cluster-04
  • 名前: lab-ns-41
  • ネットワーク: network-2

 

ネットワーク: network-2 については・・・

  • プライマリ ネットワーク(network-1)も選択できるはずです。
  • 今回は、ラボ構成の都合上 2つめのワークロード ネットワークを選択しています。

f:id:gowatana:20201109104500p:plain

 

名前空間が作成されました。はじめに表示されている説明は、閉じてしまってかまいません。

f:id:gowatana:20201109104531p:plain

 

この画面で、「権限の追加」と「ストレージの追加」を実施しておきます。

 

権限の追加

「権限の追加」では、vCenter Single Sign-on に登録された ID ソースのユーザー / グループに対して、名前空間への権限(表示可能 または 編集可能)を追加できます。

ID ソースには vCenter 組み込みのディレクトリが持つドメイン(デフォルトは vsphere.local)、Active Directory、LDAP サーバなどが利用できます。

しかし今回は vCenter に ID ソースを追加登録していないので、権限の追加は省略します。そして、この後のスーパーバイザークラスタへの接続では、デフォルトの vCenter 管理ユーザ(administrator@vsphere.local)を使用してしまいます。

 

ストレージの追加

ストレージの追加では、データストアのレイアウトを決定できる「仮想マシン ストレージ ポリシー」を選択します。このポリシーは、ワークロード管理の有効化(前回の投稿)で指定したものが利用できます。

「ストレージの管理」をクリックします。

f:id:gowatana:20201109104601p:plain

 

ポリシーを選択します。

f:id:gowatana:20201109104632p:plain

 

ポリシーが選択されました。

f:id:gowatana:20201109104655p:plain

 

これにより、スーパーバイザー クラスタで 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

 

ResourceQuota も作成されています。

$ 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 Networking を利用する(NSX-T がない)構成のため、vSphere Pod を起動することはできません。そのため、スーパーバイザー 名前空間で Pod を起動しようとするとエラーになります。

たとえば、下記のように vSphere 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 の頃と同様です。下記の投稿も参考にして下さい。

 

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 が今回のラボ構成にあっていなかったので指定しています。

gist.github.com

 

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 がデプロイされる様子が見られます。

f:id:gowatana:20201109104752p:plain

 

しばらく待つと、YAML で定義した台数の制御プレーン ノード、ワーカー ノードの VM が起動され、Kubernetes クラスタが作成された状態になります。

f:id:gowatana:20201109104816p:plain

 

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 クラスタの情報が確認できます。

f:id:gowatana:20201109104842p:plain

 

HAProxy による LoadBalancer の様子

TKC の制御プレーンの VIP は、HAProxy で提供されます。

スーパーバイザー クラスタ制御プレーンにて、Service リソース「tanzu-cluster-41-control-plane-service」を確認すると、EXTERNAL-IP が 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 を作成すると下記のようになります。

 

TKC から見た様子です。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

 

スーパーバイザー名前空間でも、同じ IP アドレスのサービスが確認できます。

$ 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 7.0 の頃と同じ手順がほとんどですが、実際に環境構築してみても、事前準備とネットワーク構成では以前より省略できる部分が多い印象を受けました。vSphere 環境での Kubernetes 利用について、ハードルが下がったのではないかと思います。

 

以上、vSphere 7.0 U1 での with Tanzu ラボ環境構築の様子でした。