LoginSignup
5
2

More than 3 years have passed since last update.

シングルノードで、ネストESXiもしないで、vSphere KubernetesとNSX-T

Last updated at Posted at 2020-07-17

TL;DR

ESXiが一つしかない、そんな環境でもNSX-TとvSphere k8s環境は構築可能です。
ただし、ノーサポート構成なので自己責任でお願いします。

なんでこの発想になったのか

vSphere Kuberentes (aka TKG service)を試したい!
ところが、ドキュメントをみると、最低3台のESXiが必要だったりします。

これでは気軽にためせん。Nested ESXiも個人的に使いにくいので避けたい。
ということでどうにかできないかと調べ、実際にうごいたので、共有です。

動いたという証明

このとおり、vCenterに繋がるひとつのESXiだけで、NSX-TとvSphere k8sが動いています。

image.png

気にしないといけないところ

ESXiがひとつしかない環境の場合、以下の点の注意が必要です。

• NSX ManagerとEdgeは非冗長構成
• NSX Edgeと、ホストのTEPの構成方法

1点目は自明なので、詳細は触れませんが、後半は後者について少しだけ触れます。

あとちなみにですが今回の手順では、k8sのコントロールノードにあたる、SupervisorClusterのControlノード数もデフォルトで3台作られれ、しかも全て同じESXi上で作られます。
これも英語のブログをみると、最小2台まで(1は不可)減らすことができるらしいです。本当に非力なサーバーは参考にしてください。

Note: You can not set a value of 1 (I tried) and although this does work, the enablement of vSphere with Kubernetes never completes from my observation. I believe the reason for this is because there is a floating IP (FIP) which is used across the three Supervisor Control Plane VMs, that perhaps its unable to completely configure it and hence it just spins forever. It would have been nice to just only have a single Supervisor Control Plane VM.

NSX EdgeとホストのTEPの構成

まず成功したとおっしゃっている英語サイト

ここのサイトをよんでいて、いまいちピンとこなかったのが、以下の箇所

The essential thing here is that the TEP of your ESXi host is in a different VLAN than the TEP of the Edge Transport Node. This also means that encapsulated Geneve traffic must be routed between these VLANs. If you connect both TEPs to the same VLAN, you get some unexpected behaviour and the setup won’t work.

この点については、以下が一番クリアに説明していると思います。

まず以下が失敗構成

image.png

  • Edgeとホストが同じN-VDSに所属
  • VTEPからヘアピンして、内部のポートとVTEPを構成する方法が現在ないため、失敗するとのこと

では、どうするのかというと

修正案①;

image.png

  • EdgeをそのホストのVSS/VDS上に構成する
  • この構成の場合、N-VDSとは、イーサネットポートを共有できないので、もうひとセット接続されている必要あり
  • 1 NICでは構成不可
  • 2 NICは構成できるが、可用性の観点から非推奨(あと、vCenterにずっと怒られる)よって4 NICが推奨

修正案②:
image.png

  • EdgeとホストのTEPを別のサブネットで構成する。こうすることで通信がヘアピンにならず、一度ホスト外に通信がでるようになる
  • この場合、L3スイッチ側でルーティング正しく行われている必要ある
  • さらにこのルーティングの際、スイッチ側でMTU 1600の通信を阻害してはいけない(超重要)

構成的により正しいのは②な気がしますが、今回私の環境ではL3スイッチにさわれないので、①を行います。
なお、2 NICしかない構成なので、さらに非推奨です。

環境

N-VDSとVDSは最終的な以下のような構成になりました。
VDSを構成する場合、MTUサイズを1600にすることをわすれずに行ってください。
さぐりさぐりでやったので、構成が綺麗ではない点ご容赦ください。

image.png

この図のどのVDSどのIPアドレスが繋がっているかは以下の通りです。

サブネット1 : マネジメント 10.197.35.0/24

IP 用途 N-VDS/VDS
10.197.35.1 GW N/A
10.197.35.10 ESXi VSK_10.197.35(のVMKとして構築)
10.197.35.11 vCenter VSK_10.197.35
10.197.35.14 NSX-T VSK_10.197.35
10.197.35.15 Edge Mgmt EDGE_10.197.35
10.197.35.150 - 153 k8s controller EDGE_10.197.35
10.197.35.201 ESXi TEP VSK_10.197.35
10.197.35.202 Edge TEP EDGE_10.197.35

ポイントとして、Edge MgmtEdge TEPが他と同じ10.197.35.0/24のIPアドレスを持ちながら、別のVDSで構成されている点です。これは、前述の通り、こうしないとTEPの通信がおかしくなってしまいます。k8s controllerをEDGE_10.197.35で構成する理由は思い返せば全くなかったと思います。これはVSK_10.197.35でもよかったはず。

サブネット2 : 外部通信用 10.197.36.0/24

IP 用途 N-VDS/VDS
10.197.36.1 GW N/A
10.197.36.3 EDGE Uplink(vlan trasport zone) EDGE_10.197.36
10.197.36.48/28 k8s ingress EDGE_10.197.36
10.197.36.64/28 k8s egress EDGE_10.197.36

そして、今回はNorth-Southトラフィックを担うEdgeのvlan transport zoneの出口は、別サブネットにしています。
これに伴い、k8sのingress/egressもここに所属させています。

正直見返したところ、これをわざわざ別のセグメントにする必要はなかったかなと思います。10.197.35.0/24のネットワークでまとめられたはずです。

ネットワーク周りの構成方法

マニュアルが結構複雑なため、いったりきたりが必要できれいなログが残っていないのですが、要所要所の構成についての画面ショットを最後に紹介します。

Edgeのノード追加時の注意

マニュアルの手順のここにあたります。

EdgeのマネジメントIPアドレスを構成するときの画面です。これは、Transport Zoneではなく、ただのマネジメントで使われるIPアドレスなので注意してください。Management InterfaceはEDGE_10.197.35を使います。技術的にはここだけに関してはVDS_10.197.35を使っても動いたかもしれないですが、試していないです。
image.png

EdgeのTEPはノード追加時に、overlay transport zoneを作成するときに静的IPアドレスを指定して追加します。
image.png

さらに、この時UPLINKはEDGE_10.197.35を使います。くどいですが、VSK_10.197.35を選んでしまうと、TEPが構成されないです。

image.png

そして、このあとvlan trasport zoneを構成するのですが、見逃してしまう+New Node Switchを押して、新しいスイッチとして定義します。 これは、North-South通信の出口であるEDGE_10.197.36を指定します。
image.png

Tier 0 gateway追加時の注意点

マニュアルの手順のここここにあたります。

マニュアルにあるとおり、まずはSegmentを作ります。この時Trasport ZoneはVLAN trasport zoneを指定します。私の構成では特にタギングなしで通信できるのでVLAN IDは0を指定します。その他はそこまで注意点はないです。
image.png

Tier 0 gatewayを作成する際には、上のSegmentを指定して、IPアドレスの指定、そしてBGPがない場合はそのIPアドレスから外部に通信が可能なデフォゲを追加します。

image.png

WorkloadをEnable時の注意点

マニュアルのここです。

ネットワーク構成時はまずマネジメント側のIPアドレス類を指定します。前にもかきましたが、EDGE_10.197.35で構成する理由は思い返せば全くなかったと思います。これはVSK_10.197.35でもよかったはず。

image.png

そして、スクロールダウンして、Workloadネットワークの箇所です。このIngressとEgressが最初さっぱりわからなかったのですが、要はLBで使用されるIPアドレスのことのようで、外部と通信可能なIPアドレス(10.197.36.0/24)の一部分をCIDR形式で指定すればよいらしいです。
image.png

その他、注意点

vCenterのWorkloadをEnableするとき、Enableボタンがない、ということがあったりします。
その際は、慌てず、TroubleShootガイドにある、前提条件確認ツールを使ってください。

筆者も同じことがおきて、数時間悩むはめになりました。ちなみにこのときのメッセージがこれ。

|---------|----------|----------------------------------------------------------------------------------------|
|cluster  |compatible|incompatibility_reasons                                                                 |
|---------|----------|----------------------------------------------------------------------------------------|
|domain-c8|False     |Failed to list all distributed switches in vCenter 2818b33a-d84d-42a5-840c-4dab2db9c7c1.|
|         |          |Cluster domain-c8 is missing compatible NSX-T VDS.                                      |
|---------|----------|----------------------------------------------------------------------------------------|

でこれのオチですが、NSXのCompute ManagersのEnable Trustを有効にすることをわすれたためでした(わかるかー)。
画面ショットのここです。
image.png

追記 2020/07/21

あとでわかったことなのですが、EdgeのサイズはLargeにしないとあとでこまります。
というのも、Guest ClusterをつくるLBがLargeにしないと、必要な個数がつくれないからです。

まとめ

ESXi一つでも、vSphere k8sを構成可能ですが、NSXが鬼門です。

個人的にはNSXを最初に触れた3年ほど前に比べるとかなり簡単になり、海外のブログも充実してきたと思います。コツさえつかめれば、そこまで難しくないはずなので、今後もこういった情報を発信をしたいと思います。

5
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
5
2