- Le plus récent
- Le plus de votes
- La plupart des commentaires
One Pod is running when restarting the deployment. For the 2nd Pod if we delete it 2-3 time then it is also running
Hi,
How is the VPC configured? Does it have Public and private subnets? Which subnets are assigned to the fargate profile. Do the private subnets have default routes assigned via NAT gateway / NAT instance?
With limited info available, one possible reason I can think of is that the non running pod is scheduled in the private subnet with no internet access and hence is pending. You might want to rule this out.
--Syd
For one pod it is able to pull the image and for another pod it is giving error. The image URL is same for both. Sometimes both are not running after restarting multiple times they are running
Troubleshooting CoreDNS Pending State, as per: https://repost.aws/knowledge-center/eks-resolve-pending-fargate-pods
- Confirm no default annotation for EC2 compute type in CoreDNS deployment.
- Ensure CoreDNS pods selectors match a Fargate profile in the cluster.
- Check Fargate profile and pod specs for compatible VPC subnets and IAM roles.
- Investigate pod events and describe pods for image pull failure clues.
- Delete one CoreDNS pod to isolate the issue.
- Deploy a simple pod with the same image for testing image pull success.
Contenus pertinents
- demandé il y a un an
- demandé il y a 3 mois
- demandé il y a un an
- Réponse acceptéedemandé il y a 8 mois
AWS OFFICIELA mis à jour il y a 3 ans- AWS OFFICIELA mis à jour il y a 8 mois
- AWS OFFICIELA mis à jour il y a 5 mois
- AWS OFFICIELA mis à jour il y a un an
It depends on which subnet is assigned. If fargate is configured to launch in public and private subnets, any of the subnet might be assigned. Assuming private subnet does not have a route via NAT, and the pod is configured in one of the private subnets, the pod might be pending. (Just elaborating on the possible cause I mentioned). Image is not a problem. You mentioned that if you delete 2 or 3 times then it run. Check which subnets it's assigned to when in pending state (assuming AWS console shows that ) and compare with pod 1.