はじめに
kubectl apply は打てる。Deployment も Service も書ける。けれども「なぜこの形なのか」を人に説明できるかというと、少し口ごもってしまう——そんな段階でこの本に出会うと、腑に落ちる箇所がかなり多いはずです。
本記事は O'Reilly『Kubernetes Patterns, 2nd Edition』（Bilgin Ibryam / Roland Huß 著） の通読メモを、設計・アーキテクチャに関心のあるエンジニア向けに1本にまとめたものです。個々の API リファレンスではなく、本書が提示する「パターン言語」の全体像を追いかけます。
結論から書くと、本書の立ち位置は著者自身の言葉に集約されています。
本書は、Gang of Four デザインパターンをコンテナオーケストレーション向けに構築するという私たちの試みです。
つまり本書は Kubernetes の入門書でもリファレンスマニュアルでもなく、「分散システムの設計語彙」を整備する本です。
本書の位置づけ
パターン本の系譜に連なる一冊
序文では、デザインパターンという概念の出自が丁寧に整理されています。1977年のクリストファー・アレクサンダー『パターン・ランゲージ』（建築）を起点に、GoF『デザインパターン』、Hohpe & Woolf『Enterprise Integration Patterns』、Fowler『Patterns of Enterprise Application Architecture』——という流れの延長線上に、本書は自らを置いています。
ここで著者が強調しているのは、パターンはレシピではないという点です。手順を1つずつ示すものではなく、類似した一連の問題に対する「青写真」を提供するもの。そして何より、共通の名前を持つことで語彙（言語）が形成されることに価値がある、と述べられています。
「Factory」と言えばオブジェクト指向プログラマの間で即座に共通のイメージが立ち上がるように、「Sidecar」「Ambassador」「Operator」と言えば同じ絵が浮かぶ状態をつくる。それが本書の狙いです。
各章のフォーマット
全パターンが以下の統一形式で記述されており、拾い読みしやすい構成になっています。
| セクション | 内容 |
|---|---|
| 名前 | パターン名（章タイトルそのもの） |
| 問題 | より広い文脈と、パターンが扱う問題空間 |
| 解決 | Kubernetes 固有の解決方法と、他パターンへの相互参照 |
| 議論 | そのコンテキストにおける利点と欠点 |
| 詳細情報 | 関連リソースへのリンク |
各章は独立して読める構成なので、興味のあるパターンから任意の順序で読み進められます。エッセイ集に近い読み心地です。
誰のための本か
対象読者は、コンテナと Kubernetes の基本概念をすでに持っていて、その先に進みたい開発者です。低レベルの実装詳細を知らなくてもユースケースは理解できるよう配慮されています。アーキテクトやコンサルタントにも有用、と明記されています。
なお序文には Kubernetes 共同創業者 Brendan Burns が寄稿しており、こう書いています。
分散システム開発をコンピュータサイエンス入門レベルの演習にすることが私たちの目標だ
本書は、その講義における教科書たろうとしている——という位置づけです。
全体構成：6パート・30章
本書は30章を6つのカテゴリに整理しています。
| パート | テーマ | 該当章 |
|---|---|---|
| I. 基礎パターン | クラウドネイティブの前提条件となる原則 | 2〜6章 |
| II. 行動パターン | Pod と管理プラットフォームの相互作用 | 7〜14章 |
| III. 構造パターン | Pod 内のコンテナの構造化 | 15〜18章 |
| IV. 構成パターン | 設定の外部化とカスタマイズ | 19〜22章 |
| V. セキュリティパターン | アプリと Kubernetes の交差点にあるセキュリティ | 23〜26章 |
| VI. 高度なパターン | プラットフォーム自体の拡張 | 27〜30章 |
以下、パートごとに要点を追っていきます。
パートI：基礎パターン（2〜6章）
「クラウドネイティブなプラットフォームの良きパートナーになるための最低条件」 を扱うパートです。ここを外すと、以降のどんな高度な仕組みも機能しません。
第2章 Predictable Demands（予測可能な需要）
コンテナは自身のリソース要件とランタイム依存関係を宣言しなければならない、という原則です。
なぜ必要かというと、理由は2つ挙げられています。
- インテリジェントな配置 — 依存関係とリソース需要が事前に分かっていて初めて、スケジューラはクラスタ上のどこに置くべきかを判断できます。優先度の異なる多数のプロセスがリソースを共有する環境では、事前申告が共存の唯一の手段です。
- キャパシティプランニング — サービスごとのリソースプロファイルが揃うことで、環境ごとの必要容量とコスト効率のよいホスト構成を割り出せます。
PVC への依存を宣言していない Pod は、必要なボリュームを提供できるノードがなければそもそもスケジュールされません。「宣言しないものは存在しないのと同じ」 という Kubernetes の思想が、最初のパターンで明示されます。
第3章 Declarative Deployment（宣言的なデプロイメント）
Deployment リソースを中核とした、アップグレードとロールバックの自動化です。
手作業でやると何が起きるか、が具体的に整理されています。新バージョンの起動、旧バージョンの正常な停止、起動の待機と検証、失敗時のロールバック——これらを人手でやれば必ずミスが混入し、スクリプト化には多大な労力がかかり、リリースプロセスがボトルネック化します。
重要なのは、Deployment が正しく機能する前提として、コンテナ側がクラウドネイティブである必要があるという指摘です。具体的には SIGTERM などのライフサイクルイベントを尊重すること（5章）と、ヘルスチェックエンドポイントを提供すること（4章）。基礎パターン同士が相互に依存している構造がよく分かります。
第4章 Health Probe（ヘルスプローブ）
「プロセスが生きている」ことと「アプリケーションが健全である」ことは別物である、という前提から出発します。
OutOfMemoryError を投げても JVM プロセスは動き続けます。無限ループ、デッドロック、キャッシュやヒープのスラッシング——プロセス監視だけでは検出できない障害は数多くあります。
本書が強調するのは、業界がすでに「バグのないコードは書けない」という事実を受け入れたという認識の転換です。重点は障害の回避から、検出と復旧へ移りました。
Kubernetes が提供するチェックは3層です。
- プロセスヘルスチェック — Kubelet による最も単純な生存確認
- Liveness Probe — 障害検出時にコンテナを再起動（HTTP / TCP Socket / Exec / gRPC）
- Readiness Probe — トラフィックを流してよいかの判断
ヘルスチェックはアプリケーション自身ではなく外部から実行されることが重要、という指摘も見逃せません。アプリ内蔵のウォッチドッグでは報告できない障害があるためです。
第5章 Managed Lifecycle（管理されたライフサイクル）
4章がプラットフォーム→アプリの「読み取り」なら、こちらは**プラットフォームからアプリへの「コマンド」**です。
- SIGTERM — 穏やかな停止要求。実行中リクエストの完了、接続の解放、一時ファイルの掃除を行うタイミング
-
SIGKILL — 猶予期間（デフォルト30秒、
.spec.terminationGracePeriodSecondsで調整）後の強制終了 - postStart / preStop フック — 起動直後・停止直前のフック
猶予期間は Pod ごとに定義できますが、コマンド発行時に上書きされうるため保証はされない、と釘を刺されています。コンテナ化されたアプリケーションには、迅速な起動とシャットダウンが求められます。
第6章 Automated Placement（自動配置）
スケジューラの内部原理と、外部から配置に影響を与える手段を扱う章です。
ノードの割り当て可能容量は以下で決まります。
割り当て可能容量
= ノード容量
- Kube-Reserved（kubelet、コンテナランタイム）
- System-Reserved（sshd、udev などの OS デーモン）
- Eviction Threshold（システムの OOM 防止用の予約メモリ）
システムデーモン分を予約しないと、Pod がノードの全容量まで詰め込まれ、Pod とシステムデーモンがリソースを奪い合う——結果として OOMKilled が全 Pod に波及したり、ノードが一時的にオフラインになったりします。
配置に影響を与える手段としては、ノードセレクタ、Affinity / Anti-Affinity、Taint と Toleration、トポロジースプレッド制約などが整理されています。
パートII：行動パターン（7〜14章）
Pod と管理プラットフォームの通信と相互作用に焦点を当てるパートです。「どの管理プリミティブを選ぶか」で得られる保証が変わる、という観点で読むと分かりやすくなります。
| 章 | パターン | 要点 |
|---|---|---|
| 7 | Batch Job | アトミックな作業単位を分離し、完了まで実行 |
| 8 | Periodic Job | 一時的なイベント／時刻でトリガーされる実行 |
| 9 | Daemon Service | アプリ Pod の前提となるインフラ寄り Pod をノードごとに実行 |
| 10 | Singleton Service | 同時にアクティブなインスタンスを1つに保ちつつ高可用性を維持 |
| 11 | Stateless Service | 同一・交換可能なインスタンス群の管理 |
| 12 | Stateful Service | 永続 ID・ネットワーク・ストレージ・順序性を持つアプリの管理 |
| 13 | Service Discovery | サービス提供インスタンスへの安定したエンドポイント |
| 14 | Self Awareness | イントロスペクションとメタデータ注入 |
特に読み応えのある2章
第12章 Stateful Service は、Kubernetes 史のふり返りとしても興味深い章です。初期の Kubernetes はステートフルワークロードのサポートを欠いており、当時の解は「ステートレス部分だけを Kubernetes に載せ、データストアはクラスタ外で従来手法により管理する」というものでした。あらゆる企業が大量のステートフルワークロードを抱えている以上、これは「汎用クラウドネイティブプラットフォーム」を名乗るうえで大きな制約でした。StatefulSet がこの穴を埋めた経緯が、要件（永続 ID・安定したネットワーク ID・順序性のある起動と停止）から丁寧に解説されます。
第13章 Service Discovery では、通信の向きによって必要な仕組みが変わることが整理されています。Pod からの送信接続（ポーリングコンシューマ、DB 接続、メッセージブローカーへの接続）は Kubernetes 側の追加設定を必要としません。問題になるのは外部からの刺激を待ち受ける長時間実行サービスで、動的に配置・スケールされる Pod をどう発見させるか。ここで ClusterIP / Headless Service / NodePort / LoadBalancer / Ingress といった選択肢が意味を持ちます。
パートIII：構造パターン（15〜18章）
「コンテナイメージはクラス、コンテナはオブジェクト」 という比喩から始まるパートです。ただしコンテナは単独で動くのではなく、Pod という別の抽象の中で他のコンテナと相互作用します。
| 章 | パターン | 要点 |
|---|---|---|
| 15 | Init Container | 初期化処理を本来の責務から分離したライフサイクル |
| 16 | Sidecar | 既存コンテナを変更せずに拡張・強化 |
| 17 | Adapter | 異種システムを外向けの統一インターフェースに整合させる |
| 18 | Ambassador | 外部サービスへのアクセスを分離するプロキシ |
Sidecar は「再利用性」の話である
第16章の導入部が本質を突いています。良いコンテナとは単一の Linux プロセスのように振る舞い、1つの問題をうまく解決するものであり、置き換え可能性と再利用性を念頭に設計されるべきものです。
HTTP クライアントライブラリを自作しないのと同様に、Web サーバのコンテナも自作しない。既存の高品質なコンテナを使い回す。そのためにはコンテナ同士を協調させる手段が要る——Sidecar はまさにその協調の型である、という位置づけです。
Adapter と Ambassador は Sidecar の特殊化として提示されており、この3つは親子関係で理解するのが正解のようです。
パートIV：構成パターン（19〜22章）
「設定をソースコードに置くのが一番簡単だが、それはコードと設定の同居という副作用を生む」——このパートはその一文から始まります。
継続的デリバリーにおいて、アプリケーションは一度ビルドされ、変更されずにパイプラインを通過して本番に到達するもの。コードと設定の混在はそのアンチパターンである、と明確に位置づけられます。
| 章 | パターン | 要点 |
|---|---|---|
| 19 | EnvVar Configuration | 環境変数による設定。手軽だが数が増えると破綻する |
| 20 | Configuration Resource | ConfigMap / Secret による設定保持 |
| 21 | Immutable Configuration | 設定を不変・バージョン管理下に置き、サイズ制限も回避 |
| 22 | Configuration Template | 微妙に異なる環境向けの大規模設定ファイルの管理 |
第21章の「不変性」が効いてくる場面
第21章の議論が具体的で参考になります。Kubernetes 1.21 以降、ConfigMap は immutable として宣言できるようになりましたが、サイズ制限は残ります。機械学習の事前計算済みデータモデルのような大規模設定には ConfigMap は向きません。
さらに、YAML の中に XML や YAML をネストする羽目になったときの惨状も率直に書かれています（著者自身が何度も失敗した、と告白しています）。エディタ支援が乏しく、インデントで必ず間違える——ここでコンテナイメージとして設定を配布し、実行時にリンクするというアプローチが選択肢に上がります。
「不変」とはアプリ起動後に設定を変更できないことを指し、これにより設定データの状態が常に明確に定義され、バージョン管理と変更管理プロセスに乗せられる、という整理です。
パートV：セキュリティパターン（23〜26章）
第2版で新設されたパートであり、本書最大のアップデートです。
セキュリティは開発プラクティス、ビルド時のイメージスキャン、デプロイ時の Admission Controller、実行時の脅威検出まで SDLC 全体に及び、レイヤ的にも「クラウドネイティブセキュリティの4C」（Cloud / Cluster / Container / Code）全域に関わります。そのうえで本パートは、アプリケーションと Kubernetes の交差点に絞って議論します。
| 章 | パターン | 要点 |
|---|---|---|
| 23 | Process Containment | プロセスを最小権限に封じ込める |
| 24 | Network Segmentation | Pod が参加できるトラフィックを制限する |
| 25 | Secure Configuration | 機密設定を安全に保管・使用する |
| 26 | Access Control | Kubernetes API サーバへの認証・認可 |
第23章 Process Containment
最小権限の原則を Kubernetes 上で実装する章です。
静的解析、動的スキャン、依存関係スキャン、イメージの脆弱性スキャン——どれだけチェックを重ねても、新しいコードや新しい依存関係が新たな脆弱性を生む可能性は消えません。リスクの完全な排除は保証できないという前提に立ち、Kubernetes の設定を「新たな防御線」として使う、という発想です。
具体的には SecurityContext による設定が中心になります。Pod レベルの設定は Pod のボリュームと全コンテナに適用され、コンテナレベルの設定は単一コンテナに適用され、両方に同じ設定がある場合はコンテナ仕様が優先されます。非 root ユーザーでの実行、読み取り専用ルートファイルシステム、Capability の削除などが扱われます。
第24章 Network Segmentation
Kubernetes のネットワーク空間はデフォルトでフラットであり、すべての Pod が他のすべての Pod に到達できます。Namespace はグルーピングの概念を提供するだけで、ネットワーク的な分離にはなりません。
異なるチームが運用する独立アプリケーションが同一クラスタに同居する場合、これはセキュリティ上の問題になります。Ingress 方向だけでなく Egress 方向のトラフィック制限も、侵害時の影響範囲を最小化するために必要である、と指摘されます。
かつてネットワークトポロジ構築は、ファイアウォールや iptables ルールを管理する管理者の仕事でした。しかしマイクロサービス環境ではネットワークグラフが極めて複雑になり、アプリケーションへの深い理解が求められます。NetworkPolicy によってトポロジ定義をアプリケーション側に引き寄せるというのが、このパターンの本質です。
なお、より厳密な分離要件には vcluster のようなテナントごとの仮想コントロールプレーンが必要になる場合がある、という言及もあります。
第25章 Secure Configuration
「Secret は暗号化されておらず Base64 エンコードされているだけ」という広く知られた事実から出発し、GitOps の普及がこの課題を深刻化させたと論じます。
Secret をリモート Git リポジトリに置くべきか。置くなら暗号化が必須ですが、暗号化された Secret はどこで復号されるのか。さらに、クラスタ内で暗号化保存されていても、RBAC の性質上クラスタ管理者だけは全データにアクセスできる——そのクラスタ管理者を信頼できるかどうかは、パブリッククラウドなのか全社共通基盤なのかといった環境に依存します。
解決策は大きく2系統に分類されます。
- クラスタ外暗号化 — Kubernetes の外側に暗号化された設定を保持する（Sealed Secrets、SOPS 系）
- クラスタ内での外部 Secret 管理サービス連携 — Vault などの外部システムから実行時に取得する
自前で復号処理を書く選択肢も一応あるが、ビジネスロジックと設定セキュリティが結合してしまう、と釘を刺されています。
第26章 Access Control
2022年、設定ミスにより100万近い Kubernetes インスタンスがインターネットに露出していたというセキュリティ研究者の発見が、章の導入として引かれています。
開発者は往々にしてアプリケーションレベルの認可に注目しがちですが、Operator パターン（28章）で Kubernetes を拡張する場面ではプラットフォーム側の認可が決定的に重要になります。Controller や Operator はクラスタ全体のリソースを監視するために高い権限を必要とするため、侵害時の影響を限定すべく、きめ細かなアクセス管理が不可欠です。
ServiceAccount、Role / ClusterRole、RoleBinding / ClusterRoleBinding といった RBAC の構成要素が、この文脈で解説されます。
パートVI：高度なパターン（27〜30章）
Controller や Operator のようにKubernetes 自身がその上に構築されている時代を超えたパターンと、まだ進化の途上にあるパターンが混在するパートです。著者も「本書を読む頃には変わっている可能性がある」と率直に書いています。
第27章 Controller
宣言的・リソース中心 API という Kubernetes の設計思想が、最も直截に説明される章です。
Deployment をスケールアップするとき、私たちは Kubernetes に「Pod を作れ」と命じません。Deployment リソースの replicas プロパティを変更するだけです。ではどうやって Pod が作られるのか——リソースのステータス変化のたびに Kubernetes がイベントを生成し、リスナー（コントローラ）がリソースを変更・削除・新規作成することで反応し、それがまた別のイベントを生む。この連鎖が状態調整（reconciliation） です。
目標状態と現在状態が異なるとき、それを一致させるのがコントローラの役割。この1点さえ理解すれば、Kubernetes のあらゆる挙動の説明がつくようになります。
第28章 Operator
Controller に CRD（CustomResourceDefinition） を組み合わせ、特定アプリケーションの運用知識をアルゴリズム的・自動的な形にカプセル化するパターンです。
単純な Controller は Kubernetes 固有リソースの監視・管理に限定されます。しかし「Prometheus を監視機能として Kubernetes に追加したい」となれば、監視設定とデプロイ詳細を記述する新しいドメインオブジェクトが欲しくなります。CRD はまさにそのためのものです。
本書が引く Jimmy Zelinskie の定義が的確です。
Operator とは、Kubernetes とそれ以外の2つのドメインを理解する Kubernetes コントローラである
両ドメインの知識を組み合わせることで、通常なら両方を理解した人間のオペレータが必要なタスクを自動化できる——というわけです。
第29章 Elastic Scale
スケーリングを3つの次元で整理する章です。
- 水平スケーリング — Pod レプリカ数の調整（HPA）
- 垂直スケーリング — Pod のリソース要求の調整（VPA）
- クラスタスケーリング — ノード数の変更（Cluster Autoscaler）
興味深いのは、Kubernetes が外部の負荷・キャパシティ関連イベントを監視して適応することで、予測ではなく実測に基づく「アンチフラジャイル」な特性を獲得する、という位置づけです。
一方で、手動スケーリングも正当な選択肢として扱われています。季節性と想定負荷が分かっているなら、自動スケーリングが「すでに増えた負荷」に反応するのを待つより、先回りしてスケールアウトするほうが良い場面があるためです。
第30章 Image Builder
クラスタ内でコンテナイメージをビルドするというパターンで、本書のなかでも最も踏み込んだ章です。
従来はクラスタ外でイメージをビルドし、レジストリに push し、Deployment 記述子から参照します。ではクラスタ内でビルドする利点は何か。
- ビルドと実行を1か所に集約でき、メンテナンスコストとキャパシティプランニングが簡素化される
- CI でのビルドは本質的に空きリソースを探すスケジューリング問題であり、それは Kubernetes スケジューラが最も得意とするところ
- CI から CD への移行時、同一インフラを共有できる
そして最も説得力があるのがベースイメージの脆弱性対応のシナリオです。共通ベースイメージに脆弱性が見つかったとき、それに依存する全アプリケーションイメージの再ビルドと再デプロイが必要になります。クラスタがビルドとデプロイの両方を認識していれば、ベースイメージの変更をトリガーに自動再デプロイできます。
なお本書は「2023年時点で」と明示したうえで各ツールを紹介し、読者が手に取る頃にはプロジェクトが存続しているか保証できないので確認してほしい、と正直に書いています。この誠実さは好感が持てます。
設計者視点での収穫
OOP プリミティブと分散プリミティブの対応表
第1章に載っている対比表が、本書全体の見取り図として非常に優秀です。JVM のローカルプリミティブと Kubernetes の分散プリミティブを並べたものです。
| 概念 | ローカルプリミティブ | 分散プリミティブ |
|---|---|---|
| 振る舞いのカプセル化 | クラス | コンテナイメージ |
| 振る舞いのインスタンス | オブジェクト | コンテナ |
| 再利用の単位 | .jar | コンテナイメージ |
| コンポジション | クラス A がクラス B を含む | Sidecar パターン |
| 継承 | クラス A が B を extends | コンテナの FROM 親イメージ |
| デプロイ単位 | .jar / .war / .ear | Pod |
| ビルド時／実行時の分離 | モジュール、パッケージ、クラス | Namespace、Pod、コンテナ |
| 初期化の前提条件 | コンストラクタ | Init Container |
| 初期化後トリガー | 初期化メソッド | postStart |
| 破棄前トリガー | 破棄メソッド | preStop |
| 非同期・並列実行 | ThreadPoolExecutor | Job |
| 定期タスク | Timer / ScheduledExecutorService | CronJob |
| バックグラウンドタスク | デーモンスレッド | DaemonSet |
| 設定管理 | System.getenv() / Properties | ConfigMap / Secret |
ただし著者は、これらは直接比較したり置き換えたりできるものではないと注意を促しています。異なる抽象レベルで動作し、前提条件も保証も異なります。併用が前提のものもあれば（オブジェクトを作るにはクラスが要る）、CronJob が ScheduledExecutorService を完全に代替できるケースもあります。
「クラウドネイティブへの道」の階層
第1章のもう1つの収穫は、良いクラウドネイティブアプリケーションに必要なスキルの階層です。
- クリーンコード — どんなコンテナ技術を使おうと、開発チームと成果物が最大の影響力を持つ
- ドメイン駆動設計 — 適切なビジネス／トランザクション境界と豊かな API を持つモデル
- ヘキサゴナルアーキテクチャ（およびオニオン、クリーンアーキテクチャ）— コアビジネスロジックを周辺インフラから分離し、移植性を高める
- マイクロサービス / Twelve-Factor App — スケール・回復力・変化速度への最適化
- コンテナとクラウドネイティブ — 本書が扱う領域
そして本書は明確にこう述べます。1〜4 は扱わない。しかしそれらを前提とする、と。
これらのパターンを効果的に活用するには、クリーンコードプラクティス、ドメイン駆動設計、ヘキサゴナルアーキテクチャのような外部依存関係の分離、マイクロサービス原則……を用いて、アプリケーションを内部から適切に設計する必要があります。
コンテナに不要なものを入れれば、大規模な「不要なもの」の分散システムができあがるだけ——この指摘は耳が痛いところです。Kubernetes は設計の悪さを救済してくれません。
第2版で押さえておきたい点
初版（2019年）からの主な変化は、以下のあたりです。
- セキュリティパターン（パートV）の新設 — Process Containment / Network Segmentation / Secure Configuration / Access Control の4章がまるごと追加
- セキュリティが「別立ての章」ではなくパターン言語の一部に組み込まれたこと自体が、この数年のクラウドネイティブ運用の成熟を反映しています
- Elastic Scale や Image Builder といった高度パターンが、2023年時点のツールエコシステムを踏まえて更新
-
kubectl rolling-updateの廃止（1.18）とkubectl rolloutへの移行、immutable ConfigMap（1.21）など、API の変遷が反映されています
読みどころと注意点
良かった点
- 章が独立していて、どこからでも読める。パターン本として理想的な構成です
- 「議論」セクションで欠点も書く姿勢。銀の弾丸として売り込まない誠実さがあります
- OOP との対比が一貫しており、アプリケーション開発者が既存の語彙で理解できます
- 具体的な YAML 例が各章に配置され、抽象論に終わりません
気をつけたい点
- Kubernetes の入門書ではありません。Pod / Deployment / Service を触ったことがない状態で読むと、第1章の時点で厳しいはずです
- 一部の高度パターンはエコシステムの変化が速い領域を扱っており、ツール選定の記述は鮮度が落ちます（著者自身が明言しています）
- 日本語で読む場合、パターン名の訳語は原著の英語名と併せて覚えておくのが無難です（Operator、Ambassador など）
こんな人におすすめ
- Kubernetes は使えるが、設計判断の根拠を言語化したい方
- マイクロサービス基盤の設計・レビューをする立場の方
- Operator や CRD で自前の拡張を書こうとしている方
- GoF や PoEAA を通ってきた方（パターン本としての読み味が近いです）
まとめ
本書のあとがきに、著者の見立てが端的に述べられています。
Kubernetes とそこから派生する概念は、オブジェクト指向プログラミングの概念と同じくらい基本的なものになると私たちは確信しています。
やや大きな主張に聞こえますが、通読してみると納得感があります。宣言的 YAML API と非同期の調整プロセスは、いまやリソースオーケストレーションのパラダイムそのものになりました。CRD と Operator は、ドメイン知識を分散システムに融合させる一般的な拡張メカニズムです。Kubernetes はすでに単なるコンテナオーケストレータを超え、クラスタ内・クラスタ外・マルチクラスタのリソースを扱う汎用の運用モデルになっています。
だとすれば、これらのパターンを知っているかどうかは、モダンなアプリケーションを設計できるかどうかに直結することになります。
個人的に一番効いたのは、基礎パターンが相互に依存しているという構造の発見でした。Declarative Deployment が機能するには Health Probe と Managed Lifecycle が必要で、Automated Placement が機能するには Predictable Demands が必要。「YAML を書けること」と「Kubernetes に乗せられるアプリケーションを書けること」の間には、はっきりとした差があります。
そして本書は、その差を埋めるための語彙を提供してくれます。
kubectl を楽しんでください。
あとがきの最後の一文です。読み終えたあと、たしかにその気分になります。
参考
- Bilgin Ibryam, Roland Huß『Kubernetes Patterns, 2nd Edition』O'Reilly Media
- 著者について：Bilgin Ibryam は Diagrid のプロダクトマネージャー（元 Red Hat、Apache Software Foundation メンバー、『Camel Design Patterns』著者）。Roland Huß は Red Hat で OpenShift Serverless のアーキテクトを務める25年以上の経験を持つエンジニア（元 Knative TOC メンバー）
- 序文：Brendan Burns（Kubernetes 共同創業者）