そのクラスタ本当にアップグレードして大丈夫？ Storage Version の更新も忘れずにしよう！ / k8s-storage-version-migration

Transcript

1. Shinya Uemura @uesyn そのクラスタ本当にアップグレードして⼤丈夫？ Storage Version の更新も忘れずにしよう！
2. Shinya Uemura / @uesyn ▶ ゼットラボ株式会社 ソフトウェアエンジニア ▶ Prometheus Meetup Tokyo, Cloud Native Meetup Tokyo Organizer 2
3. ゼットラボ株式会社 / Z Lab Corporation ▶ 2015年に設⽴されたヤフー株式会社の100%⼦会社 ▶ インフラ基盤技術の調査・研究開発 ▶ ヤフー株式会社向けのマネージド Kubernetes サービスの開発 ▶ https://zlab.co.jp/
4. Kubernetesクラスタのアップグレード ▶ 公式ページのCluster Management + https://kubernetes.io/docs/tasks/administer-cluster/cluster-management ▶ Advanced Topicsには以下の記載
5. Kubernetesのリソースの保存・読み込み Request Version apps/v1beta1 etcd API Server apps/v1 apps/v1beta1 apps/v1beta2 extentions/v1beta1 Internal Version apps/v1 Storage Version ΁ม׵ ▶ 保存: RequestされたVersionをAPI ServerがInternal Version → Storage Versionと変換され保存 + 保存されるVersionはRequestのVersionとは関係ない ▶ 読み込み: API Serverがetcdからデータを取得しDecode + API ServerがDecodeできないVersionで保存されていると…
6. 対応していないStorage Versionが保存されている場合 ▶ 例えばKubernetesのUpgradeが続きかつ、そのリソースが更新されない場合など ▶ ref: https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/0030-storage-migration.md อଘ͞Ε͍ͯΔStorage Versionͷ ϚΠάϨʔγϣϯ͕ඞཁ!!!
7. Storage Version の Migration ~K8s 1.16までの⽅法~ ▶ 1.16まではk/k repo にマイグレーション⽤スクリプトが存在 + https://github.com/kubernetes/kubernetes/blob/release-1.16/cluster/update-storage-objects.sh + リソースリスト(固定)のnamespace, resourceを 全て kubectl get → kubectl replace ▶ 1.17からメンテされてないため削除されてしまった(https://github.com/kubernetes/kubernetes/issues/69299) ▶ kubectl replaceでは、last-applied-configurationを変更するため発⽣する問題がある + https://github.com/kubernetes/kubernetes/issues/60970 + 回避策として以下のコマンドが利⽤可能 + https://github.com/zlabjp/update-storage-objects/blob/master/cmd/kput/main.go update-storage-objects.sh
8. Storage Version Hash ▶ API Serverが保存するリソースのStorage Versionをハッシュとして表現したもの + v1.14からalpha, v1.15からbetaへ ▶ API Serverが保存するAPIのStorage Versionが”変更されたこと”を検知するために利⽤できる + 値から新しいStorage Versionが使われているかどうかは判別できない ▶ 実際にetcdに保存されているリソースのStorage Versionの値ではないことに注意！
9. Storage Version Hashを確認したい ▶ APIを叩く + 例: kubectl get --raw /apis/apps/v1 ▶ テスト⽤コードから確認 + https://github.com/kubernetes/kubernetes/blob/master/pkg/master/storageversionhashdata/data.go { "kind": "APIResourceList", "apiVersion": "v1", "groupVersion": "apps/v1", "resources": [ ... { "name": "deployments", .... "storageVersionHash": "8aSe+NMegvE=" }, ... ] }
10. Storage Version Hashを利⽤したマイグレーション ▶ Storage Version Hashを利⽤したコントローラ + https://github.com/kubernetes-sigs/kube-storage-version-migrator + API Serverから公開されているStorage Version Hashの変更を検知しマイグレーションする + 現在alpha? beta? ▶ update-storage-objects.shとの違い + ⾃動実⾏される ( Masterサーバが冗⻑構成かつライブアップグレードする場合は注意が必要 ※1 ) + リソースのリストはDiscoveryされるため, リソースリストのメンテナンスは不要 + 変更が必要なリソースのみマイグレーションされる ※2 kube-storage-version-migrator ※1: Storage Versionͷߋ৽͸৽͍͠Masterαʔό΁ϦΫΤετ͕ಧ͘ඞཁ͕͋Δ ɹɹΞοϓάϨʔυதɺMasterαʔό͕ࠞࡏ͍ͯ͠Δ࣌͸ɺ৽چͲͪΒ΁ܨ͕Δ͔Θ͔Βͳ͍ͨΊ ※2: etcdͷத਎Λ௚઀ΞΫηε͠มߋ͕ඞཁ͔֬ೝ͍ͯ͠ΔΘ͚Ͱ͸ͳ͍ ͋͘·ͰStorage Version HashͷมߋΛ֬ೝ͍ͯ͠Δ͚ͩ
11. まとめ ▶ Kubernetes は etcdにリソースを保存する際に決まったVersionで保存する + これをStorage Versionと呼ぶ ▶ Storage Versionのマイグレーションには新しいAPI Server経由でetcdへ再度書き込む必要がある + 単純な操作だとkubectl get & kubectl replace + last-applied-configurationの扱いには気を付ける ▶ マイグレーションに便利なスクリプト・ツールが存在 + update-storage-objects.sh + 1.17で削除されたが、簡単なスクリプトなためメンテナンスコストは少なそう + kube-storage-version-migrator + まだProduction Readyではないが、動作することは確認できる + Master構成の冗⻑化の⽅法によっては注意が必要