No content

• 吉瀬 淳一 • • • Japan Others Japan Others

本業よりもこっちのほうが有名になってしまったかもしれない

何

のプロジェクト 標準的な クラスタのセットアップと管 理を行う 年に 〜 インフラのプロビジョニング、ネットワークの構成 などは対象外 インフラまで含めた自動化ツール（ な ど）に利用されることも多い

によるクラスタセットアップ手順（ 構成の場合） • ノードを準備する • インストール • コンテナランタイムのインストール • ノード間通信の設定（ など • 用の設定 • のインストール（全ノード） • 用のロードバランサーの用意 • 台目のコントローラーで • のインストール • 残りのコントローラーで • ワーカーノードで

でデプロイされる構成（ ）

でデプロイされる構成（ ）

によるクラスタアップグレード パイセン、 でクラスタアップグレード どうやるんすか？ RTFM

• マイナーバージョンのアップグ レードをサポート • 正しいバージョンのドキュメント を読みましょう • 順序などイマイチわかりにくいの で一度通読してから実行しましょ う

やってみる • のアップグレード • １台目 • ２台目・３台目 • のアップグレード • のアップグレード ※動画ではコマンドを手で叩いていますが、 などでコード化し てから実行したほうがよいです。絶対。

簡単ですね。だがしかし

何度も失敗しています ハマり例 • 先に と一緒に） のバージョンを上げてしまう • 新しい 用の設定は によって生成されるので、 を実行する 前に のバージョンを上げてしまうと などが上がってこなくなる。 • そのノードは潰して作り直し・・・ • そもそもワークロードが対応していない • とか・・・ • • 道半ばでタイミング悪く が • 賞味期限を確認しとけ（ • 自動更新設定しとけ • ステートフルな が謎の死を遂げる • の が死亡 • 原因究明できず（ 自体を再デプロイした）

ワークロード 稼働中のリソース

トラブルシューティングガイドも充実してきた • 裏を返せばそれだけトラブるというこ と

壊れることを前提にしたほうがいいかもしれない なぜなら • 普段遭遇するようなちょっとしたトラブルは、アップグレード中にも発生しうる • 通常ならちょちょいとトラシューして修復できるようなことでも、アップグレード中に起き ると何がなんだかわからなくなる • ワークロードが増えれば増えるほど、バージョンアップの影響を事前に全て調査するのは困難 • 自分が作ったアプリケーションはまだよい • カスタムコントローラーや を全て理解できますか？ • そもそも ノードはアップグレードせずに、 アップグレード後に新規ノード追加→古い ノード削除を繰り返したほうがよいかも

一応クラスタ構成はバックアップされます

対策と課題 • コントロールプレーン冗長化は必須 • が 台しかないと復旧はかなりつらい • 台構成なら、 台死んでもそいつをクラスタから外してきれいにしてから す ることは容易 • ワークロードはいつでも再デプロイできるようにしておく • つまり • ただし エコシステムの各種ツール（ 、 など）を の対象にするのはけっこう大 変 • 動的に生成されるリソースの再現が必要か • や が生成する とか • が取ってくる証明書とか • をどうやって救うか

やはりクラスタまるっとバックアップとりたいかも • 例えば • 旧 今は ファミ リー） • クラスタ上の全てのリソースの定義と 状態を ファイルとしてオブジェク トストレージに保存 • もバックアップできる らしい • 別クラスタへの にも使える（クラス タ２面運用ができそう） • 他によさげなものがあれば教えてください

まとめ • でのクラスタアップグレードは「うまくいけば」簡単 • うまくいかなかったときのトラブルシューティングはつらい（ に限らず） • 予防策とリカバリ策、両方準備しておきたい •

No content