Admittedly, its extremely frustrating when you've synchronized several attributes from Active Directory (or another source) into Workspace ONE Access and the Admin Console only shows a bare minimum of attributes.

So how do I see all my attributes?  Unfortunately the answer typically requires the use of Postman.  I'm going to show you a quick little trick to see all your attributes without using Postman.

Step 1: Search for your User

In the top right corner of the admin console, you will see a search box. Enter the your username here and hit enter:

Note: This procedure requires you to search for the user as opposed to going to User & Groups and selecting a user.

In the search results, select your user:

Step 2: Copy/Edit your URL

Take a look at the URL, it should look something like this (including a Path variable):

Replace "/admin/userGroups?path=/users/" with "/jersey/manager/api/scim/Users/"

Now your URL should like something like this:

Click Enter

Step 3: View your Results

You should see a result set that contains all your attribute data:

Step 4: Format your Results (Optional)

This step is completely optional and makes your response easier to read.  I like to use Notepad++ with the JSON Viewer Plugin.

I'm currently using this JSON Viewer

A JSON viewer plugin for notepad++. Displays the selected JSON string in a tree view.

Author: Kapil Ratnani

Homepage: https://github.com/kapilratnani/JSON-Viewer

Paste your response into Notepad++.

From the plugins menu - Click JSON Viewer -> Format JSON

You should now see your results in an easier to read format:

今回は、Cluster API で、vSphere 環境に Kubernetes クラスタを作成してみます。

Cluster API については、下記のあたりが参考になります。

The Cluster API Book

https://cluster-api.sigs.k8s.io/

Kubenetes でアプリケーションを稼働させるときには、Kubernetes ならではの API を利用することになり、

たとえば、コンテナを YAML 形式のデータで宣言的に展開したりします。

さらに Cluster API という、Kuberentes のプラットフォームに乗るものだけでなく

Kubernetes クラスタ自体も、Kubernetes スタイルの API で管理するというプロジェクトがあります。

Cluster API では、Kubernetes クラスタを作成する前段の、ノード（になる VM）の作成からカバー範囲となるので、

そのノードが稼働するインフラむけに、様々な Provider が用意されています。

ここでの「インフラ」とは、AWS、Azure、GCP、vSphere などです。

そして、vSphere にも、Cluster API の Provider として

「Kubernetes Cluster API Provider vSphere」（CAPV）が存在しています。

GitHub - kubernetes-sigs/cluster-api-provider-vsphere

この機能は、vSphere 7 の環境で Kubernetes を活用する場合にも、製品の一部として利用されます。

今回は、Cluster API を利用して、vSphere 7.0 の vCenter / ESXi / vSAN 環境に Kubernetes クラスタを作成します。

ただし、技術要素の勉強ということで、VMware の製品に組み込まれたものではなく

あえて素の vSphere と Cluster API を利用してみます。

Getting Started を参考に進めていきます。

https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/master/docs/getting_started.md

1. 環境。

Cluster API は、比較的 API や利用方法が割と変更されるものです。

今回は下記のバージョンのソフトウェアを利用しています。

• vSphere： vCenter 7.0 / ESXi 7.0 （あと vSAN 7.0）
• Cluster API： v1alpha3
  • clusterctl（Cluster API の CLI）： v0.3.3
  • cluster-api-provider-vsphere（CAPV）： v0.6.3
• kind（Kubernetes in Docker）： v0.6.1
• Kubernetes： v1.17.3
• antrea： v0.5.1

また、せっかくなので、できるだけ VMware Photon OS を利用してみます。

2. 事前準備。

まず、vSphere 環境を用意しておきます。

ただし今回は、vCenter / ESXi まわりのセットアップ手順については省略します。

vCenter Server Appliance のデプロイ、ESXi のインストール、vSphere クラスタは作成ずみです。

3ノードの vSAN クラスタです。

photon-01 という VM だけ（この後の手順で作成する）だけが起動してる状態です。

2-1. vSphere クラスタ / vCenter インベントリの準備。

vSphere 環境には下記のオブジェクトを作成ずみです。

• データセンタ： lab-dc-02
• vSphere クラスタ： vSAN-Cluster-02 （vSAN & DRS 有効化）
• 共有データストア： vSAN を構成ずみ
• ポートグループ： pg-vlan-0004

Cluster API で作成したクラスタがわかりやすいように、

VM フォルダと、リソースプールを作成してあります。

• VM フォルダ：
  • VM テンプレートの配置： template-01
  • Kubernetes ノード VM の配置： capi-01
• リソースプール： rp-capi-01

また、上記とは別に下記の準備もしてあります。

• インターネット接続
• DHCP サーバ： ポートグループ「pg-vlan-0004」に接続した VM がインターネット接続可能にしてある）
• DNS サーバ： vCenter や、ゲスト OS の名前解決で利用。vCenter の FQDN も登録してある。
• NTP サーバ

2-2. OVA のデプロイ。

Cluster API が自動的にクローンする OVA をデプロイしておきます。

今回は、ほかの VM / VM テンプレートと区別するため VM フォルダ「template-01」を作成して、そこにデプロイします。

.ova ファイルは、下記サイトからダウンロードできます。

GitHub - kubernetes-sigs/cluster-api-provider-vsphere

デプロイする .ova ファイルは 2つです。

• capv-haproxy-v0.6.3.ova
  • HAProxy。VM 名は「capv-haproxy-v0.6.3」としてデプロイ。
• photon-3-kube-v1.17.3.ova
  • Kubernetes ノードになる。VM 名は「photon-3-kube-v1.17.3」としてデプロイ。

cluster-api-provider-vsphere（CAPV）では、リンククローンが利用できます。

そのため、デプロイした OVA で、それぞれ下記を実施しておきます。

1. VM スナップショットを取得
2. VM テンプレートに変換

3. clusterctl 実行環境の準備。

Cluster API を操作する環境を Photon OS で用意します。

Cluster API の CLI「clusterctl」と、その前提となる Docker、kind、kubectl をインストールしたマシンを用意します。

clusterctl を実行するマシンは、これから Kuberentes クラスタを作成する vSphere の内部でも、

外部でもどちらでも構いません。（物理マシンのサーバや、ノート PC でも構いません）

Photon OS 3.0 の OVA をデプロイします。

OVA ファイルは「photon-hw13_uefi-3.0-9355405.ova」を利用します。

ちなみに、root の初期パスワードは changeme です。

http://dl.bintray.com/vmware/photon/3.0/Rev2/ova/photon-hw13_uefi-3.0-9355405.ova

OVA をデプロイ、起動したら、ネットワーク、DNS サーバ、ホスト名などの設定を済ませておきます。

今回は、photon-01 というホスト名にしています。

ここから先のコマンドラインでの手順は、すべてこの photon-01 から実施します。

Docker は、Photon OS の OVA にデフォルトでインストールされています。

docker などの RPM パッケージを、アップデートしておきます。

root@photon-01 [ ~ ]# tdnf update -y

root@photon-01 [ ~ ]# rpm -q docker

docker-18.09.9-1.ph3.x86_64

Docker のサービスを起動しておきます。

root@photon-01 [ ~ ]# systemctl start docker

root@photon-01 [ ~ ]# systemctl enable docker

この先の手順で利用する RPM （jq、diff コマンドなど）を追加インストールしておきます。

root@photon-01 [ ~ ]# tdnf install -y jq diffutils

OS を再起動しておきます。

root@photon-01 [ ~ ]# reboot

Photon OS 3.0 のホストで、docker が起動された状態です。

root@photon-01 [ ~ ]# systemctl is-active docker

active

root@photon-01 [ ~ ]# cat /etc/photon-release

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=11dd065

kubectl をインストールします。

kubectl のバージョンは、Cluster API で作成するつもりの Kuberentes バージョンに合わせています。

root@photon-01 [ ~ ]# curl -L -o /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v1.17.3/bin/linux/amd64/kubectl

root@photon-01 [ ~ ]# chmod +x /usr/local/bin/kubectl

root@photon-01 [ ~ ]# kubectl version --client

Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213", GitTreeState:"clean", BuildDate:"2020-02-11T18:14:22Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"}

kind をインストールします。

root@photon-01 [ ~ ]# curl -L -o /usr/local/bin/kind https://github.com/kubernetes-sigs/kind/releases/download/v0.6.1/kind-linux-amd64

root@photon-01 [ ~ ]# chmod +x /usr/local/bin/kind

root@photon-01 [ ~ ]# kind version

kind v0.6.1 go1.13.4 linux/amd64

clusterctl をインストールします。

今回は、v0.3.3 を利用しています。

Release v0.3.3 · kubernetes-sigs/cluster-api · GitHub

root@photon-01 [ ~ ]# curl -L -o /usr/local/bin/clusterctl https://github.com/kubernetes-sigs/cluster-api/releases/download/v0.3.3/clusterctl-linux-amd64

root@photon-01 [ ~ ]# chmod +x /usr/local/bin/clusterctl

root@photon-01 [ ~ ]# clusterctl version

clusterctl version: &version.Info{Major:"0", Minor:"3", GitVersion:"v0.3.3", GitCommit:"ecff70af1b839c4086335234d88b1b8c00c3383c", GitTreeState:"clean", BuildDate:"2020-03-27T22:25:19Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}

4. kind での管理クラスタ作成。

Cluster API では、Cluster API で Kuberentes クラスタを管理する「管理クラスタ」を用意して、

そこから、アプリケーションを実行するための「Workload クラスタ」を作成 / 管理します。

まずは「管理クラスタ」を作成します。

4-1 kind クラスタの作成。

kind で、Cluster API での処理の起点になる Kuberentes クラスタを作成します。

これは、kind コマンドを実行したマシンに作成される Docker コンテナによる 1 ノードの Kuberentes クラスタです。

[root@lab-kind-01 ~]# kind create cluster

「kind」という名前の、1ノードの Kuberentes クラスタが作成されました。

kubernetes に接続する kubeconfig は、kind で生成された $HOME/.kube/config が利用されています。

このクラスタは kind のバージョンにあわせて Kuberentes  v1.16.3 です。

（このあと Cluster API で作成する Kuberentes は別のバージョンにします）

[root@lab-kind-01 ~]# kind get clusters

kind

root@photon-01 [ ~ ]# kubectl get nodes

NAME                 STATUS   ROLES    AGE     VERSION

kind-control-plane   Ready    master   2m14s   v1.16.3

この時点で kind クラスタで起動されている Pod を確認しておきます。

root@photon-01 [ ~ ]# kubectl get pods -A

NAMESPACE     NAME                                         READY   STATUS    RESTARTS   AGE

kube-system   coredns-5644d7b6d9-59p6t                     1/1     Running   0          2m33s

kube-system   coredns-5644d7b6d9-qxscv                     1/1     Running   0          2m33s

kube-system   etcd-kind-control-plane                      1/1     Running   0          2m17s

kube-system   kindnet-h6xr6                                1/1     Running   1          2m33s

kube-system   kube-apiserver-kind-control-plane            1/1     Running   2          2m16s

kube-system   kube-controller-manager-kind-control-plane   1/1     Running   1          2m25s

kube-system   kube-proxy-4t6nm                             1/1     Running   0          2m33s

kube-system   kube-scheduler-kind-control-plane            1/1     Running   3          2m53s

4-2. CAPV むけの準備。

Kubernetes Cluster API Provider vSphere（CAPV）の利用にむけた準備をします。

CAPV でクローンされる VM に自動配置される SSH 鍵を作成します。

今回のマシンは、CAPV 専用に用意しているので、デフォルトのパスにファイルを作成しています。

root@photon-01 [ ~ ]# echo y | ssh-keygen -t rsa -f $HOME/.ssh/id_rsa -P ''

ホームディレクトリ直下に、.cluster-api ディレクトリを作成します。

root@photon-01 [ ~ ]# mkdir $HOME/.cluster-api

ラボ環境の vSphere にあわせた

cat << EOF > $HOME/.cluster-api/clusterctl.yaml

# Controller settings

VSPHERE_USERNAME: "administrator@vsphere.local"

VSPHERE_PASSWORD: "VMware1!"

 

# Required workload cluster default settings

VSPHERE_SERVER: "lab-vc-02.go-lab.jp"

VSPHERE_DATACENTER: "lab-dc-02"

VSPHERE_DATASTORE: "vsanDatastore-702"

VSPHERE_NETWORK: "pg-vlan-0004"

VSPHERE_RESOURCE_POOL: "vSAN-Cluster-702/Resources/rp-capi-01"

VSPHERE_FOLDER: "vm/capi-01"

VSPHERE_TEMPLATE: "photon-3-kube-v1.17.3"

VSPHERE_HAPROXY_TEMPLATE: "capv-haproxy-v0.6.3"

VSPHERE_SSH_AUTHORIZED_KEY: XXX

EOF

前の手順で作成した SSH 公開鍵のファイル（id_rsa.pub）の内容を、clusterctl.yaml の VSPHERE_SSH_AUTHORIZED_KEY に記載します。

sed コマンドを利用していますが、vi などエディタでの編集で大丈夫です。

root@photon-01 [ ~ ]# cp $HOME/.cluster-api/clusterctl.yaml $HOME/clusterctl.yaml_orig

root@photon-01 [ ~ ]# sed -i "s|VSPHERE_SSH_AUTHORIZED_KEY:.*|VSPHERE_SSH_AUTHORIZED_KEY\:\ \"$(cat $HOME/.ssh/id_rsa.pub)\"|" $HOME/.cluster-api/clusterctl.yaml

root@photon-01 [ ~ ]# diff $HOME/clusterctl.yaml_orig$HOME/.cluster-api/clusterctl.yaml

14c14

< VSPHERE_SSH_AUTHORIZED_KEY: XXX

---

> VSPHERE_SSH_AUTHORIZED_KEY: "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDG/NQQ3WH+Wy0UJrfL5ztSIqSYhdxkzHhxfaLnUGPgYMD3uIGQU0A4+3vTDUZF563iWlS99bOTaARyJs1BJEPHfoSrrtpMXXXXXXXXXXXXXXXXXXXXXXXY3Gy17Jxu2CC5v root@photon-01"

4-3. kind クラスタの clusterctl init。

clusterctl init で、kind クラスタで Cluster API を利用する準備をします。

vSphere むけの Cluster API Provider を利用するので、「--infrastructure vsphere」を指定しています。

root@photon-01 [ ~ ]# clusterctl init --infrastructure vsphere

Fetching providers

Installing cert-manager

Waiting for cert-manager to be available...

Installing Provider="cluster-api" Version="v0.3.4" TargetNamespace="capi-system"

Installing Provider="bootstrap-kubeadm" Version="v0.3.4" TargetNamespace="capi-kubeadm-bootstrap-system"

Installing Provider="control-plane-kubeadm" Version="v0.3.4" TargetNamespace="capi-kubeadm-control-plane-system"

Installing Provider="infrastructure-vsphere" Version="v0.6.3" TargetNamespace="capv-system"

 

Your management cluster has been initialized successfully!

 

You can now create your first workload cluster by running the following:

 

  clusterctl config cluster [name] --kubernetes-version [version] | kubectl apply -f -

 

kind クラスタに Cluster API で利用される Pod が追加起動され、

管理クラスタとして準備された様子がわかります。

root@photon-01 [ ~ ]# kubectl get pods -A

NAMESPACE                           NAME                                                             READY   STATUS    RESTARTS   AGE

capi-kubeadm-bootstrap-system       capi-kubeadm-bootstrap-controller-manager-fd9f9c8f7-n66q9        2/2     Running   1          3m25s

capi-kubeadm-control-plane-system   capi-kubeadm-control-plane-controller-manager-f7c75497-2vbt7     2/2     Running   0          2m49s

capi-system                         capi-controller-manager-5d7b4cf8f6-4dlvd                         2/2     Running   1          3m56s

capi-webhook-system                 capi-controller-manager-7d7f5888cf-6fq4t                         2/2     Running   0          4m5s

capi-webhook-system                 capi-kubeadm-bootstrap-controller-manager-679cb64b54-dv2t2       2/2     Running   0          3m43s

capi-webhook-system                 capi-kubeadm-control-plane-controller-manager-788d79c866-rv44l   2/2     Running   0          3m12s

capi-webhook-system                 capv-controller-manager-6bbbc59845-2pptf                         2/2     Running   0          92s

capv-system                         capv-controller-manager-5c8648757b-gr2fx                         2/2     Running   0          91s

cert-manager                        cert-manager-69b4f77ffc-vx2mq                                    1/1     Running   0          13m

cert-manager                        cert-manager-cainjector-576978ffc8-nkhqd                         1/1     Running   1          13m

cert-manager                        cert-manager-webhook-c67fbc858-22zrb                             1/1     Running   0          13m

kube-system                         coredns-5644d7b6d9-59p6t                                         1/1     Running   0          20m

kube-system                         coredns-5644d7b6d9-qxscv                                         1/1     Running   0          20m

kube-system                         etcd-kind-control-plane                                          1/1     Running   0          20m

kube-system                         kindnet-h6xr6                                                    1/1     Running   1          20m

kube-system                         kube-apiserver-kind-control-plane                                1/1     Running   2          20m

kube-system                         kube-controller-manager-kind-control-plane                       1/1     Running   2          20m

kube-system                         kube-proxy-4t6nm                                                 1/1     Running   0          20m

kube-system                         kube-scheduler-kind-control-plane                                1/1     Running   4          20m

幅が広くて見にくいので、一応スクリーンショットも・・・

5. Workload クラスタの作成。

ここからは、管理クラスタから Workload クラスタを作成します。

5-1. Workload クラスタの YAML 作成。

まず、clusterctl config cluster コマンドで、Workload クラスタの作成で使用する YAML ファイル（cluster.yaml）を作成します。

今回は下記のように指定しています。

Kuberentes のバージョンは、Github からダウンロードできる .ova のバージョンに合わせておきました。

• 作成する Workload クラスタの名前： capvdemo
• Kuberentes のバージョン： v1.17.3
• control-plane のノード数： 1
• Worker ノード数： 3

root@photon-01 [ ~ ]# clusterctl config cluster capvdemo --infrastructure vsphere --kubernetes-version v1.17.3 --control-plane-machine-count 1 --worker-machine-count 3 > ./cluster.yaml

cluster.yaml を、ラボ環境にあわせて編集します。

• Pod のネットワークアドレス（cidrBlocks）のデフォルト 192.168.0.0/16 が、既存ネットワークと重複してしまうので、別のレンジに変更。
  ラボにもとからある別の Kuberentes クラスタに合わせた。
• クローンされる VM（HAProxy と Kuberentes ノードの両方）のメモリサイズを 8192 → 4096 に変更。

cluster.yaml の一部より。

Cluster API v1alpha3 が利用されていることもわかります。

root@photon-01 [ ~ ]# head cluster.yaml

apiVersion: cluster.x-k8s.io/v1alpha3

kind: Cluster

metadata:

  name: capvdemo

  namespace: default

spec:

  clusterNetwork:

    pods:

      cidrBlocks:

      - 192.168.0.0/16 ★このあたりを編集

今回の編集は最小限にしました。

root@photon-01 [ ~ ]# cp ./cluster.yaml  ./cluster.yaml_orig

root@photon-01 [ ~ ]# vi cluster.yaml

root@photon-01 [ ~ ]# diff ./cluster.yaml_orig ./cluster.yaml

10c10

<       - 192.168.0.0/16

---

>       - 100.96.0.0/11

39c39

<     memoryMiB: 8192

---

>     memoryMiB: 4096

101c101

<       memoryMiB: 8192

---

>       memoryMiB: 4096

作成した cluster.yaml ファイルで、Workload クラスタを作成します。

ここからは clusterctl ではなく、kubectl を利用します。

また、kukbernetes に接続する kubeconfig は特に指定していませんが、

kind で自動生成される $HOME/.kube/config ファイルが使用されています。

root@photon-01 [ ~ ]# kubectl apply -f cluster.yaml

cluster.cluster.x-k8s.io/capvdemo created

haproxyloadbalancer.infrastructure.cluster.x-k8s.io/capvdemo created

vspherecluster.infrastructure.cluster.x-k8s.io/capvdemo created

vspheremachinetemplate.infrastructure.cluster.x-k8s.io/capvdemo created

kubeadmcontrolplane.controlplane.cluster.x-k8s.io/capvdemo created

kubeadmconfigtemplate.bootstrap.cluster.x-k8s.io/capvdemo-md-0 created

machinedeployment.cluster.x-k8s.io/capvdemo-md-0 created

Cluster API ならではの Cluster  リソース が作成され、Povisioned になります。

root@photon-01 [ ~ ]# kubectl get cluster

NAME       PHASE

capvdemo   Provisioned

vSphere Client を見ていると、YAML ファイルで指定したリソースプール / VM フォルダに、VM のクローンが開始されます。

ちなみに、cluster.yaml で指定した vSphere まわりのパラメータが間違ったり、

ノードのリソースが不足してたりすると、処理が失敗したりします。

この場合、下記のように capv-system ネームスペースの Pod（というかコンテナ）あたりのログを確認してみるとよいかなと思います。

（例は capv-controller-manager-XXXX Pod の manager コンテナのログ確認）

root@photon-01 [ ~ ]# kubectl -n capv-system logs capv-controller-manager-XXXX manager

今回のクラスタ作成では、3種類の VM が起動されます。

• HAProxy（～-lb 1台）
• Control Plane（capvdemo-～ 1台）
• ワーカー ノード（capvdemo-md-0-～ が 3台）

Kuberentes ノードが vSphere の VM として作成される様子も確認できます。

PHASE がすべて Running になったら完了です。

root@photon-01 [ ~ ]# kubectl get machine

NAME                            PROVIDERID                                       PHASE

capvdemo-md-0-c66cff7d6-2954x   vsphere://4229867c-d72f-219a-a205-0bfa5a776b56   Running

capvdemo-md-0-c66cff7d6-jskwv   vsphere://422936dc-4bed-f2b4-5cc3-115e0a822b74   Running

capvdemo-md-0-c66cff7d6-rc6c7   vsphere://42293c95-01ea-07a9-9641-e1c924deecd9   Running

capvdemo-rphzb                  vsphere://422914fa-594b-c1d4-3f01-ff3875223ddf   Running

Kuberentes のワーカー ノードは、MachineDeployment（略称は md）というリソースで管理されています。

root@photon-01 [ ~ ]# kubectl get machinedeployment

NAME            PHASE     REPLICAS   AVAILABLE   READY

capvdemo-md-0   Running   3          3           3

5-2. Workload クラスタへの接続。

Workload クラスタに接続するには、kind クラスタの Secret リソース「クラスタ名-kubeconfig」 の情報をもとに、kubeconfig を作成します。

root@photon-01 [ ~ ]# kubectl get secret capvdemo-kubeconfig -o json | jq -r .data.value | base64 --decode > $HOME/kubeconfig_capvdemo

作成した kubeconfig で、Workload クラスタに接続できます。

root@photon-01 [ ~ ]# kubectl --kubeconfig=$HOME/kubeconfig_capvdemo get nodes

NAME                            STATUS     ROLES    AGE     VERSION

capvdemo-md-0-c66cff7d6-2954x   NotReady   <none>   8m31s   v1.17.3

capvdemo-md-0-c66cff7d6-jskwv   NotReady   <none>   8m39s   v1.17.3

capvdemo-md-0-c66cff7d6-rc6c7   NotReady   <none>   6m39s   v1.17.3

capvdemo-rphzb                  NotReady   master   16m     v1.17.3

ここからは、作成した kubeconfig を環境変数 KUBECONFIG で指定して、

kubectl ではデフォルトで Workload クラスタに接続します。

root@photon-01 [ ~ ]# export KUBECONFIG=$HOME/kubeconfig_capvdemo

root@photon-01 [ ~ ]# kubectl get nodes

NAME                            STATUS     ROLES    AGE     VERSION

capvdemo-md-0-c66cff7d6-2954x   NotReady   <none>   10m     v1.17.3

capvdemo-md-0-c66cff7d6-jskwv   NotReady   <none>   10m     v1.17.3

capvdemo-md-0-c66cff7d6-rc6c7   NotReady   <none>   8m32s   v1.17.3

capvdemo-rphzb                  NotReady   master   18m     v1.17.3

しばらく待つと、Workload クラスタでは下記のように Pod が起動されます。

この時点では、まだ Pod のネットワーク Add-on が起動されていないので、

まだノードが NotReady、いくつかの Pod が Pending 状態です。

root@photon-01 [ ~ ]# kubectl get pods -A

NAMESPACE     NAME                                     READY   STATUS    RESTARTS   AGE

kube-system   coredns-6955765f44-ncrg8                 0/1     Pending   0          19m

kube-system   coredns-6955765f44-vtvc7                 0/1     Pending   0          19m

kube-system   etcd-capvdemo-rphzb                      1/1     Running   0          19m

kube-system   kube-apiserver-capvdemo-rphzb            1/1     Running   0          19m

kube-system   kube-controller-manager-capvdemo-rphzb   1/1     Running   3          19m

kube-system   kube-proxy-f8j94                         1/1     Running   0          11m

kube-system   kube-proxy-pz66s                         1/1     Running   0          11m

kube-system   kube-proxy-rfgz5                         1/1     Running   0          9m38s

kube-system   kube-proxy-xx9j8                         1/1     Running   0          19m

kube-system   kube-scheduler-capvdemo-rphzb            1/1     Running   4          19m

kube-system   vsphere-cloud-controller-manager-mqp5r   1/1     Running   2          19m

kube-system   vsphere-csi-controller-0                 0/5     Pending   0          19m

ちなみに、ここまでの時点で、下記のように Workload クラスタに接続できなくなることがあります。

しばらく待っても復旧しない場合は、HAProxy や master ノードの VM を手動再起動してみると、手早く復旧できたりします。

root@photon-01 [ ~ ]# kubectl --kubeconfig=./kubeconfig_capvdemo get pods -A

Unable to connect to the server: EOF

5-3. Pod Network Add-on インストール。（antrea）

CAPV の Github での Getting-Start では calico を利用していますが、

今回は、せっかくなので antrea をインストールしてみます。

antrea v0.5.1 を指定してインストールしています。

root@photon-01 [ ~ ]# kubectl apply -f https://github.com/vmware-tanzu/antrea/releases/download/v0.5.1/antrea.yml

customresourcedefinition.apiextensions.k8s.io/antreaagentinfos.clusterinformation.antrea.tanzu.vmware.com created

customresourcedefinition.apiextensions.k8s.io/antreacontrollerinfos.clusterinformation.antrea.tanzu.vmware.com created

serviceaccount/antctl created

serviceaccount/antrea-agent created

serviceaccount/antrea-controller created

clusterrole.rbac.authorization.k8s.io/antctl created

clusterrole.rbac.authorization.k8s.io/antrea-agent created

clusterrole.rbac.authorization.k8s.io/antrea-controller created

rolebinding.rbac.authorization.k8s.io/antrea-controller-authentication-reader created

clusterrolebinding.rbac.authorization.k8s.io/antctl created

clusterrolebinding.rbac.authorization.k8s.io/antrea-agent created

clusterrolebinding.rbac.authorization.k8s.io/antrea-controller created

configmap/antrea-config-b2b5bdkh8t created

service/antrea created

deployment.apps/antrea-controller created

apiservice.apiregistration.k8s.io/v1beta1.networking.antrea.tanzu.vmware.com created

apiservice.apiregistration.k8s.io/v1beta1.system.antrea.tanzu.vmware.com created

daemonset.apps/antrea-agent created

少し待つと、kube-system ネームスペースで、antrea 関連の Pod が起動されます。

ちなみに、CAPV の Workload クラスタでは、vSAN でおなじみのクラウド ネイティブ ストレージが

デフォルトで利用可能になっていて、vsphere-csi-～ という Pod も起動されます。

root@photon-01 [ ~ ]# kubectl get pods -A

NAMESPACE     NAME                                     READY   STATUS    RESTARTS   AGE

kube-system   antrea-agent-4wcnm                       2/2     Running   3          30m

kube-system   antrea-agent-57br8                       2/2     Running   0          30m

kube-system   antrea-agent-npgpm                       2/2     Running   0          30m

kube-system   antrea-agent-zf64r                       2/2     Running   0          30m

kube-system   antrea-controller-5fff85b9b4-c74gg       1/1     Running   0          31m

kube-system   coredns-6955765f44-ncrg8                 1/1     Running   0          54m

kube-system   coredns-6955765f44-vtvc7                 1/1     Running   0          54m

kube-system   etcd-capvdemo-rphzb                      1/1     Running   1          54m

kube-system   kube-apiserver-capvdemo-rphzb            1/1     Running   1          54m

kube-system   kube-controller-manager-capvdemo-rphzb   1/1     Running   9          54m

kube-system   kube-proxy-f8j94                         1/1     Running   0          46m

kube-system   kube-proxy-pz66s                         1/1     Running   0          46m

kube-system   kube-proxy-rfgz5                         1/1     Running   0          44m

kube-system   kube-proxy-xx9j8                         1/1     Running   1          54m

kube-system   kube-scheduler-capvdemo-rphzb            1/1     Running   10         54m

kube-system   vsphere-cloud-controller-manager-mqp5r   1/1     Running   8          54m

kube-system   vsphere-csi-controller-0                 5/5     Running   5          54m

kube-system   vsphere-csi-node-9gkxs                   3/3     Running   0          19m

kube-system   vsphere-csi-node-cwb5q                   3/3     Running   6          19m

kube-system   vsphere-csi-node-jzcfb                   3/3     Running   7          19m

kube-system   vsphere-csi-node-qqc2b                   3/3     Running   0          19m

見栄え的に、スクリーンショットも・・・

ちなみに Pod の RESTARTS が多いのは、ラボのリソースが不足しているためかなと思います。

Pod の Network Add-on が起動されたことで、ノードも Ready になりました。

これで、Workload クラスタが利用できる状態になりました。

root@photon-01 [ ~ ]# kubectl get nodes

NAME                            STATUS   ROLES    AGE   VERSION

capvdemo-md-0-c66cff7d6-2954x   Ready    <none>   46m   v1.17.3

capvdemo-md-0-c66cff7d6-jskwv   Ready    <none>   46m   v1.17.3

capvdemo-md-0-c66cff7d6-rc6c7   Ready    <none>   44m   v1.17.3

capvdemo-rphzb                  Ready    master   54m   v1.17.3

慣れると、検証 Kuberentes クラスタを手軽に作成できてよいかなと思います。

以上、Cluster API Provider for vSphere で Kuberentes クラスタを作成してみる話でした。

先日、Kuberentes クラスタを作成する投稿の中で、Pod Network Add-on として Antrea をインストールしてみました。

Cluster API で vSphere 7.0 に Kuberentes クラスタを作成してみる。（Photon OS 3.0 編）

前回の投稿を公開したあとに、ちょうど新しいバージョンの Antrea v0.6.0 がリリースされたので、

ふたたび Antrea のインストールについて投稿しておこうと思います。

あわせて、せっかくなので Octant という Kuberentes 可視化ツールもインストールしてみます。

Kuberentes では、Pod 間のネットワーク通信方式が選択できるようになっていて、

Flannel、Calico、OVN、NSX-T など、さまざまなソリューションによる実装（主に CNI Plug-in）が存在します。

kubeadm のドキュメントだと Pod Network Add-on と表現されてたりもするようです。

https://kubernetes.io/docs/concepts/cluster-administration/networking/

Antrea は、VMware が中心となって開発されているもので、Open vSwitch による CNI Plug-in です。

GitHub - vmware-tanzu/antrea: A Kubernetes networking solution based on Open vSwitch

Antrea については、motonori_shindo さんのブログ投稿がとてもわかりやすいです。

https://blog.shin.do/2020/01/antrea-yet-another-cni-plugin-for-kubernetes/

そして、今回は Antrea と一緒に、Kuberente 環境を見やすくするために、

Octant という Kubernetes 可視化ツールをインストールします。

このツールも、VMware が中心となって開発しているものです。

https://octant.dev/

Antrea のリリース ページには、Antrea の Plug-in を組み込んだ Octant をインストールできる

マニフェスト（YAML 形式の）ファイルも公開されています。

Release Release v0.6.0 · vmware-tanzu/antrea · GitHub

1. 環境準備。

前回の投稿での、「5-3. Pod Network Add-on インストール。（antrea）」の前までの手順をすませて、

Kuberentes クラスタを作成しておきます。

※ただし実際のところ、前回のように antrea v0.5.1 をインストールしていてもバージョンアップできます。

この時点では Network Add-on （というか CNI Plug-in である Antrea）がインストールされていない状態なので、

Kuberentes のノードは、まだ NotReady の状態です。

[root@lab-kind-02 ~]# kubectl --kubeconfig=$HOME/kubeconfig_capvdemo get nodes

NAME                             STATUS     ROLES    AGE   VERSION

capvdemo-9cmld                   NotReady   master   15h   v1.17.3

capvdemo-md-0-5dfbf45b6c-9glg8   NotReady   <none>   15h   v1.17.3

capvdemo-md-0-5dfbf45b6c-c926m   NotReady   <none>   15h   v1.17.3

capvdemo-md-0-5dfbf45b6c-l8s2h   NotReady   <none>   15h   v1.17.3

今回の kubeconfig ファイルは、$HOME/kubeconfig_capvdemo というファイル名です。

ここからは、環境変数 KUBECONFIG に指定して進めます。

[root@lab-kind-02 ~]# export KUBECONFIG=$HOME/kubeconfig_capvdemo

[root@lab-kind-02 ~]# kubectl get nodes

NAME                             STATUS     ROLES    AGE   VERSION

capvdemo-9cmld                   NotReady   master   15h   v1.17.3

capvdemo-md-0-5dfbf45b6c-9glg8   NotReady   <none>   15h   v1.17.3

capvdemo-md-0-5dfbf45b6c-c926m   NotReady   <none>   15h   v1.17.3

capvdemo-md-0-5dfbf45b6c-l8s2h   NotReady   <none>   15h   v1.17.3

まだ Pod の一覧にも、Network Add-on がない状態です。

[root@lab-kind-02 ~]# kubectl get pods -A

NAMESPACE     NAME                                     READY   STATUS    RESTARTS   AGE

kube-system   coredns-6955765f44-4knws                 0/1     Pending   0          15h

kube-system   coredns-6955765f44-wf7vf                 0/1     Pending   0          15h

kube-system   etcd-capvdemo-9cmld                      1/1     Running   0          15h

kube-system   kube-apiserver-capvdemo-9cmld            1/1     Running   0          15h

kube-system   kube-controller-manager-capvdemo-9cmld   1/1     Running   0          15h

kube-system   kube-proxy-747lg                         1/1     Running   0          15h

kube-system   kube-proxy-c8mt6                         1/1     Running   0          15h

kube-system   kube-proxy-qxpnw                         1/1     Running   0          15h

kube-system   kube-proxy-xbgb9                         1/1     Running   0          15h

kube-system   kube-scheduler-capvdemo-9cmld            1/1     Running   0          15h

kube-system   vsphere-cloud-controller-manager-f67z6   1/1     Running   0          15h

kube-system   vsphere-csi-controller-0                 0/5     Pending   0          15h

2. Octant むけ Secret の作成。

Octant をインストールする前に、kubeconfig を含む Secret リソースを作成しておきます。

この Secret は、Octant の Pod が起動される際に読み込まれるもので、

コンテナ内では /kube にマウントされて、/kube/admin.conf として読み込まれます。

そのため --from-file オプションは、あらかじめ admin.conf という名前にした kubeconfig ファイルを指定するか、

「--from-file=admin.conf=＜kubeconfig ファイル名＞」のような指定にしておきます。

[root@lab-kind-02 ~]# kubectl -n kube-system create secret generic octant-kubeconfig --from-file=admin.conf=$HOME/kubeconfig_capvdemo

[root@lab-kind-02 ~]# kubectl -n kube-system get secret octant-kubeconfig

NAME                TYPE     DATA   AGE

octant-kubeconfig   Opaque   1      16s

3. Antrea & Octant のインストール。

それでは、Kuberente クラスタに、Antrea v0.6.0 をインストールします。

[root@lab-kind-02 ~]# kubectl apply -f https://github.com/vmware-tanzu/antrea/releases/download/v0.6.0/antrea.yml

customresourcedefinition.apiextensions.k8s.io/antreaagentinfos.clusterinformation.antrea.tanzu.vmware.com created

customresourcedefinition.apiextensions.k8s.io/antreacontrollerinfos.clusterinformation.antrea.tanzu.vmware.com created

serviceaccount/antctl created

serviceaccount/antrea-agent created

serviceaccount/antrea-controller created

clusterrole.rbac.authorization.k8s.io/antctl created

clusterrole.rbac.authorization.k8s.io/antrea-agent created

clusterrole.rbac.authorization.k8s.io/antrea-controller created

rolebinding.rbac.authorization.k8s.io/antrea-agent-authentication-reader created

rolebinding.rbac.authorization.k8s.io/antrea-controller-authentication-reader created

clusterrolebinding.rbac.authorization.k8s.io/antctl created

clusterrolebinding.rbac.authorization.k8s.io/antrea-agent created

clusterrolebinding.rbac.authorization.k8s.io/antrea-controller created

configmap/antrea-config-m8cb9g82tf created

service/antrea created

deployment.apps/antrea-controller created

apiservice.apiregistration.k8s.io/v1beta1.networking.antrea.tanzu.vmware.com created

apiservice.apiregistration.k8s.io/v1beta1.system.antrea.tanzu.vmware.com created

daemonset.apps/antrea-agent created

つづけて Antrea の Plug-in が組み込まれた Octant の Service と Deployment をインストールします。

URL を見てのとおり、Octant の Github リポジトリではなく、antera のリポジトリで公開されている YAML を指定しています。

[root@lab-kind-02 ~]# kubectl apply -f https://github.com/vmware-tanzu/antrea/releases/download/v0.6.0/antrea-octant.yml

service/antrea-octant created

deployment.apps/antrea-octant created

少し待つと、Network Add-on が起動されたことにより、ノードが Ready になります。

[root@lab-kind-02 ~]# kubectl get nodes

NAME                             STATUS   ROLES    AGE   VERSION

capvdemo-9cmld                   Ready    master   16h   v1.17.3

capvdemo-md-0-5dfbf45b6c-9glg8   Ready    <none>   16h   v1.17.3

capvdemo-md-0-5dfbf45b6c-c926m   Ready    <none>   16h   v1.17.3

capvdemo-md-0-5dfbf45b6c-l8s2h   Ready    <none>   16h   v1.17.3

Pod も、ひととおり Running になるはずです。

antrea-controller、各ノードの antrea-agent、antrea-controller も起動されています。

[root@lab-kind-02 ~]# kubectl -n kube-system get pods

NAME                                     READY   STATUS    RESTARTS   AGE

antrea-agent-7gzsn                       2/2     Running   0          11m

antrea-agent-lbd6b                       2/2     Running   0          11m

antrea-agent-nxbf8                       2/2     Running   0          11m

antrea-agent-wq9xk                       2/2     Running   0          11m

antrea-controller-6c54499dc9-7lw2d       1/1     Running   0          11m

antrea-octant-686d4ffc4-l4trz            1/1     Running   0          10m

coredns-6955765f44-4knws                 1/1     Running   0          16h

coredns-6955765f44-wf7vf                 1/1     Running   0          16h

etcd-capvdemo-9cmld                      1/1     Running   0          16h

kube-apiserver-capvdemo-9cmld            1/1     Running   0          16h

kube-controller-manager-capvdemo-9cmld   1/1     Running   0          16h

kube-proxy-747lg                         1/1     Running   0          16h

kube-proxy-c8mt6                         1/1     Running   0          16h

kube-proxy-qxpnw                         1/1     Running   0          16h

kube-proxy-xbgb9                         1/1     Running   0          16h

kube-scheduler-capvdemo-9cmld            1/1     Running   0          16h

vsphere-cloud-controller-manager-f67z6   1/1     Running   0          16h

vsphere-csi-controller-0                 5/5     Running   0          16h

vsphere-csi-node-5jc9x                   3/3     Running   0          7m10s

vsphere-csi-node-9fsr4                   3/3     Running   0          9m9s

vsphere-csi-node-jrk5l                   3/3     Running   0          9m32s

vsphere-csi-node-s47rh                   3/3     Running   0          8m27s

antrea-controller と、antrea-octant は Deployment リソースとして作成されます。

[root@lab-kind-02 ~]# kubectl -n kube-system get deployment

NAME                READY   UP-TO-DATE   AVAILABLE   AGE

antrea-controller   1/1     1            1           17m

antrea-octant       1/1     1            1           17m

coredns             2/2     2            2           16h

antrea-agent は、各ノードで起動するので DaemonSet リソースとして作成されます。

[root@lab-kind-02 ~]# kubectl -n kube-system get daemonset

NAME                               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE

antrea-agent                       4         4         4       4            4           kubernetes.io/os=linux            19m

kube-proxy                         4         4         4       4            4           beta.kubernetes.io/os=linux       16h

vsphere-cloud-controller-manager   1         1         1       1            1           node-role.kubernetes.io/master=   16h

vsphere-csi-node                   4         4         4       4            4           <none>                            16h

Octant は、Service リソースも作成されて、NodePort でアクセスできるようになっています。

今回は、各 Kuberente ノードの 32128 番ポートでアクセスできます。

[root@lab-kind-02 ~]# kubectl -n kube-system get service antrea-octant

NAME            TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE

antrea-octant   NodePort   10.103.43.222   <none>        80:32128/TCP   21m

今回の Kuberente クラスタでは、10.0.4.162 ～ 10.0.4.165 の 32128 番ポートで Octant にアクセスできるはずです。

[root@lab-kind-02 ~]# kubectl get nodes -o wide

NAME                             STATUS   ROLES    AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                 KERNEL-VERSION   CONTAINER-RUNTIME

capvdemo-9cmld                   Ready    master   16h   v1.17.3   10.0.4.162    10.0.4.162    VMware Photon OS/Linux   4.19.79-2.ph3    containerd://1.3.3

capvdemo-md-0-5dfbf45b6c-9glg8   Ready    <none>   16h   v1.17.3   10.0.4.164    10.0.4.164    VMware Photon OS/Linux   4.19.79-2.ph3    containerd://1.3.3

capvdemo-md-0-5dfbf45b6c-c926m   Ready    <none>   16h   v1.17.3   10.0.4.163    10.0.4.163    VMware Photon OS/Linux   4.19.79-2.ph3    containerd://1.3.3

capvdemo-md-0-5dfbf45b6c-l8s2h   Ready    <none>   16h   v1.17.3   10.0.4.165    10.0.4.165    VMware Photon OS/Linux   4.19.79-2.ph3    containerd://1.3.3

4. Octant による Web UI からの確認。

Web ブラウザから、いずれかの Kuberente ノードの NodePort（今回は 32128）にアクセスすると、Octant の画面が開きます。

さきほど kubectl get pods ～ といったコマンドの表示結果が、GUI で表示できたりします。

この Octant には、Antrea の Plug-in が組み込まれています。

ちなみに、素の Octant（octant リポジトリからダウンロード＆インストールしたもの）の場合は、

デフォルトでは Antrea Plug-in が組み込まれていません。

Antrea Controller の情報や・・・

Antrea Agent の情報も、表示できるようになっています。

たとえば、Pod のリンクをドリルダウンして、

CLI であれば kubectl describe ～ といったコマンドで確認していた情報を表示したり・・・

リソースの関係を可視化することもできます。

kubectl logs で確認していたような、ログの表示もできたりします。

以上、Kuberentes に Antrea と Octant をインストールしてみる話でした。

With NSX-T 3.0 there have been some really good enhancements with IDFW feature which is mainly used for VDI use cases. This feature enables NSX administrator to create Active Directory user-based Distributed Firewall (DFW) rules. NSX-T 3.0  introduced support of Windows Server 2019. In terms of protocol support now its supports TCP as well UDP and ICMP protocols

In this blog entry part 3 (VMware Photon OS on Azure #Part 1 - introduction , VMware Photon OS on Azure #Part 2 – create an Azure Photon OS virtual machine ) I will forcibly neglect for a while that we look into a Photon OS virtual machine on Azure. Try to look to it as a time ride back of thirty years, no external connectivity, no external help. Let's assume of not knowing anymore about Linux commands. Without going into all basic improvements, how would Today the troubleshooting experience evolve? this is the mindset for this blog part.

I remember when my parents bought me a Commodore Amiga computer with floppy disk 3.5", no hard disk, 512 MB RAM, 5.25" floppy with expansion card which lets the Amiga emulate a 286 PC at full speed. I started with no English language know-how, did a lot of try and error of my own and - it was horrible. After a day or two I deleted a file called startup-sequence. I didn't knew it was a system file and I needed to reinstall the whole computer. The first weeks past on-the-fly, and the best second chance was using the help command.   So better apply this first.

With the login we directly start into gnu bash console.

localadminuser [ ~ ]$ help

GNU bash, version 4.4.18(1)-release (x86_64-unknown-linux-gnu)

These shell commands are defined internally.  Type `help' to see this list.

Type `help name' to find out more about the function `name'.

Use `info bash' to find out more about the shell in general.

Use `man -k' or `info' to find out more about commands not in this list.

The text contains a release information, how to use help and further information. The release information isn't the same as in the login prompt, so there is no obvious correlation between the system and help release.

Help gives a hook to start with. Let's discover some commands. As it is a computer let's see if we can find some mathematical functions! Indeed there are some, let's try expr or let.

Found out that there is the possibility of defining variables as well. Nice! Let's go back to other commands.

I discovered that the command "cd" means change directory, and there is a difference between the commands dirs and dir. That said, discovering the filesystem content suddenly I landed in the /bin (and /sbin) directory and discovered another and even much more bigger list of new commands. Boom! This wasn't easy at all. With the alphabetical beginning at awk I've noticed that the apps there usually use --help for their syntax declaration.

I can't remember when exactly but I've started using ctrl-c as it helps when try exiting the command dc or bc. Btw, bc is yet another math app!

A next commanddf shows us the free filesystem capacity state.

In /dev directory there are same names. These are all (virtual)devices. The time has past and I've realized that /dev/sda is a 16GB disk and /dev/sdb is a 64GB disk, both with one or more partitions.

From a discovery perspective there are interesting apps beginning with ls or ending with ctl. ls as dir command substitute uses colors displaying different type of content. These apps ls* and *ctl seem to be quite useful when discovering the hardware:

Hostnamectl exposes some system identifiers.

lscpu shows the cpu information, exposed as a 4x Intel(R) Xeon(R) Platinum 8171M CPU @ 2.60GHz system.

lsmem shows the RAM in online or offline state.

lspci shows expansion information of pci (peripheral component interconnect). As the hardware is accessible from remote only, the system I trust shows as example seven components. Two ethernet controllers are from Mellanox Technologies, all other adapters are Microsoft devices.

Networkctl shows the status of the network devices. Some ethernet adapters seems already to be configured.

There are one loopback adapter, one docker bridge, two configured network adapters and two adapters in state configuring. The two configured network adapters make use of a driver called hv_netsvc. The adapters in state configuring are the ethernet controllers exposed in lspci. The command systemctl displays the status of device drivers. The result has similarities to a list consisting of conventions for path naming, state, etc.

Timedatectl shows up the system time.

hwclock as alternative shows the time in realtime computer format. As it is known that the realtime clocks in 2020 usually reset to 1.1.1970, in this case it counts 50 years and 150 days and knowing there were 12 leap years. It is much easier to use Timedatectl , but it is good to know that most commands have a service alternative.

Let's have another view of the system. busctl exposes users and (background) services units. So far, the system shows up five users context

- me (localadminuser) with one active session firing up busctl

- root with services units init.scope, system-machined.service and systemd-logind.service

- systemd-network

- systemd-resolve

- systemd-timesync

The protocol of those services can be viewed by using the command journalctl.

journalctl -u systemd-networkd

journalctl -u systemd-machined

journalctl -u systemd-login

journalctl -u systemd-timesync

To get an idea which users' context is processed, the command who shows up users who are currently logged in. When you log out and login again with the same user, you might want to lookup commands from the last session.Quite useful is the command history.

The directory /var/log is helpful, too, as it contains some further log files.

In the past all commands so far were used interactively. To process commands in background you can add a & at the end. A process id is shown and the command jobs displays the state of registered processes.

In help this behaviour isn't explicitly mentioned as possibility for a command but rather for a job specification. A job could be a single command but also a script.

The system has a line editor called vi. It holds more than 100 features in it. Entering version exposes all features by name. And the tool shows off the date of its last compilation. However, further help does not work intuitively entering F1 as proposed.

The more investigating, the more I thought that something on the OS might be broken. How can we check that? How can I check if tools are not okay?

It took a while, but I found the tool rpmverify which can verify the system.

The tool throws out some weired output, but, it seems to be right with the missing ones! /usr/bin/wget is missing, all other six files are missing, too. How to fix the issues? This remains unclear.

From the VMware tools perspective the system is not running as a VMware virtual machine.

Let's leave the system.

Back to the present - findings

With the internal commands help only you can learn quite a bunch of commands. Step by step you find out that most are from the free software foundation (https://www.gnu.org). Most help works usually using --help and most of the commands supports --version, as well. After a while you learn more about the underlying hardware and the filesystem structure, and on top of the underlying hardware runs VMware Photon OS.

Photon OS is a security hardened system. One finding from a learning perspective is the demand of some sort of a system check recipe. For an administrator it is not easy to come along with the internal system help. Luckily it is quite useful that most logs are retrievable and there are tools like rpmverify. There is a similarity to the short Microsoft DOS epoch in 1980ies++ where you had to learn hundreds of commands one by one without centralized get-help.

Without any help from outside, it would have been impossible to repair the detected issues even after learning more and more commands. The missing wget and top can easily be reinstalled by using the package manager tdnf (tiny dandified yum). But it isn't always obvious which program belongs to which package.

If you're new to Photon OS, it helps to gain some experience in basic troubleshooting techniques. A good starting point is the Photon OS Troubleshooting Guide https://github.com/vmware/photon/tree/master/docs/photon_troubleshoot .

vSphere 7.0 Converge & Migration Process

Glad that you are seeking options to upgrade to our brand new offering vSphere 7.0

Please note that starting from vCenter 7.0, it will be only appliance based no options for integrating with any external database.

Community Support:

Did you know that VMware has a dedicated Install/Upgrade community ?

This sub community has an active user base and helps on common queries/errors during upgrade.

If you ever encounter any errors during the upgrade, feel free to post in our official install/upgrade forum - vSphere Upgrade & Install

This article focuses on migrating 6.5 Windows vCenter with external PSC to 7.0 vCenter Server

The steps are more or less same for migrating 6.7 windows to 7.0 vCenter Server

What has been deprecated in vCenter 7.0:

• No option provided for deployed external PSC
• No option provided for deploying Windows based vCenter
• No inclusion of flash based Web client

Who can upgrade:

Click here to check the vCenter Server version upgrade compatibility

Click here to get update sequence for vSphere 7.0

Licensing:

For vSphere 7.0, the existing license needs to be upgraded and you can contact VMware licensing team for upgrade options specific to your existing license.

Click here to learn more about licensing requirement for vCenter Server 7.0

Download:

Click here to download the latest version of vCenter 7.0

What you require:

• A jump box, preferably windows 10 or any windows server 2008/20212/2016
• It is advised to keep the jump box and the destination vCenter 7.0 on the same subnet, same port group/VLAN as the source vCenter appliance that you are planning to upgrade

          This way we can eliminate most of the network related errors during the upgrade phase.

• User has access to windows based external PSC and vCenter
• Make sure you have taken complete backup of the vCenter database

A quick summary of actions we will be performing for this migration process:

The migration task is split into stage 1 and stage 2.

Stage 1

Deploy a new 7.0 vCenter VM with active network connection set to communicate via the temporary IP address

 

Stage 2

The installer exports the data from the existing 6.5 vCenter to the new 7.0 vCenter using temporary IP

Performs convergence, shuts down source vCenter and reverts the network back to the same IP as the source vCenter

Performs First-Boot of vCenter 7.0 services and then imports copied data to the 7.0 vCenter

Steps with Screenshot :

___________________________________________________________________________________________

Stage 1

___________________________________________________________________________________________

Once you have read the above documents proceed to mount the downloaded image on the jump box

Inside the mounted directory, copy the "migration-assistant" folder

Log into the source windows vCenter server and paste the "migration-assistant" folder

___________________________________________________________________________________________

<On the source 6.5 windows vCenter>

Navigate to the folder and Run the migration assistant as Administrator

___________________________________________________________________________________________

Enter the SSO password and wait for the installer to perform pre-checks and shows prompt "waiting for migration to start"

DO NOT CLOSE THIS WINDOW - KEEP IT RUNNING

___________________________________________________________________________________________

<Login back to the Jump Box where you have mounted the installer ISO>

Navigate to the following directory and run the installer as Administrator and Select "Migrate"

___________________________________________________________________________________________

Once the installer starts, on the Introduction page, we have a quick recap of the two stage process which we had discussed earlier

Click "Next" and accept the EULA (End User License Agreement)

___________________________________________________________________________________________

Here you need to enter the FQDN of the source vCenter server

Also your local SSO administrator username and the password and click "Next"

(Make sure to correct the domain vsphere.local in case if you have set a different local SSO domain)

The installer gives prompt "Converge to an embedded Platform Services Controller"

This is to let users know that it has read the underlying vCenter configuration.

It automatically detects that the source vCenter has external SSO and will perform a converge operation during Migration

___________________________________________________________________________________________

Enter the host/vcenter name or IP on which the new 7.0 VM is going to get deployed

Since I have set the host IP address, I have set the username as root

If you had entered vCenter name, you should be entering the SSO admin user which is administartor@vsphere.local

___________________________________________________________________________________________

The VM name is the name on which the new VM will be deployed on the inventory

Also here you are given option to set the root password for the 7.0 vCenter

___________________________________________________________________________________________

Set the appliance deployment size based on your environmental requirement

You can refer the table in the above screenshot to size it accordingly

___________________________________________________________________________________________

You select the Datastore where the new VM will be deployed

___________________________________________________________________________________________

It is advised you select the same port-group where the source vCenter VM resides

Provide the temporary IP address, subnet, gateway and DNS server

All these steps are mandatory and cannot be skipped

___________________________________________________________________________________________

You are given one final view of all the network settings provided

Once confirming the details, click on Finish to start Stage1 deployment

___________________________________________________________________________________________

The deployment of the new vCenter 7.0 VM starts

You can check its progress by logging into the ESXi host and check the tasks pane

The installer might freeze at 80% but do not panic as this is common

At 80% is where it installs the RPM packages for the appliance

___________________________________________________________________________________________

Once completed, you should see the screen as above

___________________________________________________________________________________________

At this point, it is advised to take a snapshot of the newly deployed vCenter 7.0 appliance

If by any chance if the installer fails, you can revert back to the end of Stage1 installation and retry the upgrade again

 

To restart the upgrade from this point, you just simply enter the temporary IP address with port 5480

Example: If my temporary IP is 192.168.0.111

Then I restart the upgrade process from browser https://192.168.0.111:5480

___________________________________________________________________________________________

Stage 2

Click continue to go to Stage 2 Introduction page where the process is explained

Click "Next" to take you to the "Connect to source vCenter" page

___________________________________________________________________________________________

The installer detects the existing vCenter details which were provided earlier

Click "Next" to run the pre-migration checks for Stage 2

___________________________________________________________________________________________

This is the new option introduced

You can select the default option in case if you have single PSC and vCenter like we used in this guide

___________________________________________________________________________________________

Optional - Only for reference purpose

This is how you can select to manage convergence in case if the PSC has multiple vCenter registered

___________________________________________________________________________________________

You are given option to enter the username which has privilege to add machines to the Domain

This step automatically adds vCenter appliance to the AD domain

___________________________________________________________________________________________

You can choose to keep tasks, events and performance charts data

You can also skip and go only with the configuration data of the source vCenter

___________________________________________________________________________________________

You can check this box to join VMware customer experience improvement program

Click "Next" to continue

___________________________________________________________________________________________

You are given options to validate your inputs

You have to check the "I have backed up..." to continue

If all the entered data is correct, start the final step by clicking on "Finish"

___________________________________________________________________________________________

Stage 2 starts and it will power off the source vCenter

The new vCenter 7.0 VM will take the same IP as the source and the temporary IP will be deleted

Once complete you will see installation successful 100% complete.

___________________________________________________________________________________________

This marks the end of Stage 2 and completion of the migration process

Additional Notes:

Only the source windows vCenter is only powered off

If you notice the source PSC is still powered on

Also if you check the replication partner, you will still see the source PSC registered with the new vCenter 7.0 appliance

This is kept so that customers can continue the migrate paths for other vCenter which are connected to the same PSC

Once the entire environment is migrated, you can decommission the source windows PSC following this link

- Jonathan Ebenezer

vSphere 7.0 から、vSphere で Kubernetes ワークロードを実行する機能が追加されました。

vSphere with Kubernetesの設定と管理

vSphere with Kubernetes Configuration and Management（英語の原文）

この機能を「ちゃんとサポートされた構成」で構築するには、

ハードウェア／ソフトウェア要件がわりと厳しめです。

そこで今回は、とりあえず機能を体験するためのラボ環境構築をしてみます。

vSphere with Kubernetes を有効化したクラスタは Superviser Cluster や、Workload Control Plane（WCP）と呼ばれていて、

vCenter のインベントリで「名前空間（Namespace）」が作成できるようになります。

この環境での Kubernetes ワークロード実行には、主に 2パターンあります。

vSphere Pod

• ESXi が Kubernetes の Worker Node になる。
• Pod が作成されるたびに、Pod 専用の VM が起動される。

Tanzu Kubernetes Cluster

• ゲスト OS での Kubernetes クラスタを構成する。つまり VM が Kubernetes の Worker Node になる。
• Pod は、Worker Node の VM 上で起動される。（vSphere Client から見えるのは Wroker Node まで）

vSphere Client から見ると、それぞれ下記のように見えます。

環境説明。

Superviser Cluster での Kubernetes は、NSX-T の利用を前提としています。

これから構築するラボ環境のネットワーク構成は、下記のような感じになります。

NSX-T では、Tier-0 Gateway を手作業で作成しておく必要があります。

（NSX の各要素の設定については、のちほど説明するつもり・・・）

サーバ構成。

今回は、下記のようなサーバ構成にしています。

図の赤破線内の VM は、あらかじめ用意しておきます。

• 物理マシンは、サーバではなく、ちょっと性能がいい PC を利用します。
• ネステッド ハイパーバイザ環境です。（ESXi 上の VM に、ゲスト OS として ESXi をインストール）
• 頑張れば、もう少し CPU / メモリ リソースは削減できます。
• vCPU / vRAM 割り当てが大きい vCenter、NSX Manager、NSX Edge は、ネステッド ESXi の外側に配置。
• Superviser Cluster ラボ環境むけに、新規で vCenter を用意して、 ネステッド ESXi を登録しています。

ネストの内側の環境について。

まず、今回 Supervisor Cluster にする vSphere 環境です。

ESXi 3ノードの vSphere クラスタ（wcp-cluster-01）を構成しています。

バージョンは下記です。

• vCenter Server 7.0.0a
• ESXi 7.0 GA

ESXi の共有データストアは NFS です。

一般的には vSAN になると思いますが、ネステッド環境のスペックの都合上 NFS にしています。

シン プロビジョニングになるので、搭載 VM の VMDK 合計よりも少ない容量（500 GB程度）です。

ESXi には、「ワークロード管理」の機能をもつライセンスが必要です。

今回は、ESXi インストール直後の評価モード（60日間の）です。

ネストの外側の環境について。

ここまでに紹介した「ネステッド vSphere」の外側の vSphere です。

機能上ネステッド ESXi 上にのせる必要がない VM は、あえて外側の vSphere に配置しています。

下記の VM が稼働しています。

• ESXi の VM が 3つ
• vCenter
• NSX Manager
• NSX Edge （スクリーンショットにはまだ存在しない）
• NFS データストアにしている Linux VM

ネステッド ESXi（ESXi をインストールしている VM）の vNIC では、ネストむけのポートグループを割り当てます。

この環境では vDS を利用しており、分散ポートグループは次のように設定しておきます。

• VLAN トランク（0-4094）。※vSS の標準ポートグループの場合は VLAN 4095。
• 無差別モード、MAC アドレス変更、偽装転送を「承諾」。

また、この vDS も NSX-T オーバーレイ ネットワークの経路になるので、

MTU を 1600 に設定しておきます。

つづく。

vSphere with Kubernetes 環境構築。Part-02: vSphere 事前準備編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

今回は、vSphere 環境の事前準備です。

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-01: 環境説明編

Superviser Cluster を有効化する準備として、

vSphere DRS、vSphere HA、vDS まわりの設定をしておきます。

ここから設定するのは、（前回も掲載した）サーバ構成イメージ図の赤破線の部分にあたります。

vSphere DRS の有効化。

Superviser Cluster を有効化する前提として、vSphere DRS / HA 両方の有効化が必要です。

まず、vSphere Cluster で、DRS を「完全自動化」で有効化しておきます。

vSphere Cluster を作成した時点では DRS が無効なので、「編集」から設定変更します。

vSphere DRS を有効（緑）にして、自動化レベルは「完全自動化」を選択しておきます。

vSphere HA の有効化。

そして、vSphere Cluster で、HA も有効化しておきます。

※vSAN を利用する場合は、vSAN データストアを構成したあとで HA を有効化します。

vSphere HA も、vSphere Cluster 作成時点では無効なので、「編集」から有効化しておきます。

「障害および対応」タブで、vSphere HA を有効（緑）にしてきます。

今回のラボ構成だと共有データストアが 1つだけ（2つ以上ではない）です。

そこで、vSphere HA のハートビート データストア不足メッセージの抑止のために、「詳細オプション」タブで次のパラメータを追加しておきます。

das.ignoreinsufficienthbdatastore = true

※ 参考： vSphere HA の詳細オプション

• もしくは、2つ以上のデータストアを用意しておきます。
• vSAN の場合は、データストアが 1つでも特にメッセージは表示されません。

vSphere Cluster で、DRS / HA 両方が有効な状態になりました。

vDS 作成 ／ ESXi のアップリンク接続。

Superviser Cluster の Kubernetes ネットワーク機能では、NSX-T 3.0 を利用します。

そして、NSX-T の仮想スイッチでは、vSphere 7.0 の分散仮想スイッチ（vDS 7）を利用することになります。

そのため、バージョン 7 の vDS を作成し、そのアップリンクに ESXi の vmnic（物理 NIC にあたる）を割り当てておきます。

ただし、今回は、vDS 作成についてこまかい手順は省略し、ポイントだけ記載しておきます。

vDS 作成時に、バージョンは「7.0.0」を選択します。

vDS の MTU はデフォルトでは 1500 です。

NSX-T のオーバーレイ ネットワークの要件にあわせて、1600 以上にしておきます。

ESXi ホストを vDS に追加して、アップリンクを割り当てておきます。

Superviser Control Plane VM 用 分散ポートグループ作成。

※既存仮想スイッチに管理ネットワークに接続できるポートグループがある場合は不要ですが・・・

あとで Superviser Cluster を有効化する際に、

Superviser Control Plane VM を接続するネットワーク（ポートグループ）を選択することになります。

vCenter などが接続された管理ネットワークにアクセスできる、

もしくは管理ネットワーク自体の分散ポートグループも作成しておきます。

今回は「DPortGroup-labmgmt」というポートグループを作成しています。

つづく・・・

vSphere with Kubernetes 環境構築。Part-03: 仮想マシン ストレージ ポリシー準備編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

前回の投稿はこちら。

vSphere with Kubernetes 環境構築。Part-02: vSphere 事前準備編

今回は、vSphere with Kubernetes にかかわる機能が ESXi のデータストアを選択するときに利用する、

「仮想マシン ストレージ ポリシー」の作成です。

たとえば、Supervisor Cluster を有効化する際に、データストア指定のかわりに、

仮想マシン ストレージ ポリシーを選択します。

※これは、後程実施する手順のものです。

具体的には、下記のような作業をします。

• vSphere の機能で「タグ」を作成。
• データストアにタグを付与する。
• タグをもとにデータストアを選択する、仮想マシン ストレージ ポリシーを作成。

ただし、vSAN データストアを利用する場合は、デフォルトで作成される「vSAN Default Storage Policy」でラボ構築をすすめられるので、次の投稿にスキップしても大丈夫です。 今回のラボでは vSAN ではなく、NFS データストアを利用するため、仮想マシン ストレージ ポリシーの追加作成をしています。

vSphere の「タグ」作成。

「タグとカスタム属性」メニューを開きます。

「タグ」画面にある「新規」リンクから、「タグの作成」画面をひらいて、

「新しいカテゴリの作成」をクリックします。

下記のようにカテゴリを作成します。

• カテゴリ名： datastore-category
• オブジェクトあたりのタグ数： 1つのタグ
• 関連付け可能なオブジェクト タイプ： 「データストア」のみチェック On にする。

「タグの作成」画面にもどり、下記のようなタグを作成します。

• 名前： wcp-demo
• カテゴリ： datastore-category （直前に作成したカテゴリを選択している）

タグが作成されました。

データストアへのタグ割り当て。

データストアの「サマリー」画面で、「割り当て」をクリックします。

直前の手順で作成したタグを選択します。

データストアに、タグが割り当てられました。

仮想マシン ストレージ ポリシーの作成。

「ポリシーおよびプロファイル」メニューを開きます。

「仮想マシン ストレージ ポリシー」にある、

「仮想マシン ストレージ ポリシーの作成」をクリックします。

仮想マシン ストレージ ポリシー名を入力します。

今回は「vm-storage-policy-wcp」にしています。

「データストア 固有のルール」で、「タグ ベースの配置ルールを有効化」を On にします。

ルール1 には、先ほど作成した  カテゴリ／タグ を指定します。

• タグ カテゴリ： datastore-category
• 使用量オプション： 以下のタグ付けをされたストレージを使用
• タグ： 「wcp-demo」が指定された状態にする。

「ストレージ互換性」で、タグを付与したデータストアが表示されることを確認します。

仮想マシン ストレージ ポリシーが作成されました。

続く。

ひきつづき、vSphere with Kubernetes ラボ環境を構築していきます。

今回は、NSX Manager のデプロイについてです。

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-03: 仮想マシン ストレージ ポリシー準備編

Supervisor Cluster の有効化には、NSX-T での事前準備も必要です。

下図（以前に掲載した図の流用ですが）の、赤破線あたりです。

まず、NSX-T のセットアップとしては、次のような作業が必要です。

（厳密には、もうすこし作業が分割されます）

• NSX Manager のデプロイと vCenter の登録。
• ESXi を、NSX が利用可能な「ホスト トランスポート ノード」にする。
• NSX Edge のデプロイして、「Edge トランスポート ノード」のとして準備。
• NSX の Tier-0 Gateway と、そのアップリンクの作成。

vSphere / NSX 以外にも準備するものがありますが、今回は省略しています。

実際には下記のような準備が必要です。

• 時刻同期のため、NTP サーバ。
• DNS サーバ。vCenter / ESXi / NSX などの正引き（A）、逆引き（PTR）レコードを登録しておく。
• 当然ながら物理ネットワークの準備も必要。（MTU 設定や、VLAN、ルーティングなど・・・）

一方で、上の図中の「Supervisor Control Plane VM」や、

それ以下のネットワーク要素のほとんどは、vSphere with Kubernetes の機能から自動管理されます。

Tier-0 Gateway と、そのアップリンク（図では t0-uplink）、VLAN 論理セグメントのみを作成しておくと、

それ以外のオーバーレイ ネットワークやロードバランサは、Supervisor Cluster の有効化などによって自動作成されます。

それでは、NSX Manager をデプロイします。

NSX-T 3.0 評価版の入手。

NSX-T 評価版のソフトウェア（.ova ファイル）と、ライセンス キーは、下記のサイトから入手できます。

VMware NSX-T Product Evaluation Center

https://my.vmware.com/web/vmware/evalcenter?p=nsx-t-eval

NSX Manager のデプロイ。

今回は、ハードウェア リソースの都合上、

NSX Manager は、Supervisor Cluster にするネステッド vSphere の外側にデプロイします。

デプロイ先を右クリック →「OVF テンプレートのデプロイ」から、

NSX Manager の OVA ファイルをデプロイします。

NSX Manager の OVA ファイル名は、「nsx-unified-appliance-＜バージョン文字列＞.ova」となっています。

これは Unified Appliance と呼ばれ、デプロイの途中のロール指定によって NSX Manager になります。

OVA のデプロイでは、つぎのようなパラメータ（NSX 固有でないものは記載省略）を指定します。

※特に記載のないパラメータは、デフォルト値（もしくは空欄のまま）です。

※ネットワーク構成は、おおよそ冒頭のイメージ図のようにしています。

• 仮想マシン名： lab-nsx-03
• フォルダの選択： （ここの指定はネスト外側の vSphere 環境）
• コンピューティング リソースの選択： （ここの指定はネスト外側の vSphere 環境）
• デプロイ構成の選択： Small（4 vCPU, 16GB RAM）
• ストレージの選択： （ここの指定はネスト外側の vSphere 環境）
• ネットワークの選択： vCenter / ESXi と通信可能なポートグループを選択。
• System Root User Password：
  NSX Manager の OS（VM コンソールや SSH）に root ログインするパスワードを入力。
• CLI “admin” User Password：
  NSX Manager の Web インターフェースや OS に admin ログインするパスワードを入力。
• CLI “audit” User Password： 空欄のまま。
• Hostname： lab-nsx-03
• Rolename： NSX Manager
• NSX Site Name： 空欄のまま。
• Default IPv4 Gateway： 192.168.10.1
• Management Network IPv4 Address： 192.168.10.23
• Management Network Netmask： 255.255.255.0
• DNS Server list： ラボ環境の DNS を入力。（スペース区切り）
• Doman Search List： go-lab.jp
• NTP Server list： ラボ環境の DNS を入力。（スペース区切り）
• Enable SSH: On
• Allow root SSH logins： On

補足として・・・

「デプロイ構成の選択」はデフォルト値が「Medium」ですが、

「Small」でもラボ構築は可能です。

OVA ファイルのデプロイが完了したら、VM をパワーオンします。

しばらく待つと、Web ブラウザから https できるようになります。

そして、admin ユーザ / デプロイ時指定のパスワード でログインできるはずです。

NSX 評価ライセンスの追加。

Tier-0 ゲートウェイなどを作成するために、評価ライセンスの追加が必要です。

「システム」→「ライセンス」→「追加」から、ライセンス キーを入力しておきます。

※ちなみに、画面上部にある青メッセージの「ライセンスの管理」でもこの画面を開けます。

つづく。

vSphere with Kubernetes ラボ環境構築。Part-05: NSX Manager 設定編

ひきつづき、vSphere with Kubernetes ラボ環境を構築していきます。

前回デプロイした NSX Manager で、設定をすすめます。

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-04: NSX Manager デプロイ編

vCenter の追加。

NSX Manager に、「コンピュート マネージャ」として vCenter を登録しておきます。

（前回の図をもう一度。）

NSX Manager にログインして、

「システム」→「ファブリック」→「コンピュート マネージャ」→「追加」から

「コンピュート マネージャの作成」を開きます。

今回のラボでは次のようなパラメータで追加しています。

※下記以外はデフォルト値のままです。

• 名前： lab-vc-03
• FQDN または IP アドレス： lab-vc-03.go-lab.jp
• ユーザー名： administrator@vsphre.local
• パスワード： administrator@vsphre.local のパスワードを入力
• 信頼を有効にする： はい ★これは Supervisor Cluster 有効化のために必須。

vCenter が追加されました。

接続状態が「稼働中」にならない場合は、画面下の「更新」ボタンをクリックしてみます。

「システム」→「ファブリック」→「ノード」→「ホスト トランスポート ノード」を開き、

管理元で vCenter（今回は lab-vc-03）を選択すると、クラスタと ESXi が表示されるようになります。

この時点では、まだ NSX は「未設定」です。

このあと、NSX のトランスポート ノードとして設定します。

トランスポート ゾーンについて。

NSX によるネットワークは、「トランスポート ゾーン」で管理されます。

これは、ESXi や NSX Edge を「トランスポート ノード」として設定する際にも指定します。

「オーバーレイ」と「VLAN」の 2種類のトランスポートが存在し、Supervisor Cluster では両方を使用します。

一般的にはそれぞれ任意の名前で追加作成すると思いますが、

このラボでは、デフォルトのものをそのまま利用します。

「システム」→「ファブリック」→「トランスポート ゾーン」を開くと、

デフォルトのトランスポート ゾーンが 2つ作成されています。

• オーバーレイ トランスポート ゾーン： nsx-overlay-transportzone
• VLAN トランスポート ゾーン： nsx-vlan-transportzone

TEP IP アドレス プールの準備。

NSX のオーバーレイ ネットワークでは、

ESXi と NSX Edge では、Geneve カプセル化プロトコルのトンネルになる、

TEP（Tunnel End Point）というポートが構成されます。

TEP のアドレス設定には、NSX の「IP アドレス プール」を使用します。

このあとの ESXi と Edge の設定に備えて、

ここで「IP アドレス プール」を作成しておきます。

「ネットワーク」→「IP 管理」→「IP アドレス プール」→「IP アドレス プール の追加」を開き、下記を入力します。

• 名前： ip-pool-tep

そして、そのまま「サブネット」下の「設定」を開きます。

「サブネットの設定」が開くので、「サブネットの追加」→「IP 範囲」をクリックし、

パラメータを入力して「追加」をクリックします。

このラボでは、下記のパラメータにしています。

• IP 範囲： 192.168.71.11-192.168.71.15
• CIDR： 192.168.71.0/24

ちなみに、このラボでは ESXi の TEP と NSX Edge の TEP を同セグメント（VLAN）にしていますが、

構成によっては ESXi と NSX Edge それぞれに別セグメント（VLAN）にする必要があります。

その場合は、ちゃんと「ゲートウェイ IP」の入力も必要です。

また、NSX Edge の TEP では IP アドレス プールを使用せず、

手入力でアドレス設定すること（実際の設定値は「固定 IP のリストを使用」）も可能です。

入力したら、画面にしたがって「適用」・・・

「保存」をクリックします。

IP アドレス プールが作成されました。

ここでも「状態」が「成功」にならない場合は、

「状態」（図だと成功のとなり）か、画面下の更新ボタンをクリックしてみます。

まだ続く。

We taken offline VSAN cluster and re-install all hosts , here we forgot de-attached drive before re-image server.

After re-image we were not able to see any nvme ssd in ESXi 6.7 , I found driver was not in vib list

I installed driver on all hosts and rebooted

Now I am able to see all drive but required erase partition for creating VSAN cluster ,

Download this driver and install by command line

(VMware ESXi 6.7 intel-nvme-vmd 1.4.0.1016 NVMe Driver)

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

今回は、ESXi を ホスト トランスポート ノードとして設定します。

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-05: NSX Manager 設定編

今回、NSX Manager と連携する vCenter / ESXi では、すでに vDS を構成してあります。

NSX-T のオーバーレイ ネットワークでは MTU を 1600 以上にしますが、

NSX による仮想スイッチを vDS 7 に統合する場合は、MTU は vDS 側で設定します。

今回はネステッド環境なので、ネストの外側の仮想スイッチでも MTU を 1600 にしてあります。

ホスト アップリンク プロファイルの作成。

NSX Manager にログインして、

「システム」→「設定」→「ファブリック」→「プロファイル」を開きます。

そして、「アップリンク プロファイル」タブの「追加」から、

「アップリンク プロファイルの作成」を開いて、設定値を入力していきます。

アップリンク プロファイルの名前は「uplink-profile-esxi」にしています。

そのまま下にスクロールして、「デフォルトのチーミング」に、アップリンクの名前を入力します。

今回は、チーミング ポリシーが「フェイルオーバーの順序」なので、アクティブ / スタンバイです。

• アクティブ アップリンク： uplink-1
• スタンバイ アップリンク： uplink-2

のこりは、次のような設定にしています。

• トランスポート VLAN： 71
• MTU： 空欄のまま。（vDS 側で設定するため）

アップリンク チーミング ポリシーが作成されました。

トランスポート ノード プロファイルの作成。

「システム」→「設定」→「ファブリック」→「プロファイル」を開きます。

そして、「トランスポート ノード プロファイル」タブの「追加」から、

「トランスポート ノード プロファイルの追加」を開いて、設定値を入力していきます。

アップリンク プロファイルの名前は「tn-profile」にしています。

少し下にスクロールし、「ノード スイッチの作成」では次のように入力しています。

• タイプ： VDS
• モード： 標準
• 名前： vCenter は「lab-vc-03」、vDS は「DSwitch」を選択。
• トランスポート ゾーン： nsx-overlay-transportzone
  （オーバーレイ トランスポート ゾーンのみ。VLAN トランスポート ゾーンは必須ではない）

ふたたび下にスクロールして、残りのパラメータを入力して「追加」をクリックします。

• アップリンク プロファイル： uplink-profile-esxi
• IP の割り当て： IP プールを使用
• IP プール： ip-pool-tep
• チーミング ポリシー スイッチ マッピング → uplink-1： アップリンク 1
• チーミング ポリシー スイッチ マッピング → uplink-2： アップリンク 2

トランスポート ノード プロファイルが作成されました。

ホスト トランスポート ノードの設定。

vSphere Cluster 単位で、ESXi にトランスポート ノード プロファイルを適用します。

「システム」→「設定」→「ファブリック」→「ノード」を開きます。

そして、「ホスト トランスポート ノード」タブの「管理元」で vCenter（ここでは lab-vc-03）を選択します。

vSphere の Cluster（ここでは wcp-cluster-01）を選択して、「NSX の設定」をクリックします。

トランスポート ノード プロファイル（tn-profile）を選択し、「適用」します。

処理の完了をしばらく待ちます。たまに「更新」をクリックて様子を見ます。

処理完了すると、「NSX 設定」が「成功」になるはずです。

vSphere Client から vDS を見ると、「NSX スイッチ」になっています。

まだつづく。

vSphere with Kubernetes ラボ環境構築。Part-07: NSX Edge デプロイ編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

今回は、NSX Edge の仮想アプライアンスをデプロイします。

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-06: ホスト トランスポート ノード準備編

NSX Manager に登録されている（コンピュート マネージャになっている）vCenter配下の ESXi 上であれば、

NSX Edge は NSX Manager の Web UI からデプロイできます。

しかし、このラボではハードウェア リソースの都合上、

NSX Edge を、コンピュート マネージャ vCenter 管理外の ESXi にデプロイします。

そのため、一般的な vCenter の機能（OVF テンプレートのデプロイ）で

NSX Edge の仮想アプライアンスをデプロイします。

NSX Edge が NSX Manager と連携するためのパラメータも手入力します。

NSX Manager の証明書サムプリント取得。

NSX Edge の OVA ファイルをデプロイする際に、

NSX Manager の証明書サムプリントを入力する必要があります。

そこで、あらかじめ NSX Manager の Web UI で確認しておきます。

NSX Manager にログインして、

「システム」→「設定」→「アプライアンス」を開き、

NSX Manager（ここでは 192.168.10.23）の「詳細」をクリックします。

「証明書サムプリント」の横にあるアイコンをクリックすると、

「コピーしました」と表示され、クリップボードに証明書サムプリント（64文字）がコピーされます。

あとでこの文字列が必要になるので、テキスト ファイルなどに（Ctrl + v などで貼り付けて）保存しておきます。

ちなみに、この証明書サムプリントは、NSX Manager に SSH ログインして

下記コマンドで取得することもできます。

get certificate api thumbprint

NSX Edge デプロイ先のポートグループ作成。

NSX Edge の仮想マシンには、Edge 内部に作成される仮想スイッチのための、

VLAN トランクポートグループが必要になります。

NSX Edge をデプロイする vSphere 環境（今回はネストの外側の環境）に、

ポートグループを作成しておきます。

このポートグループは、分散仮想スイッチ（vDS）と、標準仮想スイッチ（vSS）の、

どちらに作成しても、ラボ環境を構築できます。

今回は vSS に標準ポートグループを作成します。

まず、この vSS も NSX-T のオーバーレイ ネットワークの経路となるので、

MTU を 1600 以上に設定しておきます。

NSX Edge の管理ネットワーク用のポートグループ（ここでは pg-labmgmt-0010）を作成しておきます。

これは Edge VM の 1つめの vNIC に割り当てることになります。

アップリンク用の標準ポートグループ（名前は pg-edge-uplink）を作成します。

VLAN トランクとしたいので、VLAN ID を「すべて (4095)」としています。

※ vDS の分散ポートグループの場合は、VLAN トランクで ID を「0 - 4094」にします。

アップリンク用の標準ポートグループは、

作成後に、無差別モードと偽装転送を「承諾」にしておきます。

このポートグループは Edge VM の 2つめ（から4つめ）の vNIC に割り当てることになります。

NSX Edge の OVA ファイルのデプロイ。

NSX Edge の OVA ファイルを、vSphere Client からデプロイします。

OVA ファイルは「nsx-edge-＜バージョン文字列＞.ova」となっています。

デプロイ先（クラスタや ESXi など）を右クリックして、

「OVF テンプレートのデプロイ」から、一般的な OVA ファイルと同様の手順でデプロイします。

ウィザードにしたがって、デプロイのフォルダやデータストアなどのパラメータを入力していきます。

（一般的な OVA ファイルのデプロイと変わらない部分は、省略しています）

「デプロイ構成の選択」では、かならず「Large」以上を選択します。

vCPU が最低でも 8以上でないと、リソース不足により Supervisor Cluster の有効化が失敗します。

ちなみに、メモリ容量はあとで削減可能です。（20GB くらいまでなら）

ポートグループは、先ほど選択したものを割り当てます。

vNIC の番号（ソースネットワーク）が降順表示になっているので注意します。

「Network 0」が、1つめの vNIC です。

つぎのように割り当てます。

• Network 3： pg-edge-uplink
• Network 2： pg-edge-uplink
• Network 1： pg-edge-uplink
• Network 0： pg-labmgmt-0010

「テンプレートのカスタマイズ」では、NSX Edge 固有のパラメータを入力します。

今回は、次のようにパラメータを入力します。

※これ以外のパラメータは、デフォルト値のままか、空欄のままです。

※ネットワーク関連のパラメータは、このラボのものなので環境にあわせて変更が必要です。

• System Root User Password： Edge のゲスト OS にログインする、root ユーザのパスワード。
• CLI “admin” User Password： Edge のゲスト OS にログインする、admin ユーザのパスワード。
• Manager IP： NSX Manager の IP アドレス（今回は admin）。
• Manager Password： NSX Manager の admin ユーザのパスワード。
• Manager Thumbprint： 冒頭の手順で確認した、NSX Manager の証明書サムプリント（64文字）

• Hostname： lab-nsx-edge-31
• Default IPv4 Gateway： 192.168.10.1
• Management Network IPv4 Address： 192.168.10.41
• Management Network Netmask： 255.255.255.0
• DNS Server list： スペース区切りで DNS アドレス。
• Domain Search List： go-lab.jp
• NTP Server List： スペース区切りで NTP アドレス。
• Enable SSH： On
• Allow root SSH logins： On

デプロイが完了したら、Edge VM をパワーオンします。

NSX Manager の

「システム」→「設定」→「ファブリック」→「ノード」を開きます。

そして、「Edge トランスポート ノード」にデプロイしたエッジが表示されます。

まだ NSX Edge の設定が必要な状態で、「設定の状態」には「!」マークが表示されます。

つづく・・・

vSphere with Kubernetes ラボ環境構築。Part-08: NSX Edge 設定編

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

今回は、前回デプロイした NSX Edge を、トランスポート ノードとして設定します。

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-07: NSX Edge デプロイ編

Edge 用 アップリンク プロファイルの作成。

NSX Edge は、以前に設定した ESXi とは NIC 数やチーミング ポリシー、

TEP の接続するネットワーク（VLAN ID）が異なったりするので、

別のアップリンク プロファイルを追加作成します。

※ただし、今回の構成では ESXi の TEP / Edge の TEP 両方が 同じ VLAN です。

NSX Manager にログインして、

「システム」→「設定」→「ファブリック」→「プロファイル」を開きます。

そして、「アップリンク プロファイル」タブの「追加」から、

「アップリンク プロファイルの作成」を開いて、設定値を入力していきます。

アップリンク プロファイルの名前は「uplink-profile-edge」にしています。

そのまま下にスクロールして、「デフォルトのチーミング」に、アップリンクの名前を入力します。

• アクティブ アップリンク： uplink-1
• スタンバイ アップリンク： 空欄のまま（Edge VM は、仮想スイッチ / ポートグループ側でのチーミングとなるので）

のこりは、次のような設定にしています。

• トランスポート VLAN： 71
• MTU： 空欄のまま。（vDS 側で設定するため）

Edge 用のアップリンク プロファイルが作成されました。

Edge トランスポート ノードの設定。

NSX Edge の、トランスポート ノードとしての設定をすすめます。

「システム」→「設定」→「ファブリック」→「ノード」→「Edge トランスポート ノード」を開きます。

デプロイずみの NSX Edge（lab-nsx-edge-31）の「NSX の設定」をクリックします。

「Edge トランスポート ノードの編集」で、

「ノード スイッチの作成」についてパラメータを入力していきます。

• Edge スイッチ名： （デフォルトのまま）nvds1
• トランスポート ゾーン： nsx-overlay-transportzone、nsx-vlan-transportzone
  （ESXi とは異なり、オーバーレイ と VLAN 両方のトランスポート ゾーンを選択します）

少し下にスクロールし、次のように入力して「保存」をクリックします。

• アップリンク プロファイル： uplink-profile-edge
• IP の割り当て： IP プールを使用
• IP プール： ip-pool-tep
• チーミング ポリシー スイッチ マッピング → uplink-1： fp-eth0 （Edge VM の 2つめの vNIC にあたります）

少し待って、画面下の「更新」をクリックすると、

設定の状態が「成功」になるはずです。

Edge クラスタの作成。

NSX の Edge トランスポート ノードは、「Edge クラスタ」単位で管理します。

通常は複数台の Edge トランスポート ノードを用意して Edge クラスタを構成します。

このラボは、ハードウェア リソースの都合もあり 1台だけです。

しかし NSX-T では、 Edge クラスタを構成する必要があるので、

Edge トランスポート ノードが 1台だけの Edge クラスタを作成しておきます。

「システム」→「設定」→「ファブリック」→「ノード」→「Edge クラスタ」を開きます。

「追加」をクリックして「Edge クラスタの追加」を開き、

次のようにパラメータを入力して、「追加」をクリックします。

• 名前： edge-cluster-01
• Edge クラスタ プロファイル： デフォルトのまま
• トランスポート ノード： デフォルトのまま
• 選択済み： lab-nsx-edge-31（対象の Edge ノードを選択して「>」ボタンで移動する）

これで、Edge クラスタが作成されます。

まだまだ続く。

引き続き、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

今回は、NSX の Tier-0 ゲートウェイを作成します。

前回はこちら。

vSphere with Kubernetes ラボ環境構築。Part-08: NSX Edge 設定編

ここでは、Supervisor Cluster を有効化する前提として必要な

NSX-T によるネットワークを作成しておきます。

VLAN セグメントの作成。

Tier-0 ゲートウェイのアップリンク インターフェースを接続する

VLAN セグメントを作成しておきます。

これは、NSX Edge から NSX 外部のネットワークに接続する VLAN になります。

NSX Manager にログインして、

「ネットワーク」→「接続」→「セグメント」を開きます。

「セグメント」タブの「セグメントの追加」をクリックして、パラメータを入力していきます。

パラメータは、今回のラボ環境にわせて下記のようにしています。

• セグメント名： seg-vlan0070
• 接続： なし（デフォルトのまま）
• トランスポート ゾーン： nsx-vlan-transportzone
• VLAN： 70

少し下にスクロールして、「保存」をクリックします。

「この Segment の設定を続行しますか？」を「いいえ」で抜けると、

VLAN セグメントが作成されたことが確認できます。

Tier-0 ゲートウェイの作成。

「ネットワーク」→「接続」→「Tier-0 ゲートウェイ」を開き、

「ゲートウェイの追加」→「Tier-0」をクリックします。

つぎのようにパラメータを入力して、「保存」をクリックします。

• Tier-0 ゲートウェイの名前：
• HA モード： アクティブ/スタンバイ
• Edge クラスタ： edge-cluster-01

「この Tier-0 ゲートウェイの設定を続行しますか？」では、

「はい」を選択して、つづけてインターフェースの追加を実施します。

Edge の外部インターフェイスの追加。

NSX Edge のアップリンクにあたる、「外部インターフェイス」を作成します。

「インターフェイス」→「設定」をクリックします。

「インターフェイスの追加」をクリックし、パラメータを入力してから「保存」をクリックします。

• 名前： if-uplink-01
• タイプ： 外部（デフォルトのまま）
• IP アドレス/マスク： 192.168.70.2/24
• 接続先： seg-vlan0070
• Edge ノード： lab-nsx-edge-31

インターフェイスが作成されたこと確認して、「閉じる」をクリックします。

スタティック ルートの設定。

このラボでは、ルーティング プロトコル（BGP）を利用していないので、

NSX 外部のネットワークと Edge のアップリンク ネットワーク

（この直前に作成したインターフェイスの接続されているネットワーク）とでルーティングが必要になります。

そこで、今回はスタティック ルート設定しています。

まだ編集途中の Tier-0 ゲートウェイの画面で

「ルーティング」→「スタティック ルート」のとなりの「設定」をクリックします。

「スタティック ルートの追加」をクリックして、

次のようなパラメータを入力して「ネクスト ホップの設定」をクリックします。

• 名前： default-route
• ネットワーク： 0.0.0.0/0

「ネクスト ホップの追加」をクリックして、

IP アドレスを入力（このラボ環境では 192.168.70.1）入力してから

「追加」→「適用」をクリックして閉じます。

「ホップ数: 1」と表示されたことを確認してから、

「保存」→「閉じる」をクリックします。

スタティック ルートに「1」と表示されたことを確認して、

「編集を終了」をクリックします。

Edge のアップリンク インターフェイスへの疎通確認。

これで、NSX-T の Tier-0 ゲートウェイとそのアップリンク インターフェイスが作成できたので、

直近で作成したインターフェイス（192.168.70.2）の疎通確認をしておきます。

たとえば、最終的に Kubernetes 環境を構築したあとで、

kubectl（kubernetes のクライアント ツール）を実行する想定の端末から

ping 確認などをしておきます。

つづく！

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

ひきつづき、vSphere with Kubernetes を体験するためのラボ環境構築をしていきます。

これまでは、前提環境をととのえるための準備でしたが、

今回は、Supervisor Cluster を有効化します。

前回の投稿はこちら。

vSphere with Kubernetes ラボ環境構築。Part-09: Tier-0 ゲートウェイ作成編

Supervisor Cluster の有効化。

Supervisor Cluster は、vSphere Client の「ワークロード管理」から有効化します。

（むしろ「ワークロード管理」を有効化します）

vSphere Client で、「ワークロード管理」メニューを開きます。

「ワークロード管理」で、「有効化」をクリックします。

これまでの準備により「互換性あり」に vSphere Cluster が表示されるはずなので、

「wcp-cluster-01」を選択して「次へ」をクリックします。

制御プレーンのサイズ（Supervisor Control Plane VM のスペック）を選択します。

今回はハードウェア リソースの都合上「極小」を選択しています。

ネットワークの設定をします。

管理ネットワークは、次のようなパラメータを入力しています。

• ネットワーク： DPortGroup-labmgmt-0010
  • vCenter などと通信できる、管理ネットワークのポートグループを指定する。
  • Supervisor Control Plane VM の 1つめの vNIC に割り当てられる。
• 開始 IP アドレス： 192.168.10.51
  • Supervisor Control Plane VM に付与される IP アドレス。
  • 開始 IP アドレスから 5つ消費する。
    • Supervisor Control Plane VM の Floating IP アドレス。（1つ。開始 IP アドレスが使用される）
    • Supervisor Control Plane VM 3台の IP アドレス。3つ。今回は .52 ～ .54）
    • アップグレード時の予約。（1つ。今回は .55）
• サブネットマスク： 255.255.255.0（「開始 IP アドレス」のネットワークでのサブネット マスク）
• ゲートウェイ： 192.168.10.1（「開始 IP アドレス」のネットワークでのサブネット マスク）
• DNS サーバ： （カンマ区切りで DNS サーバを指定）
• DNS 検索ドメイン： go-lab.jp
• NTP サーバ： （カンマ区切りで DNS サーバを指定）

下にスクロールし、

ワークロード ネットワークは、次のようなパラメータを入力しています。

• vSphere Distributed Switch： DSwitch
• Edge クラスタ： edge-cluster-01
• API サーバのエンドポイント FQDN： lab-wcp-01.go-lab.jp
  • Supervisor Control Plane VM の Floating IP にアクセスすると、
    ここで指定した名前が証明書 Subject Alternative Name に設定されていたりする。
• DNS サーバ： （カンマ区切りで DNS サーバを指定）
• ポッド CIDR： 10.244.0.0/21（デフォルトのまま）
  • Pod のネットワークが、このレンジから払い出される。
• サービス CIDR： 10.96.0.0/24（デフォルトのまま）
  • Kubernetes 内部通信の ClusterIP で利用される。
• 入力方向 CIDR：192.168.70.32/27
  • Tier-0 ゲートウェイの外部インターフェイス（Edge のアップリンク）と同セグメントから、/27 以上のレンジを指定する。
  • NSX ロードバランサによる VIP に払い出される。
  • Supervisor Control Plane VM の VIP は、この CIDR の最初の IP アドレス（192.168.70.33）になる。
• 出力方向 CIDR： 192.168.70.64/27
  • Tier-0 ゲートウェイの外部インターフェイス（Edge のアップリンク）と同セグメントから、/27 以上のレンジを指定する。
  • NSX では SNAT で利用される。

ストレージでは、下記の 3つのデータストアを指定するため、

仮想マシン ストレージ ポリシーを指定します。

ここでは、以前の投稿で作成した「vm-storage-policy-wcp」を指定しています。

• 制御プレーン ノード（Supervisor Control Plane VM の VMDK を配置するデータストア）
• 短期ディスク（vSphere Pod で利用するデータストア）
• イメージ キャッシュ（コンテナ イメージのキャッシュ）

設定値を確認して「完了」をクリックすると、Supervisor Cluster の有効化がはじまります。

「クラスタ」タブで、構成ステータスが確認できます。

開始直後、「最近のタスク」にリモートファイルのダウンロードで 404 エラーが表示されますが、これは無視します。

Supervisor Control Plane VM が自動的にデプロイされます。

ちなみに、ESXi が 4台以上あるクラスタでも、Control Plane VM は 3台です。

有効化処理がうまくいかない場合は、vCenter に root ユーザでログインして、

まず下記のログを確認してみるとよいと思います。

• ログファイル： /var/log/vmware/wcp/wcpsvc.log

しばらく（数十分 ～ 数時間）待つと、「構成ステータス」が「実行中」になり、

「制御プレーン ノード」の IP アドレスが、最終的に「入力方向 CIDR」で指定したレンジの IP アドレスになります。

「現在のバージョン」には、Supervisor Cluster の Kubernetes バージョンが表示されています。

これで wcp-cluster-01 クラスタで、Supervisor Cluster の機能が有効化されました。

名前空間の作成。

「ワークロード管理」メニューの「名前空間」タブを開くと、

「名前空間の作成」が表示されるので、クリックします。

クラスタを選択して、名前空間の名前（ここでは lab-ns-01）を入力して「作成」をクリックします。

名前空間が作成されました。

「ステータス」→「CLI ツールへのリンク」にある、「開く」をクリックします。

【10-32】

「Kubernetes CLI Tools」という、

専用 kubectl のダウンロード ページが表示されるはずです。

これでひとまず、vSphere with Kubernetes を体験するためのラボ環境が構築できました。

このページが表示されていない場合は、Supervisor Cluster の有効化が成功していても

NSX-T や物理ネットワークなどの構成がうまくできていない可能性があります。

以上、vSphere 7.0 ＋ NSX-T 3.0 で Supervisor Cluster の有効化でした。

おそらくつづく。

Microsoft Teams On VMware Virtual Infrastructure Platform:

Recently we observe many organizations are slowly migrating from Skype For Business to Microsoft Teams. There are two types of Microsoft Teams installation:

• Per-User Mode: For scenarios, where we have persistent VDIs, then we will go with Per-User mode.
• Per Machine Mode: For scenarios, where we have non-persistent VDIs, then we will go with Per-Desktop mode. So, it allows the user setup individually while on session.

In this article we discuss about capturing Microsoft Teams on appstack or placing them on master image on VDI infrastructure. Also we discuss about Roaming Credentials through DEM.

Pre-Requisites:

• If machine already have teams installed, please uninstall the teams.
• Download the MSI from: https://docs.microsoft.com/en-us/microsoftteams/msi-deployment [ Consumer ]

Scenario 1: Microsoft Teams on VMware VDI non persistent desktop: {for this scenario as per Microsoft, we need to use Per-Machine mode installation type}

• Power on parent / master Image.
• Once the VM is powered on,
• Create a folder called teams on C: drive
• Copy the msi to C:\Teams folder. [ Optional ]
• Open elevated command prompt and run below command:

msiexec /i "C:\Teams\Teams_windows_x64.msi" /l*v "C:\Teams\Teams.txt" ALLUSER=1 ALLUSERS=1

• You will see a Microsoft Teams banner which says Installing Teams for around 10 – 15 seconds.

• Once the installation is complete, do not launch the application. You will see a shortcut on desktop, and you can see Teams Machine Wide installer on control panel add or remove programs

• Shutdown the VM take a snapshot and publish or recompose the pool with this snapshot.

Scenario 2: Microsoft Teams On Appstack: [ Per-Machine mode ]

• Open App Volumes UI create application and package for Microsoft Teams.
• Revert the snapshot on capture VM, power on the VM.
• Click on Package on app volume and select the capture VM.
• While you are on provisioning mode.
• Run the command to install MS teams:

msiexec /i "C:\Teams\Teams_windows_x64.msi" /l*v "C:\Teams\Teams.txt" ALLUSER=1 ALLUSERS=1

• Complete the provisioning, reboot the desktop.
• Assign the Teams package to user group or to a user.

Note: Do not keep more than one instance of Microsoft teams on a particular machine. Example, having MS team package attachment on VM which has MS teams natively installed. This is  not supported.

Capturing MS teams credentials on DEM:

• Download the Teams.zip file and extract the files at: \\SHARE\DEMConfiguration\general\application
• Then open DEM management console and click on refresh tree.
• Ensure we have IEPassword config file is enabled along with this to roam the credentials.

Note: Do not use the Teams configuration which comes with default template. That contains directlex path as %localappdata%\Microsoft\teams\update.exe. This is not the correct directflexpath for machine mode MS Teams. If you want to enable directflex, then path would be: C:\Program Files(x86)\Microsoft\Teams\current\Teams.exe

Attached zip file is new version of Teams config file.

本記事ではVxRailのESXi Imageに目的のFixが含まれているかを確認します。

VxRail の ESXi ImageとVMwareのESXi Imageの差異について

VxRailには、ESXiのImageが含まれています。

しかしながら、VxRailのESXi ImageはVMwareから公開されているESXi Imageと必ず同じとは限らず、微妙に差異がある場合があります。

では、不具合などのFixを確実に適用したい場合はどうしたらよいでしょうか。

目的のFixが含まれているかを確認する方法

目的のFixが含まれていることを確認するもっとも簡単な方法は、VxRailのRelease Noteを見ることです。

重要なSecurity FixなどはReleaseNoteに記載されていることが多いため、容易に確認が可能です。

ただしすべてのFixがReleaseNoteに記載されるわけではありませんので、記載のないものについては個別に確認する必要があります。

ESXiのImageはZipで固められているので、その中身をみて個別のFixが入っていることを確認するのが一番確実です。

具体的な手順

ここでは、以下で報告されているSecurity FixがVxRail 4.7.510に含まれているかどうかを確認する手順を例にとって説明します。

DSA-2020-118: Dell EMC VxRail Appliance Security Update for Third Party Component Vulnerability in VMware ESXi

https://support.emc.com/kb/543403

VMSA-2020-0008

https://www.vmware.com/security/advisories/VMSA-2020-0008.html

上記のFixはVxRailのReleaseNoteを見るとVxRail 4.7.510に含まれている旨の記載があります。

Release-Notes 4.7

https://support.emc.com/docu91467_VxRail-Appliance-Software-4.7.x-Release-Notes.pdf

本当に含まれているかを、VxRailのUpgradeファイル内のESXi Imageを展開して確認してみましょう。

VMSA-2020-0008 によると、ESXi 6.7でのFixed Versionは、ESXi670-202004103-SG

だとあります。

My VMwareのProduct Patchから、このFixはESXi670-202004002 に含まれていることがわかります。

ESXi670-202004002のリリースノートを見てみると以下の記載があります。

つまり、VMware_bootbank_esx-ui_1.33.7-15803439のVIBがVxRail 4.7.510のESXi Imageに含まれていればよい、ということになります。

では、実際にVxRail 4.7.510のUpgradeファイルをダウンロードして中身を確認しましょう。

https://dl.dell.com/downloads/DL98593_VxRail-4.7.510-Composite-Upgrade-Package-for-4.7.x.zip

こちらのZIPを確認すると、以下のようなディレクトリ構造が見えますので、bundles → ESXi-xxx.zip と辿ってESXi Imageを入手します。

このESXi-xxx.zipを解凍するとさらにディレクトリ構造がありますので、metadata.zipをさらに解凍します。

metadata.zipに含まれる、vmware.xmlファイルを開きます。

このファイルの中で先ほど調べたVIB(VMware_bootbank_esx-ui_1.33.7-15803439)を検索します。

対象のVIBが確認できましたのでこのVersionには問題なくFixが含まれていることを確認できました。

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」を作成してあります。

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

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

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

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

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

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

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

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

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 が作成、起動されています。

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 が仮想マシンとして起動されているためです。

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 によるネットワークが自動的に設定変更されます。（これについては別途・・・）

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 を起動してみる話でした。