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

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

Local Zone に EKS 自動モードノードをデプロイする

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

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

前提条件

EKS 自動モードノードを Local Zone にデプロイする前に、次の前提条件が満たされていることを確認してください。

ステップ 1: Local Zone サブネットを作成する

EKS 自動モードノードを Local Zone にデプロイする最初のステップは、その Local Zone にサブネットを作成することです。このサブネットは、ノードのネットワークインフラストラクチャとなるもので、VPC の他の要素と通信できるようになります。「Local Zone サブネットを作成する」の手順 (「AWS Local Zone ユーザーガイド」) に従って、選択した Local Zone にサブネットを作成します。

ステップ 2: Local Zone サブネット用に NodeClass を作成する

Local Zone サブネットを作成したら、このサブネットを参照する NodeClass を定義する必要があります。NodeClass は、ノードのインフラストラクチャ属性を指定する Kubernetes カスタムリソースで、例えば使用するサブネット、セキュリティグループ、ストレージ設定を指定します。以下の例では、Local Zone サブネットをその名前に基づいてターゲットとする NodeClass を「local-zone」という名前で作成しています。また、サブネット ID を使用することもできます。Local Zone サブネットをターゲットとするように、この設定を調整する必要があります。

詳細については、「Amazon EKS のノードクラスを作成する」を参照してください。

apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: local-zone
spec:
  subnetSelectorTerms:
    - id: <local-subnet-id>

ステップ 3: NodeClass とテイントで NodePool を作成する

NodeClass を設定したら、この NodeClass を使用する NodePool を作成する必要があります。NodePool では、インスタンスタイプなど、ノードのコンピューティング特性を定義します。NodePool は、インスタンスの起動場所を決定する際に NodeClass をリファレンスとして使用します。

以下の例では、「local-zone」NodeClass を参照する NodePool を作成しています。また、ノードにテイントを追加して、これらの Local Zone ノードでは許容範囲が一致するポッドのみをスケジュールできるようにしています。これは、Local Zone ノードにとって特に重要です。このノードは、通常コストが高く、レイテンシーを短縮すると特にメリットが得られるワークロードでのみ使用する必要があるからです。

詳細については、「EKS 自動モードl 用のノードプールを作成する」を参照してください。

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 ノードへのワークロードの配置を最適に制御するには、テイント/許容範囲とノードアフィニティの両方を一緒に使用します。このように組み合わせたアプローチには以下のメリットがあります。

以下に、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 つあります。

これにより、レイテンシーの影響を受けやすいアプリケーションは 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 <node-name> | grep -A 5 Taints

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

kubectl get pods -o wide

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