KubernetesにおけるLoadBalancerとIngressの違いについて
Kubernetesでは, インターネットからクラスタ内部のPodにアクセスするためにServiceやIngressを通して内部のPodにアクセスできるように必要があります.
このとき一般的な公開方法としてLoad Balancer Serviceを使う方法とIngressを用いる方法がありますが, (NodePortやClusterIPで公開する方法は, 用途が限られるので割愛します) 本記事ではそれぞれの機能と使い分けについて簡単に解説しようと思います.
LoadBalancer
ロードバランサは下記のように定義することができます.
下記の例は hello-world
というセレクタで指定したサービスの8080番ポートにロードバランサ上の80番ポートへのリクエストをフォワーディングするように設定しています.
apiVersion: v1 kind: Service metadata: name: hello-world-service annotations: spec: type: LoadBalancer ports: - port: 80 protocol: TCP targetPort: 8080 selector: app: hello-world loadBalancerIP: xxx.xxx.xxx.xxx
GKEやAWSなどのクラウドプロバイダではLoadBalancerタイプをデフォルトでサポートしており, GKEの場合は Cloud Load Balancing が自動的に利用され, L4 (TCP/UDP)のロードバランサとして動作します.
そのため, 個別のHTTPリクエスト内容を元にしたフィルタリングなどをすることはできません. (ベアメタル上でロードバランサを動かしたい場合は自前で実装を行う必要があります) また, L4ロードバランサの原理上SSL終端などにも原理上対応していません.
(追加の注意点としてロードバランサはGKEにおいて特定のリージョンのサービスにしかフォワーディングを行うことができません.)
Ingress
今回の本題ですが, IngressはLoad Balancer Serviceとは違いL7(HTTP/HTTPS)ロードバランサーとして機能します. そのため, ホストやパスの値に応じて複数のサービスに対するリクエストを制御することが可能です. ただし, Ingressだけではサービスを外部に公開できないため, NodePortなどと併用する必要があります.
例えば下記の定義ファイルのようにパスの設定に応じてバックエンドのサービスを変更することができます.
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test spec: tls: - secretName: foo-bar-tls hosts: - foo.bar.com rules: - host: foo.bar.com http: paths: - backend: serviceName: s1 servicePort: 80 - host: bar.foo.com http: paths: - backend: serviceName: s2 servicePort: 80
また, L7ロードバランサであるためにSSL終端を行うことができ, tlsオプションでSSL鍵を指定することで インターネット -> Ingress
の経路におけるトラフィックをSSL化することができます.
他にもGKE上でIngressはグローバルなリージョンでのロードバランシングにも対応しているのでリージョンを跨いだロードバランシングも簡単に行うことができるようになっています.
まとめ
KubernetesにおけるLoadBalancerとIngressの違いについて簡単に解説を行いました. 基本的には外部で公開するサービスはSSL化すべきなので, 実際の利用時にはIngressを利用する場合が多いかと思います.
次回の記事ではIngressのSSL証明書の自動更新を行ってくれるプラグインである, cert-managerの導入方法について書こうと思います.
参考文献
- Setting up HTTP Load Balancing with Ingress | Kubernetes Engine Tutorials | Google Cloud
- medium.com
- Ingress - Kubernetes
From Shun