KubernetesのNetworkPolicyで、ipBlock
を使うことで、IPのCIDR範囲を指定して、Ingress(入方向)やEgress(出方向)の通信制御ルールの送信元や宛先を制限できます。
しかし、ここで指定すべきIPはクラスタ外部のIPアドレスであることが重要です。
理由は、クラスタ内部のPodのIPアドレスは動的に割り当てられ、予測できないためです。
1. クラスタ内部と外部のIPアドレスの違い
- PodのIPは動的で、Podが再起動や移動するたびに変わります。
- そのため、
ipBlock
はクラスタ外部のIPに対して使うのが基本です。
2. ネットワークの入方向・出方向のIP書き換えについて
Kubernetesのネットワーク処理では、パケットの送信元(source)や宛先(destination)IPが書き換えられることがあります。
しかし、NetworkPolicyの適用タイミングに関して、Kubernetes自体はパケットのIP書き換えがNetworkPolicyの前後どちらで行われるかを定義していません。
つまり、使うクラウドプロバイダーやネットワークプラグイン(Calico、Cilium、Flannelなど)によって、挙動が異なります。
3. 具体的な挙動例
-
Ingress(入方向)通信
- 実際の送信元IPアドレスを元にフィルタリングできるケースもあれば、
- LoadBalancerのIPなどに書き換わり、NetworkPolicyの“source IP”が異なる場合もあります。
-
Egress(出方向)通信
-
ipBlock
による宛先IP制限は、環境によっては有効な場合と無効な場合があります。
-
4. まとめ
-
ipBlock
はクラスタ外部のIP制御に使うのが適切です。 - Pod間通信の制御は
ipBlock
ではなく、ラベルやNamespaceを使った制御を推奨します。 - ネットワークプラグインやクラウド環境によって、IP書き換えのタイミングやNetworkPolicyの効果が異なるため、実環境での動作検証が必要です。
参考資料
この記事がNetworkPolicyの設計・運用に役立てば幸いです。
ご意見や質問があればコメントでお知らせください。