architecture
The architecture of DOK is built on top of kubeadm, and the functions of kubeadm are enhanced by introducing some easy-to-maintain scripts. All in all, DOK allows users to build a production environment-level Kubernetes cluster in about 2 minutes, and has many cluster operation and maintenance requirements ability.
At present, there are many tools in the community for deploying Kubernetes clusters, such as the official kubeadm, kubespray, Rancher’s rke, Qingyun’s kubekey, and Alibaba’s previous open source sealos. In addition, for the deployment of such complex software, you can also choose to use ansible Waiting for tools to package, after comprehensive research and comparison, mainly based on the following points to decide self-development:
- Ansible’s variable processing is very complicated, and symbols such as
{{}}
provided by the template make the configuration file less readable - Some tools do not fully support offline installation, but the possibility of being directly connected to the public network in a privatization scenario is relatively low
- Too many supported versions lead to increased complexity of scripts and tools
There are two main core competencies of DOK:
- Encapsulate ssh, scp, cmd to allow users to execute commands and distribute files locally or remotely
- Most of the components are integrated in the installation package through binary or compressed packages, which can fully support offline cluster creation
Regarding the writing of scripts, I personally prefer very concise scripts. The more lines of scripts, the better. In general, it is recommended that the script used by DOK should not exceed 100 lines, and there is no need to use too many functions or custom variables, which will lead to poor readability of the script, which is not easy to maintain and understand , concise scripts require more in-depth thinking in design, and DOK will try to keep scripts that can run independently of programs.
- The execution machine distributes the installation package to each machine in the cluster
- Remotely execute the command to decompress the installation package and initialize the binary, configuration file, and image file according to the script
- The execution machine creates master0 through kubeadm
- Remotely execute the kubeadm command serial to join other master nodes
- Remotely execute the kubeadm command parallel to join the worker node
- Execute the command to install the network plug-in on the machine
- Execute the command to install the Helm application on the machine
DOK distribution installation package
DOK installation package installation process
The core logic of DOK cluster creation
DOK cluster high availability principle
The production environment recommends at least six 2c/4g/200G machines, three control nodes, and three working nodes. This is the minimum configuration requirement for a DOK cluster to run all components.
Looking carefully at the code of DOK, we can find that in deploying Kubernetes clusters, the framework code of DOK is written in go, but the core deployment process is a bunch of scripts. The reason for choosing such an architecture is that most of the Kubernetes deployed by SRE is done through scripts. Using scripts is more in line with the habits of SREs. The use of scripts is enriched through the Go language framework. In addition, when debugging and testing deployment scripts It is also very convenient. It can be recompiled and used with a little modification. It is conceivable that so many scripts need to be converted into Go code. The workload is not only heavy, but also the deployment process code is too obscure, which is not easy for secondary development.