kubeadm

I went down this rabbit hole not so long ago too. There was a discussion open on containerd's GitHub on removing the dependency on the pause image but it has been closed as won't fix: https://github.com/containerd/containerd/issues/10505 Also, if you are using kubeadm to create your cluster, beware that kubeadm may be pre-pulling a different pause image if it does not match your containerd configuration: https://github.com/kubernetes/kubeadm/issues/2020

Yep - my understanding of https://github.com/kubernetes/kubeadm/blob/main/docs/ha-cons... is that Kubernetes doesn't usually control that load balancer (nor should it, since you could accidentally tell Kubernetes to take down the control plane LB, then not be able to get it back up again!). I suppose one could set up a "fast pass lane" kubeconfig that adds a header that haproxy would understand, and route to a priority class in its queue with e.g. https://www.haproxy.com/documentation/haproxy-configuration-... . But there's no easy `kubectl --with-priority` (or, to my knowledge, good guidelines for the various gitops solutions) that follows this pattern out of the box.

Deploying k8s has gotten a lot easier these days -- some alternatives in this space: - https://docs.k0sproject.io (https://github.com/k0sproject/k0s) - https://k3s.io (https://github.com/k3s-io/k3s/) k0s is my personal favorite and what I run, the decisions they have made align very well with how I want to run my clusters versus k3s which is similar but slightly different. Of course you also can't go wrong with kubeadm[0][1] -- it was good enough to use minimally (as in you could imagine sprinkling a tiny bit of ansible and maintaining a cluster easily) years ago, and has only gotten better. [0]: https://kubernetes.io/docs/reference/setup-tools/kubeadm/ [1]: https://github.com/kubernetes/kubeadm

If you're looking to standup a kubernetes server and not on AWS, take a look at kubeadm[0][1]. kubeadm does just enough to build a cluster and not much more -- it's a really light-feeling (even though what it sets up is complicated) bit of kit. I use it to run on baremetal, and it's a wonderfully simple and robust tool (as well as officially supported) -- it's almost too good, because you should really know everything it's doing and if you use it from the start it's easy to get lost when something goes wrong (most of the time nothing will, but eventually something will). [0]: https://kubernetes.io/docs/reference/setup-tools/kubeadm/kub... [1]: https://github.com/kubernetes/kubeadm/

running into bugs and that I need to ssh into the nodes ;) (serious answer) I can basically automate nearly everything, os updates (coreos), deployment updates (ci/cd), however updating etcd or k8s is a manual operation on bare metal, either I'm on bootkube than I need to login and update kubectl, than I need to update all daemonsets/deployments in kube-system (it's not always easy and bootkube has strange bugs, https://github.com/kubernetes-incubator/bootkube/issues/977) So one should actually use kubeadm, once again I still need to update kubelet, so I need to ssh into the machine (anyway) I also need to update kubeadm and run it, again a manual operation. *ssh means I need to do it on my own, for small clusters this can be done manually for bigger clusters it can be scripted via ansible or even better create an own software that does i

I used to also recommend kubeadm, but then I recognized there is no HA whatsoever (and what's the point of a cluster that dies with the master?) Issue to track: https://github.com/kubernetes/kubeadm/issues/261 and https://github.com/kubernetes/kubernetes/pull/44793