はじめに
AWSのALBをIngressリソースとして扱うためのALB Ingress Contollerが、2.0.0に昇格したタイミングで「AWS Load Balancer Controller」と名前を変えました。
このエントリーではかんたんに概要を追ってみようと思います。
ALB Ingress Contollerのこれまで
従来ALB Ingress Controllerでは、名前の通りAWSのALBをKubernetesのIngressとして扱うための機能を提供してきました。挙動としては以下の通りです。
- Kubernetes上でIngressリソースを作成するとALBが1つ作成される
- Ruleに記述されたPathに従って、ALBのTargetGroupが作成され、上記で作成された単一のALBに紐づく
- KubernetesノードのNodePortに対してロードバランスされる
このとき、Ingress1つに対してALB1台が作成されるモデルであることから、Ingressを作成すればするほどALBの数も増えていくという問題がありました。Nginx IngressのようにVirtualHost的な機能がほしいとかねてより要望がありましたが、これまでALB Ingress Controller1.x.xではこの機能は提供されていませんでした。
また、これまでのALB Ingress ControllerはもともとTicketmaster社と旧CoreOS社が作り始めたもので、AWSがメンテナンスを始めたのは後発でした。AWS Load Balancer Controllerとなった2.0.0ではアーキテクチャが刷新されており、機能面でも異なる部分が多いため、既にALB Ingressを利用されている方につきましてはドキュメントをよく読んだ上で移行を進めることを強く推奨します。
AWS Load Balancer Controllerの機能
新しいLoad Balancer Controllerでは、「AWSのロードバランサーを制御するオペレーター」という形で動作します。つまり
- ALBをIngressで制御
IngressGroupの登場によるALBのグルーピング
- NLBをServiceで制御
- TargetGroupを用いてPodを公開するための新しいカスタムリソース「TargetGroupBinding 」
この3つが大きな特徴で、特にTargetGroupBindingの登場によって、kubectlとaws cliのコンテキストスイッチなしにワークロードのリソースが制御しやすくなったというのは大きいでしょう。CFn/Terraform/cdkなどで作成したTargetGroupを指定することができる一方で、そのへんのリソース管理も重要になってきそうです。
IngressGroupを使うことで上記の「複数のIngressでも同一のALBが使いたい」という要望が叶うため、リソース利用効率の上昇も期待されるところです。
現状、TargetGroupBinding周りの使い方がよくわかってないので、分かり次第続きのエントリーを書こうかな。今日は一旦このへんで！
