On September 23 at 20:00 MSK, Sergey Bondarev will host a free webinar "", where he will explain how they prepare kubespray to make it fast, efficient, and fault-tolerant.
Sergey Bondarev will discuss the differences between the original version and our fork:
The Difference Between the Original Version and Our Fork.
Those who have encountered kubespray may be puzzled as to why I am contrasting kubeadm with kubespray, since kubespray is designed to create a cluster and it indeed invokes kubeadm, seeming at first glance like a package installation and automated launch script.
But that was not always the case; originally, kubespray installed all components independently:
- it assembled the etcd cluster;
- it installed kubelets, generated certificates, configurations, and access tokens for static pods of the control plane and other service components;
- it created service accounts for worker nodes and connected them to the cluster.
However, the year before last, they removed this functionality, leaving only kubeadm, which at that time was not very effective. I was disappointed, so I created my fork, where I preserved the classic installation mode, and now I'm keeping this fork current by cherry-picking commits from the original kubespray. Meanwhile, I am updating the classic mode to accommodate new changes.
As a result, the difference between the clusters created by my fork and the original is kube-proxy and the validity periods of the certificates.
In my fork, everything remains as it was: kube-proxy runs as a static pod, and certificates are issued for 100 years.
In Kubeadm, kube-proxy runs as a daemonset, and certificates are issued for 1 year, requiring regular renewal. Kubeadm has finally learned how to do this with a single command.
The difference is minor, and today we use both options.
Features (Drawbacks) in Industrial Use:
The scenario is universal, so it's not very fast. A custom setup can be significantly accelerated by skipping checks and launching from a ready-made image.
The scenario is complex, with illogical parts and a heavy legacy. Installing additional controllers and software through Kubespray is good for learning and testing. In production, relying on Kubespray is not a wise idea, plus the software updates are done by the "kill-it-make-new" method, meaning there will be downtime.
You can only add worker nodes; there are some nuances with masters regarding certificates, and the scenario does not handle all potential issues that may arise.
For instance, I had a problem with kubeadm when it failed while adding the second and third master, and after that, Kubespray performed a kubeadm reset on the node and attempted to add the master again.
The problem was that by the time of failure, the second etcd instance had already managed to register, and since it was also removed after the reset, we ended up with a nightmare—a two-node etcd cluster, one of which was deleted, and the second no longer accepting clients. As a result, the cluster died before it was born.
Open source as it is.
All this and much more in the free webinar "" on September 23 at 20:00 MSK.
Join us!
Source: habr.com
