KubeCon NA 2024 Recap

Transcript

1. KubeCon NA 2024 Recap 「Extending the Gateway API: The Power and Challenges of Policies」 CIU Development Div 木村 洸太
2. 自己紹介
 木村 洸太 - Kota Kimura • 株式会社サイバーエージェント グループIT推進本部 CIU Development Div所属 • KaaS プロダクト AKE の開発・運用を担当 • 趣味はサウナ巡り @ k10krn
3. セッション概要 
 タイトル : 「Extending the Gateway API: The Power and Challenges of Policies」 Gateway API を拡張する方法の1つのポリシーアタッチメント メカニズムに関して NGINX の独自ポリシーを実装した際に学んだ教訓を共有しながら説明
4. おさらい

5. (おさらい) Ingress API 
 Ingress API • アプリケーションの L7ルーティングを設定するリソース 課題 • インフラ管理者、クラスタ管理者、アプリ開発者の それぞれで設定したい項目があり、責任分界点が不明瞭 • トラフィックの細かなルーティング管理が Ingress Controller 独自 の拡張機能で提供される形で、環境依存が発生する
6. (おさらい) NGINX Ingress の拡張機能 
 • Ingress の annotations に付与することで設定 Reference https://kccncna2024.sched.com/event /1i7ln (多すぎる....)
7. (おさらい) Gateway API 
 Gateway API • ロール指向の設計 ◦ ペルソナごとに管理すべきリソースが 分かれている構成 • 細かなルーティング制御の実現 ◦ 標準の HTTPRoute Rules でヘッダーによる フィルタリングやタイムアウトなど設定可能 • L4/L7 ルーティングの提供 ◦ HTTPRoute ◦ GRPCRoute ◦ TLSRoute (Experimental) ◦ TCPRoute (Experimental) ◦ UDPRoute (Experimental) Reference: https://gateway-api.sigs.k8s.io/
8. (おさらい) Gateway API 
 Ingress の課題 • インフラ管理者、クラスタ管理者、アプリ開発者の それぞれで設定したい項目があり責任分界点が不明瞭 ◦ → Gateway API リソースモデルにより解決！ • トラフィックの細かなルーティング管理が Ingress Controller 独自の拡張機能で提供される形で、環境依存が発生する ◦ → HTTPRoute の設定などで一部は解決！ ◦ ただし標準で全ては解決しておらず、どのように拡張を行うのか (本セッションの内容)
9. セッション 

10. Policy Attachment 
 • Metaresource タイプの CRD ◦ Gateway API では、標準的な方法でオブジェクトの振る舞いを拡張する Kubernetes オブジェクトを Metaresource と定義 ◦ 該当オブジェクトの spec 仕様内で記述できない設定を追加できる • ポリシーは大きく分けて2種類 ◦ Direct Policies ▪ https://gateway-api.sigs.k8s.io/geps/gep-2648/ ◦ Inherited Policies ▪ https://gateway-api.sigs.k8s.io/geps/gep-2649/ Policy Attachment は現在 GEP で議論中なので、本発表の内容の仕様から 将来的に変更されている可能性があることに注意ください https://github.com/kubernetes-sigs/gateway-api/discussions/2927
11. Direct Policies 
 Policy を付与したリソースの振る舞いのみを変えるポリシー BackendTLSPolicy • Service リソースを介して Gateway からバックエンド Pod への 接続の TLS 設定を指定するポリシーリソース • Gateway API 公式で定義されている https://gateway-api.sigs.k8s.io/api-types/backendtlspolicy/
12. Inherited Policies 
 Policy を付与したリソースだけではなく複数のターゲットリソース全体の 特定の設定の振る舞いを変えるポリシー • Defaults 値は bottom-up 式で、下から上に優先順位がつけられる ◦ Backend にアタッチされた Default が最も優先 • Overrides 値は top-down 式で、上から下に優先順位がつけられる ◦ GatewayClass にアタッチされた Override が最も優先 e.g. GatewayClass, Gateway, HTTPRoute に ポリシーを付与した場合 GatewayClass Override > Gateway Override > HTTPRoute Override > HTTPRoute Default > Gateway Default > GatewayClass Default
13. Inherited Policies : NGINX Example 
 • 背景 ◦ client_max_body_size をアプリケーションごとに設定したい ① As a Cluster Operator ほとんどのアプリで機能するように クライアントボディの設定に適切な デフォルト値を設定したい ② As a Application Developer アプリの動作や要求に基づいて クライアントボディの設定を 構成できるようにしたい ③ As a Application Developer クラスタオペレーターによって設定された デフォルトのクライアントボディの 設定を微調整したい ユーザーストーリー
14. Inherited Policies CRD 
 • targetRef は必ず spec に含める • defaults, overrides の階層がない policy の場合 default 値とみなす • status は PolicyAncestorStatus の構造を持つべき
15. Inherited Policies in Practice 
 ① ② ③
16. User Experience 
 It’s complex とコメントされていた
17. Example 

18. まとめ・所感 
 • Gateway API の拡張方法として、Policy Attachment という仕組みが導入されている • Policy には Direct Policy と Inherited Policiy の2種類が存在 ◦ (所感) Inherited Policy の仕組みは面白いが、やや複雑 • Policy Attachment は現在進行形で Resource 構造や Status の課題など ディスカッションされており、破壊的な変更が入る可能性あり • Policy Attachment の仕組みは今後も発展していきそう ◦ Gateway v1.2 時点で様々な oss が policy を実装している ◦ Gateway v1.3+ 以降で Timeout や Circuit breaking, Auth, CORS など様々な設定を 行うための Policy がリリースできるように Gateway API 公式で議論中