k3sと物理ネットワークの境界 #12｜Ingress・VIP・NFSをどうつないだか
この記事で分かること
Pod CIDR / Service CIDRと物理VLANの違い
k3sで「物理IP」が必要になる場所
InternetからIngressまでの経路
NFS StorageがKubernetes Networkとどう接続するか
Cluster台数やFirewall Objectが実機とズレる「運用後の現実」
⏪ 前の記事：ログが来ない原因はログサーバではなかった #11｜FortiGate・Ubiquiti・ESXi・NASのSyslog集約
k3sでNetwork障害が起きると、Kubernetesだけを見続けて沼ることがある。
PodはRunning。 Serviceもある。 Ingressもある。
それでも外から届かない。 NFSにも届かない。
理由は、k3sのNetworkにはCluster内部の世界と、物理LANへ出る境界があるからだ。
Node IP、Pod IP、Service IP、Ingress、VIP、Storage。
これらを全部同じ「KubernetesのIP」として扱わない。
Pod CIDR / Service CIDRは物理VLANを直接消費しない
Pod CIDRとService CIDRはCluster内部のAddress Spaceだ。
物理側のApp VLANをPod数だけ消費するわけではない。
一方、物理Network側で必要になるAddressはある。
例えば、
Node
Ingress入口
LoadBalancer / VIP
外部公開用Address
VM
Storage
Management
だ。
だからApp側のSubnet設計では、Pod数そのものより、
Clusterが物理Networkへ接続する接点がどれだけ増えるか
を見る。
外部公開はPodへ直接入れない
我が家の外部公開経路は、概念的にはこうなる。
外部からNodePortやPodへ直接飛ばす構成にはしていない。
入口を一度DMZ側へ寄せ、Security Layerを通してからIngressへ渡す。
これで、
Internet側の問題とCluster内部の問題を分けやすくなる。
StorageはClusterの「外」にいる
k3sから使うStorageとしてNAS/NFSがある。
Podから見ればVolumeだが、物理的には別のStorage機器だ。
つまり、
という経路になる。
NFSを使うなら111/2049等の必要な通信を、Node/Storage間だけ許可する。
Clusterの中だけ見ていても、この経路は分からない。
KubernetesのTroubleshootingで、
「PVCはある」 「PodもRunning」
なのにStorageへ到達できない場合、物理Network側も見る必要がある。
「NodeがReady」だけでは外部公開は保証しない
Nodeが全部Readyでも、
Ingressまで外部通信が届くとは限らない。
逆に、Ingressが動いていてもBackend ServiceのEndpointがなければ失敗する。
実際のTroubleshootingでも、
PodはRunning
Pod IPへ直接到達できる
HTTP接続自体はできる
しかしIngress側ではService / Endpointの不整合
という切り分けをしたことがある。
Kubernetesでは、
Physical Network
Ingress
Service
Endpoint
Pod
を一段ずつ見る。
これは#9のProxy Chainと同じ考え方だ。
台帳と実機は時間とともにズレる
ネットワーク更改の記事を書き始めた当初は、k3sを8台構成として扱っていた。
運用を続けると、Readyとして見えているNode数と、FortiGateに残るAddress Object数が一致しない状態も出てくる。
使わなくなったNode ObjectがFirewall側へ残る。
Clusterは減ったのに台帳は減っていない。
これは単なるKubernetesの話ではない。
Network機器、DNS、監視、台帳の全てに「過去の構成」が残る
という話だ。
そして、これが次の記事につながる。
実機設定を棚卸ししたら、noteに書いた自分の設計と、今動いている設定がいくつもズレていた。
⏩ 次回：#13 設計書と実機がズレていた｜自宅ネットワークを棚卸しして見つけたDesign Drift
