Amazon EKS のノード可用性に関連するポッドスケジューリングの問題をトラブルシューティングする方法を教えてください。

所要時間6分

Amazon Elastic Kubernetes Service (Amazon EKS) のワーカーポッドをスケジュールしようとすると、ノードの可用性の問題またはエラーが発生します。ポッドが [保留] 状態のままになっています。

解決策

注: AWS コマンドラインインターフェイス (AWS CLI) コマンドの実行中にエラーが発生した場合は、「AWS CLI のエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

メモリ不足または CPU エラー

ワーカーノードで使用可能な CPU またはメモリが不足してポッドが [実行中] 状態に達しない場合、次のエラーメッセージが表示されます。

"Warning FailedScheduling 16m default-scheduler 0/2 nodes are available: 1 Too many pods, 2 Insufficient cpu, 2 Insufficient memory. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod"
"Warning FailedScheduling 11m default-scheduler 0/2 nodes are available: 1 Insufficient cpu, 1 Insufficient memory, 1 node(s) were unschedulable. preemption: 0/2 nodes are available: 1 No preemption victims found for incoming pod, 1 Preemption is not helpful for scheduling"

メモリ不足または CPU 不足の問題を解決するには、次の手順を実行します。

ワーカーノードで Session Manager (AWS Systems Manager の機能) SSH セッションを開始します。
次の kubectl top node コマンドを実行して、各ノードの現在の CPU とメモリの使用率を取得します。
```
kubectl top node
```
注: 前述のコマンドの詳細については、Kubernetes のウェブサイトの「kubectl top node」を参照してください。

次の kubectl describe コマンドを実行して、ノードで利用可能なリソースの合計数に関する情報を取得します。

kubectl describe node your_node_name

注: your_node_name をノード名に置き換えてください。前述のコマンドの詳細については、Kubernetes のウェブサイトの「kubectl describe」を参照してください。
次の出力例は、ポッドに割り当てることができるノード上のリソースを示しています。

Allocatable:
  cpu: 1930m
  ephemeral-storage: 18242267924
  hugepages-1Gi: 0
  hugepages-2Mi: 0
  memory: 3388304Ki
  pods: 17

ワーカーノードが使用する Amazon Elastic Compute Cloud (Amazon EC2) のインスタンスクラスを特定します。次に、インスタンスで使用可能なデフォルトの CPU とメモリを確認します。
デプロイで定義したリソース制限とリクエストを確認します。詳細については、Kubernetes のウェブサイトの「Deployments」(デプロイ) を参照してください。制限を設定する場合は、その制限がワークロード要件を満たしていることを確認してください。次の出力例は、リソース制限とリクエストを示しています。
```
Limits:
  memory: 170Mi
Requests:
  cpu: 100m
  memory: 70Mi
```
注: Limits と Requests に適切な値を設定することで、ワーカーノードの容量をスケールアップする必要があるかどうかを判断するのに役立ちます。詳細については、Kubernetes のウェブサイトの「コンテナのリソース管理」を参照してください。

ネットワークインターフェイスのクォータの問題

ノードで Elastic Network Interface のクォータに達すると、次のエラーメッセージが表示されます。

"Warning FailedScheduling 117s default-scheduler 0/2 nodes are available: 1 Too many pods. preemption: 0/2 nodes are available: 2 No preemption victims found for incoming pod"

注: Kubernetes クラスター内の各ポッドには独自の IP アドレスがあります。インスタンスタイプがサポートする IP アドレスの数は、ワーカーノードで実行中のポッドの最大数を決定するのに役立ちます。ワーカーノードで実行できるポッドの最大数に達すると、ポッドが [保留] 状態で停止する可能性があります。

各ノードで実行できるポッドの最大数を確認するには、次の describe-instance-types コマンドを実行します。

aws ec2 describe-instance-types --filters "Name=instance-type,Values=c5.*" --query "InstanceTypes[].{ Type: InstanceType, MaxENI: NetworkInfo.MaximumNetworkInterfaces, IPv4addr: NetworkInfo.Ipv4AddressesPerInterface}" --output table

コマンドの出力には、各インスタンスタイプのネットワークインターフェイスの最大数と、インターフェイスごとの IPv4 アドレスに関する情報が表示されます。上記のコマンドの出力では、最初のネットワークインターフェイス (eth0) が出力に含まれていないため、最大ポッド数より 1 つ少ないポッド数が表示されます。

詳細については、「Amazon EKS recommended maximum Pods for each Amazon EC2 instance type」(Amazon EC2 インスタンスタイプごとの Amazon EKS 推奨最大ポッド数) を参照してください。また、「ネットワークインターフェイスあたりの IP アドレスの最大数」も参照してください。

インスタンスがサポートできるポッドの最大数については、GitHub のウェブサイトの「amazon-vpc-cni-k8s」を参照してください。

現在のワーカーノードインスタンスで使用可能な IP アドレスが十分でない場合は、次の操作を行います。

インスタンスクラスをより多くのポッドをサポートするクラスにスケールアップします。スケールアップする前に、ネットワークインターフェイスのクォータを確認するのがベストプラクティスです。
Karpenter と Cluster Autoscaler を使用してノード数をスケールアウトします。

テイントエラーまたは許容エラー

テイントまたは許容範囲に問題があると、次のエラーメッセージが表示されます。

"Warning FailedScheduling 12s default-scheduler 0/2 nodes are available: 2 node(s) had untolerated taint {NodeType: MemoryOptimized}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling"

スケジュールするポッドには、特定のテイントを持つノードが必要です (NodeType: MemoryOptimized)。ただし、クラスターでノードを使用できないため、スケジューリングは失敗します。

テイントまたは許容範囲の問題を解決するには、次の手順を実行してください。

次の kubectl describe コマンドを実行して、ノードに設定したテイントを取得します。
```
kubectl describe node your_node_name
```
注: your_node_name をノード名に置き換えてください。ポッドの許容範囲が一致する場合にのみ、ノードにポッドをスケジュールできます。
次の kubectl describe コマンドを実行して、ポッドの許容範囲を取得します。
```
kubectl describe pod your_pod_name -n your_namespace
```
注: your_pod_name をポッド名に、your_namespace を名前空間に置き換えてください。

アフィニティエラー

ノードアフィニティに問題があると、次のエラーメッセージが表示されます。

"Warning FailedScheduling 13s default-scheduler 0/2 nodes are available: 2 node(s) didn't match Pod's node affinity/selector. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling"

アフィニティに関する問題を解決するには、次の手順を実行します。

requiredDuringSchedulingIgnoredDuringExecution ではなく preferredDuringSchedulingIgnoredDuringExecution を使用するように、ポッドのノードアフィニティ設定を更新します。

注: ポッドをスケジュールするには、requiredDuringSchedulingIgnoredDuringExecution を使用する必要があります。Kubernetes スケジューラは、アフィニティルールに準拠するノードでのみポッドをスケジュールします。
Kubernetes スケジューラがポッドをスケジュールするノードを見つけることができるように、一致するアフィニティを持つノードをクラスターに追加します。

デプロイからノードセレクター条件を削除するか、デプロイの条件を満たす値にノードグループを更新します。要件と Kubernetes クラスター上のノードの可用性に基づいて、適切なオプションを選択してください。

次の出力例は、あるデプロイのノードセレクター構成を示しています。

affinity:
  nodeAffinity:
     requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
            - key: instance-az
              operator: In
              values:
               - az1
              - az2

次の kubectl describe コマンドを実行して、ノードの詳細を取得します。

kubectl describe node your_node_name

注: your_node_name をノード名に置き換えてください。

次の例は、ノードの詳細を示しています。

Name: ip-10-1-1-172.ap-south-1.compute.internal
Roles: <none>
Labels: beta.kubernetes.io/arch=amd64
             beta.kubernetes.io/instance-type=t3.medium
             beta.kubernetes.io/os=linux
             instance-az=az1

注: Kubernetes がポッドをノードに配置できるように、デプロイで定義したキー値がノード上にある必要があります。

ポッドのセキュリティグループエラー

ポッドのセキュリティグループに問題があると、次のエラーメッセージが表示されます。

"Warning FailedScheduling 3s default-scheduler 0/3 nodes are available: 1 Insufficient vpc.amazonaws.com/pod-eni, 2 node(s) had untolerated taint {eks.amazonaws.com/compute-type: fargate}. preemption: 0/3 nodes are available: 1 No preemption victims found for incoming Pod, 2 Preemption is not helpful for scheduling"

注: Amazon EKS でポッドにセキュリティグループを使用すると、VPC リソースコントローラーはポッドごとにブランチネットワークインターフェイスを作成します。また、VPC リソースコントローラーはワーカーノードにトランクネットワークインターフェイスを作成し、ブランチネットワークインターフェイスを管理します。

重要: ポッドのセキュリティグループを使用するには、C5、M5、R5、T3 ファミリーなどの Nitro インスタンスタイプでワーカーノードを起動する必要があります。Nitro インスタンスタイプは、ポッドのブランチネットワークインターフェイスに対応するために必要なネットワークインターフェイス機能をサポートします。

ポッドのセキュリティグループの問題を解決するには、次の手順を実行します。

次の kubectl describe コマンドを実行して、ワーカーノードインスタンスがトランクインターフェイスをサポートしていることを確認します。
```
kubectl describe node your_node_name
```
注: your_node_name をノード名に置き換えてください。

前のコマンドの出力にあるノードの説明で、VPC リソースコントローラーからのイベントを確認します。
次の出力は、互換性のないインスタンスの例を示しています。

Events:
  Type     Reason                   Age                    From                             Message
  ----     ------                   ----                   ----                             -------
  Normal   RegisteredNode           22m                    node-controller                  Node ip-192-168-59-29.us-east-2.compute.internal event: Registered Node ip-192-168-59-29.us-east-2.compute.internal in Controller
  Normal   ControllerVersionNotice  21m                    vpc-resource-controller          The node is managed by VPC resource controller version v1.4.9
  Normal   NodeReady                21m                    kubelet                          Node ip-192-168-59-29.us-east-2.compute.internal status is now: NodeReady
  Warning  Unsupported              13m (x16 over 21m)     vpc-resource-controller          The instance type t3.small is not supported for trunk interface (Security Group for Pods)

Fargate のポッドサポートエラー

AWS Fargate がポッドをサポートしていない場合、次のエラーメッセージが表示されます。

"Warning FailedScheduling <unknown> fargate-scheduler Pod not supported on Fargate: volumes not supported: mysql-db not supported because: PVC mysql-db not bound"

Fargate で実行され、Amazon Elastic File System (Amazon EFS) のボリュームを使用するポッドには、通常のポッドと同じ要件があります。必要な PersistentVolume リソースと PersistentVolumeClaim リソースがクラスターにない場合、Fargate はポッドをスケジュールしません。

この問題を解決するには、次の手順を実行します。

必要な PersistentVolume リソースと PersistentVolumeClaim リソースを作成して正しく設定します。詳細については、Kubernetes のウェブサイトの「Configure a Pod to use a PersistentVolume for storage」(ストレージに PersistentVolume を使用するようにポッドを設定する) を参照してください。
ボリュームがポッドにバインドされているときに、PersistentVolume リソースと PersistentVolumeClaim リソースに問題がないかどうかを確認します。例えば、EFS ファイルシステム、アクセス許可、またはその他の設定の問題がある可能性があります。

Fargate のボリュームタイプのサポートエラー

ポッドにサポートされていないボリュームタイプの定義が含まれていると、次のエラーメッセージが表示されます。

"Warning FailedScheduling <unknown> fargate-scheduler Pod not supported on Fargate: volumes not supported: admin-panel is of an unsupported volume Type"

重要: Amazon Elastic Block Store (Amazon EBS) のボリュームを Fargate ポッドにマウントすることはできません。

サポートされていないボリュームタイプの問題を解決するには、次の操作を行います。

ポッド定義で EBS ボリュームやその他のサポートされていないボリュームタイプではなく、EFS ボリュームが指定されていることを確認します。
PersistentVolume リソースと PersistentVolumeClaim リソースが正しく設定されていること、および EFS ファイルシステムを参照していることを確認します。
ボリュームがポッドにアタッチされない原因となる可能性のある EFS ファイルシステム、アクセス許可、または設定の問題がないか確認します。

Fargate のセキュリティコンテキストエラー

セキュリティコンテキストが無効な場合、次のエラーメッセージが表示されます。

"Warning FailedScheduling 109s fargate-scheduler Pod not supported on Fargate: invalid SecurityContext fields: Privileged"

セキュリティコンテキストの問題を解決するには、Fargate ポッドが以下の要件を満たしていることを確認してください。

ポッド定義では、特権コンテナセキュリティコンテキストを指定できません。Fargate は特権コンテナを受け入れません。
ポッド定義は、ホストのルートファイルシステム (/) をコンテナにマウントできません。Fargate はコンテナをホストのルートファイルシステムから分離します。

Fargate のスケジューラが正しくないエラー

Fargate プロファイルまたはカスタムスケジューラで Amazon EKS を使用している場合、ポッドを管理するための適切な Kubernetes スケジューラがない可能性があります。

スケジューラの問題を解決するには、次の手順を実行します。

ポッドのイベントを確認します。
次の例は、テイントが Fargate コンピューティングタイプに関連付けられているため、デフォルトのスケジューラがポッドのノードを見つけられないことを示しています。

Events:
Type     Reason            Age        From               Message
----     ------            ----       ----               -------
Warning  FailedScheduling  109s       default-scheduler  0/2 nodes are available: 2 node(s) had untolerated taint {eks.amazonaws.com/compute-type: fargate}. preemption: 0/2 nodes are available: 2 Preemption is not helpful for scheduling..

注: fargate-scheduler は Fargate ポッドをスケジュールする必要があります。

次の kubectl get mutatingwebhookconfigurations コマンドを実行して、クラスターに Fargate ウェブフックがインストールされていることを確認します。

kubectl get mutatingwebhookconfigurations 0500-amazon-eks-fargate-mutation.amazonaws.com

出力にウェブフック設定が表示されていて、fargate-scheduler がポッドを取得できない場合は、競合する可能性のある他のカスタムミューテートウェブフック設定を確認してください。例えば、Fargate はウェブフックをアルファベット順に処理するため、ウェブフックが競合していると、問題が発生する可能性があります。

ポート競合エラー

Kubernetes スケジューラがポッドをスケジュールしているホストマシンでポートの競合が発生すると、次のエラーメッセージが表示されます。

"Warning FailedScheduling 10s default-scheduler 0/2 nodes are available: 1 node(s) didn't have free ports for requested pod ports.1 node(s) didn't match the requested hostname"

このエラーは、同じ hostPort 値で複数のポッドを設定したか、ホストマシン上の別のプロセスがすでにポートを実行しているために発生します。

hostNetwork: true でポッドを設定すると、ポッド内で実行されているコンテナはホストマシンのネットワークインターフェイスに直接アクセスできます。その結果、コンテナポートは対応するホストポートで外部ネットワークに直接公開されます。

ポートの競合の問題を解決するには、次の手順を実行します。

次の kubectl describe コマンドを実行して、ポート構成を確認します。

kubectl describe deploy nginx-deployment

次の出力例は、ポート情報がどこにあるかを示しています。

    spec:
      hostNetwork: true
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
          hostPort: 80

ホストネットワークまたはホストポートを変更します。例えば、hostNetwork をデフォルト値の false に設定して、仮想ネットワークインターフェイスをポッドに割り当てることができます。ホストマシンでまだ使用されていない別のホストポートを使用するようにポッド構成を更新することもできます。カーネルがポッドにランダムなホストポートを自動的に割り当てるようにするには、次の例のように hostPort を 0 に設定します。
```
  Containers:
   nginx:
    Image:        nginx:latest
    Port:         80/TCP
    Host Port:    0/TCP
```
別のホストでポッドをスケジュールします。ポートの競合がポッドをスケジュールしたいホストマシンに固有のものである場合は、別のノードでポッドをスケジュールします。ノードは Kubernetes クラスター内にある必要があります。アフィニティロジックを使用することもできます。詳細については、「Place Kubernetes Pods on Amazon EKS by using node affinity, taints, and tolerations」(ノードアフィニティ、テイント、および許容範囲を使用して Amazon EKS に Kubernetes ポッドを配置する) を参照してください。

競合するノードアフィニティエラー

ノードアフィニティルールが競合していると、次のエラーメッセージが表示されます。

"Warning FailedScheduling 57s (x3 over 3m3s) default-scheduler 0/15 nodes are available: 1 node(s) were unschedulable, 14 node(s) had volume node affinity conflict"

このエラーは、ノードアフィニティルールの競合により、使用可能なノードでポッドのボリューム要件が満たされない場合に発生します。

競合するノードアフィニティの問題を解決するには、次の手順を実行します。

ポッドとボリュームの定義で競合するノードアフィニティルールを特定します。例えば、ポッドに node-type=high-storage ラベルを必要とするノードアフィニティルールがあっても、ボリュームには node-type=ssd-storage ラベルが必要な場合があります。

ルールの競合を解決するには、ポッドまたはボリュームのノードアフィニティルールを更新します。例えば、次の例のように、ポッドのノードアフィニティルールをボリュームの要件に合わせて更新します。

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: node-type
          operator: In
          values:
          - ssd-storage

ノードラベルがアフィニティルールと一致していることを確認します。次に、クラスター内の使用可能なノードに新しい要件を満たす正しいラベルが付いていることを確認します。ノードとそのラベルを一覧表示するには、次の kubectl get nodes コマンドを実行します。
```
kubectl get nodes --show-labels
```
注: 必要な node-type=ssd-storage ラベルが付いた使用可能なノードがあることを確認してください。
ノードグループを変更するか、新しいノードグループを追加します。ノードグループを使用していて、ノードに必要なラベルがない場合は、既存のノードグループを更新してください。または、適切なラベルとインスタンスタイプを使用して新しいノードグループを作成します。

使用可能なボリュームゾーンがないエラー

クラスターにポッドをデプロイしようとしたときに、使用可能なボリュームゾーンがないと、次のエラーメッセージが表示されます。

"Warning FailedScheduling 60s (x5 over 60s) default-scheduler Pod has unbound PersistentVolumeClaims (repeated 2 times)"
"Warning FailedScheduling 2s (x16 over 59s) default-scheduler 0/2 nodes are available: 2 node(s) had no available volume zone"

使用可能なボリュームゾーンとポッドのボリュームゾーンの制約が一致しないため、ポッドのボリューム要件が満たされていません。

ボリュームゾーンの問題を解決するには、次の手順を実行します。

ポッドとボリュームの定義を確認して、ボリュームゾーンの問題の原因となっている特定のボリュームゾーンの制約を特定します。例えば、ワーカーノードを実行していないアベイラビリティゾーンを使用するようにポッドまたはボリュームを設定しているかどうかを確認します。

次の kubectl get pv コマンドを実行して、クラスターで使用できるボリュームゾーンを確認します。

kubectl get pv --all-namespaces -o jsonpath='{range .items[*]}{.spec.awsElasticBlockStore.availabilityZone}{"\n"}{end}' | sort | uniq

注: 出力リストに、ポッドまたはボリュームに必要なボリュームゾーンが含まれていることを確認してください。

ボリュームゾーンの制約を更新します。必要なボリュームゾーンが使用できない場合は、ポッドまたはボリューム構成を更新してください。この構成では、ボリュームの作成をワーカーノードが実行されているアベイラビリティゾーンのみに制限する必要があります。
ノードグループが複数のアベイラビリティゾーンにまたがっていることを確認します。ノードグループが複数のゾーンにまたがっていない場合は、必要なボリュームゾーンを含む新しいノードグループを作成します。

トピック: Containers
タグ: Amazon Elastic Kubernetes Service
言語: 日本語

AWS公式更新しました 1年前

コメントはありません