プロダクションレディを目指した Kubernetes クラスタのアップグレード戦略/Strategy to upgrade Kubernetes clusters in Production

Transcript

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