Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Amazon Load Balancer Controller クイックオーバービュー / A...
Search
Kohei Ota
November 20, 2020
Technology
1
1.8k
Amazon Load Balancer Controller クイックオーバービュー / Amazon Load Balancer Controller quick overview
Kohei Ota
November 20, 2020
Tweet
Share
More Decks by Kohei Ota
See All by Kohei Ota
The Cloud Native Chronicles: 10 Years of Community Growth Inside and Outside Japan
inductor
0
80
Cracking the KubeCon CfP
inductor
3
390
KubeCon Recap -Platform migration at Scale-
inductor
1
910
コンテナビルド最新事情 2022年度版 / Container Build 2022
inductor
3
420
データベースとストレージのレプリケーション入門 / Intro-of-database-and-storage-replication
inductor
26
6k
KubeConのケーススタディから振り返る、Platform for Platforms のあり方と その実践 / Lessons from KubeCon case studies: Platform for Platforms and its practice
inductor
3
720
オンラインの技術カンファレンスを安定稼働させるための取り組み / SRE activity for online conference platform
inductor
1
1.2k
Kubernetesネットワーキング初級者脱出ガイド / Kubernetes networking beginner's guide
inductor
18
5.8k
コンテナネイティブロードバランシングの話 / A story about container native load balancing
inductor
2
2k
Other Decks in Technology
See All in Technology
開発生産性を始める前に開発チームができること / optim-improve-development-productivity.pdf
optim
0
150
突撃! 隣のAmazon Bedrockユーザー 〜YouはどうしてAWSで?〜
minorun365
PRO
3
400
より快適なエラーログ監視を目指して
leveragestech
4
1.5k
コンポーネントテストの手法と その効果を考える
yotahada3
3
330
Next.js のページ遷移を全力で止める
ypresto
9
3.6k
実務における脅威モデリングを考えよう
nikinusu
1
720
DuckDB雑紹介(1.1対応版)@DuckDB座談会
ktz
6
1.4k
フロントエンド開発事例③ Yahoo! JAPAN トップページ
lycorptech_jp
PRO
0
110
AIで変わるテスト自動化:最新ツールの多様なアプローチ/ 20240910 Takahiro Kaneyama
shift_evolve
0
250
なにもしてないのにNew Relicのデータ転送量が増えていたときに確認したこと
tk3fftk
2
230
【株式会社ELYZA】|GENIAC成果報告会 自社開発モデルプレゼンテーション
elyza
1
430
Google CloudのLLM活用の選択肢を広げるVertex AIのパートナーモデル
nayuts
0
130
Featured
See All Featured
Adopting Sorbet at Scale
ufuk
73
8.9k
Docker and Python
trallard
39
3k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
8.9k
For a Future-Friendly Web
brad_frost
174
9.3k
Thoughts on Productivity
jonyablonski
66
4.2k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
24
610
Navigating Team Friction
lara
183
13k
10 Git Anti Patterns You Should be Aware of
lemiorhan
653
58k
Rebuilding a faster, lazier Slack
samanthasiow
78
8.6k
How to Think Like a Performance Engineer
csswizardry
16
960
From Idea to $5000 a Month in 5 Months
shpigford
379
46k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
Transcript
ALB Ingress Controllerあらため AWS Load Balancer Controller クイックオーバービュー JAWS-UGコンテナ支部 #18
Presented by @inductor
じこしょうかい 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
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は残したいケース)
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は残したいケース) 今日は主にここにフォーカ スします
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" 必要
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 実装で管理
なぜIPモードの対応が必要か
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
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”
IPモードの動き
TargetGroup これまでのService LoadBalancerの振り分け NLB Listener Node Node Node amazon-vpc-cni-k8s Destination
Pod
TargetGroup これまでのService LoadBalancerの振り分け NLB Listener Node Node Node amazon-vpc-cni-k8s Destination
Pod シンプル!!
Appendix: amazon-vpc-cni-k8sについて AWSのVPC上でKubernetesのネットワークを動かすためのCNIプラグイン → CNIが何かについては同じくコンテナ支部で前ぼくが話した 「OSSから理解するEKSとそのエコシステムについて」を御覧ください PodやService(ClusterIP含)にVPCのIPアドレスを割り当てることができるため、AWS のリソースからPod/Serviceに直接通信するようなことも可能 → コンテナネイティブロードバランシングってやつ
今までのService LB実装ではこれに対応しきれていなかった
デモ
まとめ 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