AWS Fargate を使用してコンピューティング管理を簡素化する

Fargate で実行される各 Pod には、独自の分離境界があります。基本となるカーネル、CPU リソース、メモリリソース、または Elastic Network Interface を別の Pod と共有しません。

Network Load Balancer と Application Load Balancer (ALBs) は、IPターゲットでのみ Fargate で使用できます。詳細については、ネットワークロードバランサーを作成するおよびApplication Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングするを参照してください。

Fargate 公開サービスは、ターゲットタイプの IP モードでのみ実行され、ノード IP モードでは実行されません。マネージド型ノードで実行されているサービスと Fargate で実行されているサービスからの接続を確認するためのおすすめの方法は、サービス名を使用して接続することです。

Fargate で実行するには、ポッドがスケジューリングされた時点で Fargate プロファイルと一致する必要があります。Fargate プロファイルに一致しない Pod は Pending としてスタックする可能性があります。一致する Fargate プロファイルが存在する場合、Fargate に再スケジューリングするために作成した保留中の Pods を削除できます。

デーモンセットは Fargate ではサポートされていません。アプリケーションでデーモンが必要な場合は、Pods でサイドカーコンテナとして実行するようにデーモンを再設定します。

特権を持つコンテナは Fargate ではサポートされていません。

Fargate で実行されているポッドは、HostPort または HostNetwork を Pod マニフェストに指定できません。

Fargate Pods の場合、デフォルトの nofile および nproc のソフトリミットは 1024 で、ハードリミットは 65535 です。

GPU は現在、Fargate では使用できません。

Fargate で実行されているポッドは、プライベートサブネットでのみサポートされています (AWS のサービスへの NAT ゲートウェイアクセスができますが、インターネットゲートウェイへの直接ルーティングはできません)。そのため、クラスターの VPC ではプライベートサブネットを使用できるようにする必要があります。アウトバウンドインターネットアクセスのないクラスターについては、「」を参照してくださいインターネットアクセスが制限されたプライベートクラスターをデプロイする

「Vertical Pod Autoscaler でポッドリソースを調整する」を使用して Fargate Pods の CPU とメモリの適切な初期サイズを設定し、「Horizontal Pod Autoscaler を使用してポッドデプロイをスケールする」を使用してそれらの Pods をスケールできます。Vertical Pod Autoscaler で、より大きい CPU とメモリの組み合わせを持つ Fargate に Pods を自動的に再デプロイする場合は、正しい機能を確保するため、Vertical Pod Autoscaler のモードを Auto または Recreate に設定します。詳細については、「GitHub」で「Vertical Pod Autoscaler のドキュメント」を参照してください。

VPC で DNS 解決と DNS ホスト名を有効にする必要があります。詳細については、「VPC の DNS サポートを更新する」を参照してください。

Amazon EKS Fargate は、仮想マシン (VM) 内の各ポッドを分離することで、Kubernetes アプリケーションの多層防御を追加します。この VM 境界は、コンテナエスケープが発生した場合に他のポッドが使用するホストベースのリソースへのアクセスを防ぎます。これは、コンテナ化されたアプリケーションを攻撃し、コンテナ外のリソースにアクセスする一般的な方法です。

Amazon EKS を使用しても、責任共有モデルに基づくお客様の責任は変わりません。クラスターのセキュリティとガバナンスのコントロールの設定について、慎重に検討する必要があります。アプリケーションを分離する最も安全な方法は、常に別のクラスターで実行することです。

Fargate プロファイルでは、VPC セカンダリ CIDR ブロックからのサブネットの指定がサポートされています。セカンダリ CIDR ブロックを指定することもできます。サブネットの使用できる IP アドレスの数は限られています。その結果、クラスター内に作成できる Pods の数が制限されます。Pods に別のサブネットを使用することで、使用可能な IP アドレスの数を増やすことができます。詳細については、「IPv4 CIDR ブロックの VPC への追加」を参照してください。

Amazon EC2 インスタンスメタデータサービス (IMDS) は、Fargate ノードにデプロイされた Pods では使用できません。IAM 認証情報を必要とする Fargate にデプロイされた Pods がある場合は、サービスアカウントの IAM ロール を使用して Pods に割り当てます。Pods が IMDS を通じて利用可能な他の情報にアクセスする必要がある場合は、この情報を Pod 仕様にハードコーディングする必要があります。これには、Pod がデプロイされる AWS リージョンまたはアベイラビリティーゾーンが含まれます。

AWS Outposts、AWS Wavelength、または AWS Local Zones に Fargate Pods をデプロイすることはできません。

Amazon EKS は定期的に Fargate Pods にパッチを適用して安全に保つ必要があります。影響を軽減する方法で更新を試みますが、ポッドのエビクションが正常に行われなかった場合、Pods を削除しなければならない場合があります。中断を最小限に抑えるために行えるアクションがいくつかあります。詳細については、「AWS Fargate OS パッチ適用イベントのアクションを設定する」を参照してください。

Amazon VPC CNI plugin for Amazon EKS は、Fargate ノードにインストールされています。Fargate ノードでは Amazon EKS クラスターの代替 CNI プラグインを使用することはできません。

Fargate 上で実行される Pod は、ドライバーの手動インストールステップなしで、Amazon EFS ファイルシステムを自動的にマウントします。Fargate ノードでは動的永続ボリュームプロビジョニングを使用できませんが、静的プロビジョニングを使用することはできます。

Amazon EKS は Fargate Spot をサポートしていません。

Amazon EBS ボリュームを Fargate Pods にマウントすることはできません。

Amazon EBS CSI コントローラーは Fargate ノードで実行できますが、Amazon EBS CSI ノード DaemonSet は Amazon EC2 インスタンスでのみ実行できます。

Kubernetes ジョブが Completed または Failed とマークされた後も、Job が作成した Pods は通常存在し続けます。この動作によりログと結果を表示できますが、Fargate を使用する場合、その後 Job をクリーンアップしないとコストが発生します。

Job が完了または失敗した後に、関連する Pods を自動的に削除するには、有効期限 (TTL) コントローラを使用して期間を指定できます。次の例では、Job マニフェストで .spec.ttlSecondsAfterFinished を指定する方法を示しています。

apiVersion: batch/v1
kind: Job
metadata:
  name: busybox
spec:
  template:
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["/bin/sh", "-c", "sleep 10"]
      restartPolicy: Never
  ttlSecondsAfterFinished: 60 # <-- TTL controller