Gateway の nodePort の手当てを外す(nodeport.yaml・範囲の設定)

[5ym]

k3s の頃に「要る」と結論した Gateway の nodePort 80/443 の手当てを、Talos で確かめ直して外します。

• VM(talos-boot の実験 run 39091678828): 範囲を既定に戻し nodePort がランダム(32399/32657)でも、外・ノード自身(hostNetwork の Pod)・Pod のどこからも http 301 / https 200
• 本番: port-80 の nodePort を 30080 にずらしても 301 / 200(すぐ 80 に戻した)

machine config の差分は API サーバの service-node-port-range と Cilium の node-port-range だけ。マージ後に render → apply-config → upgrade-k8s を流し、Gateway の Service を作り直してランダムな nodePort にする。

🤖 Generated with Claude Code

https://claude.ai/code/session_01JbmWyUB9jcBcYCnNyiGBSV

[claude]

Claude finished @5ym's task in 23s —— View job

---

レビュー結果

nodePort の手当て(Job・API サーバの範囲・Cilium の範囲)を外す変更です。差分は意図どおりで、実測の根拠も PR 本文とコメントにあります。ブロックする問題はありません。指摘は 3 点で、うち 2 点は文書の参照切れです。

1. 参照切れのコメント(変更箇所外)

bootstrap/cilium/values.yaml から「帰結が 3 つある」のコメントを消したため、次の 2 箇所が存在しない説明を指しています。

• apps/forgejo/node-access.yaml:3 の「bootstrap/cilium/values.yaml の nodePort の説明の 3」
• talos/patches/cluster.yaml:99 の「bootstrap/cilium/values.yaml の nodePort の 3」

この 2 箇所にも「k3s の頃の話」と注記を足すか、参照を直してください。apps/netbird/routing-peer.yaml:86 は節番号なしの参照なので問題ありません。

「ノード自身から 80/443 に届かない」前提で作った回避策(forgejo の node-access、netbird の hostNetwork 外し)も、この PR では残しています。残すのは安全側なので構いませんが、不要になったかは別途確認が要ります。

2. 適用順序のリスク(要確認)

マージ後の手順は render → apply-config → upgrade-k8s → Gateway の Service 作り直し、です。この間は、既存 Service が nodePort 80/443 のまま、API サーバと Cilium の範囲だけ既定に戻った状態になります。

• Cilium が範囲外の nodePort 80/443 を扱えなくなっても、Envoy が hostNetwork で直接受けるので通信は通るはずです。PR の実測(VM と本番での 30080 ずらし)は「範囲内の別の値」のケースで、「範囲外の値が残っている」状態では測っていないように見えます。
• API サーバが範囲を狭めた後、Cilium operator が既存 Service を update すると provided port is not in the valid range で弾かれる可能性があります。Service を作り直すまでの間、Gateway の更新が止まらないか確認してください。
• 安全に進めるなら、先に Gateway の Service を作り直してランダムな nodePort にし、そのあとで範囲を戻す順序のほうが安全です。ただしこの PR は範囲変更と同時にマージされるので、手順書に書いておくとよいです。

3. 細かい点

talos/patches/apiserver.yaml は extraArgs を丸ごと消した状態です。他の extraArgs が無いことは確認済みで、問題ありません。

その他

• bootstrap/gateway/nodeport.yaml の削除に対応する参照(gateway-nodeport、kustomization 等)は、grep した範囲では残っていません。
• talos-boot.yml の verify は、ランダムな nodePort のまま 301 / 200 を確認する形になっています。変更後の挙動を CI で検証できます。
• テストはありません。この種の変更では、talos-boot の実験 run が実質のテストです。

[claude]

Claude finished @5ym's task in 16s —— View job

---

レビュー結果

nodePort の手当て(Job・API サーバの範囲・Cilium の範囲)を外す変更です。差分は意図どおりで、ブロックする問題はありません。

前回指摘の参照切れは直っています。

• apps/forgejo/node-access.yaml:3 と talos/patches/cluster.yaml:99 は「k3s の頃・今も要るかは未確認」に直っています。
• gateway-nodeport や nodeport.yaml への参照は、リポジトリ内に残っていません。
• docs/decisions.md の消した行は箇条書きの末尾で、前後のリストは崩れていません。

要確認: 適用順序

マージ後の手順は render → apply-config → upgrade-k8s → Gateway の Service 作り直し、です。この間は、既存 Service の nodePort が 80/443 のまま、API サーバと Cilium の範囲だけ既定に戻った状態になります。この状態は PR の実測(範囲内の 30080 にずらした)ではカバーされていません。

• API サーバが範囲を狭めたあと、Cilium operator が既存 Service を update すると provided port is not in the valid range で弾かれる可能性があります。Service を作り直すまで Gateway の更新が止まらないか、確認してください。
• 通信そのものは、Envoy が hostNetwork で受けるので通るはずです。ただしこれも未実測です。
• 手順書には「Service を先に削除して作り直し、そのあと apply-config」の順を書いておくと安全です。

補足

• forgejo の node-access と netbird の hostNetwork 外しは、残してあります。安全側なので構いません。不要かどうかは別途確認が要ります。
• talos-boot.yml の verify は、ランダムな nodePort のまま 301 / 200 を見る形になりました。変更後の挙動を CI で見られます。
• テストはありません。この種の変更では talos-boot の実験 run が実質のテストです。