Skip navigation
2020

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

これまでは、前提環境をととのえるための準備でしたが、

今回は、Supervisor Cluster を有効化します。

 

前回の投稿はこちら。

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

 

Supervisor Cluster の有効化。

Supervisor Cluster は、vSphere Client の「ワークロード管理」から有効化します。

(むしろ「ワークロード管理」を有効化します)

 

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

wcp-10-05.png

 

「ワークロード管理」で、「有効化」をクリックします。

wcp-10-06.png

 

これまでの準備により「互換性あり」に vSphere Cluster が表示されるはずなので、

「wcp-cluster-01」を選択して「次へ」をクリックします。

wcp-10-07.png

 

制御プレーンのサイズ(Supervisor Control Plane VM のスペック)を選択します。

今回はハードウェア リソースの都合上「極小」を選択しています。

wcp-10-08.png

 

ネットワークの設定をします。

管理ネットワークは、次のようなパラメータを入力しています。

  • ネットワーク: DPortGroup-labmgmt-0010
    • vCenter などと通信できる、管理ネットワークのポートグループを指定する。
    • Supervisor Control Plane VM の 1つめの vNIC に割り当てられる。
  • 開始 IP アドレス: 192.168.10.51
    • Supervisor Control Plane VM に付与される IP アドレス。
    • 開始 IP アドレスから 5つ消費する。
      • Supervisor Control Plane VM の Floating IP アドレス。(1つ。開始 IP アドレスが使用される)
      • Supervisor Control Plane VM 3台の IP アドレス。3つ。今回は .52 ~ .54)
      • アップグレード時の予約。(1つ。今回は .55)
  • サブネットマスク: 255.255.255.0(「開始 IP アドレス」のネットワークでのサブネット マスク)
  • ゲートウェイ: 192.168.10.1(「開始 IP アドレス」のネットワークでのサブネット マスク)
  • DNS サーバ: (カンマ区切りで DNS サーバを指定)
  • DNS 検索ドメイン: go-lab.jp
  • NTP サーバ: (カンマ区切りで DNS サーバを指定)

wcp-10-09.png

 

下にスクロールし、

ワークロード ネットワークは、次のようなパラメータを入力しています。

  • vSphere Distributed Switch: DSwitch
  • Edge クラスタ: edge-cluster-01
  • API サーバのエンドポイント FQDN: lab-wcp-01.go-lab.jp
    • Supervisor Control Plane VM の Floating IP にアクセスすると、
      ここで指定した名前が証明書 Subject Alternative Name に設定されていたりする。
  • DNS サーバ: (カンマ区切りで DNS サーバを指定)
  • ポッド CIDR: 10.244.0.0/21(デフォルトのまま)
    • Pod のネットワークが、このレンジから払い出される。
  • サービス CIDR: 10.96.0.0/24(デフォルトのまま)
    • Kubernetes 内部通信の ClusterIP で利用される。
  • 入力方向 CIDR:192.168.70.32/27
    • Tier-0 ゲートウェイの外部インターフェイス(Edge のアップリンク)と同セグメントから、/27 以上のレンジを指定する。
    • NSX ロードバランサによる VIP に払い出される。
    • Supervisor Control Plane VM の VIP は、この CIDR の最初の IP アドレス(192.168.70.33)になる。
  • 出力方向 CIDR: 192.168.70.64/27
    • Tier-0 ゲートウェイの外部インターフェイス(Edge のアップリンク)と同セグメントから、/27 以上のレンジを指定する。
    • NSX では Tier-1 ゲートウェイの SNAT アドレスとして利用される。

wcp-10-11.png

 

ストレージでは、下記の 3つのデータストアを指定するため、

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

ここでは、以前の投稿で作成した「vm-storage-policy-wcp」を指定しています。

  • 制御プレーン ノード(Supervisor Control Plane VM の VMDK を配置するデータストア)
  • 短期ディスク(vSphere Pod で利用するデータストア)
  • イメージ キャッシュ(コンテナ イメージのキャッシュ)

wcp-10-14.png

 

設定値を確認して「完了」をクリックすると、Supervisor Cluster の有効化がはじまります。

wcp-10-15.png

 

「クラスタ」タブで、構成ステータスが確認できます。

開始直後、「最近のタスク」にリモートファイルのダウンロードで 404 エラーが表示されますが、これは無視します。

wcp-10-19.png

 

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

ちなみに、ESXi が 4台以上あるクラスタでも、Control Plane VM は 3台です。

wcp-10-20.png

 

有効化処理がうまくいかない場合は、vCenter に root ユーザでログインして、

まず下記のログを確認してみるとよいと思います。

  • ログファイル: /var/log/vmware/wcp/wcpsvc.log

 

しばらく(数十分 ~ 数時間)待つと、「構成ステータス」が「実行中」になり、

「制御プレーン ノード」の IP アドレスが、最終的に「入力方向 CIDR」で指定したレンジの IP アドレスになります。

「現在のバージョン」には、Supervisor Cluster の Kubernetes バージョンが表示されています。

wcp-10-22.png

 

これで wcp-cluster-01 クラスタで、Supervisor Cluster の機能が有効化されました。

 

名前空間の作成。

「ワークロード管理」メニューの「名前空間」タブを開くと、

「名前空間の作成」が表示されるので、クリックします。

wcp-10-23.png

 

クラスタを選択して、名前空間の名前(ここでは lab-ns-01)を入力して「作成」をクリックします。

wcp-10-31.png

 

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

「ステータス」→「CLI ツールへのリンク」にある、「開く」をクリックします。

wcp-10-32.png

 

「Kubernetes CLI Tools」という、

専用 kubectl のダウンロード ページが表示されるはずです。

wcp-10-33.png

 

これでひとまず、vSphere with Kubernetes を体験するためのラボ環境が構築できました。

このページが表示されていない場合は、Supervisor Cluster の有効化が成功していても

NSX-T や物理ネットワークなどの構成がうまくできていない可能性があります。

 

ちなみに名前空間は、Supervisor Cluster を有効化したクラスタの右クリック →「新規名前空間」でも作成できます。

wcp-10-41.png

 

以上、vSphere 7.0 + NSX-T 3.0 で Supervisor Cluster の有効化でした。

おそらくつづく。

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

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

今回は、NSX の Tier-0 ゲートウェイを作成します。

 

前回はこちら。

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

 

ここでは、Supervisor Cluster を有効化する前提として必要な

NSX-T によるネットワークを作成しておきます。

 

VLAN セグメントの作成。

Tier-0 ゲートウェイのアップリンク インターフェースを接続する

VLAN セグメントを作成しておきます。

これは、NSX Edge から NSX 外部のネットワークに接続する VLAN になります。

 

NSX Manager にログインして、

「ネットワーク」→「接続」→「セグメント」を開きます。

「セグメント」タブの「セグメントの追加」をクリックして、パラメータを入力していきます。

パラメータは、今回のラボ環境にわせて下記のようにしています。

  • セグメント名: seg-vlan0070
  • 接続: なし(デフォルトのまま)
  • トランスポート ゾーン: nsx-vlan-transportzone
  • VLAN: 70

wcp-08-03.png

 

少し下にスクロールして、「保存」をクリックします。

wcp-08-04.png

 

「この Segment の設定を続行しますか?」を「いいえ」で抜けると、

VLAN セグメントが作成されたことが確認できます。

wcp-08-06.png

 

Tier-0 ゲートウェイの作成。

「ネットワーク」→「接続」→「Tier-0 ゲートウェイ」を開き、

「ゲートウェイの追加」→「Tier-0」をクリックします。

 

つぎのようにパラメータを入力して、「保存」をクリックします。

  • Tier-0 ゲートウェイの名前: t0gw-01
  • HA モード: アクティブ/スタンバイ
  • Edge クラスタ: edge-cluster-01

wcp-08-14.png

 

「この Tier-0 ゲートウェイの設定を続行しますか?」では、

「はい」を選択して、つづけてインターフェースの追加を実施します。

wcp-08-15.png

 

Edge の外部インターフェイスの追加。

NSX Edge のアップリンクにあたる、「外部インターフェイス」を作成します。

 

「インターフェイス」→「設定」をクリックします。

wcp-08-16.png

 

「インターフェイスの追加」をクリックし、パラメータを入力してから「保存」をクリックします。

  • 名前: if-uplink-01
  • タイプ: 外部(デフォルトのまま)
  • IP アドレス/マスク: 192.168.70.2/24
  • 接続先: seg-vlan0070
  • Edge ノード: lab-nsx-edge-31

wcp-08-18.png

 

インターフェイスが作成されたこと確認して、「閉じる」をクリックします。

wcp-08-20.png

 

スタティック ルートの設定。

このラボでは、ルーティング プロトコル(BGP)を利用していないので、

NSX 外部のネットワークと Edge のアップリンク ネットワーク

(この直前に作成したインターフェイスの接続されているネットワーク)とでルーティングが必要になります。

そこで、今回はスタティック ルート設定しています。

 

まだ編集途中の Tier-0 ゲートウェイの画面で

「ルーティング」→「スタティック ルート」のとなりの「設定」をクリックします。

wcp-08-21.png

 

「スタティック ルートの追加」をクリックして、

次のようなパラメータを入力して「ネクスト ホップの設定」をクリックします。

  • 名前: default-route
  • ネットワーク: 0.0.0.0/0

wcp-08-23.png

 

「ネクスト ホップの追加」をクリックして、

IP アドレスを入力(このラボ環境では 192.168.70.1)入力してから

「追加」→「適用」をクリックして閉じます。

wcp-08-24.png

 

「ホップ数: 1」と表示されたことを確認してから、

「保存」→「閉じる」をクリックします。

wcp-08-26.png

 

スタティック ルートに「1」と表示されたことを確認して、

「編集を終了」をクリックします。

wcp-08-28.png

 

Edge のアップリンク インターフェイスへの疎通確認。

これで、NSX-T の Tier-0 ゲートウェイとそのアップリンク インターフェイスが作成できたので、

直近で作成したインターフェイス(192.168.70.2)の疎通確認をしておきます。

 

たとえば、最終的に Kubernetes 環境を構築したあとで、

kubectl(kubernetes のクライアント ツール)を実行する想定の端末から

ping 確認などをしておきます。

 

つづく!

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

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

今回は、前回デプロイした NSX Edge を、トランスポート ノードとして設定します。

 

前回はこちら。

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

 

Edge 用 アップリンク プロファイルの作成。

NSX Edge は、以前に設定した ESXi とは NIC 数やチーミング ポリシー、

TEP の接続するネットワーク(VLAN ID)が異なったりするので、

別のアップリンク プロファイルを追加作成します。

※ただし、今回の構成では ESXi の TEP / Edge の TEP 両方が 同じ VLAN です。

 

NSX Manager にログインして、

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

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

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

 

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

wcp-07-12.png

 

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

  • アクティブ アップリンク: uplink-1
  • スタンバイ アップリンク: 空欄のまま(Edge VM は、仮想スイッチ / ポートグループ側でのチーミングとなるので)

 

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

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

wcp-07-13.png

 

Edge 用のアップリンク プロファイルが作成されました。

wcp-07-14.png

 

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

NSX Edge の、トランスポート ノードとしての設定をすすめます。

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

デプロイずみの NSX Edge(lab-nsx-edge-31)の「NSX の設定」をクリックします。

wcp-07-21.png

 

「Edge トランスポート ノードの編集」で、

「ノード スイッチの作成」についてパラメータを入力していきます。

  • Edge スイッチ名: (デフォルトのまま)nvds1
  • トランスポート ゾーン: nsx-overlay-transportzone、nsx-vlan-transportzone
    (ESXi とは異なり、オーバーレイ と VLAN 両方のトランスポート ゾーンを選択します)

wcp-07-23.png

 

少し下にスクロールし、次のように入力して「保存」をクリックします。

  • アップリンク プロファイル: uplink-profile-edge
  • IP の割り当て: IP プールを使用
  • IP プール: ip-pool-tep
  • チーミング ポリシー スイッチ マッピング → uplink-1: fp-eth0 (Edge VM の 2つめの vNIC にあたります)

wcp-07-24.png

 

少し待って、画面下の「更新」をクリックすると、

設定の状態が「成功」になるはずです。

wcp-07-26.png

 

Edge クラスタの作成。

NSX の Edge トランスポート ノードは、「Edge クラスタ」単位で管理します。

通常は複数台の Edge トランスポート ノードを用意して Edge クラスタを構成します。

 

このラボは、ハードウェア リソースの都合もあり 1台だけです。

しかし NSX-T では、 Edge クラスタを構成する必要があるので、

Edge トランスポート ノードが 1台だけの Edge クラスタを作成しておきます。

 

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

「追加」をクリックして「Edge クラスタの追加」を開き、

次のようにパラメータを入力して、「追加」をクリックします。

  • 名前: edge-cluster-01
  • Edge クラスタ プロファイル: デフォルトのまま
  • トランスポート ノード: デフォルトのまま
  • 選択済み: lab-nsx-edge-31(対象の Edge ノードを選択して「>」ボタンで移動する)

wcp-07-33.png

 

これで、Edge クラスタが作成されます。

wcp-07-34.png

 

まだまだ続く。

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

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

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

 

前回はこちら。

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

 

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

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

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

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

wcp-07-image.png

 

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

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

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

 

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

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

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

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

 

NSX Manager にログインして、

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

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

wcp-06-01.png

 

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

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

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

wcp-06-03.png

 

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

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

get certificate api thumbprint

 

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

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

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

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

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

このポートグループは、分散仮想スイッチ(vDS)と、標準仮想スイッチ(vSS)の、

どちらに作成しても、ラボ環境を構築できます。

 

今回は vSS に標準ポートグループを作成します。

まず、この vSS も NSX-T のオーバーレイ ネットワークの経路となるので、

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

wcp-06-16.png

 

NSX Edge の管理ネットワーク用のポートグループ(ここでは pg-labmgmt-0010)を作成しておきます。

これは Edge VM の 1つめの vNIC に割り当てることになります。

wcp-06-19.png

 

アップリンク用の標準ポートグループ(名前は pg-edge-uplink)を作成します。

VLAN トランクとしたいので、VLAN ID を「すべて (4095)」としています。

※ vDS の分散ポートグループの場合は、VLAN トランクで ID を「0 - 4094」にします。

wcp-06-13.png

 

アップリンク用の標準ポートグループは、

作成後に、無差別モードと偽装転送を「承諾」にしておきます。

このポートグループは Edge VM の 2つめ(から4つめ)の vNIC に割り当てることになります。

wcp-06-18.png

 

NSX Edge の OVA ファイルのデプロイ。

NSX Edge の OVA ファイルを、vSphere Client からデプロイします。

OVA ファイルは「nsx-edge-<バージョン文字列>.ova」となっています。

 

デプロイ先(クラスタや ESXi など)を右クリックして、

「OVF テンプレートのデプロイ」から、一般的な OVA ファイルと同様の手順でデプロイします。

wcp-06-21.png

 

ウィザードにしたがって、デプロイのフォルダやデータストアなどのパラメータを入力していきます。

(一般的な OVA ファイルのデプロイと変わらない部分は、省略しています)

 

「デプロイ構成の選択」では、かならず「Large」以上を選択します。

vCPU が最低でも 8以上でないと、リソース不足により Supervisor Cluster の有効化が失敗します。

ちなみに、メモリ容量はあとで削減可能です。(20GB くらいまでなら)

wcp-06-28.png

 

ポートグループは、先ほど選択したものを割り当てます。

vNIC の番号(ソースネットワーク)が降順表示になっているので注意します。

「Network 0」が、1つめの vNIC です。

 

つぎのように割り当てます。

  • Network 3: pg-edge-uplink
  • Network 2: pg-edge-uplink
  • Network 1: pg-edge-uplink
  • Network 0: pg-labmgmt-0010

wcp-06-30.png

 

「テンプレートのカスタマイズ」では、NSX Edge 固有のパラメータを入力します。

今回は、次のようにパラメータを入力します。

※これ以外のパラメータは、デフォルト値のままか、空欄のままです。

※ネットワーク関連のパラメータは、このラボのものなので環境にあわせて変更が必要です。

 

  • System Root User Password: Edge のゲスト OS にログインする、root ユーザのパスワード。
  • CLI “admin” User Password: Edge のゲスト OS にログインする、admin ユーザのパスワード。
  • Manager IP: NSX Manager の IP アドレス(今回は 192.168.10.23)。
  • Manager Password: NSX Manager の admin ユーザのパスワード。
  • Manager Thumbprint: 冒頭の手順で確認した、NSX Manager の証明書サムプリント(64文字)

 

  • Hostname: lab-nsx-edge-31
  • Default IPv4 Gateway: 192.168.10.1
  • Management Network IPv4 Address: 192.168.10.41
  • Management Network Netmask: 255.255.255.0
  • DNS Server list: スペース区切りで DNS アドレス。
  • Domain Search List: go-lab.jp
  • NTP Server List: スペース区切りで NTP アドレス。
  • Enable SSH: On
  • Allow root SSH logins: On

 

デプロイが完了したら、Edge VM をパワーオンします。

wcp-06-42.png

 

NSX Manager の

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

そして、「Edge トランスポート ノード」にデプロイしたエッジが表示されます。

まだ NSX Edge の設定が必要な状態で、「設定の状態」には「!」マークが表示されます。

wcp-06-45.png

 

つづく・・・

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

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

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

 

前回はこちら。

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

 

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

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

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

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

wcp-06-image.png

 

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

NSX Manager にログインして、

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

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

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

 

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

wcp-05-02.png

 

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

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

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

 

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

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

wcp-05-03.png

 

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

wcp-05-04.png

 

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

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

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

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

 

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

wcp-05-22.png

 

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

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

wcp-05-23.png

 

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

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

wcp-05-24.png

 

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

wcp-05-25.png

 

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

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

 

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

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

 

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

wcp-05-31.png

 

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

wcp-05-32.png

 

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

wcp-05-33.png

 

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

wcp-05-34.png

 

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

wcp-05-36.png

 

まだつづく。

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

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

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

 

前回はこちら。

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

 

vCenter の追加。

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

 

(前回の図をもう一度。)

wcp-04-image-02.png

 

NSX Manager にログインして、

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

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

 

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

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

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

wcp-04-32.png

 

vCenter が追加されました。

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

wcp-04-35.png

 

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

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

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

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

wcp-04-36.png

 

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

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

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

 

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

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

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

 

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

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

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

wcp-04-41.png

 

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

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

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

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

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

 

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

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

 

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

  • 名前: ip-pool-tep

 

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

wcp-04-52.png

 

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

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

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

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

 

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

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

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

 

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

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

wcp-04-54.png

 

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

wcp-04-55.png

 

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

wcp-04-56.png

 

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

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

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

wcp-04-57.png

 

まだ続く。

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

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

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

 

前回はこちら。

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

 

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

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

wcp-04-image-01.png

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

 

NSX-T 3.0 評価版の入手。

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

 

VMware NSX-T Product Evaluation Center

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

 

NSX Manager のデプロイ。

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

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

wcp-04-image-02.png

 

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

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

 

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

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

 

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

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

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

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

 

補足として・・・

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

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

wcp-04-06.png

 

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

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

wcp-04-21.png

 

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

wcp-04-16.png

 

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

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

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

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

wcp-04-26.png

 

つづく。

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

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

 

前回の投稿はこちら。

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

 

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

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

 

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

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

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

wcp-03-41.png

 

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

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

 

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

 

vSphere の「タグ」作成。

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

wcp-03-02.png

 

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

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

wcp-03-04.png

 

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

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

wcp-03-06.png

 

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

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

wcp-03-07.png

 

タグが作成されました。

wcp-03-08.png

 

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

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

wcp-03-09.png

 

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

wcp-03-10.png

 

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

wcp-03-11.png

 

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

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

wcp-03-21.png

 

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

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

wcp-03-22.png

 

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

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

wcp-03-23.png

 

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

wcp-03-24.png

 

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

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

wcp-03-27.png

 

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

wcp-03-28.png

 

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

wcp-03-30.png

 

続く。

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

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

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

 

前回はこちら。

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

 

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

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

 

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

wcp-02_lab-image.png

 

vSphere DRS の有効化。

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

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

 

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

wcp-02-01.png

 

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

wcp-02-02.png

 

vSphere HA の有効化。

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

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

 

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

wcp-02-03.png

 

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

wcp-02-04.png

 

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

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

 

das.ignoreinsufficienthbdatastore = true

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

 

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

wcp-02-05.png

 

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

wcp-02-09.png

 

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

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

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

 

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

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

 

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

wcp-02-21.png

 

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

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

wcp-02-22.png

 

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

wcp-02-23.png

 

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

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

 

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

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

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

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

 

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

wcp-02-24.png

 

つづく・・・

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

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

vSphere with Kubernetesの設定と管理

vSphere with Kubernetes Configuration and Management (英語の原文)

 

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

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

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

 

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

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

 

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

 

vSphere Pod

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

 

Tanzu Kubernetes Cluster

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

 

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

wcp-01-p01.png

 

環境説明。

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

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

 

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

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

wcp-01-p02.png

 

サーバ構成。

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

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

 

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

wcp-01-p03.png

 

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

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

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

バージョンは下記です。

  • vCenter Server 7.0.0a
  • ESXi 7.0 GA

wcp-00-02.png

 

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

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

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

wcp-00-03.png

 

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

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

wcp-00-05.png

 

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

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

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

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

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

wcp-00-01.png

 

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

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

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

wcp-00-07.png

 

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

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

wcp-00-06.png

 

つづく。

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

 

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

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

 

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

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

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

https://octant.dev/

 

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

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

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

 

1. 環境準備。

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

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

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

 

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

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

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

NAME                             STATUS     ROLES    AGE   VERSION

capvdemo-9cmld                   NotReady   master   15h   v1.17.3

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

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

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

 

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

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

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

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

NAME                             STATUS     ROLES    AGE   VERSION

capvdemo-9cmld                   NotReady   master   15h   v1.17.3

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

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

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

 

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

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

NAMESPACE     NAME                                     READY   STATUS    RESTARTS   AGE

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

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

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

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

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

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

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

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

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

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

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

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

 

2. Octant むけ Secret の作成。

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

 

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

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

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

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

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

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

NAME                TYPE     DATA   AGE

octant-kubeconfig   Opaque   1      16s

 

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

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

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

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

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

serviceaccount/antctl created

serviceaccount/antrea-agent created

serviceaccount/antrea-controller created

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

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

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

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

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

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

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

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

configmap/antrea-config-m8cb9g82tf created

service/antrea created

deployment.apps/antrea-controller created

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

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

daemonset.apps/antrea-agent created

 

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

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

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

service/antrea-octant created

deployment.apps/antrea-octant created

 

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

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

NAME                             STATUS   ROLES    AGE   VERSION

capvdemo-9cmld                   Ready    master   16h   v1.17.3

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

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

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

 

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

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

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

NAME                                     READY   STATUS    RESTARTS   AGE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

NAME                READY   UP-TO-DATE   AVAILABLE   AGE

antrea-controller   1/1     1            1           17m

antrea-octant       1/1     1            1           17m

coredns             2/2     2            2           16h

 

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

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

antrea-otant-01.png

 

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

antrea-otant-05.png

 

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

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

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

antrea-otant-04.png

 

Antrea Controller の情報や・・・

antrea-otant-02.png

 

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

antrea-otant-03.png

 

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

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

antrea-otant-13.png

 

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

antrea-otant-15.png

 

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

antrea-otant-16.png

 

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