Amazon EKS ポッドが「failed to create pod sandbox」(ポッドサンドボックスを作成できませんでした) というエラーで [ContainerCreating] 状態でスタックするのはなぜですか?
Amazon Elastic Kubernetes Service (Amazon EKS) ポッドが [ContainerCreating] 状態でスタックし、「failed to create pod sandbox」(ポッドサンドボックスを作成できませんでした) というエラーが表示されました。
解決方法
Amazon EKS ポッドは、いくつかの理由により、ネットワーク接続エラーで [ContainerCreating] 状態でスタックすることがあります。表示されたエラーメッセージに基づいて、次のトラブルシューティングのステップを実行します。
デーモンからのエラーレスポンス: failed to start shim: fork/exec /usr/bin/containerd-shim: resource temporarily unavailable: unknown (shim を起動できませんでした: fork/exec /usr/bin/containerd-shim: リソースは一時的に利用できません: 不明)
このエラーは、最大 PID または最大ファイル数についての定義されたカーネル設定によるオペレーティングシステムの制限が原因で発生します。
次のコマンドを実行して、ポッドに関する情報を取得します。
$ kubectl describe pod example_pod
出力例:
kubelet, ip-xx-xx-xx-xx.xx-xxxxx-x.compute.internal Failed to create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox container for pod "example_pod": Error response from daemon: failed to start shim: fork/exec /usr/bin/containerd-shim: resource temporarily unavailable: unknown
この問題を一時的に解決するには、ノードを再起動します。
問題をトラブルシューティングするには、次の操作を実行します。
- ノードログを収集します。
- Docker ログで**「dockerd[4597]: runtime/cgo: pthread_create failed: Resource temporarily unavailable」** (dockerd[4597]: ランタイム/cgo: pthread_create が失敗しました: リソースは一時的に使用できません) というエラーがないか確認します。
- Kubelet ログに次のエラーがないかを確認します。
- 「kubelet[5267]: runtime: failed to create new OS thread (have 2 already; errno=11)」(kubelet[5267]: ランタイム: 新しい OS スレッドの作成に失敗しました (既に 2 つあります; errno=11))
- 「kubelet[5267]: runtime: may need to increase max user processes (ulimit -u)」(kubelet[5267]: ランタイム: 最大ユーザープロセス数を増やす必要がある可能性があります (ulimit -u))。
- ps コマンドを実行して、ゾンビプロセスを特定します。出力で Z 状態が付されてリストされているプロセスはすべてゾンビプロセスです。
Network plugin cni failed to set up pod network: add cmd: failed to assign an IP address to container (ネットワークプラグイン cni がポッドネットワークを設定できませんでした: add cmd: コンテナに IP アドレスを割り当てることができませんでした)
このエラーは、Container Network Interface (CNI) が新しくプロビジョニングされたポッドに IP アドレスを割り当てることができないことを示します。
CNI が新しく作成されたポッドに IP アドレスを提供しない理由は次のとおりです。
- 最大限許可される Elastic Network Interfaces と IP アドレスをインスタンスが使用した。
- Amazon Virtual Private Cloud (Amazon VPC) サブネットの IP アドレス数が 0 である。
ネットワークインターフェイスの IP アドレスが枯渇した例を次に示します。
Instance type Maximum network interfaces Private IPv4 addresses per interface IPv6 addresses per interface t3.medium 3 6 6
この例では、インスタンス t3.medium には最大 3 つのネットワークインターフェイスがあり、各ネットワークインターフェイスには最大 6 つの IP アドレスがあります。最初の IP アドレスはノードに使用され、割り当てることはできません。つまり、ネットワークインターフェイスが割り当てることができる IP アドレスは 17 個です。
ネットワークインターフェイスの IP アドレスがなくなると、Local IP Address Management デーモン (ipamD) のログに次のメッセージが表示されます。
"ipamd/ipamd.go:1285","msg":"Total number of interfaces found: 3 " "AssignIPv4Address: IP address pool stats: total: 17, assigned 17" "AssignPodIPv4Address: ENI eni-abc123 does not have available addresses"
次のコマンドを実行して、ポッドに関する情報を取得します。
$ kubectl describe pod example_pod
出力例:
Warning FailedCreatePodSandBox 23m (x2203 over 113m) kubelet, ip-xx-xx-xx-xx.xx-xxxxx-x.compute.internal (combined from similar events): Failed create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "provisioning-XXXXXXXXXXXXXXX": networkPlugin cni failed to set up pod "provisioning-XXXXXXXXXXXXXXX" network: add cmd: failed to assign an IP address to container
サブネットに空き IP アドレスが不足していないかどうかをサブネットで確認します。Amazon VPC コンソールの [Subnets] (サブネット) セクションで、各サブネットで使用可能な IP アドレスを確認できます。
Subnet: XXXXXXXXXX IPv4 CIDR Block 10.2.1.0/24 Number of allocated ips 254 Free address count 0
この問題を解決するには、ワークロードの一部をスケールダウンして、使用可能な IP アドレスを解放します。追加のサブネットキャパシティが使用できる場合は、ノードをスケールできます。また、追加のサブネットを作成することもできます。詳細については、「Amazon EKS で複数の CIDR 範囲を使用するにはどうすればよいですか?」を参照してください。 「新しい CIDR 範囲を使用してサブネットを作成する」セクションの指示に従います。
「Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused」(ダイヤル TCP 127.0.0.1:50051 のダイヤル中にエラーが発生しました: 接続: 接続が拒否されました)
このエラーは、ノード上で aws-node ポッドの実行が失敗したため、aws-node ポッドが IPAM との通信に失敗したことを示しています。
次のコマンドを実行して、ポッドに関する情報を取得します。
$ kubectl describe pod example_pod
$ kubectl describe pod/aws-node-XXXXX -n kube-system
出力例:
Warning FailedCreatePodSandBox 51s kubelet, ip-xx-xx-xx-xx.ec2.internal Failed create pod sandbox: rpc error: code = Unknown desc = [failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "example_pod": NetworkPlugin cni failed to set up pod "example_pod" network: add cmd: Error received from AddNetwork gRPC call: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused", failed to clean up sandbox container
"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "example_pod": NetworkPlugin cni failed to teardown pod "example_pod" network: del cmd: error received from DelNetwork gRPC call: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused"]
この問題をトラブルシューティングするには、aws-node ポッドがデプロイされ、[Running] (実行中) 状態であることを確認します。
kubectl get pods --selector=k8s-app=aws-node -n kube-system
注: クラスターバージョンに合った正しいバージョンの VPC CNI プラグインを実行していることを確認してください。
Liveness と Readiness のプローブエラーが原因で、ポッドが [Pending] (保留中) 状態になっている可能性があります。互換性の表に従って、推奨される VPC CNI アドオンバージョンが最新であることを確認してください。
次のコマンドを実行して、aws-node ポッドからの最後のログメッセージを表示します。
kubectl -n kube-system exec -it aws-node-XXX-- tail -f /host/var/log/aws-routed-eni/ipamd.log | tee ipamd.log
この問題は、Dockershim マウントポイントがマウントに失敗したために発生することもあります。この問題が発生したときに受信する可能性があるメッセージの例を次に示します。
Getting running pod sandboxes from \"unix:///var/run/dockershim.sock\ Not able to get local pod sandboxes yet (attempt 1/5): rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or director
前述のメッセージは、ポッドが var/run/dockershim.sock をマウントしなかったことを示しています。
この問題を解決するには、次の操作をお試しください。
- aws-node ポッドを再起動してマウントポイントを再マッピングします。
- ノードを cordon し、ノードグループ内のノードをスケールします。
- Amazon VPC ネットワークインターフェイスを、サポートされている最新のクラスターバージョンにアップグレードします。
CNI をマネージドプラグインとして AWS マネジメントコンソールに追加した場合、aws-node はプローブに失敗します。マネージドプラグインはサービスアカウントを上書きします。ただし、サービスアカウントは選択したロールで設定されません。この問題を解決するには、AWS マネジメントコンソールからプラグインをオフにし、マニフェストファイルを使用してサービスアカウントを作成します。または、現在の aws-node サービスアカウントを編集して、マネージドプラグインで使用されているロールを追加します。
「Network plugin cni failed to set up pod "my-app-xxbz-zz" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address」(ネットワークプラグイン cni がポッド「my-app-xxbz-zz」ネットワークを設定できませんでした: Kubernetes 引数: ポッドにラベル vpc.amazonaws.com/PrivateIPv4Address がありません)
このエラーは、次のいずれかの理由で発生します。
- ポッドが正しく動作していません。
- ポッドが使用している証明書が正常に作成されていません。
このエラーは、Windows ワークロードを実行するために Amazon EKS クラスターで必要な Amazon VPC アドミッションコントローラーウェブフックに関連しています。このウェブフックは kube-system 名前空間でポッドを実行するプラグインです。このコンポーネントは Linux ノードで実行され、Windows ノード上の着信ポッドのネットワークを許可します。
次のコマンドを実行して、影響を受けるポッドのリストを取得します。
kubectl get pods
出力例:
my-app-xxx-zz 0/1 ContainerCreating 0 58m <none> ip-XXXXXXX.compute.internal <none> my-app-xxbz-zz 0/1 ContainerCreating 0 58m <none>
次のコマンドを実行して、ポッドに関する情報を取得します。
$ kubectl describe pod my-app-xxbz-zz
出力例:
Failed to create pod sandbox: rpc error: code = Unknown desc = failed to set up sandbox container "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" network for pod "<POD_ANME>": networkPlugin cni failed to set up pod "example_pod" network: failed to parse Kubernetes args: pod does not have label vpc.amazonaws.com/PrivateIPv4Address
Reconciler worker 1 starting processing node ip-XXXXXXX.compute.internal. Reconciler checking resource vpc.amazonaws.com/PrivateIPv4Address warmpool size 1 desired 3 on node ip-XXXXXXX.compute.internal. Reconciler creating resource vpc.amazonaws.com/PrivateIPv4Address on node ip-XXXXXXX.compute.internal. Reconciler failed to create resource vpc.amazonaws.com/PrivateIPv4Address on node ip-XXXXXXX.compute.internal: node has no open IP address slots.
Windows ノードは、ノードごとに 1 つのネットワークインターフェイスをサポートします。各 Windows ノードは、ネットワークインターフェイスごとに利用可能な IP アドレスから 1 を減じた数だけポッドを実行できます。この問題を解決するには、Windows ノードの数を増やします。
IP アドレスが問題でない場合は、Amazon VPC アドミッションコントローラーポッドのイベントとログを確認してください。
次のコマンドを実行して、Amazon VPC アドミッションコントローラーポッドが作成されたことを確認します。
$ kubectl get pods -n kube-system OR kubectl get pods -n kube-system | grep "vpc-admission"
出力例:
vpc-admission-webhook-5bfd555984-fkj8z 1/1 Running 0 25m
次のコマンドを実行して、ポッドに関する情報を取得します。
$ kubectl describe pod vpc-admission-webhook-5bfd555984-fkj8z -n kube-system
出力例:
Normal Scheduled 27m default-scheduler Successfully assigned kube-system/vpc-admission-webhook-5bfd555984-fkj8z to ip-xx-xx-xx-xx.ec2.internal Normal Pulling 27m kubelet Pulling image "xxxxxxx.dkr.ecr.xxxx.amazonaws.com/eks/vpc-admission-webhook:v0.2.7" Normal Pulled 27m kubelet Successfully pulled image "xxxxxxx.dkr.ecr.xxxx.amazonaws.com/eks/vpc-admission-webhook:v0.2.7" in 1.299938222s Normal Created 27m kubelet Created container vpc-admission-webhook Normal Started 27m kubelet Started container vpc-admission-webhook
次のコマンドを実行して、ポッドログに設定上の問題がないか確認します。
$ kubectl logs vpc-admission-webhook-5bfd555984-fkj8z -n kube-system
出力例:
I1109 07:32:59.352298 1 main.go:72] Initializing vpc-admission-webhook version v0.2.7. I1109 07:32:59.352866 1 webhook.go:145] Setting up webhook with OSLabelSelectorOverride: windows. I1109 07:32:59.352908 1 main.go:105] Webhook Server started. I1109 07:32:59.352933 1 main.go:96] Listening on :61800 for metrics and healthz I1109 07:39:25.778144 1 webhook.go:289] Skip mutation for as the target platform is .
前述の出力は、コンテナが正常に起動したことを示しています。その後、ポッドは vpc.amazonaws.com/PrivateIPv4Address ラベルをアプリケーションポッドに追加します。ただし、アプリケーションポッドのマニフェストには、ポッドが Windows ノードでスケジュールされるように、ノードセレクターまたはアフィニティが含まれている必要があります。
この問題をトラブルシューティングする他の方法には、次を検証することが含まれます。
- kube-system 名前空間に Amazon VPC アドミッションコントローラーポッドをデプロイしたこと。
- ログまたはイベントが期限切れの証明書をポイントしていないこと。証明書の有効期限が切れており、Windows ポッドが [Container creating] (コンテナ作成中) の状態のままになっている場合は、ポッドを削除して再デプロイする必要があります。
- タイムアウトや DNS 関連の問題がないこと。
Amazon VPC アドミッションコントローラーを作成しない場合は、クラスターの Windows サポートをオンにします。
重要: Amazon EKS では、Windows ノードグループをサポートするために Amazon VPC アドミッションコントローラをオンにする必要はありません。Amazon VPC アドミッションコントローラーをオンにした場合は、データプレーンからレガシー Windows サポートを削除してください。
関連情報
関連するコンテンツ
- AWS公式更新しました 2年前
- AWS公式更新しました 3ヶ月前
- AWS公式更新しました 6ヶ月前
