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
PSIRTでAIテストを実施するまでの道のり
cybozuinsideout
PRO
0
67
無理なく続けるサイボウズの社内勉強会
cybozuinsideout
PRO
1
1k
分散システムにおける 無兆候データ破損の影響について
cybozuinsideout
PRO
1
38
タンパク質構造のシミュレーションソフトウェア試行錯誤
cybozuinsideout
PRO
1
31
読みやすいアセンブリ言語
cybozuinsideout
PRO
1
23
Wasmで拡張できる軽量マークアップ⾔語Brack(後編)
cybozuinsideout
PRO
1
20
Wasmで拡張できる軽量マークアップ⾔語Brack(前編)
cybozuinsideout
PRO
1
22
kintone開発組織のAWSエンジニアの紹介
cybozuinsideout
PRO
0
180
kintone開発組織のサービスプラットフォームチームの紹介
cybozuinsideout
PRO
0
92
Other Decks in Technology
See All in Technology
Software Architecture in an AI-Driven World
atty303
53
22k
正解のない未知(インボイス制度対応)をフルサイクル開発で乗り越える方法 / How to overcome the unknown invoice system with full cycle development
carta_engineering
0
160
Developer 以外にこそ使って欲しい Amazon Q Developer
mita
0
180
kernelvm-brain-net
raspython3
0
660
ホワイトボックス& SONiC アーキテクチャ(全体像) - SONiC Workshop Japan 2025
ebiken
PRO
1
350
Docker Compose で手軽に手元環境を実現する / Simplifying Local Environments with Docker Compose #CinemaDeLT
nabeo
0
260
チェックツールを導入したけど使ってもらえなかった話 #GAADjp
lycorptech_jp
PRO
0
130
経済メディア編集部の実務に小さく刺さるAI / small-ai-with-editorial
nkzn
2
500
250510 StepFunctionのテスト自動化始めました vol.1
east_takumi
1
260
Cursorをチョッパヤインタビューライターにチューニングする方法 / how to tuning cursor for interview write
shuzon
2
270
VitePress & MCPでアプリ仕様のオープン化に挑戦する
hal_spidernight
0
130
4月15日の AZ 障害をテクサポの中の人目線で振り返ってみる
kazzpapa3
3
180
Featured
See All Featured
Navigating Team Friction
lara
185
15k
VelocityConf: Rendering Performance Case Studies
addyosmani
329
24k
Fontdeck: Realign not Redesign
paulrobertlloyd
84
5.5k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
30
2.4k
How to Ace a Technical Interview
jacobian
276
23k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2k
Adopting Sorbet at Scale
ufuk
76
9.4k
Speed Design
sergeychernyshev
29
940
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
122
52k
4 Signs Your Business is Dying
shpigford
183
22k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
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)