Skip navigation
1 2 3 Previous Next

にほんごVMware

442 posts

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 では「ワークロード管理」を有効化する前に、コンテンツ ライブラリの準備が必要になります。

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

wcp-70u1-01.png

 

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

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

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

 

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

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

wcp-70u1-08.png

 

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

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

 

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

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

 

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

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

wcp-70u1-10.png

 

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

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

wcp-70u1-12.png

 

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

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

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

wcp-70u1-13.png

 

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

wcp-70u1-16.png

 

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

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

wcp-70u1-17.png

 

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

wcp-70u1-18.png

 

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

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

wcp-70u1-20.png

 

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

wcp-70u1-21.png

 

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

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

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

wcp-70u1-24.png

 

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

wcp-70u1-25.png

 

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

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

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

wcp-70u1-27.png

 

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 が利用されていることがわかります。

wcp-70u1-tkc-01.png

 

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

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 ルールの適用される様子を見るだけなので、

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

nsxt-dfw-vnic-02.png

 

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

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

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

nsxt-dfw-vnic-03.png

 

それでは、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」を作成しました。

nsxt-dfw-vnic-04.png

 

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

nsxt-dfw-vnic-06.png

 

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

nsxt-dfw-vnic-07.png

 

このポートグループ変更より、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 の分散ファイアウォール(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 によるものです。

dfw-01-00.png

 

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

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

 

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

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

dfw-01-01.png

 

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

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

dfw-01-03.png

 

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

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

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

dfw-01-02.png

 

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

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

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

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

 

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

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

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

 

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

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

dfw-01-11.png

 

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

dfw-01-14.png

 

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

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

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

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

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

 

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

dfw-01-16.png

 

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

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

dfw-01-22.png

 

DFW ルールの動作確認。

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

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

 

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

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

dfw-01-28.png

 

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

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

dfw-01-23.png

 

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

dfw-01-26.png

 

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

dfw-01-29.png

 

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

dfw-01-30.png

 

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

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

 

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

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

つづく!

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-dfw-lab-01.png

 

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

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

nsx-dfw-lab-02.png

 

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

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

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

 

NSX Manager での vCenter 登録。

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

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

 

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

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

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

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

nsx-dfw-lab-04.png

 

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

nsx-dfw-lab-06.png

 

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

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

nsx-dfw-lab-07.png

 

ただしこの 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」を選択。

nsx-dfw-lab-09.png

 

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

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

nsx-dfw-lab-10.png

 

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

nsx-dfw-lab-11.png

 

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

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

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

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

nsx-dfw-lab-14.png

 

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

nsx-dfw-lab-16.png

 

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

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

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

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

 

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

nsx-dfw-lab-17.png

 

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

nsx-dfw-lab-18.png

 

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

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

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

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

 

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

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

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

nsx-dfw-lab-21.png

 

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

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

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

nsx-dfw-lab-23.png

 

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

nsx-dfw-lab-24.png

 

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

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

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

nsx-dfw-lab-26.png

 

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

つづく。

NSX-T 3.0: DFW を VLAN セグメントで使用してみる。(前編)

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」です。

tkc-access-00.png

 

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

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

tkc-access-01.png

 

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

tkc-access-02.png

 

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

tkc-access-03.png

 

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

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

 

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

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

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

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

tkc-access-case-01.PNG

 

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

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

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

tkc-access-04.png

 

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

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

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

tkc-access-05.png

 

権限が追加されました。

tkc-access-06.png

 

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 の管理プレーン宛を指定します。

tkc-access-case-02.PNG

 

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 制御プレーン宛となります。

tkc-access-case-03.PNG

 

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 への接続はスーパーバイザー制御プレーン宛となります。

tkc-access-case-04a.png

 

方法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」ユーザーのみが追加されています。

tkc-access-09.png

 

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 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 があります。

vsphere-pod-aa-01.png

 

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 です。

vsphere-pod-aa-02.png

 

2つめの vSphere Pod です。

vsphere-pod-aa-03.png

 

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

アンチ アフィニティの方法については、下記の 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-aa-05.png

 

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

1つめの vSphere Pod です。

vsphere-pod-aa-07.png

 

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

vsphere-pod-aa-08.png

 

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

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

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

 

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

通常の Kubernetes では、名前空間(Namespace)を分ければ、同名の Pod を作成できます。

今回は、ためしに vSphere with Kubernetes の 2つのスーパーバイザー名前空間でも、

あえて同名の vSphere Pod を起動してみました。

 

ちなみに、今回の環境は vCenter Server 7.0b です。

ソフトウェア バージョンやホスト名などは異なりますが、下記のようにラボを用意しています。

vSphere with Kubernetes ラボ環境構築。(まとめ)

 

それではまず、

1つめのスーパーバイザー名前空間「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

 

Pod を「pod-01」という名前で起動します。

$ kubectl run pod-01 --image=gowatana/centos7:httpd --generator=run-pod/v1 --context=lab-ns-01

pod/pod-01 created

$ kubectl get pods --context=lab-ns-01

NAME     READY   STATUS    RESTARTS   AGE

pod-01   1/1     Running   0          102s

 

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

vsphere-pod-02.png

 

2つめのスーパーバイザー名前空間は「lab-ns-02」です。

$ kubectl config get-contexts lab-ns-02

CURRENT   NAME        CLUSTER         AUTHINFO                                        NAMESPACE

          lab-ns-02   192.168.70.97   wcp:192.168.70.97:administrator@vsphere.local   lab-ns-02

 

この名前空間でも、Pod をあえて「pod-01」という名前で起動してみます。

(当然ながら起動できます)

$ kubectl run pod-01 --image=gowatana/centos7:httpd --generator=run-pod/v1 --context=lab-ns-02

pod/pod-01 created

$ kubectl get pods --context=lab-ns-02

NAME     READY   STATUS              RESTARTS   AGE

pod-01   1/1     Running             0          2m53s

 

vSphere Client でも、vSphere Pod が起動できたことが確認できます。

vsphere-pod-04.png

 

vSphere Pod の実体は VM です。

vSphere では、フォルダ内では同名の VM は作成できませんが・・・

vsphere-pod-06.png

 

一方で、リソースプール内では、もともと同名の VM が作成可能でした。

vsphere-pod-07.png

 

そして「Namespaces」リソースプールの配下の「名前空間」でも、ちゃんと同名の Pod は起動できます。

従来からの vSphere の仕組みを、うまく利用しているのだなと思いました。

 

以上、重複する名前の vSphere Pod を起動してみる話でした。

vSphere 7.0 では、コンテンツ ライブラリに登録した「仮想マシン テンプレート」で、

バージョン管理をしやすくなりました。

vSphere Client での操作で、コンテンツ ライブラリに登録したテンプレートの

「チェックアウト」、「チェックイン」といった更新管理ができるようになっています。

 

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

仮想マシン テンプレートの管理

 

今回の環境。

今回の環境は、vCenter Server 7.0b(Build 16386335)を利用しています。

 

コンテンツ ライブラリには「仮想マシン テンプレート」と「OVF & OVA テンプレート」が登録できますが、

ここでの対象は「仮想マシン テンプレート」の方です。

コンテンツ ライブラリ「lib-os-02」には、「ol78-min-01」という名前で、Linux VM を登録してあります。

テンプレートの実体となる仮想マシン(最新のもものは「ol78-min-01 (3)」)や、

「このテンプレートから仮想マシンをチェックアウト」ボタンが表示されています。

lib-vm-template-00.png

 

OVF とは異なり、「仮想マシン テンプレート」では

サブスクライブしたライブラリでのコンテンツ同期はできませんが、

今回紹介するようなバージョン管理ができるようになっています。

 

「仮想マシンおよびテンプレート」のインベントリでも、

テンプレートに紐づく仮想マシン テンプレートの「サマリ」や「バージョン管理」タブから

同様の UI でチェックアウトができるようになっています。

lib-vm-template-02.png

 

古いバージョンのテンプレートには、新バージョンへのリンクがあります。

lib-vm-template-01.png

 

1. 仮想マシン テンプレートのチェックアウト。

ためしに、仮想マシン テンプレートを更新してみます。

テンプレートを選択して、「このテンプレートから仮想マシンをチェックアウト」をクリックします。

lib-vm-template-11.png

 

仮想マシン名を入力し、場所(仮想マシン フォルダ)を選択して「次へ」をクリックします。

lib-vm-template-12.png

 

クラスタ / リソースプール を選択して「次へ」をクリックします。

lib-vm-template-13.png

 

「チェックアウト後に仮想マシンをパワーオン」のチェックを入れて「完了」をクリックします。

lib-vm-template-14.png

 

仮想マシンが作成され「チェックアウト」された状態になりました。

パワーオン状態なので、この時点ではまだ「チェックイン」できません。

lib-vm-template-17.png

 

2. 仮想マシン(ゲスト OS)の更新。

起動された仮想マシンにアクセスして、ゲスト OS で何らかの更新をしておきます。

lib-vm-template-22.png

 

そして、仮想マシンを停止(ゲスト OS をシャットダウン)します。

※ゲスト OS 内部からのシャットダウンでも大丈夫です。

lib-vm-template-23.png

 

3. 仮想マシン テンプレートへのチェックイン。

チェックアウトで作成された仮想マシンには、水色の丸印がついています。

仮想マシンを停止した状態で、「テンプレートに仮想マシンをチェックイン」をクリックます。

lib-vm-template-31.png

 

「仮想マシンのチェックイン」画面で、チェックイン メモを何か入力して「チェックイン」をクリックします。

lib-vm-template-32.png

 

仮想マシンがテンプレートに変換(仮想マシン名も変更)され、

2世代前のテンプレート(元から存在していた、前バージョンのもの)は自動削除されます。

lib-vm-template-34.png

 

新しく作成された仮想マシン テンプレート「ol78-min-01 (4)」でも、

「サマリ」や「バージョン管理」タブの表示が更新されています。

lib-vm-template-35.png

 

これで、コンテンツ ライブラリの UI (でのテンプレートの右クリック)などから、

更新されたテンプレートから、仮想マシンが新規作成できるようになります。

lib-vm-template-36.png

 

参考: 仮想マシン テンプレートのバージョンを戻す。

仮想マシン テンプレートを、ひとつ前のバージョンに戻すことができます。

「・・・」→「このバージョンに戻す」から実行します。

lib-vm-template-41.png

 

「バージョンを戻す」画面で、「メモを元に戻す」に何か入力して「元に戻す」をクリックします。

lib-vm-template-42.png

 

ひとつ前のバージョンの仮想マシン テンプレート「ol78-min-01 (3)」から、あらたに「ol78-min-01 (5)」が作成されます。

このように、コンテンツ ライブラリで管理される「仮想マシン テンプレート」では、

同時に 2つまでの、実体となる仮想マシンが存在することになります。

lib-vm-template-43.png

 

ちなみに、前バージョンのテンプレート(の仮想マシン)は、

不要になったら「バージョンの削除」メニューから削除することもできます。

この例では「ol78-min-01 (5)」ではなく、古い「ol78-min-01 (4)」の方が削除されます。

lib-vm-template-45.png

 

仮想マシン テンプレート更新にかかわる手順を一般化するときに便利かなと思います。

 

以上、コンテンツ ライブラリで仮想マシンをチェックアウト / チェックインしてみる話でした。

vSphere with Kubernetes によるスーパーバイザー クラスタで、vSphere Pod が削除できなくなることがあります。

そもそも vSphere Pod は右クリックメニューなどから削除できず、わりと悩ましい状態になります。

そこで、なぜか残ってしまった Pod を削除する方法を紹介してみます。

 

削除ずみの vSphere Pod が残った状態。

kubectl(kubectl delete pod ~ など)で vSphere Pod を削除すると、

下記のような状態で Pod が残ってしまうことがあります。

通常は少し待つと自動的に削除されますが、たまに 1日待っても vCenter を再起動しても削除されないことがあります。

 

停止された Pod が残っている様子です。

vsphere-pod-del-01.png

 

ごく稀に、起動中の Pod が残ったりもします。

vsphere-pod-del-02.png

 

kubectl では、すでに Pod が削除された状態で、

対象の名前空間では、Pod がみつかりません。

$ 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

$ kubectl get pods -n lab-ns-01

No resources found in lab-ns-01 namespace.

$

 

スーパーバイザー クラスタの名前空間を削除すれば一緒に削除できますが、

Pod 単位での削除を試みます。

 

vCenter インベントリに残った vSphere Pod の削除。

まず、Pod が残った名前空間に、あえて同名の Pod「demo-centos7-httpd-6b58f9f454-2jddf」を作成します。

コンテナ イメージは何でもよいので、サイズが小さそうな busybox を利用しました。

$ kubectl run demo-centos7-httpd-6b58f9f454-2jddf --image=busybox --restart=Never

pod/demo-centos7-httpd-6b58f9f454-2jddf created

 

このとき、名前空間にはすでに同名 Pod があるため、Pod の作成は失敗します。

$ kubectl get pod

NAME                                  READY   STATUS                RESTARTS   AGE

demo-centos7-httpd-6b58f9f454-2jddf   0/1     PodVMCreationFailed   0          5s

 

vSphere Client でも、Pod の作成が失敗します。

vsphere-pod-del-03.png

 

ここから、あらためて Pod を削除します。

$ kubectl delete pod demo-centos7-httpd-6b58f9f454-2jddf

pod "demo-centos7-httpd-6b58f9f454-2jddf" deleted

$ kubectl get pod

No resources found in lab-ns-01 namespace.

 

これで Pod「demo-centos7-httpd-6b58f9f454-2jddf」は削除されました。

vsphere-pod-del-05.png

 

同様に、もう一つの vSphere Pod「demo-centos7-httpd-68979c6d58-4l47n」も削除します。

$ kubectl run demo-centos7-httpd-68979c6d58-4l47n --image=busybox --restart=Never

pod/demo-centos7-httpd-68979c6d58-4l47n created

$ kubectl get pods

NAME                                  READY   STATUS                RESTARTS   AGE

demo-centos7-httpd-68979c6d58-4l47n   0/1     PodVMCreationFailed   0          22s

$ kubectl delete pod demo-centos7-httpd-68979c6d58-4l47n

pod "demo-centos7-httpd-68979c6d58-4l47n" deleted

$ kubectl get pods

No resources found in lab-ns-01 namespace.

 

vSphere Client でも、削除が確認できました。

vsphere-pod-del-08.png

 

このように vSphere Pod が削除できますが、他にいい方法がないかは気になっています・・・

 

以上、kubectl で削除できなかった vSphere Pod を削除してみる話でした。

vSphere の運用では、PowerCLI が利用できると便利です。

PowerCLI は PowerShell ベースのツールです。

そのため、以前は Windows が必要でしたが、最近では Linux の PowerShell でも利用でき、

Docker コンテナ イメージ(vmware/powerclicore)も用意されていたりします。

 

Doker Hub の PowerCLI Core コンテナ イメージ

https://hub.docker.com/r/vmware/powerclicore

 

そこで、今回は Kubernetes で PowerCLI コンテナを起動してみます。

 

今回の環境。

Kubernetes は、vSphere with Kubernetes によるスーパーバイザー クラスタを利用して、

コンテナは vSphere Pod として起動してみます。

 

スーパーバイザー クラスタの環境は下記のように構築しています。

vSphere with Kubernetes ラボ環境構築。(まとめ)

 

kubectl では、下記のようにスーパーバイザ クラスタに login してあります。

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

 

Kubernetes での PowerCLI の起動。

それでは、kubectl run コマンドで、Pod として起動します。

  • Pod の名前は「pcli01」にしています。
  • 「-it」を指定して、そのままコンテナに接続して対話的にコマンド実行できるようにします。
  • vmware/powerclicore コンテナ イメージを起動します。イメージは Docker Hub からダウンロードしているので、インターネットへの接続が必要です。
  • kubectl run コマンドに、「--restart=Never」オプションを指定すると、Pod(Deployment リソースではなく)として起動できます。
  • 「--rm」を指定すると、コンテナ終了と同時に Pod が自動削除されます。

 

Pod が起動されると、そのままコンテナの中の PowerShell プロンプトが表示されます。

$ kubectl run pcli01 --image=vmware/powerclicore -it --restart=Never --rm

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

PowerShell 7.0.0

Copyright (c) Microsoft Corporation. All rights reserved.

 

https://aka.ms/powershell

Type 'help' to get help.

 

PS /root>

 

これで、PowerCLI が利用できます。

※今回は CEIP の警告は無視しています。

PS /root> Connect-VIServer -Force -Server lab-vc-41.go-lab.jp

WARNING: Please consider joining the VMware Customer Experience Improvement Program, so you can help us make PowerCLI a better product. You can join using the following command:

 

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $true

 

VMware's Customer Experience Improvement Program ("CEIP") provides VMware with information that enables VMware to improve its products and services, to fix problems, and to advise you on how best to deploy and use our products.  As part of the CEIP, VMware collects technical information about your organization?s use of VMware products and services on a regular basis in association with your organization?s VMware license key(s).  This information does not personally identify any individual.

 

For more details: type "help about_ceip" to see the related help article.

 

To disable this warning and set your preference use the following command and restart PowerShell:

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $true or $false.

 

Specify Credential

Please specify server credential

User: administrator@vsphere.local ★ユーザー名とパスワードを入力。

Password for user administrator@vsphere.local: ********

 

Name                           Port  User

----                           ----  ----

lab-vc-41.go-lab.jp            443   VSPHERE.LOCAL\Administrator

 

PS /root>

 

接続した vCenter から、情報取得ができました。

ちなみに、今回はスーパーバイザー クラスタを管理している vCenter に接続しており、

VM の一覧には vSphere Pod(pcli01)も表示されています。

PS /root> Get-Cluster

 

Name                           HAEnabled  HAFailover DrsEnabled DrsAutomationLe

                                          Level                 vel

----                           ---------  ---------- ---------- ---------------

wcp-cluster-41                 True       1          True       FullyAutomated

 

PS /root> Get-VMHost

 

Name                 ConnectionState PowerState NumCpu CpuUsageMhz CpuTotalMhz

----                 --------------- ---------- ------ ----------- -----------

lab-wcp-esxi-41.go-… Connected       PoweredOn       2        4322        6000

lab-wcp-esxi-42.go-… Connected       PoweredOn       2        1526        4608

lab-wcp-esxi-43.go-… Connected       PoweredOn       2        1990        4608

 

PS /root> Get-VM

 

Name                 PowerState Num CPUs MemoryGB

----                 ---------- -------- --------

SupervisorControlPl… PoweredOn  2        8.000

SupervisorControlPl… PoweredOn  2        8.000

SupervisorControlPl… PoweredOn  2        8.000

pcli01               PoweredOn  1        0.500

 

vSphere Clinet でも、PowerCLI の vSphere Pod が起動されたことが確認できます。

k8s-powercli-01.png

 

PowerCLI では、vCenter Server に接続する際に DNS による名前解決が重要になります。

そこで、コンテナの中の DNS サーバ参照の設定を確認してみると、

Kubernetes の機能による DNS サーバのアドレスが指定されています。

これは、このラボの DNS サーバのアドレスではありません。

PS /root> cat /etc/resolv.conf

nameserver 10.96.0.254

search sc-ns-01.svc.cluster.local svc.cluster.local cluster.local

 

起動した Pod は、デフォルトで「dnsPolicy: ClusterFirst」が設定されます。

これにより、Kubernetes の機能による DNS サーバで名前解決できなくても、

外部の DNS サーバで名前解決できるようになっています。

 

dnsPolicy については、下記が参考になります。

https://kubernetes.io/ja/docs/concepts/services-networking/dns-pod-service/ 

 

ちなみにスーパーバイザー クラスタでは、外部の DNS サーバのアドレスは、

vSphere クラスタで「ワークロード管理」を有効化する際に設定したものです。

この設定は、kubectl get pods -o yaml といったコマンドラインや、

Pod 起動時の --dry-run -o yaml オプションなどで確認することもできます。

$ kubectl run pcli01 --image=vmware/powerclicore --restart=Never --dry-run -o yaml

apiVersion: v1

kind: Pod

metadata:

  creationTimestamp: null

  labels:

    run: pcli01

  name: pcli01

spec:

  containers:

  - image: vmware/powerclicore

    name: pcli01

    resources: {}

  dnsPolicy: ClusterFirst

  restartPolicy: Never

status: {}

 

vSphere Pod の YAML は、vSphere Client でも確認できます。

vSphere Pod の「サマリ」→「メタデータ」などから、Pod の YAML を表示できます。

k8s-powercli-02.png

 

dnsPolicy は ClusterFirst になっています。

k8s-powercli-03.png

 

ちなみに、この Pod から exit すると、自動的に Pod は停止 ~ 削除されます。(--rm オプションにより)

PS /root> exit

pod "pcli01" deleted

$

 

DNS サーバ設定を指定した Pod の起動。

Pod の DNS サーバ設定は、Pod 起動時に YAML で指定することもできます。

kubectl run であっても、下記のように Pod 起動時に、dnsPolicy と dnsConfig を上書きできたりします。

 

今回は、自宅ラボの DNS サーバのアドレスとして、192.168.1.101 と 192.168.1.102 を指定して、

見やすくなるように JSON 部分を整形してあります。

kubectl run pcli01 --image=vmware/powerclicore -it --restart=Never --rm --overrides='

{

  "apiVersion": "v1",

  "spec": {

    "dnsPolicy": "None",

    "dnsConfig": {

      "nameservers": ["192.168.1.101", "192.168.1.102"],

      "searches": ["go-lab.jp"]

    }

  }

}'

 

実際に実行してみると、下記のようになります。

起動後の Pod では、/etc/resolv.conf ファイルを確認すると、DNS サーバの設定が変更できています。

$ kubectl run pcli01 --image=vmware/powerclicore -it --restart=Never --rm --overrides='

> {

>   "apiVersion": "v1",

>   "spec": {

>     "dnsPolicy": "None",

>     "dnsConfig": {

>       "nameservers": ["192.168.1.101", "192.168.1.102"],

>       "searches": ["go-lab.jp"]

>     }

>   }

> }'

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

PowerShell 7.0.0

Copyright (c) Microsoft Corporation. All rights reserved.

 

https://aka.ms/powershell

Type 'help' to get help.

 

PS /root> cat /etc/resolv.conf

nameserver 192.168.1.101

nameserver 192.168.1.102

search go-lab.jp

PS /root>

 

vSphere Client で表示できる  Pod の YAML でも、同様に DNS 設定が変更できています。

k8s-powercli-04.png

 

vSphere with Kubernetes の動作確認やデモなどでも利用できそうかなと思います。

また、スーパーバイザー クラスタ特有の機能を利用するものではないので、

Kubernetes があればどこでも同じように PowerCLI コンテナが起動できるはず・・・

 

以上、Kubernetes で PowerCLI を起動してみる話でした。

vSphere 7.0 の新機能、vSphere with Kubernetes の自宅ラボ環境を構築した様子を伝えします。

vSphere with Kubernetes では、2種類の Kubernetes クラスタが利用できるようになります。

 

Supervisor Cluster

  • vSphere クラスタで「ワークロード管理」が有効化され、kubernetes の機能が追加されたもの。
  • vSphere 上で Kubernetes リソースを稼働させることができ、
    「名前空間」や vSphere Pod などが作成できるようになる。

 

Tanzu Kubernetes Cluster

  • スーパーバイザー クラスタの「名前空間」に、Tanzu Kubernetes Grid を利用して作成されるもの。
  • Kubernetes としてはわりと普通な「コンテナ ホストの VM」によるクラスタ。

wcp-00-k8s-image.png

 

下記の流れで、vSphere 環境に 2種類の Kubernetes クラスタを作成していきます。

 

はじめに。(今回のネステッド環境の紹介など)

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

 

vSphere / データストアまわりの準備。

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

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

 

NSX-T 関連の準備。

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

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

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

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

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

vSphere with Kubernetes ラボ環境構築。Part-09: Tier-0 ゲートウェイ作成編

 

vSphere クラスタでの「ワークロード管理」有効化。(Supervisor Cluster の作成)

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

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

 

Tanzu Kubernetes Cluster の作成。

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

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

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

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

 

 

それでは、1回目はこちら・・・

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

前回は、Tanzu Kubernetes Cluster に接続して、Pod を単独で起動してみました。

 

前回の投稿はこちら。

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

 

しかし、Kubernetes で Pod を起動する場合には、

Deployment や StatefulSet といったリソースを利用することが一般的だと思うので、今回は Deployment リソースから Pod を作成してみます。

なお、今回の一連の手順では Kubernetes の Namespace を省略しており、「default」Namespace 作業対象にしています。

 

Deployment 作成を試す。(PSP エラーになるパターン)

まず、ほぼデフォルト状態の Tanzu Kubernetes Cluster に、Deployment を作成してみます。

ただし、Tanzu Kubernetes Cluster ではアドミッション コントロールと呼ばれる機能が有効化されており、

この時点での Pod 作成は失敗してしまいます。

 

前回の投稿 でも実施したように、kubectl で Tanzu Kubernetes Cluster にログインして、

Context を切り替えておきます。

$ kubectl vsphere login --insecure-skip-tls-verify --server lab-wcp-01.go-lab.jp --tanzu-kubernetes-cluster-namespace lab-ns-02 --tanzu-kubernetes-cluster-name tkg-cluster-01

$ kubectl config use-context tkg-cluster-01

 

Nginx コンテナの Pod を、Deployment から起動する YAML ファイル(nginx-deploy.yml · GitHub)を用意します。

$ cat nginx-deploy.yml

---

kind: Deployment

apiVersion: apps/v1

metadata:

  name: tkc-demo

spec:

  replicas: 2

  selector:

    matchLabels:

      app: tkc-demo

  template:

    metadata:

      labels:

        app: tkc-demo

    spec:

      containers:

      - name: nginx-container

        image: nginx

        ports:

        - containerPort: 80

          protocol: TCP

 

Deployment を作成します。

$ kubectl apply -f nginx-deploy.yml

deployment.apps/tkc-demo created

 

Deployment では、Deployment → ReplicaSet → Pod といった順でリソースが作成されますが、

待っても Pod が起動されません。

$ kubectl get all

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

service/kubernetes   ClusterIP   198.48.0.1   <none>        443/TCP    17d

service/supervisor   ClusterIP   None         <none>        6443/TCP   17d

 

NAME                       READY   UP-TO-DATE   AVAILABLE   AGE

deployment.apps/tkc-demo   0/2     0            0           61s

 

NAME                                 DESIRED   CURRENT   READY   AGE

replicaset.apps/tkc-demo-659dff8bd   2         0         0       61s

 

これは、ReplicaSet を作成する時点で PodSecurityPolicy(pod security policy)に関係するエラーが発生しています。

$ kubectl describe replicasets tkc-demo-659dff8bd

Name:           tkc-demo-659dff8bd

Namespace:      default

Selector:       app=tkc-demo,pod-template-hash=659dff8bd

Labels:         app=tkc-demo

                pod-template-hash=659dff8bd

Annotations:    deployment.kubernetes.io/desired-replicas: 2

                deployment.kubernetes.io/max-replicas: 3

                deployment.kubernetes.io/revision: 1

Controlled By:  Deployment/tkc-demo

Replicas:       0 current / 2 desired

Pods Status:    0 Running / 0 Waiting / 0 Succeeded / 0 Failed

Pod Template:

  Labels:  app=tkc-demo

           pod-template-hash=659dff8bd

  Containers:

   nginx-container:

    Image:        nginx

    Port:         80/TCP

    Host Port:    0/TCP

    Environment:  <none>

    Mounts:       <none>

  Volumes:        <none>

Conditions:

  Type             Status  Reason

  ----             ------  ------

  ReplicaFailure   True    FailedCreate

Events:

  Type     Reason        Age                  From                   Message

  ----     ------        ----                 ----                   -------

  Warning  FailedCreate  39s (x15 over 2m1s)  replicaset-controller  Error creating: pods "tkc-demo-659dff8bd-" is forbidden: unable to validate against any pod security policy: []

 

エラーになった Deployment は、ひとまず削除しておきます。

$ kubectl delete -f nginx-deploy.yml

deployment.apps "tkc-demo" deleted

 

それでは、PodSecurityPolicy を使用してみます。

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

Tanzu Kubernetesクラスタでのポッド セキュリティ ポリシーの使用

 

PodSecurityPolicy(PSP)の確認。

それでは、Deployment から Pod が起動できるように、

PodSecurityPolicy(PSP)と Kubernetes のサービスアカウント(ServiceAccount)をひもづける RoleBindig を作成しておきます。

 

Tanzu Kubernetes Cluster には、デフォルトで PSP が2つ用意されており、

vmware-system-privileged と vmware-system-restricted が作成されています。

$ kubectl get podsecuritypolicies

NAME                       PRIV    CAPS   SELINUX    RUNASUSER          FSGROUP     SUPGROUP    READONLYROOTFS   VOLUMES

vmware-system-privileged   true    *      RunAsAny   RunAsAny           RunAsAny    RunAsAny    false            *

vmware-system-restricted   false          RunAsAny   MustRunAsNonRoot   MustRunAs   MustRunAs   false            configMap,emptyDir,projected,secret,downwardAPI,persistentVolumeClaim

 

今回は root ユーザとして Pod を起動できる vmware-system-privileged を指定します。

ちなみに、もう一つの vmware-system-restricted が指定されている状態で root で Pod 起動しようとすると、

Pod のイベントとして、下記のようなエラーが発生します。

Error: container has runAsNonRoot and image will run as root

 

RoleBinding の作成。

PSP を指定した RoleBinding を作成します。

 

下記のような YAML ファイル(tkc-rb-privileged.yml · GitHub)を用意しておきます。

  • RoleBinding の名前は rb-vmware-system-privileged を指定。
  • roleRef には、ClusterRole「psp:vmware-system-privileged」を指定。
  • subjects には system:serviceaccounts Group(すべてのサービスアカウントが含まれる)を指定。

$ cat tkc-rb-privileged.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

 

roleRef で指定している ClusterRole「psp:vmware-system-privileged」では、

resourceNames に PSP「vmware-system-privileged」が指定されています。

この ClusterRole も、デフォルトで作成されているものです。

$ kubectl get clusterrole psp:vmware-system-privileged -o yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: ClusterRole

metadata:

  creationTimestamp: "2020-07-30T03:36:50Z"

  name: psp:vmware-system-privileged

  resourceVersion: "480"

  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/psp%3Avmware-system-privileged

  uid: 391f6160-44c8-4bcc-b776-184b17dce8d6

rules:

- apiGroups:

  - policy

  resourceNames:

  - vmware-system-privileged

  resources:

  - podsecuritypolicies

  verbs:

  - use

 

それでは、RoleBindig を作成します。

$ kubectl apply -f tkc-rb-privileged.yml

rolebinding.rbac.authorization.k8s.io/rb-vmware-system-privileged created

 

Deployment 作成を試す。(リトライ)

あらためて、Deployment を作成します。

$ kubectl apply -f nginx-deploy.yml

deployment.apps/tkc-demo created

 

今度は、Deployment から Pod が起動されました。

$ kubectl get all

NAME                            READY   STATUS    RESTARTS   AGE

pod/tkc-demo-6b459d8b8d-8hfbb   1/1     Running   0          10s

pod/tkc-demo-6b459d8b8d-q7cq5   1/1     Running   0          10s

 

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

service/kubernetes   ClusterIP   198.48.0.1   <none>        443/TCP    17d

service/supervisor   ClusterIP   None         <none>        6443/TCP   17d

 

NAME                       READY   UP-TO-DATE   AVAILABLE   AGE

deployment.apps/tkc-demo   2/2     2            2           11s

 

NAME                                  DESIRED   CURRENT   READY   AGE

replicaset.apps/tkc-demo-6b459d8b8d   2         2         2       11s

 

これで、アドミッション コントロールなしの Kubernetes クラスタと同様にワークロード展開できるはずです。

また、今回は RoleBindig を作成しましたが、デモ環境などであれば

ClusterRoleBinding でクラスタ全体の設定にしてもよいと思います。

 

以上、vSphere with Kubernetes と Tanzu Kubernetes Cluster のラボ環境構築でした。

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

 

前回はこちら。

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

 

今回は、作成した Tanzu Kubernetes Cluster に接続して、Pod を起動してみます。

 

Tanzu Kubernetes Cluster は作成ずみです。

※なお、前回の手順で作成していますが、再作成しているのでノードの名前が異なります。

wcp-14-01.png

 

Tanzu Kubernetes Cluster への接続。

kubectl で、Tanzu Kubernetes Cluster に接続します。

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

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

 

login では、Supervisor Cluster に接続する場合のコマンドラインに、

追加で下記のオプションを指定しています。

  • --tanzu-kubernetes-cluster-namespace=lab-ns-02
  • --tanzu-kubernetes-cluster-name=tkg-cluster-01

Tanzu Kubernetes Cluster の名前は、名前空間ごとに一意になるので、

「--tanzu-kubernetes-cluster-name」だけでなく、

名前空間の名前「--tanzu-kubernetes-cluster-namespace」も指定する必要があります。

$ kubectl vsphere login --insecure-skip-tls-verify --server=192.168.70.33 --tanzu-kubernetes-cluster-namespace=lab-ns-02 --tanzu-kubernetes-cluster-name=tkg-cluster-01

 

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

   tkg-cluster-01

 

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>`

$

 

Kubernetes クラスタを構成するノードの確認。

context  を明示的に指定して get nodes でノードの確認をしてみます。

Tanzu Kubernetes Cluster では、下記のように、デプロイされた VM によって、

Supervisor Cluster とは別の Kubernetes クラスタが構成されていることが分かります。

$ kubectl --context tkg-cluster-01 get nodes

NAME                                            STATUS   ROLES    AGE   VERSION

tkg-cluster-01-control-plane-5w6vn              Ready    master   13h   v1.16.8+vmware.1

tkg-cluster-01-control-plane-p89lb              Ready    master   12h   v1.16.8+vmware.1

tkg-cluster-01-control-plane-phd6l              Ready    master   12h   v1.16.8+vmware.1

tkg-cluster-01-workers-l6qtc-586578bd88-5d7kh   Ready    <none>   12h   v1.16.8+vmware.1

tkg-cluster-01-workers-l6qtc-586578bd88-czrpg   Ready    <none>   12h   v1.16.8+vmware.1

tkg-cluster-01-workers-l6qtc-586578bd88-vk6f8   Ready    <none>   12h   v1.16.8+vmware.1

 

あらためて、Tanzu Kubernetes Cluster(tkg-cluster-01)の外側の context(lab-ns-02 名前空間と同名)を指定して、

Kubernetes ノードを確認しておきます。

こちらは、ESXi と Supervisor Control Plane VM で、Kubernetes のクラスタが構成されています。

$ kubectl --context lab-ns-02 get nodes

NAME                               STATUS   ROLES    AGE   VERSION

422c6912a62eabbf0a45c417405308c9   Ready    master   67d   v1.17.4-2+a00aae1e6a4a69

422c9d9222c60e5328cdc12a543c099a   Ready    master   67d   v1.17.4-2+a00aae1e6a4a69

422cfbc654627c47880a2ec7ae144424   Ready    master   67d   v1.17.4-2+a00aae1e6a4a69

lab-wcp-esxi-031.go-lab.jp         Ready    agent    67d   v1.17.4-sph-091e39b

lab-wcp-esxi-032.go-lab.jp         Ready    agent    67d   v1.17.4-sph-091e39b

lab-wcp-esxi-033.go-lab.jp         Ready    agent    67d   v1.17.4-sph-091e39b

 

Tanzu Kubernetes Cluster での Pod 起動。

以前に vSphere Pod を起動した YAML ファイルで、

tkg-cluster-01 上に Pod を起動してみます。

 

YAML ファイルの内容は、下記のようになっています。

$ cat nginx-pod.yml

---

kind: Pod

apiVersion: v1

metadata:

  name: nginx-pod

  labels:

    app: wcp-demo

spec:

  containers:

  - image: nginx

    name: nginx-container

 

kubectl で操作する context を tkg-cluster-01 に切り替えます。

$ kubectl config use-context tkg-cluster-01

Switched to context "tkg-cluster-01".

 

それでは、Pod を起動します。

$ kubectl apply -f nginx-pod.yml

pod/nginx-pod created

 

tkg-cluster-01 クラスタのノード(tkg-cluster-01-workers-~)で起動されました。

$ kubectl get pods -o wide

NAME        READY   STATUS    RESTARTS   AGE   IP            NODE                                            NOMINATED NODE   READINESS GATES

nginx-pod   1/1     Running   0          40s   192.0.175.2   tkg-cluster-01-workers-l6qtc-586578bd88-vk6f8   <none>           <none>

 

一方、vSphere Client で確認すると、(vSphere Pod の場合ような)Pod の確認はできません。

vSphere Pod の場合には、インベントリや下記の赤枠のあたりで、起動された Pod が表示されていました。

しかし、Tanzu Kubernetes Cluster の Pod(そして他の Kubernete リソースも)は、

この「コア Kubernetes」の画面には表示されません。

wcp-14-02.png

 

これは、Pod が VM(この環境では、「tkg-cluster-01-workers-~」)の内部で起動されているためです。

vSphere Pod は、Pod が特殊な VM として作成されるので vSphere Client での視認性がよかったのですが、

Tanzu Kubernetes Cluster では、よくある「Docker をインストールした VM」と同様、

Pod がコンテナホストになる VM の内部で起動されるので、

特に「vSphere ならではの見やすさ」はありません。

そこで、リソースの確認には Octant(https://github.com/vmware-tanzu/octant)などの

Kubernetes 可視化ツールがあると便利です。

 

まだ続きそう。

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

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

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

 

前回はこちら。

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

 

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

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

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

 

Supervisor Cluster への接続。

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

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

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

 

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

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

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

 

環境の確認。

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

 

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

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

$ kubectl config use-context lab-ns-02

Switched to context "lab-ns-02".

 

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

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

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

$ kubectl get storageclasses

NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE

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

 

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

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

$ kubectl get virtualmachineimages

NAME                                                        VERSION                          OSTYPE

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

 

Tanzu Kuberntes Cluster の YAML 作成。

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

 

tkg-cluster-01.yml

---

kind: TanzuKubernetesCluster

apiVersion: run.tanzu.vmware.com/v1alpha1

metadata:

  name: tkg-cluster-01

spec:

  distribution:

    version: v1.16.8

  topology:

    controlPlane:

      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

    workers:

      count: 3

      class: best-effort-xsmall

      storageClass: vm-storage-policy-wcp

  settings:

    network:

      cni:

        name: calico

      services:

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

      pods:

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

    storage:

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

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

 

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

 

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

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

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

  • spec.distribution.version

 

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

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

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

 

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

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

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

 

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

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

 

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

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

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

 

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

$ kubectl get virtualmachineclasses

NAME                 AGE

best-effort-large    12d

best-effort-medium   12d

best-effort-small    12d

best-effort-xlarge   12d

best-effort-xsmall   12d

guaranteed-large     12d

guaranteed-medium    12d

guaranteed-small     12d

guaranteed-xlarge    12d

guaranteed-xsmall    12d

 

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

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

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

apiVersion: vmoperator.vmware.com/v1alpha1

kind: VirtualMachineClass

metadata:

  annotations:

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

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

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

  generation: 1

  name: best-effort-xsmall

  resourceVersion: "2182"

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

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

spec:

  hardware:

    cpus: 2

    memory: 2Gi

 

Tanzu Kubernetes Cluster の作成。

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

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

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

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

 

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

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

wcp-12-28.png

 

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

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

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

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

wcp-12-30.png

 

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

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

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

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

wcp-12-31.png

 

続く?

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

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

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

 

前回の投稿はこちら。

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

 

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

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

wcp-01-p01.png

 

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

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

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

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

 

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

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

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

 

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

 

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

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

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

 

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

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

wcp-12-01.png

 

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

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

wcp-12-03.png

 

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

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

wcp-12-04.png

 

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

wcp-12-06.png

 

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

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

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

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

 

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

wcp-12-10.png

 

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

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

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

wcp-12-11.png

 

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

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

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

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

wcp-12-22.png

 

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

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

wcp-12-23.png

 

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

wcp-12-24.png

 

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

wcp-12-25.png

 

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

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

$ kubectl get virtualmachineimages

NAME                                                        VERSION                          OSTYPE

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

 

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

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

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

 

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

wcp-10-43.png

 

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

wcp-10-44.png

 

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

wcp-10-45.png

 

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

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

$ kubectl get storageclasses

NAME                    PROVISIONER              RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE

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

 

つづく・・・。

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