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
CKE で始める!はじめての Kubernetes クラスタインプレースアップグレード
Search
Cybozu
PRO
February 27, 2020
Technology
0
2.9k
CKE で始める!はじめての Kubernetes クラスタ インプレースアップグレード
Cybozu
PRO
February 27, 2020
Tweet
Share
More Decks by Cybozu
See All by Cybozu
AIツール開発ワークショップ(Dify)【サイボウズ新人研修2025】
cybozuinsideout
PRO
8
10k
モバイル【サイボウズ新人研修2025】
cybozuinsideout
PRO
3
2.7k
Git/GitHub を使う上で知っておくと嬉しいかも Tips【サイボウズ新人研修2025】
cybozuinsideout
PRO
8
6.7k
GitHub Copilot活用【サイボウズ新人研修2025】
cybozuinsideout
PRO
13
10k
ソフトウェアライセンス【サイボウズ新人研修2025】
cybozuinsideout
PRO
8
6.7k
エンジニアのためのアウトプット講座 〜知識をシェアするはじめの一歩〜【サイボウズ新人研修2025】
cybozuinsideout
PRO
6
3.4k
Docker入門【サイボウズ新人研修2025】
cybozuinsideout
PRO
11
8.1k
セキュリティ【サイボウズ新人研修2025】
cybozuinsideout
PRO
2
2.3k
TLS 1.3をざっと理解する【サイボウズ新人研修2025】
cybozuinsideout
PRO
2
1.4k
Other Decks in Technology
See All in Technology
CDKTFについてざっくり理解する!!~CloudFormationからCDKTFへ変換するツールも作ってみた~
masakiokuda
1
190
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
130
Sansanのデータプロダクトマネジメントのアプローチ
sansantech
PRO
0
220
united airlines ™®️ USA Contact Numbers: Complete 2025 Support Guide
flyunitedhelp
1
470
【あのMCPって、どんな処理してるの?】 AWS CDKでの開発で便利なAWS MCP Servers特集
yoshimi0227
6
600
成長し続けるアプリのためのテストと設計の関係、そして意思決定の記録。
sansantech
PRO
0
140
Operating Operator
shhnjk
1
640
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
230
オーティファイ会社紹介資料 / Autify Company Deck
autifyhq
10
130k
OpenTelemetryセマンティック規約の恩恵とMackerel APMにおける活用例 / SRE NEXT 2025
mackerelio
2
1.3k
マルチプロダクト環境におけるSREの役割 / SRE NEXT 2025 lunch session
sugamasao
1
220
2025-07-06 QGIS初級ハンズオン「はじめてのQGIS」
kou_kita
0
180
Featured
See All Featured
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.6k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Building an army of robots
kneath
306
45k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.1k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Side Projects
sachag
455
42k
Why You Should Never Use an ORM
jnunemaker
PRO
58
9.4k
Transcript
Maneki & Neco Meetup CKE で始める︕ はじめての Kubernetes クラスタ インプレースアップグレード
2020-02-18 サイボウズ株式会社 ⽯井 正將 (masa213f)
発表タイトルについてのお詫び ▌チュートリアル的なタイトルですが チュートリアルではありません ▌Neco で実現している Kubernetes クラスタの アップグレード⽅法の説明になります 1
⾃⼰紹介 ▌サイボウズ ⼤阪オフィス勤務 • OSや仮想化に興味があったエンジニア ▌経歴 • 前職では、電機メーカーでOS・仮想化の開発 • 2018/09
サイボウズ キャリア⼊社 • 2019/03 運⽤本部 インフラ刷新プロジェクト Neco へ異動 2
質問 ▌Kubernetes v1.17 がリリースされました。 あなたの環境では Kubernetes v1.16 を使っています。 どうやって、Kubernetes クラスタを更新しますか︖
3 ▌よく聞く⽅法 1. クラスタを新しく⽤意して、丸ごと引っ越し 2. ノードを順番に更新して、ローリングアップグレード
⽅法1: 丸ごと引っ越し ▌クラスタを新しく⽤意して、丸ごと引越し Old 4 New! App App App
⽅法2: ローリングアップグレード ▌ノードを順番に更新し、ローリングアップグレード 5 App App App App App App
App App Old Old Old Old
⽅法2: ローリングアップグレード 1. 更新したいノードを kubectl drain ØPod が退去 (evict) &
そのノードへの Pod の配置が停⽌ 6 App App App App App App Old Old Old Old App App 更新したい kubectl drain
⽅法2: ローリングアップグレード 2. ノードの更新 7 App App App App App
App Old Old Old Old⇨New App App Pod動きません
⽅法2: ローリングアップグレード 3. ノードの更新が終わったら kubectl uncordon Øノード上で Pod が動作可能になる 8
App App App App App App Old Old Old New App App Kubectl uncordon
⽅法2: ローリングアップグレード 9 App App App App Old Old Old
New App App App App kubectl drain ▌これをノードの数だけ繰り返す • アプリケーションはいずれかのノード上で動作 Øサービス無停⽌で更新できる
これらの⽅法 ▌⽅法1、2は ノードのローカルストレージに データが保存されていない場合はうまくいく ▌Neco の Kubernetes クラスタは 少し事情が異なる Ø⾃社製
Kubernetes 管理ツール CKE で In-place Upgrade 10
CKE とは (Cybozu Kubernetes Engine) ▌サイボウズで開発している OSS ▌Kubernetes クラスタの構築と運⽤を⾃動化するソフトウェア ▌Kubernetes
Conformance Software に認定 詳しく知りたい⽅は、以下を参照ください。 n GitHub Ø https://github.com/cybozu-go/cke n CKEがKubernetes Conformance Softwareに認定されました – Cybozu Inside Out Ø https://blog.cybozu.io/entry/cke 11
Neco の Kubernetes ▌Storage on Kubernetes Øローカルストレージを多⽤する 2種類のサーバで構成 (CS、SS合わせて、1クラスタ数千台 ×
3 クラスタ) 1. CS (Compute Server) • ⾼速な CPU、SSD • AP サーバ、DBサーバ (更新頻度の⾼いデータを保存) として利⽤ 2. SS (Storage Server) • ⼤量の HDD • S3 互換のオブジェクトストレージ (更新頻度の低いデータを保存) として利⽤ 12
Neco のアップグレード要件 ▌Neco の Kubernetes には⼤量のデータ • アップグレードの度に サーバ間 and/or
クラスタ間で データのコピーはしたくない (ネットワークの負荷も上がるし、ディスクの寿命も縮まる) 13
Neco のアップグレード要件 ▌Neco の Kubernetes には⼤量のデータ • kubectl drain で
Pod を退去するとデータのコピーが不可避 Ø数千台のノードで、データをキャッチボールことに…… 14 data data Pod Pod ⼼機⼀転︕ 頑張るぞ︕ データも 送るよー︕ kubectl drain data data データないっす ⾃分も空っす Old Old Old⇨New
Neco のアップグレード要件 ▌クラスタのアップグレードでアプリケーションを⽌めたくない • 好きなタイミングで、⾃由に更新したい (夜は寝ていたい) 15
Neco のアップグレード要件 ▌Kubernetes は 3ヶ⽉に1度 マイナーアップデート • 陳腐化を防ぐために、追従していきたい Ø数千台のノードを、 3ヶ⽉毎に更新……
16
Neco のアップグレード要件 ▌まとめると 1. Eviction-free な In-place Upgrade • クラスタの作り直しなし
• ノードの⼊替なし • Pod の退去 (evict) なし 2. 加えて、(できるだけ) クラスタ無停⽌ 3. さらに加えて、(頻度が⾼いので) ⾃動化したい 17
Neco の構成 OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes 管理ツール
(CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌ざっくりとこんな構成 Neco Maneki + 製品開発 チーム 18 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS)
どこをアップグレードしたい︖ ▌⼤まかに分類すると4種類 1. Pod (Kubernetes ワークロード) • マネージドサービス 2. Kubernetes
• Kubernetes コンポーネント 3. OS 4. (サーバの) ファームウェア 19 今⽇はココの説明
こいつを Kubernetes のアップグレード OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes
管理ツール (CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌CKE で更新する 20 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS) こいつが
Kubernetes の構成 ▌⼤きく分けると2種類のノード 1. Masterノード (3〜7台) • クラスタ全体を管理 (etcd /
kube-apiserver / kube-scheduler / kube-controller-manager ) 2. Workerノード (たくさん) • アプリケーション (Pod) の実⾏環境 ( kubelet / kube-proxy ) 21
Master (3) Master (2) etcd Master (1) Masterノードの構成 apiserver ▌Neco
では以下のように、Master ノードを冗⻑ • Master コンポーネントをセットで冗⻑化 • リバースプロキシ で、etcd / kube-apiserver へのアクセスをバランス 22 scheduler controller-manager リバプロ etcd apiserver etcd apiserver リバプロ リバプロ リバプロ リバプロ リバプロ scheduler controller-manager scheduler controller-manager
Master (3) Master (2) etcd Master (1) Masterノードのアップグレード apiserver ▌scheduler
と controller-manager はそれぞれリーダー選出 Ø⼀時的にコンポーネントがダウンしても、問題なし 23 scheduler controller-manager リバプロ etcd apiserver etcd apiserver リバプロ リバプロ リバプロ リバプロ リバプロ scheduler controller-manager scheduler controller-manager
Master (3) Master (2) etcd Master (1) Masterノードのアップグレード apiserver ▌etcd
と apiserver はリバースプロキシで宛先を調整 Øこちらも、⼀時的にコンポーネントがダウンしても、問題なし 24 scheduler controller-manager リバプロ etcd apiserver etcd apiserver リバプロ リバプロ リバプロ リバプロ リバプロ scheduler controller-manager scheduler controller-manager
Masterノードのアップグレード ▌Master ノードの冗⻑化 & リバースプロキシでの経路制御 • Master コンポーネントが⼀時的にダウンしても Kubernetes クラスタの管理に影響はない
ØMaster ノードを順番に更新していけばよい 25
Pod Workerノードの構成 ▌Neco の Workerノードの構成 • リバースプロキシで Masterノード (kube-apiserver) へのアクセスを調整
ØMaster が少しダウンしても問題なし 26 OS Worker ノード (たくさん) kube-proxy kubelet ipvs コンテナ コンテナ コンテナランタイム (containerd) コンテナ Pod リバプロ Master (1) Master (2) Master (3)
Pod Workerノードのアップグレード ▌Kubernetes 上でアプリケーションが動く、と⾔うけれど どちらかというと、横からから⼩突いている 27 OS Worker ノード (たくさん)
kube-proxy kubelet ipvs コンテナ コンテナ コンテナランタイム (containerd) コンテナ Pod リバプロ Master (1) Master (2) Master (3) 起動/終了/監視 ルーティング設定
Workerノードのアップグレード ▌Kubernetes コンポーネントと Pod は別プロセス • Kubernetes コンポーネントが⼀時的にダウンしても Pod の動作に直ちに影響はない
Øダウンタイムを最⼩限にして、Pod に影響がでる前に 新しい kubelet / kube-proxy に⼊れ替えればいい 28
Workerノードのアップグレード ▌CKE では Kubernetes コンポーネントを Docker で起動 • 新しいコンテナイメージを事前に Pull
• 折を⾒て再起動 Øコンポーネントの再起動は⼗数秒、すぐにアップグレード完了 アプリケーションへの影響もなく、ノードの⼊替も不要 29
In-place Upgrade の注意点 ▌ただし • アップグレード前後で、⾮互換の変更があった場合 単純な再起動では済まないケースがある • その場合は、⾃⼒で頑張るしかない ▌Neco
の場合は 1. CKE が⾃社製ツールのため、改修が容易 2. 仮想クラスタ & Stage環境 でアップグレード試験を実施 Øだから、In-place Upgrade にチャレンジできている 30
まとめ • Neco は Storage on Kubernetes • ⾃社製ツール CKE
で Kubernetes クラスタの In-place Upgrade を実現 Øアプリケーションへの影響を最⼩限に Kubernetes クラスタをアップグレードできる 31
補⾜スライド
ココ Pod のアップグレード OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes
管理ツール (CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌Neco のマネージドサービス (アプリケーションは管轄外) 33 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS)
Pod のアップグレード ▌Neco のマネージドサービス • Kubernetes 的なやり⽅で頑張る 34
こいつを OS のアップグレード OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes
管理ツール (CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌Sabakan によるプロビジョニング 35 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS) こいつが
OS のアップグレード ▌Sabakan によるプロビジョニング • Core OS をネットワークブート • Ignition
でノード別に設定をカスタマイズ Øノードを再起動するだけで、OS が新しくなる︕ ▌ただし、再起動の間は そのノード上で動くアプリケーションのタウンタイムが発⽣ Øデータの冗⻑化 & Pod の分散配置で対応 36
データの冗⻑化 & Pod の分散配置 ▌DB でクラスタを組み、データを冗⻑化 • Rook/Ceph、Elasticsearh、MySQL のクラスタ ▌ただ、それだけでは不⼗分
ØPod の配置に偏りがでるかもしれない ノード1 カン︕ 37 Pod data Pod data Pod data Pod data ノード2 ノード3 ノード4
データの冗⻑化 & Pod の分散配置 ▌Topology Spread Constraints (Kubernetes v1.16〜) •
複数の Failure domain に Pod を分散配置 Øノードを再起動しても問題なし、耐障害性も向上 ラック1 ラック2 ラック3 ラック4 ラック1がやられたようだな やつは最弱 38 data data data data
ココ ファームウェアのアップグレード OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes 管理ツール
(CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌ファームウェアアップグレードの⾃動化はこれから…… 39 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS)