Kubernetesパターン 第2版 輪読会報告
#SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。
この記事では、2024年11月から2025年2月にかけて社内で実施したKubernetes関連書籍の輪読会について紹介します。
経緯
この書籍は、昨年9月に翻訳者の松浦隼人さんから書評用としていただいたものです。ただ、当時は仕事が立て込んでおり、十分に読む時間が取れず、書評を出せないままになっていました。
ちょうどその頃、チーム内でも何人かがこの本を購入しており、「せっかくなら一緒に読んで議論しよう」という流れで輪読会を開くことになりました。
書評を書けなかったお詫びとして、自分なりのアウトプットとして、社内での実践的な輪読会の様子をまとめた記事を公開することにしました。
開催スタイル
一般的な輪読会では、担当者が発表し、それ以外のメンバーはあまり読み込まないことが多く、議論が深まりにくいという課題があります。そこで今回の輪読会では、全員が同じタイミングで該当箇所を読み、各自が気になった点や疑問を事前にメモに残すスタイルを採用しました。
30分〜1時間の枠で、各メンバーが自分のメモをもとに発表し、それに対して自由にコメントや補足を加える形式です。部によっては議論が多くなることもあり、必要に応じてさらに部を細かく分けて取り上げました。
以下に、実際に共有されたメモの例を紹介します。
輪読会報告
ここからは書籍の内容をもとに、各部ごとの概要と議論のポイントを紹介します。
第一部
第1部「基本パターン」では、Kubernetes上でアプリケーションを運用するうえで欠かせない、設計と運用の基本が整理されています。
アプリケーションがどのようにリソース要求を宣言し、どのようにデプロイされ、健全性を保ち、ライフサイクルイベントに応答し、最終的にどのようにノードへ配置されるか——Kubernetesの観点でこの流れを整理しています。
特に関心が集まったのは、第2章「予想可能な需要（Predictable Demand）」で扱われているリソース制御まわりです。実運用に直結する内容が多く、以下のような意見や議論が交わされました。
- と の設計は極めて重要
- 特に CPU の は設定しないほうが安定するという知見は、過去のトラブルと結びついて印象に残った
- メモリは と を揃えるべきという原則を改めて確認できた
- QoS クラスや Eviction の挙動は理解しておくべき
- の導入は設計方針の判断が必要になる。適当に設定するとシステム全体に悪影響を与えるリスクがある
- は、思わぬリソースバーストを防ぐ最後の砦として有効で、導入の検討余地がある
このほか、Deployment戦略やヘルスチェックのベストプラクティス、ライフサイクルフックの使い方、スケジューリング最適化など、どれも現場の設計やトラブルシューティングで役立つ内容でした。
第二部
第二部「振る舞いパターン」では、Podの実行時のふるまいにフォーカスし、それをKubernetesがどのように支援・制御できるかが整理されています。ワークロードの種類やサービスの特性に応じて、適切な構成をどう選ぶかという視点で構成されており、実行時の設計と運用に役立つ知識が整理されていました。
バッチ処理を管理する や 、ノード単位での処理に向いた 、厳密な順序や永続性が求められる など、Kubernetesが提供する主要なリソースについて、その使いどころや落とし穴が整理されています。
加えて、、、サービスディスカバリなど、実際の運用に直結する機能も押さえられており、実践的な構成でした。
議論では次のような意見や学びが共有されました。
- の運用は依然として難易度が高く、本番環境では慎重な設計が求められる
- は便利だが、副作用が起きやすく、トラブルの温床になるケースも多い（「Kubernetesの問題はだいたいDaemonSetの問題」）
- と の違いが曖昧なまま使われがちで、挙動の正確な理解が必要
- の詳細設定（ や など）は意外と知られておらず、制御力が高い割に活用されていない
- と を組み合わせることで、分散ロック的な制御も可能になるなど、設計の幅が広がる
多様な実行形態を支えるこれらのパターンは、サービスの信頼性や拡張性に直結する重要な要素です。第二部はその設計判断の精度を高めるうえで、多くの気づきが得られる内容でした。
第三部
第三部「構造化パターン」と第四部「設定パターン」は、いずれもKubernetesにおける実践的な設計・運用ノウハウを扱っており、設計の参考になる実践的な知見が詰まっていました。
構造化パターンでは、Pod内に複数コンテナをどう配置するかという観点から、、、、 などのパターンが整理されています。責務の分離、既存機能の拡張、プロキシ設計など、実際の設計に応用しやすい内容でした。
議論では次のようなポイントが共有されました。
- のデバッグは依然扱いづらく、 を入れて検証する手法が現実的な選択肢として評価された
- の設計意図（透過型()か明示的()か）を明確にしておかないと、運用で混乱が起きやすい
- は意識せず使っているケースが多く、全体像の理解が深まった
- は特にレガシー連携に有効で、 との使い分けがアーキテクチャ設計に影響する
第四部
第四部の設定パターンでは、アプリケーションの設定管理をどう扱うかという観点から、、（ConfigMap/Secret）、、 が紹介されていました。
とくに印象的だった声は以下のとおりです。
- 環境変数は変更が効かず、柔軟な運用には不向きとの声が多かった
- や のホットリロードは便利だが、トラッキングや再起動の挙動には注意が必要
- Secretの保存方式（ や の暗号化設定など）について改めて理解を深められた
- は安定性を高める反面、導入時の設計が複雑になりやすいという指摘もあった
- は避けたいという意見もある一方で、大規模展開では避けられない現実も共有された
いずれのパターンも、CI/CDの設計やチームの運用方針と密接に関係するトピックです。個々の選択肢を知識として学ぶだけでなく、「自分たちの運用にどう落とし込めるか」という視点で議論できたのは大きな成果でした。
第五部
第五部「セキュリティパターン」では、Kubernetes上でアプリケーションを安全に運用するための基本方針と実践例がさまざまな観点から紹介されました。攻撃対象の最小化、機密情報の保護、アクセス制御といった観点を軸に、セキュリティ設計の考え方と実際の課題もわかりやすく整理されており、現場ですぐに使える内容が多く含まれていました。
議論では特に以下の点に関心が集まりました。
- コンテナの 設定は、シンプルかつ強力な対策として評価されました。現在のOSSがrootless設計を前提とする流れとも合致しており、標準設定として定着させるべきとの声が多数
- Pod Securityのアノテーション管理（）については、「なぜ今まで使ってこなかったのか」との声もあり、簡潔さと効果の両立が高く評価された
- と（Istioなど）の併用による多層的な制御設計に注目が集まり、より具体的な運用例への関心も高まった
- Secret管理に関しては、Sealed SecretやVault、CSI Driverなどの選択肢は豊富だが、いずれも運用の複雑さがネックとなりやすく、「やりたくないが避けられない領域」として共感があった
- RBAC制御における 権限の存在や、ABACの静的構成に対する批判的意見もあり、Kubernetesにおけるアクセス制御の難易度と設計責任の重さを改めて認識した
セキュリティはややもすれば開発体験を損ねる領域でもあり、どこまでを守るかの線引きは常に難しい課題です。後回しにされがちなセキュリティについて立ち止まって考える良いきっかけとなりました。
第六部
第六部「高度なパターン」では、Kubernetesの拡張性や自律的な運用を支えるパターン(やなど)が紹介されています。
ただし今回の輪読会では、この部に関する読書や議論は実施していません。参加者の多くがOperator開発の経験を持たず、また現状のSRE業務においても関与機会が少ないため、優先度は高くないと判断されました。
一方で、将来的にIDP（）構築や、より高度なPlatform Engineeringに関心を持つメンバーもおり、中長期的には避けて通れない領域であると共感されました。現場とはまだ距離があるものの、将来に向けて意識しておきたい領域です。
終わりに
今回の輪読会の内容を通じて、Kubernetesにおける設計・運用の知見をチーム全体で深めることができました。翻訳者の松浦隼人氏には、本書の日本語版をご提供いただき、心より感謝申し上げます。高品質な翻訳により、複雑な技術的内容もスムーズに理解でき、実践的な議論につなげることができました。ご興味を持たれた方は、ぜひ本書を手に取ってみてください。
SRG では一緒に働く仲間を募集しています。
ご興味ありましたらぜひこちらからご連絡ください。