After upgrading to kubelet 1.24 kubernetes won't even start. Complains about an unrecognized flag "--network-plugin=cni". And stackoverflow has nothing to offer to work around it.

God I hate backwards-incompatible software updates. Esp w/o vendor's scripts automatically porting old version configs to match the new configuration convention.

Now I have to learn all about something big, called dockershim.

Fuck! I so don't want to spend my whole day on this...

It's not very linuxish to push breaking updates w/o any bpo mechanism, esp for a software that's a part of the linux foundation :|

Not entirely true, sadly. Sadly as this seems like the typical case of "you are not part of the community bubble and missed this".

The move to remove the docker shim was well communicated.

https://kubernetes.io/blog/2022/...

Can understand your frustrations, but the topic started roughly 3-4 years ago.

If you need help, give a shout.

@IntrusionCM yeah, saw that deprecation since long ago. Yet, software features get deprecated all the time, and somehow kube is the only soft in many years of my xp with linux, where it broke this bad after upgrade.

I'll be digging into this thing sometime soon, so if you have any good references [e.G. Easy instructions to migrate], I'd appreciate if you shared

@netikras

https://kubernetes.io/docs/tasks/...

Is pretty much the best starting point.

Unless you ran an _ancient_ docker version, the docker runtime installed should be with containerd since a long long time.

https://docker.com/blog/...

As maybe more background information.

The removal of the docker shim is just inside kubernetes.

https://github.com/Mirantis/...

cri-dockerd is the alternative, provided by mirantis.

Unless you want to do a full migration away from cri-dockerd to e.g. cri-o, it's just pulling the plug from the docker shim, and providing the docker shim via the new plugin cri-dockerd.

A full migration to cri-o would *definitely* be an epic task, u might want to look at the differences nevertheless.

@IntrusionCM brilliant, thank you!

I honestly do not understand why anyone thinks this stuff makes life easier. More accurately, I do not understand how bringing in technologies that create so many problems can ever be justified.

@ultrageoff which tech are you referring to?

Containers?

@Voxera Kubernetes, Docker . I know I'm very old-fashioned, but I just see so much time spent getting involved with obscure issues and by-no-means intuitive config processes that solve problems that I genuinely never have, whether working in a team or solo. It seems a lot of (user experienced) problems occur *because* of the great complexities involved in deployment.

@ultrageoff neither are especially new, just new packaging.

And if you do mot see the need you probably do not need them :)

But when you have the kind of problems they are intended to solve they are usually worth all the work needed.

@Voxera Thanks, but unfortunately, not needing them doesn't necessarily mean I won't have them! My company brought in an IT director who moved our limited user traffic in-house stuff up onto AWS. I couldn't match his enthusiasm for the new multi-stage processes this then necessitated. Me, I just upload the new stuff to live when I'm bored with testing it on the dev site. Typically, deploy in under a minute.

@ultrageoff well then I understand, going containers if you do mot need them adds a lot of overhead :/

@netikras Downgrade back to 1.23.
the docker cri is not the problem.
Last week I was trying to setup a new single node k8s cluster:
ubuntu 18.04/containrd latest/kubeadm latest/calico rbac latest/canal cni latest.
And.... nope. Nopety nope. CRI issues. Master node not ready bc network not ready. flanel? nope. tigra operator? nope.
wasted 2 hours tring to figure out what the shit.

Consulted devops dude - says: yup. known problem. downgrade k8s, and it just works.

@magicMirror considering that route quite seriously. Thanks

@magicMirror Ubuntu 18.04 is ancient.

Might switch directly to 22.04.

@IntrusionCM No argument there.

It is the standard VM image at my company, along with debian strech (yup. strech!) as the docker base image.

@magicMirror sad. very sad.