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

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

6ee833afddca37209631fb25a0cec547?s=128

Shunya Murata

March 26, 2020
Tweet

Transcript

  1. 4.

    ▶ 前提条件 ▶ ゼットラボ株式会社はヤフー株式会社の⼦会社です + ヤフーの次世代のインフラを設計・開発する会社として2015年に設⽴ ▶ 今回の話はゼットラボがヤフーにKubernetesを導⼊して運⽤した際の話になり ます +

    ヤフーでは現在300以上のKubernetesクラスタがあり、それをアップグレード していく際に実施した内容になります + ⾃分の⽴場的にKubernetesの運⽤者というよりKubernetesを提供するプラッ トフォームの管理者という⽴ち位置の視点の話なのでご了承ください 4
  2. 7.

    ▶ Kubernetesのアップグレードの必要作業 ▶ 準備 + Kubernetesの変更点調査 + テスト + アップグレード計画策定

    + リリースノート作成・周知 ▶ 実施 + クラスタのアップグレード + ストレージバージョンの更新 + マニフェストの更新 7
  3. 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
  4. 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
  5. 10.

    ▶ Kubernetesの変更点調査(2/2) ▶ コンポーネントのパラメータ変更点調査 + パラメータレベルでdiffをとって変更点をチェック ▶ API 変更点調査 +

    APIリストのdiffをとって追加削除をチェック + https://github.com/zlabjp/kubernetes-scripts/blob/master/apiversion2resources 10
  6. 11.

    ▶ Kubernetes 以外も更新していく必要がある ▶ OS + コンテナランタイム + CNI ▶

    アドオン + CoreDNS + metrics-server + IngressController + Prometheus/Grafana/AlertManager + kube-state-metrics/node-exporter/blackbox-exporter 11
  7. 13.

    ▶ テスト ▶ Conformance test + Sonobuoy: https://github.com/vmware-tanzu/sonobuoy + 当時の使い勝⼿と更新タイミングの問題で独⾃にビルド

    + https://github.com/zlabjp/kube-conformance ▶ クラスタアップグレードの e2e ▶ アドオンの e2e ▶ ⻑期稼働試験 + 全マイナーバージョンの検証クラスタを常時稼働 13
  8. 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
  9. 18.

    ▶ Kubernetesクラスタのアップグレードの細かい注意点(2/2) ▶ ストレージバージョンを上げる必要があることも + Etcd に保存されているリソースのスキーマのバージョン + update-storage-objects.sh +

    kube-storage-version-migrator ▶ Etcd も推奨バージョンがあるので合わせてアップグレード + https://kubernetes.io/docs/setup/release/notes/#dependencies 18
  10. 19.

    ▶ ダウンタイムなくアップグレードするには + 安全なノードの削除(kubectl drain) + PodDisruptionBudget + Pod をグレースフルにダウンさせるには

    + プロダクションレディ Pods+ + Kubernetes: 詳解 Pods の終了 ▶ リソースを減らさないようにアップグレード + ノードを追加して削除を繰り返していく + ノードの数に⽐例して時間がかかる Kubernetes Cluster Operator ノード C ノード B ノード A drain 追加 19 ▶ Kubernetes ノードのアップグレード
  11. 21.

    ▶ Kubernetes クラスタのアップグレード要件 ▶ アップグレード中の要件 + サービス全体でダウンタイムが発⽣しない + 稼働中の全体リソースは減らない +

    Masterコンポーネントは極⼒ダウンタイムが発⽣しない + contorller-manager, scheduler などはリーダー交代中の停⽌は許容 ▶ ローカルディスクの内容は保持しなくても良い 21
  12. 25.

    ▶ ライブアップグレード例(v1.17 -> v1.18) 25 v1.17ノード C v1.17ノード B v1.17ノード

    A v1.17のノードグループ v1.18のノードグループ v1.18ノード A’ Surge分(今回は1)だけ新バージョンのノードを追加
  13. 26.

    ▶ ライブアップグレード例(v1.17 -> v1.18) 26 v1.17ノード C v1.17ノード B v1.17ノード

    A v1.17のノードグループ v1.18のノードグループ v1.18ノード A’ 追加したノードが稼働したことを確認できたら旧バージョンのノードを削除
  14. 27.

    ▶ ライブアップグレード例(v1.17 -> v1.18) 27 v1.17ノード C v1.17ノード B v1.17のノードグループ

    v1.18のノードグループ v1.18ノード A’ v1.18ノード B’ 同様に終わるまでSurgeの数だけ新バージョンのノードを追加
  15. 28.

    ▶ ライブアップグレード例(v1.17 -> v1.18) 28 v1.17ノード C v1.17ノード B v1.17のノードグループ

    v1.18のノードグループ v1.18ノード A’ v1.18ノード B’ 追加したノードが稼働したことを確認できたら旧バージョンのノードを削除
  16. 29.

    ▶ ライブアップグレード例(v1.17 -> v1.18) 29 v1.17ノード C v1.17のノードグループ v1.18のノードグループ v1.18ノード

    A’ v1.18ノード B’ v1.18ノード C’ 同様に終わるまでSurgeの数だけ新バージョンのノードを追加
  17. 30.

    ▶ ライブアップグレード例(v1.17 -> v1.18) 30 v1.17ノード C v1.17のノードグループ v1.18のノードグループ v1.18ノード

    A’ v1.18ノード B’ v1.18ノード C’ 追加したノードが稼働したことを確認できたら旧バージョンのノードを削除
  18. 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
  19. 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
  20. 37.

    ▶ Kubernetes クラスタのアップグレード戦略まとめ 37 ҆શੑ Ϧιʔε ӡ༻ίετ ϥΠϒΞοϓάϨʔυ ˚ Ϛελʔίϯϙʔωϯτ

    + ϊʔυ * (N + surge) ̋ ϒϧʔάϦʔϯΞοϓάϨʔυ ̋ Ϛελʔίϯϙʔωϯτ * 2 + ϊʔυ * 2 * N ˚
  21. 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
  22. 39.

    ▶ Z Lab / Yahoo! JAPAN の例 ▶ ほぼライブアップグレードのみ +

    Kubernetes ⾃体のアップグレードが原因で事故になったことはない + メトリクス名の変更でアラートが上がらないとかはあった + ノードのローリングアップデートがトリガーになって発⽣する事故は多々あ る + 基本的にはプロダクションレディなPodになっていないことが多かった + ⽉⼀回程度ノードのローリングアップデートを実施するようにしているの でユーザが徐々に慣れてきている + グレースフルシャットダウンのノウハウも溜まってきている + クラスタ⾃体よりアドオンの更新のほうが事故になる + Ingress controller / CoreDNS 39
  23. 40.

    ▶ ライブアップグレードで発覚している問題点と対応 ▶ Podの無駄な移動が発⽣することがある + ノードの削除時に削除予定のノードにスケジュールされると2回移動すること に + 削除予定のノードにTaintsを付与してスケジュールされにくく ▶

    アップグレードの時間がかかる + ノード数が多いとその分時間がかかる + Surgeの調整 + ⼀⻫にアップグレードが発⽣するとアップグレードがスタックする + IaaS 側が詰まってしまう + IaaSのパフォーマンス向上を検討中 40
  24. 42.

    ▶ クラスタのアップデート作業の⾃動化 ▶ ノードの更新 + https://kccncna19.sched.com/event/UaYz/handling-risky-business-cluster- upgrades-puneet-pruthi-lyft + Kubernetes Cluster

    Operator ▶ アドオンの更新 + addon-manager + addon-managerに渡すアドオンのマニフェストをパッケージ化して配布 + ⾃作コントローラで Kubernetes のバージョンに応じて⾃動配布 ▶ ストレージバージョンの更新 + ⾃作コントローラでマイナーバージョンの更新に対応して⾃動実⾏ 42
  25. 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
  26. 44.

    ▶ アドオンの管理 ▶ addon-manager + https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/ addon-manager + 指定されたディレクトリに配置されたマニフェストを apply

    し続ける + prune もするのでディレクトリのマニフェストを削除すればリソースも削 除される ▶ addon-updater + addon-manager が参照するディレクトリにあるマニフェストを⾃動更新する ⾃作コントローラ + すべてのマスターノードのバージョンが⼀致したらそのバージョンに合わせて アドオンのマニフェストを更新する 44
  27. 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
  28. 46.

    ▶ 導⼊してみた効果 ▶ アップグレードコストの最⼩化により健全な状態を維持できている + 全クラスタサポートバージョン範囲内(1.16以上) ▶ 300以上オンプレでのKubernetes クラスタの運⽤と提供のコスト削減  +

    開発、運⽤、サポート、教育で20から30名程度でできるように ▶ OS移⾏やIaaSのアップグレードなども利⽤者に⼤きな影響を与えることなく実 施できるようになった + クラスタのスケールアップなども容易に ▶ オペレーションミスによる障害はほとんど発⽣していない 46
  29. 47.
  30. 48.

    ▶ まとめ ▶ Kubernetes のアップグレード + 定期的なアップグレードが必須 + Kubernetes以外もあるので定期的にチェックして更新する体制を ▶

    アップグレード戦略 + ⾊んな⽅法があるが⼀⻑⼀短 + 環境や要件に合わせて選ぶとよい ▶ ⾃動化 + ⼤規模になってくるとほぼ必須 + オペレーションミスを防ぐためにもコストに⾒合うなら実施を推奨 + Operatorパターンを利⽤すると容易に安定した⾃動化が実現できる 48