AIによる美容医療の基礎知識業界ビジネスレポートサイトを運用しています
Kubernetes特集 第3章を公開しました――「動いた」ではなく「止めずに更新して戻せる」を確かめる
※この記事は、以下の当方ブログの要約です。全文は以下をどうぞ。
ブログ記事の全文
30秒の紹介動画
10月19日から6日間、毎日1ページずつ公開している、初級技術者向けのKubernetes再入門特集。4日目の今日は、第3章「ワークロード」を公開しました。昨日の章で追った裏側の部品の上で、実際にアプリを動かし、更新し、戻すところまでを扱います。
「起動した」と「受け付けられる」は別
アプリが起動していても、お客様からの通信を受けられる状態とは限りません。Kubernetesには、アプリの状態を定期的に確かめる仕組みがあり、「受付の準備ができたか」と「作り直しが必要なほど壊れているか」を別々に判断させます。この2つを取り違えると、サーバーが一時的に遅いだけで、全台が同時に再起動してしまうことがあります。章では、この違いを図で整理しました。
更新は1台ずつ入れ替え、失敗したら戻す（ただしデータの変更は戻らない）
Kubernetesは、新しい版を1台ずつ増やし、準備ができてから古い版を減らします。更新中も、必要な台数が使える状態を保てます。失敗したときは、1つ前の版へ戻せます。ただし、データベースの構造を不可逆に変えた場合、アプリだけを戻すことはできません。更新の前に、止めてよい台数、戻す条件、データの互換性を決めておく必要があります。この判断項目も表にしました。
壊してよい環境で3つの失敗を起こす
後半では、確認の設定を間違える、設定の名前を打ち間違える、必ず失敗する処理を動かす、の3つをわざと起こします。更新が止まっても古い版が残っていれば、お客様への影響はありません。担当者には、原因だけでなく「利用者に影響があったか」も記録させてください。
特集は10月24日まで、毎日1ページずつ続きます。特集トップをブックマークしておくと、続きを追えます。
※2026年10月時点の公開情報に基づきます。
「うちはKubernetesが必要なのか」「ECSやCloud Runで足りるのか」といった導入判断から、クラスター設計、運用体制づくりまで、30分の無料相談で承っています。
https://shinichi.noguchi.jp.net/feature/kubernetes/03-workloads.html
