Legacy User Blogs articles

Virtualization - help!

Kip5 — Wed, 29 Mar 2023 18:56:41 GMT

Computer support provider sold me a high spec pc with VMware installed to enable me to use legacy XP software. His 'solution' has never worked succesfully from day one and has caused major problems I never had before with e.g. MS Office 365. He finally admitted the pc he supplied is unstable, has since fled and left me in the lurch big time.

I'm based in London (E6) and would appreciate a steer to finding someone who can assess / advise on recovering from the mess he's left me in.

Thx

VMware Fusion - Mouse Clicks not recognized in version 12

jamescpa — Thu, 19 Jan 2023 21:53:00 GMT

Updated McBook to Catalina and Fusion to versions 12. Track Pad Clicks are not recognized

vCenter 7.0 installation stuck at 80% (Waiting for RPM...)

marcelo_soares — Fri, 30 Oct 2020 11:06:00 GMT

I was trying to install a vCenter for a lab on top of a ESXi 6.7 using the FREE license. Have verified several things:

- NTP was in place

- DNS records all good

- Enough resources

- Etc...

I realized that when using the FREE license on the ESXi hosting the vCenter appliance, seems that the installer can´t set the IP of the VCSA remotely using the OVA features. I just added a trial license back to the ESX and the installation worked.

I could not find any documentation on this: Software Requirements for the vCenter Server Appliance

Hope this helps,

Marcelo

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

gowatana — Thu, 29 Oct 2020 14:33:44 GMT

vSphere with Tanzu にて、NSX-T なしでの Tanzu Kubernetes クラスタのラボを構築していきます。

今回は、スーパーバイザークラスタに名前空間と、Tanzu Kubernetes クラスタ（TKC）を作成します。

前回はこちら。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理有効化編

TKC の作成は、基本的に vSphere 7.0 の頃と変わらないので、

主に以前の投稿へのリンクと、その補足をお伝えします。

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

前回の作業で、vSphere クラスタで「ワークロード管理」が有効化されています。

vSphere Client で「メニュー」→「ワークロード管理」→「クラスタ」を開くと、

「構成ステータス」が「実行中」になっています。

「制御プレーンノード」に表示されている IP アドレスは、

「プライマリ」ワークロードネットワーク（network-1）で指定した IP 範囲のうち、

最初の IP アドレスが割り当てられているはずです。

制御プレーンの IP アドレス（この環境では 192.168.21.128）は、

Kubernetes を操作するクライアント（kubectl）の接続先になります。

また、kubectl（と vSphere 接続用のプラグイン）のダウンロードサイトも提供されます。

ネットワーク構成と、HAProxy デプロイとワークロード管理の有効化で指定した IP レンジが間違っていなければ、

下記のページを表示することができるはずです。

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

vSphere with Tanzu での Tanzu Kubernetes クラスタは、

NSX-T の利用の有無にかかわらず、スーパーバイザー名前空間に作成します。

そこで、まずスーパーバイザー名前空間を作成しておきます。

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

名前空間の情報を入力して「作成」をクリックします。

今回は下記のように入力しています。

クラスタ： wcp-cluster-04
名前： lab-ns-41
ネットワーク： network-2
- プライマリネットワーク（network-1）も選択できるはずです。
- 今回は、ラボ構成の都合上 2つめのワークロードネットワークを選択しています。

名前空間が作成されました。

はじめに表示されていう説明は、閉じてしまってかまいません。

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

権限の追加

「権限の追加」では、vCenter Single Sign-on に登録された ID ソースのユーザー / グループに対して、

名前空間への権限（表示可能または編集可能）を追加できます。

ID ソースには vCenter 組み込みのディレクトリが持つドメイン（デフォルトは vsphere.local）、

Active Directory、LDAP サーバなどが利用できます。

しかし今回は vCenter に ID ソースを追加登録していないので、権限の追加は省略します。

そして、この後のスーパーバイザークラスタへの接続では、

デフォルトの vCenter 管理ユーザ（administrator@vsphere.local）を使用してしまいます。

ストレージの追加

ストレージの追加では、データストアのレイアウトを決定できる「仮想マシンストレージポリシー」を選択します。

このポリシーは、ワークロード管理の有効化（前回の投稿）で指定したものが利用できます。

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

ポリシーを選択します。

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

これにより、スーパーバイザークラスタで vSphere のデータストアを利用するための

StorageClass、ResourceQuota リソースが作成されます。

（のちのど）kubectl でスーパーバイザークラスタに接続した際に、下記のようなリソースが確認できるはずです。

StorageClass の名前は、ストレージポリシーの名前から自動生成されます。

$ kubectl get storageclasses
NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
vm-storage-policy-wcp   csi.vsphere.vmware.com   Delete          Immediate           true                   3d
$ kubectl get resourcequotas
NAME                     AGE   REQUEST                                                                                     LIMIT
lab-ns-41-storagequota   3d    vm-storage-policy-wcp.storageclass.storage.k8s.io/requests.storage: 0/9223372036854775807

スーパーバイザークラスタ / 名前空間への接続。

kubectl を入手して、スーパーバイザークラスタに接続し、使用する名前空間を選択します。

接続方法は、vSphere 7.0 の頃と同様なので、下記の投稿を参考にしてください。

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

ただし、vSphere Networking を利用する（NSX-T がない）構成のため、vSphere Pod を起動することはできません。

そのため、スーパーバイザー名前空間で Pod を起動しようとするとエラーになります。

$ kubectl run --image=centos:7 --generator=run-pod/v1 pod-01
Flag --generator has been deprecated, has no effect and will be removed in the future.
Error from server (workload management cluster uses vSphere Networking, which does not support action on kind Pod): admission webhook "default.validating.license.supervisor.vmware.com" denied the request: workload management cluster uses vSphere Networking, which does not support action on kind Pod

Tanzu Kubernetes クラスタ（TKC）の作成。

TKC は「Cluster API」を利用しており、マニフェスト（YAML 形式の定義）で Kubernetes クラスタを作成できます。

TKC 作成も vSphere 7.0 の頃と同様です。下記の投稿も参考にして下さい。

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

Pod の接続されるネットワークに変更があり、

デフォルトの CNI が、Calico から Antrea になりました。

今回は下記のような YAML ファイルで、TKC を作成してみます。

Kubernetes のバージョン： v1.18.5
- これは、コンテンツライブラリ（今回は cl-tkg-01）にある OVF テンプレートの名前から、利用可能なバージョンが分かります。
- バージョンは、完全な文字列（v1.18.5+vmware.1-tkg.1.c40d30d）や省略（v1.18）での指定も可能です。
制御プレーン（controlPlane）ノード数： 1
ワーカー（workers）ノード数： 1
制御プレーン / ワーカーノードのスペック（class）： best-effort-xsmall
- ラボなのでリソースの少ないものを指定しています。
CNI： Antrea を使用。
- 今回は、あえて「antrea」を指定しています。他に「calico」が指定できます。
- services / pods ネットワークで使用するネットワーク（CIDR 表記）は、省略もできますが、
  デフォルトの CIDR が今回のラボ構成にあっていなかったので指定しています。

tanzu-cluster-41.yml · GitHub

---
kind: TanzuKubernetesCluster
apiVersion: run.tanzu.vmware.com/v1alpha1
metadata:
name: tanzu-cluster-41
spec:
distribution:
    version: v1.18.5
topology:
    controlPlane:
      count: 1
      class: best-effort-xsmall
      storageClass: vm-storage-policy-wcp
    workers:
      count: 1
      class: best-effort-xsmall
      storageClass: vm-storage-policy-wcp
settings:
    network:
      cni:
        name: antrea
      services:
        cidrBlocks: ["10.21.0.0/16"]
      pods:
        cidrBlocks: ["10.22.0.0/16"]

kubectl で、スーパーバイザークラスタに接続して、

スーパーバイザー名前空間「lab-ns-41」を使用するコンテキストに切り替えておきます。

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.21.129
$ kubectl config use-context lab-ns-41

現在のコンテキストは、下記のように確認できます。

$ kubectl config current-context
lab-ns-41

YAML ファイルを指定して、TKC を作成します。

$ kubectl apply -f tanzu-cluster-41.yml
tanzukubernetescluster.run.tanzu.vmware.com/tanzu-cluster-41 created

自動的に Kubernetes ノードとなる VM がデプロイされていきます。

kubectl で、VM のデプロイ処理が開始されたことが確認できます。

$ kubectl get machine
NAME                                              PROVIDERID   PHASE
tanzu-cluster-41-control-plane-cpl82                           Provisioning
tanzu-cluster-41-workers-54xhz-764f586457-f2mk8                Pending

vSphere Client でも、VM がデプロイされる様子が見られます。

しばらく待つと、YAML で定義した台数の制御プレーンノード、ワーカーノードの VM が起動され、

Kubernetes クラスタが作成された状態になります。

kubectl でも、最終的にすべての Machine が Running になるはずです。

$ kubectl get machine
NAME                                              PROVIDERID                                       PHASE
tanzu-cluster-41-control-plane-pmrcw              vsphere://420c5f79-20b4-6e57-6cc8-bd079195e5aa   Running
tanzu-cluster-41-workers-7mbf2-544d847df6-hh6nz   vsphere://420c69bf-89a9-9697-4b10-66d7dbdf3012   Running

名前空間の「コンピューティング」→「Tanzu Kubernetes」でも

Tanzu Kubernetes クラスタの情報が確認できます。

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

「tanzu-cluster-41-control-plane-service」が、HAProxy の VIP レンジから払い出されていることが分かります。

$ kubectl get service -n lab-ns-41
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
tanzu-cluster-41-control-plane-service LoadBalancer 10.96.0.79 192.168.21.129 6443:31848/TCP 1d2h

ちなみに、TKC で「type: LoadBalancer」の Service リソースを作成した場合も、この名前空間で、同じレンジから VIP が払い出されます。

たとえば、TKC の中で「tkc-ns-01」という名前空間を作成して、そこで LoadBalancer を作成すると下記のようになります。

（HAProxy による VIP 192.168.21.131 が提供されている様子です）

$ kubectl get service --context tanzu-cluster-41 -n tkc-ns-01
NAME        TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
web-svc-a   LoadBalancer   10.21.172.149   192.168.21.131   80:32456/TCP   3d1h
$ kubectl get service --context lab-ns-41 -n lab-ns-41
NAME                                     TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)          AGE
tanzu-cluster-41-24f36e6c691ea3608647d   LoadBalancer   10.96.0.102   192.168.21.131   80:32012/TCP     3d1h
tanzu-cluster-41-control-plane-service   LoadBalancer   10.96.0.79    192.168.21.129   6443:31848/TCP   3d2h

TKC への接続 / Pod 起動。

TKC への接続や、Pod などのリソース管理も、vSphere 7.0 の頃と同様です。

下記を参考にしてください。

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

vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編

Tanzu Kubernetes Cluster への接続。（実験編）

一連の流れをとおして vSphere 7.0 の頃と同じ手順がほとんどですが、

実際に環境構築してみても、事前準備とネットワーク構成では以前より省略できる部分が多い印象を受けました。

vSphere 環境での Kubernetes 利用について、ハードルが下がったのではないかと思います。

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

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理有効化編

gowatana — Wed, 28 Oct 2020 15:15:00 GMT

vSphere with Tanzu にて、NSX-T なしでの Tanzu Kubernetes クラスタのラボを構築していきます。

今回は、vSphere クラスタで「ワークロード管理」を有効化して、スーパーバイザークラスタにします。

前回はこちら。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-02 HAProxy デプロイ編

それでは、ひたすらウィザードを進めていきます。

vSphere Client で、「メニュー」→「ワークロード管理」を開きます。

初回は、ライセンス入力、または評価版として利用する人の情報を入力する画面が表示されます。

今回は評価版として利用するので、情報を入力して「開始する」をクリックします。

「vCenter Server とネットワーク」で、vCenter と、ネットワークスタックオプションを選択します。

「NSX-T」または「vCenter Server Network」が選択できるので、

今回は「 vCenter Server Network」を選択して「次へ」をクリックします。

「ワークロード管理」を有効化するクラスタを選択して、「次へ」をクリックします。

制御プレーンのサイズ（自動展開される Supervisor Control Plane VM のサイズ）を選択します。

ラボ環境なので「極小」を選択して「次へ」をクリックします。

制御プレーンノード（Supervisor Control Plane VM）に割り当てる、

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

下記のようなロードバランサ（HAProxy）のパラメータを入力して、「次へ」をクリックします。

名前：今回は HAProxy VM のホスト名と合わせてあります。
タイプ：「HA プロキシ」（つまり HAProxy）のみ選択できます。
データプレーン API のアドレス： HAProxy VM のネットワークアダプター 1 に指定した IP アドレスとポートを指定します。
- 今回の環境では、192.168.10.80:5556 にしています。
ユーザー名 / パスワード： HAProxy VM デプロイ時に入力したものを、ここでも入力します。
仮想サーバの IP アドレス範囲：ロードバランサが払い出す VIP アドレスのレンジを指定します。
- VIP は下記に払い出されます。（他にもあるかもしれません）
  - スーパーバイザークラスタの制御プレーン
  - Tanzu Kubernetes クラスタの制御プレーン
  - Tanzu Kubernetes クラスタの Service（Type: LoadBalancer）リソース
- ワークロードネットワーク（1つめ）からレンジを指定します。
  - このレンジは、HAProxy VM デプロイ時に「Load Balancer IP Range」で指定したレンジから指定します。

この環境では Load Balancer IP Range を 192.168.21.128/25（192.168.21.128 ～ .254）にしてあるので、
そこから 192.168.21.128-192.168.21.191 を指定しています。（残りアドレスはは何かしらの予備としてます）
ちなみに、192.168.21.128/25 のネットワークの場合、192.168.21.128 はネットワークを表すアドレスになります。
しかし今回は IP レンジとして CIDR 表記を用いているだけのようで、.128 も VIP として利用できました。

サーバ認証局： HAProxy VM で自動生成された CA 証明書を入力します。
- これは、前回投稿の最後に取得した「-----BEGIN CERTIFICATE-----」～「-----END CERTIFICATE-----」の文字列を、そのまま入力します。

管理ネットワークのパラメータを入力します。

ネットワーク：管理ネットワークにあたる、分散ポートグループを選択します。
開始 IP アドレス： Supervisor Control Plane VM に割り当てられる IP アドレスで、ここから 5つ採番されます。
- 今回は 192.168.10.81 を入力したので、192.168.10.81 ～ 192.168.10.81 が採番されます。
  - 192.168.10.81 → フローティング IP アドレス。
  - 192.168.10.82 ～ 192.168.10.84 → Supervisor Control Plane VM（3 VM）の、ネットワークアダプター 1 に設定される。
  - 192.168.10.85 → アップグレード時に使用される（とのこと）

下記についても入力します。（これは一般的なパラメータなので説明省略）

サブネットマスク
ゲートウェイ
DNS サーバ
DNS 検索ドメイン
NTP サーバ

パラメータを入力したら「次へ」をクリックします。

ワークロードネットワークのパラメータを入力していきます。

サービスの IP アドレス：
- 今回はデフォルトのまま 10.96.0.0/24 を利用します。
DNS サーバ：ここでも DNS サーバのアドレスを入力します。

入力したら、「追加」をクリックして、ワークロードネットワークを作成します。

ワークロードネットワークは、最小構成では 1つだけ必要です。

ただし、今回はラボ構成の都合上、2つ作成します。

まず 1つめのワークロードネットワークを作成します。

これは、「スーパーバイザークラスタのプライマリネットワーク」となり、

制御プレーンのネットワークアダプター 2 が接続されます。

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

名前：今回はデフォルトのまま network-1 です。
ポートグループ：事前作成しておいた分散ポートグループを選択します。
ゲートウェイ：ワークロードネットワーク（1つめ）のデフォルトゲートウェイを入力します。
サブネット：ワークロードネットワーク（1つめ）のサブネットマスクを入力します。
IP アドレス範囲：
- ワークロードネットワークのサブネットから、他のサーバや HAProxy の「Load Balancer IP Range」と重ならないレンジを指定します。
- 今回は、192.168.21.11-192.168.21.79 にしてあります。
  これは下記に採番されるくらいのようなので、今回の構成では実際にはもっと少なくても IP アドレスは足りそうです。
  - Supervisor Control Plane VM（3 VM）のネットワークアダプター 2

同様に、2つめのワークロードネットワークも追加します。

これは、あとでスーパーバイザー名前空間を作成する際に選択することになります。

名前：今回はデフォルトのまま network-2 です。
ポートグループ：事前作成しておいた分散ポートグループを選択します。
ゲートウェイ：ワークロードネットワーク（2つめ）のデフォルトゲートウェイを入力します。
サブネット：ワークロードネットワーク（2つめ）のサブネットマスクを入力します。
IP アドレス範囲：
- 今回は、192.168.21.11-192.168.21.200 にしてあります。
- このレンジから、下記の IP アドレスが採番されます。（空いているので、余裕のあるレンジ指定にしています）
  - Tanzu Kubernetes クラスタの制御プレーンノード
  - Tanzu Kubernetes クラスタのワーカーノード

結果として下記のように、ワークロードネットワークを 2つ作成したら「次へ」をクリックします。

「TKG 構成」では、事前に作成した Tanzu Kubernetes Grid のコンテンツライブラリ（今回は cl-tkg-01）を選択して「次へ」をクリックします。

「完了」をクリックすると、「ワークロード管理」の有効化が開始されます。

しばらく待ちます・・・

処理の途中ではエラーが発生しますが、自動的にリトライされたりするのでいったんは静観します。

クラスタでは、Namespaces リソースプールが自動作成され、

Supervisor Control Plane VM が自動デプロイされます。

ステータスが「実行中」になったら、処理完了です。

つづく・・・

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

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-02 HAProxy デプロイ編

gowatana — Tue, 27 Oct 2020 14:29:21 GMT

vSphere with Tanzu にて、NSX-T なしでの Tanzu Kubernetes クラスタのラボを構築していきます。

今回は、NSX-T によるロードバランサーの代わりとなる、HAProxy 仮想アプライアンスをデプロイします。

前回はこちら。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-01 事前準備編

HAProxy 仮想アプライアンスについて。

HAProxy の仮想アプライアンス（.ova ファイル）のダウンロードサイトは、

KB などでも案内されていますが、MyVMware ではありません。

Where to find HA Proxy OVA Image and Configuration Requirements for vSphere with Tanzu (80735)

https://kb.vmware.com/s/article/80735

HAProxy Technologies の GitHub ページからダウンロードできます。

今回は、vmware-haproxy-v0.1.8.ova ファイルをダウンロードして使用しています。

GitHub - haproxytech/vmware-haproxy

HAProxy のデプロイ。

HAProxy は、一般的な仮想アプライアンスと同様、vSphere Client などからデプロイします。

今回は、スーパーバイザークラスタにする（ワークロード管理を有効化する）クラスタの中に

HAProxy の .ova ファイルをデプロイします。

クラスタを右クリック →「OVF テンプレートのデプロイ」を開きます。

私のラボ環境だと、URL を直接指定すると失敗しやすいので、

vmware-haproxy-v0.1.8.ova ファイルをローカルにダウンロードしたうえで指定しています。

仮想マシン名とデータセンター（またはフォルダ）を指定して「次へ」。

クラスタ（またはリソースプール）を選択して「次へ」。

.ova ファイルの内容確認画面も「次へ」。

使用許諾契約書を読んで、チェックをいれて「次へ」。

ここから、HAProxy ならではのパラメータ指定がはじまります。

「デプロイ構成」では、「Default」と、「Frontend Netowrk」（を追加する構成）が選択できます。

今回はできるだけシンプルなラボ構成にしたいため、「Default」を選択しています。

今回は NFS データストアに、シンプロビジョニングでデプロイします。

容量はシステム要件に対してだいぶ少ない（200GB）ですが、ラボの構築は可能です。

ちなみに、すでに消費されている容量は Tanzu Kubernetes Grid のコンテンツライブラリによるものです。

「ネットワークの選択」では、事前作成してある分散ポートグループを選択します。

今回は「Default」構成のため、Frontend で選択したポートグループは無視されます。

そこで下記のように適当に選択しています。

Management： DPortGroup-0010-MGMT
Workload： DPortGroup-0021-WL1
Frontend：適当なポートグループ

「テンプレートのカスタマイズ」でパラメータを入力しつつ、下にスクロールしていきます。

OS の root ユーザのパスワードを入力します。
root ユーザでのログインを許可（Permit Root Login のチェックをオン）しておきます。
TLS 証明書のパラメータは、今回はデフォルトのまま空欄にしています。

そして画面を下にスクロール・・・

下記を入力して、下にスクロールします。

ホスト名
DNS サーバのアドレス（カンマ区切り）
Management IP
- HAProxy のネットワークアダプタ 1 に設定される。
- このあと「ワークロード管理」の有効化で、「データプレーン API のアドレス」として指定することになる。
Management Gateway
- Management IP のデフォルトゲートウェイ。

ワークロードネットワークのアドレスを入力して、下にスクロールします。

Workload IP
- HAProxy のネットワークアダプタ 2 に設定される。
- Kubernetes のワークロード（制御プレーンや Pod）が通信するネットワークの IP アドレス。
Workload Gateway
- ワークロードネットワークのゲートウェイ。

ロードバランサーの設定（Load Balancing）のパラメータを入力します。

Load Balancer IP Range
- Kubernetes の Load Balancer リソースによる VIP に払い出す IP アドレスのレンジを指定します。
- あとで「ワークロード管理」の有効化でも、このレンジに合わせたアドレス入力があります。
- このレンジの IP アドレスは、実際に VIP を払い出してなくても HAProxy が応答するようになってしまうので、
  他で利用している IP アドレスとは重ならないように指定します。
- 今回はワークロードネットワークとして 192.168.21.0/24 を用意しているので、
  このレンジでは 192.168.21.128/25（192.168.21.128 ～ .254 に応答するようになる）を指定します。
Dataplane API Management Port
- デフォルトのまま 5556。
HAProxy User ID
- デフォルトだと空欄なので、今回は「admin」。
HAProxy Password
- HAProxy User ID で入力したユーザの、パスワードを指定（2回入力）

パラメータを入力したら、「次へ」をクリックします。

確認画面が表示されるので、「完了」をクリックするとデプロイが開始されます。

HAProxy の起動。

デプロイ処理が完了したら、パワーオンします。

ちなみに「Default」構成のため Frontend として指定したポートグループは無視され、

ネットワークアダプタは 2つのみ作成されています。

VM 起動後は、ゲスト OS で自動的にネットワーク設定や HAProxy の設定は実行されます。

そのため少し待っておきます。

CA 証明書の取得。

このあとに実施する「ワークロード管理」の有効化で、

HAProxy 仮想アプライアンスで自動生成された CA 証明書が必要になります。

これは、VM の詳細設定から取得できます。

起動後の HAProxy VM で、右クリック →「設定の編集」を開きます。

「仮想マシンオプション」タブにある、「詳細」→「詳細設定」を開きます。

「構成パラメータ」画面が開くので、「guestinfo.dataplaneapi.cacert」の長い文字列を記録しておきます。

これが、Base64 エンコーディングされた CA 証明書です。

この長い文字列は、Linux であれば下記のように base64 -d コマンドで証明書にデコードできます。

$ echo "長い文字列" | base64 -d

Windows の PowerShell では、下記のようにデコードできます。

PS> $Base64cert = "長い文字列"
PS> [Text.Encoding]::Utf8.GetString([Convert]::FromBase64String($Base64cert.Value))

ちなみに、個人的には、vSphere with Tanzu Quick Start Guide | VMware を参考にして

下記のような PowerShell / PowerCLI スクリプトを用意して証明書を取得しています。

get_haproxy_vm_cacert.ps1 · GitHub

$VMname = $args[0]
$AdvancedSettingName = "guestinfo.dataplaneapi.cacert"
$Base64cert = Get-VM $VMname | Get-AdvancedSetting -Name $AdvancedSettingName
$cert = [Text.Encoding]::Utf8.GetString([Convert]::FromBase64String($Base64cert.Value))
$cert

下記のような感じで証明書が取得できます。

「-----BEGIN CERTIFICATE-----」～「-----END CERTIFICATE-----」の文字列を、

そのままこの後で入力することになります。

PS> Connect-VIServer lab-vc-04.go-lab.jp -Force
PS> .\get_haproxy_vm_cacert.ps1 lab-haproxy-41
-----BEGIN CERTIFICATE-----
MIIDoTCCAomgAwIBAgIJAL1hdYJhEykrMA0GCSqGSIb3DQEBBQUAMG4xCzAJBgNV
BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRIwEAYDVQQHDAlQYWxvIEFsdG8x
・・・
awIo/nyGgU48YiylWNyJKtjO7rJ01TLEoq6KSAzPw1Y/MMunJCeCAZqoS9X/2pUL
nF4DBb08fK97UpSBSaaHzugJEAIeiTXmGot4ScPegKJzOzM9zKzfjBu84b0FYoxM
S8HtOipnxBTPS3iGgCQ05OKP9pAqi7l1lliiHMS7VNJvzxYhtycY9O7Gu3qA6PKm
TQt7IUDi3+cr8RFuFY2TJ+3zRqTf
-----END CERTIFICATE-----

つづく！

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理有効化編

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-01 事前準備編

gowatana — Mon, 26 Oct 2020 15:33:29 GMT

vSphere 7.0 U1 リリースにあわせて、

vSphere with Kubernetes が vSphere with Tanzu になりました。

VMware vSphere with Tanzu リリースノート

そして、NSX-T なしでも Tanzu Kubernetes クラスタを作成できるようになったので、

さっそくラボ環境を構築してみました。

製品ドキュメントは下記です。

vSphere with Tanzu について

このうち、NSX-T ではなく vSphere ネットワーク（vDS）を利用する場合の要件は、

下記のあたりに説明があります。

vSphere ネットワークを使用してスーパーバイザークラスタを設定するためのシステム要件およびトポロジ

ドキュメント以外にも、まず動作する環境を用意したい場合は、

下記にある Quick Start Guide が参考になります。

https://core.vmware.com/resource/vsphere-tanzu-quick-start-guide

ちなみに、vSphere 7.0 GA 時点の時と同様に、NSX-T を利用した環境構築も可能です。

その様子についてはこちらもどうぞ。

vSphere 7.0 と 7.0 U1 での「ワークロード管理」有効化の違いについて。（NSX-T あり編）

手順の流れ。

今回は、下記のような流れで説明していきます。

前提とするラボ環境の説明。（vSphere 環境の構築については、今回は省略）
HAProxy のデプロイ。
「ワークロード管理」の有効化。
Tanzu Kubernetes クラスタの作成。

構成について。

ラボの構成イメージは、下記のような感じです。

「Ext GW」は各ネットワークのゲートウェイとなるルータです。

パラメータの事情説明などは、後続の手順にて・・・

vSphere Client での完成イメージは、下記のような感じです。

スーパーバイザークラスタの名前空間、Tanzu Kubernetes クラスタを作成します。

それぞれ、スクリーンショットでは下記の名前です。

スーパーバイザークラスタ： wcp-cluster-04
スーパーバイザー名前空間： lab-ns-41
Tanzu Kubernetes クラスタ： tanzu-cluster-41

今回の主なソフトウェア構成です。

vCenter Server 7.0 U1、仮想スイッチは vDS 7.0（NSX-T なし）
ESXi 7.0 U1
ロードバランサは HAProxy

前提環境の説明。

それでは、これからの vSphere with Tanzu 環境構築の前提とする、ラボ環境について説明します。

vSphere の構築については省略していますが、以前に紹介したものと同様にネステッド環境で構築しています。

vSphere with Kubernetes ラボ環境構築。（まとめ）

vCenter 7.0 U1 に、ESXi 7.0 U1 （4台）のクラスタを構築してあります。

（今回の手順には関係しませんが）クラスタには 3台の vCLS VM が自動デプロイされています。

vSphere HA / DRS も有効化してあります。

仮想スイッチは、バージョン 7.0 の分散仮想スイッチ（vDS）です。

vDS には、vSphere with Tanzu で利用する 3種類のネットワークむけに、

それぞれ分散ポートグループを作成してあります。

管理ネットワーク： DPortGroup-0010-MGMT、VLAN ID 10
ワークロードネットワーク 1（プライマリ）： DPortGroup-0021-WL1、VLAN ID 21
ワークロードネットワーク 2： DPortGroup-0022-WL2、VLAN ID 22

そして物理ネットワークも、これらの VLAN での通信ができるように構成ずみです。

データストアには、vCenter の機能によるタグを割り当てずみです。

また、データストアに割り当てたタグを指定した、仮想マシンストレージポリシーも作成ずみです。

これらは下記のように設定してます。

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

NFS データストアを、クラスタ内の全 ESXi ホストにマウントしてあります。

データストアには、タグ（タグ名は wcp-demo、カテゴリは datastore-category）を割り当ててあります。

データストアに割り当てたタグを指定した、仮想マシンストレージポリシーも作成ずみです。

Tanzu Kubernetes Grid のコンテンツライブラリも作成ずみです。

以前は「ワークロード管理」有効化後に作成すればよかったのですが、

vSphere 7.0 U1 からは、事前作成が必要になりました。

コンテンツライブラリは下記のように作成しています。

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

今回は、cl-tkg-01 という名前でコンテンツライブラリを作成しています。

Tanzu Kubernetes クラスタのノードとしてデプロイされる、OVF テンプレートがダウンロードされています。

複数の Kubernetes バージョンのものが用意されていることがわかります。

つづく。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-02 HAProxy デプロイ

NTPと同期してくれないときのトラブルシューティング

nkaneda — Fri, 23 Oct 2020 04:38:56 GMT

ラボ環境や検証環境だと、用意したNTPサーバーとESXi/VCSAが同期してくれないことがしばしばあると思います。

多くの場合はちょっとした設定の追加で解決できることが多いので、今回はその方法についてご説明します。

NTPサーバとの疎通確認

何はともあれ、まずはNTP側との疎通と動作確認が必要です。

以下のコマンドを実行してください。

※ESXiにはntpdateコマンドはないのでスキップしてください。

/sbin/ntpdate -b -u <ntp server ip>

/sbin/ntpdate -d <ntp server ip>

上のコマンドはNTPサーバと同期するコマンドです。NTPデーモンは時間がずれすぎている同期してくれないので、まずはこのコマンドで強制的に時間を合わせます。

下のコマンドはntpサーバの正常動作を確認するコマンドです。

このコマンドが失敗するようでは疎通やNTPサーバ側の問題ですのでそちらをご確認ください。

NTPサーバとの同期に時間がかかっている可能性

NTPサーバとの同期は一時間くらいかかることもあります。

その場合はiburstというオプションを付与することで初期同期までの時間を短縮できます。

/etc/ntp.conf内の外部NTPサーバのIPアドレスの後ろにiburstを追加することで設定可能です。

以下のような感じです。

##
48 server <ntp server ip> iburst
49 trustedkey
##

上記の設定があることで何十分も同期を待たずに済みます。

実施後は/etc/init.d/ntpd restart でサービスを再起動してください。

なお、NTPサーバとしてインターネット上の公開NTPサーバを指定している場合はiburstは利用しないか、利用可能かどうかをサーバの管理者にお尋ねください。

社内のNTPサーバの場合はほぼほぼ問題ないとは思いますが、確認しておいた方が無難です。

NTPサーバからの時刻が信頼されていない可能性

iburst設定後や、十分な時間が経過した後でも同期しない場合は、NTPサーバからの情報をNTP Clientが信頼していない場合があります。

VCSAの場合

# /usr/sbin/ntpdc -c 'showpeer <ntp ip address>'
remote <ntp ip address>, local <ntp ip address>
hmode client, pmode unspec, stratum 2, precision -6
leap 00, refid [xxx.xxx.xxx.xxx], rootdistance 0.03125, rootdispersion 8.30737
ppoll 6, hpoll 6, keyid 0, version 4, association 57089
reach 001, unreach 1, flash 0x0400, boffset 0.00400, ttl/mode 0
timer 0s, flags config, bclient
reference time:      dc0bbd00.3f21a2e7 Tue, Dec 27 2016 1:00:00.246
originate timestamp: dc0c6b35.c3fed202 Tue, Dec 27 2016 13:23:17.765
receive timestamp:   dc0c6b35.c3d4dc75 Tue, Dec 27 2016 13:23:17.764
transmit timestamp: dc0c6b35.c3bfd0d1 Tue, Dec 27 2016 13:23:17.764
filter delay: 0.00032 0.00032 0.00000 0.00000
               0.00000 0.00000 0.00000 0.00000
filter offset: 0.000801 0.000480 0.000000 0.000000
               0.000000 0.000000 0.000000 0.000000
filter order: 0        1        2        3
               4        5        6        7
offset 0.000801, delay 0.00032, error bound 1.98726, filter error 0.01791

ESXiの場合

# /usr/sbin/ntpq -classoc
ind assid status conf reach auth condition last_event cnt
===========================================================
1 63674 961a   yes   yes none sys.peer    sys_peer 1
# /usr/sbin/ntpq -c "rv 63674"    <<<< rv xxxx のIDは↑のコマンドのassidで確認
associd=63674 status=961a conf, reach, sel_sys.peer, 1 event, sys_peer,
srcadr=ntp-sv1.cpsd.local, srcport=123, dstadr=xxx.xxx.xxx.xxx, dstport=123,
leap=00, stratum=4, precision=-25, rootdelay=350.113, rootdisp=94.040,
refid=10.30.48.37,
reftime=e2b64f76.e5a956e2 Mon, Jul 13 2020 3:11:50.897,
rec=e2b650cc.9a6cec7e Mon, Jul 13 2020 3:17:32.603, reach=377,
unreach=0, hmode=3, pmode=4, hpoll=10, ppoll=10, headway=0, flash=00 ok,
keyid=0, offset=3.212, delay=0.700, dispersion=19.482, jitter=0.630,
xleave=0.039,
filtdelay=     0.74    0.70    0.74    0.68    0.69    0.73    0.76    0.79,
filtoffset=    3.37    3.21    2.94    2.99    2.91    2.83    2.40    1.89,
filtdisp=      0.00   16.02   32.31   48.08   64.13   79.52   95.43 111.65

このコマンド出力中で注目すべきところは太字で強調したflash のところです。

flashの値は簡単にいえばエラーコードみたいなものです。

上の例ではVCSAは0x400 となっており、ESXiでは00 (0x0000)となっています。

flashの値の意味についてはntpのソースコードのヘッダファイルに説明があります。

#### ヘッダファイル引用
+++++ include/ntp.h
/*
* Define flasher bits (tests 1 through 11 in packet procedure)
* These reveal the state at the last grumble from the peer and are
* most handy for diagnosing problems, even if not strictly a state
* variable in the spec. These are recorded in the peer structure.
*
* Packet errors
*/
#define TEST1           0X0001 /* duplicate packet */
#define TEST2           0x0002 /* bogus packet */
#define TEST3           0x0004 /* protocol unsynchronized */
#define TEST4           0x0008 /* access denied */
#define TEST5           0x0010 /* authentication error */
#define TEST6           0x0020 /* bad synch or stratum */
#define TEST7           0x0040 /* bad header data */
#define TEST8           0x0080 /* autokey error */
#define TEST9           0x0100 /* crypto error */
#define PKT_TEST_MASK   (TEST1 | TEST2 | TEST3 | TEST4 | TEST5 |\
                        TEST6 | TEST7 | TEST8 | TEST9)
/*
* Peer errors
*/
#define TEST10          0x0200 /* peer bad synch or stratum */
#define TEST11          0x0400 /* peer distance exceeded */
#define TEST12          0x0800 /* peer synchronization loop */
#define TEST13          0x1000 /* peer unreacable */
#define PEER_TEST_MASK (TEST10 | TEST11 | TEST12 | TEST13)
####

上記のように定められています。
今回の場合は flash 0x400なので、
TEST11のpeer distance exceededに該当することが分かります。
（多くの場合はこれが原因と思います・・・）
これは要するに同期先のNTPサーバまでの距離が遠いということです。
（距離が遠いと信頼性が下がりますからね。違ったら御免なさい）

デフォルトで許容されるホップ数がいくつなのかは不明ですが、
とりあえず増やしてあげれば解決する理屈です。
なのでホップ数を30まで増やすためにtosコマンドを/etc/ntp.confに追記しましょう。
まとめるとこんな感じです。

## /etc/ntp.conf
    48 server <ntp ip address > iburst <<<< iburst 追記
    49 trustedkey
    50
    51 tos maxdist 30        <<<< 追記

##

この設定をすれば、少なくともflash 0x400の問題は解消できるはずです。

0x400以外の問題については別の対応が必要になると思います。

また、flash codeが正常（0x00）なのに同期してくれない場合は、messagesログなどにntp デーモンのエラーが吐かれているかもしれませんので確認されることをお勧めします。

（補足）NTPサーバがWindwos OSの場合

WindowsサーバをNTPサーバとして構築している場合、デフォルトの設定では同期可能なNTPサーバとしてみなされない場合があります。

おそらく多くの場合はLocalClockDispersion の設定によるものと思われますので、この値が0になっているかを確認されることをお勧めいたします。

Synology Hyper-V & vSphere Backup Configuration

VysakhNair — Sat, 17 Oct 2020 15:06:00 GMT

https://www.vxpert.in/synology-hyper-v-vsphere-backup-configuration/

VMware vCloud Director – Install and Configure RabbitMQ Cluster

VysakhNair — Sat, 17 Oct 2020 15:02:00 GMT

https://www.vxpert.in/vmware-vcloud-director-install-and-configure-rabbitmq-cluster/

How to Debug IOS Mobile Traffic

StevenDSa — Fri, 14 May 2021 15:02:50 GMT

For updates on this blog and other blogs: Follow @SteveIDM

This blog has been moved to

https://TheIdentityGuy.ca

vSphere 7.0 と 7.0 U1 での「ワークロード管理」有効化の違いについて。（NSX-T あり編）

gowatana — Sun, 11 Oct 2020 05:14:20 GMT

vSphere 7.0 U1 では「vSphere with Kubernetes」が「vSphere with Tanzu」になり、

製品構成や技術的な面で vSphere 環境で Tanzu Kubernetes Grid による Kubernetes が利用しやすくなりました。

たとえば、NSX-T がなくても Kubernetes が利用できるようになりました。

その一方で、vSphere 7.0 のときと同様の、NSX-T を組み込んだスーパーバイザークラスタも利用できます。

ただ、スーパーバイザークラスタを作成する「ワークロード管理」の有効化にも

少し手順変更があったので、主な差分について紹介しておきます。

ドキュメントでは下記のあたりです。

（若干 vSphere 7.0 からの差分は確認しにくいかなと思います）

ワークロード管理の有効化

なお、おおまかな流れとしては以前に投稿したスーパーバイザークラスタのラボ構築手順で、

vSphere 7.0 U1 でも環境構築できるはずです。

vSphere with Kubernetes ラボ環境構築。（まとめ）

「ワークロード管理」有効化の準備。

vSphere や、NSX-T の準備については、vSphere 7.0 時点とほぼ同様です。

ただし、Tanzu Kubernetes Grid（TKG）のコンテンツライブラリを、事前に作成しておくようになりました。

vSphere 7.0 時点では、TKG の OVF テンプレートををダウンロードする

コンテンツライブラリを、Tanzu Kubernetes Cluster を作成する前に作成する必要がありました。

7.0 U1 では「ワークロード管理」を有効化する前に、コンテンツライブラリの準備が必要になります。

コンテンツライブラリ未作成の場合は、エラーとなり「ワークロード管理」有効化を開始できません。

そこで、事前準備として TKG のコンテンツライブラリを作成しておきます。

これは下記投稿での「コンテンツライブラリの準備」にある手順と同様です。

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

ライブラリに含まれる OVF（Kubernetes のバージョン）は増えており、

この投稿の時点では下記のようになっています。

「ワークロード管理」の有効化。

「ワークロード管理」の有効化は、ひと通り画面遷移を掲載しておきます。

以前の vSphere 7.0 時点での様子は下記をどうぞ。

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

vSphere Client で「メニュー」→「ワークロード管理」を開くと、

まず、ライセンス追加、もしくは評価版利用者の基本情報入力する画面が追加されています。

評価版として利用する場合は、情報を入力して「開始する」をクリックすると、下記画面に遷移します。

「開始する」で次に進みます。

「vCenter Server とネットワーク」画面の「ネットワークスタックオプションを選択します」にて、

「NSX-T」もしくは「vCenter Server Network」を選択します。

今回は、従来どおり「NSX-T」を選択します。

「クラスタを選択」の画面は、7.0 と同様に、対象のクラスタを選択します。

ここからは、以前の vSphere 7.0 の頃と同様の情報入力が続きます。

「制御プレーンのサイズ」を選択します。

「ストレージ」で、用途ごとに仮想マシンストレージポリシーを選択します。

「管理ネットワーク」の情報を入力します。

vSphere 7.0 U1 では、管理とワークロードとで入力画面が明確に分割されました。

「ワークロードネットワーク」の情報を入力します。

「TKG 構成」は、vSphere 7.0 U1 から追加されました。

事前に作成した、TKG のコンテンツライブラリを選択します。

ただし、TKG と同時に Tanzu Kubernetes Cluster が作成されるわけではありません。

「確認」で、「完了」をクリックすると、処理が開始されます。

しばらく（ラボ環境では数十分）待つと、「ワークロード管理」が有効化されます。

これで、スーパーバイザー名前空間が作成できるようになります。

ちなみにクラスタ名の隣にある「!」マークが表示されているのは、評価版のためです。

Tanzu Kubernetes Cluster の変更点。

Tanzu Kubernetes Cluster（TKC）の作成方法は、vSphere 7.0 と同様です。

（下記投稿からの流れのように作成できます）

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

ただし、デフォルトの CNI が Calico から Antrea になりました。

TKC を定義するマニュフェスト（YAML 形式）で CNI を定義していない場合は、Antrea がインストールされます。

例えば、下記のような YAML で TKC を作成してみます。

tkg-cluster-03.yml · GitHub

---
kind: TanzuKubernetesCluster
apiVersion: run.tanzu.vmware.com/v1alpha1
metadata:
name: tkg-cluster-03
spec:
distribution:
    version: v1.18.5
topology:
    controlPlane:
      count: 1
      class: best-effort-xsmall
      storageClass: vm-storage-policy-wcp
    workers:
      count: 1
      class: best-effort-xsmall
      storageClass: vm-storage-policy-wcp
settings:
    network:
      services:
        cidrBlocks: ["10.16.0.0/12"]
      pods:
        cidrBlocks: ["10.32.0.0/12"]

この YAML では、あえて CNI の指定（下記のような）は省略しています。

・・・
spec:
settings:
    network:
      cni:
        name: antrea #or calico
・・・

TKC を作成します。

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

kubectl vsphere login でログインした後に、作成された TKC を確認すると、

Antrea が利用されていることがわかります。

以上、vSphere 7.0 U1 での「ワークロード管理」有効化の様子でした。

Using Workspace ONE Access as a Claims Provider in ADFS

StevenDSa — Fri, 14 May 2021 15:05:33 GMT

For updates on this blog and other blogs: Follow @SteveIDM

This blog has been moved to

https://TheIdentityGuy.ca

NSX-T 3.0： DFW を VLAN セグメントで使用してみる。（後編）

gowatana — Thu, 08 Oct 2020 13:18:54 GMT

NSX-T の分散ファイアウォール（DFW）を、VLAN セグメントで使用してみます。

前回は、簡単な動作確認をしてみました。

NSX-T 3.0： DFW を VLAN セグメントで使用してみる。（前編）

今回は、vNIC のポートグループを「VLAN セグメント」と「分散ポートグループ」に

それぞれ切りかえて、DFW ルール適用の様子を確認してみます。

今回の DFW ルール。

NSX Manager の「分散ファイアウォール」の画面を確認すると、

ID 3048 の DFW ルールが作成されて、有効になっています。

このルールは、適用先が「分散ファイアウォール (DFW)」となっており、

基本的には NSX 環境内のすべての VM、つまりホストトランスポートノード上で

NSX によるセグメントに接続されているすべて VM に適用されます。

（例外もありますが、今回は省略）

ちなみに、今回は DFW ルールの適用される様子を見るだけなので、

通信は遮断しない（アクション：許可）ルールにしてあります。

「VLAN セグメント」接続の vNIC と DFW ルール。

VM「vm01」の vNIC が、NSX-T による VLAN セグメント「seg-vlan-0006」に接続されています。

この VLAN セグメントは前回の投稿で作成したもので、VLAN ID 6 が設定されています。

それでは、vm01 が起動されている ESXi ホストに SSH 接続して、

vNIC への DFW ルール適用の様子を確認します。

まずに、DFW のルールが作成されている vNIC を確認しておきます。

ESXi に SSH ログインした状態です。

[root@lab-nsx-esxi-21:~] vmware -vl
VMware ESXi 7.0.0 build-16324942
VMware ESXi 7.0 GA

vm01 が起動しています。

この VM の World ID（371855）を記録しておきます。

[root@lab-nsx-esxi-21:~] esxcli network vm list
World ID Name Num Ports Networks
-------- ---- --------- --------
371855 vm01 1

summarize-dvfilter で、vm01 の vNIC に適用されている dvfilter を探します。

赤字の部分が、vm01 の vNIC にあたります。

[root@lab-nsx-esxi-21:~] summarize-dvfilter
Fastpaths:
agent: dvfilter-generic-vmware, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter-generic-fastpath
agent: vmware-si, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: nsxt-vsip-15945874
agent: vmware-sfw, refCount: 4, rev: 0x1010000, apiRev: 0x1010000, module: nsxt-vsip-15945874
agent: nsx_bridgelearningfilter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: nsxt-vdrb-15945874
agent: ESXi-Firewall, refCount: 3, rev: 0x1010000, apiRev: 0x1010000, module: esxfw
agent: dvfilter-faulter, refCount: 1, rev: 0x1010000, apiRev: 0x1010000, module: dvfilter
ServiceVMs:
serviceVM: 1, agent vmware-sfw, refCount: 2, rev: 0x4, apiRev: 0x4, capabilities: csum,tso
serviceVM: 2, agent vmware-sfw, refCount: 1, rev: 0x4, apiRev: 0x4, capabilities: csum,tso
Filters:
world 0 <no world>
port 67108877 vmk0
vNic slot 0
   name: nic-0-eth4294967295-ESXi-Firewall.0
   agentName: ESXi-Firewall
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failOpen
   serviceVMID: none
   filter source: Invalid
   moduleName: esxfw
port 67108878 vmk1
vNic slot 0
   name: nic-0-eth4294967295-ESXi-Firewall.0
   agentName: ESXi-Firewall
   state: IOChain Attached
   vmState: Detached
   failurePolicy: failOpen
   serviceVMID: none
   filter source: Invalid
   moduleName: esxfw
world 371855 vmm0:vm01 vcUuid:'50 07 76 2d a1 08 3d 62-94 8a 57 ce fd 77 9c aa'
port 67108883 vm01.eth0
vNic slot 2
   name: nic-371855-eth0-vmware-sfw.2
   agentName: vmware-sfw
   state: IOChain Attached
   vmState: Attached
   failurePolicy: failClosed
   serviceVMID: 1
   filter source: Dynamic Filter Creation
   moduleName: nsxt-vsip-15945874

さきほど確認した、VM の World ID をもとにすると、

vm01 のフィルタの名前を見つけやすいかなと思います。

vm01 の 1つめの vNIC（ゲスト OS の種類に関係なく eth0）のフィルタ名

「nic-371855-eth0-vmware-sfw.2」を見つけました。

[root@lab-nsx-esxi-21:~] summarize-dvfilter | grep 371855
world 371855 vmm0:vm01 vcUuid:'50 07 76 2d a1 08 3d 62-94 8a 57 ce fd 77 9c aa'
name: nic-371855-eth0-vmware-sfw.2

そしてフィルタ名を指定して「vsipioctl getrules」コマンドを実行すると、

DFW のルールが実際に設定されている様子がわかります。

さきほど NSX Manager でも確認できた、ID 3048 のルールが表示されており、

vm01 の vNIC に DFW ルールが適用されていることがわかります。

[root@lab-nsx-esxi-21:~] vsipioctl getrules -f nic-371855-eth0-vmware-sfw.2
ruleset mainrs {
# generation number: 0
# realization time : 2020-10-07T17:00:19
# FILTER rules
rule 3048 at 1 inout protocol any from any to any accept;
rule 2 at 2 inout protocol any from any to any accept;
}
ruleset mainrs_L2 {
# generation number: 0
# realization time : 2020-10-07T17:00:19
# FILTER rules
rule 1 at 1 inout ethertype any stateless from any to any accept;
}

ちなみに、DFW が適用されていることは nsxcli コマンドでも確認できます。

この ESXi で起動されている VM（の vNIC）が 1つだけなので、Firewall VIF が 1件表示されています。

[root@lab-nsx-esxi-21:~] nsxcli -c "get firewall vifs"
Firewall VIFs
----------------------------------------------------------------------
VIF count: 1
1 1db50096-f1b8-44a2-8639-8ed6ac641446

「vDS の分散ポートグループ」接続の vNIC と DFW ルール。

続いて、NSX-T の VLAN セグメントと同じ VLAN ID の分散ポートグループを適用して、

DFW ルールの変化を確認してみます。（結果として DFW ルールは消えます）

vDS「vds-21」に作成されている、分散ポートグループの一覧です。

今回は NSX で利用している vDS に、VLAN セグメントと同様に、

VLAN ID 6 の分散ポートグループ「dvpg-vlan-0006」を作成しました。

vm01 の vNIC のポートグループを、分散ポートグループである「dvpg-vlan-0006」に変更します。

分散ポートグループに変更されました。

このポートグループ変更より、DFW ルールが即時変更されます。

ESXi で summarize-dvfilter を実行してみると、

vm01 の「nic-371855-eth0-vmware-sfw.2」フィルタは存在したままです。

[root@lab-nsx-esxi-21:~] summarize-dvfilter | grep 371855
world 371855 vmm0:vm01 vcUuid:'50 07 76 2d a1 08 3d 62-94 8a 57 ce fd 77 9c aa'
name: nic-371855-eth0-vmware-sfw.2

しかし、vsipioctl getrules コマンドで確認すると、DFW ルールが消えて「No rules」になりました。

[root@lab-nsx-esxi-21:~] vsipioctl getrules -f nic-371855-eth0-vmware-sfw.2
No rules.

nsxcli コマンドでも 1件表示されていた VIF がなくなり、

Firewall VIF のカウントがゼロになっています。

[root@lab-nsx-esxi-21:~] nsxcli -c "get firewall vifs"
Firewall VIFs
----------------------------------------------------------------------
VIF count: 0

このように、VM が起動する ESXi が NSX-T のホストトランスポートノードとして設定されていたとしても、

vSS の標準ポートグループや vDS の分散ポートグループに接続された vNIC には、DFW ルールが適用されません。

DFW はオーバーレイネットワークでなくても使用できますが、

VLAN ネットワークで使用する場合、vNIC には「VLAN セグメント」を割り当てる必要があります。

以上、DFW を VLAN セグメントで使用してみる話でした。

NSX-T 3.0： DFW を VLAN セグメントで使用してみる。（前編）

gowatana — Wed, 07 Oct 2020 23:10:26 GMT

NSX-T の分散ファイアウォール（DFW）は、NSX-T のセグメント（オーバーレイ or VLAN）で機能します。

今回は、VLAN セグメントでも DFW が利用できることを確認してみます。

ラボ環境について。

今回のラボ環境は、下記のように用意してあります。

NSX-T 3.0 のシンプルな DFW ラボを構築する。

特にオーバーレイネットワークやルーティング機能などは準備せず、

ただ「VLAN セグメント」が利用できるようになっています。

NSX-T では、VLAN セグメント「seg-vlan-0006」を作成してあります。

まず、NSX Manager の画面から確認しておきます。

セグメントはオーバーレイではなく、VLAN のトランスポートゾーンに作成し、VLAN ID 6 を設定しています。

つまりこれは NSX-T で作成されたセグメントですが、Geneve のオーバーレイではなく VLAN によるものです。

vCenter（の vSphere Client）で vDS「vds-21」を確認すると、

「seg-vlan-0006」が表示されており、NSX の「N」マークがついています。

ちなみに、dvpg-vlan-0006 という NSX-T に関係しない、VLAN ID 6 の分散ポートグループも別途作成してあります。

※この分散ポートグループは次の投稿で利用します。

VM「vm01」の vNIC に、ポートグループとして NSX-T による VLAN セグメントを割り当てました。

なお、この VM の IP アドレスは 10.0.6.91 です。あとで、このアドレス宛に疎通確認します。

ESXi ホスト「192.168.10.21」で仮想スイッチの構成を確認すると、1つの vDS だけが構成されてます。

この vDS は NSX と統合されており、「NSX 仮想スイッチ」となっていることがわかります。

分散ポートグループやセグメントは、トポロジの図では実際に使用されているものだけが表示されています。

DFW ポリシー / ルールの作成。

NSX Manager で、DFW のポリシーとルールを作成します。

今回は、デフォルトで作成されているポリシーはそのままで、あえてポリシーを追加作成します。

そして、ルールの適用有無が分かりやすいように、すべての通信を許可 / 遮断するためのルールを、1つだけ作成します。

「セキュリティ」→「分散ファイアウォール」→「カテゴリ固有のルール」→「アプリケーション」を開きます。

デフォルト作成されるポリシー「Default Layer3 Section 」には、すべての通信を「許可」するルールが設定されているので、

今回の動作確認には特に影響しません。

この画面で「ポリシーの追加」をクリックすると「新規ポリシー」が作成されるので、

名前を「test-policy-01」に変更します。

追加された「test-policy-01」ポリシーを選択して、「ルールを追加」をクリックします。

「新規ルール」が作成されるので、「test-rule-01」に変更します。

ルールの「適用先」はデフォルトで「分散ファイアウォール」全体となっており、

NSX-T のオーバーレイ / VLAN セグメントに接続された VM に適用されます。

また、ルールの「送信元」、「宛先」、「サービス」は、いずれも「任意」になっているので、すべての通信が対象になります。

ただし、アクションは「許可」なので、このままでは通信の遮断はされません。

そして「発行」をクリックしてポリシー / ルールを保存しておきます。

ルールが保存され、このルールの ID は 3048 が採番されました。

このあと、このルールの設定を変更して、DFW の動作確認をします。

DFW ルールの動作確認。

それでは NSX 外部のマシンから、VLAN セグメントに接続されている vm01 宛に ping で疎通確認をしつつ、

DFW で通信を遮断してみます。

作成した DFW ルール「test-rule-01」のアクションを「許可」→「却下」に変更します。

※これはドロップより却下の方がデモ的に見栄えがよいため・・・

「発行」をクリックすると、ルールが適用されます。

この時点で vm01 宛に通信できる外部のマシンから ping を実行しつつ、「発行」をクリックします。

DFW のルールが作用して、外部の端末から vm01（10.0.6.91）への ping が通らなくなりました。

DFW ルール「test-rule-01」のアクションを「却下」→「許可」に戻して、「発行」をクリックすると・・・

外部の端末から、vm01 への ping が通るようになりました。

このように、オーバーレイセグメントではなく、VLAN セグメントでも、NSX-T の DFW は動作します。

まずは、DFW が動作することの確認でした。

次は、VM の vNIC に「NSX の VLAN セグメント」ではなく「vDS の分散ポートグループ」を割り当てた環境で、

分散ファイアウォールルールが動作しない様子を確認してみます。

つづく！

NSX-T 3.0： DFW を VLAN セグメントで使用してみる。（後編）

NSX-T 3.0 のシンプルな DFW ラボを構築する。

gowatana — Wed, 07 Oct 2020 14:59:02 GMT

NSX-T には、分散ファイアウォール（DFW）機能があります。

この DFW は、NSX-T の有名な機能であるオーバーレイネットワーク（Geneve による）の環境でなくても利用可能です。

そこで今回は、オーバーレイネットワークなしのシンプルな DFW ラボ環境を構築してみます。

今回の環境。

今回のラボは、下記のような構成です。

vCenter Server 7.0d / ESXi 7.0
NSX-T 3.0
NSX の仮想スイッチは、N-VDS ではなく vDS 7.0 を利用（NSX-T 3.0 ～新機能）
NSX Edge は無し。オーバーレイネットワークも無し。

vCenter / ESXi の仮想スイッチは、分散仮想スイッチ（vDS）のみを構成しています。

vDS のバージョンは 7.0 で作成してあり、アップリンクには ESXi の物理 NIC（vmnic0 と vmnic1）が割り当てられています。

NSX Manager の仮想アプライアンス（VM）は、すでにデプロイしてあります。

OVA ファイルは「nsx-unified-appliance-3.0.0.0.0.15945876-le.ova」です。

なお、NSX-T の設定作業をするためにはライセンスの適用は必須です。

デプロイ直後の NSX Manger の VM を起動して、

評価ライセンスを適用してある状態です。

NSX Manager での vCenter 登録。

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

これは、NSX-T の仮想スイッチで vDS を利用するために必要です。

「システム」→「ファブリック」→「コンピュートマネージャ」を開き、

「追加」をクリックして「コンピュートマネージャの作成」画面を表示します。

そして、下記を入力して「追加」をクリックします。

vCenter の「名前」（これは任意の文字列）
vCenter の「FQDN または IP アドレス」
vCenter の、ユーザー名と、パスワード

画面に従って証明書のサムプリントを受け入れると、vCenter がコンピュートマネージャとして登録されます。

これで、「システム」→「ファブリック」→「ノード」→

「ホストトランスポートノード」で vCenter を選択すると、クラスタと ESXi が表示されるようになります。

ただしこの ESXi は、まだ NSX-T むけに準備されていない状態です。

ESXi のホストトランスポートノードとしての準備。

ここから ESXi を、NSX-T の「ホストトランスポートノード」として準備します。

まず、「システム」→「ファブリック」→「プロファイル」→

「トランスポートノードプロファイル」で、「追加」をクリックします。

「トランスポートノードプロファイルの追加」画面が表示されるので、

下記を入力して、そのまま画面を下にスクロールします。

プロファイルにつける「名前」を入力。今回は tnp-esxi-vds-01 としています。
ノードスイッチの「タイプ」で、「VDS」を選択。
ノードスイッチ「名前」では、vCenter と vDS 名を選択。（例での vDS は vds-21）
トランスポートゾーンとして「nsx-vlan-transportzone」を選択。
（これは、デフォルト作成される VLAN トランスポートゾーン）
アップリンクプロファイルとして「nsx-default-uplink-hostswitch-profile」を選択。

画面下にスクロールして、下記を入力してから「追加」をクリックします。

uplink-1 → vDS の1つめのアップリンク名（例では dvUplink1）
uplink-2 → vDS の2つめのアップリンク名（例では dvUplink2）

これで、VLAN セグメントを利用できるようになる、トランスポートノードプロファイルが作成されました。

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

クラスタ（ESXi ではなくその上の）を選択して、「NSX の設定」をクリックします。

「NSX のインストール」画面が表示されるので、先ほど作成したトランスポートノードプロファイルを選択して、

「適用」をクリックします。

これで少し待つと、クラスタ配下の ESXi が NSX のホストトランスポートノードとして設定された状態になります。

NSX-T によるネットワークの準備。

このラボでは DFW だけを利用するため、NSX Edge はデプロイしていません。

そして、ルーティングのための Tier-0 / Tier-1 ゲートウェイや、Geneve のオーバーレイセグメントも作成しません。

VLAN 接続するための「VLAN セグメント」のみ作成します。

Tier-0 ゲートウェイは、作成しません。

そして Tier-1 ゲートウェイも作成しません。

NSX-T では、vCenter でポートグループとして扱える「セグメント」を作成できます。

そして NSX-T の DFW は、この「セグメント」で作用します。

NSX-T のセグメントには、「オーバーレイ」と「VLAN」の２種類がありますが、DFW はどちらでも利用できます。

そこで、ここでは「VLAN セグメント」のみを作成します。

「ネットワーク」→「セグメント」にある、「セグメント」タブで、「セグメントの追加」をクリックします。

そして下記を入力して、画面を下にスクロールします。

セグメント名を入力。ここでは seg-vlan-0006。
トランスポートゾーンを選択。デフォルトで作成されている「nsx-vlan-transportzone | VLAN」を選択する。

VLAN ID を入力し、「保存」をクリックします。

今回は、セグメント名からもわかるように VLAN ID 6 のセグメントを作成します。

ちなみに、この VLAN ID は（NSX 外部の）物理スイッチのトランクポートでも設定しておく必要があります。

このセグメントの設定を続行するかという確認メッセージは、「いいえ」で閉じます。

これで、VLAN セグメントが作成されました。

ここで作成した、VLAN セグメント「seg-vlan-0006」は、

vCenter の vSphere Client などでは、ポートグループとして VM の vNIC に割り当てられます。

これで、DFW を利用可能な、シンプルな構成のラボが構築できました。

つづく。

Integrating DUO with Workspace ONE Access

StevenDSa — Fri, 14 May 2021 15:00:53 GMT

For updates on this blog and other blogs: Follow @SteveIDM

This blog has been moved to

https://TheIdentityGuy.ca

Using SCIM with OneLogin and Workspace ONE Access

StevenDSa — Tue, 15 Jun 2021 14:37:25 GMT

For updates on this blog and other blogs: Follow @SteveIDM

This blog has been moved to

https://TheIdentityGuy.ca

Tanzu Kubernetes Cluster への接続。（実験編）

gowatana — Mon, 21 Sep 2020 14:58:42 GMT

vSphere with Kubernetes のスーパーバイザークラスタ上に作成した

「Tanzu Kubernetse Cluster」に、kubectl を使用していくつかの方法で接続してみます。

ドキュメントでは、下記のあたりが参考になります。

Tanzu Kubernetesクラスタ環境への接続

環境について。

今回の接続元の環境は Linux です。

スーパーバイザークラスタの管理プレーンから、kubectl と vSphere プラグインはダウンロードしてあります。

$ cat /etc/system-release
Oracle Linux Server release 7.8
$ kubectl version --short --client
Client Version: v1.17.4-2+a00aae1e6a4a69
$ kubectl vsphere version
kubectl-vsphere: version 0.0.2, build 16232217, change 8039971

Tanzu Kubernetse Cluster のラボは、下記のように構築しています。

vSphere with Kubernetes ラボ環境構築。（まとめ）

kubectl は、スーパーバイザークラスタの制御プレーンからダウンロードしたものを利用しています。

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

vCenter Server 7.0b で、3ノードの ESXi でスーパーバイザークラスタを構成しています。

スーパーバイザークラスタ「wcp-cluster-41」の、制御プレーンの IP アドレスは「192.168.70.97」です。

Tanzu Kubernetes Cluster（TKC）は、スーパーバイザークラスタの名前空間「lab-ns-03」に作成ずみです。

TKC の名前は「tkg-cluster-41」で、制御プレーンの IP アドレスは「192.168.70.99」です。

あらかじめ、vCenter Single Sign-On には、ID ソースとして LDAP サーバを登録ずみです。

ID ソースのドメイン「go-lab.jp」からユーザ情報を取得できています。

方法1： vCenter Single Sign-On 認証で接続する。

ここでは、「k8s-infra-user @ go-lab.jp」という vCenter Single Sigh-On のユーザーで接続してみます。

まず、対象のユーザーには、スーパーバイザークラスタの名前空間で「権限の追加」が必要です。

そして、kubectl で TKC に接続する際は、スーパーバイザー制御プレーン宛となります。

ちなみに、vCenter の管理者ユーザ（administrator@vsphere.local）であれば、

デフォルトでスーパーバイザークラスタや TKC にアクセス可能です。

1-1：スーパーバイザー名前空間での権限の追加。

スーパーバイザークラスタの名前空間「lab-ns-03」の、

「サマリ」→「権限」にある「権限の追加」をクリックします。

ID ソース、ユーザー（またはグループ）、ロールを選択して、「OK」をクリックします。

今回は、ユーザー（k8s-infra-user）を指定していますが、一般的にはグループを指定するはずです。

ロールでは、「編集可能」（edit）または、「表示可能」（view）が選択できます。

権限が追加されました。

1-2： kubectl での接続。

kubectl vsphere login でログインすると、kubeconfig のファイルが生成されます。

デフォルトでは、$HOME/.kube/config というファイル名で作成されますが、

環境変数 KUBECONFIG を設定しておくと、そのパスに生成されます。

$ export KUBECONFIG=$(pwd)/kubeconfig_tkc

kubectl vsphere login では、次のようなオプションを指定します。

--server： Tanzu Kubernetes Cluster の制御プレーンではなく、
スーパーバイザークラスタの、制御プレーンが持つ IP アドレス（この環境では 192.168.70.97）を指定します。
--tanzu-kubernetes-cluster-namespace： TKC を作成したスーパーバイザー名前空間
--tanzu-kubernetes-cluster-name： TKC の名前

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.97 --tanzu-kubernetes-cluster-namespace=lab-ns-03 --tanzu-kubernetes-cluster-name=tkg-cluster-41
Username: k8s-infra-user@go-lab.jp
Password: ★パスワードを入力。
Logged in successfully.
You have access to the following contexts:
   192.168.70.97
   lab-ns-03
   tkg-cluster-41
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>`
$

TKC「tkg-cluster-41」と、TKC のスーパーバイザー名前空間「lab-ns-03」と同名のコンテキストが作成されます。

ここでも、TKC の制御プレーンアドレス「192.168.70.99」がわかります。

$ kubectl config get-contexts tkg-cluster-41
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* tkg-cluster-41 192.168.70.99 wcp:192.168.70.99:k8s-infra-user@go-lab.jp

TKC のノードが表示できました。

$ kubectl --context tkg-cluster-41 get nodes
NAME                                            STATUS   ROLES    AGE    VERSION
tkg-cluster-41-control-plane-vcdpg              Ready    master   153m   v1.17.8+vmware.1
tkg-cluster-41-workers-c72df-5979f6ffcf-lgsx2   Ready    <none>   131m   v1.17.8+vmware.1
tkg-cluster-41-workers-c72df-5979f6ffcf-qvv92   Ready    <none>   127m   v1.17.8+vmware.1
tkg-cluster-41-workers-c72df-5979f6ffcf-vdrpn   Ready    <none>   131m   v1.17.8+vmware.1

ちなみに権限を追加していなかったり、ロールが「表示可能」の場合はエラーになります。

$ kubectl --context tkg-cluster-41 get nodes
Error from server (Forbidden): nodes is forbidden: User "sso:k8s-infra-user@go-lab.jp" cannot list resource "nodes" in API group "" at the cluster scope

なお、TKC で Deployment リソースなどで Pod を作成するには、PodSecurityPolicy の設定が必要になったりします。

（これは、この後の方法でも同様です）

vSphere with Kubernetes ラボ環境構築。Part-15: Tanzu Kubernetes Cluster での PSP 使用 / Deployment 作成編

方法2： Kubernetes の管理ユーザ（kubernetes-admin）として接続する。

この方法では、TKC を作成してあるスーパーバイザー名前空間「lab-ns-03」に自動作成されている Secret リソースから、kubeconfig の情報を取得します。

これは、あらかじめ kubectl vsphere login でスーパーバイザークラスタか TKC に接続したうえで取得することになります。

kubernetes-admin の kubeconfig での接続は、直接 TKC の管理プレーン宛を指定します。

2-1： kubernetes-admin ユーザーの kubeconfig の取得。

Secret リソースは、「＜Tanzu Kubernetes Cluster の名前＞-kubeconfig」となっており、

この環境では「tkg-cluster-41-kubeconfig」です。

$ kubectl --context lab-ns-03 get secrets tkg-cluster-41-kubeconfig
NAME TYPE DATA AGE
tkg-cluster-41-kubeconfig Opaque 1 167m

JSON パスでの「{.data.value}」に、base64 エンコーディングされた kubeconfig が格納されています。

この内容を、「base64 -d」コマンドでデコードして、ファイルに保存します。

$ kubectl --context lab-ns-03 get secret tkg-cluster-41-kubeconfig -o jsonpath='{.data.value}' | base64 -d > ./kubeconfig_tkg-cluster-41

2-2：生成した kubeconfig での kubectl 接続。

保存した kubeconfig で、管理ユーザーのコンテキストで TKC に接続できます。

これは、vCenter Single Sign-On の認証とは関係なく接続できるものです。

$ kubectl --kubeconfig=./kubeconfig_tkg-cluster-41 config current-context
kubernetes-admin@tkg-cluster-41
$ kubectl --kubeconfig=./kubeconfig_tkg-cluster-41 get nodes
NAME                                            STATUS   ROLES    AGE    VERSION
tkg-cluster-41-control-plane-vcdpg              Ready    master   155m   v1.17.8+vmware.1
tkg-cluster-41-workers-c72df-5979f6ffcf-lgsx2   Ready    <none>   133m   v1.17.8+vmware.1
tkg-cluster-41-workers-c72df-5979f6ffcf-qvv92   Ready    <none>   129m   v1.17.8+vmware.1
tkg-cluster-41-workers-c72df-5979f6ffcf-vdrpn   Ready    <none>   133m   v1.17.8+vmware.1

方法3： Kubernetes の ServiceAccount を作成して接続する。

方法1か、方法2の、いずれかで TKC に接続したうえで、TKC の名前空間に ServiceAccount を作成して接続します。

ServiceAccount での TKC への接続も、スーパーバイザー制御プレーンではなく、TKC 制御プレーン宛となります。

3-1： ServiceAccount の作成。

ここからは、ちょうど直前の方法2 で作成した kubeconfig を利用します。

$ export KUBECONFIG=$(pwd)/kubeconfig_tkg-cluster-41
$ kubectl config current-context
kubernetes-admin@tkg-cluster-41

この時点では TKC の「default」名前空間を使用していますが、

あらたに「tkg-ns-01」という名前空間を作成して、そこに ServiceAccount で接続できるようにします。

$ kubectl create namespace tkg-ns-01
namespace/tkg-ns-01 created

この時点 tkg-ns-01 名前空間に存在するのは、ServiceAccount（sa）は default のみです。

$ kubectl -n tkg-ns-01 get sa
NAME SECRETS AGE
default 1 43s

ServiceAccount「sa-01」を作成します。

$ kubectl -n tkg-ns-01 create sa sa-01
serviceaccount/sa-01 created
$ kubectl -n tkg-ns-01 get sa
NAME      SECRETS   AGE
default   1         47s
sa-01     1         12s

この ServiceAccount のトークンが格納されている、Secret リソースの名前を確認します。

$ SA_SECRET_NAME=$(kubectl -n tkg-ns-01 get sa sa-01 -o jsonpath='{.secrets[0].name}')
$ echo $SA_SECRET_NAME
sa-01-token-zc74c

Secret リソースから、トークンを取得します。

$ SA_TOKEN=$(kubectl -n tkg-ns-01 get secrets $SA_SECRET_NAME -o jsonpath='{.data.token}' | base64 -d)

確認したトークンをもとに、Credential、コンテキストを作成します。

$ kubectl config set-credentials sa-01 --token=$SA_TOKEN
User "sa-01" set.
$ kubectl config set-context ctx-sa-01 --user=sa-01 --cluster=tkg-cluster-41 --namespace=tkg-ns-01
Context "ctx-sa-01" created.

コンテキストを kubeconfig ファイルとして保存しておきます。

$ kubectl config view --minify --context=ctx-sa-01 --raw > ./kubeconfig_ctx-sa-01
$ kubectl config delete-context ctx-sa-01

ServiceAccount で接続する kubeconifg が生成されました。

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* ctx-sa-01 tkg-cluster-41 sa-01 tkg-ns-01

3-2： ServiceAccount の権限設定。

作成した ServiceAccount「sa-01」が Kubernetes のリソースを操作できるように、

ClusterRole「edit」を割り当てる RoleBinding を作成しておきます。

role-binding-edit.yml

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: rb-edit-sa-01
roleRef:
kind: ClusterRole
name: edit
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
name: sa-01

RoleBinding を、TKC の tkg-ns-01 名前空間に作成します。

$ kubectl -n tkg-ns-01 apply -f role-binding-edit.yml
rolebinding.rbac.authorization.k8s.io/rb-edit-sa-01 created

TKC で Pod を起動できるように、PodSecurityPolicy を割り当てる RoleBinding も作成しておきます。

こちらは、すべての ServiceAccount を指定しています。

role-binding-psp.yml

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: rb-vmware-system-privileged
roleRef:
kind: ClusterRole
name: psp:vmware-system-privileged
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
name: system:serviceaccounts
apiGroup: rbac.authorization.k8s.io

TKC の名前空間に RoleBinding を作成します。

$ kubectl -n tkg-ns-01 apply -f role-binding-psp.yml
rolebinding.rbac.authorization.k8s.io/rb-vmware-system-privileged created

3-3：生成した kubeconifg での kubectl 接続。

生成した kubeconfig で、Pod の起動ができました。

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 run pod-01 --image=gowatana/centos7:httpd --restart=Never
pod/pod-01 created
$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01 get pods
NAME READY STATUS RESTARTS AGE
pod-01 1/1 Running 0 44s

Pod は削除しておきます。

$ kubectl --kubeconfig=./kubeconfig_ctx-sa-01.txt delete pod pod-01
pod "pod-01" deleted

方法4： TKC 側で vCenter Single Sign-On ユーザーの権限を割り当てる。

あらかじめ、方法1、または方法2の、いずれかの方法で TKC に接続しておきます。

そして方法1 とは異なり、TKC で作成した名前空間に vCenter Single Sigh-On ユーザーの権限を割り当てます。

そのあとの TKC への接続はスーパーバイザー制御プレーン宛となります。

方法4-1： TKC の名前空間への権限の追加。

ここでは、方法2 で生成した kubeconfig を利用して、TKC を操作します。

（方法1 の接続でも同様に操作できます）

$ export KUBECONFIG=$(pwd)/kubeconfig_tkg-cluster-41
$ kubectl config current-context
kubernetes-admin@tkg-cluster-41

TKC の名前空間「tkg-ns-02」を追加作成します。

あわせて、PSP の RoleBinding（YAML は方法3のものと同様）も作成しておきます。

$ kubectl create namespace tkg-ns-02
namespace/tkg-ns-02 created
$ kubectl -n tkg-ns-02 apply -f role-binding-psp.yml
rolebinding.rbac.authorization.k8s.io/rb-vmware-system-privileged created

RoleBinding の YAML を用意します。

リソースを操作できるように、ClusterRole「edit」を割り当てます。

subjects では vCenter Single Sign-On ユーザー（sso:k8s-dev-user@go-lab.jp）を指定しています。

ちなみに、グループを指定する場合は、「kind: User」を「kind: Group」にします。

role-binding-vcsso.yml

---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: rb-edit-k8s-dev-user
roleRef:
kind: ClusterRole
name: edit
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
name: sso:k8s-dev-user@go-lab.jp #sso:<username>@<domain>
apiGroup: rbac.authorization.k8s.io

作成した TKC の名前空間「tkg-ns-02」に、RoleBinding を作成します。

$ kubectl -n tkg-ns-02 apply -f role-binding-vcsso.yml
rolebinding.rbac.authorization.k8s.io/rb-edit-k8s-dev-user created

方法4-2： kubectl での接続。

既存の kubeconfig を上書きしないように、環境変数 KUBECONFIG に、新しい kubeconfig ファイルのパスを指定します。

この時点では「kubeconfig_k8s-dev-user」ファイルは存在しません。

$ export KUBECONFIG=$(pwd)/kubeconfig_k8s-dev-user

kubectl vsphere login で、スーパーバイザー制御プレーンと TKC に接続します。

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.97 --tanzu-kubernetes-cluster-namespace=lab-ns-03 --tanzu-kubernetes-cluster-name=tkg-cluster-41
Username: k8s-dev-user@go-lab.jp
Password: ★パスワードを入力。
Logged in successfully.
You have access to the following contexts:
192.168.70.97
tkg-cluster-41
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>`
$

コンテキストが生成されました。

$ kubectl config get-contexts tkg-cluster-41
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* tkg-cluster-41 192.168.70.99 wcp:192.168.70.99:k8s-dev-user@go-lab.jp

コンテキストを TKC の「tkg-cluster-41」に切り替えて、

デフォルトの名前空間として「tkg-ns-02」を設定します。

$ kubectl config use-context tkg-cluster-41
Switched to context "tkg-cluster-41".
$ kubectl config set-context --current --namespace=tkg-ns-02
Context "tkg-cluster-41" modified.
$ kubectl config get-contexts tkg-cluster-41
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* tkg-cluster-41 192.168.70.99 wcp:192.168.70.99:k8s-dev-user@go-lab.jp tkg-ns-02

Pod が起動できました。

$ kubectl run pod-01 --image=gowatana/centos7:httpd --restart=Never
pod/pod-01 created
$ kubectl get pods -n tkg-ns-02
NAME READY STATUS RESTARTS AGE
pod-01 1/1 Running 0 10s

スーパーバイザー名前空間「lab-ns-03」では「k8s-dev-user」ユーザーへの権限は追加していませんが、

vCenter Single Sigh-On ユーザーでリソース作成ができました。

vSphere Client で確認すると、方法1 で使用した「k8s-infra-user」ユーザーのみが追加されています。

vCenter 同梱ではない kubectl の接続。

ちなみに、ここまでの方法に関わらず、kubeconfig が生成できていれば

一般的な Kubernetes 操作ツールでも TKC に（スーパーバイザークラスタにも）接続することができます。

Kubernetes のドキュメントでおなじみの URL から kubectl をダウンロードします。

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.17.8/bin/linux/amd64/kubectl
$ chmod +x ./kubectl

vCenter 同梱の kubectl と、あらたにダウンロードした kubectl（./kubectl でカレントディレクトリのものを実行）です。

$ kubectl version --short
Client Version: v1.17.4-2+a00aae1e6a4a69
Server Version: v1.17.8+vmware.1
$ ./kubectl version --short
Client Version: v1.17.8
Server Version: v1.17.8+vmware.1

どちらの kubectl でも、普通に TKC を操作できます。

$ ./kubectl --kubeconfig=./kubeconfig_k8s-dev-user run pod-01 --image=gowatana/centos7:httpd --restart=Never
pod/pod-01 created
$ ./kubectl --kubeconfig=./kubeconfig_k8s-dev-user get pods
NAME READY STATUS RESTARTS AGE
pod-01 1/1 Running 0 15s

Tanzu Kubernetes Cluster は、kubectl + vSphere プラグインによる vCenter Single Sign-On の認証だけでなく、

一般的な kubernetes と同様なクラスターへの接続ができます。

いくつか接続方法を試しましたが、もっとよい方法もあるかもしれません。

以上、いろいろと Tanzu Kubernetes Cluster への接続を試してみる話でした。

vSphere Pod で Anti-Affinity を試してみる。

gowatana — Fri, 18 Sep 2020 19:49:58 GMT

vSphere with Kubernetes のスーパーバイザークラスタで、

Pod をノードに分散して起動する「アンチアフィニティ」を試してみます。

vSphere で VM を起動する場合でも、複数台の VM を ESXi に分散して配置しようとするケースが多くあります。

たとえば「Web サーバ VM の 1号機と2号機は別の ESXi で起動する」といったものです。

vSphere Pod の実体は VM なのですが、特殊な VM なので、

ユーザが手動で vMotion できなかったり、DRS ＋アンチアフィニティルールが利用できなかったりします。

そこで、Kubernetes の持つ affinity の仕組みを利用できそうか様子を見てみます。

今回の環境。

vCenter Server 7.0b / ESXi 7.0 を利用しています。

スーパーバイザークラスタ（wcp-cluster-41）には、3台のワーカーノードとなる ESXi があります。

kubectl でも、スーパーバイザークラスタに ESXi が 3台あることが確認できます。

$ kubectl get nodes
NAME                               STATUS   ROLES    AGE   VERSION
42113326156c17e10192d03d69cfc933   Ready    master   25d   v1.17.4-2+a00aae1e6a4a69
4211b5cba366a26db4debeca422d75ca   Ready    master   25d   v1.17.4-2+a00aae1e6a4a69
4211b7998322f27779a8a0af22dbf35d   Ready    master   25d   v1.17.4-2+a00aae1e6a4a69
lab-wcp-esxi-41.go-lab.jp          Ready    agent    25d   v1.17.4-sph-c4c19c8
lab-wcp-esxi-42.go-lab.jp          Ready    agent    25d   v1.17.4-sph-c4c19c8
lab-wcp-esxi-43.go-lab.jp          Ready    agent    25d   v1.17.4-sph-c4c19c8

ホスト名やソフトウェアバージョンは若干異なりますが、

このラボは下記のように環境構築しています。

vSphere with Kubernetes ラボ環境構築。（まとめ）

vSphere Pod の起動。

まず、Kubernetes の Deployment リソースで、vSphere Pod を2つ起動します。

Deployment の定義は下記のようにしています。

httpd.yml · GitHub

---
kind: Service
apiVersion: v1
metadata:
name: web-svc
spec:
type: LoadBalancer
ports:
- port: 80
    protocol: TCP
    targetPort: 80
selector:
    app: demo-httpd
---
kind: Deployment
apiVersion: apps/v1
metadata:
name: demo-httpd
labels:
    app: web
spec:
replicas: 2
selector:
    matchLabels:
      app: demo-httpd
template:
    metadata:
      labels:
        app: demo-httpd
    spec:
      containers:
      - name: httpd
        image: gowatana/centos7:httpd
        ports:
        - containerPort: 80
          protocol: TCP

Pod を作成するのは、スーパーバイザークラスタの名前空間「lab-ns-01」です。

$ kubectl config current-context
lab-ns-01
$ kubectl config get-contexts lab-ns-01
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* lab-ns-01 192.168.70.97 wcp:192.168.70.97:administrator@vsphere.local lab-ns-01

Deployment を作成します。

$ kubectl apply -f httpd.yml
service/web-svc created
deployment.apps/demo-httpd created

特に Pod 配置にかかわる定義はなく、1つのホストに Pod が2つとも起動しています。

$ kubectl get pods -o wide
NAME                          READY   STATUS    RESTARTS   AGE   IP             NODE                        NOMINATED NODE   READINESS GATES
demo-httpd-6b58f9f454-kqld5   1/1     Running   0          70s   10.244.0.227   lab-wcp-esxi-41.go-lab.jp   <none>           <none>
demo-httpd-6b58f9f454-t8bwj   1/1     Running   0          70s   10.244.0.226   lab-wcp-esxi-41.go-lab.jp   <none>           <none>

vSphere Client でも、vSphere Pod として、

Pod が 2つとも「lab-wcp-esxi-41.go-lab.jp」で起動されたことが確認できます。

1つめの vSphere Pod です。

2つめの vSphere Pod です。

アンチアフィニティへの定義変更。

アンチアフィニティの方法については、下記の Kubernetes ドキュメントが参考になります。

アフィニティとアンチアフィニティ（日本語）

https://kubernetes.io/ja/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity

podAntiAffinity を定義した、下記のような YAML を用意しました。

httpd_anti-affinity.yml · GitHub

Deployment を作成した YAML との差分です。

今回は、わかりやすく動きを見たいので、必須要件となるように

「requiredDuringSchedulingIgnoredDuringExecution」を指定しています。

$ diff httpd.yml httpd_anti-affinity.yml
37a38,47
>       affinity:
>         podAntiAffinity:
>           requiredDuringSchedulingIgnoredDuringExecution:
>           - labelSelector:
>               matchExpressions:
>               - key: app
>                 operator: In
>                 values:
>                 - demo-httpd
>             topologyKey: "kubernetes.io/hostname"

それでは、定義を変更（YAML を適用）します。

※今回は既存の Deployment の定義を変更していますが、新規作成でもアンチアフィニティ配置になります。

$ kubectl apply -f httpd_anti-affinity.yml
service/web-svc unchanged
deployment.apps/demo-httpd configured

kubectl get pods で様子を見ていると、

Kubernetes による Pod の追加 / 削除が実施されます。

既存の Pod（～-c26jc、～-sjxpp）は停止され、あらたに Pod（～-rdz6l、～-wb774）が起動されています。

特に、スーパーバイザークラスタだからといって、vSphere DRS で vMotion されたりはしていません。

ちなみに内部的には、ReplicaSet リソースが作成されて Pod が追加されています。

$ kubectl get pods --watch
NAME                          READY   STATUS    RESTARTS   AGE
demo-httpd-68979c6d58-rdz6l   0/1     Pending   0          9s
demo-httpd-6b58f9f454-c26jc   1/1     Running   0          70m
demo-httpd-6b58f9f454-sjxpp   1/1     Running   0          71m
demo-httpd-68979c6d58-rdz6l   1/1     Running   0          9s
demo-httpd-6b58f9f454-c26jc   1/1     Terminating   0          70m
demo-httpd-68979c6d58-wb774   0/1     Pending       0          0s
demo-httpd-68979c6d58-wb774   0/1     Pending       0          0s
demo-httpd-68979c6d58-wb774   0/1     Pending       0          1s
demo-httpd-6b58f9f454-c26jc   1/1     Terminating   0          70m
demo-httpd-68979c6d58-wb774   0/1     Pending       0          3s
demo-httpd-68979c6d58-wb774   0/1     Pending       0          4s
demo-httpd-6b58f9f454-c26jc   1/1     Terminating   0          70m
demo-httpd-68979c6d58-wb774   1/1     Running       0          9s
demo-httpd-6b58f9f454-sjxpp   1/1     Terminating   0          71m
demo-httpd-6b58f9f454-sjxpp   1/1     Terminating   0          71m
demo-httpd-6b58f9f454-sjxpp   1/1     Terminating   0          71m

別のワーカーノードで、Pod が起動された状態になりました。

$ kubectl get pods -o wide
NAME                          READY   STATUS    RESTARTS   AGE    IP             NODE                        NOMINATED NODE   READINESS GATES
demo-httpd-68979c6d58-bvlgx   1/1     Running   0          119s   10.244.0.228   lab-wcp-esxi-43.go-lab.jp   <none>           <none>
demo-httpd-68979c6d58-dhrpc   1/1     Running   0          106s   10.244.0.229   lab-wcp-esxi-42.go-lab.jp   <none>           <none>

vSphere Client でも、vSphere Pod が順次追加 → 削除される様子が見られます。

最終的に vSphere Pod は 2つとなり、別の ESXi で起動されたことが確認できます。

1つめの vSphere Pod です。

もうひとつの vSphere Pod も、別の ESXi で起動されています。

vSphere Pod 起動時の配置決定では DRS が利用されています。

しかし、vCenter 7.0b 時点では、vSphere Pod の配置制御を工夫したい場合には

アフィニティルールや DRS ではなく、Kubernetes 側の仕組みを利用するとよさそうです。

以上、vSphere Pod をアンチアフィニティ配置してみる話でした。

Legacy User Blogs articles

Virtualization - help!

VMware Fusion - Mouse Clicks not recognized in version 12

vCenter 7.0 installation stuck at 80% (Waiting for RPM...)

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

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

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

権限の追加

ストレージの追加

スーパーバイザー クラスタ / 名前空間への接続。

Tanzu Kubernetes クラスタ（TKC）の作成。

TKC への接続 / Pod 起動。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理 有効化編

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-02 HAProxy デプロイ編

HAProxy 仮想アプライアンスについて。

HAProxy のデプロイ。

HAProxy の起動。

CA 証明書の取得。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-01 事前準備編

手順の流れ。

構成について。

前提環境の説明。

NTPと同期してくれないときのトラブルシューティング

NTPサーバとの疎通確認

NTPサーバとの同期に時間がかかっている可能性

NTPサーバからの時刻が信頼されていない可能性

VCSAの場合

ESXiの場合

（補足）NTPサーバがWindwos OSの場合

関連ドキュメント

Synology Hyper-V & vSphere Backup Configuration

VMware vCloud Director – Install and Configure RabbitMQ Cluster

How to Debug IOS Mobile Traffic

vSphere 7.0 と 7.0 U1 での「ワークロード管理」有効化の違いについて。（NSX-T あり編）

「ワークロード管理」有効化の準備。

「ワークロード管理」の有効化。

Tanzu Kubernetes Cluster の変更点。

Using Workspace ONE Access as a Claims Provider in ADFS

NSX-T 3.0： DFW を VLAN セグメントで使用してみる。（後編）

今回の DFW ルール。

「VLAN セグメント」接続の vNIC と DFW ルール。

「vDS の分散ポートグループ」接続の vNIC と DFW ルール。

NSX-T 3.0： DFW を VLAN セグメントで使用してみる。（前編）

ラボ環境について。

DFW ポリシー / ルールの作成。

DFW ルールの動作確認。

NSX-T 3.0 のシンプルな DFW ラボを構築する。

今回の環境。

NSX Manager での vCenter 登録。

ESXi のホスト トランスポート ノードとしての準備。

NSX-T によるネットワークの準備。

Integrating DUO with Workspace ONE Access

Using SCIM with OneLogin and Workspace ONE Access

Tanzu Kubernetes Cluster への接続。（実験編）

環境について。

方法1： vCenter Single Sign-On 認証で接続する。

1-1： スーパーバイザー名前空間での権限の追加。

1-2： kubectl での接続。

方法2： Kubernetes の管理ユーザ（kubernetes-admin）として接続する。

2-1： kubernetes-admin ユーザーの kubeconfig の取得。

2-2： 生成した kubeconfig での kubectl 接続。

方法3： Kubernetes の ServiceAccount を作成して接続する。

3-1： ServiceAccount の作成。

3-2： ServiceAccount の権限設定。

3-3： 生成した kubeconifg での kubectl 接続。

方法4： TKC 側で vCenter Single Sign-On ユーザーの権限を割り当てる。

方法4-1： TKC の名前空間への権限の追加。

方法4-2： kubectl での接続。

vCenter 同梱ではない kubectl の接続。

vSphere Pod で Anti-Affinity を試してみる。

今回の環境。

vSphere Pod の起動。

アンチ アフィニティへの定義変更。

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

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

スーパーバイザークラスタ / 名前空間への接続。

vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-03 ワークロード管理有効化編

ESXi のホストトランスポートノードとしての準備。

1-1：スーパーバイザー名前空間での権限の追加。

2-2：生成した kubeconfig での kubectl 接続。

3-3：生成した kubeconifg での kubectl 接続。

アンチアフィニティへの定義変更。