Slide 1
Slide 1 text
プロダクションレディを⽬指した
Kubernetes クラスタのアップグレード戦略
Kubernetes Meetup Tokyo #29 / March 26, 2020
Shunya Murata @shmurata_
Slide 2
Slide 2 text
▶ アジェンダ
1. Kubernetes のアップグレードに必要な作業
2. Kubernetes のアップグレード戦略
3. アップグレードの⾃動化
2
Slide 3
Slide 3 text
Shunya Murata / @shmurata_
▶ ゼットラボ株式会社 ソフトウェアエンジニア
▶ 2010年にヤフー株式会社に新卒⼊社、2015年ゼットラボ株式会社に出向
3
Slide 4
Slide 4 text
▶ 前提条件
▶ ゼットラボ株式会社はヤフー株式会社の⼦会社です
+ ヤフーの次世代のインフラを設計・開発する会社として2015年に設⽴
▶ 今回の話はゼットラボがヤフーにKubernetesを導⼊して運⽤した際の話になり
ます
+ ヤフーでは現在300以上のKubernetesクラスタがあり、それをアップグレード
していく際に実施した内容になります
+ ⾃分の⽴場的にKubernetesの運⽤者というよりKubernetesを提供するプラッ
トフォームの管理者という⽴ち位置の視点の話なのでご了承ください
4
Slide 5
Slide 5 text
▶ このスライドの⾊の意味
▶ ⼀般的に実施しているであろう内容
▶ 社内で実施している内容
5
Slide 6
Slide 6 text
Kubernetes のアップグレードに必要
な作業
Slide 7
Slide 7 text
▶ Kubernetesのアップグレードの必要作業
▶ 準備
+ Kubernetesの変更点調査
+ テスト
+ アップグレード計画策定
+ リリースノート作成・周知
▶ 実施
+ クラスタのアップグレード
+ ストレージバージョンの更新
+ マニフェストの更新
7
Slide 8
Slide 8 text
▶ Kubernetes のリリースサイクルとサポート期間
▶ マイナーバージョンは3ヶ⽉に1回リリース
+ 年4回
▶ 公式のサポート期間は最新3マイナーバージョン
+ 3/26時点だと1.18, 1.17, 1.16
+ LTSは working group ができたが具体的な話までは進んでいないようです
+ https://github.com/kubernetes/community/tree/master/wg-lts
8
Slide 9
Slide 9 text
▶ Kubernetesの変更点調査(1/2)
▶ ChangeLog調査
+ https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG
+ Major Themes
+ Known Issues/Urgent Upgrade Notes
+ Deprecations and Removals/Metrics Changes/API Changes
+ Notable Features/Other notable changes
+ 現在だと巨⼤になり過ぎていて調査が⼤変
+ 複数⼈で専⾨分野を持って調査
+ Qiita で調査内容を公開中: https://qiita.com/shmurata/items/55acb85f60e5e8d19500
9
Slide 10
Slide 10 text
▶ Kubernetesの変更点調査(2/2)
▶ コンポーネントのパラメータ変更点調査
+ パラメータレベルでdiffをとって変更点をチェック
▶ API 変更点調査
+ APIリストのdiffをとって追加削除をチェック
+ https://github.com/zlabjp/kubernetes-scripts/blob/master/apiversion2resources
10
Slide 11
Slide 11 text
▶ Kubernetes 以外も更新していく必要がある
▶ OS
+ コンテナランタイム
+ CNI
▶ アドオン
+ CoreDNS
+ metrics-server
+ IngressController
+ Prometheus/Grafana/AlertManager
+ kube-state-metrics/node-exporter/blackbox-exporter
11
Slide 12
Slide 12 text
▶ Kubernetesのマイナーバージョンに合わせてまとめて更新
▶ すべて適宜更新することは⾼コスト
▶ 定期的に⾒直す機会作るように
+ Kubernetesマイナーバージョンに合わせてバージョンアップ
+ OSイメージにまとめてアップグレード
+ アドオン⼀式をまとめてコンテナにしてアップグレード
+ もちろん不具合修正などは適宜実施
12
Slide 13
Slide 13 text
▶ テスト
▶ Conformance test
+ Sonobuoy: https://github.com/vmware-tanzu/sonobuoy
+ 当時の使い勝⼿と更新タイミングの問題で独⾃にビルド
+ https://github.com/zlabjp/kube-conformance
▶ クラスタアップグレードの e2e
▶ アドオンの e2e
▶ ⻑期稼働試験
+ 全マイナーバージョンの検証クラスタを常時稼働
13
Slide 14
Slide 14 text
▶ アップグレード計画策定
▶ クラスタで動作しているアプリケーションを⽌めずに実施できるか？
▶ クラスタ全体を⽌めずに実施できるか？
▶ アップグレード前後に実施すべき内容があるか？
▶ ユーザへの影響があるか？
14
Slide 15
Slide 15 text
▶ リリースノート作成
▶ ユーザに影響のある部分のみ抜粋して社内限定のリリースノートを作成して公開
+ アップグレード前後に実施すべき内容があるか？
+ ユーザに影響がある変更点はあるか？
▶ マニフェストのlinterの更新
+ 設定すべき項⽬(resource.requests, probe など)
+ 廃⽌予定となったAPIバージョン
15
Slide 16
Slide 16 text
▶ マスターコンポーネントのアップグレード
▶ ノード のアップグレード
▶ アドオンのアップグレード
▶ マニフェストのアップグレード
16
▶ Kubernetesクラスタのアップグレード作業
Slide 17
Slide 17 text
▶ Kubernetesクラスタのアップグレードの細かい注意点(1/2)
▶ マスター < ノードにならないようにマスターから先にアップグレード
+ 詳しいコンポーネントバージョン間依存関係はこちらを
+ https://kubernetes.io/docs/setup/release/version-skew-policy/
+ すべての マスターのアップグレードが完了したらノードを
+ アップグレード中も依存関係を満たす必要がある
▶ マスターはマイナーバージョンをスキップするのはサポート外
+ ノードは2個下のマイナーバージョンまでサポート
+ ただし永続的に2バージョンまたぐのは⾮推奨と明記されている
+ https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-component-upgrade-order
17
Slide 18
Slide 18 text
▶ Kubernetesクラスタのアップグレードの細かい注意点(2/2)
▶ ストレージバージョンを上げる必要があることも
+ Etcd に保存されているリソースのスキーマのバージョン
+ update-storage-objects.sh
+ kube-storage-version-migrator
▶ Etcd も推奨バージョンがあるので合わせてアップグレード
+ https://kubernetes.io/docs/setup/release/notes/#dependencies
18
Slide 19
Slide 19 text
▶ ダウンタイムなくアップグレードするには
+ 安全なノードの削除(kubectl drain)
+ PodDisruptionBudget
+ Pod をグレースフルにダウンさせるには
+ プロダクションレディ Pods+
+ Kubernetes: 詳解 Pods の終了
▶ リソースを減らさないようにアップグレード
+ ノードを追加して削除を繰り返していく
+ ノードの数に⽐例して時間がかかる
Kubernetes Cluster Operator
ノード C
ノード B
ノード A
drain
追加
19
▶ Kubernetes ノードのアップグレード
Slide 20
Slide 20 text
アップグレード戦略
Slide 21
Slide 21 text
▶ Kubernetes クラスタのアップグレード要件
▶ アップグレード中の要件
+ サービス全体でダウンタイムが発⽣しない
+ 稼働中の全体リソースは減らない
+ Masterコンポーネントは極⼒ダウンタイムが発⽣しない
+ contorller-manager, scheduler などはリーダー交代中の停⽌は許容
▶ ローカルディスクの内容は保持しなくても良い
21
Slide 22
Slide 22 text
▶ Kubernetes クラスタのアップグレード戦略
▶ ライブアップグレード
▶ ブルーグリーンアップグレード
22
Slide 23
Slide 23 text
▶ ライブアップグレード
▶ サービス稼働中のクラスタをサービスインしたままアップグレードする⽅式
+ 新バージョンのノードを追加して動作確認が取れたら旧バージョンのノード
を削除する
+ 稼働したままアップグレードできるので運⽤コストを低くしやすい
+ ⼀度に追加するノード数(Surge) の数を増やせばその分リソースが必要になる
+ 1台 から100%まで
+ 数を増やせばアップグレードの速度は向上
23
Slide 24
Slide 24 text
▶ ライブアップグレード例(v1.17 -> v1.18)
24
v1.17ノード C
v1.17ノード B
v1.17ノード A
v1.17のノードグループ v1.18のノードグループ
Slide 25
Slide 25 text
▶ ライブアップグレード例(v1.17 -> v1.18)
25
v1.17ノード C
v1.17ノード B
v1.17ノード A
v1.17のノードグループ v1.18のノードグループ
v1.18ノード A’
Surge分(今回は1)だけ新バージョンのノードを追加
Slide 26
Slide 26 text
▶ ライブアップグレード例(v1.17 -> v1.18)
26
v1.17ノード C
v1.17ノード B
v1.17ノード A
v1.17のノードグループ v1.18のノードグループ
v1.18ノード A’
追加したノードが稼働したことを確認できたら旧バージョンのノードを削除
Slide 27
Slide 27 text
▶ ライブアップグレード例(v1.17 -> v1.18)
27
v1.17ノード C
v1.17ノード B
v1.17のノードグループ v1.18のノードグループ
v1.18ノード A’
v1.18ノード B’
同様に終わるまでSurgeの数だけ新バージョンのノードを追加
Slide 28
Slide 28 text
▶ ライブアップグレード例(v1.17 -> v1.18)
28
v1.17ノード C
v1.17ノード B
v1.17のノードグループ v1.18のノードグループ
v1.18ノード A’
v1.18ノード B’
追加したノードが稼働したことを確認できたら旧バージョンのノードを削除
Slide 29
Slide 29 text
▶ ライブアップグレード例(v1.17 -> v1.18)
29
v1.17ノード C
v1.17のノードグループ v1.18のノードグループ
v1.18ノード A’
v1.18ノード B’
v1.18ノード C’
同様に終わるまでSurgeの数だけ新バージョンのノードを追加
Slide 30
Slide 30 text
▶ ライブアップグレード例(v1.17 -> v1.18)
30
v1.17ノード C
v1.17のノードグループ v1.18のノードグループ
v1.18ノード A’
v1.18ノード B’
v1.18ノード C’
追加したノードが稼働したことを確認できたら旧バージョンのノードを削除
Slide 31
Slide 31 text
▶ ライブアップグレード例(v1.17 -> v1.18)
31
v1.17のノードグループ v1.18のノードグループ
v1.18ノード A’
v1.18ノード B’
v1.18ノード C’
すべてのノードがv1.18になりアップグレード完了
Slide 32
Slide 32 text
▶ ブルーグリーンアップグレード
▶ 既存のクラスタをアップグレードするのではなく新規にクラスタを構築して切
り替える⽅式
+ アップグレード後にマスターコンポーネントの不具合などがあった場合でも
ロールバックが容易
+ クラスタ2台分のリソースが必要
32
Slide 33
Slide 33 text
▶ ブルーグリーンアップグレード例(v1.17 -> v1.18)
33
v1.17ノード C
v1.17ノード B
v1.17ノード A
v1.17のクラスタ
LB
Slide 34
Slide 34 text
▶ ブルーグリーンアップグレード例(v1.17 -> v1.18)
34
v1.17ノード C
v1.17ノード B
v1.17ノード A
v1.17のクラスタ v1.18のクラスタ
v1.18ノード A’
v1.18ノード B’
v1.18ノード C’
LB
Slide 35
Slide 35 text
▶ ブルーグリーンアップグレード例(v1.17 -> v1.18)
35
v1.17ノード C
v1.17ノード B
v1.17ノード A
v1.17のクラスタ v1.18のクラスタ
v1.18ノード A’
v1.18ノード B’
v1.18ノード C’
LB
Slide 36
Slide 36 text
▶ ブルーグリーンアップグレード例(v1.17 -> v1.18)
36
v1.18のクラスタ
v1.18ノード A’
v1.18ノード B’
v1.18ノード C’
LB
Slide 37
Slide 37 text
▶ Kubernetes クラスタのアップグレード戦略まとめ
37
҆શੑ Ϧιʔε ӡ༻ίετ
ϥΠϒΞοϓάϨʔυ ˚
Ϛελʔίϯϙʔωϯτ
+
ϊʔυ * (N + surge)
̋
ϒϧʔάϦʔϯΞοϓάϨʔυ ̋
Ϛελʔίϯϙʔωϯτ * 2
+
ϊʔυ * 2 * N
˚
Slide 38
Slide 38 text
▶ マネージドサービスのクラスタアップグレード
▶ ドキュメントを⾒た限りでは以下のマネージドサービスも同様の⽅式でアップ
グレードをサポート
+ 注意：実際に試したわけではないため詳細は以下のドキュメントを参照下さ
い
▶ GKE: https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-upgrades
▶ EKS: https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/update-cluster.html
▶ AKS: https://docs.microsoft.com/ja-jp/azure/aks/upgrade-cluster
38
Slide 39
Slide 39 text
▶ Z Lab / Yahoo! JAPAN の例
▶ ほぼライブアップグレードのみ
+ Kubernetes ⾃体のアップグレードが原因で事故になったことはない
+ メトリクス名の変更でアラートが上がらないとかはあった
+ ノードのローリングアップデートがトリガーになって発⽣する事故は多々あ
る
+ 基本的にはプロダクションレディなPodになっていないことが多かった
+ ⽉⼀回程度ノードのローリングアップデートを実施するようにしているの
でユーザが徐々に慣れてきている
+ グレースフルシャットダウンのノウハウも溜まってきている
+ クラスタ⾃体よりアドオンの更新のほうが事故になる
+ Ingress controller / CoreDNS
39
Slide 40
Slide 40 text
▶ ライブアップグレードで発覚している問題点と対応
▶ Podの無駄な移動が発⽣することがある
+ ノードの削除時に削除予定のノードにスケジュールされると2回移動すること
に
+ 削除予定のノードにTaintsを付与してスケジュールされにくく
▶ アップグレードの時間がかかる
+ ノード数が多いとその分時間がかかる
+ Surgeの調整
+ ⼀⻫にアップグレードが発⽣するとアップグレードがスタックする
+ IaaS 側が詰まってしまう
+ IaaSのパフォーマンス向上を検討中
40
Slide 41
Slide 41 text
アップグレードの⾃動化
Slide 42
Slide 42 text
▶ クラスタのアップデート作業の⾃動化
▶ ノードの更新
+ https://kccncna19.sched.com/event/UaYz/handling-risky-business-cluster-
upgrades-puneet-pruthi-lyft
+ Kubernetes Cluster Operator
▶ アドオンの更新
+ addon-manager
+ addon-managerに渡すアドオンのマニフェストをパッケージ化して配布
+ ⾃作コントローラで Kubernetes のバージョンに応じて⾃動配布
▶ ストレージバージョンの更新
+ ⾃作コントローラでマイナーバージョンの更新に対応して⾃動実⾏
42
Slide 43
Slide 43 text
▶ Kubernetes Cluster Operator
▶ Kubernetes クラスタを管理する Operator
+ クラスタの作成、削除、更新を⾃動化
+ アップグレードコストの最⼩化を⽬的に開発
▶ 過去の発表
+ https://speakerdeck.com/shmurata/how-we-accomplish-noops-by-kubernetes-operator
+ https://speakerdeck.com/shmurata/thirdpartyresource-woshi-tuta-kubernetes-as-a-
service-falseshi-zhuang
43
Slide 44
Slide 44 text
▶ アドオンの管理
▶ addon-manager
+ https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/
addon-manager
+ 指定されたディレクトリに配置されたマニフェストを apply し続ける
+ prune もするのでディレクトリのマニフェストを削除すればリソースも削
除される
▶ addon-updater
+ addon-manager が参照するディレクトリにあるマニフェストを⾃動更新する
⾃作コントローラ
+ すべてのマスターノードのバージョンが⼀致したらそのバージョンに合わせて
アドオンのマニフェストを更新する
44
Slide 45
Slide 45 text
▶ ストレージバージョンの更新
▶ update-storage-objects.sh
+ ストレージバージョンを更新するためにすべてのオブジェクト更新し直すス
クリプト
+ 公式ではもう削除されてしまった。。。
+ https://github.com/kubernetes/kubernetes/pull/83969
+ 後継(kube-storage-version-migrator)が作られているがまだ alpha?
▶ uso-runner
+ https://github.com/zlabjp/update-storage-objects を⾃動的に実⾏する⾃作コ
ントローラ
+ すべてのマスターノードのバージョンが⼀致したら update-storage-
objects.sh を実⾏する
45
Slide 46
Slide 46 text
▶ 導⼊してみた効果
▶ アップグレードコストの最⼩化により健全な状態を維持できている
+ 全クラスタサポートバージョン範囲内(1.16以上)
▶ 300以上オンプレでのKubernetes クラスタの運⽤と提供のコスト削減
+ 開発、運⽤、サポート、教育で20から30名程度でできるように
▶ OS移⾏やIaaSのアップグレードなども利⽤者に⼤きな影響を与えることなく実
施できるようになった
+ クラスタのスケールアップなども容易に
▶ オペレーションミスによる障害はほとんど発⽣していない
46
Slide 47
Slide 47 text
まとめ
Slide 48
Slide 48 text
▶ まとめ
▶ Kubernetes のアップグレード
+ 定期的なアップグレードが必須
+ Kubernetes以外もあるので定期的にチェックして更新する体制を
▶ アップグレード戦略
+ ⾊んな⽅法があるが⼀⻑⼀短
+ 環境や要件に合わせて選ぶとよい
▶ ⾃動化
+ ⼤規模になってくるとほぼ必須
+ オペレーションミスを防ぐためにもコストに⾒合うなら実施を推奨
+ Operatorパターンを利⽤すると容易に安定した⾃動化が実現できる
48