VMware Global Community
yi1234
Enthusiast
Enthusiast
Jump to solution

vSphere with TanzuのSupervisor Clusterの制御プレーンノードのIPアドレスにアクセスできない

以下のガイドを参照して、vSphere with Tanzu + HAProxyの環境作成を目指し、ワークロードの管理を有効化、名前空間作成まではできたのですが、Supervisor Clusterの制御プレーンノードのIPアドレス(VIP)に、別ネットワーク(管理ネットワーク)からアクセスすることができません(pingの応答がありません)。
vSphere with Tanzu Quick Start Guide V1a 

以下の状況なのですが、どういった原因が考えられますでしょうか?

  • 同じワークロードネットワーク上のVMからは制御プレーンノードのVIPにブラウザでアクセス可能(Kubernetes CLI Tools画面が表示される)のため、HAProxyのロードバランシングは機能していそう
  • 管理ネットワークから、制御プレーンVM(3つ)がもつワークロードネットワークのIPアドレスには3VMともにブラウザでアクセス可能(Kubernetes CLI Tools画面が表示される)のため、ルーティングは問題なさそう

バージョンは以下を使っています。

 haproxy-v0.1.10
 vSphere 7.0.1, 17168206
 vCenter 7.0.1, 16858589

 

こちらのサイトも参考にさせていただき、同じように設定はできているつもりのなのですが。。。助言いただけると助かります。
vSphere 7.0 U1 での with Tanzu ラボ環境構築。Part-01 事前準備編 

Labels (2)
Reply
0 Kudos
1 Solution

Accepted Solutions
gowatana
Leadership
Leadership
Jump to solution

こんにちは。

 

HAProxyデプロイと、ワークロード管理の有効化でのIPアドレスの指定自体には問題ないようです。

もしかしたら、HAProxyのルーティング テーブルの設定がうまく機能していないのかもしれません。

HAProxy VM(v0.1.10でも)では、複数のルーティング テーブルが利用され、OVFデプロイで入力したパラメータを元に作成されます。
しかし、なぜかうまく設定されていないことがあります。

ルーティング テーブルは、HAProxy のVMにSSHログインすると確認できます。

大抵の場合、Linuxではこのテーブルだけを見ると思いますが・・・

root@lab-haproxy-41 [ ~ ]# ip route show
default via 192.168.10.1 dev management proto static
192.168.10.0/24 dev management proto kernel scope link src 192.168.10.80
192.168.21.0/24 dev workload proto kernel scope link src 192.168.21.80

 

HAProxy VMのworkloadネットワークでは、table 2 というテーブルも設定されます。
このテーブルが設定されていれば、別ネットワークからVIPにアクセスできるようになるはずです。

ちなみに、この環境の、HAProxyデプロイ時に指定したワークロードネットワークは192.168.21.0/24です。
そして、Frontendネットワークがある場合は、table 3 も追加されます。

root@lab-haproxy-41 [ ~ ]# ip route show table 2
default via 192.168.21.1 dev workload proto static

 

route table 2 が設定されていない場合は、/etc/vmware/route-tables.cfg ファイルを次のように編集(末尾にIPのない行を#でコメントアウト)して、systemctl restart route-tablesで再起動すると、/etc/systemd/network/10-xxxx.network ファイルへの追記なしで、テーブルが追加されるはずです。

2,workload,00:50:56:98:4b:ce,192.168.21.80/24,192.168.21.1
#2,workload,00:50:56:98:4b:ce,192.168.21.80/24

 

この設定ファイルについては、以前にVMware DevOps Meetup #8でもご紹介したので、よろしければ下記から資料をどうぞ。

https://vmware.connpass.com/event/203934/presentation/

 

View solution in original post

Reply
0 Kudos
4 Replies
gowatana
Leadership
Leadership
Jump to solution

こんにちは。

 

Supervisor Clusterの制御プレーンノードのIPアドレス(VIP)なのですが、
「ワークロード管理」→「クラスタ」画面や、
「Kubernetes CLI Tools画面」は、現在どのアドレスになっていますでしょうか?

これは、つぎの2パターンがあります。

  1. ワークロード管理 を有効化する際に、「5. ロードバランサ」で入力した「開始 IP アドレス」になっている。
    → HAProxy VM の設定がうまくいっていない、スーパーバイザー クラスタが中途半端な状態。
  2. HAProxy の「Load Balancer IP Range」で指定したレンジのIPになっている。
    → スーパーバイザークラスタの構成が完了できてる状態。

 

おそらく「2」の状態ではあり、開始 IP アドレスはping応答があり、
HAProxy の VIP からはping応答がない状態にはなっているのではないかと思います。

その場合は、HAProxy のルーティング テーブル設定か、HAProxy まわりのネットワーク構成の問題の可能性が考えられます。

「Load Balancer IP Range」レンジの VIP にアクセスできないのであれば、
まずは HAProxy VM に SSH ログインして、「tracepath -n <アクセス元IP>」コマンドで、
workload(もしくは frontend)NIC 側を通っているか確認してみるとよいかなと思います。

 

ただ、まずはスーパーバイザークラスタの VIP が「2」の状態になれているかが気になりました。

Reply
0 Kudos
yi1234
Enthusiast
Enthusiast
Jump to solution

gowatanaさん

ご返信ありがとうございます。

"1.ワークロード管理 を有効化する際に、「5. ロードバランサ」で入力した「開始 IP アドレス」になっている"

⇒「5.ロードバランサ」画面で入力した「仮想サーバのIPアドレス範囲」の開始IPアドレスになっていました。
 ただ、「仮想サーバのIPアドレス範囲」には、HAProxyの「Load Balancer IP Range」で指定したIPの範囲を入力していたので、「2.HAProxy の「Load Balancer IP Range」で指定したレンジのIPになっている」にもなっています。
 これが間違っていますでしょうか?gowatanaさんのサイトも再度見直したのですが、ここは同じように見えました。

 なお、スーパーバイザー制御プレーンVM自体に割り当てられたIPアドレスは、ワークロード管理を有効化する際の「7.ワークロードネットワーク」で追加したワークロードネットワークの「IPアドレス範囲」になっています(HAProxyの「Load Balancer IP Range」と被らない範囲にしています)。

 具体的には、以下のようにIPを指定しています。

  • HAProxyの「Load Balancer IP Range」:172.18.0.208/28
  • ワークロード管理 を有効化する際の「5. ロードバランサ」の「仮想サーバのIPアドレス範囲」:172.18.0.208-172.18.0.222
  • ワークロード管理を有効化する際の「7.ワークロードネットワーク」で追加したワークロードネットワークの「IPアドレス範囲」:172.18.0.100-172.18.0.200

 

改めてネットワーク構成を見直してみたのですが、スーパーバイザー制御ブレーンVMには「7.ワークロードネットワーク」で追加した、ワークロードネットワークにゲートウェイを指定していますが、HAProxyの「Load Balancer IP Range」や「5. ロードバランサ」の「仮想サーバのIPアドレス範囲」ではワークロードのゲートウェイは指定するところがなかったため、HAProxyの「/etc/systemd/network/10-xxxx.network」設定ファイルにワークロードネットワークから、管理ネットワークとは別ネットワークへのルーティングを追加することで、別ネットワークからVIPにアクセスできるようになりました

HAProxyのルーティング追加等Quick Start Guideに記載がなかったので(気がするので)、そこは気にせずガイド通りに試していたのですが、このようにすべきなのが正解なのでしょうか?

それとも「1」の設定がおかしいことでネットワーク設定が正しく行われていないのでしょうか?

 

Reply
0 Kudos
gowatana
Leadership
Leadership
Jump to solution

こんにちは。

 

HAProxyデプロイと、ワークロード管理の有効化でのIPアドレスの指定自体には問題ないようです。

もしかしたら、HAProxyのルーティング テーブルの設定がうまく機能していないのかもしれません。

HAProxy VM(v0.1.10でも)では、複数のルーティング テーブルが利用され、OVFデプロイで入力したパラメータを元に作成されます。
しかし、なぜかうまく設定されていないことがあります。

ルーティング テーブルは、HAProxy のVMにSSHログインすると確認できます。

大抵の場合、Linuxではこのテーブルだけを見ると思いますが・・・

root@lab-haproxy-41 [ ~ ]# ip route show
default via 192.168.10.1 dev management proto static
192.168.10.0/24 dev management proto kernel scope link src 192.168.10.80
192.168.21.0/24 dev workload proto kernel scope link src 192.168.21.80

 

HAProxy VMのworkloadネットワークでは、table 2 というテーブルも設定されます。
このテーブルが設定されていれば、別ネットワークからVIPにアクセスできるようになるはずです。

ちなみに、この環境の、HAProxyデプロイ時に指定したワークロードネットワークは192.168.21.0/24です。
そして、Frontendネットワークがある場合は、table 3 も追加されます。

root@lab-haproxy-41 [ ~ ]# ip route show table 2
default via 192.168.21.1 dev workload proto static

 

route table 2 が設定されていない場合は、/etc/vmware/route-tables.cfg ファイルを次のように編集(末尾にIPのない行を#でコメントアウト)して、systemctl restart route-tablesで再起動すると、/etc/systemd/network/10-xxxx.network ファイルへの追記なしで、テーブルが追加されるはずです。

2,workload,00:50:56:98:4b:ce,192.168.21.80/24,192.168.21.1
#2,workload,00:50:56:98:4b:ce,192.168.21.80/24

 

この設定ファイルについては、以前にVMware DevOps Meetup #8でもご紹介したので、よろしければ下記から資料をどうぞ。

https://vmware.connpass.com/event/203934/presentation/

 

Reply
0 Kudos
yi1234
Enthusiast
Enthusiast
Jump to solution

IPアドレスの指定自体問題ないとのことで安心しました。

ip route show table 2で何も出力なかったため、/etc/vmware/route-tables.cfg ファイルを編集してtable 2を設定しました。

ただ、それだけではうまくルーティングされないようでVIPにアクセスできず、/etc/systemd/network/10-xxxx.networkでネットワークアドレスとゲートウェイの指定を行いました。

ひとまずこれで確認進められるので、ここはそのままにしておきます。。

 

資料もありがとうございます。非常に参考になりました。

色々ありがとうございました!

Reply
0 Kudos