Kubic:KubicD and kubicctl
What are KubicD/kubicctl?
kubicd is a gRPC based daemon using mutualTLS and RBAC for communication and salt with kubeadm to setup and manage a Kubernetes cluster on openSUSE Kubic. Authantication is done via certificates. kubicctl is the corresponding command line interface.
What is Kubernetes?
Kubernetes is an open-source system for automating deployment, scaling, and management of containerised applications. It groups containers that make up an application into logical units for easy management and discovery. Services then receive features like self-healing, high-availability, and load balancing with Kubernetes taking steps to ensure services keep running even in the event of failures. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.
Put simply, if you want to run containers across multiple servers in a coordinated way, you probably want to use Kubernetes.
If you only need to run containers on a single server, then we recommend using MicroOS, which offers both the Podman/CRI-O and Docker container runtimes for running containers on a stand-alone system.
Please Note: the whole kubernetes and tooling stuff on openSUSE Kubic is under heavy active development.
Mainly generic requirements by kubernetes itself:
- All the nodes on the cluster must be on a the same network and be able to communicate directly with each other.
- All nodes in the cluster must be assigned static IP addresses. Using dynamically assigned IPs will break cluster functionality if the IP address changes.
- The Kubernetes master node(s) must have valid Fully-Qualified Domain Names (FQDNs), which can be resolved both by all other nodes and from other networks which need to access the cluster.
- Since Kubernetes mainly works with certificates and tokens, the time on all Nodes needs to be always in sync. Else communication inside the cluster will break.
For installing on bare metal, burn this media to a DVD or USB Stick, and then boot your first system from it. For VMs or VPS providers just boot the iso directly. This first system will be the machine we will refer to as the Admin Node, and will run the core Kubernetes services but not any containerised applications. That will be done by additional machines referred to as Worker Nodes.
After selecting your language and agreeing to our license, you will be presented with the "System Roles" screen. Select Kubic Admin Node. Even if it is only marked as Alpha, it should work pretty well.
Follow the next step of configuring NTP, setting a root password and optional ssh keys, and if you wish you can customize networking and other options before starting the installation. We recommend leaving the defaults unless you know what you're doing. The installation will then proceed, and you will end up with the login prompt.
Setting up Kubernetes master
Login using the root password set during the installation or remotely via ssh.
flannel is used as default POD network.
kubicctl init --pod-network cilium will use cilium as POD network. But be warned, that cilium needs much more memory than flannel.
After a brief period, your Master should now be initialized. Additional, transactional-update is configured and kured is used to reboot the nodes after an successful update.
To be able to talk to the cluster, create the directory
mkdir ~/.kube and
kubicctl kubeconfig > ~/.kube/config
Joining nodes to the cluster
This now means your admin node is fully set up and ready for other nodes to join it. To install a worker node you have to select another system role: Kubic Worker Node. Everything else during installation is just as before.
However, before you can communicate with the admin node, you need to configure and start the salt minion.
Create a configuration file telling salt the name of our admin node:
echo "master: <admin-hostname>" > /etc/salt/minion.d/master.conf and enable it:
systemctl enable --now salt-minion.service
Accept now on the admin node the salt minion. List at first all keys (
salt-key -L) and accept them (
Afterwards you can join the nodes:
kubicctl node add node1,node2,.... The node names need to be the one of the salt minions in the same form has you have accepted.
Verifying the cluster
Now from your master node (or any system with
kubectl installed and the
/etc/kubernetes/admin.config file from the master copied to your users
$HOME/.kube/config file) you can run
kubectl get nodes to confirm your cluster is operational.
Congratulations! You now have a working Kubernetes cluster.
For further documentation, we highly recommend you read .