Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,459 views

Published on

2020 年 4 月 27 日(月)
第 10 回 Google Cloud INSIDE Games & Apps Online
Google Cloud 篠原 一徳によるセッション スライドです。

Published in: Technology
  • Login to see the comments

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

  1. 1. #gc_inside 篠原 一徳 Application Modernization Specialist GKE に飛んでくるトラフィックを 自由自在に操る力
  2. 2. 篠原 一徳 Application Modernization Specialist 専門分野: Anthos 、k8s 、Serverless 、CI/CD Twitter: @kazshinohara 猫とカメラと旅が好き
  3. 3. ● タイトルの「飛んでくるトラフィック」の通り、 GKE へのインバウンドトラフィックの話に絞ります ● 原則 GKE (k8s) のマニフェストで設定可能な機能の話をします ● What is Kubernetes ? What is GKE ? What is GCP ? などは ご存知の前提で話をします
  4. 4. 1. GKE へのインバウンドトラフィック制御で考慮すべきポイント 2. インターネットからGKE へのトラフィック(External) 3. VPC 内部から GKE へのトラフィック(Internal) 4. まとめ アジェンダ
  5. 5. へのインバウンドトラフィック制御で  考慮すべきポイント
  6. 6. Kubernetes の可用性やスケーラビリティの恩恵に与るためには、 インバウンド トラフィックを適切に制御しPod まで転送することが重要 のワークロードは分散システムが主流 Pod Pod Pod Pod Pod Pod Nodes Pod Pod Pod Pod Pod Pod Clients
  7. 7. トラフィック制御への要件はアプリケーションにより様々だが、 大きく以下 3 つのポイントを考慮することが重要 1. トラフィックの向き 2. プロトコル 3. トラフィックに加える動き インバウンド トラフィック制御で考慮すべきポイント
  8. 8. ● インターネットからGKE へのトラフィック(External) ○ 外部公開目的 ○ ユーザーや 3rd party からのアクセス ○ 求められるセキュリティレベルが高い (SSL/TLS 、FW 、WAF etc.) ● VPC 内部から GKE へのトラフィック(Internal) ○ 内部システム間の連携など ○ VPC 内の GCE からのアクセス ○ Interconnect/Cloud VPN を経由したオンプレや他社クラウド上のホストからのアクセス ポイント トラフィックの向き
  9. 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. 10. ● 負荷分散 ○ 分散配置されたPod に対するトラフィックに対してL4 や L7 レベルで 負荷分散を行う ● 高度なルーティング ○ トラフィック スプリットやリダイレクト、URI リライトなどを行うなど ポイント トラフィックに加える動き
  11. 11. インターネットから へのトラフィック
  12. 12. トラフィックの負荷分散 External Traffic
  13. 13. トラフィックの負荷分散 GKE (k8s) の Service リソースを使う Type は LoadBalancer を指定 ● 外部 LB として、GCP の External TCP/UDP Network Load Balancing が利用される ● Proxy はせず、送信元 IP アドレスが 維持される ● 送信元 IP とポートと、宛先 IP とポート、 プロトコルのハッシュに基づいて バランシングを行う External Traffic
  14. 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
  15. 15. トラフィックの負荷分散 External Traffic
  16. 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. 17. External Traffic
  18. 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. 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. 20. 証明書、諸注意 ● SSL 証明書のローテーション ○ Managed certificate は自動更新、その他はユーザーが手動で更新する必要がある ● Ingress 毎の設定可能な SSL 証明書数 ○ 最大 10 個の SSL 証明書 を設定可能 ● SSL 証明書が複数ある場合の選択ルール ○ TLS ハンドシェイクの際の Domain name に基づいて、SNI を使ってどの SSL 証明書 を クライアントに返すか決める ○ どの SSL 証明書 の CN にもマッチしない場合は、リストの最初の SSL 証明書を使う External Traffic
  21. 21. External Traffic
  22. 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
  23. 23. External Traffic
  24. 24. 設定イメージ Service Internet Deployment Ingress External HTTP(S) LB GKE Cloud Armor Security policy ManagedCertificate BackendConfig $ kubectl で設定 固定外部IP $ gcloud で設定 External Traffic
  25. 25. コンテナ ネイティブ 負荷分散 External Traffic
  26. 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. 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. 28. ● 基本は使うべし ○ 新しい機能はNEG をベースに開発されていることが多い ○ 少しでもネットワークレイテンシーのオーバーヘッドを減らしたい、 パフォーマンスセントリックなワークロードは特に ● 設定自体は簡単だが、以下の通りQuota があるので注意 ○ プロジェクト毎の最大NEG 数 : 100 ○ NEG 毎のエンドポイント数: 10,000 は使うべきか? External Traffic
  29. 29. クラスタ間で トラフィックの負荷分散 External Traffic
  30. 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
  31. 31. External Traffic
  32. 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. 33. 以下のようなユースケースがある場合、おすすめ ● リージョン間で冗長構成を組みたい ● GKE クラスタのカナリーアップグレードをしたい ● グローバルにサービスを提供しつつ ○ クライアント〜サーバー間を同一地域内に閉じレイテンシーを低くしたい ○ シングル IP で運用したい 2020.04.27 現在、BackendConfig でサポートしているのはTimeout のみ 今後、通常のIngress と同等の機能を提供出来るようになる予定 を使うべきか? External Traffic
  34. 34. デモ External Traffic
  35. 35. トラフィックに対する 高度なルーティング External Traffic
  36. 36. Anthos Service Mesh (ASM) を使う ASM は Istio 互換のマネージドサービスメッシュ 以下のようなトラフィック制御が出来る ● トラフィック スプリット ● URI リライト ● Path Based Routing ● Retry logic ● Circuit Breaker ● Traffic Mirroring..etc. トラフィックに対する高度なルーティング External Traffic
  37. 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. 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. 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. 40. External Traffic Path Based Routing
  41. 41. External Traffic トラフィック スプリット
  42. 42. istio-ingressgateway は豊富なトラフィック制御機能が売り External HTTP(S) Load Balancing (Ingress) とあえて組み合わせて使う場合は 以下のケースが想定される ● シングル IP が必要な場合 ● Cloud Armor や Cloud CDN など BackendConfig 系の機能が必要な場合 ● Managed Certificate が必要な場合 ● Ingress for Anthos と組み合わせて利用したい場合 と の組み合わせ
  43. 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 “/”
  44. 44. トラフィックの負荷分散 External Traffic
  45. 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. 46. デモ ロードバランシング External Traffic
  47. 47. 以下のようなユースケースがある場合、おすすめ ● Ingress がサポートしていない高度なルーティングが必要 ● アプリがマイクロサービスアーキテクチャ ● gRPC の負荷分散、特にクラスタ内で行いたい(Envoy 個別に管理したくない) ● Istio 使いたいけどちょっと不安、Google のサポートがほしい Istio 運用のツラミはコミュニティでも情報が出てきてますので、 その辺りも参考にしながら、十分に設計、検証の上、導入しましょう! を使うべきか? External Traffic
  48. 48. 内部から へのトラフィック
  49. 49. トラフィックの負荷分散 Internal Traffic
  50. 50. トラフィックの負荷分散 Internal Traffic Egress と同様、Service リソースを使う Internal であることを示す、 アノテーションを付ける。(Beta) ● 外部 LB として、GCP の Internal TCP/UDP Load Balancing が利用される ● Proxy はせず、送信元 IP アドレスが 維持される ● バランシング アルゴリズムも External と 同様
  51. 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. 52. トラフィックの負荷分散 Internal Traffic
  53. 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. 54. Internal Traffic
  55. 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. 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. 57. まとめ
  58. 58. 以下 3 点と 各 LB の特徴を踏まえて快適なGKE トラフィック制御ライフを! 1. トラフィックの向き 2. プロトコル 3. トラフィックに加える動き マルチクラスタIngress や高度なルーティングはAnthos の機能として提供 今後更に機能が追加されていく予定 今後の GKE / Anthos にご期待ください! まとめ
  59. 59. #gc_inside #gc_inside
  60. 60. 今すぐ参加登録 ↑ ビジネスをサポートするGoogle Cloud ソリューションを学ぶ。 年 月 日 火 日 木 ライブ配信 年 月 日 火 日 火 開催
  61. 61. Google Cloud トレーニング無料提供 キャンペーンのご案内 Qwiklabs、Pluralsight(英語のみ)、対象 のCoursera のコースを1 か月間無料でご提供 お申込み期限は、5 月 20 日まで (Pluralsight のみ 4 月 30 日まで) goo.gle/TrainingOffer 詳細・お申込みはこちら ↑

×