**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# AWS Fargate を使用してコンピューティング管理を簡素化する
このトピックでは、Amazon EKS を使用して AWS Fargate で Kubernetes Pod を実行する方法について説明します。Fargate は、[コンテナ](https://aws.amazon.com/what-are-containers)に適切なサイズのコンピューティング能力をオンデマンドで提供するテクノロジーです。Fargate を使用すると、コンテナを実行するために仮想マシンのグループをプロビジョニング、設定、スケールする必要がありません。これにより、サーバータイプの選択、ノードグループをスケールするタイミングの決定、クラスターのパッキングの最適化を行う必要がなくなります。
Fargate で起動する Pod と、[Fargate プロファイル](fargate-profile.md)での実行方法を制御できます。Fargate プロファイルは Amazon EKS クラスターの一部として定義されています。Amazon EKS は、Kubernetes が提供するアップストリームの拡張可能なモデルを使用して AWS により構築されたコントローラーを使用して、Kubernetes と Fargate を統合します。これらのコントローラーは、Amazon EKS マネージド Kubernetes コントロールプレーンの一部として実行され、ネイティブ Kubernetes Pod を Fargate にスケジューリングします。Fargate コントローラーには、いくつかの変更と検証アドミッションコントローラーに加えて、デフォルトの Kubernetes スケジューラーとともに実行される新しいスケジューラが含まれています。Fargate で実行する条件を満たす Pod を起動すると、クラスターで実行されている Fargate コントローラーは Pod を認識し、更新し、Fargate にスケジューリングします。
このトピックでは、Fargate で実行されている Pod のさまざまなコンポーネントについて説明し、Amazon EKS で Fargate を使用する際の特別な考慮事項を示します。
## AWS Fargate 考慮事項
Amazon EKS での Fargate の使用についての考慮事項を以下に示します。
+ Fargate で実行される各 Pod には、独自のコンピューティング境界があります。基本となるカーネル、CPU リソース、メモリリソース、または Elastic Network Interface を別のPod と共有しません。
+ Network Load Balancer と Application Load Balancer (ALBs) は、IPターゲットでのみ Fargate で使用できます。詳細については、「[ネットワークロードバランサーを作成する](network-load-balancing.md#network-load-balancer)」および「[Application Load Balancer を使用してアプリケーションと HTTP トラフィックをルーティングする](alb-ingress.md)」を参照してください。
+ Fargate 公開サービスは、ターゲットタイプの IP モードでのみ実行され、ノード IP モードでは実行されません。マネージド型ノードで実行されているサービスと Fargate で実行されているサービスからの接続を確認するためのおすすめの方法は、サービス名を使用して接続することです。
+ Fargate で実行するには、ポッドがスケジューリングされた時点で Fargate プロファイルと一致する必要があります。Fargate プロファイルに一致しない Pod は `Pending` としてスタックする可能性があります。一致する Fargate プロファイルが存在する場合、Fargate に再スケジューリングするために作成した保留中の Pod を削除できます。
+ デーモンセットは Fargate ではサポートされていません。アプリケーションにデーモンが必要な場合は、そのデーモンを Pod のサイドカーコンテナとして実行するように再設定します。
+ 特権を持つコンテナは Fargate ではサポートされていません。
+ Fargate で実行されている Pod は、`HostPort` または `HostNetwork` を Pod マニフェストに指定できません。
+ Fargate Pod の場合、デフォルトの `nofile` および `nproc` のソフトリミットは 1024、ハードリミットは 65535 です。
+ GPU は現在、Fargate では使用できません。
+ Fargate で実行されているポッドは、プライベートサブネットでのみサポートされています (AWS のサービスへの NAT ゲートウェイアクセスができますが、インターネットゲートウェイへの直接ルーティングはできません)。そのため、クラスターの VPC ではプライベートサブネットを使用できるようにする必要があります。アウトバウンドインターネットアクセスのないクラスターについては、「」を参照してください[インターネットアクセスが制限されたプライベートクラスターをデプロイする](private-clusters.md)
+ 「[Vertical Pod Autoscaler でポッドリソースを調整する](vertical-pod-autoscaler.md)」を使用して Fargate Pod の CPU とメモリの適切な初期サイズを設定し、「[Horizontal Pod Autoscaler を使用してポッドデプロイをスケールする](horizontal-pod-autoscaler.md)」を使用してそれらの Pod をスケールできます。Vertical Pod Autoscaler で、より大きい CPU とメモリの組み合わせを持つ Fargate に Pod を自動的に再デプロイする場合は、正しい機能を確保するため、Vertical Pod Autoscaler のモードを `Auto` または `Recreate` に設定します。詳細については、GitHub で [Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#quick-start) のドキュメントを参照してください。
+ VPC で DNS 解決と DNS ホスト名を有効にする必要があります。詳細については、「[VPC の DNS サポートを更新する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating)」を参照してください。
+ Amazon EKS Fargate は、仮想マシン (VM) 内の各ポッドを分離することで、Kubernetes アプリケーションの多重防御を追加します。この VM 境界は、コンテナエスケープが発生した場合に他のポッドが使用するホストベースのリソースへのアクセスを防ぎます。これは、コンテナ化されたアプリケーションを攻撃し、コンテナ外のリソースにアクセスする一般的な方法です。
Amazon EKS を使用しても、[責任共有モデル](security.md)に基づくお客様の責任は変わりません。クラスターのセキュリティとガバナンスのコントロールの設定について、慎重に検討する必要があります。アプリケーションを分離する最も安全な方法は、常に別のクラスターで実行することです。
+ Fargate プロファイルでは、VPC セカンダリ CIDR ブロックからのサブネットの指定がサポートされています。セカンダリ CIDR ブロックを指定することもできます。サブネットの使用できる IP アドレスの数は限られています。結果的に、クラスター内に作成できる Pod の数も制限されます。Pod に別のサブネットを使用することで、使用可能な IP アドレスの数を増やすことができます。詳細については、「[IPv4 CIDR ブロックの VPC への追加](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#vpc-resize)」を参照してください。
+ Amazon EC2 インスタンスメタデータサービス (IMDS) は、Fargate ノードにデプロイされた Pod では使用できません。IAM 認証情報を必要とする Fargate にデプロイされた Pod がある場合は、[サービスアカウントの IAM ロール](iam-roles-for-service-accounts.md)を使用して Pod に割り当てます。Pod が IMDS を通じて利用可能な他の情報にアクセスする必要がある場合は、この情報を Pod 仕様にハードコーディングする必要があります。これには、Pod がデプロイされる AWS リージョンまたはアベイラビリティーゾーンが含まれます。
+ AWS Outposts、AWS Wavelength、または AWS Local Zones に Fargate Pod をデプロイすることはできません。
+ Amazon EKS は定期的に Fargate Pod にパッチを適用して安全に保つ必要があります。影響を軽減する方法で更新を試みますが、Pod のエビクションが正常に行われなかった場合、Pod を削除しなければならない場合があります。中断を最小限に抑えるために行えるアクションがいくつかあります。詳細については、「[AWS Fargate OS パッチ適用イベントのアクションを設定する](fargate-pod-patching.md)」を参照してください。
+ [Amazon VPC CNI plugin for Amazon EKS](https://github.com/aws/amazon-vpc-cni-plugins) は、Fargate ノードにインストールされています。Fargate ノードでは [Amazon EKS クラスターの代替 CNI プラグイン](alternate-cni-plugins.md)を使用することはできません。
+ Fargate 上で実行される Pod は、ドライバーの手動インストールステップなしで、Amazon EFS ファイルシステムを自動的にマウントします。Fargate ノードでは動的永続ボリュームプロビジョニングを使用できませんが、静的プロビジョニングを使用することはできます。
+ Amazon EKS は Fargate Spot をサポートしていません。
+ Amazon EBS ボリュームを Fargate Pod にマウントすることはできません。
+ Amazon EBS CSI コントローラーは Fargate ノードで実行できますが、Amazon EBS CSI ノード DaemonSet は Amazon EC2 インスタンスでのみ実行できます。
+ [Kubernetes Job](https://kubernetes.io/docs/concepts/workloads/controllers/job/) が `Completed` または `Failed` とマークされた後も、Job が作成した Pod は通常存在し続けます。この動作によりログと結果を表示できますが、Fargate を使用する場合、その後 Job をクリーンアップしないとコストが発生します。
Job が完了または失敗した後に、関連する Pod を自動的に削除するには、有効期限 (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
```
## Fargate 比較テーブル
| 条件 | AWS Fargate |
| --- | --- |
| [AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html) にデプロイ可能 | いいえ |
| [AWS Local Zone](local-zones.md) にデプロイ可能 | いいえ |
| Windows を必要とするコンテナを実行できる | いいえ |
| Linux を必要とするコンテナを実行可能 | はい |
| インフェクエンティア チップを必要とするワークロードを実行可能 | いいえ |
| GPU を必要とするワークロードを実行可能 | いいえ |
| Arm プロセッサを必要とするワークロードを実行可能 | いいえ |
| AWS [Bottlerocket](https://aws.amazon.com/bottlerocket/) を実行可能 | いいえ |
| Pod は、カーネルランタイム環境を他の Pod と共有します。 | いいえ: 各 Pod には専用のカーネルがあります。 |
| ポッドはCPU、メモリ、ストレージ、およびネットワークリソースを他のポッドと共有します。 | いいえ — 各 Pod には専用のリソースがあり、リソース使用率を最大化するために個別にサイズ設定できます。 |
| Pod 仕様で要求されているよりも多くのハードウェアとメモリを、Pod が使用できます。 | いいえ: より大きな vCPU およびメモリー設定を使用して、Pod を再デプロイできます。 |
| Amazon EC2 インスタンスをデプロイおよび管理する必要がある | いいえ |
| Amazon EC2 インスタンスのオペレーティングシステムの保護、保守、パッチ適用を行う必要がある | いいえ |
| ノードをデプロイする時に、追加の [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) 引数 などのブートストラップ引数を提供できます。 | いいえ |
| ノードに割り当てられた IP アドレスとは異なる CIDR ブロックから、IP アドレスを Pod に割り当てることができます。 | いいえ |
| ノードに SSH 接続可能 | いいえ – SSH 接続を行うノードホストオペレーティングシステムはありません。 |
| 独自のカスタム AMI をノードにデプロイ可能 | いいえ |
| 独自のカスタム CNI をノードにデプロイ可能 | いいえ |
| ノード AMI を自分で更新する必要がある | いいえ |
| ノードの Kubernetes バージョンを自分で更新する必要があります。 | いいえ: ノードを管理しません。 |
| Pod で Amazon EBS ストレージを使用可能 | いいえ |
| Pod で Amazon EFS ストレージを使用可能 | [あり](efs-csi.md) |
| Pod で Amazon FSx for Lustre ストレージを使用可能 | いいえ |
| Network Load Balancer をサービスに使用可能 | はい、「[Network Load Balancer を作成する](network-load-balancing.md#network-load-balancer)」を使用する場合 |
| ポッドはパブリックサブネットで実行可能 | いいえ |
| それぞれの Pod に、異なる VPC セキュリティグループを割り当て可能 | はい |
| Kubernetes DaemonSets を実行可能 | いいえ |
| Pod マニフェストで `HostPort` および `HostNetwork` をサポートします | いいえ |
| AWS が利用可能なリージョン | [一部の Amazon EKS 対応リージョン](https://docs.aws.amazon.com/general/latest/gr/eks.html) |
| Amazon EC2 専有ホストでコンテナを実行できます | いいえ |
| 料金 | 個々のFargate メモリとCPU構成のコスト。各 Pod には、独自のコストがあります。詳細については、「[AWS Fargate の料金](https://aws.amazon.com/fargate/pricing/)」を参照してください。 |