Google Cloud Platformに戻る | GKE (Google Kubernetes Engine)に戻る

GKEのPod（ポッド）

Podとは

Pod（ポッド）は、Kubernetesにおける最小のデプロイ単位であり、Google Kubernetes Engine (GKE)でアプリケーションを実行する基本的な構成要素です。Podは1つ以上のコンテナをグループ化し、それらが同じ実行環境を共有できるようにします。これらのコンテナは同じノード上で実行され、同じネットワーク名前空間、IPアドレス、ポート空間を共有します。

重要なポイント

Podは一時的（エフェメラル）なリソースとして設計されています。ノードの障害、リソース不足、または他の理由でPodが終了した場合、Kubernetesは自動的に新しいPodを作成して置き換えることができます。このため、永続的なデータはPodの外部（例：永続ボリューム）に保存する必要があります。

Podの構造と構成要素

Podは以下の主要な構成要素で構成されています：

構成要素	説明
コンテナ	Pod内で実行されるDockerなどのコンテナ。メインアプリケーションコンテナとサイドカーコンテナ（補助的な機能を提供）が含まれることがある
ボリューム	Pod内のコンテナ間でデータを共有するためのストレージ。Pod内のすべてのコンテナからアクセス可能
ネットワーク名前空間	Pod内のすべてのコンテナが共有するネットワーク設定。各Podには固有のIPアドレスが割り当てられる
リソース仕様	CPUやメモリなど、Podが要求または制限するリソースの量
ラベルとアノテーション	Podを識別・分類するためのメタデータ
セキュリティコンテキスト	Pod内のコンテナの実行権限や分離レベルを定義

Podのライフサイクル

Podは以下のライフサイクルフェーズを経ます：

Pending（保留中）： Podが作成されたが、すべてのコンテナがまだ実行状態になっていない状態
Running（実行中）： Podがノードにスケジュールされ、すべてのコンテナが作成され、少なくとも1つのコンテナが実行中または起動/再起動中
Succeeded（成功）： Pod内のすべてのコンテナが正常に終了し、再起動されない状態
Failed（失敗）： Pod内の少なくとも1つのコンテナが失敗して終了
Unknown（不明）： 何らかの理由でPodの状態を取得できない状態

Podのライフサイクルを確認するコマンド

kubectl get pod my-pod -o wide
kubectl describe pod my-pod

Pod条件（Conditions）

Podの状態をより詳細に表す条件フラグ：

PodScheduled： Podがノードにスケジュールされたかどうか
ContainersReady： Pod内のすべてのコンテナが準備完了状態かどうか
Initialized： すべての初期化コンテナが正常に完了したかどうか
Ready： Podがリクエストを処理する準備ができているかどうか

Podの作成と管理

GKEでPodを作成・管理するには、通常以下の方法を使用します：

YAMLマニフェストを使用したPodの作成

基本的なPodマニフェストの例

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.21
    ports:
    - containerPort: 80
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

このマニフェストをapplyコマンドで適用します：

kubectl apply -f nginx-pod.yaml

直接Podを作成する代わりに上位レベルのリソースを使用する

実際の運用環境では、単独のPodを直接作成するよりも、Deployment、StatefulSet、DaemonSetなどの上位レベルのコントローラーを使用することが推奨されます。これらのコントローラーはPodの自動再起動、スケーリング、ローリングアップデートなどの機能を提供します。

マルチコンテナPod

1つのPodに複数のコンテナを配置することで、密接に関連するプロセスを一緒に実行できます：

マルチコンテナPodの例

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
  - name: web
    image: nginx:1.21
    ports:
    - containerPort: 80
  - name: log-collector
    image: fluentd:v1.14
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/nginx
  volumes:
  - name: log-volume
    emptyDir: {}

一般的なPodパターン

サイドカー： メインコンテナを拡張または強化する追加コンテナ（例：ログ収集、監視エージェント）
アンバサダー： メインコンテナの代わりにネットワーク接続を処理するプロキシコンテナ
アダプター： メインコンテナの出力を標準化または変換するコンテナ

Podのリソース管理

GKEでPodのリソースを効率的に管理するには、リソース要求（requests）と制限（limits）を適切に設定することが重要です：

リソース要求と制限

リソース要求（requests）： Podが必要とする最小限のリソース量。スケジューリングの決定に使用される
リソース制限（limits）： Podが使用できる最大リソース量。この値を超えるとコンテナが再起動される可能性がある

リソース要求と制限の設定例

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: app
    image: nginx
    resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: "1000m"

リソース単位

CPUリソースは「m」（ミリCPU）で指定され、1000mが1コアに相当します。メモリリソースはMi（メビバイト）やGi（ギビバイト）などの単位で指定されます。

QoS（Quality of Service）クラス

Kubernetesは、リソース要求と制限の設定に基づいて、各Podに以下のQoSクラスを自動的に割り当てます：

Guaranteed： すべてのコンテナにリソース要求と制限が設定され、それらが等しい場合
Burstable： 少なくとも1つのコンテナにリソース要求が設定されているが、Guaranteedの条件を満たさない場合
BestEffort： どのコンテナにもリソース要求と制限が設定されていない場合

リソース不足が発生した場合、Kubernetesは優先度の低いQoSクラス（BestEffort、次にBurstable）のPodから終了させます。

Podのネットワーキング

GKEにおけるPodのネットワーキングの主な特徴：

Pod IP： 各Podには、クラスタ内で一意のIPアドレスが割り当てられる
コンテナ間通信： 同じPod内のコンテナは、localhostを介して相互に通信可能
Pod間通信： 異なるPod間の通信は、Pod IPを使用して直接行われる
サービスディスカバリ： Serviceリソースを使用して、動的に変化するPodの集合に安定したエンドポイントを提供

Pod IPの確認方法

kubectl get pod nginx-pod -o wide

ネットワークポリシー

GKEでは、NetworkPolicyリソースを使用してPod間の通信を制限できます：

基本的なネットワークポリシーの例

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Podのストレージ

GKEのPodでデータを永続化するためのオプション：

ボリュームタイプ

emptyDir： Pod内のコンテナ間でデータを共有するための一時的なストレージ。Podが削除されると内容も失われる
hostPath： ノードのファイルシステムからのパスをマウント。ノードレベルのデータにアクセスするために使用
PersistentVolume (PV) と PersistentVolumeClaim (PVC)： Podのライフサイクルとは独立した永続的なストレージ
ConfigMap と Secret： 設定データと機密情報をPodにマウントするための特殊なボリューム
CSI (Container Storage Interface)： サードパーティのストレージプロバイダを統合するためのインターフェース

PersistentVolumeClaimを使用したPodの例

apiVersion: v1
kind: Pod
metadata:
  name: database-pod
spec:
  containers:
  - name: db
    image: mysql:8.0
    volumeMounts:
    - name: data-volume
      mountPath: /var/lib/mysql
  volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: mysql-pvc

Podのセキュリティ

GKEでPodのセキュリティを確保するためのベストプラクティス：

セキュリティコンテキスト

securityContextを使用して、Podまたはコンテナレベルでセキュリティ設定を構成できます：

セキュリティコンテキストの例

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsNonRoot: true
    fsGroup: 1000
  containers:
  - name: app
    image: nginx
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true

その他のセキュリティベストプラクティス

最小権限の原則： Podに必要最小限の権限のみを付与
イメージの脆弱性スキャン： Artifact Registryの脆弱性スキャンを使用して、コンテナイメージの脆弱性を検出
Binary Authorization： 承認されたイメージのみがデプロイされるようにポリシーを設定
Workload Identity： GCPサービスアカウントとKubernetesサービスアカウントを安全に連携
Pod Security Standards： Kubernetesの定義するセキュリティ標準に従ってPodを構成

Podのヘルスチェックとプローブ

GKEでは、以下の3種類のプローブを使用してPodの健全性を監視できます：

Livenessプローブ： コンテナが動作しているかどうかを確認。失敗した場合、コンテナは再起動される
Readinessプローブ： コンテナがリクエストを処理する準備ができているかどうかを確認。失敗した場合、Podはサービスのエンドポイントから削除される
Startupプローブ： コンテナのアプリケーションが起動したかどうかを確認。起動中は他のプローブは無効化される

プローブの設定例

apiVersion: v1
kind: Pod
metadata:
  name: probe-demo
spec:
  containers:
  - name: app
    image: nginx
    ports:
    - containerPort: 80
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 5

Podのデバッグとトラブルシューティング

GKEでPodの問題をトラブルシューティングするための一般的なコマンドとテクニック：

Podの状態確認

kubectl get pods
kubectl describe pod <pod-name>

ログの確認

kubectl logs <pod-name>
kubectl logs <pod-name> -c <container-name>  # マルチコンテナPodの場合

Podへの接続

kubectl exec -it <pod-name> -- /bin/bash
kubectl exec -it <pod-name> -c <container-name> -- /bin/bash  # マルチコンテナPodの場合

一般的な問題と解決策

問題	考えられる原因	解決策
Podが「Pending」状態	リソース不足、PVCのプロビジョニング待ち	`kubectl describe pod`でイベントを確認クラスタのリソース状況を確認
Podが「CrashLoopBackOff」状態	コンテナの起動失敗、アプリケーションのクラッシュ	`kubectl logs`でログを確認コンテナの設定とアプリケーションコードを確認
Podが「ImagePullBackOff」状態	イメージが見つからない、プライベートレジストリの認証失敗	イメージ名とタグを確認イメージプルシークレットを設定
Podが「Error」または「Completed」状態	ジョブまたはバッチ処理の完了または失敗	`kubectl logs`で実行結果を確認必要に応じてジョブ設定を調整

GKE Autopilotにおけるポッド

GKE Autopilotモードでは、Podの管理方法に以下の特徴があります：

リソース要求の必須化： Autopilotでは、すべてのコンテナにリソース要求を指定する必要がある
自動ノードプロビジョニング： Podのリソース要求に基づいて、適切なノードが自動的にプロビジョニングされる
Podの優先度： システムクリティカルなPodが優先的にスケジュールされる
リソース制限の自動設定： リソース要求に基づいて、適切なリソース制限が自動的に設定される

Autopilotでのベストプラクティス

Autopilotでは、アプリケーションの実際の要件に基づいて正確なリソース要求を設定することが特に重要です。過大な要求はコストの増加につながり、過小な要求はパフォーマンスの問題を引き起こす可能性があります。

まとめ

Podは、GKEおよびKubernetesにおけるアプリケーション実行の基本単位です。効果的なPod設計と管理は、GKEでのアプリケーションの信頼性、スケーラビリティ、セキュリティを確保するために不可欠です。

Podを効果的に活用するためのポイント：

適切なコントローラー（Deployment、StatefulSetなど）を使用してPodのライフサイクルを管理する
リソース要求と制限を適切に設定してリソース効率を最適化する
ヘルスチェックとプローブを設定して自動復旧を確保する
セキュリティベストプラクティスに従ってPodを保護する
永続データには適切なストレージソリューションを使用する
マルチコンテナPodパターンを理解し、適切に活用する

これらの原則に従うことで、GKEでのコンテナ化アプリケーションの運用を効率化し、安定したサービス提供を実現できます。