GKE に飛んでくるトラフィックを自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online

1. #gc_inside 篠原一徳 Application Modernization Specialist GKE に飛んでくるトラフィックを自由自在に操る力

2. 篠原一徳 Application Modernization Specialist 専門分野: Anthos 、k8s 、Serverless 、CI/CD Twitter: @kazshinohara 猫とカメラと旅が好き

3. ● タイトルの「飛んでくるトラフィック」の通り、 GKE へのインバウンドトラフィックの話に絞ります ● 原則 GKE (k8s) のマニフェストで設定可能な機能の話をします ● What is Kubernetes ? What is GKE ? What is GCP ? などはご存知の前提で話をします

4. 1. GKE へのインバウンドトラフィック制御で考慮すべきポイント 2. インターネットからGKE へのトラフィック(External) 3. VPC 内部から GKE へのトラフィック(Internal) 4. まとめアジェンダ

5. へのインバウンドトラフィック制御で　考慮すべきポイント

6. Kubernetes の可用性やスケーラビリティの恩恵に与るためには、インバウンドトラフィックを適切に制御しPod まで転送することが重要のワークロードは分散システムが主流 Pod Pod Pod Pod Pod Pod Nodes Pod Pod Pod Pod Pod Pod Clients

7. トラフィック制御への要件はアプリケーションにより様々だが、大きく以下 3 つのポイントを考慮することが重要 1. トラフィックの向き 2. プロトコル 3. トラフィックに加える動きインバウンドトラフィック制御で考慮すべきポイント

8. ● インターネットからGKE へのトラフィック(External) ○ 外部公開目的 ○ ユーザーや 3rd party からのアクセス ○ 求められるセキュリティレベルが高い (SSL/TLS 、FW 、WAF etc.) ● VPC 内部から GKE へのトラフィック(Internal) ○ 内部システム間の連携など ○ VPC 内の GCE からのアクセス ○ Interconnect/Cloud VPN を経由したオンプレや他社クラウド上のホストからのアクセスポイントトラフィックの向き

9. ● TCP/UDP ○ HTTP を使わないアプリケーションや独自プロトコル、 RTSP/RTP などを使った動画、音声などのリアルタイム通信など ● HTTP/HTTPS ○ HTTP/1.0 & HTTP/1.1 ■ 一般的な Web 、Rest 、Websocket など ○ HTTP/2 ■ ストリームの多重化、 HTTP/1.0 、HTTP1.1 と比較し高速に通信、 gRPC などポイントプロトコル

10. ● 負荷分散 ○ 分散配置されたPod に対するトラフィックに対してL4 や L7 レベルで負荷分散を行う ● 高度なルーティング ○ トラフィックスプリットやリダイレクト、URI リライトなどを行うなどポイントトラフィックに加える動き

11. インターネットからへのトラフィック

12. トラフィックの負荷分散 External Traffic

13. トラフィックの負荷分散 GKE (k8s) の Service リソースを使う Type は LoadBalancer を指定 ● 外部 LB として、GCP の External TCP/UDP Network Load Balancing が利用される ● Proxy はせず、送信元 IP アドレスが維持される ● 送信元 IP とポートと、宛先 IP とポート、プロトコルのハッシュに基づいてバランシングを行う External Traffic

14. Pod kube-proxy(iptables) Pod Pod Pod Pod Pod NIC NIC NIC ① : External TCP/UDP Network Load Balancing がトラフィックを受信 ② : 宛先 IP / Port は変えずにNode のいずれかにバランシングしつつ転送 ③ : kube-proxy(iptables) に転送 ④ : kube-proxy(iptables) から青 Pod のいずれかにバランシングしつつ転送 ① ② ③ ④ Nodes :8080 :8080 :8080 トラフィックの負荷分散イメージ 34.69.XX.XX:80External TCP/UDP Network Load Balancing External Traffic LB からの Health Check は各ノードのkube-proxy の /healthz に対して TCP 10256 で行っている iptables のバランシングアルゴリズムはRandom

16. トラフィックの負荷分散 GKE (k8s) の Ingress と Service リソースを使う Service の Type は NodePort を指定 ● 外部 LB として、GCP の External HTTP(S) Load Balancing が利用される ● SSL / TLS の終端をしつつ、複数のService 間で Path based routing が可能 ● Client と External HTTP(S) Load Balancing 間は HTTP/1.0 、HTTP/1.1 、HTTP/2 が利用可能 ● External HTTP(S) Load Balancing とバックエンドサービス(Pod) 間はデフォルトではHTTP/1.1 で通信される(別途 HTTP/2 に変更可能) External Traffic

17. External Traffic

18. トラフィックの負荷分散イメージ Pod kube-proxy(iptables) Pod Pod Pod Pod Pod NIC NIC NIC Health check は各 NodePort 宛に行われる :50000 :50000 NodePort: *:30080 ① : External HTTP(S) Load Balancing がトラフィックを受信 ② : Path 毎に指定されたService の NodePort 　　に転送 ③ : NodePort から kube-proxy(iptables) へ転送 ④ : kube-proxy(iptables) から各 Pod にバランシングして転送 ② ③ ④ NodePort: *:30180 :8080:8080:8080 kube-proxy(iptables) Nodes ① :50000 /* : “my-products” service /discounted “my-discounted-products” service External HTTP(S) Load Balancing External Traffic 34.69.XX.XX:443 iptables のバランシングアルゴリズムはRandom

19. External HTTP(S) Load Balacing に SSL 証明書を渡す方法は以下3 つある ● Managed SSL certificate (Beta) ○ Google が払い出す SSL 証明書を利用、CA は Google Trust Services ○ DV のみ、1 SSL 証明書で 100 non-wildcard ドメインまでサポート ● Secret ○ GKE (k8s) の Secret を使った SSL 証明書の持ち込み ○ DV, OV, EV 利用可能、wildcard ドメインサポート ● Pre-shared certificate ○ GCP が持つ SSL 証明書管理の仕組みを使った持ち込み ○ DV, OV, EV 利用可能、wildcard ドメインサポート証明書の設定 External Traffic

20. 証明書、諸注意 ● SSL 証明書のローテーション ○ Managed certificate は自動更新、その他はユーザーが手動で更新する必要がある ● Ingress 毎の設定可能な SSL 証明書数 ○ 最大 10 個の SSL 証明書を設定可能 ● SSL 証明書が複数ある場合の選択ルール ○ TLS ハンドシェイクの際の Domain name に基づいて、SNI を使ってどの SSL 証明書をクライアントに返すか決める ○ どの SSL 証明書の CN にもマッチしない場合は、リストの最初の SSL 証明書を使う External Traffic

22. 負荷分散 Custom Resource の BackendConfig を使って以下の機能を設定可能。 ● Cloud Armor security policy ● Cloud CDN ● Identity-Aware-Proxy (IAP) ● Timeout ● HTTP access logging ● Connection draining timeout ● Session Affinity ● User-defined request headers NEW External Traffic

24. 設定イメージ Service Internet Deployment Ingress External HTTP(S) LB GKE Cloud Armor Security policy ManagedCertificate BackendConfig $ kubectl で設定固定外部IP $ gcloud で設定 External Traffic

25. コンテナネイティブ負荷分散 External Traffic

26. デフォルトの Ingress では External HTTP(S) Load Balancing と kube-proxy (iptables) による 2 重のロードバランシングをしているため、オーバーヘッドが大きいネットワークエンドポイントグループ (NEG) を使用することで、 External HTTP(S) Load Balancing から直接 Pod にロードバランシングを行うことが出来る設定方法はService リソースに cloud.google.com/neg: '{"ingress": true}' を annotation として入れるだけ、VPC Native クラスタでのみ利用可能コンテナネイティブ負荷分散 External Traffic

27. とを使った負荷分散イメージ Pod Pod Pod Pod Pod Pod NIC NIC NIC :50000 :50000 ① : External HTTP(S) Load Balancing がトラフィックを受信 ② : Path 毎に指定されたService の Pod に　　直接転送 ② :8080:8080:8080 Nodes ① :50000 35.244.**.** /* : “my-products” service /discounted “my-discounted-products” service External Traffic Health check は各 Endpoint ( Pod ) の target port に対して行われる External HTTP(S) Load Balancing

28. ● 基本は使うべし ○ 新しい機能はNEG をベースに開発されていることが多い ○ 少しでもネットワークレイテンシーのオーバーヘッドを減らしたい、パフォーマンスセントリックなワークロードは特に ● 設定自体は簡単だが、以下の通りQuota があるので注意 ○ プロジェクト毎の最大NEG 数 : 100 ○ NEG 毎のエンドポイント数: 10,000 は使うべきか？ External Traffic

29. クラスタ間でトラフィックの負荷分散 External Traffic

30. Ingress for Anthos (Beta) を使う Ingress for Anthos は External HTTP(S) Load Balancing をベースにした新しいサービス ● クラスタ間、マルチリージョン間でのHTTP/HTTPS ロードバランシングが可能 ● VPC ネイティブクラスタで利用可能(NEG 依存) ● バックエンドの状態(Health) をみつつ、最寄り(Latency) のクラスタに転送される ● kubemci との違い ○ CLI ツールではなく、CRD ○ 宣言型 ○ GCP のサポートクラスタ間でトラフィックの負荷分散 External Traffic

32. GCP Project asia-northeast1 asia-northeast2 Google Backbone Cluster A Kubernetes Engine Cluster B Kubernetes Engine Internet 東京大阪クラスタ間でトラフィックの負荷分散イメージ 1.1.1.1 External Traffic 1.1.1.1

33. 以下のようなユースケースがある場合、おすすめ ● リージョン間で冗長構成を組みたい ● GKE クラスタのカナリーアップグレードをしたい ● グローバルにサービスを提供しつつ ○ クライアント〜サーバー間を同一地域内に閉じレイテンシーを低くしたい ○ シングル IP で運用したい 2020.04.27 現在、BackendConfig でサポートしているのはTimeout のみ今後、通常のIngress と同等の機能を提供出来るようになる予定を使うべきか？ External Traffic

34. デモ External Traffic

35. トラフィックに対する高度なルーティング External Traffic

36. Anthos Service Mesh (ASM) を使う ASM は Istio 互換のマネージドサービスメッシュ以下のようなトラフィック制御が出来る ● トラフィックスプリット ● URI リライト ● Path Based Routing ● Retry logic ● Circuit Breaker ● Traffic Mirroring..etc. トラフィックに対する高度なルーティング External Traffic

37. コントロールプレーンはGoogle 管理 Istio の各コントローラは Google の Proprietary に置き換え ● Istio Pilot >> Traffic Director ● Istio Citadel >> Mesh CA ● Istio Mixer >> Managed backends 概要 External Traffic Traffic Director Config to Envoys (xDSv2 APIs) TLS certs to Envoys Telemetry Mesh CA HTTP, gRPC, TCP mTLS Managed backends GA BetaAlpha Anthos GKE Single Cluster Data Plane Control Plane managed by Google App A Envoy App B Envoy

38. デフォルトのネットワーク構成 External Traffic istio-ingressgateway Envoy App A container Envoy App B container Replica: 1 Limits: CPU:2, memory: 1Gi Requests: CPU: 100m, 128Mi Sidecar proxy (Envoy) Limits: CPU: 100m, memory: 50Mi Requests: CPU: 10m, 10Mi istio-ingressgateway は Deployment として配置され、Service の Type は LoadBalancer が指定され、External TCP/UDP Network Load Balancing が使われる istio-ingressgateway / Envoy は Pilot から宛先 Service のエンドポイントを入手し、各 Pod に対して直接パケットを転送する External TCP/UDP Network Load Balancing Kube-proxy (iptables)

39. とのリソース相関図 Gateway VirtualService DestinationRule k8s Service External Traffic istio-ingressgateway Envoy App container Envoy App container v2 Pod 参照設定設定 Pilot 経由で Endpoint を取得転送先ルートとして指定指定 Pod Endpoints v1 Pod Subset 参照 Selector Subset 定義

40. External Traffic Path Based Routing

41. External Traffic トラフィックスプリット

42. istio-ingressgateway は豊富なトラフィック制御機能が売り External HTTP(S) Load Balancing (Ingress) とあえて組み合わせて使う場合は以下のケースが想定される ● シングル IP が必要な場合 ● Cloud Armor や Cloud CDN など BackendConfig 系の機能が必要な場合 ● Managed Certificate が必要な場合 ● Ingress for Anthos と組み合わせて利用したい場合との組み合わせ

43. External Traffic External HTTP(S) Load Balancing istio-ingressgateway Envoy App A Container NEG Pod Pod 通常の Ingress ではホップ数が多くなるため、NEG 利用がおすすめポイントは External HTTP(S) Load Balancing の Health Check への対応をどうするかの設定 NEG を有効にした Service を新たに作成 Ingress を作成 LB からの Health Check が通るように VirtualService を設定 Health Checkに対して 200 を返すように Health Check GET “/”

45. Envoy App container gRPC App Pod トラフィックの負荷分散 External Traffic ASM の Envoy を使って gRPC の負荷分散を行うことが可能 Health check は Pod の readinessProbe で grpc_health_probe を使い、fail した場合は、 Service から Pod の Endpoint が削除され、結果、Envoy による転送もされない istio-ingressgateway Envoy App container Envoy App container gRPC App PodPod gRPC App Pod SSL/TLS を終端 mTLS しつつバランシング SSL/TLSな gRPC リクエスト Clients readiness Probe

46. デモロードバランシング External Traffic

47. 以下のようなユースケースがある場合、おすすめ ● Ingress がサポートしていない高度なルーティングが必要 ● アプリがマイクロサービスアーキテクチャ ● gRPC の負荷分散、特にクラスタ内で行いたい(Envoy 個別に管理したくない） ● Istio 使いたいけどちょっと不安、Google のサポートがほしい Istio 運用のツラミはコミュニティでも情報が出てきてますので、その辺りも参考にしながら、十分に設計、検証の上、導入しましょう！を使うべきか？ External Traffic

48. 内部からへのトラフィック

49. トラフィックの負荷分散 Internal Traffic

50. トラフィックの負荷分散 Internal Traffic Egress と同様、Service リソースを使う Internal であることを示す、アノテーションを付ける。(Beta) ● 外部 LB として、GCP の Internal TCP/UDP Load Balancing が利用される ● Proxy はせず、送信元 IP アドレスが維持される ● バランシングアルゴリズムも External と同様

51. Pod kube-proxy(iptables) Pod Pod Pod Pod Pod NIC NIC NIC ① : Internal TCP/UDP Load Balancing が VPC内のホストからトラフィックを受信 ② : Node のいずれかに宛先IP/Port は　　変えずにバランシングしつつ転送 ③ : kube-proxy(iptables) に転送 ④ : kube-proxy(iptables) から青 Pod のいずれかにバランシングしつつ転送 ① ② ③ ④ Nodes :8080 :8080 :8080 トラフィックのイメージ 192.168.2.14:80Internal TCP/UDP Load Balancing Internal Traffic LB からの Health Check は各ノードのkube-proxy の /healthz に対して TCP 10256 で行っている iptables のバランシングアルゴリズムはRandom

52. トラフィックの負荷分散 Internal Traffic

53. External と同様 GKE (k8s) の Ingress と Service リソースを使う Ingress には Internal であることを示す、アノテーションを付ける。(Beta) ● 外部 LB として、GCP の Internal HTTP(S) Load Balancing が利用される ● Release channnel の Rapid かつ VPC Native クラスタのみサポート、NEG 必須 ● L7 LB の実体としてはEnvoy ベースのプロキシが使用される ● 別途プロキシ専用サブネットが必要(64 以上のホスト IP が必要) ● BackendConfig は Timeout 、HTTP access logging 、Session Affinity のみサポートトラフィックの負荷分散 Internal Traffic

54. Internal Traffic

55. Internal HTTP(S) Load Balacing に SSL 証明書を渡す方法は以下2 つある ● Secret ○ GKE (k8s) の Secret を使った SSL 証明書の持ち込み ○ DV, OV, EV 利用可能、wildcard ドメインサポート ● Pre-shared certificate ○ GCP が持つ SSL 証明書管理の仕組みを使った持ち込み ○ DV, OV, EV 利用可能、wildcard ドメインサポート証明書の設定 Internal Traffic

56. トラフィックの負荷分散イメージ Pod Pod Pod Pod Pod Pod NIC NIC NIC :50000 :50000 ① : Internal HTTP(S) Load Balancing がトラフィックを受信 ② : Path 毎に指定されたService の Pod に　　直接転送 ② :8080:8080:8080 :50000 10.254..**.** /* : “my-products” service /discounted “my-discounted-products” service Health check は各 Endpoint ( Pod ) の target port に対して行われる Internal HTTP(S) Load Balancing Internal Traffic

57. まとめ

58. 以下 3 点と各 LB の特徴を踏まえて快適なGKE トラフィック制御ライフを！ 1. トラフィックの向き 2. プロトコル 3. トラフィックに加える動きマルチクラスタIngress や高度なルーティングはAnthos の機能として提供今後更に機能が追加されていく予定今後の GKE / Anthos にご期待ください！まとめ

59. #gc_inside #gc_inside

60. 今すぐ参加登録 ↑ ビジネスをサポートするGoogle Cloud ソリューションを学ぶ。年月日火日木ライブ配信年月日火日火開催

61. Google Cloud トレーニング無料提供キャンペーンのご案内 Qwiklabs、Pluralsight（英語のみ）、対象のCoursera のコースを1 か月間無料でご提供お申込み期限は、5 月 20 日まで（Pluralsight のみ 4 月 30 日まで） goo.gle/TrainingOffer 詳細・お申込みはこちら ↑

GKE に飛んでくるトラフィックを 自由自在に操る力 | 第 10 回 Google Cloud INSIDE Games & Apps Online

Google Cloud Platform - Japan