karpenter-provider-aws: incompatible with provisioner. No instance type satisfied resources

Version

Karpenter Version: v0.20.0

Kubectl Version:

Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.14-eks-fb459a0", GitCommit:"b07006b2e59857b13fe5057a956e86225f0e82b7", GitTreeState:"clean", BuildDate:"2022-10-24T20:32:54Z", GoVersion:"go1.16.15", Compiler:"gc", Platform:"linux/amd64"}

Expected Behavior

karpenter launches a new node and the pod is scheduled

Actual Behavior

karpenter is unable to launch an instance with the below error

Warning FailedScheduling 1s karpenter Failed to schedule pod, incompatible with provisioner "useast1-infrastructure", incompatible requirements, key node-type, node-type In [StatefulSet] not in node-type In [Infrastructure]; incompatible with provisioner "useast1-stateful", no instance type satisfied resources {"cpu":"1","memory":"1Gi","pods":"1"} and requirements node-type In [StatefulSet], topology.kubernetes.io/zone In [us-east-1a], kubernetes.io/arch In [amd64], karpenter.k8s.aws/instance-generation Exists >2, topology.kubernetes.io/region In [us-east-1], karpenter.sh/capacity-type In [spot], karpenter.k8s.aws/instance-category In [c m r], kubernetes.io/os In [linux], karpenter.sh/provisioner-name In [useast1-stateful]

Steps to Reproduce the Problem

Apply the attached specs and deploy a pod with the node selector node-type: StatefulSet

Resource Specs and Logs

specs.zip

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave “+1” or “me too” comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 42 (15 by maintainers)

Most upvoted comments

@ellistarn working as expected now! Thanks a ton.

@ellistarn I deleted the discovery tag on subnet in 1A and re-added. That could be the reason why it shows as discovered recently. And also the reason why it was not able to launch instances in 1A. I am testing it on us-east-1a again as we speak. I will keep you posted. Looks like you may have solved the mystery 😃

apm.yaml.txt

attached… please rename it .yaml

We have the affinity and anti affinity requirements that I pasted above. No topology spread constraints. Let me attach the full manifest 1 sec

We updated the docs to give more details on this one.