**このページの改善にご協力ください** 

このユーザーガイドに貢献するには、すべてのページの右側のペインにある「**GitHub でこのページを編集する**」リンクを選択してください。

# Local Zone に EKS 自動モードノードをデプロイする
<a name="auto-local-zone"></a>

EKS 自動モードでは、自動ノードプロビジョニングでクラスター管理をシンプルにできます。AWSLocal Zone は、エンドユーザーに地理的に近い場所まで AWS インフラストラクチャを拡張して、レイテンシーの影響を受けやすいアプリケーションのレイテンシーを軽減します。このガイドでは、EKS 自動モードノードを AWS Local Zone にデプロイするプロセスを見ていきます。ガイドに従うと、特定の地理的エリアのユーザーを対象に、コンテナ化されたアプリケーションを低レイテンシーで実行できます。

また、Kubernetes テイントおよび許容を使用して、特定のワークロードのみが Local Zone ノードで実行されるようにする方法も示します。これにより、コストを抑え、リソースの使用を最適化できます。

## 前提条件
<a name="_prerequisites"></a>

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 サブネットを作成する
<a name="_step_1_create_local_zone_subnet"></a>

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 を作成する
<a name="_step_2_create_nodeclass_for_local_zone_subnet"></a>

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: <local-subnet-id>
```

## ステップ 3: NodeClass とテイントで NodePool を作成する
<a name="_step_3_create_nodepool_with_nodeclass_and_taint"></a>

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: 許容範囲とノードアフィニティでワークロードをデプロイする
<a name="_step_4_deploy_workloads_with_toleration_and_node_affinity"></a>

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 コンソールで検証する
<a name="step_5_verify_with_shared_aws_console"></a>

NodeClass、NodePool、Deployment をセットアップしたら、ノードが想定どおりに Local Zone にプロビジョニングされていることと、ワークロードがノードで実行されていることを確認する必要があります。AWS マネジメントコンソールを使用すると、EC2 インスタンスが適切な Local Zone サブネットで起動されていることを確認できます。

また、`kubectl get nodes -o wide` を使用すると、Kubernetes ノードリストをチェックして、ノードが適切なラベルとテイントでクラスターに参加していることを確認できます。

```
kubectl get nodes -o wide
kubectl describe node <node-name> | grep -A 5 Taints
```

さらに、ワークロードポッドが Local Zone ノードにスケジュールされていることを確認することもできます。

```
kubectl get pods -o wide
```

このアプローチにより、指定された範囲で Local Zone テイントを許容するワークロードのみがこれらのノードでスケジュールされるため、コストを抑え、Local Zone リソースを最も効率的に使用できます。