Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Ad22fcf5773b906c08330f4d57242212?s=47 Kohei Ota
November 20, 2020

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

Ad22fcf5773b906c08330f4d57242212?s=128

Kohei Ota

November 20, 2020
Tweet

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