はじめに
こんにちは。最近数年ぶりにKubernetesの資格試験を受験したのですが、数年あけると色々な機能が新しく追加されたり、昔あった機能が非推奨になったりします。
Kubernetesではアプリケーションをクラスタ外部に公開するのにIngress/Ingress Controllerという機能が利用されてきましたが、この外部公開する仕組みについても現在はGateway APIというIngressに代わる機能が登場しています。
AWSでEKSを利用するときはAWS Load Balancer Controllerというアドオンを導入することによりIngress/Ingress Controllerと合わせてALBを作成・設定することでアプリケーションを公開していましたが、Gateway APIを利用したいときはどうすれば良いのでしょうか？
この記事ではEKSにおいてIngressとGateway APIを利用する際のAWSサービスの設定の違いについて説明します。
Ingress
利用方法
IngressはL7のルーティングを定義するKubernetesのリソースです。Ingressリソース自体は定義のみで、実際にルーティングをするのはIngress Controllerです。
前述の通り、AWS Load Balancer Controllerを利用することでIngress作成時に自動的にALBを作成・設定してくれます。
ここでは説明を割愛しますが、Load Balancer Controller自体もアドオンとして導入する必要がありますのでご注意ください。
EKS Add-onでサポートされていればマネジメントコンソールからワンクリックで導入出来ますが、残念ながらこのControllerには対応していません。
また、以下の検証ではnginxのコンテナをIngressで公開していますが、このコンテナの作成についても説明を割愛しています。
Kubernetes側の設定
以下の内容でIngressを作成します(アノテーションでALBの設定を指定)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: nginx-ingress
namespace: demo
annotations:
alb.ingress.kubernetes.io/scheme: internet-facing
alb.ingress.kubernetes.io/target-type: ip
spec:
ingressClassName: alb
rules:
- http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: nginx
port:
number: 80
公開対象のPodは以下です
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-576c6b7b6-tsgvn 1/1 Running 0 10h 10.0.157.232 ip-10-0-153-235.ap-northeast-1.compute.internal <none> <none>
nginx-576c6b7b6-vjwx4 1/1 Running 0 10h 10.0.135.205 ip-10-0-137-41.ap-northeast-1.compute.internal <none> <none>
AWS側の設定
Ingressを作成すると、それに対応したALBが作成されます。
ターゲットグループに公開対象のコンテナのIPが設定されていることが分かります
Gateway API
利用方法
Gateway APIもIngressと同様にL7ルーティングを定義するKubernetesの機能です。Ingressと比較した際の優位点としては、
- "どのLoad Balancer(Gateway/Ingress Contoller)を利用するか"と"どういったルールにするか"が分離された
- Ingressではアノテーションに詰め込まれていた各種設定がパラメータになった
ことが挙げられます。
このGateway APIを利用する方法は2種類あり、一つは前述のAWS Load Balancer Controller, もう一つはAWS Gateway API Controllerです。
ただし、インターネット公開を目的とする場合は前者のControllerしか利用出来ません。
まずは前者の仕様を確認します。
AWS Load Balancer Controller
Kubernetes側の設定
Gateway APIをLoad Balancer Controllerで利用するには、まずKubernetesクラスタ自体にGateway APIのCRD(Custom Resource Definition)をインストール必要があります。(Ingressは標準で組み込まれている)
CRDの導入
$ kubectl apply --server-side=true -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.0/standard-install.yaml
customresourcedefinition.apiextensions.k8s.io/gatewayclasses.gateway.networking.k8s.io serverside-applied
customresourcedefinition.apiextensions.k8s.io/gateways.gateway.networking.k8s.io serverside-applied
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io serverside-applied
customresourcedefinition.apiextensions.k8s.io/grpcroutes.gateway.networking.k8s.io serverside-applied
customresourcedefinition.apiextensions.k8s.io/referencegrants.gateway.networking.k8s.io serverside-applied
CRD導入以後の詳細な手順は以下のAWSブログをご確認ください。Ingressと比較して手動で作成が必要なKubernetesリソースが多いです。
GatewayClassではcontrollerを設定しておく必要があります。
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
name: aws-alb-gateway-class
spec:
controllerName: gateway.k8s.aws/alb
TargetGroupConfiguration・LoadBalancerConfigurationは省略可能ですが、デフォルトでは公開方式がNodePort(Pod単位ではなく、Nodeの特定ポート経由でコンテナにルーティングされる)なため、Ingressと公開方式を揃えるために追加の設定を行っています。
apiVersion: gateway.k8s.aws/v1beta1
kind: TargetGroupConfiguration
metadata:
name: ip-tg-defaults
namespace: demo
spec:
defaultConfiguration:
targetType: ip
apiVersion: gateway.k8s.aws/v1beta1
kind: LoadBalancerConfiguration
metadata:
name: ip-lb-config
namespace: demo
spec:
scheme: internet-facing
defaultTargetGroupConfiguration:
name: ip-tg-defaults
Gateway
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: nginx-gateway-ip
namespace: demo
spec:
gatewayClassName: aws-alb-gateway-class
infrastructure:
parametersRef:
kind: LoadBalancerConfiguration
name: ip-lb-config
group: gateway.k8s.aws
listeners:
- name: http
protocol: HTTP
port: 80
allowedRoutes:
namespaces:
from: Same
HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: nginx-route-ip
namespace: demo
spec:
parentRefs:
- name: nginx-gateway-ip
sectionName: http
rules:
- backendRefs:
- name: nginx
port: 80
AWS側の設定
Gatewayの設定に対応してALBが作成されます。
こちらもターゲットグループには公開対象のPodのIPが指定されているのが分かります
AWS Gateway API Controller
Load Balancer Controllerとの違い
まず最大の違いとして、Gateway API Controllerはインターネット公開用途で利用出来ないということです。以下のAWS Blogsにもその記載があります。
Use AWS Load Balancer Controller when you need any of the below:
Internet ingress: Your service needs to be accessible from the public internet
...
Use VPC Lattice Gateway API Controller when you need any of the below:
Cross-cluster communication: Services need to communicate across multiple EKS clusters
...
そのため、Gateway API ControllerでGateway APIを利用する場合は、VPC Latticeのリソースが作成されます。
具体的にはGatewayはVPC LatticeのService Networkと、HTTPRouteはServiceと連携します。
Gateway API ControllerについてもLoad Balancer Controller同様、まずアドオンとしてインストールする必要があります。
詳細な導入手順についてはこの記事では割愛しますので、以下をご確認ください。
Kubernetes側の設定
GatewayClassではcontrollerとしてGateway API Controllerを指定します。
apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
name: amazon-vpc-lattice
spec:
controllerName: application-networking.k8s.aws/gateway-api-controller
Gateway・HTTPRouteはLoad Balancer ControllerでGateway APIを利用する場合と同じ設定になります。
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: nginx-lattice-gateway
namespace: demo
spec:
gatewayClassName: amazon-vpc-lattice
listeners:
- name: http
protocol: HTTP
port: 80
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: nginx-lattice-route
namespace: demo
spec:
parentRefs:
- name: nginx-lattice-gateway
sectionName: http
rules:
- backendRefs:
- name: nginx
port: 80
AWS側の設定
Load Blancer ControllerではALBやターゲットグループが設定されていましたが、Gateway API ControllerではVPC Latticeのサービスネットワークやサービスが作成されています。
クラスタ外からのアクセス確認としてVPC CloudShellからアクセスしてみると、正常にアクセス出来ました。
使い分け
Load Balancer ControllerとGateway API Controllerの使い分け
Gateway API Controllerを使うべき場面として、上記Blogでは以下のように記載されています。EKSのクラスタ間や他VPC,AWSアカウント間など、インターネット公開以外のクラスタ外部との通信ではこちらを利用すべき、ということのようです。(Gateway APIというより、VPC Latticeの特長ですね)
Cross-cluster communication: Services need to communicate across multiple EKS clusters
Cross-VPC connectivity: Services span multiple VPCs and they need to communicate with each other, or services have targets across multiple VPCs.
Cross-Account access: Services in different AWS accounts need to communicate
Service-to-service communication features: You need features like automatic service discovery, traffic management, service-level routing capabilities
Authentication and authorization: You want to enforce service-to-service authentication and authorization policies
Simplified networking: You want to avoid managing network connectivity services such as VPC peering or AWS Transit Gateway.
Mixed compute options: You have applications that use AWS Lambda, Amazon Elastic Container Service (ECS), ECS Fargate, or Amazon Elastic Compute Cloud (EC2) instances, and you want simplified connectivity across all compute options.
EKSの場合はPodのIPはクラスタ内の仮想IPではなくVPCの実IPとなるので、このVPCに疎通が出来ればVPC LatticeがなくてもPodへのアクセスは可能なのですが、サービスディスカバリーや構成の疎結合性を考えるとGateway API Controllerの活用の利点は大きいように思います。
IngressとGateway APIの使い分け
ではLoad Balancer ControllerでIngressとGateway APIどちらを利用すべきか？ですが、新規構築であればGateway APIを利用すべきだと思います。Ingressは将来的にKubernetesとして非推奨・廃止となる可能性が考えられます。ただし、Gateway APIの利用にはCRDのインストールが必要なことから分かる通り、まだまだ多くの場面でIngressが利用されているため、直近で問題になることはないと思います。
まとめ
本記事ではEKSでアプリケーションをインターネット公開する際のIngress/Gateway APIの利用と、このGateway APIに関連してAWS Load Balancer Controller・AWS Gateway API Controllerの違いについて確認しました。
Kubernetes、AWSとも日々最新のサービス・機能が追加されていきますので、都度情報をキャッチアップをしていく必要がありますね。
この記事が何かのお役に立てば幸いです。