ブレンダン・バーンズとKubernetes：オーケストレーションを形作ったアイデア

なぜKubernetesは日常の運用を変えたのか

Kubernetesは単なる新しいツールの導入にとどまらず、“日々の運用”のあり方そのものを変えました。何十、何百ものサービスを運用する状況では、オーケストレーション以前はチームがスクリプトや手作業のランブック、属人的な知識で同じ問いに繰り返し対処していました：このサービスはどこで動かすべきか？ どう安全に変更を展開するか？ 深夜2時にノードが落ちたらどうする？

「オーケストレーション」が実際に解くもの

本質的には、オーケストレーションはあなたの意図（「こう動かしたい」）と、機械の故障、トラフィック変動、継続的なデプロイといった現実の間をつなぐ調整層です。各サーバーを特別扱いする代わりに、計算資源をプールとして扱い、ワークロードを移動可能なスケジューラブルな単位として扱います。

Kubernetesはチームが「何を望むか」を記述し、システムがその記述に現実を合わせ続けるモデルを普及させました。この変化は、運用をヒーロー的な対応から再現可能なプロセスへと変えます。

チームがすぐに感じた三つの成果

Kubernetesは多くのサービスチームが必要とする運用上の成果を標準化しました：

• デプロイ：何を動かすかを宣言し、それを更新して健全性を検証する一貫した方法
• スケーリング：サービスを設計し直したりマシンを手動で用意したりせずに、1インスタンスから多数へ拡張する実用的な道筋
• サービス運用：サービスが互いに見つけ合い、トラフィックをルーティングし、インスタンスの変化に合わせて動き続けるための安定した方法

範囲と情報源についての注意

この記事はKubernetes（およびBrendan Burnsのようなリーダー）に関連するアイデアとパターンに焦点を当てており、個人の伝記ではありません。また「始まり方」や「設計理由」を語る際には、会議の発表、設計ドキュメント、上流ドキュメントといった公開情報に基づくべきで、神話化された話ではなく検証可能なストーリーにすることを意図しています。

Kubernetesの起源物語におけるブレンダン・バーンズ（概観）

ブレンダン・バーンズは、Joe Beda、Craig McLuckieと並んでKubernetesの共同創設者の一人として広く認識されています。Googleでの初期のKubernetes作業において、Burnsは技術的な方向性とプロジェクトのユーザーへの説明方法の形成に寄与しました。特に「コンテナをどう実行するか」だけでなく「ソフトウェアをどう運用するか」に焦点を当てていました（出典：Kubernetes: Up & Running（O’Reilly）、KubernetesプロジェクトのAUTHORS／メンテナ情報）。

オープンソースでの協調が設計に与えた影響

Kubernetesは完成した社内システムとして単に公開されたわけではなく、増え続ける貢献者、ユースケース、制約とともに公開の場で作られていきました。そのオープンさが、さまざまな環境で生き残れるインターフェイスへの設計を後押ししました：

• 実装の隠れた詳細よりも明確でバージョン管理されたAPI
• クラウドプロバイダやオンプレ環境間での移植可能な挙動
• コアを比較的小さく保ちながら多様なニーズを受け止める拡張ポイント

この協調的なプレッシャーは、Kubernetesが何を最適化したかに影響を与えました：多くのチームが合意できる共有プリミティブと再現可能なパターンです。

ここで言う「標準化」の意味

Kubernetesが「デプロイや運用を標準化した」と言うとき、それはすべてのシステムを同一にしたという意味ではありません。むしろ、共通の語彙とワークフローを提供したという意味です：

• “Deployment”や“Service”、“Ingress”、“Job”、“Namespace”といった共有用語
• 望む状態を宣言してシステムに実現させる一貫したモデル
• 変更のローリング展開、スケール、障害からの回復の予測可能な方法

共通モデルがあることで、ドキュメントやツール、チームのプラクティスが会社間で移転しやすくなりました。

プロジェクト本体とエコシステムの区別

Kubernetes（オープンソースプロジェクト）とKubernetesエコシステムは分けて考えると有益です。

プロジェクトはコアのAPIとコントロールプレーンコンポーネントで構成されるプラットフォーム本体です。エコシステムはそこから成長したものすべて――ディストリビューション、マネージドサービス、アドオン、関連するCNCFプロジェクト――を指します。実運用で多くのチームが依存する「Kubernetesの機能」の多くは、コアではなくエコシステム側（観測スタック、ポリシーエンジン、GitOpsツール等）に存在しています。

コアの考え方：宣言的な望ましい状態

宣言的な設定は、システムを記述する方法の単純な転換です：手順（ステップ）を列挙するのではなく、達成したい最終結果を記述します。

Kubernetesの文脈では、プラットフォームに「コンテナを起動してポートを開けて、クラッシュしたら再起動する」と逐次命令するのではなく、「このアプリのコピーを3つ動かし、このポートで到達可能にし、このコンテナイメージを使う」と宣言します。Kubernetesはその宣言と現実を一致させる責任を負います。

望ましい状態と命令型スクリプトの違い

命令型の運用はランブックのようなものです：前回有効だったコマンド列を再実行して対応します。

望ましい状態は契約に近いものです。設定ファイルに意図した結果を記録し、システムが継続的にその結果に向けて動きます。もしドリフトが起きれば（インスタンスが死ぬ、ノードが消える、手動変更が入るなど）、プラットフォームが不一致を検出して修正します。

以前／以後：ランブックのコマンド vs YAML

以前（命令型ランブック思考）：

• サーバーにSSHで入る
• 新しいコンテナイメージをpullする
• 古いプロセスを止める
• 新しいプロセスを起動する
• ロードバランサのルールを更新する
• トラフィックが急増したら更にサーバーで繰り返す

このやり方は成り立ちますが、サーバーが“スノーフレーク化”し、限られた人しか信用しない長いチェックリストが残りがちです。

以後（宣言的な望ましい状態）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
spec:
  replicas: 3
  selector:
    matchLabels:
      app: checkout
  template:
    metadata:
      labels:
        app: checkout
    spec:
      containers:
      - name: app
        image: example/checkout:1.2.3
        ports:
        - containerPort: 8080

ファイルを変更（たとえば image や replicas を更新）して適用すれば、Kubernetesのコントローラが実行中の状態を宣言と一致させるように働きます。

なぜ工数とドリフトが減るのか

宣言的な望ましい状態は「この17ステップを実行する」から「こうしておけ」に変えることで運用工数を下げます。また、設定の真実の単一のソースが明示的でレビュー可能（多くはバージョン管理）になるため、ドリフトが減り、驚きが発生しにくく、監査やロールバックが容易になります。

コントローラとリコンシリエーション：状態を保つ仕組み

Kubernetesが“自己管理的”に感じられるのは、単純なパターンの上に成り立っているからです：望ましい状態を記述すると、システムが現実をその記述に合わせて継続的に動く。エンジンはコントローラです。

コントローラとは何か（平易に）

コントローラはクラスタの現在状態を監視し、YAMLやAPIで宣言された望ましい状態と比較して差分があればその差分を埋めるアクションを取るループです。

一度だけ動くスクリプトではなく、人間のクリックを待つものでもありません。繰り返し実行される（観察→判断→行動）ことで、いつでも変化に応答できます。

リコンシリエーション：Kubernetesが「状態を保つ」方法

その繰り返しの比較と修正の振る舞いをリコンシリエーションと言います。これは「自己修復」の一般的な保証の背後にあるメカニズムです。システムは障害を魔法のように防ぐわけではなく、ドリフトを検出して修正します。

ドリフトは以下のような日常的な理由で起きます：

• プロセスがクラッシュする
• ノードが消える
• 誰かがスケールを手動で変える
• デプロイが更新される

リコンシリエーションはKubernetesがそれらのイベントを意図を再チェックして復元するための合図として扱うことを意味します。

実際に関心のある成果

コントローラは親しみのある運用結果に変換されます：

• 失敗したPodの置換：Podが死ねばコントローラが新しいPodをスケジュールする
• レプリカ数の維持：5レプリカ要求で4しか動いていなければ、Kubernetesは欠損分を作る
• ローアウトの進行管理：更新中にコントローラが可用性を保ちながら新バージョンへ移行する

核心は、症状を手動で追いかけるのではなく、目標を宣言し制御ループが継続的に「その状態にしておく」作業を行う点です。

このアプローチが単一機能を超えてスケールする理由

この方法は単一のリソース型に限定されません。Kubernetesは同じコントローラとリコンシリエーションの考え方をDeployments、ReplicaSets、Jobs、Nodes、Endpointsなど多くのオブジェクトに適用しています。この一貫性が、プラットフォーム化の大きな理由です：パターンを理解すれば、新しい機能（カスタムリソースを含む）を追加したときの挙動を予測できます。

スケジューリングは製品機能であり手作業ではない

もしKubernetesが単に「コンテナを動かす」だけなら、どこでワークロードを走らせるかという最も難しい部分は残ったままです。スケジューリングはPodを適切なノードに自動的に配置する組み込みの仕組みで、リソース要求やルールに基づいて配置します。

配置決定は稼働時間とコストに直接影響します。混雑したノードに固定されたWeb APIは遅くなるかクラッシュする可能性があります。バッチジョブがレイテンシに敏感なサービスの隣に置かれればノイズィネイバー問題を引き起こします。KubernetesはこれをスプレッドシートとSSHによる手作業ではなく、再現可能な製品機能に変えます。

スケジューラが最適化していること

基本的には、スケジューラはPodの要求を満たせるノードを探します。

• CPU/メモリのrequests：配置決定のために容量を予約します。500m CPUと1Giメモリを要求したら、Kubernetesは十分な空きのあるノードだけを候補にします。

この単純な習慣――現実的なrequestsを設定すること――がランダムな不安定性を減らすことが多いです。重要なサービスが他のものと奪い合わなくなります。

実運用でよく使われる制約

リソース以外に、実稼働クラスタではいくつかの実務的なルールが使われます：

• Affinity / Anti-affinity：キャッシュローカリティのため一緒に置く、あるいは可用性のため分散する
• Taints and Tolerations：GPUノードやシステムノード、コンプライアンス用ノードを特殊用途としてマークし、承認されたワークロードだけを許可する

これが障害をどう減らすか

スケジューリング機能は運用意図をコード化します：

• レプリカをノードに分散してノード障害に耐える
• スパイクするジョブを顧客向けサービスから隔離する
• 高価なノード（GPUなど）を誤ったワークロードから守る

実用的な要点：スケジューリングルールをプロダクト要件として扱い、文書化・レビューし、一貫して適用することで、信頼性が深夜の誰かの記憶に依存しないようにすることです。

スケーリング：アプリを書き換えずに1つから数千へ

Kubernetesのもっとも実用的な考え方の一つは、スケーリングにアプリコードの書き換えや新しいデプロイ方式が不要であるべきだ、という点です。アプリが1つのコンテナで動くなら、同じワークロード定義で通常は数百〜数千のコピーまで拡張できます。

スケーリングは二層で考える

Kubernetesはスケーリングを二つの関連する決定に分けます：

• 何個のPodを走らせるか（スループットや冗長性のためにコピー数を増やす）
• クラスタにどれだけの容量があるか（ノード数とそのサイズがPodを配置できるか）

この分割は重要です：200個のPodを要求しても、クラスタに50しか場所がなければスケーリングは保留（Pending）になります。

オートスケーリングの概念（HPA、VPA、Cluster Autoscaler）

Kubernetesでは一般に三つのオートスケーラが使われます。それぞれ異なるレバーにフォーカスします：

• Horizontal Pod Autoscaler（HPA）：CPU使用率やカスタムアプリメトリクスに基づいてPod数を変える
• Vertical Pod Autoscaler（VPA）：Podのrequests/limitsを調整して各Podがより（またはより少なく）CPU/メモリを使うようにする
• Cluster Autoscaler：スケジューラが要求したPodを配置できるようにノード数を増減する

これらを組み合わせると、スケーリングは「レイテンシを一定に保つ」や「CPUをX%に保つ」といったポリシーになります。手動で誰かを呼び出す作業ではなくなります。

「良いスケーリング」が依存するもの

スケーリングは入力の質に依存します：

• メトリクス：CPUは簡単だが常に意味があるわけではない。リクエストレート、キュー深さ、レイテンシの方が実際の負荷に合うことが多い。
• リソースrequests/limits：これがスケジューラにPodの必要量を伝える。未設定だと配置やオートスケールの判断が困難になる。
• 負荷パターン：スパイク、ウォームアップの遅さ、重いバックグラウンドジョブはスケーリングの応答速度に影響する。

よくある落とし穴

繰り返し見かけるミスは二つ：間違ったメトリクスでスケールする（CPUは低いがリクエストがタイムアウトする）ことと、リソースrequestsを設定していないこと（オートスケーラが容量を予測できずPodが詰め込まれて性能が不安定になる）。

安全なデプロイ：ローアウト、ヘルスチェック、ロールバック

Kubernetesが普及させた大きな転換は「デプロイを単発のスクリプトではなく継続的な制御問題として扱う」ことです。ローアウトとロールバックはファーストクラスの振る舞いです：どのバージョンを望むか宣言すれば、Kubernetesが可用性を確認しながらその状態に向けてシステムを移行します。

ロールアウトは制御された遷移である

Deploymentではローアウトは古いPodを段階的に新しいPodに置き換えるプロセスです。一度に全てを止めて再起動するのではなく、容量を保ちながら実トラフィックで新バージョンを検証できます。

新バージョンが失敗し始めたら、ロールバックは緊急の手順ではなく通常の操作になります：以前のReplicaSet（最後に正常だったバージョン）へ戻してコントローラに旧状態を復元させます。

プローブ：「動いているが悪い」リリースを防ぐ

ヘルスチェックはローアウトを希望的観測から計測可能なものに変えます。

• Readiness probe はPodがトラフィックを受ける資格があるかを決めます。コンテナが動作していても（起動はしているが）まだ準備が整っていない場合はtrafficを受けさせません。
• Liveness probe はコンテナがハングしているか壊れているかを検出して再起動を促します。

プローブを適切に使うことで、Podが単に起動しただけで見かけ上は成功しているが実際にはリクエストを処理できない、という誤判定を減らせます。

デプロイ戦略：ローリング、ブルー/グリーン、カナリア

Kubernetesはローリングアップデートを標準でサポートしますが、チームはしばしばその上に別のパターンを重ねます：

• ブルー/グリーン：二つの完全な環境を用意し、グリーンが検証できたらトラフィックを切り替える
• カナリア：少量のトラフィックを新バージョンに送り、メトリクスを観察してから段階的に拡大する

測定可能で自動化できる安全性

安全なデプロイは信号に依存します：エラー率、レイテンシ、飽和度、ユーザー影響です。多くのチームはロールアウトの意思決定をSLOとエラーバジェットに紐づけます—もしカナリアが許容されるバジェットを消費しすぎたら昇格を止めます。

目標は、失敗時に自動的にロールバックするトリガー（readinessの失敗、5xxの増加、レイテンシの急上昇など）を持つことで、「ロールバック」が予測可能なシステム応答になり、深夜のヒーロー対応を減らすことです。

サービス運用：発見、ルーティング、安定したネットワーキング

コンテナプラットフォームが“自動的”に感じられるのは、他のシステム要素がアプリを動的に見つけられるときです。実運用のクラスタではPodは作成、削除、再スケジュール、スケールを常に繰り返します。もし変更のたびにIPアドレスを設定に書き換えなければならないなら、運用は忙殺され、障害が常態化します。

サービスディスカバリが重要な理由

サービスディスカバリはクライアントが変化するバックエンド群に確実に到達する方法を与えます。Kubernetesの重要な変化は、個々のインスタンス（「10.2.3.4を呼べ」）を狙うのをやめ、名前付きサービス（「checkoutを呼べ」）を呼ぶようにする点です。プラットフォームが現在どのPodがその名前を提供しているかを管理します。

Service、Selector、Endpoints を平易に説明する

Service はPod群の安定した入口です。クラスタ内で一貫した名前と仮想アドレスを持ち、背後のPodが変わっても表面は変わりません。

Selector はどのPodがその入口の背後にいるかを決める方法で、通常はラベル（例：app=checkout）で一致させます。

Endpoints（またはEndpointSlices）はセレクタに現在一致する実際のPod IPの生きた一覧です。Podがスケールアップ、ロールアウト、再スケジュールされるとこの一覧が自動で更新され、クライアントは同じService名を使い続けられます。

安定したアドレス、ロードバランシング、トラフィックルーティング

運用上、これが提供するものは：

• 安定したアドレス：アプリはPod IPを追いかけずServiceのDNS名を使う
• ロードバランシング：トラフィックがService背後のヘルシーなPodに分散される
• 予測可能なルーティング：誰にトラフィックを送るか（ラベル／セレクタ）とPodがどこで動くかを分離できる

外部からの北南トラフィックについては、Kubernetesは通常Ingressや新しいGatewayアプローチを使います。どちらもホスト名やパスでリクエストをルーティングし、TLS終端などの懸念を集中化できます。重要なのは同じ考え方：外部へのアクセスを安定させ、バックエンドは下で変わり続けられるようにする点です。

自己修復（Self-healing）：本番での意味

Kubernetesの「自己修復」は魔法ではありません。自動化された反応の集合です：再起動、再スケジュール、置換。プラットフォームはあなたが宣言した望ましい状態を監視し、現実をその状態へ戻すために働き続けます。

再起動：コンテナがクラッシュしたとき

プロセスが終了するかコンテナが不健康になった場合、Kubernetesは同じノード上で再起動できます。主な駆動要因は：

• Liveness probe：コンテナがまだ機能しているか。そうでなければ再起動する。
• 再起動ポリシー：いつ再起動するかの規則

実運用の典型パターンは、単一コンテナがクラッシュ→Kubernetesが再起動→ServiceはヘルシーなPodだけにルーティングし続ける、です。

再スケジュールと置換：ノード障害時

ノード全体がダウンした場合（ハードウェア故障、カーネルパニック、ネットワーク喪失など）、KubernetesはそのノードをNotReadyとして検出し、ワークを他へ移します。大まかな流れは：

• ノードが不健康／NotReadyとマークされる
• そこにいたPodは喪失と見なされる
• コントローラが他の健康なノードに代替Podを作成して望ましいレプリカ数を復元する

これがクラスタレベルでの「自己修復」です：人間がSSHで介入するのを待つ代わりに、システムが容量を置き換えます。

可観測性：どうやって修復が行われていると分かるか

自己修復が意味を持つのは検証できるときだけです。チームは通常次を監視します：

• ログ（アプリログとプラットフォームイベント）で何が再起動したかとその理由を確認
• メトリクス（再起動回数、プローブ失敗、ノードのReady状態）
• アラート：修復がうまくいっていないとき（CrashLoopBackOffの繰り返し、レプリカ不足、過剰な追い出しなど）

自己修復を壊す誤設定

Kubernetesでもガードレールが間違っていると「修復」が働かないことがあります：

• 不適切または欠落した liveness/readiness probe（誤検出や永遠にReadyにならない）
• リソースrequests/limitsがないためスケジューリングやOOMによる不安定化
• レプリカ数が少なすぎる（単一Podでは継続性が確保できない）
• 過度に厳しいプローブ設定で再起動の嵐が起きる
• ノードローカルな状態に依存し、永続的なストレージ戦略がないワークロード

自己修復が適切に設定されていれば、障害は短く小さくなり、そして何より測定可能になります。

標準化されたAPIと拡張性：Kubernetesがプラットフォームになった理由

Kubernetesが勝利したのは単にコンテナを動かせたからではありません。最も一般的な運用ニーズ（デプロイ、スケーリング、ネットワーク、観測）に対して標準化されたAPIを提供したからです。チームが同じオブジェクトの「形」（Deployment、Service、Jobなど）に合意すると、ツールを共有でき、トレーニングが簡単になり、開発と運用の引き継ぎが属人的知識に依存しなくなります。

標準APIがチームのワークフローをどう変えるか

一貫したAPIがあれば、デプロイパイプラインは各アプリの細かい違いを知らなくても同じ操作（作成、更新、ロールバック、ヘルスチェック）を実行できます。

また、整合性が向上します：セキュリティチームはガードレールをポリシーとして表現でき、SREは共通のヘルス信号に基づくランブックを標準化でき、開発者は共通語彙でリリースを考えられるようになります。

Kubernetesの拡張：CRDとOperator

Custom Resource Definitions（CRD） でクラスタに新しいタイプのオブジェクト（例：Database、Cache、Queue）を追加できます。

Operator はそれらのカスタムオブジェクトにコントローラを組み合わせ、バックアップやフェイルオーバー、バージョンアップといった従来手動だったタスクを自動化します。重要なのは魔法ではなく、Kubernetesが他で使っている同じ制御ループのアプローチを再利用している点です。

GitOps、CI/CD、ポリシーチェックとの適合

KubernetesがAPI駆動であるため、現代的なワークフローとの統合が容易です：

• GitOps：望ましい状態をGitに置き、変更をコードのようにレビューする
• CI/CD：パイプラインでマニフェストを適用し、Readinessを待ち、バージョンをPromoteする
• ポリシーチェック：Admission Controllerで本番へ到達する前に危険な設定をブロックする

これらのアイデアに基づいたより実践的なデプロイ・運用ガイドが欲しければ、/blog を参照してください。

今日チームが適用できること（Kubernetes以外でも有効）

多くのKubernetesの考え方（Brendan Burnsの初期のフレーミングに関連するものを含む）は、VM、サーバーレス、より小規模なコンテナ環境でも有効に翻訳できます。

日常運用を改善するパターン

「望ましい状態」を書き、それを自動化で守らせる。 Terraform、Ansible、CIパイプラインのいずれであれ、設定を単一の真実のソースとして扱ってください。結果として手動デプロイ手順が減り「自分の環境では動いたのに本番では動かない」という驚きが減ります。

一回きりのスクリプトではなくリコンシリエーションを使う。 一度実行して終わりのスクリプトではなく、バージョンや設定、インスタンス数、ヘルスといった重要なプロパティを継続的に検証するループを作りましょう。これが再現可能な運用と障害からの予測可能な回復につながります。

スケジューリングとスケーリングを明確な製品機能にする。 いつ、なぜキャパシティを増やすのか（CPU、キュー深さ、レイテンシのSLO）を定義します。Kubernetesのオートスケーリングがなくても、チームはスケールルールを標準化しておけば成長時にアプリを書き換えたり誰かを呼び出したりする必要が減ります。

ローアウトを標準化する。 ローリング更新、ヘルスチェック、迅速なロールバック手順は変更のリスクを下げます。ロードバランサ、フィーチャーフラグ、リリースを実際の信号でゲートするデプロイパイプラインでこれを実現できます。

安全に導入するためのチェックリスト

• サービスの望ましい状態を定義する：バージョン、設定、依存関係、最低インスタンス数
• ヘルスエンドポイント（liveness/readiness相当）を追加し、ロードバランサやデプロイパイプラインに接続する
• デプロイ手順を自動化する：デプロイ、検証、トラフィック移行、失敗時のロールバック
• 小さな「リコンシリエラ」を作る：設定ドリフトやインスタンス欠損を定期的に是正するチェック
• 明確な上限（最大インスタンス数、クールダウン、承認ルール）を持つスケーリングトリガーを追加する

これだけで解決できないこと

これらのパターンは不適切なアプリ設計、安全でないデータマイグレーション、コスト管理を自動で解決するわけではありません。バージョン管理されたAPI、マイグレーション計画、予算／制限、デプロイが顧客影響と結びつく可観測性は別途必要です。

次の一手

顧客向けサービスの1つを選んでチェックリストをエンドツーエンドで実装し、その後に他へ展開してください。

新しいサービスを素早く「デプロイ可能」にしたい場合、Koder.aiはチャット駆動の仕様からフロントはReact、バックエンドはGoとPostgreSQL、モバイルはFlutterといったフルスタックアプリを生成し、ソースコードをエクスポートしてこの記事で取り上げたKubernetesパターン（宣言的設定、再現可能なローアウト、ロールバックに優しい運用）を適用できるように支援します。コストやガバナンスを評価するチームは /pricing を確認できます。