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

Transcript

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

   View Slide

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
   

   View Slide

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は残したいケース)
   

   View Slide

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は残したいケース)
   今日は主にここにフォーカ
   スします
   

   View Slide

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"
   必要
   

   View Slide

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
   実装で管理
   

   View Slide

7. なぜIPモードの対応が必要か
   

   View Slide

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
   

   View Slide

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”
   

   View Slide

10. IPモードの動き
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. デモ
    

    View Slide

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
    

    View Slide