**このページの改善にご協力ください**
このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。
# EKS 自動モード設定を構成する
この章ではAmazon エラスティックKubernetesサービス (EKS) 自動モード クラスターの特定の特徴を設定する方法について説明します。EKS 自動モード はほとんどのインフラストラクチャコンポーネントを自動的に管理しますが、ワークロードの要件を満たすように特定の機能をカスタマイズできます。
このトピックで説明されている設定オプションを使用して、自動インフラストラクチャ管理の利点を維持しながら、ネットワーク設定、コンピューティングリソース、ロードバランシングの動作を変更できます。設定を変更する前に、以下のセクションで使用可能なオプションを確認して、ニーズに最適なアプローチを決定してください。
| どの機能を設定したいですか? | 設定オプション |
| --- | --- |
| **ノードネットワークとストレージ** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [Amazon EKS のノードクラスを作成する](create-node-class.md) |
| **ノードコンピューティングリソース** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [EKS 自動モードl 用のノードプールを作成する](create-node-pool.md) |
| **静的キャパシティノードプール** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [EKS Auto Mode での静的キャパシティノードプール](auto-static-capacity.md) |
| **Application Load Balancer の設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [IngressClass を作成して Application Load Balancer を設定する](auto-configure-alb.md) |
| **Network Load Balancer の設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [サービス注釈を使用して Network Load Balancer を設定する](auto-configure-nlb.md) |
| **ストレージクラスの設定** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [ストレージクラスを作成する](create-storage-class.md) |
| **ODCR 使用の制御** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する](auto-odcr.md) |
| **ノードの高度なセキュリティ** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/settings-auto.html) | [ノードの高度なセキュリティ設定を構成する](auto-advanced-security.md) |
# Amazon EKS のノードクラスを作成する
Amazon EKS ノードクラスは、EKS Auto Mode マネージドノードの設定をきめ細かく制御できるテンプレートです。ノードクラスは、ネットワーク設定、ストレージ設定、リソースタグ付けなど、EKS クラスター内のノードのグループに適用されるインフラストラクチャレベルの設定を定義します。このトピックでは、特定の運用要件を満たすようにノードクラスを作成および設定する方法について説明します。
EKS Auto Mode がデフォルト設定を超えて EC2 インスタンスをプロビジョニングおよび設定する方法をカスタマイズする必要がある場合は、ノードクラスを作成すると、重要なインフラストラクチャパラメータを正確に制御できます。例えば、セキュリティを強化するためにプライベートサブネットの配置を指定したり、パフォーマンス重視のワークロード用にインスタンスエフェメラルストレージを設定したり、コスト配分のためにカスタムタグ付けを適用したりできます。
## ノードクラスを作成する
`NodeClass` を作成するには、次の手順に従います。
1. 自分のノードクラス設定で YAML ファイル (`nodeclass.yaml` など) を作成します
1. `kubectl` を使用してこの設定をクラスターに適用します
1. ノードプール設定でノードクラスを参照します。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
`kubectl` がインストールおよび設定されている必要があります。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
### 基本的なノードクラスの例
ノードクラスの例を次に示します。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
この NodeClass により、ノード上のエフェメラルストレージの量が増加します。
次を使用してこの設定を適用します。
```
kubectl apply -f nodeclass.yaml
```
次に、ノードプール設定でノードクラスを参照します。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
## ノードクラスのアクセスエントリを作成する
カスタムノードクラスを作成する場合は、ノードがクラスターに参加できるように EKS アクセスエントリを作成する必要があります。組み込みのノードクラスとノードプールを使用すると、EKS によってアクセスエントリが自動的に作成されます。
アクセスエントリがどのように機能するかについては、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
EKS Auto Mode ノードクラスのアクセスエントリを作成するときは、`EC2` のアクセスエントリタイプを使用する必要があります。
### CLI でアクセスエントリを作成する
**EC2 ノードのアクセスエントリを作成して EKS Auto Node ポリシーを関連付けるには:**
次の CLI コマンドを、使用するクラスター名とノードロール ARN で更新します。ノードロール ARN は、ノードクラス YAML で指定されます。
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### CloudFormation でアクセスエントリを作成する
**EC2 ノードのアクセスエントリを作成して EKS Auto Node ポリシーを関連付けるには:**
次の CloudFormation を、使用するクラスター名とノードロール ARN で更新します。ノードロール ARN は、ノードクラス YAML で指定されます。
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
CloudFormation スタックのデプロイの詳細については、「[Getting started with CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)」を参照してください
## ノードクラスの指定
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws:kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## 考慮事項
+ インスタンスのローカルストレージの容量を確認したい場合は、ノードを記述してエフェメラルストレージリソースを表示できます。
+ **ボリュームの暗号化** – インスタンスの読み取り専用ルートボリュームおよび読み取り/書き込みデータボリュームを暗号化するため、EKS は設定されたカスタム KMS キーを使用します。
+ **ノード IAM ロールの置換** - `NodeClass` に関連付けられているノード IAM ロールを変更する場合は、新しいアクセスエントリを作成する必要があります。EKS は、クラスターの作成時にノード IAM ロールのアクセスエントリを自動的に作成します。ノード IAM ロールには `AmazonEKSAutoNodePolicy` EKS アクセスポリシーが必要です。詳細については、「[EKS アクセスエントリを使用して Kubernetes へのアクセスを IAM ユーザーに許可する](access-entries.md)」を参照してください。
+ **最大 Pod 密度** - EKS では、ノード上の Pod の最大数が 110 に制限されています。この制限は、既存の最大 Pod を計算した後に適用されます。詳細については、「[最適な Amazon EC2 ノードインスタンスタイプを選択する](choosing-instance-type.md)」を参照してください。
+ **タグ** - Kubernetes から EC2 にタグを伝播させる場合は、追加の IAM アクセス許可を設定する必要があります。詳細については、「[EKS Auto Mode での ID とアクセスについての説明](auto-learn-iam.md)」を参照してください。
+ **デフォルトのノードクラス** - カスタムノードクラスに `default` という名前を付けないでください。これは、EKS Auto Mode には、少なくとも 1 つの組み込み `NodePool` を有効にすると自動的にプロビジョニングされる `default` と呼ばれる `NodeClass` が含まれるためです。組み込み `NodePools` を有効にする方法については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
+ **複数のサブネットを使用した `subnetSelectorTerms` 動作** - `subnetSelectorTerms` 条件に一致するサブネットまたは ID で指定したサブネットが複数ある場合、EKS Auto Mode はサブネット全体に分散されたノードを作成します。
+ サブネットが異なるアベイラビリティーゾーン (AZ) にある場合、[Pod トポロジスプレッド制約](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints)や [Topology Aware Routing](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) といった Kubernetes 機能を使用して、Pod とトラフィックをそれぞれゾーン間に分散できます。
+ *同じ AZ 内に* `subnetSelectorTerms` に一致するサブネットが複数ある場合、EKS Auto Mode はその AZ のサブネット全体に分散した各ノードに Pod を作成します。EKS Auto Mode は、同じ AZ 内の他のサブネットの各ノードにセカンダリネットワークインターフェイスを作成します。各サブネットで使用可能な IP アドレスの数に基づいて選択し、サブネットをより効率的に使用します。ただし、EKS Auto Mode が各 Pod に使用するサブネットを指定することはできません。特定のサブネットで Pod を実行する必要がある場合は、代わりに [ポッドのサブネットとセキュリティグループを分離する](#pod-subnet-selector) を使用してください。
## ポッドのサブネットとセキュリティグループを分離する
`podSubnetSelectorTerms` と `podSecurityGroupSelectorTerms` フィールドにより、ポッドがノードとは異なるサブネットとセキュリティグループを使用できるようになるため、高度なネットワーク設定が可能になります。両方のフィールドを一緒に指定する必要があります。この分離により、ネットワークトラフィックのルーティングとセキュリティポリシーの制御が強化されます。
**注記**
この機能は、EKS Auto Mode 以外のコンピューティング用の AWS VPC CNI で使用される[ポッドのセキュリティグループ](security-groups-for-pods.md) (SGPP) 機能とは異なります。SGPP は EKS Auto Mode ではサポートされていません。代わりに、`NodeClass` で `podSecurityGroupSelectorTerms` を使用して、ポッドトラフィックに個別のセキュリティグループを適用します。セキュリティグループは `NodeClass` レベルで適用されます。つまり、その `NodeClass` を使用するノード上のすべてのポッドは、同じのポッドセキュリティグループを共有します。
### 仕組み
`podSubnetSelectorTerms` と `podSecurityGroupSelectorTerms` を設定する場合:
1. ノードのプライマリ ENI は、`subnetSelectorTerms` および `securityGroupSelectorTerms` のサブネットとセキュリティグループを使用します。このインターフェイスには、ノード自身の IP アドレスのみが割り当てられます。
1. EKS Auto Mode では、`podSubnetSelectorTerms` に一致するサブネット内にセカンダリ ENI が作成され、`podSecurityGroupSelectorTerms` のセキュリティグループがそれらにアタッチされます。ポッド IP アドレスは、デフォルトで /28 プレフィックスを使用してこれらのセカンダリ ENI から割り当てられます。連続するプレフィックスブロックが使用できない場合、セカンダリ IP (/32) への自動フォールバックが行われます。`advancedNetworking` で `ipv4PrefixSize` が `"32"` に設定されている場合、セカンダリ IP のみが使用されます。
1. `podSecurityGroupSelectorTerms` で指定されたセキュリティグループは、VPC 内のポッドトラフィックに適用されます。VPC 外を送信先とするトラフィックの場合、ソースネットワークアドレス変換 (SNAT) はポッド IP をノード IP に変換するため、ポッドはノードのプライマリ ENI (およびそのセキュリティグループ) を使用します。この動作は、`NodeClass` の `snatPolicy` フィールドで変更できます。
### ユースケース
以下の場合に `podSubnetSelectorTerms` および `podSecurityGroupSelectorTerms` を使用します。
+ 異なるセキュリティグループを適用して、ノードとポッドのトラフィックを個別に制御する必要がある場合。
+ インフラストラクチャトラフィック (ノード間の通信) とアプリケーショントラフィック (ポッド間の通信) を分離する必要がある場合。
+ Pod サブネットとは異なるネットワーク設定をノードサブネットに適用する。
+ Pod トラフィックに影響を与えずに、ノードトラフィック専用のリバースプロキシまたはネットワークフィルタリングを設定する。`advancedNetworking` と `certificateBundles` を使用して、リバースプロキシと、プロキシの自己署名証明書またはプライベート証明書を定義する。
### 設定例
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### 個別のポッドサブネットとセキュリティグループに関する考慮事項
+ **セキュリティグループの範囲**: `podSecurityGroupSelectorTerms` のセキュリティグループはセカンダリ ENI にアタッチされ、VPC 内のポッドトラフィックに適用されます。SNAT が有効になっている場合 (デフォルトの `snatPolicy: Random`)、VPC から出るトラフィックはノードのプライマリ ENI IP アドレスに変換されるため、`securityGroupSelectorTerms` からのノードのセキュリティグループは代わりにそのトラフィックに適用されます。`snatPolicy: Disabled` を設定すると、ポッドはすべてのトラフィックに独自の IP アドレスを使用するため、ルーティンググループとセキュリティグループが適切に設定されていることを確認する必要があります。
+ **NodeClass レベルの粒度**: ポッドセキュリティグループは、`NodeClass` を使用してノードでスケジュールされたすべてのポッドに適用されます。異なるセキュリティグループを異なるワークロードに適用するには、個別の `NodeClass` リソースと `NodePool` リソースを作成し、テイント、許容範囲、またはノードセレクターを使用してワークロードを適切なノードにスケジュールします。
+ **ポッド密度の低下**: ノードのプライマリネットワークインターフェイスはノード IP 用に予約されており、ポッドに使用できないため、各ノードで実行できるポッドの数が少なくなります。
+ **サブネットセレクターの制限**: 標準 `subnetSelectorTerms` および `securityGroupSelectorTerms` 設定は、ポッドサブネットまたはセキュリティグループの選択には適用されません。
+ **ネットワーク計画**: ワークロード要件をサポートするために、ノードサブネットと Pod サブネットの両方に十分な IP アドレススペースを確保します。
+ **ルーティング設定**: Pod サブネットのルートテーブルとネットワークアクセスコントロールリスト (ACL) が、ノードと Pod サブネット間の通信用に正しく設定されていることを確認します。
+ **アベイラビリティーゾーン**: 複数の AZ にわたって Pod サブネットを作成したことを確認します。特定のポッドサブネットを使用している場合、そのサブネットはノードサブネット AZ と同じ AZ に存在している必要があります。
## ポッドのセカンダリ IP モード
`ipv4PrefixSize` フィールドは、ノードへのセカンダリ IP アドレスのみを割り当てることで、高度なネットワーク設定を有効にします。この機能はノードにプレフィックス (/28) を割り当てず、1 つのセカンダリ IP のみを MinimalIPTarget として維持します。
### ユースケース
次の場合に `ipv4PrefixSize` を使用します:
+ **IP 使用率を抑えたい**: 各ノードでウォームアップされる IP アドレスが 1 つだけになります。
+ **ポッドの解約率を低下させたい**: ポッドの作成速度がそれほど重要ではない場合に適しています。
+ **プレフィックスのフラグメント化を回避したい**: プレフィックスによるフラグメント化が大きな懸念事項、または Auto Mode 使用の阻害要因となっている場合に適しています。
### 設定例
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### セカンダリ IP モードに関する考慮事項
+ **ポッド作成速度の低下**: 1 つのセカンダリ IP のみがウォームアップされるため、より多くのポッドが作成された場合、IPAM サービスによる IP のプロビジョニングにより多くの時間がかかります。
## IPv6 クラスター内の IPv6 ポッドからの IPv4 egress を無効にする。
デフォルトでは、`enableV4Egress` フィールドは `true` です。Auto Mode IPv6 クラスターの場合、この機能を無効にすることで、Auto Mode が IPv6 ポッドに対して egress 専用 IPv4 インターフェイスを作成しないようにすることができます。IPv4 egress インターフェイスはネットワークポリシーの適用対象外であるため、これは重要です。ネットワークポリシーは、ポッドのプライマリインターフェイス (eth0) にのみ適用されます。
### ユースケース
次の場合に `enableV4Egress` を使用します:
+ **IPv6 クラスターを使用する**: IPv4 egress トラフィックはデフォルトで許可されています。
+ **ネットワークポリシーを使用する**: 現在、EKS ネットワークポリシーはデュアルスタックをサポートしていません。`enableV4Egress` を無効にすると、ポッドトラフィックが IPv4 経由で予期せず出力されるのを防ぐことができます。
### 設定例
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### enableV4Egress を無効にする際の考慮事項
+ **IPv6 クラスターのネットワークポリシー**: IPv6 クラスターでは、デフォルトで IPv4 トラフィックが許可されています。`enableV4Egress: false` に設定すると、IPv4 egress トラフィックがブロックされ、特にネットワークポリシーで使用する場合にセキュリティが強化されます。
# EKS 自動モードl 用のノードプールを作成する
Amazon EKS ノードプールにより、Kubernetes クラスター内のコンピューティングリソースを柔軟に管理できます。このトピックでは、クラスターのスケーリングとリソース使用率を最適化するノードプロビジョニングツールである Karpenter を使用してノードプールを作成および設定する方法を示します。Karpenter の ノードプール リソースを使用すると、インスタンスタイプ、アベイラビリティーゾーン、アーキテクチャ、キャパシティータイプなど、コンピューティングリソースの特定の要件を定義できます。
組み込みの `system` および `general-purpose` ノードプールは変更できません。これらは、有効または無効にすることのみができます。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
ノードプール の指定により、サポートされているさまざまなラベルと要件を通じて、EKS クラスターのコンピューティングリソースをきめ細かく制御できます。これには EC2 インスタンスカテゴリ、CPU 設定、アベイラビリティーゾーン、アーキテクチャ (ARM64/AMD64)、キャパシティタイプ (スポットまたはオンデマンド) を指定するためのオプションが含まれます。CPU とメモリの使用量のリソース制限を設定して、クラスターが必要な運用境界内に収まるようにすることもできます。
EKS 自動モードl は広く知られている Kubernetes ラベルを活用して、ノードの特性を識別する一貫性のある標準化された方法を提供します。アベイラビリティーゾーンの `topology.kubernetes.io/zone` や CPU アーキテクチャの `kubernetes.io/arch` といったこのラベルは確立された Kubernetes 規則に従います。さらに、EKS 固有のラベル (プレフィックスが `eks.amazonaws.com/`) により、インスタンスタイプ、CPU メーカー、GPU 機能、ネットワーク仕様などの AWS 固有の属性でこの機能が拡張されます。この標準化されたラベル付けシステムにより、既存の Kubernetes ツールとシームレスに統合できると同時に、緊密な AWS インフラストラクチャ統合が提供されます。
## ノードプール を作成する
Amazon EKS クラスターの ノードプール を作成するには次のステップに従います：
1. 必要な NodePool 設定で `nodepool.yaml` という名前の YAML ファイルを作成します。以下のサンプル設定を使用できます。
1. ノードプール をクラスターに適用します：
```
kubectl apply -f nodepool.yaml
```
1. ノードプール が正常に作成されたことを確認します：
```
kubectl get nodepools
```
1. (任意 ノードプール のステータスをモニタリングします：
```
kubectl describe nodepool default
```
ノードプール がクラスターに存在する有効な ノードクラス を参照していることを確認します。ノードクラス はコンピューティングリソースの AWS 固有の設定を定義します。詳細については「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
## サンプル ノードプール
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## EKS Auto Mode でサポートされているラベル
EKS 自動モードl は以下の広く知られてるラベルをサポートしています。
**注記**
EKS 自動モードl は Karpenter とは異なるラベルを使用します。EC2 マネージドインスタンスに関連するラベルは`eks.amazonaws.com` で始まります。
| ラベル | 例 | 説明 |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-east-2a | AWS リージョン |
| node.kubernetes.io/インスタンス型 | g4dn.8xlarge | AWS インスタンスタイプ |
| kubernetes.io/arch | amd64 | アーキテクチャはインスタンスの [GOARCH 値](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58)によって定義されます |
| karpenter.sh/capacity-type | spot | キャパシティータイプには `spot`、`on-demand` などがあります |
| eks.amazonaws.com/instance-hypervisor | nitro | 特定のハイパーバイザーを使用するインスタンスタイプ |
| eks.amazonaws.com/compute-type | 自動 | EKS 自動モードl マネージドノードを識別します |
| eks.amazonaws.com/instance-encryption-in-transit-supported | 真 | 転送中の暗号化をサポートする (またはサポートしない) インスタンスタイプ |
| eks.amazonaws.com/instance-category | g | 同じカテゴリのインスタンスタイプ、通常は生成番号の前の文字列 |
| eks.amazonaws.com/instance-generation | 4 | インスタンスカテゴリ内のインスタンスタイプ生成番号 |
| eks.amazonaws.com/instance-family | g4dn | プロパティが類似していてリソース量が異なるインスタンスタイプ |
| eks.amazonaws.com/instance-size | 8xlarge | リソース量が類似していてプロパティが異なるインスタンスタイプ |
| eks.amazonaws.com/instance-cpu | 32 | インスタンスにおける CPU の数 |
| eks.amazonaws.com/instance-cpu-manufacturer | `aws` | CPU メーカーの名前 |
| eks.amazonaws.com/instance-memory | 131072 | インスタンスのメモリのメビバイト数 |
| eks.amazonaws.com/instance-ebs-bandwidth | 9500 | インスタンスで使用できる EBS の[最大メガビット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance)数 |
| eks.amazonaws.com/instance-network-bandwidth | 131072 | インスタンスで使用可能な[ベースラインメガビット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html)数 |
| eks.amazonaws.com/instance-gpu-name | t4 | インスタンス上の GPU の名前 (使用可能な場合) |
| eks.amazonaws.com/instance-gpu-manufacturer | nvidia | GPU メーカーの名前 |
| eks.amazonaws.com/instance-gpu-count | 1 | インスタンスにおける GPU の数 |
| eks.amazonaws.com/instance-gpu-memory | 16384 | GPU のメモリのメビバイト数 |
| eks.amazonaws.com/instance-local-nvme | 900 | インスタンス上のローカル nvme ストレージのギビバイト数 |
**注記**
EKS Auto Mode は特定のインスタンスのみをサポートし、最小サイズ要件があります。詳細については、「[EKS Auto Mode でサポートされているインスタンスリファレンス](automode-learn-instances.md#auto-supported-instances)」を参照してください。
## EKS Auto Mode でサポートされていないラベル
EKS 自動モードl は次のラベルをサポートしていません。
+ EKS 自動モードは Linux のみをサポートしています
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## 組み込みノードプールを無効にする
カスタムノードプールを作成する場合は、組み込みノードプールを無効にすることができます。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
## 組み込みノードプールがないクラスター
組み込みノードプールがないクラスターを作成できます。これは、組織がカスタマイズしたノードプールを作成している場合に役立ちます。
**注記**
組み込みノードプールなしでクラスターを作成すると、`default` NodeClass は自動的にプロビジョニングされません。カスタム NodeClass を作成する必要があります。詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
**概要：**
1. `nodePools` と `nodeRoleArn` の両方の値を空にして、EKS クラスターを作成します。
+ eksctl `autoModeConfig` の例:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
詳細については、[eksctl CLI を使用して EKS Auto Mode クラスターを作成する](automode-get-started-eksctl.md)を参照してください。
1. ノードロール ARN を使用してカスタムノードクラスを作成します
+ 詳細については、[Amazon EKS のノードクラスを作成する](create-node-class.md)を参照してください。
1. カスタムノードクラスのアクセスエントリを作成します
+ 詳細については、[ノードクラスのアクセスエントリを作成する](create-node-class.md#auto-node-access-entry)を参照してください。
1. 前述のように、カスタムノードプールを作成します。
## 中断
NodePool を介してノードを中断するように、EKS Auto Mode を複数の方法で設定できます。`spec.disruption.consolidationPolicy`、`spec.disruption.consolidateAfter`、または `spec.template.spec.expireAfter` を使用できます。NodePool の `spec.disruption.budgets` を使用して、EKS Auto Mode の中断をレート制限することもできます。中断される時間枠と同時ノード数を制御することもできます。この動作を設定する手順については、Karpenter ドキュメントの「[Disruption](https://karpenter.sh/docs/concepts/disruption/)」を参照してください。
ノードプールの中断は、次の目的で設定できます。
+ インスタンスの使用率が低いタイミングを特定し、ワークロードを統合する。
+ ノードプールの中断予算を作成して、ドリフト、空、統合が理由でのノードの終了をレート制限する。
デフォルトでは、EKS Auto Mode では以下が行われます。
+ 使用率が低いインスタンスを統合します。
+ 336 時間後にインスタンスを終了します。
+ ノードの 10% の単一の中断予算を設定します。
+ 新しい Auto Mode AMI がリリースされたときに、ドリフトを理由にノードを置き換えることを許可します。これは、およそ週に 1 回行われます。
## 終了猶予期間
EKS Auto NodePool で `terminationGracePeriod` を明示的に定義していない場合、関連付けた NodeClaim に 24 時間 (デフォルト) の終了猶予期間が自動的に適用されます。EKS Auto のカスタム NodePool 設定では `terminationGracePeriod` がデフォルトであることを確認できませんが、NodeClaim には、このデフォルト値が表示されます。猶予期間を NodePool で明示的に設定済みか、NodeClaim でデフォルト設定を行ったかに関係なく、この機能には一貫性があり、予測可能なノード終了動作がクラスター全体で維持されます。
# EKS Auto Mode での静的キャパシティノードプール
Amazon EKS Auto Mode は、静的キャパシティノードプールをサポートしており、ポッドの需要に関係なく決まった数のノードを維持します。静的キャパシティノードプールは、予測可能なキャパシティ、リザーブドインスタンス、または一貫したインフラストラクチャフットプリントの維持が求められる特定のコンプライアンス要件を必要とするワークロードに有用です。
ポッドスケジューリングの需要に基づいてスケールする動的ノードプールとは異なり、静的キャパシティノードプールでは設定したノードの数が維持されます。
## 静的キャパシティノードプールを設定する
静的キャパシティノードプールを作成するには、NodePool 仕様に `replicas` フィールドを設定します。`replicas` フィールドでは、ノードプールが維持するノードの正確な数を定義します。`replicas` の設定方法については、「[例](#static-capacity-examples)」を参照してください。
## 静的キャパシティノードプールに関する考慮事項
静的キャパシティノードプールには、重要な制約と動作がいくつかあります。
**設定に関する制約:**
+ **モードを切り替えることができない**: ノードプールで `replicas` を設定したら、以後削除することはできません。ノードプールでは、静的モードと動的モードとを切り替えることができません。
+ **リソースが制限されている**: 制限セクションでは、`limits.nodes` フィールドのみがサポートされています。CPU とメモリに関する制限は適用されません。
+ **重みフィールドがない**: ノードの選択が優先度に基づいていないため、静的キャパシティノードプールに `weight` フィールドを設定することができません。
**オペレーション動作:**
+ **統合対象外**: 静的キャパシティプールのノードは、統合対象と見なされません。
+ **スケールオペレーション**: スケールオペレーションでは、ノード中断の予算はバイパスされますが、PodDisruptionBudgets は引き続き考慮されます。
+ **ノードの置き換え**: 設定に基づいてドリフト (AMI アップデートなど) と有効期限が発生した場合は、ノードが置き換えられます。
## ベストプラクティス
**容量プランニング:**
+ `limits.nodes` を `replicas` よりも高い値に設定すると、ノードの置き換えオペレーション中に一時的にスケールできるようになります。
+ 制限を設定するときは、ノードドリフトや AMI アップデートに必要な最大キャパシティを考慮してください。
**インスタンス選択:**
+ リザーブドインスタンスがある場合や特定のハードウェア要件がある場合は、特定のインスタンスタイプを使用します。
+ 制限を過度に厳しくしてスケール中にインスタンスの可用性が制限されるような要件は避けてください。
**中断の管理:**
+ 可用性とメンテナンスオペレーションとのバランスが取れるように、適切な中断の予算を設定します。
+ 予算の割合を設定するときは、アプリケーションでノードの置き換えをどの程度許容するかを考慮してください。
**モニタリング:**
+ `status.nodes` フィールドを定期的にモニタリングして、必要なキャパシティが維持されていることを確認します。
+ 実際のノード数が目的のレプリカから逸脱した場合に備えてアラートを設定します。
**ゾーンの分散:**
+ 高可用性を実現するには、静的キャパシティをいくつかのアベイラビリティーゾーンに分散させます。
+ 複数のアベイラビリティーゾーンにまたがる静的キャパシティノードプールを作成すると、EKS Auto Mode により、指定されたゾーンにノードが分散しますが、その分散が均等であるとは限りません。
+ アベイラビリティーゾーン間に想定の範囲内で均等に分散させるには、静的キャパシティノードプールを個別にいくつか作成し、`topology.kubernetes.io/zone` 要件を使用してそれぞれを特定のアベイラビリティーゾーンに固定します。
+ 3 つのゾーンに 12 個のノードを均等に分散させる必要がある場合は、1 つのノードプールを作成して 3 つのゾーンに 12 個のレプリカを分散させるのではなく、3 つのノードプールを作成してそれぞれに 4 個のレプリカを分散させます。
## 静的キャパシティノードプールをスケールする
`kubectl scale` コマンドを使用すると、静的キャパシティノードプール内のレプリカの数を変更できます。
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
スケールダウンすると、EKS 自動モードはノードを適切に終了し、PodDisruptionBudgets を考慮のうえ、実行中のポッドを残りのノードに再スケジュールできるようにします。
## 静的キャパシティノードプールをモニタリングする
以下のコマンドを使用すると、静的キャパシティノードプールをモニタリングできます。
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
`status.nodes` フィールドは、ノードプールで管理されているノードの現在の数を示し、通常の条件下で必要になる `replicas` の数と一致する必要があります。
## トラブルシューティング
**ノードが目的のレプリカに到達しない:**
+ `limits.nodes` の値が十分かどうかを確認します。
+ 要件がインスタンス選択を過度に制限していないことを確認します。
+ 使用しているインスタンスタイプとリージョンの AWS サービスクォータを確認します。
**ノードの置き換えに時間がかかりすぎる:**
+ 同時により多くの置き換えができるように中断予算を調整します。
+ PodDisruptionBudgets がノードの終了を妨げていないかどうかを確認します。
**ノードが予期せずに終了する:**
+ `expireAfter` と `terminationGracePeriod` の設定を確認します。
+ 手動によるノードの終了や AWS メンテナンスイベントを確認します。
## 例
### 基本的な静的キャパシティノードプール
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### 特定のインスタンスタイプの静的キャパシティ
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### マルチゾーンの静的キャパシティノードプール
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### キャパシティ予約による静的キャパシティ
以下の例は、EC2 キャパシティ予約で静的キャパシティノードプールを使用する方法を示しています。EKS Auto Mode での EC2 キャパシティ予約の使用の詳細については、「[EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する](auto-odcr.md)」を参照してください。
`capacityReservationSelectorTerms` を定義する `NodeClass`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
上記の `NodeClass` を参照し、`karpenter.sh/capacity-type: reserved` を使用する `NodePool`
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# IngressClass を作成して Application Load Balancer を設定する
EKS Auto Mode は、インターネットへのクラスターアプリケーションの公開など、ロードバランシングのルーチンタスクを自動化します。
AWS では、Application Load Balancer (ALB) を使用して HTTP および HTTPS トラフィックを処理することを推奨しています。Application Load Balancer は、リクエストの内容に基づいてリクエストをルーティングできます。Application Load Balancer の詳細については、「[What is Elastic Load Balancing?](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html)」を参照してください。
EKS Auto Mode は、Application Load Balancer (ALB) の作成と設定を行います。例えば、`Ingress` Kubernetes オブジェクトを作成すると EKS Auto Mode によってロードバランサーが作成され、クラスターワークロードにトラフィックをルーティングするように設定されます。
**概要**:
1. インターネットに公開するワークロードを作成します。
1. SSL/TLS や VPC サブネットに使用する証明書などの AWS 固有の設定値を指定して、`IngressClassParams` リソースを作成します。
1. `IngressClass` リソースを作成し、EKS Auto Mode がリソースのコントローラーになるように指定します。
1. HTTP パスおよびポートをクラスターワークロードに関連付ける `Ingress` リソースを作成します。
EKS Auto Mode は、`IngressClassParams` リソースで指定されたロードバランサー設定を使用して、`Ingress` リソースで指定されたワークロードをポイントする Application Load Balancer を作成します。
## 前提条件
+ EKS Auto Mode が Amazon EKS クラスターで有効になっている
+ kubectl がクラスターに接続するように設定されている
+ `kubectl apply -f ` を使用して、以下のサンプル設定 YAML ファイルをクラスターに適用できます。
**注記**
EKS Auto Mode では、パブリックサブネットとプライベートサブネットを識別するためにサブネットタグが必要です。
`eksctl` を使用してクラスターを作成した場合は、これらのタグは既にあります。
「[EKS Auto Mode のサブネットにタグを付ける](tag-subnets-auto.md)」ではその方法を説明しています。
## ステップ 1: ワークロードを作成する
まず、インターネットに公開するワークロードを作成します。これは、デプロイやサービスなど、HTTP トラフィックを処理する任意の Kubernetes リソースです。
この例では、`service-2048` というシンプルな HTTP サービスを使用して、ポート `80` をリッスンします。次の `2048-deployment-service.yaml` というマニフェストを適用して、このサービスとそのデプロイを作成します。
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
設定をクラスターに適用します。
```
kubectl apply -f 2048-deployment-service.yaml
```
前記のリソースは、デフォルトの名前空間に作成されます。次のコマンドを実行して、これを検証できます。
```
kubectl get all -n default
```
## ステップ 2: IngressClassParams を作成する
`IngressClassParams` オブジェクトを作成して、Application Load Balancer に対する AWS 固有の設定オプションを指定します。この例では、`alb` という名前の `IngressClassParams` リソース (次のステップで使用する) を作成し、ロードバランサースキームを `internet-facing` として `alb-ingressclassparams.yaml` というファイルで指定します。
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
設定をクラスターに適用します。
```
kubectl apply -f alb-ingressclassparams.yaml
```
## ステップ 3: IngressClass を作成する
`alb-ingressclass.yaml` という名前のファイル内に、`IngressClassParams` リソースで設定された AWS 固有の設定値を参照する `IngressClass` を作成します。`IngressClass` の名前をメモしてください。この例では、`IngressClass` と `IngressClassParams` の両方が `alb` という名前になっています。
`is-default-class` 注釈を使用して、`Ingress` リソースがこのクラスをデフォルトで使用するかどうかを制御します。
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
設定オプションの詳細については、「[IngressClassParams リファレンス](#ingress-reference)」を参照してください。
設定をクラスターに適用します。
```
kubectl apply -f alb-ingressclass.yaml
```
## ステップ 4: Ingress を作成する
`alb-ingress.yaml` という名前のファイルに `Ingress` リソースを作成します。このリソースの目的は、Application Load Balancer のパスとポートをクラスター内のワークロードに関連付けることです。この例では、ポート 80 で `service-2048` という名前のサービスにトラフィックをルーティングする `2048-ingress` という名前の `Ingress` リソースを作成します。
このリソースの構成方法の詳細については、Kubernetes ドキュメントの「[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/)」を参照してください。
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
設定をクラスターに適用します。
```
kubectl apply -f alb-ingress.yaml
```
## ステップ 5: ステータスを確認する
`kubectl` を使用して、`Ingress` のステータスを取得します。ロードバランサーが利用できるようになるまで数分かかる場合があります。
前のステップで設定した `Ingress` リソースの名前を使用します。例えば、次のようになります。
```
kubectl get ingress 2048-ingress
```
リソースの準備ができたら、ロードバランサーのドメイン名を取得します。
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
ウェブブラウザでサービスを表示するには、`Ingress` レスキューで指定したポートとパスを確認します。
## ステップ 6: クリーンアップ
ロードバランサーをクリーンアップするには、次のコマンドを使用します。
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
EKS Auto Mode が、AWS アカウント内の関連するロードバランサーを自動的に削除します。
## IngressClassParams リファレンス
次の表は、一般的に使用される設定オプションのクイックリファレンスです。
| フィールド | 説明 | 値の例 |
| --- | --- | --- |
| `scheme` | ALB が内部向けかインターネット向けかを定義します | `internet-facing` |
| `namespaceSelector` | この IngressClass を使用できる名前空間を制限します | `environment: prod` |
| `group.name` | 1 つの ALB を共有する複数の Ingress をグループ化します | `retail-apps` |
| `ipAddressType` | ALB の IP アドレスタイプを設定します | `dualstack` |
| `subnets.ids` | ALB デプロイにおけるサブネット ID のリスト | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | ALB のサブネットを選択するタグフィルター | `Environment: prod` |
| `certificateARNs` | 使用する SSL 証明書の ARN | ` arn:aws:acm:region:account:certificate/id` |
| `tags` | AWS リソースのカスタムタグ | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | ロードバランサー固有の属性 | `idle_timeout.timeout_seconds: 60` |
## 考慮事項
+ EKS Auto Mode でロードバランサーを設定するのに、IngressClass で注釈を使用することはできません。IngressClass の設定は、IngressClassParams を介して行う必要があります。ただし、個々の Ingress リソースで注釈を使用すると、ロードバランサーの動作を設定できます (`alb.ingress.kubernetes.io/security-group-prefix-lists`や `alb.ingress.kubernetes.io/conditions.*` など)。
+ EKS Auto Mode では、[ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html) を設定できません。
+ クラスター IAM ロールを更新して、Kubernetes から AWS ロードバランサーリソースへのタグの伝播を有効にする必要があります。詳細については、「[EKS Auto リソースのカスタム AWS タグ](auto-learn-iam.md#tag-prop)」を参照してください。
+ リソースを EKS Auto Mode またはセルフマネージド AWS Load Balancer Controller に関連付ける方法については、「[移行のリファレンス](migrate-auto.md#migration-reference)」を参照してください。
+ ロードバランサーの問題の修正方法については、「[EKS 自動モードl のトラブルシューティング](auto-troubleshoot.md)」を参照してください。
+ EKS Auto Mode のロードバランシング機能の使用に関する考慮事項については、「[負荷分散](auto-networking.md#auto-lb-consider)」を参照してください。
次の表は、EKS Auto Mode の IngressClassParams、Ingress 注釈、および TargetGroupBinding 設定の変更の詳細な比較を示しています。これらの表は、API バージョンの変更、廃止された機能、更新されたパラメータ名など、EKS Auto Mode のロードバランシング機能とオープンソースのロードバランサーコントローラーの主な違いを強調しています。
### IngressClassParams
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API バージョンの変更 |
| `spec.certificateArn` | `spec.certificateARNs` | 複数の証明書 ARN のサポート |
| `spec.subnets.tags` | `spec.subnets.matchTags` | サブネット一致スキーマの変更 |
| `spec.listeners.listenerAttributes` | サポートされていません | EKS Auto Mode で未サポート |
### Ingress 注釈
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | サポートされていません | Ingress オブジェクトで `spec.ingressClassName` を使用 |
| `alb.ingress.kubernetes.io/group.name` | サポートされていません | IngressClass でのみグループを指定 |
| `alb.ingress.kubernetes.io/waf-acl-id` | サポートされていません | 代わりに WAF v2 を使用 |
| `alb.ingress.kubernetes.io/web-acl-id` | サポートされていません | 代わりに WAF v2 を使用 |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | サポートされていません | Shield 統合が無効 |
| `alb.ingress.kubernetes.io/auth-type: oidc` | サポートされていません | 現時点で OIDC 認証タイプはサポートされていません |
### TargetGroupBinding
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API バージョンの変更 |
| `spec.targetType` が任意 | `spec.targetType` が必須 | 明示的なターゲットタイプの指定 |
| `spec.networking.ingress.from` | サポートされていません | セキュリティグループなしでは NLB がサポートされなくなりました |
カスタム TargetGroupBinding 機能を使用するには、ターゲットグループにクラスター名と共に eks:eks-cluster-name タグを付けて、必要な IAM アクセス許可をコントローラーに付与する必要があります。TargetGroupBinding リソースまたはクラスターを削除すると、コントローラーがターゲットグループを削除することに注意してください。
# サービス注釈を使用して Network Load Balancer を設定する
Kubernetes サービス注釈を使用して Amazon EKS で Network Load Balancer (NLB) を設定する方法について説明します。このトピックでは、インターネットアクセシビリティ、ヘルスチェック、SSL/TLS ターミネーション、IP ターゲティングモードなど、NLB の動作をカスタマイズするための EKS Auto Mode でサポートされている注釈について説明します。
EKS Auto Mode でタイプ `LoadBalancer` の Kubernetes サービスを作成すると、EKS は指定した注釈に基づいて AWS Network Load Balancer を自動的にプロビジョニングして設定します。この宣言型アプローチにより、Kubernetes マニフェストを通じてロードバランサーの設定を直接管理し、Infrastructure as Code プラクティスを維持できます。
EKS Auto Mode は、デフォルトでタイプ LoadBalancer のサービスすべてに対する Network Load Balancer プロビジョニングを処理します。追加のコントローラーのインストールや設定は必要ありません。`loadBalancerClass: eks.amazonaws.com/nlb` の仕様は、クラスターのデフォルトとして自動的に設定され、既存の Kubernetes ワークロードとの互換性を維持しながらデプロイプロセスが合理化されます。
**注記**
EKS Auto Mode では、パブリックサブネットとプライベートサブネットを識別するためにサブネットタグが必要です。
`eksctl` を使用してクラスターを作成した場合は、これらのタグは既にあります。
「[EKS Auto Mode のサブネットにタグを付ける](tag-subnets-auto.md)」ではその方法を説明しています。
## サンプルサービス
Kubernetes `Service` リソースの詳細については、「[Kubernetes ドキュメント](https://kubernetes.io/docs/concepts/services-networking/service/)」を参照してください。
以下のサンプル `Service` リソースを確認してください。
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## 一般的に使用される注釈
次の表に、EKS Auto Mode でサポートされている、一般的に使用される注釈を示します。EKS Auto Mode は、すべての注釈をサポートしているわけではないことに注意してください。
**ヒント**
以下の注釈はすべて、`service.beta.kubernetes.io/` というプレフィックスを付ける必要があります
| フィールド | 説明 | 例 |
| --- | --- | --- |
| `aws-load-balancer-type` | ロードバランサーのタイプを指定します。新しいデプロイには `external` を使用します。 | `external` |
| `aws-load-balancer-nlb-target-type` | トラフィックをノードインスタンスにルーティングするか、ポッド IP に直接ルーティングするかを指定します。標準デプロイでは `instance` を、直接ポッドルーティングでは `ip` を使用します。 | `instance` |
| `aws-load-balancer-scheme` | ロードバランサーが内部向けかインターネット向けかを指定します。 | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | ターゲットグループのヘルスチェックプロトコル。一般的なオプションは `TCP` (デフォルト) または `HTTP` です。 | `HTTP` |
| `aws-load-balancer-healthcheck-path` | HTTP/HTTPS プロトコルを使用する場合のヘルスチェックの HTTP パス。 | `/healthz` |
| `aws-load-balancer-healthcheck-port` | ヘルスチェックに使用されるポート。特定のポート番号または `traffic-port` を指定できます。 | `traffic-port` |
| `aws-load-balancer-subnets` | ロードバランサーを作成するサブネットを指定します。サブネット ID またはサブネット名を使用できます。 | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | HTTPS/TLS 用の AWS Certificate Manager からの SSL 証明書の ARN。 | ` arn:aws:acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | SSL/TLS を使用するポートを指定します。 | `443, 8443` |
| `load-balancer-source-ranges` | ロードバランサーへのアクセスが許可されている CIDR 範囲。 | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | ロードバランサーおよび関連リソースに適用する追加の AWS タグ。 | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | ロードバランサーが使用するのが IPv4 かデュアルスタック (IPv4 \$1 IPv6) かを指定します。 | `ipv4`-または-`dualstack` |
## 考慮事項
+ クラスター IAM ロールを更新して、Kubernetes から AWS ロードバランサーリソースへのタグの伝播を有効にする必要があります。詳細については、「[EKS Auto リソースのカスタム AWS タグ](auto-learn-iam.md#tag-prop)」を参照してください。
+ リソースを EKS Auto Mode またはセルフマネージド AWS Load Balancer Controller に関連付ける方法については、「[移行のリファレンス](migrate-auto.md#migration-reference)」を参照してください。
+ ロードバランサーの問題の修正方法については、「[EKS 自動モードl のトラブルシューティング](auto-troubleshoot.md)」を参照してください。
+ EKS Auto Mode のロードバランシング機能の使用に関する考慮事項については、「[負荷分散](auto-networking.md#auto-lb-consider)」を参照してください。
ロードバランシングのために EKS Auto Mode に移行する場合は、サービス注釈とリソース設定にいくつかの変更が必要です。次の表は、サポートされていないオプションや推奨される代替案など、新旧の実装の主な違いをまとめたものです。
### サービス注釈
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | サポートされていません | Service で `spec.loadBalancerSourceRanges` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-type` | サポートされていません | Service で `spec.loadBalancerClass` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | サポートされていません | `service.beta.kubernetes.io/aws-load-balancer-scheme` を使用する |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` を使用 |
| 各種ロードバランサー属性 | サポートされていません | `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用する |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用 |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | サポートされていません | 代わりに `service.beta.kubernetes.io/aws-load-balancer-attributes` を使用 |
非推奨のロードバランサー属性注釈から移行するには、これらの設定を `service.beta.kubernetes.io/aws-load-balancer-attributes` 注釈に統合します。この注釈は、各種ロードバランサー属性のキーと値のペアのカンマ区切りリストを受け入れます。例えば、アクセスログ記録とクロスゾーンロードバランシングを指定するには、次の形式を使用します。
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
この統合形式により、より優れた一貫性と柔軟性で、必要な個々の注釈の数を減らしつつロードバランサー属性を設定することができます。既存の Service 設定を確認し、この統合形式を使用するように更新してください。
### TargetGroupBinding
| 旧 | 新 | 説明 |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | API バージョンの変更 |
| `spec.targetType` が任意 | `spec.targetType` が必須 | 明示的なターゲットタイプの指定 |
| `spec.networking.ingress.from` | サポートされていません | セキュリティグループなしでは NLB がサポートされなくなりました |
注意: カスタム TargetGroupBinding 機能を使用するには、ターゲットグループにクラスター名と共に `eks:eks-cluster-name` タグを付けて、必要な IAM アクセス許可をコントローラーに付与する必要があります。TargetGroupBinding リソースまたはクラスターを削除すると、コントローラーがターゲットグループを削除することに注意してください。
# ストレージクラスを作成する
Amazon EKS Auto Mode の `StorageClass` は、アプリケーションが永続的ストレージをリクエストしたときの Amazon EBS ボリュームを自動的にプロビジョニングする方法を定義します。このページでは、Amazon EKS Auto Mode で動作する `StorageClass` を作成して設定し、EBS ボリュームをプロビジョニングする方法について説明します。
`StorageClass` を設定することで、ボリュームタイプ、暗号化、IOPS、その他のストレージパラメータなど、EBS ボリュームのデフォルト設定を指定できます。暗号化管理に AWS KMS キーを使用するように `StorageClass` を設定することもできます。
EKS Auto Mode では、お客様用の `StorageClass` は作成されません。EKS Auto Mode のストレージ機能を使用するには、`ebs.csi.eks.amazonaws.com` を参照する `StorageClass` を作成する必要があります。
まず、`storage-class.yaml` という名前のファイルを作成します。
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
次に、ストレージクラスをクラスターに適用します。
```
kubectl apply -f storage-class.yaml
```
**主要コンポーネント:**
+ `provisioner: ebs.csi.eks.amazonaws.com` - EKS Auto Mode を使用する
+ `allowedTopologies` - `matchLabelExpressions` を `eks.amazonaws.com/compute-type:auto` に一致するように指定した場合、自動モードを使用してポッドに必要なボリュームを自動的にプロビジョニングするようにすれば、そのポッドは自動以外のノードにスケジュールされなくなります。
+ `volumeBindingMode: WaitForFirstConsumer` - ポッドが必要とするまでボリュームの作成を遅らせる
+ `type: gp3` - EBS ボリュームタイプを指定する
+ `encrypted: "true"` – EBS は、`StorageClass` を使用して作成されたすべてのボリュームを暗号化します。EBS はデフォルトの `aws/ebs` キーエイリアスを使用します。詳細については、「Amazon EBS ユーザーガイド」の「[How Amazon EBS encryption works](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html)」を参照してください。この値は省略可能ですが、推奨です。
+ `storageclass.kubernetes.io/is-default-class: "true"` – 永続ボリュームのクレームで別のボリュームクラスを指定しない限り、Kubernetes はデフォルトでこのストレージクラスを使用します。この値はオプションです。別のストレージコントローラーから移行する場合は、この値を設定するときに注意してください。
## セルフマネージド KMS キーを使用して EBS ボリュームを暗号化する
セルフマネージド KMS キーを使用して EKS Auto Mode によって自動化される EBS ボリュームを暗号化するには、以下を実行する必要があります。
1. セルフマネージド KMS キーを作成します。
+ 詳細については、「KMS ユーザーガイド」の「[Create a symmetric encryption KMS key](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html)」または「[How Amazon Elastic Block Store (Amazon EBS) uses KMS](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html)」を参照してください。
1. KMS キーへのアクセスを許可する新しいポリシーを作成します。
+ 以下のサンプル IAM ポリシーを使用してポリシーを作成します。新しいセルフマネージド KMS キーの ARN を挿入します。詳細については、「AWS IAM ユーザーガイド」の「[ロールの作成とポリシーのアタッチ (コンソール)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html)」を参照してください。
1. ポリシーを EKS クラスターロールにアタッチします。
+ AWS コンソールを使用して、EKS クラスターロールの ARN を見つけます。ロール情報は **[概要]** セクションに表示されます。詳細については、「[Amazon EKS クラスター の IAM ロール](cluster-iam-role.md)」を参照してください。
1. `parameters.kmsKeyId` フィールドの KMS キー ID を参照するように `StorageClass` を更新します。
### サンプルセルフマネージド KMS IAM ポリシー
以下のポリシーで次の値を更新します。
+ `` – AWS アカウント ID (`111122223333` など)
+ `` – クラスターの AWS リージョン (`us-west-2` など)
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### サンプルセルフマネージド KMS `StorageClass`
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass` パラメータリファレンス
Kubernetes `StorageClass` リソースの一般的な情報については、Kubernetes ドキュメントの「[ストレージクラス](https://kubernetes.io/docs/concepts/storage/storage-classes/)」を参照してください。
`StorageClass` リソースの `parameters` セクションは AWS に固有です。次の表を使用して使用可能なオプションを確認してください。
| パラメータ | 値 | デフォルト | 説明 |
| --- | --- | --- | --- |
| 「csi.storage.k8s.io/fstype」 | xfs、ext2、ext3、ext4 | ext4 | ボリュームの作成時にフォーマットされるファイルシステムタイプ。このパラメータは大文字と小文字が区別されます。 |
| 「type」 | io1、io2、gp2、gp3、sc1、st1、standard、sbp1、sbg1 | gp3 | EBS ボリュームタイプ。 |
| 「iopsPerGB」 | | | GiB ごとの 1 秒あたりの I/O オペレーション回数秒。IO1、IO2、GP3 ボリュームで指定できます。 |
| 「allowAutoIOPSPerGBIncrease」 | true、false | false | `"true"` であると、`iopsPerGB * ` が小さすぎて AWS でサポートされている IOPS 範囲に収まらない場合に、CSI ドライバーによりボリュームの IOPS が増加します。この結果、ユーザーが指定する PVC キャパシティーや `iopsPerGB` 値が小さすぎる場合でも、動的プロビジョニングが常に成功します。一方、このようなボリュームの IOPS は `iopsPerGB` でリクエストされた値よりも高くなるため、追加コストが発生する可能性があります。 |
| 「iops」 | | | 1 秒あたりの I/O オペレーション回数。IO1、IO2、GP3 ボリュームで指定できます。 |
| 「throughput」 | | 125 | 単位 MiB/秒でのスループット。gp3 ボリュームタイプが指定されている場合にのみ有効です。 |
| 「encrypted」 | true、false | false | ボリュームを暗号化するかどうか。有効な値は「true」または「false」です。 |
| 「blockExpress」 | true、false | false | io2 Block Express ボリュームの作成を有効にします。 |
| 「kmsKeyId」 | | | ボリュームの暗号化時に使用するキーの完全な ARN。指定されていない場合、AWS ではボリュームが存在するリージョンのデフォルトの KMS キーが使用されます。これは、変更されていない場合、`/aws/ebs` という名前の自動生成キーになります。 |
| 「blockSize」 | | | 基盤となるファイルシステムをフォーマットするときに使用するブロックサイズ。Linux ノードと fstype `ext2`、`ext3`、`ext4` または `xfs` でのみサポートされます。 |
| 「inodeSize」 | | | 基盤となるファイルシステムをフォーマットするときに使用する inode サイズ。Linux ノードと fstype `ext2`、`ext3`、`ext4` または `xfs` でのみサポートされます。 |
| 「bytesPerInode」 | | | 基盤となるファイルシステムをフォーマットするときに使用する `bytes-per-inode`。Linux ノードと fstype `ext2`、`ext3`、`ext4` でのみサポートされます。 |
| 「numberOfInodes」 | | | 基盤となるファイルシステムをフォーマットするときに使用する `number-of-inodes`。Linux ノードと fstype `ext2`、`ext3`、`ext4` でのみサポートされます。 |
| 「ext4BigAlloc」 | true、false | false | `bigalloc` フォーマットオプションを有効にして、クラスター化されたブロック割り当てを使用するように `ext4` ファイルシステムを変更します。警告: ノードの Linux カーネルでは `bigalloc` が完全にはサポートされない場合があります。 |
| 「ext4ClusterSize」 | | | `bigalloc` 機能が有効になっている場合に、`ext4` ファイルシステムをフォーマットするときに使用するクラスターサイズ。注: `ext4BigAlloc` パラメータを true に設定する必要があります。 |
詳細については、GitHub の「[AWS EBS CSI Driver](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md)」を参照してください。
## 考慮事項
**注記**
EKS オートモードノードの EKS オートモード StorageClasses に依存するワークロードのみをデプロイできます。ノードのタイプが混在するクラスターがある場合は、ワークロードを EKS オートモードノードでのみ実行するように設定する必要があります。詳細については、「[ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する](associate-workload.md)」を参照してください。
EKS Auto Mode のブロックストレージ機能は、EBS CSI ドライバーとは異なります。
+ 静的プロビジョニング
+ EKS Auto Mode で外部作成の EBS ボリュームを使用する場合は、キー `eks:eks-cluster-name` とクラスター名の値を含む AWS タグを手動で追加する必要があります。
+ ノード起動テイント
+ ノード起動テイント機能を使用して、ストレージ機能の準備が整う前にポッドのスケジューリングを防ぐことはできません
+ 動的にプロビジョニングされたボリュームのカスタムタグ
+ 追加タグ CLI フラグを使用して、動的にプロビジョニングされた EBS ボリュームにカスタムタグを設定することはできません
+ `StorageClass` タグ付けを使用してカスタムタグを追加できます。EKS Auto Mode は、関連付けられた AWS リソースにタグを追加します。カスタムタグのクラスター IAM ロールを更新する必要があります。詳細については、「[EKS Auto リソースのカスタム AWS タグ](auto-learn-iam.md#tag-prop)」を参照してください。
+ EBS 詳細パフォーマンスメトリクス
+ EBS 詳細パフォーマンスの Prometheus メトリクスにアクセスできません
## CSI スナップショットコントローラーアドオンをインストールする
EKS Auto Mode は、CSI スナップショットコントローラー Amazon EKS アドオンと互換性があります。
AWS では、組み込み `system` ノードプールで実行するようにこのアドオンを設定することをお勧めします。
詳細については、以下を参照してください。
+ [ハードウェア専有インスタンスで重要なアドオンを実行する](critical-workload.md)
+ [組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)
+ [CSI ボリュームのためにスナップショット機能を有効にする](csi-snapshot-controller.md)
### スナップショットコントローラーをシステムノードプールにインストールするには
1. AWS コンソールで EKS クラスターを開きます
1. **[アドオン]** タブから、**[アドオンをさらに追加]** を選択します
1. **[CSI スナップショットコントローラー]**、**[次へ]** の順に選択します
1. **[選択したアドオン設定を構成する]** ページで、**[オプションの設定]** を選択して **[アドオン設定スキーマ]** を表示します
1. 次の yaml を挿入して、スナップショットコントローラーを `system` ノードプールに関連付けます。スナップショットコントローラーには、`CriticalAddonsOnly` テイントの許容が含まれています。
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. **[次へ]** を選択します
1. アドオン設定を確認し、**[作成]** を選択します
# EKS 自動モードl を無効にする
既存の EKS クラスターで EKS 自動モードl を無効にすることができます。これは破壊的な操作です。
+ EKS はEKS 自動モードl によって運用されているすべての EC2 インスタンスを終了します。
+ EKS はEKS 自動モードl によって運用されているすべてのロードバランサーを削除してください。
+ EKS はEKS 自動モードl によってプロビジョニングされた EBS ボリュームを削除**しません**。
EKS Auto Mode は作成するリソースを完全に管理するように設計されています。手動で操作すると、EKS Auto Mode が無効になっているときにそれらのリソースを完全にクリーンアップできなくなる可能性があります。例えば、外部のセキュリティグループルールからマネージドセキュリティグループを参照し、クラスターの EKS Auto Mode を無効にする前にその参照を削除するのを忘れた場合、マネージドセキュリティグループはリークします (削除されません)。以下のステップではリークされたセキュリティグループが発生した場合に削除する方法について説明します。
## EKS 自動モードl を無効にする (AWS コンソール)
1. AWS マネジメントコンソールでクラスターの概要ページを開きます。
1. **[EKS 自動モードl]** で **[管理]** を選択してください
1. **EKS 自動モードl** を `off` に切り替えます。
このプロセスの最後にマネージドセキュリティグループが削除されない場合は、「[セキュリティグループを削除する](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html)」の説明を参照して手動で削除できます。
## EKS 自動モードl を無効にする (AWS CLI)
既存のクラスターで EKS 自動モードl を無効にするには次のコマンドを使用します。
`aws` CLI をインストールし、EKS クラスターを管理するのに十分なアクセス許可が付与された状態でログインする必要があります。詳細については「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
**注記**
コンピューティング、ブロックストレージ、およびロードバランシング機能はすべて、同じリクエストで有効または無効にする必要があります。
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
EKS Auto Mode を無効にした後、リークした EKS Auto Mode セキュリティグループ の削除に失敗したかどうかは次のように確認できます。
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
セキュリティグループを削除するには：
```
aws ec2 delete-security-group --group-name=
```
# EKS Auto Mode クラスターの Kubernetes バージョンを更新する
このトピックでは、Auto Mode クラスターの Kubernetes バージョンを更新する方法について説明します。Auto Mode は、ポッド中断の予算を通じてワークロードの可用性を維持しながら、ノード交換によるコントロールプレーンの更新を調整することで、バージョン更新プロセスを簡素化します。
Auto Mode クラスターのアップグレード時に、従来手動更新が必要だった多くのコンポーネントがサービスの一部として管理されるようになりました。アップグレードプロセスの自動化された側面とユーザー担当部分を理解することで、クラスターのバージョンをスムーズに移行できます。
## EKS Auto Mode による更新についての説明
コントロールプレーンのアップグレードを開始したら、EKS Auto Mode によってクラスター内のノードがアップグレードされます。ノードの有効期限が切れると、EKS Auto Mode によって新しいノードに置き換えられます。新しいノードには、対応する新しい Kubernetes バージョンがあります。EKS Auto Mode は、ノードのアップグレード時にポッド中断の予算を監視します。
さらに、次のようなコンポーネントは更新する必要がありません。
+ Amazon VPC CNI
+ AWS ロードバランサーコントローラー
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS EBS CSI ドライバー
EKS Auto Mode は、これらのコンポーネントをサービス機能に置き換えます。
以下の更新は引き続きユーザーが行います。
+ クラスターにデプロイされたアプリケーションとワークロード
+ セルフマネージドアドオンおよびコントローラー
+ Amazon EKS アドオン
+ 「[Amazon EKS アドオンを更新する](updating-an-add-on.md)」ではその方法を説明しています。
「[クラスターのアップグレードのベストプラクティス](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)」を参照してください
## クラスターの更新を開始する
クラスターの更新を開始するには、「[既存のクラスターを新しい Kubernetes バージョンに更新する](update-cluster.md)」を参照してください。
# 組み込み NodePool を有効または無効にする
EKS Auto Mode には 2 つの組み込み NodePool があります。これらの NodePool を有効または無効にするには、AWS コンソール、CLI、または API を使用します。
## 組み込み NodePool リファレンス
+ `system`
+ この NodePool には `CriticalAddonsOnly` テイントがあります。CoreDNS など多くの EKS アドオンで、このテイントが許容されています。このシステムノードプールを使用して、クラスターに不可欠なアプリケーションを分離します。
+ `amd64` と `arm64` アーキテクチャの両方をサポートします。
+ `general-purpose`
+ この NodePool は、クラスター内の汎用ワークロード用のノードの起動をサポートします。
+ `amd64` アーキテクチャのみを使用します。
両方の組み込み NodePool:
+ デフォルトの EKS NodeClass を使用する
+ オンデマンド EC2 容量のみを使用する
+ C、M、および R EC2 インスタンスファミリーを使用する
+ 世代 5 以降の EC2 インスタンスが必要になる
**注記**
EKS が「デフォルト」の NodeClass をプロビジョニングするには、少なくとも 1 つの組み込み NodePool を有効にする必要があります。すべての組み込み NodePool を無効にする場合は、カスタム NodeClass を作成し、それを使用するように NodePool を設定する必要があります。NodeClass の詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
## 手順
### 前提条件
+ AWS コマンドラインインターフェイス (AWS CLI) の最新バージョンがデバイスにインストールおよび設定されていること。現在のバージョンを確認するには「`aws --version`」を参照してください。最新バージョンをインストールするには、「AWS コマンドラインインターフェイスユーザーガイド」の「[インストール](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」および「[aws configure を使用したクイック設定](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config)」を参照してください。
+ 十分な IAM アクセス許可を使用して CLI にログインし、IAM ポリシー、IAM ロール、EKS クラスターなどの AWS リソースを作成します。
### AWS CLI で有効にする
次のコマンドを使用して、両方の組み込み NodePool を有効にします。
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
コマンドを変更して、NodePool を選択的に有効にすることができます。
### AWS CLI で無効にする
次のコマンドを使用して、両方の組み込み NodePool を無効にします。
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# ワークロードが EKS Auto Mode ノードにデプロイされるかどうかを制御する
EKS Auto Mode を使用して EKS クラスターでワークロードを実行する場合、特定のワークロードが EKS Auto Mode ノードで実行されるか、他のコンピューティングタイプで実行されるかを制御することが必要になる場合があります。このトピックでは、ノードセレクターとアフィニティルールを使用して、ワークロードを目的のコンピューティングインフラストラクチャでスケジュールする方法について説明します。
このトピックの例では、`eks.amazonaws.com/compute-type` ラベルを使用して EKS Auto Mode ノードへのワークロードのデプロイを要求または禁止する方法を示します。これは、EKS Auto Mode と、セルフマネージド Karpenter プロビジョナーや EKS マネージドノードグループなどの他のコンピューティングタイプの両方を実行している混合モードクラスターで特に便利です。
EKS Auto Mode ノードでは、ラベル `eks.amazonaws.com/compute-type` の値が `auto` に設定されています。このラベルを使用して、ワークロードが EKS Auto Mode によって管理されるノードにデプロイされるかどうかを制御できます。
## ワークロードを EKS Auto Mode ノードにデプロイするように要求する
**注記**
この `nodeSelector` 値は EKS Auto Mode では必須ではありません。この `nodeSelector` 値は、クラスターを混合モードで実行している場合にのみ関連し、ノードタイプは EKS Auto Mode で管理されません。例えば、EKS マネージドノードグループを使用してクラスターに静的コンピューティング容量をデプロイし、EKS Auto Mode で動的計算能力を管理しているとします。
この `nodeSelector` をデプロイまたは他のワークロードに追加して、Kubernetes が EKS Auto Mode ノードにスケジュールするように要求できます。
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## ワークロードを EKS Auto Mode ノードにデプロイしないように要求する
この `nodeAffinity` をデプロイまたは他のワークロードに追加して、Kubernetes が EKS Auto Mode ノードにスケジュール**しないように**要求できます。
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# ハードウェア専有インスタンスで重要なアドオンを実行する
このトピックでは、EKS Auto Mode が `system` ノードプールにワークロードをスケジュールできるように、`CriticalAddonsOnly` の容認を持つワークロードをデプロイする方法について説明します。
EKS Auto Mode の組み込みの `system` ノードプールは、専用インスタンス上で重要なアドオンを実行するために設計されています。この分離により、重要なコンポーネントに専用のリソースが備わり、一般的なワークロードから分離されることが保証され、クラスター全体の安定性とパフォーマンスが向上します。
このガイドでは、`CriticalAddonsOnly` の容認と適切なノードセレクターを利用して、`system` ノードプールにアドオンをデプロイする方法を説明します。これらのステップに従うことで、EKS Auto Mode の特殊なノードプール構造が提供する分離とリソース割り当ての利点を活用して、重要なアプリケーションを専用の `system` ノードにスケジュールできるようになります。
EKS Auto Mode には、`general-purpose` と `system` の 2 つのノードプールが組み込まれています。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
`system` ノードプールの目的は、重要なアドオンを異なるノードに分離することです。`system` ノードプールによってプロビジョニングされたノードには、`CriticalAddonsOnly` という Kubernetes のテイントがあります。Kubernetes は、対応する容認がある場合のみ、これらのノードにポッドをスケジュールします。詳細については、Kubernetes ドキュメントの「[テイントと容認](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)」を参照してください。
## 前提条件
+ EKS Auto Mode クラスターで組み込みの `system` ノードプールが有効になっていること。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
+ `kubectl` がインストールされ、設定済みであること。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
## 手順
以下の yaml の例を確認してください。以下の設定に留意してください。
+ `nodeSelector` — これにより、ワークロードが組み込みの `system` ノードプールに関連付けられます。このノードプールは AWS API で有効にする必要があります。詳細については、「[組み込み NodePool を有効または無効にする](set-builtin-node-pools.md)」を参照してください。
+ `tolerations` — この容認は、`system` ノードプール内のノードの `CriticalAddonsOnly` テイントを克服します。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
`system` ノードプールで実行するようにワークロードを更新するには、以下の操作を行う必要があります。
1. 既存のワークロードを更新して、上記で説明した以下の設定を追加します。
+ `nodeSelector`
+ `tolerations`
1. `kubectl apply` を使用して、更新されたワークロードをクラスターにデプロイする
ワークロードを更新すると、専用ノードで実行されるようになります。
# EKS Auto Mode でネットワークポリシーを使用する
## 概要:
お客様が EKS を使用してアプリケーション環境をスケールするにつれて、クラスター内外のリソースへの不正アクセスを防ぐ必要があり、そのためにはネットワークトラフィックの分離がますます欠かせないものになります。これは、クラスター内で互いに関連性のない複数のワークロードが並行して動作するマルチテナント環境で特に重要です。Kubernetes ネットワークポリシーを使用すると、Kubernetes ワークロードのネットワークセキュリティ体制を強化し、それをクラスター外のエンドポイントと強固に統合できます。EKS 自動モードは、さまざまなタイプのネットワークポリシーをサポートしています。
### レイヤー 3 と 4 の分離
標準の Kubernetes ネットワークポリシーは OSI ネットワークモデルのレイヤー 3 と 4 で動作し、Amazon EKS クラスター内の IP アドレスまたはポートレベルでトラフィックフローを制御できます。
#### ユースケース
+ ワークロード間でネットワークトラフィックをセグメント化すると、関連するアプリケーションのみが相互に通信できるようになります。
+ ポリシーを使用して名前空間レベルでテナントを分離すると、ネットワークを分離できます。
### DNS ベースの適用
お客様が EKS にデプロイするワークロードはより広範な分散環境に属しているのが一般的で、その中にはクラスター外のシステムやサービスとの通信を必要とするものもあります (インバウンドトラフィック)。こうしたシステムやサービスは、AWS クラウド内にあっても AWS 外にあってもかまいません。ドメインネームシステム (DNS) ベースのポリシーを使用すると、予測精度の高い安定したアプローチに沿って、ポッドからクラスター外のリソースやエンドポイントへの不正アクセスを防ぎ、セキュリティ体制を強化できます。このメカニズムにより、特定の IP アドレスを手動で追跡して許可リストに登録する必要がなくなります。DNS ベースのアプローチに沿ってリソースを保護することで、アップストリームサーバーやホストを変更する際にセキュリティ体制を緩和することも、ネットワークポリシーを変更することもなく、柔軟に外部インフラストラクチャを更新できます。完全修飾ドメイン名 (FQDN)、または DNS ドメイン名に一致するパターンを使用すると、外部エンドポイントへの出力トラフィックをフィルタリングできます。これにより、クラスター外の特定のエンドポイントに複数のサブドメインが関連付けられている場合に、各サブドメインへのアクセスを柔軟に拡張できます。
#### ユースケース
+ Kubernetes 環境からクラスター外のエンドポイントへのアクセスをフィルタリングする場合には、DNS ベースのアプローチを標準とします。
+ マルチテナント環境で AWS サービスへのアクセスを保護します。
+ ハイブリッドクラウド環境でポッドからオンプレミスワークロードへのネットワークアクセスを管理します。
### 管理者 (またはクラスター範囲の) ルール
マルチテナントシナリオのように、ネットワークセキュリティ標準をクラスター全体に適用しなければならないという要件が求められる場合があります。名前空間ごとにポリシーを繰り返し定義して維持するのではなく、単一のポリシーを使用して、名前空間に関係なく、クラスター内のさまざまなワークロードに対するネットワークアクセスコントロールを一元管理できます。こうしたタイプのポリシーでは、レイヤー 3、レイヤー 4、および DNS ルールの使用時に適用されるネットワークフィルタリングルールの適用範囲を拡張できます。
#### ユースケース
+ EKS クラスター内のすべての (または一部の) ワークロードに対するネットワークアクセスコントロールを一元管理します。
+ クラスター全体にわたるデフォルトのネットワークセキュリティ体制を定義します。
+ 組織のセキュリティ標準を運用効率の高い方法でクラスターの範囲へと拡張します。
## 開始方法
### 前提条件
+ EKS Auto Mode が有効になっている Amazon EKS クラスター
+ kubectl がクラスターに接続するように設定されている
### ステップ 1: ネットワークポリシーコントローラーを有効にする
EKS Auto Mode でネットワークポリシーを使用するには、まずクラスターに ConfigMap を適用してネットワークポリシーコントローラーを有効にする必要があります。
1. 以下の内容で `enable-network-policy.yaml` という名前のファイルを作成します。
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. ConfigMap をクラスターに適用します。
```
kubectl apply -f enable-network-policy.yaml
```
### ステップ 2: ネットワークポリシーを作成してテストする
これで、EKS Auto Mode クラスターが Kubernetes ネットワークポリシーをサポートするように設定されました。これは [Amazon EKS のネットワークポリシーの星型デモ](network-policy-stars-demo.md) でテストできます。
### ステップ 3: ノードクラスでネットワークポリシーエージェント設定を調整する (オプション)
オプションで新しいノードクラスを作成して、ノード上のネットワークポリシーエージェントのデフォルトの動作を変更したり、ネットワークポリシーイベントのログ記録を有効にしたりできます。これを実行するには、以下の手順を実行します。
1. 次の内容でノードクラス YAML ファイル (例: `nodeclass-network-policy.yaml`) を作成または編集します。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. ノードクラス設定をクラスターに適用します。
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. ノードクラスが作成されていることを確認します。
```
kubectl get nodeclass network-policy-config
```
1. このノードクラスを使用するようにノードプールを更新します。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
## 動作の仕組み
### DNS ベースのネットワークポリシー
![\[EKS 自動で DNS ベースのポリシーが適用される際のワークフローの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[EKS 自動で DNS ベースのポリシーが適用される際のワークフローの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/apply-dns-policy-2.png)
1. プラットフォームチームが、DNS ベースのポリシーを EKS クラスターに適用します。
1. ネットワークポリシーコントローラーが、クラスター内でのポリシーの作成をモニタリングし、ポリシーエンドポイントを調整します。このユースケースの場合、ネットワークポリシーコントローラーは、作成されたポリシーの許可リストに登録されたドメインに基づいて DNS リクエストをフィルタリングするようにノードエージェントに指示します。ドメイン名を許可リストに登録する場合は、FQDN を使用するか、Kubernetes リソース設定に定義されたパターンと一致するドメイン名を使用します。
1. ワークロード A が、クラスター外のエンドポイントの IP を解決しようとします。DNS リクエストはまずプロキシを通過します。その際に、ネットワークポリシーで適用された許可リストに基づいて該当するリクエストがフィルタリングされます。
1. DNS フィルター許可リストを通過した DNS リクエストは、CoreDNS にプロキシされます。
1. CoreDNS は、受け取ったリクエストを外部 DNS リゾルバー (Amazon Route 53 Resolver) に送信して、ドメイン名の背後にある IP アドレスのリストを取得します。
1. 解決した IP が TTL と共に、DNS リクエストへのレスポンスで返されます。こうして解決した IP が eBPF マップに書き込まれて、次のステップで IP レイヤーを適用する際に使用されます。
1. ポッドの veth インターフェイスにアタッチされた eBPF プローブが、所定のルールに基づいて、ワークロード A からクラスター外のエンドポイントへのエグレストラフィックをフィルタリングします。これにより、ポッドは許可リストに登録されたドメインの IP にのみクラスター外のトラフィックを送信できるようになります。こうした IP の有効性は、外部 DNS リゾルバー (Amazon Route 53 Resolver) から取得した TTL に基づいています。
#### ApplicationNetworkPolicy を使用する
`ApplicationNetworkPolicy` は、単一のカスタムリソース定義 (CRD) を使用して、標準の Kubernetes ネットワークポリシーの機能と DNS ベースのフィルタリングを名前空間レベルで結合します。そのため、`ApplicationNetworkPolicy` は以下の用途に使用できます。
1. IP ブロックとポート番号を使用して、ネットワークスタックのレイヤー 3 と 4 に制限内容を定義します。
1. ネットワークスタックのレイヤー 7 で機能するルールを定義し、FQDN に基づいてトラフィックをフィルタリングします。
**重要**
`ApplicationNetworkPolicy` で定義した DNS ベースのルールは、EKS 自動モードで起動した EC2 インスタンスで動作するワークロードにのみ適用できます。`ApplicationNetworkPolicy` は、標準の Kubernetes `NetworkPolicy` のすべてのフィールドをサポートするほか、Egress ルール用の FQDN フィルターにも対応しています。
**警告**
同じ名前空間内で `ApplicationNetworkPolicy` と `NetworkPolicy` に同じ名前を使用しないでください。名前が競合すると、生成された `PolicyEndpoints` オブジェクトにどちらのポリシーも正しく反映されない可能性があります。エラーになることなくどちらのリソースも受け入れられるため、この問題を診断するのは容易ではありません。
名前の競合を解決するには、その名前空間内で一意になるように `ApplicationNetworkPolicy` または `NetworkPolicy` の名前を変更し、対応する `PolicyEndpoints` オブジェクトが正しく更新されることを確認します。
#### 例
EKS 自動モードクラスターにワークロードがあり、DNS 名が付与されたロードバランサーの背後にあるオンプレミスのアプリケーションと通信する必要があります。そのために、次のネットワークポリシーを使用します。
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
Kubernetes ネットワークレベルでは、`role: backend` というラベルが付いた「galaxy」名前空間内のポッドからのエグレスが、TCP ポート 8080 で **myapp.mydomain.com** というドメイン名に接続できるようになります。また、VPC から社内のデータセンターへのエグレストラフィック用にネットワーク接続をセットアップする必要があります。
![\[EKS 自動でオンプレミスのアプリケーションと通信しているワークロードの図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### 管理者 (あるいはクラスター) ネットワークポリシー
![\[EKS でネットワークポリシーが評価される順序を示した図\]](http://docs.aws.amazon.com/ja_jp/eks/latest/userguide/images/evaluation-order.png)
#### ClusterNetworkPolicy を使用する
`ClusterNetworkPolicy` を使用する場合、管理者階層ポリシーが最初に評価され、このポリシーを上書きすることはできません。管理者階層ポリシーが評価されたら、名前空間範囲の標準ポリシーに従って、適用したネットワークセグメンテーションルールが実行されます。そのためには、`ApplicationNetworkPolicy` または `NetworkPolicy` を使用します。最後に、ベースライン階層ルールが適用されます。ここには、クラスターワークロードに対するデフォルトのネットワーク制限が定義されています。こうしたベースライン階層ルールは、必要に応じて名前空間範囲のポリシーで上書き**できます**。
#### 例
クラスター内にアプリケーションがあり、これを他のテナントワークロードから分離する必要があります。他の名前空間からクラスタートラフィックを明示的にブロックすると、機密性の高いワークロード名前空間へのネットワークアクセスを防ぐことができます。
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## 考慮事項
### ポリシー評価順序を理解する
EKS でサポートされているネットワークポリシー機能は、トラフィックを予測して安全に管理できるように、特定の順序で評価されます。そのため、評価の流れを理解したうえで、ご使用の環境に適した効果的なネットワークセキュリティ体制を設計することが重要です。
1. **管理者層ポリシー (最初に評価)**: 管理者階層のすべての ClusterNetworkPolicy が他のポリシーよりも先に評価されます。管理者階層内では、優先順位に従って (優先順位番号の最も小さいものから) ポリシーが処理されます。次にどうなるかは、アクションタイプによって決まります。
+ **拒否アクション (最も高い優先順位)**: 拒否アクションを定義した管理者ポリシーがトラフィックと一致すると、そのトラフィックは他のポリシーとは関係なくすぐにブロックされます。ClusterNetworkPolicy や NetworkPolicy ルールはそれ以上処理されません。これにより、組織全体のセキュリティコントロールを名前空間レベルのポリシーで上書きできないようにしています。
+ **許可アクション**: 拒否ルールが評価されると、許可アクションを定義した管理者ポリシーが優先順位に従って (優先順位番号の最も小さいものから) 処理されます。許可アクションに一致すると、トラフィックは受け入れられ、ポリシーはそれ以上評価されません。これらのポリシーは、ラベルセレクターに基づいて複数の名前空間に対するアクセスを許可して、特定のリソースにどのワークロードがアクセスできるかを一元的に制御できます。
+ **パスアクション**: 管理階層ポリシーにパスアクションを定義すると、意思決定が下位の階層に委任されます。トラフィックがパスルールに一致すると、そのトラフィックの残りの管理者階層ルールの評価がスキップされ、NetworkPolicy 階層に直接進みます。これにより、管理者は特定のトラフィックパターンに対する制御をアプリケーションチームに明示的に委任できます。例えば、パスルールを使用すると、外部アクセスを厳密に制御しつつ、名前空間内のトラフィック管理を名前空間管理者に委任できます。
1. **ネットワークポリシー階層**: 拒否または許可に一致する管理者階層ポリシーがない場合や、パスアクションが一致した場合、次は名前空間範囲の ApplicationNetworkPolicy と従来の NetworkPolicy リソースが評価されます。これらは個々の名前空間内できめ細かく制御できるポリシーで、アプリケーションチームによって管理されます。名前空間範囲のポリシーでは、管理者ポリシーよりも厳しく制限を課すことができます。管理者ポリシーによる拒否の判断を上書きすることはできませんが、管理者ポリシーによって許可またはパスされたトラフィックをさらに制限できます。
1. **ベースライン階層管理ポリシー**: トラフィックに一致する管理者ポリシーや名前空間範囲のポリシーがない場合、ベースライン階層の ClusterNetworkPolicy が評価されます。これにより、デフォルトのセキュリティ体制を名前空間範囲のポリシーで上書きできるため、管理者が組織全体のデフォルトを設定する一方で、チームが必要に応じて柔軟にカスタマイズできます。ベースラインポリシーは、優先順位に従って (優先順位番号の最も小さいものから) 評価されます。
1. **デフォルト拒否 (一致するポリシーがない場合)**: この deny-by-default 動作により、明示的に認められた接続のみが許可されるため、強力なセキュリティ体制を維持できます。
### 最小特権の原則を適用する
+ **制限ポリシーから開始し、必要に応じて徐々にアクセス許可を追加する** - まずはクラスターレベルで deny-by-default ポリシーを実装し、次に正当な接続要件の検証に合わせて許可ルールを段階的に追加していきます。このアプローチにより、チームは外部接続ごとにその正当性を明示的に評価して、より安全で監査可能な環境を構築できるようになります。
+ **未使用のポリシールールを定期的に監査して削除する** - ネットワークポリシーは、アプリケーションの進化に伴い時間が経つにつれて増えていきます。そのために、古いルールが残ってアタックサーフェスが不必要に拡大する可能性があります。ポリシールールを定期的に見直すプロセスを実装して、不要になったものを特定して削除するようにすると、厳格で管理しやすいセキュリティ体制を維持できます。
+ **可能であれば、広範なパターンではなく特定のドメイン名を使用する** - `*.amazonaws.com` のようなワイルドカードパターンは便利ですが、同時に幅広いサービスへのアクセスも許可することになります。可能な限り、`s3.us-west-2.amazonaws.com` のような厳密なドメイン名を指定して、アプリケーションが必要とする特定のサービスにのみアクセスを制限して、ワークロードが侵害された場合に横展開されるリスクを軽減します。
### EKS での DNS ベースのポリシーを使用する
+ `ApplicationNetworkPolicy` を使用して定義した DNS ベースのルールは、EKS 自動モードで起動された EC2 インスタンスで動作するワークロードにのみ適用できます。混合モードクラスター (EKS 自動ワーカーノードと非 EKS 自動ワーカーノードの両方で構成) を実行している場合、DNS ベースのルールは EKS 自動モードのワーカーノード (EC2 マネージドインスタンス) でのみ有効です。
### DNS ポリシーを検証する
+ **ステージングクラスターを使用してテスト用に本番稼働のネットワークトポロジをミラーリングする** - ステージング環境では、ポリシーを正確にテストできるように、本番稼働のネットワークアーキテクチャ、外部依存関係、および接続パターンをレプリケートする必要があります。例えば、VPC 設定、DNS 解決動作、本番稼働のワークロードで必要になるのと同じ外部サービスへのアクセスを一致させます。
+ **重要なネットワークパスを自動的にテストする機能を実装する** - CI/CD パイプラインの一部として、必要不可欠な外部サービスへの接続を検証する自動テストを構築します。自動テストでは、正当なトラフィックフローは許可され、不正な接続はブロックされることを検証します。インフラストラクチャが進化しても、ネットワークポリシーにより、正しいセキュリティ体制が維持されていることを継続的に検証する必要があります。
+ **ポリシーが変更されたらアプリケーションの動作をモニタリングする** - 新規または変更後のネットワークポリシーを本番稼働にデプロイしたら、アプリケーションログ、エラー率、パフォーマンスメトリクスを注意深くモニタリングして、接続の問題があればすばやく特定できるようにします。明確なロールバック手順を確立して、予期しないアプリケーションの動作やサービスの中断が発生したら、ポリシーへの変更をすばやく元に戻せるようにします。
### Amazon Route 53 DNS ファイアウォールとのインタラクション
EKS 管理者ポリシーとネットワークポリシーは、トラフィックの開始時にポッドレベルで最初に評価されます。EKS ネットワークポリシーで特定のドメインへのエグレスを許可している場合、ポッドは Route 53 Resolver に到達する DNS クエリを実行します。この時点で、Route 53 DNS ファイアウォールルールが評価されます。DNS ファイアウォールがドメインクエリをブロックしている場合、EKS ネットワークポリシーで許可していたとしても、DNS 解決は失敗し、接続を確立できません。そのため、セキュリティレイヤーをいくつか作成して補完します。EKS DNS ベースのネットワークポリシーではアプリケーションに固有のアクセス要件とマルチテナントセキュリティ境界に応じてポッドレベルでエグレスを制御し、DNS ファイアウォールでは既知の悪意のあるドメインから VPC 全体を保護して組織全体のブロックリストを適用します。
# EKS Auto Mode のサブネットにタグを付ける
EKS Auto Mode の負荷分散機能を使用する場合は、VPC サブネットに AWS タグを追加する必要があります。
## 背景
これらのタグは、サブネットがクラスターに関連付けられているものと特定し、さらに重要な点として、サブネットがパブリックかプライベートかを識別します。
パブリックサブネットは、インターネットゲートウェイを介してインターネットに直接アクセスできます。ロードバランサーなど、パブリックにアクセスできるようにする必要があるリソースに使用されます。
プライベートサブネットには直接インターネットにアクセスできる機能がなく、アウトバウンドトラフィックに NAT ゲートウェイを使用します。プライベートサブネットは、パブリック IP を必要としない EKS ノードなどの内部リソースに使用されます。
NAT ゲートウェイとインターネットゲートウェイの詳細については、「Amazon Virtual Private Cloud (VPC) ユーザーガイド」の「[VPC を他のネットワークに接続する](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html)」を参照してください。
## 要件
現時点で、EKS Auto Mode で負荷分散に使用するサブネットには、次のいずれかのタグが必要です。
### パブリックサブネット
パブリックサブネットは、インターネット向けロードバランサーに使用されます。これらのサブネットには、次のタグが必要です。
| キー | 値 |
| --- | --- |
| `kubernetes.io/role/elb` | `1` または `` |
### プライベートサブネット
プライベートサブネットは、内部ロードバランサーに使用されます。これらのサブネットには、次のタグが必要です。
| キー | 値 |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1` または `` |
## 手順
開始する前に、パブリックサブネット (インターネットゲートウェイアクセスを使用) とプライベートサブネット (NAT ゲートウェイを使用) を特定します。VPC リソースを変更するには、アクセス許可が必要です。
### AWS マネジメントコンソール
1. Amazon VPC コンソールを開き、**[サブネット]** に移動します。
1. タグ付けするサブネットを選択します。
1. **[タグ]** タブを選択してから、**[タグを追加]** を選択します。
1. 適切なタグを追加します。
+ パブリックサブネットの場合: Key=`kubernetes.io/role/elb`
+ プライベートサブネットの場合: Key=`kubernetes.io/role/internal-elb`
1. **[値]** を `1` に設定するか、空白のままにします。
1. 保存し、残りのサブネットについても同じ操作を繰り返します。
### AWS CLI
パブリックサブネットの場合:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
プライベートサブネットの場合:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
`subnet-ID` を実際のサブネット ID に置き換えます。
# kubectl debug を使用して Kubernetes ノードの CIS コンプライアンスレポートを生成する
このトピックでは、`kubectl debug` コマンドを使用して Amazon EKS ノードの CIS (Center for Internet Security) コンプライアンスレポートを生成する方法について説明します。このコマンドを使用すると、Kubernetes ノードにデバッグコンテナを一時的に作成し、`apiclient` ツールを使用して CIS コンプライアンスチェックを実行できます。この `apiclient` ツールは、Bottlerocket OS (EKS Auto Mode ノードで使用する OS) に組み込まれています。
## 前提条件
開始する前に、以下を確認してください。
+ `kubectl` が設定された Amazon EKS クラスターへのアクセス (バージョンは v1.32.0 以上である必要があります。確認するには `kubectl version` と入力します)。
+ ノードをデバッグするための適切な IAM アクセス権限。
+ デバッグオペレーションが許可される有効なプロファイル (例: `sysadmin`)。
`kubectl` とデバッグプロファイルの併用方法については、Kubernetes ドキュメントの「[Debugging a Pod or Node while applying a profile](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles)」で詳しく確認できます。
## 手順
1. レポートを実行するノードの AWS インスタンス ID を決定します。クラスター内のノードを一覧表示するには、以下のコマンドを使用します。インスタンス ID は名前の列にあり、`i-` で始まります。
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. `` を、クエリするノードのインスタンス ID に置き換えて、次のコマンドを実行します。
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
このコマンドのコンポーネントは次のとおりです。
+ `kubectl debug node/` — 指定した EC2 インスタンス ID でデバッグセッションを作成します。
+ `-it` — TTY (コマンドラインシェル) を割り当てて、stdin を開いたままにし、インタラクティブに使用できるようにします。
+ `--profile=sysadmin` — 指定した `kubectl` プロファイル (適切なアクセス権限が付与されている) を使用します。
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023` — `amazonlinux:2023` を、デバッグ用のコンテナイメージに使用します。
+ `bash -c "…"` — bash シェルで次のコマンドを実行します。
+ `yum install -q -y util-linux-core` — 必要なユーティリティパッケージをサイレントインストールします。
+ `nsenter -t 1 -m` — `nsenter` を実行して、ホストプロセス (PID 1) の名前空間に入ります。
+ `apiclient report cis --level 1 --format text` — テキスト出力を使用して、レベル 1 で CIS コンプライアンスレポートを実行します。
1. レポートのテキスト出力を確認します。
## 出力の解釈
このコマンドにより、テキストベースのレポートを生成して、さまざまな CIS コントロールのコンプライアンスステータスを確認できます。以下のような情報が出力されます。
+ 個々の CIS コントロール ID
+ 各コントロールの説明
+ 各チェックの合格、失敗、スキップのステータス
+ コンプライアンス上の問題の詳細説明
Bottlerocket インスタンスで実行したレポートの出力例を次に示します。
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
ベンチマークの詳細については、Center for Internet Security (CIS) の「[Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)」を参照してください。
## 関連リソース
+ 「[Bottlerocket CIS Benchmark](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/)」(Bottlerocket OS ドキュメント)
+ 「[実行中のポッドのデバッグ](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/)」(Kubernetes ドキュメント)
+ 「[Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/)」(Center for Internet Security (CIS))
# EKS オートモードでカスタマーマネージド KMS キー使用した EBS ボリュームの暗号化を有効にする
カスタマーマネージド KMS キーを使用すると、EKS オートモードのインスタンスのエフェメラルルートボリュームを暗号化することができます。
Amazon EKS オートモードは、Kubernetes クラスターの暗号化された EBS ボリュームを管理するときに、サービスリンクロールを使用して他の AWS サービスにアクセス許可を委任します。このトピックでは、EKS オートモードの Amazon EBS 暗号化のカスタマーマネージドキーを指定するときに必要になる、キーポリシーの設定方法について解説します。
考慮事項:
+ EKS オートモードでは、デフォルトの AWS マネージドキーを使用してアカウントにある暗号化されたボリュームを保護する場合、追加の承認は不要です。
+ このトピックでは、EC2 インスタンスのルートボリュームである、エフェメラルボリュームを暗号化する方法について取り上げます。ワークロードに使用するデータボリュームの暗号化の方法については、「[ストレージクラスを作成する](create-storage-class.md)」を参照してください。
## 概要
以下の AWS KMS キーは、EKS オートモードでインスタンスを起動するときに、Amazon EBS ルートボリュームの暗号化に使用できます。
+ **AWS マネージドキー** – Amazon EBS が作成、所有、管理するアカウント内の暗号化キーです。これは、新しいアカウントのデフォルトの暗号化キーです。
+ **カスタマーマネージド型キー** – お客様が作成、所有、および管理するカスタム暗号化キー。
**注記**
KMS キーは対称である必要があります。Amazon EBS は非対称カスタマー管理キーをサポートしていません。
## ステップ 1: キーポリシーを設定する
KMS キーには、カスタマーマネージドキーで暗号化された Amazon EBS ボリュームを使用してインスタンスを起動することを EKS オートモードに許可する、キーポリシーが必要です。
キーポリシーは次の構造で設定します。
**注記**
このポリシーには EKS オートモードのアクセス許可しか含まれていません。他の ID でキーを使用したり許可を管理したりする必要がある場合、このキーポリシーに追加のアクセス許可が必要になる可能性があります。
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
`` を、現在お使いの AWS アカウント ID に置き換えます。
キーポリシーを設定する場合:
+ `ClusterServiceRole` には、暗号化のオペレーションに KMS キーを使用するために必要な、IAM アクセス許可が含まれている必要があります。
+ `kms:GrantIsForAWSResource` 条件によって、AWS サービスに対してのみ許可を作成することができます。
## ステップ 2: カスタマーマネージドキーを使用して NodeClass を設定する
キーポリシーを設定したら、EKS オートモード NodeClass 設定で KMS キーを参照します。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws:kms:::key/"
```
プレースホルダーの値を実際の値にそれぞれ置き換えます。
+ `` は現在の AWS リージョンに
+ `` はご自身の AWS アカウント ID に
+ `` はご自身の KMS キー ID に
KMS キーは以下のいずれかの形式を使用して指定することができます。
+ KMS キー ID: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ KMS キー ARN: ` arn:aws:kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ キーエイリアス名: `alias/eks-auto-mode-key`
+ キーエイリアス ARN: ` arn:aws:kms:us-west-2:111122223333:alias/eks-auto-mode-key`
kubectl を使用して NodeClass 設定を適用します。
```
kubectl apply -f nodeclass.yaml
```
## 関連リソース
+ [Amazon EKS のノードクラスを作成する](create-node-class.md)
+ 詳細については、「AWS Key Management Service デベロッパーガイド」を参照してください。
+ [キーポリシーにおける AWS サービスのアクセス許可](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [キーポリシーを変更する](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Grants in AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# EKS Auto Mode の組織コントロールを更新する
一部の組織コントロールは、EKS Auto Mode の正常な機能を妨げる場合があります。その場合、これらのコントロールを更新し、EKS Auto Mode がユーザーに代わって EC2 インスタンスを管理するために必要なアクセス許可を持てるようにする必要があります。
EKS Auto Mode には、EKS Auto Mode ノードをバックアップする EC2 インスタンスを起動するためのサービスロールが使用されます。サービスロールはユーザーの名義で作成された [IAM ロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)であり、サービスがユーザーに代わってアクションを実行するために引き受けます。[サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCP) はサービスロールで実行されるアクションに常に適用されます。SCP が自動モードのオペレーションを禁止できるようにします。最も一般的なケースは、SCP を使用して起動できる Amazon マシンイメージ (AMI) を制限する場合です。EKS Auto Mode を機能させるには、SCP を変更して EKS Auto Mode アカウントから AMI の起動を許可します。
[EC2 が許可された AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) 機能を使用し、他のアカウントで AMI の可視性を制限することもできます。この機能を使用する場合、対象リージョンに EKS Auto Mode AMI アカウントも含めるため、イメージ条件を拡張する必要があります。
## EKS Auto Mode AMI を除くすべての AMI をブロックする SCP の例
以下の SCP では、AMI が us-west-2 または us-east-1 の EKS Auto Mode AMI アカウントに属していない限り、`ec2:RunInstances` の呼び出しが防止されます。
**注記**
`ec2:Owner` コンテキストキーを使用**しない**ことが重要です。Amazon は EKS Auto Mode AMI アカウントを所有しており、このキーの値は常に `amazon` になります。`ec2:Owner` が `amazon` の場合に AMI の起動を許可する SCP を構築すると、EKS Auto Mode 用の AMI だけでなく、Amazon が所有する AMI の起動も許可されます。\$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## EKS Auto Mode AMI アカウント
リージョンによって異なる AWS アカウントは、EKS Auto Mode パブリック AMI をホストします。
| | |
| --- |--- |
| AWS リージョン | アカウント |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-east-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-southeast-6 | 905418310314 |
| ap-southeast-7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-central-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us–east–1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## パブリック IP アドレスの関連付け
`ec2:RunInstances` が呼び出されると、インスタンス起動の `AssociatePublicIpAddress` フィールドは、インスタンスが起動されるサブネットのタイプによって自動的に決定されます。SCP を使用すると、起動するサブネットのタイプに関係なく、この値を明示的に false に設定することができます。この場合、SCP の要件を満たすために NodeClass フィールド `spec.advancedNetworking.associatePublicIPAddress` を false に設定することもできます。
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# EKS 自動モードでキャパシティ予約へのワークロードのデプロイを制御する
[キャパシティ予約](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html)へのワークロードのデプロイを制御できます。EKS 自動モードは、EC2 On-Demand Capacity Reservations (ODCR) と EC2 Capacity Block for ML をサポートしています。
**ヒント**
デフォルトでは、EKS Auto Mode はオープンマッチングを通じてオープン ODCR に起動できますが、優先順位は付けられません。オープンマッチングによって起動されたインスタンスには、`reserved` ではなく `karpenter.sh/capacity-type: on-demand` というラベルが付けられます。ODCR の使用を優先し、インスタンスに `karpenter.sh/capacity-type: reserved` というラベルを付けるには、NodeClass 定義で `capacityReservationSelectorTerms` を設定します。Capacity Blocks for ML には、常に `capacityReservationSelectorTerms` が必要であり、自動的には使用されません。
## EC2 オンデマンドキャパシティ予約 (ODCR)
EC2 オンデマンドキャパシティ予約 (ODCR) を使用すると、任意の期間中に特定のアベイラビリティーゾーンで Amazon EC2 インスタンスのコンピューティングキャパシティを予約できます。EKS Auto Mode を使用するとき、Kubernetes ワークロードをこれらの予約されたインスタンスにデプロイするかどうかを制御し、事前購入された容量の使用率を最大化したり、重要なワークロードが保証されたリソースにアクセスできるようにしたりすることができます。
デフォルトでは、EKS Auto Mode は自動的にオープン ODCR として起動します。ただし、NodeClass で `capacityReservationSelectorTerms` を設定することで、ワークロードが使用する ODCR を明示的に制御できます。設定された ODCR を使用してプロビジョニングされたノードには `karpenter.sh/capacity-type: reserved` があり、オンデマンドおよびスポットよりも優先されます。この機能を有効にすると、EKS Auto Mode はオープン ODCR を自動的に使用しなくなります。NodeClass で明示的に選択する必要があり、クラスター全体のキャパシティ予約の使用状況を正確に制御できます。
**警告**
クラスター内の NodeClass で `capacityReservationSelectorTerms` を設定した場合、EKS Auto Mode はクラスター内の*すべて*の NodeClass に対してオープン ODCR を自動的に使用しなくなります。
### NodeClass の例
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
この NodeClass の例では、ODCR を選択するための 2 つのアプローチが示されています。1 番目の方法では、特定の ODCR が ID (`cr-56fac701cc1951b03`) で直接参照されます。2 番目の方法ではタグベースの選択を使用し、タグ `Name: "targeted-odcr"` で ODCR がターゲットされます。オプションとして、予約を所有する AWS アカウントでフィルタリングすることもできます。アカウント間シナリオや共有キャパシティ予約を使用する場合に特に便利です。
## EC2 Capacity Blocks for ML
Capacity Blocks for ML は、短期間の機械学習ワークロードをサポートするため、GPU ベースの高速コンピューティングインスタンスを将来の日付で予約します。キャパシティブロック内で実行されるインスタンスは、Amazon EC2 UltraClusters 内に自動的に互いに近く配置され、低レイテンシーでペタビットスケールのノンブロッキングネットワーキングを実現します。
サポートされているプラットフォームとインスタンスタイプの詳細については、「EC2 ユーザーガイド」の「[Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)」を参照してください。
前述の ODCR と同じく、EKS 自動モードの NodeClass を作成し、その中で Capacity Block for ML を使用できます。
次のサンプル定義では、3 つのリソースを作成しています。
1. キャパシティブロック予約を参照する NodeClass
1. NodeClass を使用し、テイントを適用する NodePool
1. テイントを許容し、GPU リソースをリクエストするポッド仕様
### NodeClass の例
この NodeClass は、特定の Capacity Block for ML をその予約 ID で参照します。この ID は、EC2 コンソールから取得できます。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
### NodePool の例
この NodePool は、`gpu` NodeClass を参照し、以下の重要な設定を指定します。
+ `karpenter.sh/capacity-type: reserved` を設定してリザーブドキャパシティ**のみ**を使用します。
+ ML ワークロードに適した特定の GPU インスタンスファミリーをリクエストします。
+ `nvidia.com/gpu` テイントを適用して、これらのノードで GPU ワークロードのみがスケジュールされるようにします。
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
### ポッドの例
この例に示したポッドは、キャパシティブロックノードで動作するようにワークロードを設定する方法を示しています。
+ **nodeSelector** を使用して、特定の GPU タイプ (この例では H200 GPU) をターゲットとしています。
+ NodePool で適用される `nvidia.com/gpu` テイントの**許容値**が含まれています。
+ `nvidia.com/gpu` リソースタイプを使用して明示的に **GPU リソースをリクエスト**します。
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
詳細については、Kubernetes ドキュメントの「[ポッド](https://kubernetes.io/docs/concepts/workloads/pods/)」を参照してください。
### 関連リソース
+ 「Amazon EC2 ユーザーガイド」の「[Capacity Blocks for ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html)」
+ 「Amazon EC2 ユーザーガイド」の「[キャパシティブロックの検索と購入](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html)」
+ [Amazon EKS で AI/ML ワークロードのコンピューティングリソースを管理する](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ 「EKS ベストプラクティスガイド」の「[GPU リソースの最適化とコスト管理](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management)」
# Local Zone に EKS 自動モードノードをデプロイする
EKS 自動モードでは、自動ノードプロビジョニングでクラスター管理をシンプルにできます。AWSLocal Zone は、エンドユーザーに地理的に近い場所まで AWS インフラストラクチャを拡張して、レイテンシーの影響を受けやすいアプリケーションのレイテンシーを軽減します。このガイドでは、EKS 自動モードノードを AWS Local Zone にデプロイするプロセスを見ていきます。ガイドに従うと、特定の地理的エリアのユーザーを対象に、コンテナ化されたアプリケーションを低レイテンシーで実行できます。
また、Kubernetes テイントおよび許容を使用して、特定のワークロードのみが Local Zone ノードで実行されるようにする方法も示します。これにより、コストを抑え、リソースの使用を最適化できます。
## 前提条件
EKS 自動モードノードを Local Zone にデプロイする前に、次の前提条件が満たされていることを確認してください。
+ [EKS 自動モードのクラスターが既に存在している](create-auto.md)
+ [AWS アカウントで Local Zone にオプトインされている](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## ステップ 1: Local Zone サブネットを作成する
EKS 自動モードノードを Local Zone にデプロイする最初のステップは、その Local Zone にサブネットを作成することです。このサブネットは、ノードのネットワークインフラストラクチャとなるもので、VPC の他の要素と通信できるようになります。「[Local Zone サブネットを作成する](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet)」の手順 (「AWS Local Zone ユーザーガイド」) に従って、選択した Local Zone にサブネットを作成します。
**ヒント**
Local Zone サブネットの名前をメモします。
## ステップ 2: Local Zone サブネット用に NodeClass を作成する
Local Zone サブネットを作成したら、このサブネットを参照する NodeClass を定義する必要があります。NodeClass は、ノードのインフラストラクチャ属性を指定する Kubernetes カスタムリソースで、例えば使用するサブネット、セキュリティグループ、ストレージ設定を指定します。以下の例では、Local Zone サブネットをその名前に基づいてターゲットとする NodeClass を「local-zone」という名前で作成しています。また、サブネット ID を使用することもできます。Local Zone サブネットをターゲットとするように、この設定を調整する必要があります。
詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## ステップ 3: NodeClass とテイントで NodePool を作成する
NodeClass を設定したら、この NodeClass を使用する NodePool を作成する必要があります。NodePool では、インスタンスタイプなど、ノードのコンピューティング特性を定義します。NodePool は、インスタンスの起動場所を決定する際に NodeClass をリファレンスとして使用します。
以下の例では、「local-zone」NodeClass を参照する NodePool を作成しています。また、ノードにテイントを追加して、これらの Local Zone ノードでは許容範囲が一致するポッドのみをスケジュールできるようにしています。これは、Local Zone ノードにとって特に重要です。このノードは、通常コストが高く、レイテンシーを短縮すると特にメリットが得られるワークロードでのみ使用する必要があるからです。
詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
key が `aws.amazon.com/local-zone` で effect が `NoSchedule` のテイントにより、許容範囲が一致しないポッドがこれらのノードでスケジュールされることはありません。これにより、通常のワークロードが誤って Local Zone で実行されて、想定外のコストが発生するのを防ぐことができます。
## ステップ 4: 許容範囲とノードアフィニティでワークロードをデプロイする
Local Zone ノードへのワークロードの配置を最適に制御するには、テイント/許容範囲とノードアフィニティの両方を一緒に使用します。このように組み合わせたアプローチには以下のメリットがあります。
1. **コストの抑制**: テイントにより、許容範囲が明示的に指定されたポッドのみが、コストが高くつく可能性がある Local Zone リソースを使用できるようになります。
1. **保証された配置**: ノードアフィニティにより、レイテンシーの影響を受けやすいアプリケーションは、通常のクラスターノードではなく、Local Zone でのみ実行されます。
以下に、Local Zone ノードでのみ実行されるように設定された Deployment の例を示します。
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
この Deployment には、重要なスケジューリング設定が 2 つあります。
1. **許容範囲**により、テイントが `aws.amazon.com/local-zone` のノードにポッドをスケジュールできます。
1. **ノードアフィニティ**要件により、こうしたポッドはラベルが `node-type: local-zone` のノードでのみ実行されます。
これにより、レイテンシーの影響を受けやすいアプリケーションは Local Zone ノードでのみ実行され、通常のアプリケーションは明示的に設定されていない限り Local Zone リソースを消費しません。
## ステップ 5: AWS コンソールで検証する
NodeClass、NodePool、Deployment をセットアップしたら、ノードが想定どおりに Local Zone にプロビジョニングされていることと、ワークロードがノードで実行されていることを確認する必要があります。AWS マネジメントコンソールを使用すると、EC2 インスタンスが適切な Local Zone サブネットで起動されていることを確認できます。
また、`kubectl get nodes -o wide` を使用すると、Kubernetes ノードリストをチェックして、ノードが適切なラベルとテイントでクラスターに参加していることを確認できます。
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
さらに、ワークロードポッドが Local Zone ノードにスケジュールされていることを確認することもできます。
```
kubectl get pods -o wide
```
このアプローチにより、指定された範囲で Local Zone テイントを許容するワークロードのみがこれらのノードでスケジュールされるため、コストを抑え、Local Zone リソースを最も効率的に使用できます。
# ノードの高度なセキュリティ設定を構成する
このトピックでは、ノードクラスの `advancedSecurity` 仕様を使用して Amazon EKS Auto Mode ノードの高度なセキュリティ設定を構成する方法について説明します。
## 前提条件
開始する前に、以下を確認してください。
+ Amazon EKS Auto Mode クラスター。詳細については、「[Amazon EKS 自動モードl クラスターを作成する](create-auto.md)」を参照してください。
+ `kubectl` がインストールされ、設定済みであること。詳細については、「[Amazon EKS を使用するようにセットアップする](setting-up.md)」を参照してください。
+ ノードクラス設定について。詳細については、「[Amazon EKS のノードクラスを作成する](create-node-class.md)」を参照してください。
## 高度なセキュリティ設定を構成する
ノードの高度なセキュリティ設定を構成するには、ノードクラス仕様の `advancedSecurity` フィールドを設定します。
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
この設定を適用します。
```
kubectl apply -f nodeclass.yaml
```
ノードプール設定でこのノードクラスを参照します。詳細については、「[EKS 自動モードl 用のノードプールを作成する](create-node-pool.md)」を参照してください。
## フィールドの説明
+ `fips` (ブール値、オプション): `true` に設定すると、FIPS 140-2 検証済み暗号化モジュールを含む AMI を使用してノードをプロビジョニングします。この設定では、FIPS 準拠の AMI が選択されます。お客様はコンプライアンス要件を管理する責任があります。詳細については、「[AWS FIPS Compliance](https://aws.amazon.com/compliance/fips/)」を参照してください。デフォルト: `false`。
+ `kernelLockdown` (文字列、オプション): カーネルロックダウンセキュリティモジュールモードを制御します。使用できる値:
+ `integrity`: カーネルメモリを上書きしたり、カーネルコードを変更するメソッドをブロックします。署名なしカーネルモジュールがロードされないようにします。
+ `none`: カーネルロックダウン保護を無効にします。
詳細については、「[Linux kernel lockdown](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html)」ドキュメントを参照してください。
## 考慮事項
+ FIPS 準拠の AMI は、AWS 米国東部/西部、AWS GovCloud (米国)、AWS カナダ (中部/西部) の各リージョンで利用できます。詳細については、「[AWS FIPS Compliance](https://aws.amazon.com/compliance/fips/)」を参照してください。
+ `kernelLockdown: "integrity"` を使用する場合は、ワークロードが署名なしカーネルモジュールのロードやカーネルメモリの変更を必要としないことを確認してください。
## 関連リソース
+ [Amazon EKS のノードクラスを作成する](create-node-class.md) – 完全なノードクラス設定ガイド
+ [EKS 自動モードl 用のノードプールを作成する](create-node-pool.md) – ノードプールの設定