プレイブック

コマンドラインのキーと値のペアからConfigMapまたは汎用Secretを作成する。

→`kubectl create configmap <name> --from-literal=<key>=<value>`または`kubectl create secret generic <name> --from-literal=<key>=<value>`を使用します。

理由: `--from-literal`は、直接キーと値を入力するためのものです。複数のキーに対しては、このフラグを複数回使用します。これは、単純なケースでYAMLファイルを作成するよりも高速です。

リファレンス↗

ConfigMapまたはSecretのすべてのキーと値のペアを環境変数としてコンテナに注入する。

→コンテナのspecで`envFrom`と`configMapRef`または`secretRef`を使用します。例: `envFrom: [{configMapRef: {name: my-config}}]`。

理由: `envFrom`は、ソースからのすべてのキーを環境変数にマッピングする一括操作です。これにより、各キーを手動でリストアップする手間が省けます。

リファレンス↗

ConfigMapまたはSecretから単一の特定の値を環境変数として注入する。

→`env.valueFrom`を使用します。例: `env: [{name: LOG_LEVEL, valueFrom: {configMapKeyRef: {name: my-config, key: log_level}}}]`。

理由: `valueFrom`は選択的な注入を提供し、ソースキーを異なる環境変数名にマッピングすることを可能にします。

ConfigMapまたはSecretをPodにファイルとしてマウントし、ライブ更新を可能にする。

→`configMap`または`secret`タイプの`volume`を定義します。`volumeMounts`を使用してコンテナにマウントします。ファイル名はキーと同じになります。

理由: ConfigMap/Secretからマウントされたファイルは、ソースが変更されると自動的に更新されます。環境変数は更新されず、Podの再起動が必要です。

リファレンス↗

セキュリティのベストプラクティスを強制する: rootでの実行を防ぐ、rootファイルシステムを読み取り専用にする、またはユーザーIDを指定する。

→Podまたはコンテナレベルで`securityContext`を使用します。`runAsNonRoot: true`、`readOnlyRootFilesystem: true`、および/または`runAsUser: <UID>`を設定します。

理由: SecurityContextは、コンテナの権限に対するきめ細かく宣言的な制御を提供し、アプリケーションの堅牢化とセキュリティポリシーへの準拠に不可欠です。

リファレンス↗

PodにKubernetes APIへの最小限のアクセス権限を付与する。

→1. カスタムの`ServiceAccount`を作成します。2. 必要なAPI権限（例: Podのリスト表示）のみを持つ`Role`を作成します。3. `RoleBinding`を作成してServiceAccountとRoleをリンクします。4. `spec.serviceAccountName`を介してServiceAccountをPodに割り当てます。

理由: 最小権限の原則に従い、Podが侵害された場合の攻撃対象領域を最小限に抑えます。

APIアクセスを必要としないPodへのServiceAccountトークンの自動マウントを防ぐ。

→PodのspecまたはServiceAccount自体で`automountServiceAccountToken: false`を設定します。

理由: APIクレデンシャルを必要としないコンテナに提供しないことで、攻撃対象領域を減らします。

Ingressまたはその他のセキュアなサービスでのTLSターミネーションに使用するSecretを作成する。

→`kubectl create secret tls <secret-name> --cert=<path/to/cert.pem> --key=<path/to/key.pem>`を使用します。

理由: これにより、Ingressコントローラーが期待する標準の`tls.crt`および`tls.key`データキーを持つ正しいタイプ`kubernetes.io/tls`のSecretが作成されます。

Podのメタデータ（名前、Namespace、ラベル、ノードIPなど）をコンテナに公開する。

→Downward APIを使用して、メタデータを環境変数または`downwardAPI`ボリューム内のファイルとして投影します。例: `valueFrom: {fieldRef: {fieldPath: metadata.name}}`。

理由: コンテナがKubernetes APIをクエリすることなく自己認識できるようにし、設定を簡素化し、RBAC要件を減らします。

リファレンス↗

Namespace内のすべてのPodにデフォルトのCPU/メモリリクエストと制限を設定する。

→Namespaceに`LimitRange`オブジェクトを作成します。リソースの`default`および`defaultRequest`値を定義します。

理由: 開発者が指定を忘れた場合でも、すべてのPodにリソース制約が設定されるようにし、スケジューリングと安定性を向上させます。ResourceQuotaと連携して機能します。

Namespace内で消費できるリソース（CPU、メモリ、オブジェクト数）の総量を制限する。

→`ResourceQuota`オブジェクトを作成します。`spec.hard`で厳密な制限（例: `requests.cpu: "4"`, `pods: "10"`）を定義します。

理由: あるNamespaceまたはチームがクラスターのすべてのリソースを消費するのを防ぎ、公平なリソース割り当てを保証します。

メインアプリケーションが起動する前に、前提条件タスク（例: データベースの待機、マイグレーションの実行、データのプル）を実行する。

→Podのspecに1つ以上の`initContainers`を定義します。これらはメインアプリケーションコンテナが起動する前に順次実行され、完了します。

理由: セットアップロジックをアプリケーションコンテナから分離し、アプリケーションが起動する前に依存関係が満たされることを保証します。

リファレンス↗

ロギング、モニタリング、プロキシなどのヘルパー機能で主要なアプリケーションコンテナを拡張する。

→Podのspecに2番目のコンテナ（サイドカー）を追加します。両方のコンテナはネットワークやボリュームなどのリソースを共有します。

理由: メインアプリケーションコードを変更することなく機能を強化し、関心の分離を促進します。

同じPod内のコンテナ間で読み書き用のディレクトリを共有する。

→Podのspecで`emptyDir`ボリュームを定義し、必要なすべてのコンテナにマウントします。

理由: `emptyDir`はPodの寿命の間存在するシンプルで一時的なストレージボリュームを提供し、Pod内でのデータ共有に最適です。

コンテナイメージのデフォルトのENTRYPOINTおよび/またはCMDを上書きする。

→コンテナのspecで、ENTRYPOINTを上書きするために`command`を使用し、CMDを上書きするために`args`を使用します。`command: ["/bin/sh"], args: ["-c", "echo hello"]`。

理由: Pod定義からコンテナの起動コマンドを完全に制御でき、汎用イメージを適応させるのに役立ちます。

並列処理と成功完了数を制御しながら、有限のタスクを完了まで実行する。

→`Job`リソースを使用します。ターゲットの成功数には`spec.completions`を、同時実行Podの数には`spec.parallelism`を設定します。再試行を制御するには`spec.backoffLimit`を使用します。

理由: Jobは、長時間実行されるDeploymentとは異なり、完了まで実行されるタスクのために設計されています。これらの設定は、バッチワークロードを管理するための鍵です。

cron構文を使用して定期的なタスクをスケジュールし、重複するジョブの処理方法を制御する。

→`CronJob`リソースを使用します。`spec.schedule`をcron形式（例: `*/5 * * * *`）で定義します。`spec.concurrencyPolicy`を`Allow`、`Forbid`、または`Replace`に設定します。

理由: スケジュールされたタスクを自動化します。`concurrencyPolicy`は、重複実行を防ぐ（`Forbid`）または古いものを置き換える（`Replace`）ために重要です。

クラスターに作成せずに、リソースのYAMLマニフェストを迅速に生成する。

→命令型コマンドで`--dry-run=client -o yaml`フラグを使用します。例: `kubectl run nginx --image=nginx --dry-run=client -o yaml > pod.yaml`。

理由: カスタマイズ可能で、宣言的に適用できる有効なマニフェストを足場として提供することで時間を節約します。

Deploymentを命令的に更新、スケール、ステータス確認、履歴表示、ロールバックする。

→`kubectl set image`、`kubectl scale`、`kubectl rollout status`、`kubectl rollout history`、および`kubectl rollout undo`を使用します。

理由: これらは、開発中およびトラブルシューティング中にデプロイされたアプリケーションのライフサイクルを管理するためのコアとなる命令型コマンドです。

可用性を確保するために、Deploymentの更新速度と安全性を制御する。

→`spec.strategy.rollingUpdate`で、`maxSurge`（作成できる追加Podの数）と`maxUnavailable`（停止できるPodの数）を設定します。

理由: `maxSurge`と`maxUnavailable`のバランスは、更新中の容量とリソース使用量を管理するための鍵です。ゼロダウンタイムを実現するには、`maxUnavailable`が`replicas`よりも小さくなければなりません。

新しいPodを作成する前に古いPodをすべて終了させることで、アプリケーションの2つのバージョンが同時に実行されないようにする。

→Deploymentで`spec.strategy.type: Recreate`を設定します。

理由: 旧バージョンと新バージョンが共存しないことを保証します。これは、同じデータにアクセスする2つの異なるバージョンを処理できないアプリケーションに必要です。この戦略ではダウンタイムが発生します。

個々の変更が中間的なロールアウトをトリガーすることなく、ライブのDeploymentに複数の変更を加える。

→`kubectl rollout pause deployment/<name>`を使用し、変更を適用してから`kubectl rollout resume deployment/<name>`を使用します。

理由: 複数の更新を単一のロールアウトイベントに統合し、チャーンと競合状態を防ぎます。

etcdストレージを節約するために、Deploymentで保持される古いReplicaSetの数を制限する。

→`spec.revisionHistoryLimit`を保持したいリビジョン数（例: 3）に設定します。デフォルトは10です。

理由: より低い制限を設定することでetcdの乱雑さを減らします。`0`に設定すると、ロールバック機能が完全に無効になります。

Deploymentの更新理由を文書化し、リビジョン履歴に表示されるようにする。

→Deploymentマニフェストに`kubernetes.io/change-cause`アノテーションを追加します。例: `kubectl annotate deployment/nginx kubernetes.io/change-cause="update to 1.20"`。

理由: ロールアウト履歴（`kubectl rollout history`）を表示する際に貴重なコンテキストを提供し、どのリビジョンにロールバックすべきかを特定しやすくします。

新しいアプリケーションバージョンを古いものと並行してデプロイし、トラフィックをゼロダウンタイムで即座に切り替える。

→異なるバージョンラベルを持つ2つのDeployment（例: `app-blue`, `app-green`）を使用します。単一のServiceが、`selector`を介してアクティブなバージョンを選択します。切り替えるには、`kubectl patch service`を使用してセレクターを新しいバージョンラベルに更新します。

理由: Serviceセレクターを元に戻すだけで、即座に低リスクのリリースとロールバック機能を提供します。

本番環境でのテストのために、新しいアプリケーションバージョンに少量のトラフィックをルーティングする。

→同じセレクターラベルを共有する2つのDeployment（stable、canary）を使用します。Serviceは両方をターゲットにします。レプリカの比率（例: stableレプリカ9、canaryレプリカ1でトラフィック10%）でトラフィックの割合を制御します。

理由: Service Meshなしでカナリアリリースを実行する簡単な方法で、新機能の制御された低リスクなテストを可能にします。トラフィックの分散は近似的です。

クラスター内からの通信のみのためにPodのセットを公開する。

→`type: ClusterIP`を持つServiceを使用します。これはデフォルトのタイプです。

理由: `ClusterIP`は、Serviceに安定した内部IPアドレスとDNS名を提供し、個々のPod IPを抽象化します。

各ノードのIPアドレス上の静的ポートでサービスを公開する。

→`type: NodePort`を持つServiceを使用します。K8sは範囲（デフォルト: 30000-32767）からポートを割り当てます。

理由: 開発用や外部ロードバランサーが利用できない場合に役立ちます。`<NodeIP>:<NodePort>`へのトラフィックはServiceに転送されます。

ホスト名またはURLパスに基づいて、外部のHTTP/Sトラフィックを内部サービスにルーティングする。

→`Ingress`リソースを作成します。ホストの`rules`と、バックエンドサービスにマッピングするための`http.paths`を定義します。TLS Secretを指す`spec.tls`でTLSを設定します。

理由: IngressはL7ルーティングを提供し、複数のサービスを1つの外部IPの下に統合し、TLS終端をオフロードします。

ラベル、Namespace、またはIPブロックに基づいてPodとの間のネットワークトラフィックを制限する。

→`podSelector`でPodをターゲットとする`NetworkPolicy`を作成します。特定のトラフィックを許可するように`ingress`および/または`egress`ルールを定義します。デフォルトでは、Podにポリシーを適用すると、明示的に許可されていないすべてのトラフィックが拒否されます。

理由: NetworkPolicyは、ネットワークセグメンテーションとKubernetesにおけるゼロトラストセキュリティモデルの実装にとって基本的です。

リファレンス↗

デフォルトで、Namespace内のすべてのPodに対するすべてのイングレスおよびエグレストラフィックをブロックする。

→空の`podSelector: {}`と空のイングレス/エグレスルールを持つNetworkPolicyを作成します。例: `podSelector: {}, policyTypes: [Ingress, Egress]`。

理由: 他のより具体的なNetworkPolicyによって明示的に許可されない限り、すべてのトラフィックが拒否される安全なベースラインを確立します。

ロードバランシングのための仮想IPなしで、すべてのPod IPに直接解決される安定したDNSエントリを提供する。

→`spec.clusterIP: None`を持つServiceを作成します。

理由: StatefulSetsのようなステートフルなアプリケーションや、特定のPodと直接通信する必要があるピアツーピアシステムにとって不可欠です。

NodePortまたはLoadBalancer Serviceからのトラフィックに対して、バックエンドのPodが元のクライアントIPを認識するようにする。

→Serviceで`spec.externalTrafficPolicy: Local`を設定します。

理由: デフォルトの（`Cluster`）ポリシーは、ネットワークアドレス変換によりソースIPを隠蔽します。`Local`はそれを保持しますが、Podがすべてのノードに存在しない場合、トラフィックの分布が不均一になる可能性があります。

特定のクライアントからのすべてのリクエストが同じPodに送信されるようにする。

→Serviceで`spec.sessionAffinity: ClientIP`を設定します。

理由: 特定のPodのメモリにセッション状態を保存するレガシーアプリケーションに必要とされる「スティッキーセッション」を提供します。

あるNamespace内のPodが別のNamespace内のServiceと通信する必要がある。

→拡張されたDNS名: `<service-name>.<namespace-name>.svc.cluster.local`、または短縮形`<service-name>.<namespace-name>`を使用します。

理由: 単純なサービス名は同じNamespace内でしか解決されません。Namespaceをまたぐ通信には、DNSクエリでターゲットNamespaceを指定する必要があります。

Podのライフサイクルを管理するためにヘルスチェックを定義する: 失敗時に再起動するか、サービスから削除するか。

→`livenessProbe`: プローブが失敗した場合にコンテナを再起動します。`readinessProbe`: プローブが失敗した場合にPodをServiceのエンドポイントから削除します。`startupProbe`: コンテナが起動を完了するまで他のプローブを無効にします。

理由: 適切に設定されたプローブは、アプリケーションの自己修復とゼロダウンタイムデプロイメントの実現に不可欠です。

リファレンス↗

Podが非実行状態（例: Pending, ContainerCreating, CrashLoopBackOff）でスタックしている理由を診断する。

→`kubectl describe pod <pod-name>`を使用します。`Events`セクションは、スケジューラー（リソース問題）、kubelet（イメージプルエラー）、またはコンテナランタイムからの重要な手がかりを提供します。

理由: `describe`は、アプリケーションが起動したりログを出力したりする前に発生するPodのライフサイクル問題を理解するための最も重要なコマンドです。

クラッシュして現在再起動ループ（CrashLoopBackOff）にあるコンテナのログを検査する。

→`kubectl logs <pod-name> --previous`を使用します。

理由: `--previous`フラグは、コンテナの最後の終了インスタンスからのログを表示します。これには、クラッシュの原因となったエラーが含まれています。

ラベルセレクターに一致するすべてのPodからのログをリアルタイムで表示し、追跡する。

→`kubectl logs -l <label-selector> -f`を使用します。各行がどのPodからのものかを確認するには`--prefix`を追加します。

理由: 分散アプリケーションからのログを集約し、その動作を統一的に視覚化できます。

デバッグのために、実行中のコンテナ内でコマンドを実行したり、対話型シェルを取得したりする。

→`kubectl exec -it <pod-name> -- /bin/sh`（または`/bin/bash`）を使用します。`--`はkubectlフラグとコマンドを区切ります。

理由: ライブデバッグ、ファイルの検査、ネットワーク接続の確認のために、コンテナの環境に直接アクセスできます。

実行中のPodの現在のCPUおよびメモリ消費量を表示する。

→`kubectl top pod <pod-name>`を使用します。Pod内の各コンテナの使用状況を確認するには`--containers`を使用します。

理由: Metrics Serverがインストールされている必要があります。これは、リソースを大量に消費するアプリケーション、メモリリーク、またはCPUボトルネックを特定するために不可欠です。

シェルやデバッグツールがない実行中のコンテナをトラブルシューティングする。

→`kubectl debug <pod-name> -it --image=busybox --share-processes --copy-to=debug-pod`を使用します。これにより、同じプロセス名前空間を共有するデバッグコンテナを持つ新しいPodが作成されます。

理由: `kubectl debug`は、元のPodのspecを変更することなく、デバッグツールを備えた一時的な「エフェメラルコンテナ」を実行中のPodにアタッチする現代的な方法です。