AIによる分散型SNS業界ビジネスレポートサイトを運用しています
Kubernetes特集 第2章を公開しました――障害対応は「どの層で止まっているか」の切り分けから始まります
※この記事は、以下の当方ブログの要約です。全文は以下をどうぞ。
ブログ記事の全文
30秒の紹介動画
10月19日から6日間、毎日1ページずつ公開している、初級技術者向けのKubernetes再入門特集。3日目の今日は、第2章「アーキテクチャ」を公開しました。昨日の第1章で確かめた「見張り役」の正体を、部品ごとに分解する章です。
部品は5つ。全員が台帳を見て動く
Kubernetesの司令塔には、受付窓口（API Server）、台帳（etcd）、置き場所を決める係（Scheduler）、頼まれた数と現実の差を埋める係（Controller）がいて、各サーバーには実際にコンテナを動かす係（kubelet）がいます。
この章で担当者に理解してほしいのは、部品どうしが直接話さないことです。全員が台帳を読み、自分の担当の差を見つけ、結果を書き戻します。設定を投入して「成功」と返った時点では、台帳に書けただけで、コンテナはまだ動いていません。「投入は通ったのに動かない」という問い合わせの多くは、この理解で説明がつきます。
出来事の1行ずつに担当者の名前を付ける
章の前半では、アプリを1つ配置して、起きた出来事を古い順に並べ、1行ずつに「誰の仕事か」を付けていきます。障害のときは、この並びがどこで途切れているかを見れば、止まっている層がわかります。
後半では、壊してよい環境で3種類の障害を起こします。置き場所が見つからない障害、置き場所は決まるのに起動できない障害、名札を書き換えて見張り役を混乱させる障害です。どれも「古い構成は動き続けていて利用者への影響はない」ことを確かめたうえで戻します。担当者には、原因の欄に「止まった層」を必ず書かせてください。
司令塔が止まっても、動いているものは動く
「司令塔が落ちたらサービスが全部止まる」と思われがちですが、動いているコンテナは動き続けます。止まるのは、変えることと、状態を読むことです。逆に言えば、画面が見えているからといって正常とは判断できません。マネージド環境では司令塔のログに直接触れないため、自分で確認できる項目と事業者に問い合わせる項目を、障害が起きる前に分けておく必要があります。この線引きも章の中で表にしました。
特集は10月24日まで、毎日1ページずつ続きます。
※2026年10月時点の公開情報に基づきます。
「うちはKubernetesが必要なのか」「ECSやCloud Runで足りるのか」といった導入判断から、クラスター設計、運用体制づくりまで、30分の無料相談で承っています。
https://shinichi.noguchi.jp.net/feature/kubernetes/02-architecture.html
