Quantcast
Channel: にほんごVMware
Viewing all 495 articles
Browse latest View live

vSAN のつぶやき。 Advent Calendar 2019 - ふりかえり。

$
0
0

昨年の12月のクリスマス シーズンに、ひたすら vSAN 6.7 の Tips をつぶやく Advent Calendar を試みてみました。

これは「Twitter 140文字+スクリーンショット4枚+Adventar のコメント」という割とシンプルなコンテンツです。

1ヶ月くらいたったので、少し振り返っておこうかと思います。

vSAN のつぶやき。 Advent Calendar 2019 - Adventar

 

なお、一昨年の2018年末にも、

ひたすら色々なパターンでネステッド vSAN をつくって様子を投稿していました。

Nested vSAN Advent Calendar 2018 - Adventar

ネステッド vSAN 6.7 U1 を楽しむ。まとめ

 

毎日投稿するコンテンツなので、2019 年版は省エネ働き方改革をねらったものの、

コンテンツのボリュームは少ないのですが、検証&作文で結局 1日あたり 1~3時間くらいかかり、

2018年版と同じくらいの(結局ブログを投稿するくらいの)リソース消費だった気がします。

 

それでは、いくつか振り返りについて・・・

 

利用した環境について。

利用した vSAN 環境は、昨年と同様、基本的に 1台の物理マシン上のネステッド環境です。

物理マシンは Intel NUC で、スペックは下記です。

  • Intel Core i7-6770HQ CPU @ 2.60GHz
  • 32 GiB Memory
  • Intel SSD 600p Series (512GB)

 

意外とオーバーコミットできるので、このハードウェア スペックでも

「VCSA + 8 ESXi + 監視ホスト」といったサイズの vSAN でもネストで動作します。

いろいろ vSAN クラスタを作成してみたところ、UI や製品動作の確認は、たいていネスト環境で問題なそうな感触です。

 

vSAN 環境構築の方法について。

毎日 vSAN クラスタを作成するには手動だとさすがに大変なので、

PowerCLI スクリプトである程度、自動化していました。

 

利用した PowerCLI スクリプトは下記のようなものです。

これは、PowerCLI の手動実行でネステッド vSAN 構築したときの コマンドラインを羅列したようなスクリプトですが、

そこそこ頻繁に手を入れて徐々に育てています。

GitHub - gowatana/deploy-1box-vsan: Nested vSAN ラボを構築するための工夫。

Home · gowatana/deploy-1box-vsan Wiki · GitHub

 

今回のイベントでは、下記のような設定ファイルをもとに vSAN クラスタを作成していました。

あとで同様の vSAN クラスタを作成して確認をするときも便利です。

GitHub - gowatana/vsan-advent-2019: vSAN のつぶやき。 Advent Calendar 2019 | 設定ファイル集

 

今年は Linux で PowerCLI(しかも Docker コンテナのもの)を使用したのですが、

vSAN 関連モジュールも含めて、意外と  Windows の PowerShell 環境で作成していたスクリプトがそのまま動作しました。

vSAN Setup from Linux · gowatana/deploy-1box-vsan Wiki · GitHub

 

いろいろ PowerCLI の Tips が得られたので、いずれ紹介したいと思っています。

 

つぶやきの感想。

毎日思いつくままつぶやいたので、並べて見直すとあまり関連性がなく、

やはり、ある程度はシナリオを考えてから始めればよかった気がしました。

 

そして、スクリーンショットは、あえて無加工(赤枠などをつけないまま)投稿してみたのですが、

はやり赤枠くらいはつければよかったかなと思いました。

Tweet した Tips を実機スクリーンショットで確認できるように

できるだけ特徴的なスクリーンショットを取得して Twitter に貼ったつもりだったのですが、

なんといても、後日に自分で見直しても意外とポイントがわかりにくかった・・・

 

以上、昨年末の vSAN のつぶやきの振り返りでした。


vCenter と vROps で vMotion / DRS を観察してみる。

$
0
0

自宅ラボの vSphere を眺めていたら、クラスタの vMotion 数がいい感じに増えていました。

そこで vMotion と DRS の様子を、vCenter Server と vRealize Operations Manager(vROps) で

観察する Tips を紹介しようと思います。

今回の環境は、vCenter 6.7 U3 + vROps 8.0 です。

 

vCenter / vSphere Client での vMotion 観察。

まず、クラスタでの vMotion 数についてです。

vCenter Server では、クラスタごとに vMotion 実行数を記録しています。

自宅ラボのクラスタ「infra-cluster-01」では、これまで 45781 回の vMotion が実行されたことがわかります。

このクラスタでは vSphere DRS が有効化されており、ほとんどの vMotion は自動実行されたものです。

検証環境なので使用リソース増減も激しく、結構頻繁に vMotion が発生します。

drs-vmotion-01.png

 

vMotion の合計移行回数は、vSphere Client のパフォーマンス チャートでも表示できます。

対応しているカウンタは、クラスタの「仮想マシン操作」→「vMotion 数」です。

drs-vmotion-02.png

 

直近1年間の、vMotion の積み重ねが可視化されました。

いい感じに自宅ラボが使われていそうな気がします。

しかし、パフォーマンス チャートの情報は一定期間ごとにロールアップされてしまうため、

vCenter だけでは詳しく vMotion の様子を確認しにくいかなと思います。

drs-vmotion-04.png

 

そこで、vRealize Operations Manager(vROps)でも、

このクラスタでの vMotion の様子を見てみます。

 

vRealize Operations Manager での vMotion 観察。

vROps を利用すると、過去にさかのぼって一定間隔ごと(最短で5分間隔くらい)の vMotion 数が確認できます。

これで、クラスタで普段と異なる動きがないか確認することもできます。

2月23日あたりのグラフ上昇は、自宅ラボの ESXi を1台ずつローリング アップデートしたため vMotion が特に増えています。

※残念ながらこの vROps は最近デプロイしたもので1年間の情報が蓄積されていないため、年間通してのチャートは表示しません。

drs-vmotion-05.png

 

さらに、vMotion が DRS によるものか、それ以外(手動 vMotion)なのかも可視化できます。

赤枠内の紫線のところだけは、DRS ではない手動 vMotion のはずです。

drs-vmotion-06.png

 

おまけとして・・・

本来の利用方法ではないと思いますが、VM がどの時間帯に、どの ESXi ホストにいたかをチャートに表示することもできます。

VM(例では lab-rancher-01)の「メトリック」で、「サマリ」→「親ホスト」のチャートを表示すると、

時系列で VM がどの ESXi で稼働していたか確認することができます。

ただし、ESXi がチャートの縦軸で表現されているので、ESXi 台数が多くなると見にくいかもしれません。

この例の VM は、5台 の ESXi (クラスタは 6ノードですが)の間だけで移動しています。

drs-vmotion-07.png

 

DRS / vMotion の観察方法はいろいろあり、vCenter のイベント情報や他の vRealize 製品でも違った見方ができます。

今回は、あえて GUI で簡単に確認できそうな方法を選択してみました。

 

以上、vMotion 観察の Tips 紹介でした。

vSAN の SCSI-3 Persistent Reservation(SCSI-3 PR)を Linux で確認してみる。

$
0
0

vSphere 6.7 U3 では、ネイティブな VMDK が SCSI-3 Persistent Reservation(SCSI-3 PR)対応になりました。

 

VMware vSAN 6.7 Update 3 リリース ノート

ネイティブ vSAN VMDK 上の Windows Server Failover Clusters (WSFC)。vSAN 6.7 Update 3 では SCSI-3 PR がネイティブにサポートされており、Windows Server Failover Clusters を最初のクラスのワークロードとして VMDK に直接デプロイできます。この機能を使用すると、物理 RDM のレガシー環境または外部ストレージ プロトコルを vSAN に移行できます。

 

vSAN 6.7 U2 以前でも、vSAN iSCSI ターゲット(VIT)による LUN を共有ディスクを利用することで

vSAN による仮想ディスク(VMDK)で SCSI-3 PR が利用でき、

WSFC(Windows Server Failover Clustering)のようなクラスタウェアの

排他制御のしくみで利用することができていました。

しかし 6.7 U3 以降では、VIT による LUN ではない(ネイティブな)VMDK(いわゆる 共有 VMDK)でも、WSFC などで利用可能とのことです。

これは下記のあたりが参考になります。

 

Configuring a shared disk resource for Windows Server Failover Cluster (WSFC)

and migrating SQL Server Failover Cluster Instance (FCI) from SAN (RDMs) to vSAN

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

 

Hosting Windows Server Failover Cluster (WSFC) with shared disk on VMware vSphere: Doing it right!

https://blogs.vmware.com/apps/2019/05/wsfc-on-vsphere.html

 

そこで今回は、vSAN 6.7 U2 と vSAN 6.7 U3 の環境で、Linux VM から SCSI-3 PR の様子を見てみました。

 

今回の vSAN 環境。

vCenter 6.7 U3 に、ESXi 6.7 U2 / ESXi 6.7 U3 を登録して、

それぞれで vSAN 6.7 U2 / vSAN 6.7 U3 のクラスタを作成してあります。

そして、vSAN バージョンの異なるクラスタを用意しています。

 

クラスタ: vSAN-Cluster-67u2

  • vSAN 6.7 U2
  • ESXi 6.7 U2(Build 13006603)
  • 稼働している VM: vm01-on-67u2、vm02-on-67u2

 

クラスタ: vSAN-Cluster-67u2

  • vSAN 6.7 U3
  • ESXi 6.7 U3(Build 14320388)
  • 稼働している VM: vm01-on-67u3、vm02-on-67u3

 

vSAN-Cluster-67u2 クラスタに参加しているすべての ESXi のビルドは 13006603 なので、

ESXi 6.7 U2 → vSAN 6.7 U2 になります。

vsan-env-05.png

 

vSAN 6.7 U2 では、vSAN オン ディスク フォーマット が バージョン 7 です。

vsan-env-04.png

 

一方、vSAN-Cluster-67u3 クラスタに参加しているすべての ESXi のビルドは 14320388 なので、

ESXi 6.7 U3 → vSAN 6.7 U3 になります。

 

 

vSAN 6.7 U3 では、vSAN オン ディスク フォーマット が バージョン 10 です。

vsan-env-06.png

 

vSAN のバージョンアップによる新機能を利用するには、この環境のように

新バージョンの vSAN にあったオン ディスク フォーマットにしておく必要があります。

vSAN バージョンとオン ディスク フォーマットの関係は、下記で確認できます。

 

Build numbers and versions of VMware vSAN

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

 

今回の vSAN 上のゲスト OS。

検証で利用する ゲスト OS は、Oracle Linux 7 です。

[root@vm01-on-67u2 ~]# cat /etc/oracle-release

Oracle Linux Server release 7.7

 

SCSI-3 PR の動作確認では、Linux の sg_persist コマンドを利用します。

これは、sg3_utils パッケージ(Linux ディストリビューション同梱のもの)に含まれています。

[root@vm01-on-67u2 ~]# which sg_persist

/usr/bin/sg_persist

[root@vm01-on-67u2 ~]# rpm -qf /usr/bin/sg_persist

sg3_utils-1.37-18.0.1.el7_7.2.x86_64

 

これらの VM では、vSAN データストアに配置した 10GB の VMDK「ハード ディスク 2」を接続しています。

vsan-env-14.png

 

仮想 SCSI コントローラ 1 で(デフォルトの SCSI コントローラ 0 とは分けて)接続しています。

そして SCSI コントローラ 1 では、SCSI パスの共有を「物理」に設定しています。

vsan-env-15.png

 

この ハード ディスク 2 は、ゲスト OS からは

「VMware Virtual disk」である /dev/sdb という名前で認識されています。

[root@vm01-on-67u2 ~]# lsscsi

[0:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sda

[1:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sdb

[4:0:0:0]    cd/dvd  NECVMWar VMware SATA CD00 1.00  /dev/sr0

 

/dev/sdb は「ハード ディスク 2」なので 10GB です。

[root@vm01-on-67u2 ~]# lsblk -i

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

sda           8:0    0   16G  0 disk

|-sda1        8:1    0    1G  0 part /boot

`-sda2        8:2    0   15G  0 part

  |-ol-root 249:0    0 13.4G  0 lvm  /

  `-ol-swap 249:1    0  1.6G  0 lvm  [SWAP]

sdb           8:16   0   10G  0 disk

sr0          11:0    1 1024M  0 rom

 

vSAN 6.7 U2 での ネイティブ VMDK と SCSI-3 PR。

vSAN 6.7 U2 までは、ネイティブ VMDK だと SCSI-3 PR に対応していません。

sg_persist を実行すると、サポートされていないことがわかります。

ちなみに、-s は SCSI-3 PR のステータスを、-k では SCSI-3 PR で登録するキーを読み取ろうとしています。

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdb -s

  VMware    Virtual disk      2.0

  Peripheral device type: disk

PR in (Read full status): bad field in cdb including unsupported service action

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdb -k

  VMware    Virtual disk      2.0

  Peripheral device type: disk

PR in (Read keys): bad field in cdb including unsupported service action

 

vSAN 6.7 U2 での vSAN iSCSI LUN と SCSI-3 PR。

vSAN 6.7 U2 でも、vSAN iSCSI ターゲット(VIT)の LUN であれば、SCSI-3 PR に対応しています。

そこで Linux から VIT の LUN に接続して、SCSI-3 PR の動作確認をしてみます。

 

まず、vSAN で iSCSI ターゲットと、LUN を作成します。

ここでは iqn.2016-09.jp.go-lab:vit67u2 という IQN の iSCSI ターゲットを作成して、

そこに 5GB の LUN を追加しています。

vsan-env-13.png

 

Linux OS 側には iscsi-initiator-utils をインストールして・・・

(設定コマンドの出力結果は、一部省略しています)

[root@vm01-on-67u2 ~]# yum install -y iscsi-initiator-utils

[root@vm01-on-67u2 ~]# systemctl enable iscsid

[root@vm01-on-67u2 ~]# systemctl start iscsid

[root@vm01-on-67u2 ~]# systemctl is-active iscsid

active

 

iscsiadm コマンドで、iSCSI ターゲットに接続します。

[root@vm01-on-67u2 ~]# iscsiadm --mode discoverydb --type sendtargets --portal 192.168.1.33 --discover

[root@vm01-on-67u2 ~]# iscsiadm --mode node --portal 192.168.1.33:3260 --login

[root@vm01-on-67u2 ~]# iscsiadm -m session

tcp: [1] 192.168.1.33:3260,257 iqn.2016-09.jp.go-lab:vit67u2 (non-flash)

 

接続された iSCSI LUN は「VMware Virtual SAN」による /dev/sdc として認識されました。

[root@vm01-on-67u2 ~]# lsscsi

[0:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sda

[1:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sdb

[4:0:0:0]    cd/dvd  NECVMWar VMware SATA CD00 1.00  /dev/sr0

[34:0:0:0]   disk    VMware   Virtual SAN      0001  /dev/sdc

 

さきほどのスクリーンショットにあった LUN なので、/dev/sdc は 5GB です。

[root@vm01-on-67u2 ~]# lsblk

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT

sda           8:0    0   16G  0 disk

tqsda1        8:1    0    1G  0 part /boot

mqsda2        8:2    0   15G  0 part

  tqol-root 249:0    0 13.4G  0 lvm  /

  mqol-swap 249:1    0  1.6G  0 lvm  [SWAP]

sdb           8:16   0   10G  0 disk

sdc           8:32   0    5G  0 disk

sr0          11:0    1 1024M  0 rom

 

では、sg_persist コマンドで様子を確認してみます。

この iSCSI LUN であれば、SCSI-3 PR に対応しているため、さきほどの /dev/sdc とは出力結果がことなります。

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -s

  VMware    Virtual SAN       0001

  Peripheral device type: disk

  PR generation=0x0

  No full status descriptors

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -k

  VMware    Virtual SAN       0001

  Peripheral device type: disk

  PR generation=0x0, there are NO registered reservation keys

 

ためしに /dev/sdc デバイスに、SCSI-3 PR の Reservation を設定してみます。

まずは、キーを登録します。

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -o --register -S 123

  VMware    Virtual SAN       0001

  Peripheral device type: disk

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -k

  VMware    Virtual SAN       0001

  Peripheral device type: disk

  PR generation=0x1, 1 registered reservation key follows:

    0x123

 

この時点では、まだ Reservation を持っていません。

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -r

  VMware    Virtual SAN       0001

  Peripheral device type: disk

  PR generation=0x1, there is NO reservation held

 

それでは、登録したキーを指定(-K 123)して、

他のホストから書き込めないように Reservation を設定(-T 1)してみます。

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -o --reserve -K 123 -T 1

  VMware    Virtual SAN       0001

  Peripheral device type: disk

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -r

  VMware    Virtual SAN       0001

  Peripheral device type: disk

  PR generation=0x1, Reservation follows:

    Key=0x123

    scope: LU_SCOPE,  type: Write Exclusive

 

/dev/sdc デバイスには、この Linux からは、書き込みができます。

※デバイスまで書き込むように oflag=sync をつけています。

[root@vm01-on-67u2 ~]# dd if=/dev/zero of=/dev/sdc count=1 oflag=sync

1+0 レコード入力

1+0 レコード出力

512 バイト (512 B) コピーされました、 0.00960002 秒、 53.3 kB/秒

 

一方で、おなじ LUN に接続している別の Linux からは、書き込みができなくなっています。

ホスト名 vm02-on-67u2 の Linux からも同様に iSCSI LUN に接続して /dev/sdc と認識していますが・・・

[root@vm02-on-67u2 ~]# iscsiadm -m session

tcp: [1] 192.168.1.33:3260,257 iqn.2016-09.jp.go-lab:vit67u2 (non-flash)

[root@vm02-on-67u2 ~]# lsscsi

[0:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sda

[1:0:0:0]    disk    VMware   Virtual disk     2.0   /dev/sdb

[4:0:0:0]    cd/dvd  NECVMWar VMware SATA CD00 1.00  /dev/sr0

[34:0:0:0]   disk    VMware   Virtual SAN      0001  /dev/sdc

[root@vm02-on-67u2 ~]# lsblk /dev/sdc

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT

sdc    8:32   0   5G  0 disk

 

SCSI-3 PR の Reservation によって、デバイスへの書き込みはエラーになりました。

[root@vm02-on-67u2 ~]# dd if=/dev/zero of=/dev/sdc count=1 oflag=sync

dd: `/dev/sdc' に書き込み中です: 入力/出力エラーです

1+0 レコード入力

0+0 レコード出力

0 バイト (0 B) コピーされました、 0.0144499 秒、 0.0 kB/秒

 

そして Reservation  を開放すると、他のホストからの書き込みもできるようになります。

vm01-on-67u2 で Reservation  を開放(--release)すると・・・

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -o --release -K 123 -T 1

  VMware    Virtual SAN       0001

  Peripheral device type: disk

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -r

  VMware    Virtual SAN       0001

  Peripheral device type: disk

  PR generation=0x1, there is NO reservation held

 

vm02-on-67u2 でも、書き込みができるようになります。

[root@vm02-on-67u2 ~]# dd if=/dev/zero of=/dev/sdc count=1 oflag=sync

1+0 レコード入力

1+0 レコード出力

512 バイト (512 B) コピーされました、 0.0161903 秒、 31.6 kB/秒

 

最後に、キーの登録も削除しておきます。

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -o --register -K 123

[root@vm01-on-67u2 ~]# sg_persist -d /dev/sdc -k

  VMware    Virtual SAN       0001

  Peripheral device type: disk

  PR generation=0x2, there are NO registered reservation keys

 

vSAN 6.7 U3 での ネイティブ VMDK と SCSI-3 PR。

vSAN 6.7 U3 では、ネイティブ VMDK でも SCSI-3 PR に対応します。

 

sg_persist コマンドでキーを読み取ろうとすると iSCSI LUN と同様の出力結果となり、

SCSI-3 PR に対応していそうな様子が見られました。

※この時点ではキーが未登録なので「NO registered reservation keys」です。

[root@vm01-on-67u3 ~]# sg_persist -d /dev/sdb -k

  VMware    Virtual disk      2.0

  Peripheral device type: disk

  PR generation=0x0, there are NO registered reservation keys

 

ただし、Full Status を確認しようとすると、失敗(command failed)してしまいます。

[root@vm01-on-67u3 ~]# sg_persist -d /dev/sdb -s

  VMware    Virtual disk      2.0

  Peripheral device type: disk

persistent reservation in: scsi status: Busy

PR in (Read full status): command failed

 

また、キー登録を試みても同様に失敗してしまいました。

[root@vm01-on-67u3 ~]# sg_persist -d /dev/sdb -o --register -S 123

  VMware    Virtual disk      2.0

  Peripheral device type: disk

persistent reserve out: scsi status: Busy

PR out: command failed

 

vSAN 6.7 U3 でのネイティブ VMDK の SCSI-3 PR 対応は、WSFC をサポートするようです。

しかし、他のクラスタウェアなどで SCSI-3 PR 要件がある場合に vSAN でネイティブ VMDK の共有接続をするには

実際に利用する想定のソフトウェアで動作確認をしたほうがよさそうかなと思いました。

 

以上、vSAN の SCSI-3 PR の様子を確認してみる話でした。

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

$
0
0

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

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

 

The Cluster API Book

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

 

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

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

 

1. 環境。

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

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

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

 

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

 

2. 事前準備。

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

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

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

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

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

k8s-capv-01.png

 

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

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

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

 

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

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

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

 

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

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

 

2-2. OVA のデプロイ。

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

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

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

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

 

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

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

k8s-capv-02.png

 

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

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

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

 

3. clusterctl 実行環境の準備。

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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

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

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

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

docker-18.09.9-1.ph3.x86_64

 

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

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

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

 

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

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

 

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

root@photon-01 [ ~ ]# reboot

 

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

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

active

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

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=11dd065

 

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

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

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

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

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

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

 

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

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

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

root@photon-01 [ ~ ]# kind version

kind v0.6.1 go1.13.4 linux/amd64

 

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

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

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

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

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

root@photon-01 [ ~ ]# clusterctl version

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

 

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

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

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

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

 

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

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

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

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

 

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

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

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

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

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

kind

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

NAME                 STATUS   ROLES    AGE     VERSION

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

 

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

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

NAMESPACE     NAME                                         READY   STATUS    RESTARTS   AGE

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

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

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

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

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

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

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

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

 

4-2. CAPV むけの準備。

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

 

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

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

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

 

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

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

 

ラボ環境の vSphere にあわせた

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

# Controller settings

VSPHERE_USERNAME: "administrator@vsphere.local"

VSPHERE_PASSWORD: "VMware1!"

 

# Required workload cluster default settings

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

VSPHERE_DATACENTER: "lab-dc-02"

VSPHERE_DATASTORE: "vsanDatastore-702"

VSPHERE_NETWORK: "pg-vlan-0004"

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

VSPHERE_FOLDER: "vm/capi-01"

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

VSPHERE_HAPROXY_TEMPLATE: "capv-haproxy-v0.6.3"

VSPHERE_SSH_AUTHORIZED_KEY: XXX

EOF

 

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

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

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

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

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

14c14

< VSPHERE_SSH_AUTHORIZED_KEY: XXX

---

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

 

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

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

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

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

Fetching providers

Installing cert-manager

Waiting for cert-manager to be available...

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

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

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

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

 

Your management cluster has been initialized successfully!

 

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

 

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

 

 

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

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

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

NAMESPACE                           NAME                                                             READY   STATUS    RESTARTS   AGE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

k8s-capv-03.png

 

5. Workload クラスタの作成。

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

 

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

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

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

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

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

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

 

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

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

 

cluster.yaml の一部より。

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

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

apiVersion: cluster.x-k8s.io/v1alpha3

kind: Cluster

metadata:

  name: capvdemo

  namespace: default

spec:

  clusterNetwork:

    pods:

      cidrBlocks:

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

 

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

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

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

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

10c10

<       - 192.168.0.0/16

---

>       - 100.96.0.0/11

39c39

<     memoryMiB: 8192

---

>     memoryMiB: 4096

101c101

<       memoryMiB: 8192

---

>       memoryMiB: 4096

 

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

NAME       PHASE

capvdemo   Provisioned

 

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

k8s-capv-05.png

 

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

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

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

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

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

 

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

  • HAProxy(~-lb 1台)
  • Control Plane(capvdemo-~ 1台)
  • ワーカー ノード(capvdemo-md-0-~ が 3台)

k8s-capv-06.png

 

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

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

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

NAME                            PROVIDERID                                       PHASE

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

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

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

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

 

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

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

NAME            PHASE     REPLICAS   AVAILABLE   READY

capvdemo-md-0   Running   3          3           3

 

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

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

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

 

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

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

NAME                            STATUS     ROLES    AGE     VERSION

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

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

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

capvdemo-rphzb                  NotReady   master   16m     v1.17.3

 

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

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

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

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

NAME                            STATUS     ROLES    AGE     VERSION

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

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

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

capvdemo-rphzb                  NotReady   master   18m     v1.17.3

 

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

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

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

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

NAMESPACE     NAME                                     READY   STATUS    RESTARTS   AGE

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

Unable to connect to the server: EOF

 

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

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

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

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

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

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

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

serviceaccount/antctl created

serviceaccount/antrea-agent created

serviceaccount/antrea-controller created

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

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

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

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

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

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

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

configmap/antrea-config-b2b5bdkh8t created

service/antrea created

deployment.apps/antrea-controller created

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

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

daemonset.apps/antrea-agent created

 

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

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

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

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

NAMESPACE     NAME                                     READY   STATUS    RESTARTS   AGE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

k8s-capv-07.png

 

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

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

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

NAME                            STATUS   ROLES    AGE   VERSION

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

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

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

capvdemo-rphzb                  Ready    master   54m   v1.17.3

 

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

 

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

自宅ラボの Kuberente に Antrea と Octant をインストールしてみる。

$
0
0

先日、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 をインストールしてみる話でした。

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

$
0
0

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 事前準備編

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

$
0
0

引き続き、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 with Kubernetes 環境構築。Part-03: 仮想マシン ストレージ ポリシー準備編

$
0
0

引き続き、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 デプロイ編

$
0
0

ひきつづき、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 ラボ環境構築。Part-05: NSX Manager 設定編

$
0
0

ひきつづき、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: ホスト トランスポート ノード準備編

$
0
0

引き続き、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 ラボ環境構築。Part-07: NSX Edge デプロイ編

$
0
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 アドレス(今回は admin)。
  • Manager Password: NSX Manager の admin ユーザのパスワード。
  • Manager Thumbprint: 冒頭の手順で確認した、NSX Manager の証明書サムプリント(64文字)

 

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

 

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

wcp-06-42.png

 

NSX Manager の

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

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

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

wcp-06-45.png

 

つづく・・・

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

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

$
0
0

引き続き、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 ゲートウェイ作成編

$
0
0

引き続き、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 ゲートウェイの名前:
  • 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 ラボ環境構築。Part-10: Supervisor Cluster 有効化編

$
0
0

ひきつづき、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 では 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 ツールへのリンク」にある、「開く」をクリックします。

【10-32】

wcp-10-32.png

 

「Kubernetes CLI Tools」という、

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

wcp-10-33.png

 

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

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

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

 

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

おそらくつづく。


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

$
0
0

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

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

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

 

前回はこちら。

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

 

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

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

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

VMware Photon OS 3.0

PHOTON_BUILD_NUMBER=49d932d

 

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

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

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

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

 

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

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

 

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

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

wcp-11-01.png

 

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

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

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

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

wcp-11-02.png

 

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

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

wcp-11-03.png

 

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

wcp-11-04.png

 

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

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

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

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

 

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

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

 

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

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

 

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

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

gowatana [ ~ ]$ ls

sha256sum.txt  vsphere-plugin.zip

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

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

vsphere-plugin.zip: OK

 

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

gowatana [ ~ ]$ unzip vsphere-plugin.zip

Archive:  vsphere-plugin.zip

   creating: bin/

  inflating: bin/kubectl-vsphere

  inflating: bin/kubectl

 

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

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

gowatana [ ~ ]$ which kubectl

/home/gowatana/bin/kubectl

 

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

gowatana [ ~ ]$ kubectl version --client

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

 

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

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

 

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

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

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

 

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

gowatana [ ~ ]$ kubectl vsphere --help

vSphere Plugin for kubectl.

 

Usage:

  kubectl-vsphere [command]

 

Available Commands:

  help        Help about any command

  login       Authenticate user with vCenter Namespaces

  logout      Destroys current sessions with all vCenter Namespaces clusters.

  version     Prints the version of the plugin.

 

Flags:

  -h, --help                     help for kubectl-vsphere

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

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

 

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

 

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

gowatana [ ~ ]$ kubectl vsphere login --help

Authenticate user with vCenter Namespaces:

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

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

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

 

Usage:

  kubectl-vsphere login [flags]

 

Examples:

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

 

https://10.0.1.10/Flags:

  -h, --help                                        help for login

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

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

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

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

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

 

Global Flags:

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

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

 

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

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

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

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

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

 

Username: administrator@vsphere.local

Password: ★パスワード入力

Logged in successfully.

 

You have access to the following contexts:

   192.168.70.33

   lab-ns-01

   lab-ns-02

 

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

logging in again later, or contact your cluster administrator.

 

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

 

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

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

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

Switched to context "lab-ns-01".

 

Pod の起動確認。(kubectl run)

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

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

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

 

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

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

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

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

[root@centos /]#

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

CentOS Linux release 7.8.2003 (Core)

 

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

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

wcp-11-05.png

 

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

[root@centos /]# exit

exit

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

pod "centos" deleted

gowatana [ ~ ]$

 

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

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

wcp-11-07.png

 

Pod の起動確認。(kubectl apply)

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

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

 

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

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

---

kind: Pod

apiVersion: v1

metadata:

  name: nginx-pod

  labels:

    app: wcp-demo

spec:

  containers:

  - image: nginx

    name: nginx-container

 

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

gowatana [ ~ ]$ vi nginx-pod.yml

 

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

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

> ---

> kind: Pod

> apiVersion: v1

> metadata:

>   name: nginx-pod

>   labels:

>     app: wcp-demo

> spec:

>   containers:

>   - image: nginx

>     name: nginx-container

> EOF

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

---

kind: Pod

apiVersion: v1

metadata:

  name: nginx-pod

  labels:

    app: wcp-demo

spec:

  containers:

  - image: nginx

    name: nginx-container

 

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

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

pod/nginx-pod created

 

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

gowatana [ ~ ]$ kubectl get pods

NAME        READY   STATUS    RESTARTS   AGE

nginx-pod   1/1     Running   0          40s

 

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

 

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

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

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

wcp-11-08.png

 

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

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

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

pod "nginx-pod" deleted

 

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

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

 

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

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

$
0
0

ここまでに、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 作成編

$
0
0

前回は、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 起動編

$
0
0

前回は、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 作成編

$
0
0

前回は、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 のラボ環境構築でした。

Viewing all 495 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>