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
140
0
Share
GKE -IP体系のはなし-
朝のLT向けに作った、GKEのIP体系設計の話
Yasuhiro Murata
November 27, 2019
More Decks by Yasuhiro Murata
See All by Yasuhiro Murata
N:Nツリー構造データにおけるグラフDB活用
mura123yasu
0
1k
JSON関数と共に歩む、BigQueryを使った超汎化型データ活用基盤
mura123yasu
0
410
引きこもって作ってみた!おうちKubernetes
mura123yasu
0
3.9k
Harbor
mura123yasu
0
95
ゼロから始めるFlutter生活 - Prologue
mura123yasu
0
400
CloudEvents
mura123yasu
0
390
envoy - Resilience -
mura123yasu
0
71
containerd
mura123yasu
0
99
etcd
mura123yasu
0
130
Other Decks in Technology
See All in Technology
【ハノーバーメッセ振り返りイベントat名古屋】データは集約からAI起点の収集に ~組織内・組織間でのデータ連携~
tanakaseiya
0
120
食べログのサーキットブレーカー導入を振り返って
atpons
0
110
ラズパイ & Picoで入門:Zephyr(RTOS)の環境構築からビルドまでの紹介
iotengineer22
0
240
TypeScriptはどのようにどこまで推論できるのか ─ とにかく as は禁止で
ypresto
3
420
キャリア25年目にしてTypeScript に出会うまで - 「型」を通じて振り返るプログラミング言語遍歴 / Meeting TypeScript After 25 Years in Tech - Looking Back at My Programming Language Journey Through "Types"
bitkey
PRO
2
280
A Harness for Behaviour: how to get AI to generate code that does what we intend, or "TDD in the age of AI"
xpmatteo
0
420
AIAgentと取り組むKaggle
508shuto
2
560
TROCCOで始めるクラウドコストを民主化するためのFinOps
tk3fftk
0
120
Claude Codeですべての日常業務を爆速化しよう!
minorun365
PRO
15
13k
JavaScript実装の自作プログラミング言語をTypeScript実装に移行した話
keisukeikeda
1
160
実践 TanStack Start ― 新規プロダクトを開発して確立した、サーバーとクライアント境界の設計パターン / Practical TanStack Start Server-Client Boundary Patterns
kaminashi
2
320
なぜハノーバーメッセに行くべきなのか 〜初参加だから語れること〜
tanakaseiya
0
110
Featured
See All Featured
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.1k
The Invisible Side of Design
smashingmag
302
52k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
3.1k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
10k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2k
Practical Orchestrator
shlominoach
191
11k
The agentic SEO stack - context over prompts
schlessera
0
780
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.6k
Statistics for Hackers
jakevdp
799
230k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
920
Rails Girls Zürich Keynote
gr2m
96
14k
Design in an AI World
tapps
1
220
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.