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
GKE -IP体系のはなし-
Search
Yasuhiro Murata
November 27, 2019
Technology
0
120
GKE -IP体系のはなし-
朝のLT向けに作った、GKEのIP体系設計の話
Yasuhiro Murata
November 27, 2019
Tweet
Share
More Decks by Yasuhiro Murata
See All by Yasuhiro Murata
N:Nツリー構造データにおけるグラフDB活用
mura123yasu
0
890
JSON関数と共に歩む、BigQueryを使った超汎化型データ活用基盤
mura123yasu
0
360
引きこもって作ってみた!おうちKubernetes
mura123yasu
0
3.8k
Harbor
mura123yasu
0
80
ゼロから始めるFlutter生活 - Prologue
mura123yasu
0
360
CloudEvents
mura123yasu
0
350
envoy - Resilience -
mura123yasu
0
53
containerd
mura123yasu
0
71
etcd
mura123yasu
0
110
Other Decks in Technology
See All in Technology
Modern Linux
oracle4engineer
PRO
0
160
Bedrock で検索エージェントを再現しようとした話
ny7760
2
120
Snowflake Intelligence × Document AIで“使いにくいデータ”を“使えるデータ”に
kevinrobot34
1
120
Unlocking the Power of AI Agents with LINE Bot MCP Server
linedevth
0
120
LLM時代のパフォーマンスチューニング:MongoDB運用で試したコンテキスト活用の工夫
ishikawa_pro
0
170
企業の生成AIガバナンスにおけるエージェントとセキュリティ
lycorptech_jp
PRO
3
200
複数サービスを支えるマルチテナント型Batch MLプラットフォーム
lycorptech_jp
PRO
1
990
いま注目のAIエージェントを作ってみよう
supermarimobros
0
360
Oracle Cloud Infrastructure IaaS 新機能アップデート 2025/06 - 2025/08
oracle4engineer
PRO
0
110
なぜテストマネージャの視点が 必要なのか? 〜 一歩先へ進むために 〜
moritamasami
0
240
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
280
共有と分離 - Compose Multiplatform "本番導入" の設計指針
error96num
2
1.2k
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
53
7.8k
Bash Introduction
62gerente
615
210k
Site-Speed That Sticks
csswizardry
10
820
Context Engineering - Making Every Token Count
addyosmani
3
62
Statistics for Hackers
jakevdp
799
220k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
How to Think Like a Performance Engineer
csswizardry
26
1.9k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.6k
Become a Pro
speakerdeck
PRO
29
5.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Transcript
GKE – IP体系のはなし - morn ng alk Yasuhiro Murata 2019.11.27
GKEのIP体系設計 ミスっちゃいました
GKEのIP体系設計ミスっちゃいました u Shared VPC下でVPC-nativeなPrivateクラスタを構築しました Host Project Sub Project VPC Peering
GCP Managed-Project my-subnet VPC Managed VPC GKE-master GKE-node-pool GKE-pod GKE-service
GKEのIP体系設計ミスっちゃいました u 今回IP設計を行ったのは4箇所 Host Project Sub Project VPC Peering GCP
Managed-Project my-subnet VPC Managed VPC GKE-master GKE-node-pool GKE-pod GKE-service ①IP address range ②Master address range ③Pod address range ④Service address range
GKEのIP体系設計ミスっちゃいました u どんな設計にしたかというと... ① IP address range → 利用できるIP範囲に制限もあり「/21」 ②
Master address range → ドキュメント合わせる形で「/28」 ③ Pod address range → Pod数に余裕をみて「/20」 ④ Service address range → Service数に余裕をみて「/20」
どこをミスったの?
どこをミスったの? u PodのIP設計がNGでした ① IP address range → 利用できるIP範囲に制限もあり「/21」 ②
Master address range → ドキュメント合わせる形で「/28」 ③ Pod address range → Pod数に余裕をみて「/20」 ④ Service address range → Service数に余裕をみて「/20」
どこをミスったの? u こんな感じになると思っていました Sub Project GKE-node GKE-pod GKE-service GKE-node GKE-pod
GKE-service GKE-node GKE-pod GKE-service GKE-node GKE-pod GKE-service GKE-node GKE-pod GKE-service GKE-node GKE-pod GKE-service Podのアドレスは必要に応じて 各ノードに割り当てられる(嘘⼄) node-pool node-pool
違いました...
違いました... https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips?hl=ja#cluster_sizing
つまり...
つまり... u こういうこと Sub Project GKE-node GKE-pod GKE-service GKE-node GKE-pod
GKE-service GKE-node GKE-pod GKE-service GKE-node GKE-pod GKE-service GKE-node GKE-pod GKE-service GKE-node GKE-pod GKE-service node-pool node-pool /24 /24 /24 /24 /24 /24 「/24」ごとにNodeへ割り当て
つまり... u 必要なIP数は「Node数 * 256」で計算しなければなりませんでした l Pod address range l
Pod数に余裕をみて(みたつもりで)「/20」と定義していた l 利用可能なIP数は「4096」個 l 作成可能なNode数はたったの「 16」個
This is 知見
This is 知見 u GKEのIP体系設計で気をつけなければいけないこと l Pod address rangeは「/24」で各Nodeに割り振られる l
必要なPodのIPは「Node数 * 256」で計算すること
そもそも
業務内容ごとに Node-poolを分割したのが Node数増大の根源
やっぱアプリとインフラは 切り離して考えるべきだったよね
いったん Fin. 後日談へ続く...
さっそくの 後日談
後日談 https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidr?hl=ja u 最大Pod数を減らすことで割り当てCIDR範囲を小さくすることが可能
Fin.