Skip navigation
2020

前回は、vSphere with Kubernetes のラボ環境で、Tanzu Kubernetes Cluster 作成の準備作業をしました。

今回は Tanzu Kubernetes Cluster を作成してみます。

 

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編

 

Tanzu Kubernetes Grid(TKG)サービスで利用されている Cluster API では、

Management Cluster と Workload Cluster という役割の Kubernetes クラスタが登場しますが、

今回作成する Tanzu Kubernetes Cluster は、Workload Cluster にあたります。

 

Supervisor Cluster への接続。

kubectl で、Supervisor Cluster に接続します。

vSphere 専用の kubectl の準備については、下記の投稿のようにしています。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

 

kubectl では、下記のようログインにしてます。

  • この環境では Supervisor Cluster の Control Plane アドレスとして、192.168.70.33 を指定します。
  • このあとの対話入力で、administrator@vsphere.local とパスワードを入力。

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33

 

環境の確認。

前回の準備をふまえて、あらためて環境確認をしておきます。

 

今回は、名前空間「lab-ns-02」に Tanzu Kuberntes Cluster を作成するので、

同名の Context に切りかえておきます。

$ kubectl config use-context lab-ns-02

Switched to context "lab-ns-02".

 

作成されている Storage Class です。

あとで Tanzu Kuberntes Cluster の設定値として YAML で指定するので、

「vm-storage-policy-wcp」という名前をひかえておきます。

$ kubectl get storageclasses

NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE

vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           false                  7h

 

名前空間へのコンテンツ ライブラリ追加により、VirtualMachineImage の情報取得ができるようになっています。

イメージの名前(NAME 列)の文字列から、このあとの YAML では Kubernetes バージョン「v1.16.8」を指定します。

$ kubectl get virtualmachineimages

NAME                                                        VERSION                          OSTYPE

ob-15957779-photon-3-k8s-v1.16.8---vmware.1-tkg.3.60d2ffd   v1.16.8+vmware.1-tkg.3.60d2ffd   vmwarePhoton64Guest

 

Tanzu Kuberntes Cluster の YAML 作成。

Tanzu Kuberntes Cluster の設定値を記載したマニュフェストを、YAML 形式のファイルとして作成します。

 

tkg-cluster-01.yml

---

kind: TanzuKubernetesCluster

apiVersion: run.tanzu.vmware.com/v1alpha1

metadata:

  name: tkg-cluster-01

spec:

  distribution:

    version: v1.16.8

  topology:

    controlPlane:

      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

    workers:

      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

  settings:

    network:

      cni:

        name: calico

      services:

        cidrBlocks: ["198.51.100.0/12"] # Cannot overlap with Supervisor Cluster

      pods:

        cidrBlocks: ["192.0.2.0/16"]    # Cannot overlap with Supervisor Cluster

    storage:

      classes: ["vm-storage-policy-wcp"]  # Named PVC storage classes

      defaultClass: vm-storage-policy-wcp # Default PVC storage class

 

YMAL では、下記のようにパラメータを指定しています。

 

Kubernetes のバージョンは、コンテンツ ライブラリに登録されている OVF テンプレート

(にもどづく VirtualMachineImage の名前)の文字列を指定します。

ここでは省略して「v1.16.8」と指定しています。

  • spec.distribution.version

 

各所で指定している「vm-storage-policy-wcp」は、

名前空間へのストレージ ポリシー追加で自動的に作成・利用可能になった、

仮想マシン ストレージ ポリシーと同名の StorageClass です。

 

CIDR によるアドレス範囲は、Supervisor Cluster とは別のものを指定します。

ちなみに、Pod Network の CNI では、Calico が使用されます。

  • spec.settings.network.services.cidrBlocks
  • spec.settings.network.pods.cidrBlocks

 

Control Plane ノード、Worker ノードは、それぞれ 3ノードです。

  • spec.topology.controlPlane.count
  • spec.topology.worker.count

 

Control Plane ノード、Worker ノードの VM スペックは、下記で指定しています。

ここでは、「best-effort-xsmall」を指定しています。

  • spec.topology.controlPlane.class
  • spec.topology.worker.class

 

ここで指定している class(VirtualMachineClass)には、下記が用意されています。

$ kubectl get virtualmachineclasses

NAME                 AGE

best-effort-large    12d

best-effort-medium   12d

best-effort-small    12d

best-effort-xlarge   12d

best-effort-xsmall   12d

guaranteed-large     12d

guaranteed-medium    12d

guaranteed-small     12d

guaranteed-xlarge    12d

guaranteed-xsmall    12d

 

ちなみに、今回指定した VirtualMachineClass「best-effort-xsmall」は、下記のようなスペックです。

vCPU は 2個(cpus: 2)、メモリ容量は 2GiB(memory: 2Gi)です。

$ kubectl get virtualmachineclasses best-effort-xsmall -o yaml

apiVersion: vmoperator.vmware.com/v1alpha1

kind: VirtualMachineClass

metadata:

  annotations:

    kubectl.kubernetes.io/last-applied-configuration: |

      {"apiVersion":"vmoperator.vmware.com/v1alpha1","kind":"VirtualMachineClass","metadata":{"annotations":{},"name":"best-effort-xsmall"},"spec":{"hardware":{"cpus":2,"memory":"2Gi"}}}

  creationTimestamp: "2020-05-24T15:20:10Z"

  generation: 1

  name: best-effort-xsmall

  resourceVersion: "2182"

  selfLink: /apis/vmoperator.vmware.com/v1alpha1/virtualmachineclasses/best-effort-xsmall

  uid: b5a801bc-28d4-4526-966b-7e30dbc9b570

spec:

  hardware:

    cpus: 2

    memory: 2Gi

 

Tanzu Kubernetes Cluster の作成。

それでは、Tanzu Kubernetes Cluster を作成します。

用意した YAML を指定して、kubectl apply を実行します。

$ kubectl apply -f ./tkg-cluster-01.yml

tanzukubernetescluster.run.tanzu.vmware.com/tkg-cluster-01 created

 

しばらく待つと、lab-ns-02 名前空間に、Kubernetes のノードになる VM がデプロイ、起動されます。

これらの VM(のゲスト OS)で、Tanzu Kubernetes Cluster が構成されています。

wcp-12-28.png

 

Kubernetes のバージョンは、v1.16.8 になっています。

これは、Supervisor Cluster の Kubernetes バージョンと一致するわけではありません。

kubectl でログイン先として指定する、制御プレーンのアドレスもわかります。

(これは、Supervisor Cluster への接続と同じアドレスです)

wcp-12-30.png

 

YAML で指定したとおり、Kubernetes Node が VM で作成されています。

Control Plane Node(VM 名は、<クラスタ名>-control-plane-~) が 3 VM、

Worker Node(VM 名は、<クラスタ名>-worker-~)が 3 VM 作成されています。

どちらも、仮想マシン クラスは、best-effort-xsmall になっています。

wcp-12-31.png

 

続く?

vSphere with Kubernetes ラボ環境構築。Part-14: Tanzu Kubernetes Cluster への接続 / Pod 起動編

ここまでに、vSphere with Kubernetes のラボ環境を構築して、

名前空間(Supervisor Namespace)に vSphere Pod を起動してみました。

 

前回の投稿はこちら。

vSphere with Kubernetes ラボ環境構築。Part-11: kubectl で vSphere Pod 起動編

 

vSphere with Kubernetes では、おもに 2種類の方法でコンテナを起動できます。

  1. Supervisor Cluster(ESXi が Kubernetes Worker ノード)の上で、vSphere Pod を起動する。※前回の投稿。
  2. Supervisor Cluster のうえに、さらに ゲスト OS による Kubernetes クラスタ(Tanzu Kubernetes Cluster)を作成して、その上で Pod を起動する。

wcp-01-p01.png

 

今回から、前回までに構築した Subervisor Cluster に、Tanzu Kubernetes Cluster のデモ環境を構築していきます。

つまり、Supervisor Namespace に Tanzu Kubernetes Grid サービスによる Kubernetes Cluster

(ドキュメントでは Tanzu Kubernetes Cluster)を作成してみます。

vSphere with Kubernetes での Tanzu Kubernetes クラスタの実行

 

Tanzu Kubernetes Grid(TKG)は、Cluster API という Kubernetes クラスタ自体のライフサイクルを管理できる API を利用しています。

Cluster API では、おもに 2種類の Kubernetes クラスタが登場します。

  • Management Cluster
    • Kubernetes クラスタを管理するための Kubernetes クラスタ。
    • vSphere with Kubernetes の TKG では、Subervisor Cluster が Management Cluster になる。
  • Workload Cluster
    • 実際になにかしたいワークロードを展開するための Kubernetes クラスタ。
    • vSphere with Kubernetes の TKG では、Subervisor Cluster の名前空間に VM がデプロイされて、そのゲスト OS でさらに Kubernetes クラスタが作成される。

 

ここからは、Management Cluster での準備作業です。

 

コンテンツ ライブラリの準備。

TKG では、Kubernetes ノードになる VM のテンプレートを利用します。

そして、vSphere with Kubernetes の TKG では、VM テンプレートの配置に vCenter のコンテンツ ライブラリを利用します。

 

ここでは、TKG で利用するコンテンツ ライブラリを作成して、コンテンツを同期(インターネット経由でダウンロード)しておきます。

vSphere Client で、「コンテンツ ライブラリ」メニューを開きます。

wcp-12-01.png

 

「作成」ボタンをクリックして、「新しいコンテンツ ライブラリ」画面を開きます。

コンテンツ ライブラリの名前は「lib-tkg-01」にしています。

wcp-12-03.png

 

「コンテンツ ライブラリの設定」では、次のように入力して「NEXT」をクリックします。

  • 「サブスクライブ済み コンテンツ」を選択
  • サブスクリプション URL を入力: https://wp-content.vmware.com/v2/latest/lib.json
    ※製品ドキュメントにある URL です。
  • コンテンツのダウンロード: 今すぐ(デフォルトのまま)

wcp-12-04.png

 

ストレージの追加では、ダウンロードされたコンテンツを格納するデータストアを選択します。

wcp-12-06.png

 

コンテンツ ライブラリが作成されました。

しばらく待つと、コンテンツ ライブラリの同期が完了します。

この処理は 5GB を超えるファイルのダウンロードなので、そこそこ時間がかかります。

※「ライブラリの同期」タスクは 0% の状態が長く続きます。

 

同期の完了したコンテンツ ライブラリで、名前(lib-tkg-01)をクリックします。

wcp-12-10.png

 

「OVF & OVA テンプレート」を開くと、

Kubernetes ノードになる VM テンプレートが見つかります。

名前の文字列から、Kubernetes のバージョンが v1.16.8 であることがわかります。

wcp-12-11.png

 

名前空間でのコンテンツ ライブラリ追加。

名前空間で、TKG が VM テンプレートをさがすコンテンツ ライブラリを追加します。

名前空間(ここでは lab-ns-02)の「サマリ」→「Tanzu Kubernetes」で、

「ライブラリの追加」をクリックします。

wcp-12-22.png

 

「ライブラリの追加」をクリックします。

※名前空間の「設定」→「名前空間」→「全般」を直接ひらいても大丈夫です。

wcp-12-23.png

 

先ほど作成・同期したコンテンツ ライブラリを選択し、「OK」をクリックします。

wcp-12-24.png

 

コンテンツ ライブラリが追加されました。

wcp-12-25.png

 

これにより、Kubernetes の VirtualMachineImage リソースが作成されます。

kubectl で接続(前回の投稿参照)すれば、下記のようにリソースの存在を確認できます。

$ kubectl get virtualmachineimages

NAME                                                        VERSION                          OSTYPE

ob-15957779-photon-3-k8s-v1.16.8---vmware.1-tkg.3.60d2ffd   v1.16.8+vmware.1-tkg.3.60d2ffd   vmwarePhoton64Guest

 

名前空間への仮想マシン ストレージ ポリシーの追加。

名前空間に、仮想マシン ストレージ ポリシーを追加します。

この手順により、この仮想マシン ストレージ ポリシーによってデータストアを利用する、Kubernetes の StorageClass リソースが用意されます。

 

名前空間(ここでは lab-ns-02)の「サマリ」→「ストレージ」で、「ストレージの追加」をクリックします。

wcp-10-43.png

 

仮想マシン ストレージ ポリシーを選択して、「OK」をクリックします。

wcp-10-44.png

 

名前空間に、仮想マシン ストレージ ポリシーが追加されました。

wcp-10-45.png

 

これにより、Kubernetes の StorageClasse リソースが作成されます。

kubectl で接続(前回の投稿参照)すれば、下記のようにリソースの存在を確認できます。

$ kubectl get storageclasses

NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE

vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           false                  7h

 

つづく・・・。

vSphere with Kubernetes ラボ環境構築。Part-13: Supervisor Namespace での Tanzu Kubernetes Cluster 作成編

vSphere with Kubernetes を体験するためのラボ環境構築をしたので、

kubectl で接続して、コンテナ を Kubernetes の Pod(vSphere Pod)として起動してみます。

Supervisor Cluster に作成した名前空間の配下の管理は、基本的には vSphere 専用の kubectl を利用します。

 

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-10: Supervisor Cluster 有効化編

 

クライアント環境について。

今回は、kubectl を実行するクライアントとして Linux(VMware Photon OS 3.0)を利用しています。

gowatana [ ~ ]$ cat /etc/photon-release

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=49d932d

 

Photon OS はデフォルトのパッケージが少ないので、

あらかじめ root ユーザで RPM を追加インストールしておきます。

  • photon-checksum-generator: ハッシュ値確認のため(sha256sum コマンド)
  • unzip: kubectl の zip ファイル(vsphere-plugin.zip)の解凍のため。

root@vm01 [ ~ ]# tdnf install -y photon-checksum-generator unzip

 

kubectl のダウンロード ページ。

まず、vSphere 専用の kubectl をダウンロードします。

 

この環境の Supervisor Cluster には、名前空間「lab-ns-01」、「lab-ns-02」を作成してあります。

ダウンロード サイトには、「名前空間」のサマリページにある「開く」リンクからアクセスできます。

wcp-11-01.png

 

「Kubernetes CLI Tools」ページが開けます。

ちなみに、このサイトのアドレスは、Supervisor Control Plane VM (のアドレスをメンバにしている NSX-T の LB の VIP)のものです。

Web ブラウザのアドレスバーを見ると、今回の IP アドレスは、192.168.70.33 になっています。

このあとの kubectl での接続先も、この IP アドレスです。

wcp-11-02.png

 

ダウンロードサイトでは、Windows / Linux / Mac OS 用の kubectl と、

それぞれの SHA256 ハッシュ値のファイルが提供されます。

wcp-11-03.png

 

OS ごとの kubectl の利用手順も、このページに記載されています。

wcp-11-04.png

 

kubectl のダウンロード ~ ログイン。

「Kubernetes CLI Tools」ページにある「CLI PLUGIN LINUX」と「Checksum CLI plugin Linux」から

右クリック メニューなどでダウンロード URL を取得しておきます。

そして、今回 kubectl を実行する Linux からダウンロードします。

 

kubectl の zip ファイル(vsphere-plugin.zip)を、curl でダウンロードします。

gowatana [ ~ ]$ curl -k -L -O https://192.168.70.33/wcp/plugin/linux-amd64/vsphere-plugin.zip

 

あわせて、ハッシュ値のファイル(sha256sum.txt)をダウンロードします。

gowatana [ ~ ]$ curl -k -L -O https://192.168.70.33/wcp/plugin/linux-amd64/sha256sum.txt

 

2つのファイルをダウンロードしたら、SHA256 のハッシュ値でファイルに問題がなそうか確認しておきます。

  • Photon OS 3.0 では、「Kubernetes CLI Tools」ページとは少し手順が異なり、
    冒頭での photon-checksum-generator のインストールが必要です。
  • とりあえず実行してみるだけであれば、ハッシュ値確認は省略しても大丈夫です。

gowatana [ ~ ]$ ls

sha256sum.txt  vsphere-plugin.zip

gowatana [ ~ ]$ tdnf install -y photon-checksum-generator

gowatana [ ~ ]$ sha256sum --check sha256sum.txt < vsphere-plugin.zip

vsphere-plugin.zip: OK

 

zunzip でファイルを解凍すると、中に kubectl が入っています。

gowatana [ ~ ]$ unzip vsphere-plugin.zip

Archive:  vsphere-plugin.zip

   creating: bin/

  inflating: bin/kubectl-vsphere

  inflating: bin/kubectl

 

kubectl に PATH を通しておきます。

gowatana [ ~ ]$ export PATH=$(pwd)/bin:$PATH

gowatana [ ~ ]$ which kubectl

/home/gowatana/bin/kubectl

 

今回の kubectl のバージョンです。

gowatana [ ~ ]$ kubectl version --client

Client Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.4-2+a00aae1e6a4a69", GitCommit:"a00aae1e6a4a698595445ec86aab1502a495c1ce", GitTreeState:"clean", BuildDate:"2020-04-22T11:35:29Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

 

kubectl で Bash の Tab キー補完を利用するためのコマンドラインを実行しておきます。

gowatana [ ~ ]$ source <(kubectl completion bash)

 

ちなみに、Photon OS ではなく RHEL / CentOS などを利用する場合、

この Bash 補完機能を利用するためには、bash-completion のインストールと再ログインが必要だったりします。

[root@centos7 ~]# yum install -y bash-completion

 

ダウンロードした kubectl には、一般的な kubectl にはない「kubectl vsphere ~」といったコマンドがあります。

gowatana [ ~ ]$ kubectl vsphere --help

vSphere Plugin for kubectl.

 

Usage:

  kubectl-vsphere [command]

 

Available Commands:

  help        Help about any command

  login       Authenticate user with vCenter Namespaces

  logout      Destroys current sessions with all vCenter Namespaces clusters.

  version     Prints the version of the plugin.

 

Flags:

  -h, --help                     help for kubectl-vsphere

      --request-timeout string   Request timeout for HTTP client.

  -v, --verbose int              Print verbose logging information.

 

Use "kubectl-vsphere [command] --help" for more information about a command.

 

「kubectl vsphere login」で、Supervisor Control VM のアドレス宛にログインします。

gowatana [ ~ ]$ kubectl vsphere login --help

Authenticate user with vCenter Namespaces:

To access Kubernetes, you must first authenticate against vCenter Namespaces.

You must pass the address of the vCenter Namspaces server and the username of

the user to authenticate, and will be prompted to provide further credentials.

 

Usage:

  kubectl-vsphere login [flags]

 

Examples:

kubectl vsphere login --vsphere-username user@domain --server=https://10.0.1.10

 

https://10.0.1.10/Flags:

  -h, --help                                        help for login

      --insecure-skip-tls-verify                    Skip certificate verification (this is insecure).

      --server string                               Address of the server to authenticate against.

      --tanzu-kubernetes-cluster-name string        Name of the Tanzu Kubernetes cluster to login to.

      --tanzu-kubernetes-cluster-namespace string   Namespace in which the Tanzu Kubernetes cluster resides.

  -u, --vsphere-username string                     Username to authenticate.

 

Global Flags:

      --request-timeout string   Request timeout for HTTP client.

  -v, --verbose int              Print verbose logging information.

 

今回は、vCenter の名前空間で特にアクセス権限を付与していないので、

デフォルトでアクセス可能になっている administrator@vsphere.local ユーザでログインします。

接続先は、vCenter ではなく、Supervisor Control VM にアクセスできる VIP アドレス「192.168.70.33」です。さきほどの 「Kubernetes CLI Tools」ページと同じアドレスになるはずです。

証明書エラーを回避するため、「--insecure-skip-tls-verify」を指定しています。

gowatana [ ~ ]$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33

 

Username: administrator@vsphere.local

Password: ★パスワード入力

Logged in successfully.

 

You have access to the following contexts:

   192.168.70.33

   lab-ns-01

   lab-ns-02

 

If the context you wish to use is not in this list, you may need to try

logging in again later, or contact your cluster administrator.

 

To change context, use `kubectl config use-context <workload name>`

 

利用可能な Context が表示されるので、

名前空間「lab-ns-01」にアクセスできる、同名のコンテキストに切り替えます。

gowatana [ ~ ]$ kubectl config use-context lab-ns-01

Switched to context "lab-ns-01".

 

Pod の起動確認。(kubectl run)

まずは、kubectl コマンドで CentOS 7 のコンテナを Kubernetes の Pod として起動してみます。

下記のようなオプション指定で、まずは コンテナが起動できることだけ確認します。

  • コンテナ イメージは centos:7 を Docker Hubからダウンロードしています。
  • 「-it」 オプションで起動したコンテナにそのまま接続しています。
  • 「--rm」オプションで、コンテナから抜けた(exit した)際に、Pod を削除します。

 

コンテナを起動し、そのまま接続して、CentOS であることを確認してみました。

gowatana [ ~ ]$ kubectl run -it --image=centos:7 --generator=run-pod/v1 --rm centos

If you don't see a command prompt, try pressing enter.

[root@centos /]# ★ここからコンテナの中。

[root@centos /]#

[root@centos /]# cat /etc/centos-release

CentOS Linux release 7.8.2003 (Core)

 

この状態で vSphere Client から名前空間「lab-ns-01」を確認すると、

「centos」という名前のコンテナを含む Pod が作成、起動されています。

wcp-11-05.png

 

exit で抜けると、「--rm」オプションにより自動的にコンテナは削除されます。

[root@centos /]# exit

exit

Session ended, resume using 'kubectl attach centos -c centos -i -t' command when the pod is running

pod "centos" deleted

gowatana [ ~ ]$

 

vSphere Client でも、Pod が削除される様子が確認できます。

ちなみに、タスク名が「仮想マシンの削除」なのは、vSphere Pod では Pod が仮想マシンとして起動されているためです。

wcp-11-07.png

 

Pod の起動確認。(kubectl apply)

Kubernetes へのコンテナの展開は、実際には YAML ファイルを利用するのが一般的です。

そこで、YAML ファイルを用意して Pod を起動してみます。

 

下記のような nginx-pod.yml ファイルを用意します。

nginx イメージによる nginx-container コンテナ 1つを含む、nginx-pod という Pod を作成します。

---

kind: Pod

apiVersion: v1

metadata:

  name: nginx-pod

  labels:

    app: wcp-demo

spec:

  containers:

  - image: nginx

    name: nginx-container

 

nginx-pod.yml  ファイルは、たとえば vi などのテキスト エディタで作成・・・

gowatana [ ~ ]$ vi nginx-pod.yml

 

もしくは下記のように ファイルを作成します。

gowatana [ ~ ]$ cat << EOF > nginx-pod.yml

> ---

> kind: Pod

> apiVersion: v1

> metadata:

>   name: nginx-pod

>   labels:

>     app: wcp-demo

> spec:

>   containers:

>   - image: nginx

>     name: nginx-container

> EOF

gowatana [ ~ ]$ cat ./nginx-pod.yml

---

kind: Pod

apiVersion: v1

metadata:

  name: nginx-pod

  labels:

    app: wcp-demo

spec:

  containers:

  - image: nginx

    name: nginx-container

 

kubectl apply コマンドで YAML ファイルを指定して、Pod を起動してみます。

gowatana [ ~ ]$ kubectl apply -f nginx-pod.yml

pod/nginx-pod created

 

Pod の起動が、kubectl で確認できます。

gowatana [ ~ ]$ kubectl get pods

NAME        READY   STATUS    RESTARTS   AGE

nginx-pod   1/1     Running   0          40s

 

vSphere Client でも、Pod が起動された様子が確認できます。

 

ちなみに、今回はただ Pod を起動しただけなので、Nginx に Web アクセスするには別途手順が必要です。

vSphere with Kubernetes の機能は NSX-T を前提としており、kubectl での操作に合わせて、

NSX によるネットワークが自動的に設定変更されます。(これについては別途・・・)

wcp-11-08.png

 

kubectl delete コマンドで Pod を削除すると、

vSphere Client でも Pod が削除された様子がわかるはずです。

gowatana [ ~ ]$ kubectl delete pod -f nginx-pod.yml

pod "nginx-pod" deleted

 

このように、vSphere with Kubernetes のでの Kubernetes ワークロードの操作については、

vSphere Client ではなく、基本的に kubectl を利用します。

 

以上、Supervisor Cluster に kubectl でアクセスして Pod を起動してみる話でした。

 

次は・・・

vSphere with Kubernetes ラボ環境構築。Part-12: Supervisor Namespace での Tanzu Kubernetes Cluster 準備編