Change:
} ``` <del> #### Support traffic shaping </del> <ins> ### Support traffic shaping </ins> **Experimental Feature**

Discussion:
! ref:
/sig node /kind cleanup If any flag found which was removed in , Kindly remove them too.
/triage accepted
/language en
For anyone facing this issue and Kubernetes is not starting, I removed the flag from file and restarted kubelet service. ().
/priority important-longterm
I have run into the same problem and removing it from does not work. Basically this breaks the system
Hi Seems like you are using . If not ,kindly share kubelet version and log. Thanks !!
The version i used was 1.24.0 from the debian repo, downgrading to 1.23.6 solved my issue and got everything running again Let me know if more information is needed?
How you have bootstrapped the cluster? Using kubeadm or different tools
I was using 1.23 and I came up with this issue upon performing updates to the nodes of the cluster (apt-get upgrade). Then, 1.24 was installed and the issue came up and I managed to resolve it as I mentioned above as the logs of the kubelet service were indicating error with the --network-plugin flag.
Behaviour is expected. since remove in v1.24 Please share and the output of ?
: Logs:
Folks, this is an accepted issue. We should update that page to remove mentions of the command line argument. Pull requests are welcome - see for tips on how to contribute.
my cluster is down after doing an apt upgrade. From what I can understand it looks like I have this issue, running version 1.24.0 as well. Is here any instructions on how to downgrade my cluster so that I can get it up and running again? Update: I’ve managed to get my cluster up and running again. Whilst I agree that this comment is off-topic for the exact problem at hand, this may help someone with the problem that I had. The problem is that my K8S install was running on docker, and now dockershim has been removed, which is what stopped my cluster working. I used a couple of posts to get the problem I was having solved. Here’s one of the link (I can’t remember the other) On the workers, I streamlined the changes to this…. The first line should prevent the problem that I had - auto upgrading k8s during an apt upgrade.

Updating to 1.24 had the breaking change that caused my cluster to become unavailable. sudo apt-mark hold kubelet kubeadm kubectl sudo systemctl enable --now kubelet sudo su - mkdir -p /etc/containerd containerd config exit sudo nano /var/lib/kubelet/kubeadm- Remove --network-plugin=cni Add --container-runtime=remote --container-runtime- Save Sudo reboot At this point the node should come up. Not 100% sure if this will solve the problem on the control plain, I got that working before streamlining the commands, anything else should be able to be taken from the link I posted above.
I got mine up by simply downgrading the kubelet to latest 1.23.x
I've marked some off-topic comments as hidden. They're not deleted (you can click Show comment to reveal them). Please, folks, do focus on the topic here: fixing the Kubernetes documentation about setting up cluster networking
If anyone has questions about how to propose a fix for , you're very welcome to ask. You can reply here or, if you use the Kubernetes workspace for Slack, ask there in the channel.
I've created a SO page to redirect all the "how to fix my cluster now" questions there: . Should I update the OP to reflect this link and state that this is not a request to fix the cluster's setup?
Duplicated by issue
We should edit so that it is no longer incorrect, and then close this issue.
Anyone who wants to edit that page is welcome to.
/assign
is reviewing PR
remove " --network-plugin"flag work fine.
This resulted in my case just in another error:
same error for me.
same here EDIT: fixed it by "migrating" from docker to containerd by simply: now connect kubelet to containerd directly by editing /etc/systemd/system/kubelet.service.d/10- add after "ExecStart=/usr/bin/kubelet" which looks like: for me. finally restart kubelet.service:
As this bug is resolved, I'm going to lock it to ensure that the record remains on-topic.