エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
2020-03-26 Kubernetes Meetup Tokyo #29 Cluster Upgrade 編 #k8sjp|諏訪真一
記事へのコメント0件
- 注目コメント
- 新着コメント
このエントリーにコメントしてみましょう。
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
2020-03-26 Kubernetes Meetup Tokyo #29 Cluster Upgrade 編 #k8sjp|諏訪真一
→cluster migrationに絞ると5つ ●Cluster migrationの原則 ・クラスタをコード間 ・動作確認の省力化 ・... →cluster migrationに絞ると5つ ●Cluster migrationの原則 ・クラスタをコード間 ・動作確認の省力化 ・非名前管理 ・バックアップ ・重複欠損管理 ●クラスタをコード管理 ・互換性がない場合変更が大きい クラスタの作成を楽にしたい ・クラスタの設定、作成もコード化 ・環境ごとの差分は明示的に比較できるように ●動作確認の省力化 ・ツールの恩恵が受けられない ・検証環境との差異をできるだけ減らす 本番でしか起きない問題を減らす ・クラスタへの変更はコードを元にする 意図しないリソースの変更を検知 ●非名前管理 ・複数クラスタの運用を考慮する場合 クラスタ名が同じだと識別できない 別の名前で立てることになる 監視やアラートも新しいクラスタ向けに必要 ロールバックをしやすく ・同一要素のリソースが複数立てられることを想定 production 本番で複数クラスタ