ingress-gce（GKE Ingress）をGKEにデプロイしたときに何が起こるか

2023年1月16日

はじめに

  • GKEのクラスターにIngressをデプロイする場合、特にannotationをつけなければingress-gceが用いられる
    • Ingressについてはこちらもご参考に：Kubernetes Ingressについて
    • ingress-gceはGKE ingressやGLBC（Google Load Balancer Controller）とも呼ばれる
  • ingress-gceをGKEにデプロイした時にKubernetes Ingress APIを介してGoogle CloudのCloud load balancerやNEGなどが生成されるが、Google Cloudで実際どういう構成になるのかイメージできなかったので、最小限のアプリ（Ingress+Service+Pod）をデプロイしたときに何が生成されてどういう関係性なのかを調査した
  • ingress-nginxをデプロイした場合の調査はこちら：ingress-nginxをGKEにデプロイしたときに何が起こるか
  • Ingressのyamlは下記の通り（ServiceとDeploymentのyamlはこちら）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: basic-ingress
spec:
  defaultBackend:
    service:
      name: web
      port:
        number: 8080

ingress-gceをデプロイしたときの構成

  • Service、Podを一つ含むDeployment、Ingress（ingress-gce）をデプロイしたとき、下図のような構成になる
    ingress-gceとService, Podをデプロイしたときの構成イメージ
  • 生成されるGoogle Cloudのサービスはタイミングはそれぞれ下記の通り
    • VPC NetwokとSubnetはアカウントを作成したとき
    • K8s clusterと3つのVM instatnceはGKEにクラスターを作成したとき
    • ロードバランサとゾーンNEGはIngressをデプロイしたとき
  • Ingress+Serviceで外部アクセスをロードバランシングしてPodに導く構成を、Google CloudのロードバランサとNEGによりVM instance内のPodにアクセスを導くという構成をとることで、コンテナネイティブのロードバランシング（Podレベルでのロードバランシング）が可能になる
    デフォルトの動作（左）とコンテナネイティブのロードバランサの動作の比較
    （引用：https://cloud.google.com/kubernetes-engine/docs/concepts/container-native-load-balancing）
  • GKEでコンテナネイティブのロードバランシングを行う利点はざっくり下記の通り
    • ネットワークパフォーマンスの改善
      • ロードバランサがPodと直接通信するため、デフォルトに比べレイテンシーとスループットが改善される
    • 可視性の向上
      • Kuberentesのiptablesを介さないため、トラブルシューティングしやすい
    • 高度なロードバランシング機能のサポート
      • HTTP(S)ロードバランシング機能がサポートされているため、高機能
    • Traffic Directorのサポート
      • NEGを使っているため、Traffic Directorを使用できる（詳細は要調査）

Google Couldの要素（ロードバランサ―、NEG、VMインスタンス）の詳細は以降にまとめる

構成要素

外部HTTP(S)ロードバランサ

  • Cloud Load Balancingというサービスが提供するロードバランサのうちの一つ
  • 厳密には、外部HTTP(S)ロードバランサ（従来）が生成される
  • プロキシベースのL7 ロードバランサであり、一つの外部IP アドレスをもつ
    • 外部からアクセスすべきIPアドレスは、Ingressのアドレスと連携されているため、kubectlでIngressの設定を見るとIPアドレスを確認できる
  • バックエンドサービスを設定し、背後でサービスを実行する
    • バックエンドサービス：Cloud Load Balancing によるトラフィックの分散方法を定義する
    • バックエンドサービスに設定する分散方法は、「バックエンド」と呼ばれる
  • 今回のケースでは、Ingressをデプロイすることで、「外部HTTP（S）ロードバランサ（従来）が生成され、そのバックエンドサービスのバックエンドとしてゾーンNEGが設定される」という状況

ゾーンNEG

  • NEGはNetwork Endpoint Groupの略
    • Network Endpointは、今回のケースはPodのエンドポイント（Serviceではないところが重要）
    • Podのエンドポイントは、IPアドレス・ポートを利用するため、NetworkEndpointType API 名は、GCE_VM_IP_PORT
  • GKEの場合、ゾーンNEGが作成され、今回のケースではdefaultのVPCネットワーク・defaultのサブネットに属する
  • コンテナネイティブのロードバランシングを構築するには、仮想 IP アドレス、転送ルール、ヘルスチェック、ファイアウォール ルールなど設定項目がたくさんあるが、Ingressを利用することで自動で設定されるため、簡単に利用できるようになる

VM instance

  • 厳密にはGKEクラスターを作成したときにインスタンスが3つ作成される
  • 各VM instanceは、KuberenetesにはNodeとして認識され、Podが配置される

参考

項目調査まとめKuberentes,GKE,Google Cloud,Ingress

Posted by ttnt