-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
CNI not ready on particular instance group #9530
Comments
Any chance you can provide a spec that reproduces this issue that contains a bit less custom stuff? Would make it easier to diagnose the issue. |
Aslo, can you check the |
Sure, I have updated the cluster spec without the additional user data key.
Kops-configuration latest logs (I actually checked them since the beginning and didn't find any errors) :
Kubelet status is running but the logs from journalctl show:
Daemon arguments are:
Regarding kube-proxy, kube-router replaces its functionality. |
The "network plugin is not ready: cni config uninitialized" part is misleading. This is an effect, not the cause. There should be other cause for nodes not being able to register, either in kubelet or in kube-router logs. |
Yes, I agree, it's really strange that it only happens on a particular instance group. |
By any chance is the group with the taint? |
Yes, it has one:
However, I'm not completely sure if this is the issue because we have another cluster with the same config (apart from the k8s version 1.15.3) and it's running with no issues. |
Well, at the end of the day, the issue was with the taints, I just removed it and the nodes are now ready and joined to the cluster. This is quite interesting, the other cluster like I previously mentioned, has almost the same configuration and it works with no issues, I thought the taints only affected workloads created after the cluster is validated. |
Thanks for the update @javierlga. |
@hakman: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/reopen I have decided to reopen the issue because I don't think it's the expected behavior, adding a taint to a particular instance group shouldn't affect node bootstrapping process, in this case the CNI. |
@javierlga: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Your expectation would not be correct. Taints affect all pods that don't tolerate them. But the kuberouter tolerations do seem a bit narrow. |
Yes, that's correct, tbh I haven't checked kube-router tolerations. |
1. What
kops
version are you running? The commandkops version
, will displaythis information.
Version 1.17.0
2. What Kubernetes version are you running?
kubectl version
will print theversion if a cluster is running or provide the Kubernetes version specified as
a
kops
flag.Server Version: v1.17.7
Client Version: v1.17.0
3. What cloud provider are you using?
Amazon Web Services
4. What commands did you run? What is the simplest way to reproduce this issue?
Created a new cluster running
kops create -f cluster.yaml
, a new secret for SSH keykops create secret --name test.k8s.local sshpublickey admin -i ~/.ssh/id_rsa.pub
and finallykops update cluster --yes
5. What happened after the commands executed?
All the resources defined within the YAML file were created, a group of three masters, and two different instance groups. However, the nodes from one instance group were not ready, looking at kubelet logs I could find this:
Kubelet:
kubeAPIServer logs:
CNI provider is kube-router.
6. What did you expect to happen?
Bootstrap all the nodes from both instance groups as expected to validate the cluster.
7. Please provide your cluster manifest. Execute
kops get --name my.example.com -o yaml
to display your cluster manifest.You may want to remove your cluster name and other sensitive information.
8. Please run the commands with most verbose logging by adding the
-v 10
flag.Paste the logs into this report, or in a gist and provide the gist link here.
9. Anything else do we need to know?
No
The text was updated successfully, but these errors were encountered: