Kubernetes（EKS）ネットワーク入門

Kubernetes（EKS）のネットワークについて、社内勉強会で使用した資料です。
お役に立てれば嬉しいです。

Transcript

1. Kubernetes（EKS） ネットワーク入門 2026/2/19 李俊起 1
2. 話す内容 2026/2/19 2 • Pod間、外部からPodへの通信を可能にする仕組み • Service、Ingress、GatewayAPI • iptables、kube-proxy • CNIについて • DNSについて • 通信の流れ • Pod間通信 • 外部からの通信
3. 2026/2/19 3 Pod間、外部からPodへの通信を 可能にする仕組み
4. apiVersion: v1 kind: Service metadata: name: nginx spec: type: ClusterIP ServiceのTypeを指定 selector: app: nginx このラベルを持つPodにトラフィックを転送 ports: - port: 80 targetPort: 80 Serviceについて 2026/2/19 4 • Podは頻繁に入れ替わり、そのたびにPodのIPは変わる • ServiceはPodのIPが変わっても通信できるようにするためのもの • Serviceを作成するとServiceのドメイン <service- name>.<namespace>.svc.cluster.local が作成され、そのドメイン名で Podにアクセスでき、 Pod IPの変更を意識しなくて良くなる apiVersion: apps/v1 kind: Deployment metadata: name: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx Podに付与されるラベル ...
5. Serviceの種類 2026/2/19 5 • ClusterIP（デフォルト） • NodePort • LoadBalancer • Headless
6. ClusterIP 2026/2/19 6 • 外部に公開する必要のない、Pod間通信のためのもの ➢ Kubernetesクラスター内でのみ使える仮想IPアドレスが割り振られる • 仮想的なIPアドレスから実際のPodのIPアドレスにDNATされる • １つのServiceに複数のPodが関連づけられている場合、自動的 にロードバランシングされる
7. NodePort 2026/2/19 7 • 外部からPodにアクセスするための一番基本的なtypeのService ➢ NodePortの範囲は30000〜32767 • Podに ワーカーノードのIP ＋ NodePort でアクセスする ➢ Podが存在するワーカーノード以外のワーカーノードのIPからもアクセス できる（全ワーカーノードに同じiptablesのルールが設定されるため） • LBとPodの間で繋ぎ口としても機能する（※） ※LBの種類や作成方法、ベンダーなどによって異なる。 NodePortを介さずにLBから直接PodのIPにアクセスする場合もある。
8. Service（ClusterIP、NodePort）の簡略図 2026/2/19 8 ワーカーノード 3 0 0 0 0 service type: NodePort selector: app: handson-app ports: - port: 800 targetPort: 80 nodePort: 30000 ClusterIP: 10.100.159.150 8 0 0 POD labels: app: handson-app 8 0 POD IP: 172.31.22.175 POD labels: app: mysql POD IP: 172.31.46.249 ワーカーノード ノードIP: 18.183.62.141 ユーザ POD labels: app: handson-app 8 0 POD IP: 172.31.11.147 18.183.62.141:30000 ノードIP: 54.95.101.197 10.100.185.77:33006 service type: ClusterIP selector: app: mysql ports: - port: 33006 targetPort: 3306 3 3 0 6 ClusterIP: 10.100.185.77 10.100.185.77:33006 3 0 0 0 0 54.95.101.197:30000 Serviceは特定のノード 内にあるものではない ですが、理解を助ける ためにノード内に入れ て表現しています
9. LoadBalancer 2026/2/19 9 • L４のロードバランシング • 別途Controllerのインストールが必要 ➢ LoadBalancerのリソース作成を検知し、実際のLBを作成するため • EKS AutoModeの場合、AWS Load Balancer Controllerが ビルトインされていて、NLBが作成される
10. LoadBalancerのサンプルマニフェスト 2026/2/19 10 apiVersion: v1 kind: Service metadata: name: my-app-nlb annotations: service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip" service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing" spec: type: LoadBalancer loadBalancerClass: eks.amazonaws.com/nlb selector: app: my-app ports: - port: 80 targetPort: 8080 • 「aws-load-balancer-nlb-target-type」には“ip”もし くは“instance”を指定できて、それによってLBからPodへ の通信フロー(方式)が変わる
11. Headless 2026/2/19 11 • 主にStatefulSet（ステートフルなPod）で使われるもの • 「clusterIP: None」を指定することでHeadless Serviceになる。 Headless ServiceにはClusterIPが生成されない • <Pod名>.<Service名>.<namespace名>.svc.cluster.local ドメインで、固定のPodにアクセスできる（※） apiVersion: v1 kind: Service metadata: name: thanos-ingesting-receiver namespace: monitoring labels: app: thanos component: ingesting-receiver spec: clusterIP: None # ここ selector: app: thanos Cluster IPがNone になっている ※StatefulSet側で対象Serviceの指定が必要
12. その他外部からアクセスのためのリソース（１） Ingress 2026/2/19 12 • L７のロードバランシング ➢ URLパスやHost名でのルーティングが可能 • EKS AutoModeの場合、同じくビルトインの AWS Load Balancer ControllerでALBが作成される
13. Ingressのサンプルマニフェスト 2026/2/19 13 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: my-app-ingress spec: ingressClassName: alb rules: - host: app.example.com http: paths: - path: / pathType: Prefix backend: service: name: my-app-svc port: number: 80 • LB（の作成）とルーティングのルールが１つのリソースで 管理される
14. その他外部からアクセスのためのリソース（２） GatewayAPI 2026/2/19 14 • Ingressの後継として、ロールベースで分離された設計になっている （GatewayClass / Gateway / Route） • Ingressより高度なルーティング(e.g. 重み付けトラフィック分割な ど)が標準仕様としてサポートされる。 また、L7だけではなく、L4のルーティングも可能 https://gateway-api.sigs.k8s.io/
15. GatewayAPIの各リソース（サンプルマニフェスト） 2026/2/19 15 apiVersion: gateway.networking.k8s.io/v1beta1 kind: GatewayClass metadata: name: amazon-vpc-lattice spec: controllerName: application-networking.k8s.aws/gateway-api-controller apiVersion: gateway.networking.k8s.io/v1beta1 kind: Gateway metadata: name: my-hotel spec: gatewayClassName: amazon-vpc-lattice listeners: - name: http protocol: HTTP port: 80 apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: inventory spec: parentRefs: - name: my-hotel sectionName: http rules: - backendRefs: - name: inventory-ver1 kind: Service port: 8090 weight: 50 - name: inventory-ver2 kind: Service port: 8090 weight: 50 どのControllerで Gateway（LB層）を作成 するかを定義 e.g. VPC Lattice、Envoy • Gatewayリソースで 実際のLB層が作成される • 通信を受け付ける リスナーを定義 各種Routeリソース でルーティングの ルールを設定
16. Endpoints / EndpointSlice 2026/2/19 16 • Serviceのselectorの条件に一致するPodのIPアドレスと Port番号（の一覧）を持つリソース • kube-controller-manager内のEndpointSlice Controllerが Serviceと（selectorの条件に一致する）Podを監視して、 EndpointSliceを更新する
17. iptables 2026/2/19 17 • Linuxのファイアウォール機能で、パケットフィルタリングだけでは なく、NATにも使える • KubernetesではServiceのCluster IPから実際のPodのIPへ の変換（DNAT）にiptables（※）が使われる ※kube-proxyのモードで、iptables以外にIPVSやnftablesがあるけど、 EKSではdefaultでiptablesが使われるため、ここではiptablesの前提で話を進めます
18. kube-proxy 2026/2/19 18 • DaemonSetとして各ワーカーノード上に存在 ➢ EKS AutoModeではプロセスとして存在 • ServiceとEndpointSliceリソースを監視して、 ワーカーノード上のiptablesのNATルールを更新する役割を担う ➢ ServiceはDNATの変換前の宛先IP（ClusterIP）のため ➢ EndpointSliceはDNATの変換後の宛先IP（PodのIP）のため
19. Service → EndpointSlice → kube-proxy → iptablesの関係図 2026/2/19 19 Pod IP: 10.0.0.1 ①PodとServiceを作成 ClusterIP: 10.0.10.10 EndpointSlice Controller Pod IP: 10.0.0.2 kube-proxy ②Controllerによって EndpointSliceリソースが 作成される Serviceに紐づく Pod IPの一覧を管理 ③kube-proxyによって iptablesのルールが作成される ServiceのClusterIP・port・ targetPort、EndpointSliceのPodのIP などに基づき、DNATのルールを管理
20. 2/19/2026 20 CNIについて
21. CNIとは（１） 2026/2/19 21 • コンテナランタイム(e.g. containerd)がコンテナの ネットワークインターフェースを設定する際に、 CNIプラグインを呼び出すための標準的な仕様 • CNIプラグインは以下のようなことを行う ➢ Podのネットワーク（netns）にNIC（veth）の割り当て ➢ PodのvethにIPアドレスの割り当て、ルーティングの設定 ➢ ホスト側のルーティング設定
22. CNIとは（２） 2026/2/19 22 • Kubernetesは以下のネットワーク要件を定めており、 CNIプラグインはこれを満たす限り自由に実装できる ➢ Pod同士はNATなしで直接通信できる ➢ ノード（kubeletなどノード上のエージェント）とPodはNATなしで直接通信できる ➢ PodのIPはPod内外で同一（Pod自身が認識するIPと外部から見えるIPが同じ） • VPC CNI、Calico、Ciliumなど数多くのCNIプラグインが存在し、 CNIプラグインによってネットワークの構成や使える機能に違いが ある
23. CNIのネットワークモード 2026/2/19 23 • Overlay ➢ VXLANやIPIPでパケットのカプセル化 • Underlay ➢ パケットのカプセル化なしで、PodのIPで直接通信 ➢ EKSで使われるVPC CNIはUnderlay ➢ ENIのセカンダリIPをPodに直接割り当てるため、 Pod IPがVPCネットワーク上でそのままルーティング可能 ➢ Public CloudのマネージドK8sではほとんどUnderlay方式を採用 • Routing ➢ BGP等でPodへのルート情報を交換
24. Overlay 2026/2/19 24 • ワーカーノードとPodが異なるネットワークセグメント上に存在し、 異なるワーカーノード上のPod間の通信時、VXLANやIPIPで パケットのカプセル化（トンネリング）を行う https://www.alibabacloud.com/blog/getting-started-with-kubernetes-%7C-kubernetes-cnis-and-cni-plug-ins_596330
25. Underlay 2026/2/19 25 • ワーカーノードとPodが同じネットワークセグメント上に存在し、 パケットのカプセル化を行わずに直接PodのIPで通信する https://www.alibabacloud.com/blog/getting-started-with-kubernetes-%7C-kubernetes-cnis-and-cni-plug-ins_596330
26. Routing 2026/2/19 26 • BGPなどでPodへのルーティング情報をノード間で交換・ルート テーブルに登録し、カプセル化なしでルーティングする https://www.alibabacloud.com/blog/getting-started-with-kubernetes-%7C-kubernetes-cnis-and-cni-plug-ins_596330
27. ※補足 NetworkPolicy 2026/2/19 27 • デフォルトでは、すべてのnamespace上のすべてのPod同士が 相互に通信できる • NetworkPolicyを使えば namespace、IPレンジ、ラベルなどを もとにingress/egressの細かい制御ができる • CNIプラグインごとに使える機能に違いがある ➢ そもそもNetworkPolicyをサポートしてないCNIプラグインもある （e.g. Flannel）
28. 2026/2/19 28 DNSについて
29. CoreDNS 2026/2/19 29 • Kubernetes内の名前解決を担当 • kube-system namespace上に（Podとして）存在 ➢ EKS AutoModeではWorkerNode上にプロセスとして配置されていて、 ユーザ側(kube-system namespace上)には見えない • 「cluster.local」 （Service）ドメインは自分で処理し、 それ以外のドメインは外部DNSサーバに転送 ➢ EKSの場合は、VPC DNS（Route 53 VPC Resolver）に転送される
30. Podから名前解決の流れ 2026/2/19 30 • Pod内の/etc/resolv.confにDNSサーバとしてCoreDNS （のClusterIP）が設定されている search monitoring.svc.cluster.local svc.cluster.local cluster.local ap-northeast-1.compute.internal nameserver 172.20.0.10 # CoreDNSのClusterIP options ndots:5 CoreDNSの ClusterIP CoreDNSの (Podの)IPに DNAT cluster.localドメイン （Service）の場合 cluster.local以外の ドメインの場合 送信先Serviceの ClusterIPに名前解決 外部DNSサーバに転送 ※EKSの場合はRoute 53 VPC Resolver 外部DNSサーバにて 名前解決
31. 2/19/2026 31 通信の流れ
32. Pod間通信（同じノード上のPod間） 2026/2/19 32 • ノード側（netns）のルートテーブルのルールでPodにルーティング ワーカーノード POD 1 veth POD 2 veth eth veth veth Pod2用のServiceのドメインでPod2にアクセス ①CoreDNSからPod2用 ServiceのClusterIPに解決 ②ノード上のiptablesのルールで Pod2のIPアドレスにDNAT ③ノードのルートテーブルに定義されている Pod2のIPアドレスに対するvethにルーティング Podのnetns ノードのnetns
33. Pod間通信（異なるノード上のPod間） Underlay（EKS）の場合 2026/2/19 33 • VPC fabricを経由して、PodのIPのままルーティングされる ワーカーノード１ POD 1 veth POD 2 veth eth veth veth Pod2用のServiceのドメインでPod2にアクセス ①CoreDNSからPod2用 ServiceのClusterIPに解決 ②ノード上のiptablesの ルールでPod2の IPアドレスにDNAT ③自ノードのルートテーブルにPod2への直接 のルートがないため、サブネット/VPCレンジの ルートに従い、ノードのethにルーティング Podのnetns ノードのnetns ワーカーノード２ eth ④ノード2のethにルーティング VPC fabric ⑤ノードのルートテーブルに 定義されているPod2の IPアドレスに対するvethにルーティング
34. Pod間通信（異なるノード上のPod間） Overlayの場合 • IPIPやVXLANでtargetノードのIPにカプセル化してルーティング ワーカーノード１ POD 1 veth POD 2 veth eth veth veth Pod2用のServiceのドメインでPod2にアクセス ①CoreDNSからPod2用 ServiceのClusterIPに解決 ②ノード上のiptablesの ルールでPod2の IPアドレスにDNAT ③トンネルI/Fでノード２のIPにカプセル化 Podのnetns ノードのnetns ワーカーノード２ eth ⑤ARPにより、 ノード2のethに転送 ⑥トンネルI/Fで Pod２のIPに デカプセル化 トンネル I/F ④カプセル後のノード2のIPに より、ethにルーティング トンネル I/F 2026/2/19 34 ⑦デカプセル化後の Pod2のIPでvethに ルーティング
35. 外部からPodへの通信 aws-load-balancer-nlb-target-type: ipの場合 2026/2/19 35 • iptablesのルールを経由せず、直接ノードについているPod用の ENIからPodにルーティング ワーカーノード POD veth eth veth ②ノードのethに ルーティング ③ノードのルートテーブルに定義されている PodのIPアドレスに対するvethにルーティング ターゲットとして 「PodのIP:Podの公開Port」が 登録されている ユーザ ①ユーザがLBの エンドポイントにアクセス VPC fabric
36. 外部からPodへの通信 aws-load-balancer-nlb-target-type: instanceの場合 2026/2/19 36 • ノードのiptablesのルールで、 「ノードのIP:NodePort」→「PodのIP:Podの公開Port」にDNAT ターゲットとして 「ノードのIP:NodePort」が 登録されている ワーカーノード POD veth eth veth ②ノードのethに ルーティング ③ノード上のiptablesのルールで 「PodのIP:Podの公開Port」にDNAT ユーザ ①ユーザがLBの エンドポイントにアクセス VPC fabric ④ノードのルートテーブルに 定義されているPodのIPアドレスに 対するvethにルーティング