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
90
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
700
JSON関数と共に歩む、BigQueryを使った超汎化型データ活用基盤
mura123yasu
0
290
引きこもって作ってみた!おうちKubernetes
mura123yasu
0
3.6k
Harbor
mura123yasu
0
73
ゼロから始めるFlutter生活 - Prologue
mura123yasu
0
300
CloudEvents
mura123yasu
0
270
envoy - Resilience -
mura123yasu
0
44
containerd
mura123yasu
0
61
etcd
mura123yasu
0
100
Other Decks in Technology
See All in Technology
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
380
2024年グライダー曲技世界選手権参加報告/2024 WGAC report
jscseminar
0
300
Can We Measure Developer Productivity?
ewolff
1
110
地理情報データをデータベースに格納しよう~ GPUを活用した爆速データベース PG-Stromの紹介 ~
sakaik
1
130
Terraform未経験の御様に対してどの ように導⼊を進めていったか
tkikuchi
2
370
TanStack Routerに移行するのかい しないのかい、どっちなんだい! / Are you going to migrate to TanStack Router or not? Which one is it?
kaminashi
0
280
私はこうやってマインドマップでテストすることを出す!
mineo_matsuya
0
310
Going down the RAT hole: Deep dive into the Vuln-derland of APT-class RAT Tools
nttcom
0
320
障害対応指揮の意思決定と情報共有における価値観 / Waroom Meetup #2
arthur1
5
420
テストコード品質を高めるためにMutation Testingライブラリ・Strykerを実戦導入してみた話
ysknsid25
6
1.7k
社内で最大の技術的負債のリファクタリングに取り組んだお話し
kidooonn
1
500
ノーコードデータ分析ツールで体験する時系列データ分析超入門
negi111111
0
350
Featured
See All Featured
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Navigating Team Friction
lara
183
14k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
400
Practical Orchestrator
shlominoach
186
10k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
Music & Morning Musume
bryan
46
6.2k
Raft: Consensus for Rubyists
vanstee
136
6.6k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
7
570
Bash Introduction
62gerente
608
210k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
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.