プレイブック

可能な限り最小で、同じ場所に配置されるワークロードユニットをデプロイする。

→`Pod` リソースを定義します。Podは、ネットワークとストレージを共有する1つまたは複数のコンテナを含むことができます。

理由: PodはKubernetesにおけるスケジューリングの原子単位です。コンテナは常にPod内でデプロイされます。

リファレンス↗

クラスタの状態が継続的に望ましい状態と一致するようにする。

→`kube-controller-manager` に依存します。これは、リソース（例：ReplicaSets、Deployments）を監視し、差異を調整する制御ループを実行します。

理由: これは宣言的で自己修復的な中核メカニズムです。ReplicaSetによって管理されているPodが停止した場合、コントローラは自動的にそれを置き換えます。

新しく作成されたPodを最も適切なワーカーノードに自動的に割り当てる。

→`kube-scheduler` に依存します。これは、Podの要件（例：リソース要求）に基づいてノードをフィルタリングし、最適なものを選択するためにスコアリングします。

理由: スケジューラは、ポリシー、アフィニティ、可用性に基づいて配置決定を行い、ユーザーからノード選択を抽象化します。

Podで指定されたコンテナが、特定のワーカーノードで実行されており、かつ正常であることを保証する。

→`kubelet` エージェントはすべてのノードで実行され、APIサーバーと通信し、コンテナランタイムを介してコンテナのライフサイクル（起動、停止、ヘルスチェック）を管理します。

理由: Kubeletはコントロールプレーンとワーカーノード間のリンクであり、Podの仕様を実行します。

Kubernetesクラスタのすべての状態と設定を確実に永続化する。

→一貫性があり高可用性なキーバリューストアである `etcd` を使用します。これはクラスタの単一の真実の情報源として機能します。

理由: すべてのクラスタオブジェクト（Pod、Serviceなど）はetcdに保存されます。APIサーバーのみが直接etcdと通信します。

Kubernetes Serviceを介した通信を可能にするために、各ノードにネットワークルールを実装する。

→各ノード上の `kube-proxy` コンポーネントは、Service IPからのトラフィックを正しいバックエンドPodに転送するネットワークルール（例：iptables、IPVS）を維持します。

理由: Kube-proxyはService抽象化の背後にある実装の詳細であり、ロードバランシングとルーティングを処理します。

単一のKubernetesクラスタを、複数のチーム、プロジェクト、または環境のために論理的にパーティション分割する。

→`Namespace` リソースを作成します。Namespaceは、名前のスコープと、認証やポリシー（例：ResourceQuotas）をアタッチする方法を提供します。

理由: Namespaceは、複数のクラスタのオーバーヘッドなしに、マルチテナンシーとリソースの組織化を可能にします。

一時的なPodのセットに対して、安定したネットワークエンドポイント（IPおよびDNS）を提供する。

→ラベルセレクタを使用してPodのセットをターゲットとする `Service` リソースを定義します。

理由: Podは一時的であり、IPアドレスは変化します。Serviceは、正しいPodにトラフィックをロードバランシングする永続的な抽象化を提供します。

リファレンス↗

Podで実行されているアプリケーションを異なるネットワークスコープに公開する。

→Serviceの `type` を選択します: `ClusterIP` （内部のみ、デフォルト）、`NodePort` （各ノードのIP:portで公開）、または `LoadBalancer` （クラウドロードバランサーをプロビジョニング）。

理由: Serviceのタイプは、アプリケーションのアクセス性を、純粋な内部から完全に外部まで決定します。

Serviceプロキシをバイパスして、個々のPodの直接ネットワークディスカバリを有効にする。

→`clusterIP: None` を持つ `Service` を作成します。これにより、各PodのDNS Aレコードが作成され、クライアントがPodに直接接続できるようになります。

理由: ピアツーピア通信や安定したPodの識別が必要なデータベースのようなステートフルなアプリケーション（多くの場合StatefulSetを使用）にとって不可欠です。

Kubernetesオブジェクトのサブセットを整理し、選択する。

→オブジェクトにキーバリューの `labels` （例：`app: my-api`）をアタッチします。他のオブジェクト（例：Service、Deployment）で `label selectors` を使用してそれらをターゲットにします。

理由: ラベルはKubernetesにおける中核的なグルーピングメカニズムであり、リソース間の疎結合を可能にします。

アプリケーション設定をコンテナイメージから分離する。

→非機密設定データを `ConfigMap` に保存します。ボリュームとしてマウントするか、環境変数としてPodにキーを注入します。

理由: これにより、12-Factor Appの原則に従い、アプリケーションコードとは独立して設定を管理できます。

パスワード、トークン、APIキーなどの機密データをアプリケーションが使用するために保存する。

→`Secret` オブジェクトを使用します。ボリュームとしてマウントするか、環境変数として注入します。

理由: Secretは機密データ専用であり、ConfigMapよりも安全に扱われます（例：デフォルトでは `kubectl describe` に表示されず、保存時に暗号化可能）。

Podの再起動後も存続するストレージをステートフルアプリケーションに提供する。

→Podはストレージを要求するために `PersistentVolumeClaim` (PVC) を作成します。管理者はその要求を満たす `PersistentVolume` (PV) をプロビジョニングします。

理由: これにより、ストレージの消費（PVC）とストレージのプロビジョニング（PV）が分離され、ポータブルなワークロード定義が可能になります。

コンテナのCPUとメモリ割り当てを管理する。

→保証されたリソース（スケジューリングに使用）には `resources.requests` を設定し、最大許容使用量（実行時に強制）には `resources.limits` を設定します。

理由: RequestはPodが実行に十分なリソースを持つことを保証し、LimitはPodが過剰なリソースを消費して他のワークロードに影響を与えるのを防ぎます。

ネームスペースに集約的なリソース制約を設定する。

→`ResourceQuota` オブジェクトを作成して、ネームスペースで作成できるCPU、メモリ、またはオブジェクト（Pod、Service）の総量を制限します。

理由: ResourceQuotaは、マルチテナント環境において公平なリソース共有を保証し、過剰な消費を防ぐために不可欠です。

バージョン管理された設定ファイルを使用してKubernetesリソースを管理する。

→`kubectl apply -f <filename.yaml>` を使用します。このコマンドは、ファイルの内容に基づいてリソースを作成または更新します。

理由: `apply` は宣言的であり、GitOpsやCI/CDに最適です。変更を追跡し、3-wayマージを実行するため、命令的な `create` や `replace` よりも安全です。

Podが正しく実行されていない理由（例：Pending、ContainerCreating、またはCrashLoopBackOffで停止している）を診断する。

→`kubectl describe pod <pod-name>` を使用します。下部の `Events` セクションで、スケジューラ、kubelet、またはコントローラからの詳細なメッセージを確認します。

理由: `describe` は、リソースのライフサイクルに関する問題をデバッグするための主要なツールである時系列イベントログを提供します。

コンテナにネットワーク機能を提供し、クラスタ全体のPod間通信を可能にする。

→Container Network Interface (CNI) プラグイン（例：Calico、Flannel、Cilium）を使用します。各ノードのkubeletはCNIプラグインを使用して各Podのネットワークを設定します。

理由: CNIは標準インターフェースを提供し、コアコンポーネントを変更することなくKubernetesをさまざまなネットワークソリューションと統合できるようにします。

ユーザーおよびアプリケーションのKubernetes APIリソースへのアクセスを制御する。

→ロールベースアクセス制御 (RBAC) を使用します。権限を持つ `Role`（ネームスペーススコープ）または `ClusterRole`（クラスタースコープ）を定義し、`RoleBinding` または `ClusterRoleBinding` を使用してそれをサブジェクト（ユーザー、グループ、ServiceAccount）にバインドします。

理由: RBACはKubernetesを保護するための標準であり、すべてのAPIインタラクションに対して最小特権の原則を可能にします。

リファレンス↗

ステートレスアプリケーションを管理し、簡単な更新とロールバックを可能にする。

→`Deployment` ワークロードを使用します。これはReplicaSetを管理し、望ましい数のPodレプリカが実行されていることを保証し、宣言的な更新戦略を提供します。

理由: Deploymentはステートレスアプリケーションの標準であり、スケーリングとローリングアップデートの詳細を抽象化します。

リファレンス↗

安定したネットワークIDとストレージを必要とするステートフルアプリケーション（例：データベース）をデプロイする。

→`StatefulSet` ワークロードを使用します。これは各Podに安定した一意のホスト名と、再起動後も追従する永続ストレージを提供します。

理由: Deploymentとは異なり、StatefulSetはアイデンティティを持つPodを管理し、順序付けられたデプロイとスケーリングを保証します。これはステートフルシステムにとって重要です。

クラスタ内のすべてのノードにエージェント（例：ログコレクタ、監視エージェント）をデプロイする。

→`DaemonSet` ワークロードを使用します。これは、各ノード（またはノードのサブセット）でPodのコピーが実行されることを保証します。

理由: DaemonSetはノードレベルサービスの配布を自動化し、新しいノードがクラスタに参加すると自動的にスケーリングします。

完了まで実行する必要がある、有限の1回限りのタスクを実行する。

→`Job` リソースを使用します。これは1つまたは複数のPodを作成し、それらが正常に終了することを保証します。

理由: Jobはバッチ処理用であり、継続的なサービス用のDeploymentとは異なります。Podは正常完了後に置き換えられません。

定期的なスケジュール（例：毎晩のバックアップ、レポート）でタスクを実行する。

→`CronJob` リソースを使用します。これはcronスケジュール文字列に基づいてJobを作成します。

理由: CronJobは、時間ベースの定期的なタスクを管理するためのKubernetesネイティブな方法を提供します。

応答しなくなったコンテナ（例：デッドロック）を自動的に再起動する。

→コンテナスペックに `livenessProbe` を設定します。プローブが失敗した場合、kubeletがコンテナを再起動します。

理由: Liveness Probeは、クラッシュせずに破損した状態に陥る可能性のあるアプリケーションに対し、強力な自己修復メカニズムを提供します。

まだリクエストを処理する準備ができていないコンテナにトラフィックが送信されるのを防ぐ。

→コンテナスペックに `readinessProbe` を設定します。プローブが成功した後にのみ、PodはServiceエンドポイントに追加されます。

理由: Readiness Probeは、ダウンタイムなしのローリングアップデートにとって不可欠であり、新しいPodが本番トラフィックを受信する前に完全に初期化されていることを保証します。

メインアプリケーションコンテナを開始する前に、セットアップタスクを実行したり、依存関係が準備完了になるのを待ったりする。

→Podスペックに1つまたは複数の `initContainers` を定義します。これらは、アプリケーションコンテナが開始される前に順番に完了まで実行されます。

理由: Init Containerはセットアップロジックをきれいに分離し、メインアプリケーションコンテナを散らかすことなく前提条件が満たされていることを保証します。

Podが特定の特性を持つノード（例：GPU、SSDを持つノード）にスケジュールされることを保証する。

→Podスペックで `nodeAffinity` を使用し、ノードラベルに基づいてルールを設定します。「必須」（ハード）または「推奨」（ソフト）の制約を設定できます。

理由: Node affinityは `nodeSelector` よりも表現力があり、ノードのプロパティに基づいてPodの配置を制御する現代的な方法です。

パフォーマンスまたは高可用性のために、Podの相互の共存を制御する。

→`podAffinity` を使用してPodを一緒にスケジュールするか（例：同じノード上）、`podAntiAffinity` を使用してPodを分散させます（例：異なるノードまたはゾーン全体）。

理由: Anti-affinityは、サービスのレプリカが同じ障害ドメインにないことを保証するために重要であり、それによって可用性を高めます。

汎用Podが専用または特殊な目的のノードにスケジュールされるのを防ぐ。

→ノードに `Taint` を適用します。Podは、そのノードにスケジュールされるために、スペックに一致する `Toleration` を持っている必要があります。

理由: TaintとTolerationは、ノードが明示的に実行を許可されたワークロードのために予約されることを保証します。

ゾーンやノードなどの障害ドメイン全体にPodを均等に分散させることで、高可用性を保証する。

→Podスペックで `topologySpreadConstraints` を定義し、ラベルとトポロジーキー（例：`topology.kubernetes.io/zone`）に基づいてPodがどのように分散されるかを制御します。

理由: これはPodアンチアフィニティよりもHAに対してよりきめ細かい制御を提供し、すべてのレプリカが単一の場所に集中するのを防ぎます。

観測された負荷に基づいてアプリケーションレプリカの数を自動的にスケーリングする。

→Deploymentをターゲットとし、メトリック（例：CPU使用率）とターゲット値を指定する `HorizontalPodAutoscaler` (HPA) リソースを作成します。

理由: HPAは弾力的なスケーリングを可能にし、手動での介入なしに、負荷時のパフォーマンスを確保しつつ、閑散期にはコストを節約します。

リファレンス↗

リソースの需要に合わせて、クラスタからワーカーノードを自動的に追加または削除する。

→`Cluster Autoscaler` をデプロイします。これはスケジュールできないPod（リソース不足のため）を監視し、ノードを追加したり、利用率の低いノードを削除したりします。

理由: Cluster Autoscalerはインフラレベルの弾力性を管理し、クラウドプロバイダと連携してワークロードのニーズに基づいてクラスタサイズを調整します。

自発的な中断（例：ノードアップグレード）中に、最小限のアプリケーションレプリカが利用可能であることを保証する。

→Podのセットに対して `minAvailable` または `maxUnavailable` を指定する `PodDisruptionBudget` (PDB) を作成します。

理由: PDBは、`kubectl drain` のようなアクションが一度に多数のレプリカを停止させるのを防ぎ、アプリケーションの可用性を保護します。

ステートレスアプリケーションに対してゼロダウンタイムの更新を実行する。

→デフォルトの `RollingUpdate` 戦略を持つ `Deployment` を使用します。`maxSurge` と `maxUnavailable` を設定して更新プロセスを制御します。

理由: ローリングアップデートは古いPodを新しいものに徐々に置き換えることで、更新中もサービスが利用可能であることを保証します。

バージョン管理と監査証跡を使用して、インフラストラクチャとアプリケーションのデプロイを宣言的に管理する。

→GitOpsを実装します。Gitリポジトリを単一の真実の情報源として使用します。Argo CDやFluxのようなツールを使用して、クラスタの状態をGitと自動的に同期します。

理由: GitOpsはすべての変更の明確で監査可能な履歴を提供し、Gitコミットを元に戻すことで簡単なロールバックを可能にします。これはInfrastructure as Codeを運用化します。

複雑なKubernetesアプリケーションを再利用可能でバージョン管理された方法でパッケージ化、設定、デプロイする。

→Kubernetesのパッケージマネージャである `Helm` を使用します。アプリケーションを、テンプレート化されたマニフェストと設定可能な `values.yaml` ファイルを持つ `Charts` としてパッケージ化します。

理由: Helmは、多数のコンポーネントを持つ複雑なアプリケーションの管理を簡素化し、依存関係、バージョン管理、ライフサイクル管理を処理します。

テンプレートを使用せずに、異なる環境向けにKubernetesマニフェストをカスタマイズする。

→`Kustomize` を使用します。ベース設定を指定し、各環境にパッチまたはオーバーレイを適用する `kustomization.yaml` ファイルを定義します。

理由: Kustomizeは、設定バリアントを管理するための宣言的でテンプレート不要な方法を提供します。これは、テキストベースのテンプレートよりもシンプルでエラーが発生しにくい場合があります。

新しいアプリケーションバージョンを、本格的なロールアウトの前に、本番トラフィックの小さなサブセットでテストする。

→新しいバージョンを古いバージョンと並行してデプロイします。サービスメッシュまたはIngressコントローラを使用して、トラフィックのごく一部（例：5%）を新しい「カナリア」バージョンにルーティングします。

理由: カナリアリリースは、影響範囲を限定し、本番環境でのテストを可能にすることで、不良なリリースが導入されるリスクを低減します。

ゼロダウンタイムと即時ロールバック機能で新しいアプリケーションバージョンをデプロイする。

→既存の「ブルー」バージョンと並行して新しい「グリーン」バージョンをデプロイします。グリーンバージョンが検証されたら、Service/ルータレベルでトラフィックの100%をブルーからグリーンに切り替えます。

理由: ブルーグリーンデプロイはダウンタイムをなくします。ロールバックは、トラフィックをブルー環境に戻すのと同じくらい簡単です。

複雑なアプリケーションを、小さく、独立した、疎結合なサービスの集合体として設計する。

→アプリケーションをマイクロサービスとして構成し、それぞれがビジネス機能を中心に編成されます。各サービスは独自のデータを所有し、明確に定義されたAPIを介して通信する必要があります。

理由: このアーキテクチャにより、サービスの独立した開発、デプロイ、スケーリングが可能になり、俊敏性と回復力が向上します。

確立されたベストプラクティスに従って、ポータブルでスケーラブルなクラウドネイティブアプリケーションを構築する。

→Twelve-Factor Appの方法論に準拠します。主要な原則は、環境間で異なるすべての設定を環境変数に保存することです。

理由: これにより、設定がコードから厳密に分離され、同じコンテナイメージを環境間で変更なしに昇格させることができます。

リファレンス↗

複雑なサービス間通信を管理し、トラフィック管理、セキュリティ、および可観測性を提供する。

→サービスメッシュ（例：Istio、Linkerd）を実装します。これは各Podにサイドカープロキシを注入し、すべてのネットワークトラフィックを傍受および管理します。

理由: サービスメッシュは、ネットワークに関する懸念事項（mTLS、リトライ、サーキットブレーキング）をアプリケーションコードから抽象化し、プラットフォームレベルで強制します。

アプリケーションコンテナのコードを変更することなく、その機能を拡張または強化する。

→メインアプリケーションと同じPodに「サイドカー」コンテナをデプロイします。これは同じネットワークとストレージを共有します。

理由: サイドカーは、ロギング、監視、プロキシ（サービスメッシュの場合など）といった横断的な懸念事項に使用され、関心の分離を促進します。

分散システムの動作に関する深い洞察を得て、トラブルシューティングを容易にする。

→可観測性の3つの柱を実装します: `Metrics`（集計された数値データ）、`Logs`（離散イベント）、`Traces`（エンドツーエンドのリクエストフロー）。

理由: これらのデータタイプは合わせて、システムの健全性とパフォーマンスの包括的なビューを提供し、これは複雑なマイクロサービスアーキテクチャにとって不可欠です。