-
Notifications
You must be signed in to change notification settings - Fork 986
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nodes come up slower then expected #1639
Comments
Controller log from large batch
|
Hello @mmclane ! |
Great to hear that someone is looking into it. Let me know if I can help. I am also available on the Kubernetes slack |
So far I've been unable to reproduce this problem. Can you clarify your timings from above? Does it seem that in each test you're waiting for the CNI plugin to start? Would you be willing to share the "events" output for a pod that is taking a long time to start?
|
You can disregard this question. I guess I missed your comment from above: "During this time the pods report that they are waiting on the CNI to be available but that only takes 30s after the node is ready." Events would still be helpful to look at, though. |
Could you also share logs from the |
Node took 87s to be ready. Logs from aws-node pod on new node. This is up and running right away.
|
Pods took ~ 8m30s Events:
|
Does that image normally take 4m to pull?
|
So this morning I ran tested this. I had 6 pods running on my cluster (the number that can fit on my existing node and then added 1 more so that it would spin up a new node with only one pod. Here is the time it took to pull the image
So... my question is this. Is k8s trying to pull the same image multiple times when a new node comes up and thus running into issues or something? |
Here is the full event listing
Its worth noting that it took a LOT less time for the linkerd images to get pulled too. |
Hey @mmclane . The image pull policy for your "app" container is set to
|
I thought of that and changed it but it didn't seem to make a difference. |
Out of curiosity, I noticed this in your image line: I'm not familiar with |
Yep, that is exactly what that is for. |
OK, just reading about Imagescan a bit more and it seems this is just a method to populate manifests with most recent image:tag. Shouldn't be related to pull performance. |
It shouldn't be related. It just updates the manifest in git for us. |
Hey @mmclane . Updating the issue per our findings while working together through Slack. It seems the container-runtime in use is related to this problem. When we force new Karpenter nodes to use Going to try to reproduce this directly through containerd to see if there is a difference. |
Events for node on karpenter provisioned node that is running docker instead of containerd. Not that 5 other pods were launching at the same time. This is in contrast to the 4 minutes it takes to pull the images with containerd.
Nodes:
|
Seems like this PR is related to our problem with containerd: containerd/containerd#6702 |
I did some testing and found that the PR mentioned above improves containerd image pull performance considerably when merged into the release/1.5 branch. As such, I'm planning to cut a PR to back-port the fix to containerd-1.5.x. The issue manifests when many pods are scheduled on a single node at one time which all use the same image. In my testing I was able to reproduce the problem with containerd-1.4.13 and containerd-1.5.11 by launching 20 pods that all used the same 250MB image (golang:latest). I then patched 1.5.11 with the code in containerd/containerd#6702 and found image pull times reduced from ~3 minutes to under 30 seconds in most cases. Below is an example of the difference in image pull times from the versions tested. containerd-1.4.13 (3 minutes and 12 seconds)
containerd-1.5.11 (3 minutes and 26 seconds)
containerd-1.5.11-patched (17 seconds)
|
The PR to back port the image pull performance fix to containerd-1.5.x was denied. The fix was included in containerd-1.6.4, however, which I've briefly tested alongside k8s 1.21+. I do not have a timeline for when containerd-1.6.x will built into the EKS Optimized AL2 image. There are a few possible workarounds to the improve image pull performance in the meantime:
|
Labeled for closure due to inactivity in 10 days. |
@tzneal could the flag |
The most recent version of the EKS Optimized AL2 image upgraded to Containerd 1.6.6 (https://github.com/awslabs/amazon-eks-ami/releases/tag/v20220824). Issues with slow pod startup times should now be resolved. I'm going to go ahead and close out this issue. Feel free to reopen if need be. Thanks! |
Version
Karpenter: v0.8.1
Kubernetes: v1.21.1
Expected Behavior
Brandon (on slack) suggested that my nodes should be coming up a little faster and asked me to post an issue so the team could look into it.
Actual Behavior
I have an EKS cluster running with the latest CNI plugin (v.1.10.2) and I am using the latest version of Karpenter to scale nodes out dynamically. That works great but I am seeing some slowness when a new nodes is added that I can't explain and I am trying to understand and if possible improve. The following are my observations. I have found these times to be fairly consistent over multiple tests.
Core cluster nodes support 6 pods of our application running. When I added a new pod to our cluster and it gets scheduled on an existing node, the pods are ready and available in ~40s.
Adding two pods so that karpenter creates a new node creates a t3.medium.
Adding eight new pods, karpenter creates a t3.2xlarge
During this time the pods report that they are waiting on the CNI to be available but that only takes 30s after the node is ready. It also doesn't explain why it takes so much longer for a larger node then a smaller one. I suspect that this might be related: aws/amazon-vpc-cni-k8s#1943 but I don't know when that will make it into a release.
I have also created an issue on the aws/amazon-vpc-cni-k8s repo: aws/amazon-vpc-cni-k8s#1956
Steps to Reproduce the Problem
Use karpenter to create a small node (t3.small) and node the times, then have it create a large node (t3.xlarge) and node the difference in how long it takes for your pods to be available.
Resource Specs and Logs
Provisioner spec
Deployment Spec:
Controller Logs for small batch:
The text was updated successfully, but these errors were encountered: