Kubernetes トラフィックルーティング 徹底解説!! Oracle Cloud Hangout Café – Season9 #3 Takuya Niita Principal Cloud Engineer Oracle Corporation Japan, Solution Architect Dec 11th, 2024 Service/Ingress/Gateway API 全網羅!!

Introduction Takuya Niita Principal Cloud Engineer Oracle Corporation Japan 2 Copyright © 2024, Oracle and/or its affiliates • 日本オラクル株式会社 ソリューションアーキテクト部 • AppDev/Container/FaaS/(a little)ML…(GPU) • Oracle Cloud Hangout Café メンバー • Oracle Groundbreakers Advocate • 前職はSIer • Oracle歴: 5年半 • ジブリ大好き もちろん今回もネタあります…!! takuya_0301

Title (agenda) Copyright © 2024, Oracle and/or its affiliates 3 3 Kubernetes Ingress 2 Kubernetes Service 5 まとめ 4 Kubernetes Gateway API 1 トラフィック ルーティングの基礎 とKubernetes いろいろ寄り道しながら解説していくので、迷った方は右上に以下のマークがついているスライドだけ見 てください…!!

トラフィックルーティングの基礎とKubernetes Oracle Cloud Hangout Café – Season 9 #3 4 Copyright © 2024, Oracle and/or its affiliates

トラフィックルーティングとは…?? トラフィックルーティング • 経路制御とも呼ばれる • 「ルーター」が役割を担う • 任意のネットワークにおけるパス選択のプロセス • OSI参照モデルとしてはレイヤー3(ネットワーク層） 以上に実装される仕組み • 複数のネットワークやノード(マシン)間を接続するパ ス（経路）で構成 • パスは複数構成でき、それぞれのパスで通信可能 • ルーティングテーブル（ルーターが利用）を利用 • 主に「宛先（≒目的の駅）」、「ネクストホップ （≒次の乗り換え駅）」、「出力インタフェース （≒利用する路線）」で構成 5 Copyright © 2024, Oracle and/or its affiliates 192.168.1.1/24 192.168.3.1/24 192.168.2.1/24 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 fa0/0 .254 fa0/1 .254 fa0/0 .253 fa0/1 .254 宛先 ネクストホップ 出力インタフェース 192.168.3.0/24 192.168.2.253 fa0/1 ルーターAのルーティングテーブル ルーターA ルーターB 192.168.3.1まで 行きたい… 着いた…!! 宛先 ネクストホップ 出力インタフェース 192.168.3.0/24 connected fa0/1 ルーターBのルーティングテーブル

ルーティング方式 スタティックルーティング • ネットワーク管理者が宛先ネットワークへの最適なルートを手動で設定したルート • 以下のようにネットワーク状態に変化があっても、自動的に切り替わることはない • ネットワーク機器に障害が発生した場合 • 他に最適なルートが新たにできた場合 … ダイナミックルーティング • ルーターで設定されたルーティングプロトコルで動的に追加されるルート • あるルーターで設定されたルーティングプロトコルの動作にしたがって他のルーターにも通知 • ネットワークの状態に変化があった場合、自動的に最適なルートに切り替わる • 代表的なプロトコル: OSPF(Open Shortest Path First), BGP(Border Gateway Protocol)… (直接接続/connected) • ルーターと隣接している（ルーター不要で到達できる）ルート • 通常はネットワークインタフェースの有効化後に自動的に設定 6 Copyright © 2024, Oracle and/or its affiliates

【ちょっと寄り道】スタティックルーティング vs ダイナミックルーティング 7 Copyright © 2024, Oracle and/or its affiliates スタティックルーティング ダイナミックルーティング 設定方法 管理者が手動で設定 ルーティングプロトコルにより動的に追加 状態変化時の挙動 変化なし 動的に更新 ルーターへの負荷 なし CPUやメモリを消費 管理者のタスク 設定の手間 ルーティングプロトコルへの理解 プロトコル - OSPF, BGP… 【コラム】 ダイナミックルーティングのプロトコルは大きく、IGP(Interior Gateway Protocol)とEGP(Exterior Gateway Protocol ≒ BGP)に分けられ、BGP以 外のプロトコルであるOSPFなどはIGPに属する 基本的にはBGPの方が大規模な運用可能で耐障害性にも優れているが、リソース消費や運用の手間などを考慮してIGPがあり、複数のプロ トコルが用意されている

【ちょっと寄り道】代表的なダイナミックルーティングプロトコル – BGP – BGP(Border Gateway Protocol) • インターネットに存在する各ネットワーク（クラウドベンダー, ISP, 企業, 学校法人…が所有）を接続するためのダイナミックルーティ ングプロトコル • 各ネットワーク内に存在するAS（一意の識別番号であるAS番号を所有）を利用して外部ネットワークへのルーティングを実施 • 内部ネットワークのルーティングはIGPで実施（iBGPという内部用のBGPも利用できるが、前述した通りIGPプロトコルは多数） 8 Copyright © 2024, Oracle and/or its affiliates ASは地域の郵便局のイメージ。 特定の家に行くには必ず郵便 局（AS）経由で向かう BGPによるダイナミックルーティング IGPによるダイナミックルーティング AS

ルーティングテーブル ルーティングテーブル • Linuxでは”route(Deprecated)”/”ip route”コマンドを利用して経路情報の設定が可能（スタティックルーティング） • net-toolsパッケージに含まれる 9 Copyright © 2024, Oracle and/or its affiliates 宛先 via ネクストホップ dev(インタフェース) インタフェース名 「“169.254.169.254”に向かうパケットは”ens3”のインタフェースから“10.0.0.1”を経由してください」というルール “ifconfig”もしくは”ip a”コマンドによるインタフェース

iptables 10 Copyright © 2024, Oracle and/or its affiliates iptables • ファイアウォールとルーターの機能を兼ね備えたパケットフィルタ • ルーティングテーブルはレイヤー3(IP)で動作するが、 iptablesはレイヤー4(TCP/IP, UDPなど)を利用する • “INPUT”, “OUTPUT”, “FORWARD”,“PREROUTING(DNAT)”, “POSTROUTING(SNAT)”のチェインを意識して設定する • iptablesを利用すれば、Linuxサーバでのルーターの構築も比較的簡単にできる -A チェイン -p プロトコル -d パケットを受信するIP –dport ポート番号 -j SNAT/DNAT --to-destination 宛先 -A PREROUTING -p tcp -d 10.20.30.40 –dport 1111 –j DNAT --to-deatination 192.168.10.20:1111 「”10.20.30.40:1111”にきたパケットは、IPを192.168.10.20に変換（ポートはそのまま）して転送 今日の ポイントスライド NAPT(IPマスカレード) もできる 【この後のお話】 Kubernetesの（特に内部での）トラフィックルーティングは、主にiptablesを元に実施する

Kubernetesのトラフィックルーティング要素 11 Copyright © 2024, Oracle and/or its affiliates /ingress https://ocha.com https://cafe.com /gateway パスベース パスベース ホスト

Kubernetes Service Oracle Cloud Hangout Café – Season 9 #3 12 Copyright © 2024, Oracle and/or its affiliates

ホスト パスベース パスベース Kubernetesのトラフィックルーティング要素 13 Copyright © 2024, Oracle and/or its affiliates Load Balancer /ingress https://ocha.com https://cafe.com /gateway

Service Service • 1つ以上のPodを公開するためのエンドポイント（言い換えれば、“ロードバランサー“） • セレクターを利用して対象となるPodを紐づける(Nodeは意識しない -> Nodeに跨っても有効) • オーケストレーションの目的の一つである“サービスディスカバリ”を実現(種類が複数存在、後述) • クライアントからPodを管理する責務を分離 • Podがクラスタやアプリケーションの状態によって削除される揮発的なリソースのために存在する 14 Copyright © 2024, Oracle and/or its affiliates “app=MyApp”という ラベルが付与された Podが紐づく

Serviceの種類(type) - ClusterIP ClusterIP • デフォルトのServiceであり、クラスタ内部の仮想IPを利用して対象のPodを公開する • クラスタ内部からのみアクセス可能 • 実態はkube-proxyと連携してiptablesを利用して実現されている（デフォルト） 15 Copyright © 2024, Oracle and/or its affiliates CoreDNS 名前解決 リクエスト ClusterIP ルーティング Podが落ちたりなどで新たなPod が起動しても、セレクタによっ てServiceに紐づけられる iptables /etc/resolv.conf 今日の ポイントスライド Nodeごと DaemonSet

Serviceの種類(type) - ClusterIP ClusterIP • デフォルトのServiceであり、クラスタ内部の仮想IPを利用して対象のPodを公開する • クラスタ内部からのみアクセス可能 • 実態はkube-proxyと連携しiptablesを利用して実現されている（デフォルト） 16 Copyright © 2024, Oracle and/or its affiliates CoreDNS 名前解決 リクエスト ルーティング iptables /etc/resolv.conf ClusterIP 実は下位リソースが あります…!!

Serviceの下位リソース – EndpointSlice(Endpoint) EndpointSlice（Endpoint） • Service作成時にペアで自動的に作成されるリソース（EndpointSlice(Endpoint) Controllerが作成） • 実際にルーティング対象となるPodのIPとそれらを公開する仮想IPを管理するリソース • 実際にネットワーク設定を実施するのはkube-proxy（後述） • 元々はEndpointだったが、スケーラビリティの問題からEndpointSliceという新たな仕組みが登場 • 以前は、全てのServiceに紐づくエンドポイントが単一のEndpointリソースとして管理されていた • 現在はEndpointSliceがデフォルト(v1.21でstable) 17 Copyright © 2024, Oracle and/or its affiliates Podの作成、更新、削除の監視 Serviceの作成、更新、削除の監視 Endpointの作成、更新、削除 EndpointSlice(Endpoint)の取得結果例 セレクタで取得したPodのIP 今日の ポイントスライド

Serviceの種類(type) - ClusterIP ClusterIP • デフォルトのServiceであり、クラスタ内部の仮想IPを利用して対象のPodを公開する • クラスタ内部からのみアクセス可能 • 実態はkube-proxyと連携しiptablesを利用して実現されている（デフォルト） 18 Copyright © 2024, Oracle and/or its affiliates CoreDNS 名前解決 リクエスト ClusterIP ルーティング /etc/resolv.conf iptables 動作モードが 3 + 1パターンあります…!! (厳密には“kernelspace(Windows限定)モード” も ありますが、割愛します…)

kube-proxyの動作モード – iptables iptablesモード • iptablesを利用する • kube-proxyが対象のPodにルーティングするルールをiptablesに設定する • ルーティングは対象Podにランダムに実施 • 最初にルーティングされたPodが応答しない場合、そのコネクションは失敗する • Readiness Probeで対応 • この動作モードが現在のデフォルト • オーバヘッドが最も少ない動作モード（Linuxのnetfilterという仕組みにより） 19 Copyright © 2024, Oracle and/or its affiliates リクエスト ClusterIP ルーティング iptables iptablesを 書き換える ルーティングす るのはこっち 今日の ポイントスライド

kube-proxyの動作モード – nftables nftablesモード(k8s v1.31でβ) • 新たに開発されているパケットフィルタリングツールである”nftables”を利用するモード • iptablesのパフォーマンス的な課題やIPVS(後述)の制限などを背景に開発されている • 様々なLinuxディストリビューションもnftablesへの移行を進めている • カーネルからの削除予定はない • iptables v1.8.0からiptablesがnftablesモード(nf_tables)という形態で動作するようになっている • ただし、互換性の問題からパフォーマンスは改善しない • kube-proxyのnftablesモードではnftablesネイティブ(≠ iptables)で動作 • CNI(Container Network Interface)によっては互換性がない可能性がある • 将来的にはデフォルトになりそう… 20 Copyright © 2024, Oracle and/or its affiliates

kube-proxyの動作モード – IPVS IPVSモード • IPVS(IP Virtual Server) ※を利用する • kube-proxyが対象のPodにリダイレクトするルールをIPVSに同期させる • ルーティングはさまざまなルールを利用可能 • ラウンドロビン/最低コネクション/送信先（送信元）ハッシュ… • データ構造がハッシュテーブルであること、カーネルで動作することから他の2つに比べて低レイテンシーで高パ フォマンスなルーティングを実現可能（ただし、開発はそこまでアクティブではない） ※: Linuxカーネルの内部L4ロードバランサー 21 Copyright © 2024, Oracle and/or its affiliates リクエスト ClusterIP ルーティング IPVS IPVSにルール を同期 ルーティングす るのはこっち

【v1.26で削除済み】kube-proxyの動作モード – user-space user-spaceモード • iptablesを利用する • kube-proxyが対象のPodにルーティングする • ルーティングは対象Podにラウンドロビンにて実施 • 最初にルーティングされたPodが応答しない場合、自動的に再接続する • オーバヘッドが最も高いモード • ルーティングをkube-proxyが（しかもユーザスペースで）捌く必要がある（ボトルネックになりやすい） 22 Copyright © 2024, Oracle and/or its affiliates リクエスト ClusterIP ルーティング iptables ルーティングする のはこっち トラフィックを kube-proxyに転送する

Serviceの種類(type) - NodePort NodePort • 各NodeにアサインされたIPとポート(NodePort)を利用して対象のPodを公開する • “各NodeのIP:NodePort”でアクセスできる（いずれかのNodeがリクエストを受信する） • リクエストを受け付けたNodeが転送する先となるClusterIPも自動的に作成される（ルーティングされたNodeに対 象Podがなくても、内部でルーティングできる） • NodePortは”--service-node-port-range“フラグ（Control Planeのフラグ）によって指定された範囲のポート(デフォ ルト: 30000-32767)を割り当てる • フラグを変更することで、アサインするNodeのIPやNodePortを特定の範囲に絞ることも可能 23 Copyright © 2024, Oracle and/or its affiliates リクエスト NodePort IP: 30080 ルーティング iptables NodePort

Serviceの種類(type) - LoadBalancer LoadBalancer • クラスタ外に存在するロードバランサー（アプライアンス/クラウドサービス)を利用して対象のPodを公開する • ”LoadBalancerのIP:LoadBalancerのリスナーPort”でアクセスできる • LoadBalancerのバックエンドに各NodeのNodePortが紐づく • LoadBalancerの実装によってはNodePortを経由しないことも可能 • その後はClusterIPでルーティング • クラウドプロバイダーやロードバランサーのプロバイダーが提供するControllerが必須 24 Copyright © 2024, Oracle and/or its affiliates リクエスト NodePort IP: 30080 ルーティング iptables LoadBalancer ocha.com:80

Serviceの種類 – ExternalName ExternalName • ServiceとDNSを（いわゆるCNAMEとして）マッピングし、DNS名で公開する • セレクタは存在しない • 以下のユースケースに有効（クライアント（Pod）から見たアクセス先の抽象化） • コードに本番用のURLがハードコーディングされているが、開発用には別のURLを利用したい • 開発用のデータベースはコンテナを利用したいが、本番環境はマネージドのサービスを利用したい 25 Copyright © 2024, Oracle and/or its affiliates CoreDNS CNAMEによる名前解決 リクエスト ルーティング iptables /etc/resolv.conf ExternalName CNAME “https://postgre-svc” にアクセスすると ”https://aaa-primary.postgresql.ap- tokyo-1.oci.oraclecloud.com” にリダイレクトする

Serviceの種類 – Headless Service Headless Service • ClusterIPのような対象のPodを公開する単一のエンドポイントを作成せずに、PodのIPアドレスを直接公開する • iptablesを利用 • PodのIPの永続性が高いStatefulSetにおいてよく利用される • いわゆるDNSラウンドロビンを利用したエンドポイントを提供 • クライアント側でのキャッシュ機構に注意が必要 26 Copyright © 2024, Oracle and/or its affiliates CoreDNS PodのIPに名前解決 リクエスト ルーティング /etc/resolv.conf Headless Service “None”に設定 iptables

【ちょっと寄り道】Services without selectors セレクタなしのService • 通常はPodに対するアクセスを抽象化するものだが、例えば以下の利用方法もある • 本番環境ではクラウドベンダーのマネーシドなデータベースサービスを利用するが、テスト環境ではクラスタ 内に展開したデータベースを利用したい • Serviceを異なるNamespaceのServiceや他のクラスタのServiceに向けたい • この場合はEndpointSliceが自動作成されないため、手動で追加できる 27 Copyright © 2024, Oracle and/or its affiliates selectorなし 手動でEndpointを設定

Demo Serviceを作成した際のiptablesの書き換えを確認してみる…!! 28 Copyright © 2024, Oracle and/or its affiliates リクエスト ClusterIP ルーティング iptables iptablesを 書き換える ルーティングす るのはこっち この様子を確認します…!!

Service まとめ Serviceの種類 ルーティング用途 ルーティング方式 補足 ClusterIP k8s内部 iptables or IPVS kube-proxyの動作モードに依存 NodePort k8s外 -> k8s内 IP ClusterIPも自動作成 LoadBalancer k8s外 -> k8s内 (外部DNS) or IP NodePort + ClusterIPも自動作成 ExternalName k8s外 -> k8s内 外部DNS CNAMEの利用 (Headless Service) k8s内部 内部DNS 厳密にはClusterIPの一部 DNSラウンドロビンでルーティング 29 Copyright © 2024, Oracle and/or its affiliates 今日の ポイントスライド

Serviceでできること/できないこと Serviceで実現できること • Kubernetes内外からのルーティング（LoadBalancerの利用を含む） • TCP/UDPなどのL4を利用したルーティング Serviceで実現できないこと • HTTP(S)などのL7を利用したルーティング(Host / Path Routing…) 30 Copyright © 2024, Oracle and/or its affiliates ならできる…!! 今日の ポイントスライド

Kubernetes Ingress Oracle Cloud Hangout Café – Season 9 #3 31 Copyright © 2024, Oracle and/or its affiliates

Kubernetesのトラフィックルーティング要素 32 Copyright © 2024, Oracle and/or its affiliates パスベース Load Balancer https://ocha.com /gateway パスベース /ingress ホスト https://cafe.com

Ingress Ingress • 外部から対象Podに対してHTTP(S)ベースのルーティングを可能にするリソース • 以下を提供（Ingress & LoadBalancerのベンダーが提供するLoadBalancerの機能と統合） • 負荷分散 • SSL/TLS終端 • Hostベースのルーティング • パスベースのルーティング • 実際にPodを公開するのはIngressではなく、Serviceの役割 33 Copyright © 2024, Oracle and/or its affiliates 今日の ポイントスライド 参考: https://kubernetes.io/docs/concepts/services-networking/ingress/

Ingress Controller Ingress Controller • Ingressを実現するためにクラスタ上で動作するController • 複数のControllerの実装が存在 • Nginx / Kong / HAProxy / Traefik / OCI Native Ingress / ALB Ingress (AWS) / Azure Application Gateway Ingress / GCE Ingress… • 各Controllerによって実装は異なる => Ingressリソースの定義方法やルーティングの挙動も異なる • IngressリソースのIngress Classの設定により切り替え（後述） 34 Copyright © 2024, Oracle and/or its affiliates Ingress Controller

Ingressでのプロバイダー拡張のリソース定義 プロバイダー拡張のリソース定義 • Ingressでは“.metadata.annotations”に詳細なリソース定義を行うことが多い • OCI Native Ingress ControllerとNginx Ingress Controllerを例に挙げると・・・ 35 Copyright © 2024, Oracle and/or its affiliates 今日の ポイントスライド OCI Native Ingress Controller Nginx Ingress Controller IngressClassを変更する際に可搬性に難あり・・・?? 【課題】

Ingressリソース例(パスベース) – OCI Native Ingress Controllerを例に 36 Copyright © 2024, Oracle and/or its affiliates Ingress Class の指定 “http://LBのIP/test” で ”nginx1”にアクセスできる ルーティングルールに 合致しなかった場合

Ingressリソース例(Host) – OCI Native Ingress Controllerを例に 37 Copyright © 2024, Oracle and/or its affiliates Hostの ルーティングルール http://foo.bar.com/ で ”ServiceA”にアクセスできる

【ちょっと寄り道】OCI Native IngressでのIngressClass 38 Copyright © 2024, Oracle and/or its affiliates Ingress Classの デフォルト設定 OCI Native Ingress Controllerの指定 パラメーターの指定 パラメータの 具体的な定義 OCI Native Ingress独 自のリソース

【ちょっと寄り道】ExternalDNS ExternalDNS • https://github.com/kubernetes-sigs/external-dns • Kubernetes内のリソース(主にPod)をパブリックDNSサーバで検出できるようにする仕組み • Kubernetesの内部DNS(CoreDNS)サーバから着想を得ている • Kubernetes API経由で必要なリソース(Ingress/Service)を取得して、サポートするパブリックDNSサーバにDNSレコー ドを自動作成する • サポートするパブリックDNSサーバは以下 • OCI DNS / AWS Route 53 / Azure DNS / Google Cloud DNS / Cloudflare DNS / CoreDNS… • サポートするパブリックDNSサーバが多岐に渡るため、最近では本体コードから切り離して管理するように試みて いる最中(#4347) 39 Copyright © 2024, Oracle and/or its affiliates

Demo OCI Kubernetes Engine(OKE)でOCI Native Ingress Controllerを利用したルーティングをやってみる…!! ついでにExternalDNSをOCI DNSを利用してやってみる…!! 40 Copyright © 2024, Oracle and/or its affiliates /ocha http://ingress.ochacafe.jp Host + パスベース /cafe OCI Native Ingress Controller ExternalDNS Controller Aレコードの登録 OCI DNS LBのルーティング設定 /ocha /cafe デモコード

Service(type: LoadBalancer) / Ingress の課題 41 Copyright © 2024, Oracle and/or its affiliates 今日の ポイントスライド ServiceやIngressを設定するのは開発者…?? それともクラスタ管理者(インフラエンジニア)…?? 開発者だとしたら、Load Balancerをボコボコ作って しまっていいのか…??課金管理とかどうなる…?? クラスタ管理者(インフラエンジニア)だとしたら、 わざわざ開発者が連絡しないといけないの…??

Kubernetes Gateway API Oracle Cloud Hangout Café – Season 9 #3 42 Copyright © 2024, Oracle and/or its affiliates

Gateway API Gateway API • 新たに実装されたKubernetesのトラフィックルーティングAPI（2023年10月にGA） • https://github.com/kubernetes-sigs/gateway-api（最新: v1.2.0） • Gateway API Controllerによって動作し、複数のプロバイダーが実装を提供している • Service/Ingressの課題に基づき、Role志向で以下のエンジニアを想定してリソースを構成 • インフラストラクチャプロバイダー: クラウドおよびテナントを管理するエンジニア • クラスタオペレーター: Kubernetesクラスタを管理するエンジニア • アプリケーション開発者: コンテナアプリケーションを管理するエンジニア • ポータビリティ • 高度なルーティング機能 • 高い拡張性 • 主に3つのリソースからなる • GatewayClass/ Gateway / xRoute(HTTP / TCP / gRPC…) • 今後の機能拡張はGEPとして管理 • https://gateway-api.sigs.k8s.io/geps/overview/ 43 Copyright © 2024, Oracle and/or its affiliates 今日の ポイントスライド

Gateway APIのリソース GatewayClass • クラスタ全体にわたってGateway APIに関する共通の 設定を持ち、Gateway API Controllerによって管理され るGatewayの集合を定義 Gateway • ロードバランサーなどのトラフィックを処理するイ ンフラストラクチャのサービスを定義 xRoute • Gatewayからバックエンドのエンドポイントへのト ラフィックルールを定義 • エンドポイントは多くの場合、Serviceになる 44 Copyright © 2024, Oracle and/or its affiliates 参考: https://gateway-api.sigs.k8s.io/ エンジニアのRoleによって明確 に扱うべきリソースが分かれる 今日の ポイントスライド 1:N 1:N 1:N 1:N 1:N

Gateway APIのリソース – GatewayClass(nginx-gateway-fabricの場合) 45 Copyright © 2024, Oracle and/or its affiliates Controllerを指定 （IngressClassとほぼ同じ） リソースはCluster Scopeで有効

Gateway APIのリソース - Gateway (nginx-gateway-fabricの場合) 46 Copyright © 2024, Oracle and/or its affiliates GatewayClassの指定 リソースは Namespace Scopeではあるが、 Gatewayをcross-namespaceで利 用することも可能 （Ingressでは不可） リスナーの設定。 “allowedRoute”フィールド でトラフィック制御も可能

Gateway APIのリソース - HTTPRouteを例に 47 Copyright © 2024, Oracle and/or its affiliates リソースは Namespace Scope Hostの指定 Gatewayの指定 ルーティングルールの指定。 パスベースのルーティングだけではな く、重みづけによるルーティングや HTTPヘッダーのModifyも可能

【ちょっと寄り道】HTTPRouteのルール競合 HTTPRouteのルーティングルールの優先度 1. Hostルール • 最も長いおよび具体的なホスト名を優先 2. パスルール • 最も長いおよび具体的なパスを優先 3. ヘッダー • 一致するHTTPヘッダーの数が多いものを優先 48 Copyright © 2024, Oracle and/or its affiliates Ingressもほぼ同じ優先ルールで選択される。 https://kubernetes.io/docs/concepts/services-networking/ingress/#multiple-matches 【コラム】

Gateway APIを提供するプロバイダー Gateway APIのプロバイダー（一部） • AWS Gateway API （GA）（Amazon VPC Latticeを利用） • https://github.com/aws/aws-application-networking-k8s • Azure Application Gateway（GA） • https://learn.microsoft.com/ja-jp/azure/application-gateway/for-containers/overview • GKE Gateway（GA） • https://cloud.google.com/kubernetes-engine/docs/concepts/gateway-api?hl=ja • Cilium（β） • https://isovalent.com/blog/post/cilium-release-114/ • Istio（GA） • https://gateway-api.sigs.k8s.io/mesh/ • NGINX Gateway Fabric（GA） • https://github.com/nginxinc/nginx-gateway-fabric 参考: https://gateway-api.sigs.k8s.io/implementations 49 Copyright © 2024, Oracle and/or its affiliates

Gateway APIとIngressでのプロバイダー拡張リソース定義の違い Ingress • ”.medatata.annotation”に定義することが多い Gateway API • .spec配下に定義することが多い(=標準仕様として実 装されている=Gateway APIは可搬性が高い) 50 Copyright © 2024, Oracle and/or its affiliates 今日の ポイントスライド

Gateway API vs Ingress 51 Copyright © 2024, Oracle and/or its affiliates Gateway API Ingress Roleの明確化 Roleにより管理するリソースが明確 リソース管理者が曖昧（運用次第） ルーティングポリシー パスベース, Host, ヘッダーベース, 重みづ け, A/Bテスト, ミラーリング… パスベース, Host サポートするプロトコル L4 & L7プロトコル （今後の実装予定も含む） HTTP(S) プロバイダーによる拡張 （移植性） 高 (仕様として標準化) 低 (アノテーションを利用して拡張) リソースの管理性 多 (GatewayClass, Gateway, HTTPRoute…) 少 (IngressClass, Ingress) Gateway APIはIngressの後継として開発されているが、IngressがDeprecatedにはなっていない。 FAQにも“we expect most Ingress controllers to support it indefinitely.”と記載されているが、Ingressのドキュメントには“Ingress is frozen. New features are being added to the Gateway API.”と書かれている。 果たして・・・ 【コラム】 今日の ポイントスライド

IngressからGateway APIへの移行 Migrating from Ingress • IngressとGateway APIに共通リソースは存在しない・・・(“annotations” vs “spec”) • ある程度泥臭い移行作業が必要・・・ • 移行に関して示したドキュメントも存在するが・・・ • https://gateway-api.sigs.k8s.io/guides/migrating-from-ingress/#migrating-from-ingress • 結局は頑張ってGateway APIの定義に書き換えてくださいという手順 • 一応自動移行ツールもある模様 • https://github.com/kubernetes-sigs/ingress2gateway • Gateway API SIGのサブプロジェクト • サポートされているプロバイダーが限られている（2024年12月現在） • APISIX、Ingress-Nginx、Istio、Google Cloud、Kong… 52 Copyright © 2024, Oracle and/or its affiliates

Gateway API for Service Mesh Project GAMMA（The GAMMA Initiative） • 2022年に発足したGateway APIの仕組みをService Meshにも導入しようという試み • Gateway APIのRole指向を維持しつつ、Gateway APIを利用してService Meshを構築する • Service Meshのプロダクトに関係なく、一貫してGateway APIを利用できる • GEPを通して、機能拡張が行われている • IstioのCRD(e.g. Virtual Service, DestinationRule)などをはじめとするService Meshクラスタ内部(east/west)の既存ルーティ ングの仕組みをHTTPRouteを利用して実現しようとしている • Gateway（north/south、GatewayClass含む）はService Mesh環境で基本的に1つであるため、あまり意識しない 参考 OCHaCafe Season6 #1 Service Meshがっつり入門 https://speakerdeck.com/oracle4engineer/get-started-service-mesh 53 Copyright © 2024, Oracle and/or its affiliates

Demo OCI Kubernetes Engine(OKE)でNGINX Gateway Fabricを利用したルーティングをやってみる…!! またまたついでにcert-managerを利用してHTTP01チャレンジでの証明書発行もやってみる…!! 54 Copyright © 2024, Oracle and/or its affiliates /ocha https://gateway.ochacafe.jp /cafe NGINX Gateway cert-manager HTTPRoute HTTPRoute 証明書発行 Gateway API ExernalDNSを利用してDNSレコード登録は実施済み。 HTTP01チャレンジの詳細は、こちら!! OCHaCafe Season7 #4「セキュアなWeb APIの作り方」 資料 https://speakerdeck.com/oracle4engineer/secure-web-api 【補足】 デモコード

まとめ Oracle Cloud Hangout Café – Season 9 #3 55 Copyright © 2024, Oracle and/or its affiliates

まとめ Kubernetes内部のルーティングで利用される“Service” • ClusterIPが最もよく利用されるが、一部のユースケースではExternalNameやHeadless Serviceも利用可能 • ClusterIPは原則iptablesを利用してルーティングされる • 外部からのルーティングにはNodePort、LoadBalancer(L4ルーティング)がある Kubernetes外部からHTTP/HTTPSレベルルーティングで利用される“Ingress” • Serviceでは実現できないHTTP/HTTPSのルーティングを実現 • パスベースやHostによるルーティングが可能 • プロバイダーによって実装が異なる Kubernetes外部からL4/L7ルーティングで利用される新たな実装“Gateway API” • ServiceやIngressでは曖昧だったリソース管理を明確に分離（プラットフォームエンジニアリングにも一役） • 実装を標準化し、プロバイダーに依存しない実装や拡張性を実現 • Service Meshとの統合も視野に開発中 56 Copyright © 2024, Oracle and/or its affiliates

参考資料 Kubernets公式ドキュメント • Service Networking: https://kubernetes.io/ja/docs/concepts/services-networking/ • Ingress: https://kubernetes.io/docs/concepts/services-networking/ingress/ Gateway API公式ドキュメント • https://gateway-api.sigs.k8s.io/ Gateway API GitHub • https://github.com/kubernetes-sigs/gateway-api 参考記事 • Gateway API の現在地 〜これまでとこれから〜@amsy810(青山さん) https://amsy810.hateblo.jp/entry/2023/12/01/090000 • KubernetesとCoreDNSについて理解する@bell17さん https://speakerdeck.com/bells17/kubernetestocorednsnituiteli-jie-suru デモ • https://github.com/oracle-japan/ochacafe-traffic-routing 57 Copyright © 2024, Oracle and/or its affiliates

No content