Deploying a Kubernetes cluster on OpenStack with Kubespray
This blog post walks you through deploying a Kubernetes cluster on OpenStack with Kubespray. In this example, we explain it through the SkyAtlas project, which uses OpenStack in its infrastructure. Kubespray uses Terraform for the provision of the environment and Ansible for the automatic deployment of Kubernetes.
If you only change the directory to kubernetes_cluster following the instructions in this blog post, you’ll have a virtual private environment for Kubernetes deployment.
After you run the Terraform apply command, you should get an output as below:
The output shows you the Public IP of your Bastion node, and your virtual subnet id used by the Kubernetes cluster.
Now, we need to log in to the Bastion node. Kubespray comes with a variety of deployment options, the cluster only accessible from Bastion node for management is what we follow as a method here. For the login to Bastion node, you need the ssh-key you used Terraform provisioning.
If you trigger this file with a Gitlab CI, the GitLab Runner will run the steps above automatically, and if everything goes as planned, you can log in to your Bastion node and continue the steps below.
Now we need to edit the inventory file for Ansible. If you don’t have OpenStack API Client, you can log in to SkyAtlas Dashboard, and under Compute/Instances, you can find your Kubernetes nodes and their IP addresses.
Then we edit the inventory file:
$ vim inventory/mycluster/inventory.ini
It should look like this:
Now we set cloud_provider option to OpenStack in all.yaml file.
$ vim inventory/mycluster/group_vars/all/all.yml
All Kubernetes cluster nodes are only accessible with the ssh-key we used for Terraform provision, but those nodes are only accessible from their own network, except Bastion node. So, if you add the private ssh-key to your Bastion node as ~/.ssh/id_rsa and edit your hosts and inventory files correctly, your ansible should be able to access your other Kubernetes nodes. (If you prefer to go with another file path, then you need the chance your Ansible config, or you can use —private-key= options.
Kubespray needs your environment variables from RC file.
You can find the way to get your RC file here. Source the RC file on Bastion node, and you’re ready for Kubernetes cluster deployment with Ansible.
If everything goes as planned, you should see results like this:
With the private key you put in Bastion Node, you can SSH your Kubernetes nodes. Add subnet-id and floating-network-id under LoadBalancer section on /etc/kubernetes/cloud_config file from all the master nodes. Your cloud_config file should look like this:
If you don’t have an OpenStack API client installed, you can get the subnet-id and floating-network-id from SkyAtlas Dashboard.
Let’s check the cluster status:
Let’s test it!
I already have this Docker image for test purposes, and we can use that image with the Kubernetes LoadBalancer service. Kubia is a simple node.js image which will accept HTTP requests and respond with the hostname of the machine it’s running in.
Edit kubia.yaml file and change the “THE_FLOATING_NETWORK_ID.” from the line starting with “loadbalancer.openstack.org/floating-network-id:” it’s under the Service section.
Create Pods and services from the file:
$ kubectl create -f kubia.yaml
As a result, kubia application should be running on 3 Pods; those Pods should be deployed on different worker nodes, which are shown below:
Kubia.yaml file exposes the kubia app with the Kubernetes service. The service automatically creates a LoadBalancer on SkyAtlas.
When a connection is made to the service via its Public IP, a random pod will be selected, and then all network packets belonging to that connection are all sent to that single pod. If there’s a new connection that new traffic will go to the next pod.
Now, if you try to reach the application with different connections, every time you try, the next pod on the line will respond.