KlusterKit

KlusterKit: a set of open-source tools designed to simplify Kubernetes deployments and operations in physically isolated local environments.

Today, we are excited to announce that Platform9 is open-sourcing Klusterkit, a suite of three tools, under the Apache v2.0 license on GitHub.

Our clients deploy software in private data centers, which are often offline (due to security reasons or other factors). These large companies want to leverage the benefits of Kubernetes and modernize their applications while deploying them across various data centers, which frequently lack external connectivity. This is where Klusterkit comes in, simplifying the delivery and management of K8s clusters in physically isolated environments.

Klusterkit includes three independent tools that can be used together or separately to manage the lifecycle of a production Kubernetes cluster:

1. etcdadm, a CLI for simplified management of the etcd cluster.
2. nodeadm, a CLI for node administration that complements kubeadm and deploys the dependencies required by kubeadm.
3. cctl, a cluster lifecycle management tool that adopts the Cluster API from the Kubernetes community and uses nodeadm and etcdadm to effortlessly deliver and maintain highly available Kubernetes clusters in local and physically isolated environments.

Together, these three tools perform the following tasks:

• Simple delivery and management of a highly available etcd cluster and Kubernetes control panel in physically isolated local environments via the Cluster API.
• Restoration of the cluster control panel after a failure using etcd backup.
• Packaging all artifacts needed for delivering Kubernetes in physically isolated environments.

Klusterkit capabilities

• Support for multiple masters (HA Kubernetes cluster).
• Deployment and management of secure etcd clusters.
• Operation in physically isolated environments.
• Support for sequential upgrades and rollbacks.
• Flannel (vxlan) as a CNI for the backend; plans to support other CNIs in the future.
• Fault tolerance and recovery of etcd clusters after quorum loss.
• Protection of the control panel from memory shortages and CPU time limitations.

Klusterkit solution architecture

For fault tolerance and simplicity, Klusterkit uses a single file cctl-state.yaml to store the Kubernetes cluster metadata. Through the cctl CLI, you can manage the lifecycle of a Kubernetes cluster on any machine that has this state file. This could be the operator's laptop or any other computer that is part of the Kubernetes cluster.

Cctl implements and calls the upstream cluster-api interface as a CRUD operation library for clusters. It utilizes ssh-provider, an open-source cluster-api provider on bare metal from Platform9, which in turn calls etcdadm and nodeadm to perform operations on the cluster.

How to use Klusterkit and its components:

1 – Any of the three tools can be easily built with the command go get:

go get -u github.com/platform9/cctl

go get -u github.com/platform9/nodeadm

go get -u github.com/kubernetes-sigs/etcdadm

2 – Then these executables can be packaged and copied to the target machines where the highly available Kubernetes cluster should run. Place the nodeadm and etcdadm files in the version directories:

cp $GOPATH/bin/nodeadm /var/cache/ssh-provider/nodeadm//

cp $GOPATH/bin/etcdadm /var/cache/ssh-provider/etcdadm//

3 – If you need to orchestrate the Kubernetes cluster locally, in a physically isolated environment, the necessary dependencies can be easily downloaded in advance on a computer with internet access using the download command for nodeadm and etcdadm. Then the downloaded items (i.e., kubelet and the kubelet unit file for systemd, CNI executable files, the kubeadm file, all container images including Kubernetes, the keepalived image, and the systemd file, the etcd container image, and related configuration files) can be easily copied to the physically isolated hosts along with cctl, nodeadm, and etcdadm. (For details, see wiki).

4 – When everything is in place, the first Kubernetes cluster can be created with a couple of commands:

– First, create the credentials for the cluster.

$GOPATH/bin/cctl create credential --user root --private-key ~/.ssh/id_rsa

– Then create a cluster object. –help invokes the list of supported parameters.

$GOPATH/bin/cctl create cluster --pod-network 192.168.0.0/16 --service-network 192.169.0.0/24

– Finally, create the first machine in the cluster.

$GOPATH/bin/cctl create machine --ip $MACHINE_IP --role master

Read more documentation at GitHub.

Source: habr.com