0Pricing
AWS Solutions Architect · レッスン

サーバーレスポッド向けFargateプロファイル

EC2ノードを管理せずにFargate上でKubernetesポッドを実行し、Fargateプロファイルを設定して、名前空間による制限を理解します。

「サーバーレスポッド向けFargateプロファイル」はCoddyKit上の無料AWS Solutions Architectレッスンです。 これはレッスン2/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。

Fargate プロファイルとは

AWS Fargate for EKSを使用すると、EC2 ノードをプロビジョニングまたは管理することなく Kubernetes Pod を実行できます。インスタンスタイプやノードグループを考える代わりに、Fargate プロファイルを定義します。このプロファイルによって、namespace とオプションのラベルセレクターに基づき、どの Pod を Fargate で実行するかを EKS に指定します。AWS は各 Pod に必要な量のコンピューティングリソースを自動的にプロビジョニングし、Pod が停止すると解放します。

Fargate プロファイルの設定

Fargate プロファイルは EKS クラスターに関連付けられ、1 つ以上のセレクターを含みます。各セレクターでは、namespace とオプションの Kubernetes ラベルのキーと値のペアを指定します。Pod が Fargate でスケジュールされるには、少なくとも 1 つのセレクターに一致する必要があります。また、プロファイルではPod 実行ロール（IAM ロール）と、Fargate が Pod の起動に使用するプライベートサブネットも指定します。

# Create a Fargate profile for the 'production' namespace
aws eks create-fargate-profile \
  --cluster-name my-cluster \
  --fargate-profile-name production-profile \
  --pod-execution-role-arn arn:aws:iam::111122223333:role/EKSFargatePodExecutionRole \
  --subnets subnet-aaa subnet-bbb \
  --selectors '[{"namespace":"production"},{"namespace":"staging","labels":{"fargate":"true"}}]'

Pod 実行ロール

Pod 実行ロールは、Fargate がコンテナイメージを取得し、Pod のログを CloudWatch に送信するときに EKS が引き受ける IAM ロールです。このロールには、AmazonEKSFargatePodExecutionRolePolicy AWS 管理ポリシーを含める必要があります。このロールがない場合、Fargate は ECR に対する認証や CloudWatch Logs への書き込みを行えないため、Fargate でスケジュールされた Pod は起動に失敗します。

# Create the pod execution role trust policy
cat fargate-trust-policy.json
# {
#   "Version": "2012-10-17",
#   "Statement": [{
#     "Effect": "Allow",
#     "Principal": {"Service": "eks-fargate-pods.amazonaws.com"},
#     "Action": "sts:AssumeRole"
#   }]
# }

aws iam attach-role-policy \
  --role-name EKSFargatePodExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy

Fargate の namespace 制限

Fargate には重要なnamespace の制限があります。kube-system namespace では kube-proxy などのシステム Pod が実行されるため、ほとんどの Fargate プロファイルで使用できません。ただし CoreDNS は例外です。AWS が提供する手順に従って CoreDNS の Deployment を修正し、eks.amazonaws.com/compute-type: ec2 アノテーションを削除すると、Fargate で実行できるようになります。除外された namespace の Pod は、使用可能な EC2 ノードがない場合、スケジュールされないままになります。

# Patch CoreDNS to allow Fargate scheduling
kubectl patch deployment coredns \
  -n kube-system \
  --type json \
  -p '[{"op":"remove","path":"/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'

# Restart CoreDNS to apply the patch
kubectl rollout restart deployment coredns -n kube-system

Fargate Pod のリソースサイジング

Fargate は、Pod 仕様で定義されたCPU とメモリの requestsに基づいてコンピューティングリソースを割り当てます。Fargate がサポートする vCPU とメモリの組み合わせのうち、最も近い上位の値に切り上げられます（例: 0.25 vCPU / 0.5 GB から 16 vCPU / 120 GB まで）。料金は、Pod の実行中に割り当てられたリソースに対して、1 秒単位でのみ発生します。リソース requests は必ず正確に設定してください。少なすぎるとメモリ不足による強制終了が発生し、多すぎるとコストが増加します。

# Pod spec with explicit resource requests and limits
apiVersion: v1
kind: Pod
metadata:
  name: api-pod
  namespace: production
spec:
  containers:
  - name: api
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/my-api:latest
    resources:
      requests:
        cpu: '500m'
        memory: '1Gi'
      limits:
        cpu: '1'
        memory: '2Gi'

Fargate と EC2 ノードグループの比較: トレードオフ

Fargate ではノード管理が不要になりますが、いくつかの制約があります。DaemonSet は使用できず（スケジュール先となる永続的なノードがないため）、特権コンテナも使用できず、一部のストレージタイプのサポートも限定的です。EC2 ノードグループでは、GPU、カスタムカーネル、ローカル NVMe ドライブを使用するステートフルワークロードをサポートできます。一般的な構成では、同じ EKS クラスター内で、ステートレスサービスを Fargate 上で実行し、ステートフルワークロードや GPU ワークロードを専用の EC2 ノードグループで実行します。

Fargate のネットワークとセキュリティグループ

各 Fargate Pod には独自のElastic Network Interface（ENI）が割り当てられ、プロファイルで指定したサブネットからプライベート IP が付与されます。これにより、Security Groups for Pods 機能を使用して、各 Pod に固有のセキュリティグループを適用できます。Fargate Pod は標準的な VPC セキュリティグループのルールをすべてサポートするため、個々の Pod レベルでインバウンドおよびアウトバウンドトラフィックをきめ細かく制御できます。これは、ノード間で共有するノードレベルのセキュリティグループと比べて、大きなセキュリティ上の利点です。

# Assign a security group to a pod via annotation
apiVersion: v1
kind: Pod
metadata:
  name: secure-api
  namespace: production
  annotations:
    vpc.amazonaws.com/pod-eni: 'true'
spec:
  securityGroups:
    groupIds:
    - sg-0abc1234def56789a
  containers:
  - name: api
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/secure-api:v2

Fargate から CloudWatch へのログ送信

Fargate Pod は、組み込みの Fluent Bit ログルーターを使用してログをAmazon CloudWatch Logsに送信します。ログを設定するには、aws-observability namespace に aws-logging という名前の ConfigMap を作成します。Pod 実行ロールには、ロググループの作成とログイベントの書き込みを行う権限が必要です。ログはクラスターと namespace ごとに CloudWatch ロググループに整理されるため、個別のログエージェントを実行しなくてもログを簡単に一元集約できます。

# ConfigMap to enable Fargate logging
apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-logging
  namespace: aws-observability
data:
  flb_log_cw: 'true'
  output.conf: |
    [OUTPUT]
        Name cloudwatch_logs
        Match *
        region us-east-1
        log_group_name /aws/eks/my-cluster/fargate
        log_stream_prefix fargate-
        auto_create_group true

Fargate での Horizontal Pod Autoscaler

Fargate は Kubernetes のHorizontal Pod Autoscaler（HPA）をサポートしています。HPA がレプリカをスケールアウトすると、ノードグループのサイズを調整しなくても、Fargate が新しいマイクロ VM を自動的にプロビジョニングします。これにより、真のサーバーレスオートスケーリングを実現できます。HPA が Pod 数を制御し、Fargate がコンピューティングリソースを柔軟に処理します。ただし、HPA が CPU とメモリの使用量を読み取るには、クラスターにMetrics Serverをデプロイする必要があります。

# Deploy Metrics Server (required for HPA)
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Create an HPA for a Fargate-scheduled deployment
kubectl autoscale deployment my-api \
  --namespace production \
  --cpu-percent=60 \
  --min=2 \
  --max=20

Fargate の料金モデル

Fargate では、消費したvCPU 秒および GB 秒に対して、Pod ごとに最低 1 分の料金が発生します。ノードレベルの料金、リザーブドキャパシティ料金、AMI や OS のパッチ適用コストはありません。コンピューティング単位あたりの料金は、適切なサイズの EC2 オンデマンドインスタンスより通常高くなりますが、ノード管理、パッチ適用、スケーリングの判断にかかるエンジニアリング作業を削減できるため、総保有コストは低くなることがよくあります。

Fargate の主な制限事項

SAA-C03 試験で重要な Fargate の制限事項は、DaemonSet をサポートしないこと（永続的なノードがないため、各ノードに Pod を配置できません）、特権コンテナを使用できないこと、hostNetwork モードを使用できないこと、そしてエフェメラルストレージが Pod あたり 20 GB に制限されることです（設定により 200 GB まで拡張可能です）。EBS による永続ブロックストレージはサポートされていないため、Fargate Pod で共有する永続ファイルストレージには EFS を使用します。

# Mount EFS in a Fargate pod (EBS is NOT supported on Fargate)
apiVersion: v1
kind: Pod
metadata:
  name: efs-pod
  namespace: production
spec:
  volumes:
  - name: efs-storage
    persistentVolumeClaim:
      claimName: efs-pvc
  containers:
  - name: app
    image: my-image:latest
    volumeMounts:
    - name: efs-storage
      mountPath: /data

クイックチェック

このレッスンで学んだ AWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、Fargate プロファイルが namespace とラベルセレクターを使用して Pod をサーバーレスでスケジュールすること、Pod 実行ロールによって Fargate にイメージの取得とログの書き込みを行う権限を付与すること、そしてFargate は DaemonSet と EBS をサポートしないため、永続ストレージには EFS を使用することを学びました。次は、VPC CNI プラグインと AWS Load Balancer Controller を使用した EKS のネットワークについて学びます。

よくある質問

「サーバーレスポッド向けFargateプロファイル」レッスンは無料ですか？

はい。「サーバーレスポッド向けFargateプロファイル」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。

「サーバーレスポッド向けFargateプロファイル」で何を学びますか？

EC2ノードを管理せずにFargate上でKubernetesポッドを実行し、Fargateプロファイルを設定して、名前空間による制限を理解します。 ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

AWS Solutions Architectを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン2/4です。

「サーバーレスポッド向けFargateプロファイル」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAWS Solutions Architectレッスンでコードを書いて実行できますか？

はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. EKSコントロールプレーンとワーカーノード
  2. サーバーレスポッド向けFargateプロファイル
  3. EKSネットワーキング：VPC CNIとロードバランシング
  4. サービスアカウントのIAMロール（IRSA）
← AWS Solutions Architectに戻る