$30 off During Our Annual Pro Sale. View Details »

Amazon Load Balancer Controller クイックオーバービュー / Amazon Load Balancer Controller quick overview

Kohei Ota
November 20, 2020

Amazon Load Balancer Controller クイックオーバービュー / Amazon Load Balancer Controller quick overview

Kohei Ota

November 20, 2020
Tweet

More Decks by Kohei Ota

Other Decks in Technology

Transcript

  1. ALB Ingress Controllerあらため AWS Load Balancer Controller クイックオーバービュー JAWS-UGコンテナ支部 #18

    Presented by @inductor
  2. じこしょうかい apiVersion: inductor.apps/v1 kind: Person metadata: name: “Kohei Ota” Twitter:

    “@_inductor_” GitHub: “@inductor” org: “HPE” role: “Solutions Architect” community: “CNCF Ambassador, CloudNative Days organizer, Docker Meetup Tokyo organizer” spec: replicas: 1
  3. Load Balancer Controllerのおもな追加点 LoadBalancer Serviceが使えるようになった! → 名前がAWS Ingress Controllerじゃなくなった一番大きな理由 AWSのロードバランサーを管理するためのカスタムコントローラー爆誕!

    1つのALBを複数のIngressリソースで利用可能になった → これまでのALB IngressはIngressの数=ALBの数でコストかかりがちだった 既存のALBに相乗りするなどもできず、Ingress削除=ALB削除 カスタムリソースTargetGroupBindingが追加 → 既存のALB/NLBに対して割り当てるTarget Groupを管理するためのリソース LBのライフサイクルがKubernetesのServiceに依存しなくなるメリットがある (例: クラスターを消したいけどLBは残したいケース)
  4. Load Balancer Controllerのおもな追加点 LoadBalancer Serviceが使えるようになった! → 名前がAWS Ingress Controllerじゃなくなった一番大きな理由 AWSのロードバランサーを管理するためのカスタムコントローラー爆誕!

    1つのALBを複数のIngressリソースで利用可能になった → これまでのALB IngressはIngressの数=ALBの数でコストかかりがちだった 既存のALBに相乗りするなどもできず、Ingress削除=ALB削除 カスタムリソースTargetGroupBindingが追加 → 既存のALB/NLBに対して割り当てるTarget Groupを管理するためのリソース LBのライフサイクルがKubernetesのServiceに依存しなくなるメリットがある (例: クラスターを消したいけどLBは残したいケース) 今日は主にここにフォーカ スします
  5. EKSにおけるLoadBalancer Serviceの種類 LBの種類とモード YAMLのアノテーション LB Controller CLB なし 不要 NLB(instance

    mode) service.beta.kubernetes.io/aws-load-balancer-type: "nlb" 不要 NLB(ip mode) service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" 必要
  6. EKSにおけるLoadBalancer Serviceの種類 LBの種類とモード YAMLのアノテーション LB Controller CLB なし 不要 NLB(instance

    mode) service.beta.kubernetes.io/aws-load-balancer-type: "nlb" 不要 NLB(ip mode) service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip" 必要 既存のin-tree cloud provider 実装で管理
  7. なぜIPモードの対応が必要か

  8. TargetGroup NodePort TCP: 30001 NodePort TCP: 30001 NodePort TCP: 30001

    これまでのService LoadBalancerの振り分け NLB Listener Node Node Node kube-proxy kube-proxy kube-proxy Destination Pod
  9. TargetGroup NodePort TCP: 30001 NodePort TCP: 30001 NodePort TCP: 30001

    これまでのService LoadBalancerの振り分け NLB Listener Node Node Node kube-proxy kube-proxy kube-proxy Destination Pod 1. LBがノード(各EC2)のNodePortにロードバランシングしつ つ通信を転送 2. NodePort ServiceからPodのいるノードに通信を転送 3. Podに通信が到達 → これがいわゆる”Instance mode”
  10. IPモードの動き

  11. TargetGroup これまでのService LoadBalancerの振り分け NLB Listener Node Node Node amazon-vpc-cni-k8s Destination

    Pod
  12. TargetGroup これまでのService LoadBalancerの振り分け NLB Listener Node Node Node amazon-vpc-cni-k8s Destination

    Pod シンプル!!
  13. Appendix: amazon-vpc-cni-k8sについて AWSのVPC上でKubernetesのネットワークを動かすためのCNIプラグイン → CNIが何かについては同じくコンテナ支部で前ぼくが話した 「OSSから理解するEKSとそのエコシステムについて」を御覧ください PodやService(ClusterIP含)にVPCのIPアドレスを割り当てることができるため、AWS のリソースからPod/Serviceに直接通信するようなことも可能 → コンテナネイティブロードバランシングってやつ

    今までのService LB実装ではこれに対応しきれていなかった
  14. デモ

  15. まとめ Load Balancer ControllerのNLB-IPを使うとネットワーク由来のボトルネックが 改善される!! ALB Ingressにも嬉しい改善がいっぱい!(今回は時間の関係上取り扱わず) 今日扱った内容の補足資料はこちら YAMLおきば: https://github.com/inductor/aws-container-meetup-sample

    前回資料: https://speakerdeck.com/inductor/understanding-eks-and-its-ecosystem-from-oss-perspective