September 23, 20.00 Moscow time Sergey Bondarev will hold a free webinar "”, where he will tell you how to prepare kubespray to make it fast, efficient and fault-tolerant.
Sergey Bondarev will tell you the difference between the original version and our fork:
The difference between the original version and our fork.
Those who have already encountered the cubespray are probably now wondering why I oppose kubeadm to the cubespray, because the cubespray for creating a cluster just calls kubadm and at first glance looks like a package installation script and an automated launch.
But this was not always the case, initially the cubespray installed all the components on its own:
- assembled an etcd cluster;
- installed kublets, generated certificates, configs and access tokens for static pods of the controlplain and other service components;
- created service accounts for worker nodes and connected them to the cluster.
But the year before last, they sawed out this functionality, leaving only the cubadm. Which at the time was not very good. I felt offended and made my own fork, in which I kept the classic installation mode, and actually now I keep this fork up to date, cherry-picking the commits from the original cubespray to myself. Along the way, finishing the classic mode for new changes.
As a result, the difference between the clusters created by my fork and the original one is kube-proxy and certificate expiration dates.
In my fork, everything remains as it was before - the proxy cube is launched as a static pod, certificates are issued for 100 years.
In Kubeadm, the proxy cube runs as a daemonset, and certificates are issued for 1 year and must be renewed periodically. kubeadm has finally learned how to do this with one command.
The difference is small, and today we use both options.
Features (disadvantages) in industrial operation:
The script is universal, so it's not very fast. Your own can be significantly accelerated by throwing out checks, starting from the finished image.
The script is complex, there are illogical places, a heavy legacy. Installation of add. controllers and software via cubespray - good for learning and testing. In the prom. operation to depend on the cubespray is not a very sensible idea, plus the software update is implemented by the "kill-made new" method - it means a break in service.
It can only add worker nodes, with masters there are some nuances with certificates, and the script does not work out all the possible problems that may arise.
For example, I had a problem with kubeadm when it crashed at the time of adding the second and third master, and after that the cubespray did a kubeadm reset on the node, and tried to add the master again.
The only problem was that by the time of the failure, the second etcd instance had already managed to register, and since it was also deleted after the reset, we got a nightmare - an etcd cluster of two nodes, one of which was deleted, and the second no longer accepts clients. As a result, the cluster died without being born.
open source as it is.
All this and more in this free webinar» September 23, 20.00 Moscow time.
Join now!
Source: habr.com