Kubernetesでは、Podを直接作成するのではなく、Deployment、StatefulSet、DaemonSetなどのワークロードリソースを使用することが推奨されます。これらのリソースは高可用性とスケーラビリティを提供し、Podの自動回復とローリングアップデートを実現します。
- Deployment: ステートレスなアプリケーションに最適。レプリカ数の管理とローリングアップデートを提供
- StatefulSet: データベースなどのステートフルなアプリケーション用。順序付きデプロイと永続的な識別子を提供
- DaemonSet: 各ノードで1つのPodを実行する必要がある場合（ログ収集、モニタリングエージェントなど）
これらのワークロードリソースにより、Podの障害時の自動回復やローリング更新による無停止デプロイが可能になります。
EKSでは、Application Load Balancer (ALB) とKubernetesのServiceリソースを組み合わせることで、高可用性なトラフィック分散を実現できます。AWS Load Balancer Controllerを使用することで、ALBを自動的にプロビジョニングし、複数のPodにトラフィックを分散できます。
- Service（ClusterIP）: クラスタ内でのPod間通信とロードバランシング
- Ingress + ALB: 外部からのHTTP/HTTPSトラフィックの負荷分散
ALBによるヘルスチェック機能により、異常なPodへのトラフィック送信を自動的に停止し、可用性を向上させます。
PodのヘルスチェックにはLiveness ProbeとReadiness Probeを設定することで、アプリケーションの健全性を監視し、自動回復を実現できます。
- Liveness Probe: Podが正常に動作しているかを確認。失敗した場合はPodを再起動
- Readiness Probe: Podがトラフィックを受け取る準備ができているかを確認。失敗した場合はServiceのエンドポイントから除外
これらのProbeにより、障害の早期検出と自動回復、トラフィックの適切な分散が可能になります。
Podの停止時にはpreStopフックとterminationGracePeriodSecundsを適切に設定することで、データの整合性を保ちながら安全に停止できます。
- preStopフック: Pod停止前に実行される処理（データベース接続のクローズ、進行中のリクエストの完了待ちなど）
- terminationGracePeriodSeconds: SIGTERMシグナル送信からSIGKILLまでの猶予時間
- ローリングアップデート設定: maxUnavailableとmaxSurgeの調整による段階的な更新
これにより、サービスの中断を最小限に抑えながらPodの更新や停止が可能になります。
Pod affinityとanti-affinityを使用することで、Podの配置を制御し、可用性とパフォーマンスを向上させることができます。
- Node Affinity: 特定のノードタイプやAZにPodを配置
- Pod Anti-Affinity: 同一アプリケーションの複数レプリカを異なるノードやAZに分散
- Pod Affinity: 関連するアプリケーション（例：WebサーバーとCache）を同一ノードに配置
これらの設定により、単一障害点を回避し、ネットワークレイテンシを最適化できます。
Pod Disruption Budget (PDB) を設定することで、ノードのメンテナンスやクラスタのスケーリング時にも最小限のサービス影響で運用を継続できます。
- minAvailable: 常に利用可能であるべき最小Pod数
- maxUnavailable: 同時に停止可能な最大Pod数
PDBにより、ローリングアップデートやノードメンテナンス時のサービス継続性が保証されます。
DeploymentやStatefulSetのUpdateStrategyを適切に設定することで、アプリケーションの更新時の可用性を制御できます。
- RollingUpdate: 段階的な更新でサービス継続性を維持
- Recreate: 全Podを一度に停止してから新しいバージョンを起動
- maxUnavailable/maxSurge: ローリングアップデート時の同時更新Pod数制御
適切なUpdateStrategyにより、アプリケーションの特性に応じた最適な更新方法を選択できます。