Google Cloud GKEでのingress-gceとingress-nginxの違い

経緯

• Google CloudのGKEでIngressを利用する場合、まずingress-gceとingress-nginxが候補に挙がる（参考：K8s Ingressについて）
• それらをデプロイした場合に、Google Cloudのロードバランサ―等が自動生成されてクラスターと連携する
• それぞれ何ができるのか実際にデプロイしてみてサービス構成を確認後、機能を比較をした

まとめ

サービス構成

• デプロイ後の構成イメージは下図（左：ingress-nginx、右：ingress-gce）の通り
  

• 上図で省略しているロードバランサ―からPodへのアクセスは下図（左：ingress-nginx、右：ingress-gce）の通り

引用：https://cloud.google.com/kubernetes-engine/docs/concepts/container-native-load-balancing

機能比較

• ingress-gce（詳細）
  • 外部HTTP（S）ロードバランサ（従来）が生成され、そのバックエンドサービスのバックエンドとして効果薄るPodのエンドポイントを含むゾーンNEGが設定されるという状況
  • 主な利点
    • コンテナネイティブのロードバランシングを活用できるため、レイテンシーやスループットが高く、トラブルシューティングもしやすい
• ingress-nginx（詳細）
  • 外部TCP/UDP ネットワークロードバランサが生成され、そのバックエンドサービスのバックエンドとしてVM instanceが3つを含み、ingress-nginx-controllerの設定と連携した転送ルールをもつターゲットプールが設定されるという状況
  • 主な利点
    • 設定項目が非常に多くより細やかな機能設定が可能（らしい。項目の違いは未確認）
    • Could Providerによらずに同じ設定を使えるためマルチクラウド環境にも対応可能

サービス構成比較詳細

• 最小限と思われる、1 Ingress + 1 Service + 1 Deployment(1 Pod)の構成でデプロイした（yaml・デプロイ手順の詳細はこちら）
• 以降、ブラウザ上で詳細を確認をした際の記録

ingress-gce

• より一般的なまとめはこちら
• 生成されたロードバランサの設定画面
  • HTTP/HTTPS（クラシック）ロードバランサ―が生成され、バックエンドにゾーンネットワークエンドポイントグループ（ゾーンNEG）が設定されている
    
    
• ゾーンNEGの設定画面
  • defaultのVPCネットワーク、defaultのサブネットに属し、ホストVMのエンドポイントが含まれている
    
    

ingress-nginx

• より一般的なまとめはこちら
• 生成されたロードバランサの設定画面
  • ネットワーク（ターゲットプール）ロードバランサ―が生成され、3つのVMインスタンスを含むターゲットプールが設定されている
    
    
• ターゲットプールの設定画面
  - 転送ルールに {"kubernetes.io/service-name":"default/nginx-ingress-ingress-nginx-controller"}が紐づけられている
  `
  
  

所感

• 機能的な部分だけ考えると、とりあえず始めるならingress-gce、ロードバランサの細かい設定をしたい場合やマルチクラウドをしたい場合はingress-nginxを検討したらいいと思われる
• 本当はコスト比較もしたかったが、明確にまとめきれなかった
  • GKE以外でコストがかかるサービスは下記の通り（そもそも本当にこれだけなのかも怪しい）
    • Virtual Private Cloud
      • ネットワークの料金
    • Cloud Load Balancing
      • ロードバランサ―の利用料金
    • Compute Engine
      • VMインスタンス、ストレージの料金
  • ロードバランサ―の違い、NEGの有り無しによるネットワーク料金の違いや、nginx-ingress-controllerがPodとして存在することによるVMインスタンスのコストの違いが不明
  • ざっと公式ドキュメント類を見た限りでは、ingressの違いで劇的にコストは変わらないと思われる（料金計算ツールもあるが、抜け漏れがわからない）