CKE で始める！はじめての Kubernetes クラスタインプレースアップグレード

by Cybozu

Slide 1

Slide 1 text

Maneki & Neco Meetup CKE で始める︕ はじめての Kubernetes クラスタインプレースアップグレード 2020-02-18 サイボウズ株式会社⽯井正將 (masa213f)

Slide 2

Slide 2 text

発表タイトルについてのお詫び ▌チュートリアル的なタイトルですがチュートリアルではありません ▌Neco で実現している Kubernetes クラスタのアップグレード⽅法の説明になります 1

Slide 3

Slide 3 text

⾃⼰紹介 ▌サイボウズ⼤阪オフィス勤務 • OSや仮想化に興味があったエンジニア ▌経歴 • 前職では、電機メーカーでOS・仮想化の開発 • 2018/09 サイボウズキャリア⼊社 • 2019/03 運⽤本部インフラ刷新プロジェクト Neco へ異動 2

Slide 4

Slide 4 text

質問 ▌Kubernetes v1.17 がリリースされました。あなたの環境では Kubernetes v1.16 を使っています。どうやって、Kubernetes クラスタを更新しますか︖ 3 ▌よく聞く⽅法 1. クラスタを新しく⽤意して、丸ごと引っ越し 2. ノードを順番に更新して、ローリングアップグレード

Slide 5

Slide 5 text

⽅法1: 丸ごと引っ越し ▌クラスタを新しく⽤意して、丸ごと引越し Old 4 New! App App App

Slide 6

Slide 6 text

⽅法2: ローリングアップグレード ▌ノードを順番に更新し、ローリングアップグレード 5 App App App App App App App App Old Old Old Old

Slide 7

Slide 7 text

⽅法2: ローリングアップグレード 1. 更新したいノードを kubectl drain ØPod が退去 (evict) & そのノードへの Pod の配置が停⽌ 6 App App App App App App Old Old Old Old App App 更新したい kubectl drain

Slide 8

Slide 8 text

⽅法2: ローリングアップグレード 2. ノードの更新 7 App App App App App App Old Old Old Old⇨New App App Pod動きません

Slide 9

Slide 9 text

⽅法2: ローリングアップグレード 3. ノードの更新が終わったら kubectl uncordon Øノード上で Pod が動作可能になる 8 App App App App App App Old Old Old New App App Kubectl uncordon

Slide 10

Slide 10 text

⽅法2: ローリングアップグレード 9 App App App App Old Old Old New App App App App kubectl drain ▌これをノードの数だけ繰り返す • アプリケーションはいずれかのノード上で動作 Øサービス無停⽌で更新できる

Slide 11

Slide 11 text

これらの⽅法 ▌⽅法1、2はノードのローカルストレージにデータが保存されていない場合はうまくいく ▌Neco の Kubernetes クラスタは少し事情が異なる Ø⾃社製 Kubernetes 管理ツール CKE で In-place Upgrade 10

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Neco のアップグレード要件 ▌Neco の Kubernetes には⼤量のデータ • アップグレードの度にサーバ間 and/or クラスタ間でデータのコピーはしたくない (ネットワークの負荷も上がるし、ディスクの寿命も縮まる) 13

Slide 15

Slide 15 text

Neco のアップグレード要件 ▌Neco の Kubernetes には⼤量のデータ • kubectl drain で Pod を退去するとデータのコピーが不可避 Ø数千台のノードで、データをキャッチボールことに…… 14 data data Pod Pod ⼼機⼀転︕ 頑張るぞ︕ データも送るよー︕ kubectl drain data data データないっす⾃分も空っす Old Old Old⇨New

Slide 16

Slide 16 text

Neco のアップグレード要件 ▌クラスタのアップグレードでアプリケーションを⽌めたくない • 好きなタイミングで、⾃由に更新したい (夜は寝ていたい) 15

Slide 17

Slide 17 text

Neco のアップグレード要件 ▌Kubernetes は 3ヶ⽉に1度マイナーアップデート • 陳腐化を防ぐために、追従していきたい Ø数千台のノードを、 3ヶ⽉毎に更新…… 16

Slide 18

Slide 18 text

Neco のアップグレード要件 ▌まとめると 1. Eviction-free な In-place Upgrade • クラスタの作り直しなし • ノードの⼊替なし • Pod の退去 (evict) なし 2. 加えて、(できるだけ) クラスタ無停⽌ 3. さらに加えて、(頻度が⾼いので) ⾃動化したい 17

Slide 19

Slide 19 text

Neco の構成 OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes 管理ツール (CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌ざっくりとこんな構成 Neco Maneki + 製品開発チーム 18 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS)

Slide 20

Slide 20 text

どこをアップグレードしたい︖ ▌⼤まかに分類すると4種類 1. Pod (Kubernetes ワークロード) • マネージドサービス 2. Kubernetes • Kubernetes コンポーネント 3. OS 4. (サーバの) ファームウェア 19 今⽇はココの説明

Slide 21

Slide 21 text

こいつを Kubernetes のアップグレード OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes 管理ツール (CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌CKE で更新する 20 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS) こいつが

Slide 22

Slide 22 text

Kubernetes の構成 ▌⼤きく分けると2種類のノード 1. Masterノード (3〜7台) • クラスタ全体を管理 (etcd / kube-apiserver / kube-scheduler / kube-controller-manager ) 2. Workerノード (たくさん) • アプリケーション (Pod) の実⾏環境 ( kubelet / kube-proxy ) 21

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

Masterノードのアップグレード ▌Master ノードの冗⻑化 & リバースプロキシでの経路制御 • Master コンポーネントが⼀時的にダウンしても Kubernetes クラスタの管理に影響はない ØMaster ノードを順番に更新していけばよい 25

Slide 27

Slide 27 text

Pod Workerノードの構成 ▌Neco の Workerノードの構成 • リバースプロキシで Masterノード (kube-apiserver) へのアクセスを調整 ØMaster が少しダウンしても問題なし 26 OS Worker ノード (たくさん) kube-proxy kubelet ipvs コンテナコンテナコンテナランタイム (containerd) コンテナ Pod リバプロ Master (1) Master (2) Master (3)

Slide 28

Slide 28 text

Pod Workerノードのアップグレード ▌Kubernetes 上でアプリケーションが動く、と⾔うけれどどちらかというと、横からから⼩突いている 27 OS Worker ノード (たくさん) kube-proxy kubelet ipvs コンテナコンテナコンテナランタイム (containerd) コンテナ Pod リバプロ Master (1) Master (2) Master (3) 起動／終了／監視ルーティング設定

Slide 29

Slide 29 text

Workerノードのアップグレード ▌Kubernetes コンポーネントと Pod は別プロセス • Kubernetes コンポーネントが⼀時的にダウンしても Pod の動作に直ちに影響はない Øダウンタイムを最⼩限にして、Pod に影響がでる前に新しい kubelet / kube-proxy に⼊れ替えればいい 28

Slide 30

Slide 30 text

Workerノードのアップグレード ▌CKE では Kubernetes コンポーネントを Docker で起動 • 新しいコンテナイメージを事前に Pull • 折を⾒て再起動 Øコンポーネントの再起動は⼗数秒、すぐにアップグレード完了アプリケーションへの影響もなく、ノードの⼊替も不要 29

Slide 31

Slide 31 text

In-place Upgrade の注意点 ▌ただし • アップグレード前後で、⾮互換の変更があった場合単純な再起動では済まないケースがある • その場合は、⾃⼒で頑張るしかない ▌Neco の場合は 1. CKE が⾃社製ツールのため、改修が容易 2. 仮想クラスタ & Stage環境でアップグレード試験を実施 Øだから、In-place Upgrade にチャレンジできている 30

Slide 32

Slide 32 text

まとめ • Neco は Storage on Kubernetes • ⾃社製ツール CKE で Kubernetes クラスタの In-place Upgrade を実現 Øアプリケーションへの影響を最⼩限に Kubernetes クラスタをアップグレードできる 31

Slide 33

Slide 33 text

補⾜スライド

Slide 34

Slide 34 text

ココ Pod のアップグレード OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes 管理ツール (CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌Neco のマネージドサービス (アプリケーションは管轄外) 33 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS)

Slide 35

Slide 35 text

Pod のアップグレード ▌Neco のマネージドサービス • Kubernetes 的なやり⽅で頑張る 34

Slide 36

Slide 36 text

こいつを OS のアップグレード OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes 管理ツール (CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌Sabakan によるプロビジョニング 35 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS) こいつが

Slide 37

Slide 37 text

OS のアップグレード ▌Sabakan によるプロビジョニング • Core OS をネットワークブート • Ignition でノード別に設定をカスタマイズ Øノードを再起動するだけで、OS が新しくなる︕ ▌ただし、再起動の間はそのノード上で動くアプリケーションのタウンタイムが発⽣ Øデータの冗⻑化 & Pod の分散配置で対応 36

Slide 38

Slide 38 text

データの冗⻑化 & Pod の分散配置 ▌DB でクラスタを組み、データを冗⻑化 • Rook/Ceph、Elasticsearh、MySQL のクラスタ ▌ただ、それだけでは不⼗分 ØPod の配置に偏りがでるかもしれないノード1 カン︕ 37 Pod data Pod data Pod data Pod data ノード2 ノード3 ノード4

Slide 39

Slide 39 text

データの冗⻑化 & Pod の分散配置 ▌Topology Spread Constraints (Kubernetes v1.16〜) • 複数の Failure domain に Pod を分散配置 Øノードを再起動しても問題なし、耐障害性も向上ラック1 ラック2 ラック3 ラック4 ラック1がやられたようだなやつは最弱 38 data data data data

Slide 40

Slide 40 text

ココファームウェアのアップグレード OS (Ubuntu) 管理サーバ (3〜5台) サーバ管理ツール (Sabakan) Kubernetes 管理ツール (CKE) Kubernetes ノード (数千台規模) マネージドサービス (ロードバランサー、モニタリング、データベースなど) ▌ファームウェアアップグレードの⾃動化はこれから…… 39 OS (CoreOS) アプリケーション (サイボウズ製品) サーバ (CS) サーバ (CS) サーバ (SS) サーバ (SS) OS (CoreOS) OS (CoreOS) OS (CoreOS)