2020-03-26 Kubernetes Meetup Tokyo #29 Cluster Upgrade 編 #k8sjp
2020/03/26 に開催された Kubernetes Meetup Tokyo #29 Cluster Upgrade 編 のイベントレポートです。
■クラスタの引っ越しによるサービス無停止アップデート
Atsushi Tanaka さん [Wantedly, Inc.]
●wantedly
・すべてのサービスをkubernetesで運用
・AWS EC2上にkopsで
・2016年から本番運用
●アップグレード戦略
・まず in-place upgrade を試す
・サービスダウンが発生する場合は cluster migration
●アップグレード方法の比較
・in-place upgrade
既存のクラスタでin-place
ノードをrolling update
・cluster migration
新しいクラスタでblue/green deploy
リソースをコピー
●アップグレード方法の特徴
・in-place upgrade
各クラウドベンダーのAPIやツールが用意されている
1minor versionしか上げられない
・cluster migration
ツールの恩恵を受けられない
複数クラスタでの運用の考慮が必要
バージョンを飛ばすこともできる
コアコンポーネントの入れ替えもできる
●in-place upgradeが実施できなかった例
・kubernetesのバグ
masterの入れ替えですべてのnodeがNotReadyになる
古いmasterにhealth checkを送り続けていたnodeが多数
patchを当てる必要があった
・etcdのバージョン上げ
v2→v3へのアップグレードはk8sがサポートしていない
kopsが用意したetcdのmigration pathがうまく動かなかった
in-place を試したらkubednsが不安定になった
●kubernetesをアップグレードする理由
・バグや脆弱性の修正
・新機能を使いたい
・サポートされているバージョンを使いたい
●サポートされるバージョン
・最新リリースから3 minor version
・9ヶ月経ったらサポートされなくなる
→頻繁なアップグレードが必要
●cluster migrationの手順
・新クラスタを作成
・新クラスタにリソースを移行
リストアで実施している
・新クラスタにトラフィックを切り替え
動作確認できたら
・旧クラスタを削除
●kubernetes 8 factors
・cloudnative daysで発表
・記事も公開
→cluster migrationに絞ると5つ
●Cluster migrationの原則
・クラスタをコード間
・動作確認の省力化
・非名前管理
・バックアップ
・重複欠損管理
●クラスタをコード管理
・互換性がない場合変更が大きい
クラスタの作成を楽にしたい
・クラスタの設定、作成もコード化
・環境ごとの差分は明示的に比較できるように
●動作確認の省力化
・ツールの恩恵が受けられない
・検証環境との差異をできるだけ減らす
本番でしか起きない問題を減らす
・クラスタへの変更はコードを元にする
意図しないリソースの変更を検知
●非名前管理
・複数クラスタの運用を考慮する場合
クラスタ名が同じだと識別できない
別の名前で立てることになる
監視やアラートも新しいクラスタ向けに必要
ロールバックをしやすく
・同一要素のリソースが複数立てられることを想定
production
本番で複数クラスタだったら？
production-20200326
同じ日に複数のクラスタを立てることはない
・直接名前を参照しない
ユーザに見える場所はCNAME
ロールバックしやすく
labelやtagで指定
Datadogの監視
env:productionなどのタグで回避
→datadogの変更は不要に
●バックアップ
・クラスタのリストアに必要なリソースが全て入ったバックアップ
・veleroを利用している
●重複欠損管理
・重複と欠損
重複：名前が同じ
欠損：ダウンダイムが起きた
・複数クラスタでの運用の副作用を減らす
重複を許容できない場合は、専用の手順が必要
どちらかは許容できるように設計
・重複を許容しないリソースの例
CronJob
800くらいのjobが存在
チェックが大変なので、ルールで
欠損を許容
実行されないケースを許容させる
・重複と欠損の両方を許容しないリソースの例
RDB × stateful set
そもそもkubernetesでは管理しない
●実際のcluster migration手順
・新クラスタを作成
・重複を許容するリソースを新クラスタにリストア
重要なリソースが入っている
・重複を許容しないリソースを旧クラスタから削除
これで、欠損は発生するが、重複は起きない
・重複を許容しないリソースを新クラスタにリストア
・新クラスタにトラフィックを切り替え
・旧クラスタを削除
●まとめ
・アップグレード戦略
基本は in-place upgrade
ダウンタイムが発生するときは cluster migration
・cluster migrationの手順
バックアップからリストアしてリソースを移行
同じ設定で複数クラスタを運用するときは副作用がある
●QA
・upgradeがうまく行かなったの判断基準は？
サービス影響があるか？
まずはin-place、だめならcluster migration
監視が入っているから、基本的に大丈夫
・RDB以外でPVを持っている場合は、無停止で移行できる？
elasticsearchで利用
キャッシュとしてしか利用していない
cluster migrationで空になる
・切り戻し手順は用意している？
kopsだと逆の手順でOK
cluster migrationはCNAMEなどで考慮はしているが慎重に
・例にあったk8sのバグに遭遇したときの対処は？
IPアドレスのキャッシュが残っている問題だった
15分くらい待てば復旧した
■プロダクションレディを目指した Kubernetes クラスタのアップグレード戦略
Shunya Murata さん [ゼットラボ株式会社]
●ゼットラボ株式会社
・ヤフー株式会社の子会社
・ヤフーの次世代インフラを設計・開発する会社
・k8sを提供するプラットフォームの管理者な立ち位置
●Kubernetesのアップグレードに必要な作業
・準備
更新内容の調査
意図通り動作するか
アップグレード計画
リリースノート作成
・実施
クラスタのアップグレード
ストレージバージョンの更新
マニュフェストの更新
※バックアップは定期的に取っているので、手順に入っていない
●リリースサイクルとサポート期間
・マイナーバージョンは3ヶ月ごと
・サポート期間は最新3マイナーバージョン
3/26時点では、1.18, 1.17, 1.16
LTS版はまだworking groupで話している段階
●kubernetes変更点の調査
・changelog調査
urgent upgrade notes
removals
巨大なので調査が大変
複数人で専門分野を持って対応
qiitaで公開
・パラメータ、API変更点はdiffでチェック
●kubernetes以外の更新
・コンテナランタイム
・CNI
・CoreDNSなどのアドオン
●大変なのでマイナーバージョンに合わせてまとめて更新
・定期的に見直す
OSイメージにまとめてアップグレード
アドオン一式をまとめてコンテナ化してアップグレード
・不具合修正は適宜
●テスト
・conformance test
sonobuoy
zlabでは独自にビルド
・クラスタアップグレード、アドオンのe2e
・全マイナーバージョンの検証環境
スクリプト化して自動化
●アップグレード計画
・アプリケーションを止めずに実施できるか？
・クラスタ全体を止めずに実施できるか？
・アップグレード前後にやることは？
・ユーザー影響は？
●リリースノート
・利用している人向けに周知ドキュメントを用意
アップグレード
ユーザ影響
・マニフェストのlinterを提供
resource.request, probeなど
deprecateのapiはwarningを上げる
●k8sクラスタアップグレードの細かい注意
・マスターから先にアップグレード
アップグレード中も依存関係を満たす必要がある
・マスターはマイナーバージョンのスキップはサポート外
一つずつ上げていく必要がある
・ストレージバージョンのアップグレードが必要なことがある
etcdに保存されているスキーマのバージョン
・etcdも推奨バージョンがあるので合わせてアップグレード
●k8sノードのアップグレード
・podをgraceful shutdownしてから、ノード
kubectl drainで安全にノード削除
PodDisruptionBudgetで制御
・ノードを削除して追加する方式にしている
●クラスタのアップグレード要件
・アップグレード中
サービス全体でダウンタイムが発生しない
稼働中の全体リソースは減らない
masterコンポーネントは極力ダウンタイムが発生しない
controller-manager, schedulerなどはリーダー切り替え中は止まる
・ローカルディスクの内容は保持しない
●クラスタのアップグレード戦略
・ライブアップグレード
in-place migration
ダウンタイムなし
必要なリソースは最小で1ノード分にできる
一度に追加するノード数（Surge）で必要なリソースが決まる
・ブルーグリーンアップグレード
cluster migration
切り戻しは楽
リソースは2倍必要
●zlabでは、ほぼライブアップグレード
・k8sのアップグレードが原因の事故はない
・ノードのローリングアップデートがトリガーでサービス影響はある
・アドオンの更新のほうが事故になる
ingress controller
CoreDNS
●ライブアップグレードの問題点
・podのムダな移動が発生
削除予定のノードに再配置されてしまうことも
taintsで優先度は下げているが、
リソースをギリギリまで使っていると効果がない
・アップグレードに時間がかかる
一斉にアップグレードするとスタックする
IaaS側が詰まる
●クラスタアップデートの自動化
・ノードの更新
kubernetes cluster operator ※独自
クラスタの作成、削除、更新を自動化
アップグレードコストの最小化
・アドオンの更新
addon-manager ※公式のツール
指定ディレクトリのマニフェストをapplyし続ける
pruneもする
addon-updater ※自作
対象ディレクトリのマニフェストを管理
・ストレージバージョンの更新
update-storage-objects.sh
forkして公開済み
●導入効果
・すべてのクラスタがサポートバージョン範囲内
・300クラスタ以上を20-30名で対応
開発、運用、サポート、教育など
・IaaSのアップグレードも利用者に大きな影響なし
・オペミス撲滅
●QA
・manifestのlinterは何を使っている？
conftest、OPAでポリシーを書いてチェック
社内ルールなので公開はしなそう
API versionのwarningなど
・operatorのversion upで大変なことは？
k8sより高頻度にアップグレードしているので
大変さを感じたことはない
・担当の割当はどうしている？
人によってできるできないはあるが、基本的には希望制
■kubeadmでのクラスタアップグレード：その光と闇
Junichi Yoshise さん [Hewlett Packard Enterprise]
●自己紹介
・HPEでCloud Native Computingのチーフアーキテクト
・去年はほとんど日本にいなかった
今年は1週間しか海外に行っていない
・GAFAの社長w
●kubeadm is 何？
・SIG Cluter lifecycleのプロジェクト
・標準的なk8sクラスタのセットアップと管理
・インフラ、ネットワークは対象外
・インフラまで含めた自動化ツールに使われたり
kubesprayとか
●kubeadmのクラスタセットアップ手順
・ノードを準備
OS
コンテナランタイム
ノード間通信
CNI設定
・kubeadm, kubelet, kubectlのインストール
・kube APIのLBを用意
・1代目のコントローラーでkubeadm init
・CNIのインストール
・残りのコントローラーでkubeadm join
・ワーカーノードでkubeadm join
●kubeadmのクラスタアップグレード手順
・マニュアルにきっちり書いてある
・今だと17→18
・先に全部読みましょう
●デモ動画
・kubeadm を aptでインストール
・一旦 kubectl drain
・kubeadm upgrade plan
・kubeadm upgrade apply v1.17.4
kubernetesのコアコンポーネントがkubelet上で動いているので
新しいmanifestでpodが上がってきているだけ
・kubeadm upgrade node
・kubeletをaptでupgrade
・daemonを再起動
→ミスりがちなので、ansibleなどでコード化して実行しましょう
●ハマり例
・kubeadmと同時にkubeletのバージョンを上げてしまう
・ワークロードがバージョンに対応していない
・certificateがexpire
kubeadm alpha certs check-expiration
自動更新設定をしよう
・ステートフルなpodが突然死
●トラブルシューティングガイドが充実してきた
・ということは、それだけトラブルが多いということ
●壊れることを前提に
・アップグレード中は、いつものちょっとしたトラブルがわかりにくい
・バージョンアップの影響を事前に把握し切ることは難しい
カスタムコントローラ、CRD、、、
・master upgradeしたら、nodeはkubeadm joinが良いかもしれない
●壊さない、戻せるがアップグレードの前提
・コントロールプレーンは冗長化必須
3台構成なら、1台死んでもきれいにしてkubeadm joinできる
・ワークロードはいつでも再デプロイできるように
gitops
でも、OSSの各種ツールをgitopsはむずかしい
・結局クラスタまるごとバックアップ
velero
クラスタ上のすべてのリソース定義
PVもバックアップできるらしい
●QA
・kubeadmでproduction運用ってどう？
用途による
前提はオンプレ。研究用の環境とか
一般的なweb serviceには大変。
きっちり設計して、デプロイのツールとして使うくらい。
※途中退場で、LTはお話を伺えず。
■LT: そのクラスタ本当にアップグレードして大丈夫？ Storage Version の更新も忘れずにしよう！
uesyn さん
■LT: Kuma サービスメッシュ 使ってみた
ikeike443 さん
■LT: 設定記述言語 CUE で YAML Hell に立ち向かえ
y_taka_23 さん
■LT: kubeval を使って manifest を validation しよう
makocchi さん
■LT: GKE で始める Private clusters
iga_kyu さん
■感想
改めて、どのレイヤを扱うにせよデプロイ戦略は rolling update か blue/green deploy だな、としみじみ感じました。k8sではないですが、先日、オンプレ airgapなVM環境の、リソース増強ができない制約で無停止デプロイする方法を検討したときも、クラスタを半分に縮退してblue/green deployする方針にたどり着きました。。。
戦略は同じですが、気をつけないとハマるポイントはモノによるので、ノウハウを kubernetes 8 factors や Cluster migrationの原則 の様に型化していただけるのはとてもありがたいですね！
登壇者の皆さん、運営の皆さん、ありがとうございました！！
この記事が参加している募集
いつも応援していただいている皆さん支えられています。