Deploy a multi-master OKD 4.5 cluster using a single command in ~30 minutes

TL;DR;

We will deploy an OKD 4.5 cluster in ~30 minutes (3 controllers, 1 to 10 workers, 1 service, and 1 bootstrap node) using one single command in around 30 minutes using a tool called KubeInit.

The content of this blog post was originally posted in https://www.anstack.com/blog/2020/07/31/the-fastest-and-simplest-way-to-deploy-okd-openshift-4-5.html.

Introduction

What is OpenShift?

Red Hat OpenShift is an open source container application platform based on the Kubernetes container orchestrator for enterprise application development and deployment.

-- https://www.openshift.com/

There are multiple ways of deploying the Community Distribution of Kubernetes that powers Red Hat OpenShift (OKD) depending on the underlying infrastructure where it will be installed. In this particular blog post, we will deploy it on top of a KVM host using Libvirt. The initial upstream support is described in the official upstream OpenShift documentation, but as you can see, it involves a high number of manual steps prone to manual errors, and most important, outdated references when the deployment workflow changes.

In this case, we will use a project based in Ansible playbooks and roles for deploying and configuring multiple Kubernetes distributions, the project is called KubeInit.

Requirements

• RAM, depending on how many compute nodes this can go up to 384GB (the smallest amount required is around 64GB), configure the node's resources in the inventory file.
• Be able to log in as root in the hypervisor node without using passwords (using SSH certificate authentication).
• Reach the hypervisor node using the hostname nyctea, you can change this in the inventory or add an entry in your /etc/hosts file.

Deploy

That's it, now, let's execute the deployment command:

git clone https://github.com/ccamacho/kubeinit.git
cd kubeinit
ansible-playbook \
    --user root \
    -v -i ./hosts/okd/inventory \
    --become \
    --become-user root \
    ./playbooks/okd.yml

You should get something like:

[ccamacho@wakawaka kubeinit]$ time ansible-playbook \
                                  --user root \
                                  -i ./hosts/okd/inventory \
                                  --become \
                                  --become-user root \
                                  ./playbooks/okd.yml

Using /etc/ansible/ansible.cfg as config file
PLAY [Main deployment playbook for OKD] ********************************************
TASK [Gathering Facts] *************************************************************
ok: [hypervisor-01]
.
.
.
"NAME              STATUS   ROLES    AGE     VERSION",
"okd-master-01     Ready    master   16m     v1.18.3",
"okd-master-02     Ready    master   15m     v1.18.3",
"okd-master-03     Ready    master   12m     v1.18.3",
"okd-worker-01     Ready    worker   6m12s   v1.18.3"
]}]}}

PLAY RECAP *************************************************************************
hypervisor-01: ok=83 changed=39 unreachable=0 failed=0 skipped=6 rescued=0 ignored=3   

real 33m49.483s
user 2m30.920s
sys  0m19.678s

A ready to use OKD 4.5 cluster in ~30 minutes!

What you just executed should give you an operational OKD 4.5 cluster with 3 master nodes, 1 compute node (configurable from 1 to 10 nodes), 1 services node, and 1 dummy bootstrap node. The services node has installed HAproxy, Bind, Apache httpd, and NFS to host some of the external required cluster services.

Now, ssh into your hypervisor node and check the cluster status from the services machine.

ssh root@nyctea
ssh root@10.0.0.100
# This is now the service node (check the Ansible inventory for IPs and other details)
export KUBECONFIG=~/install_dir/auth/kubeconfig
oc get pv
oc get nodes

The root password of the services machine is defined as a variable in the playbook, but the public key of the hypervisor root user is deployed across all the cluster nodes, so, you should be able to connect to any node from the hypervisor machine using SSH certificate authentication. Connect as the root user for the services machine (because is CentOS based) or as the core user to any other node (CoreOS based), using the IP addresses defined in the inventory file.

There are reasons for having this password-based access to the services node. Sometimes we need to connect to the services machine when we deploy for debugging purposes, in this case, if we don't set a password for the user we won't be able to log in using the console. Instead, for all the CoreOS nodes, once they are bootstrapped correctly/automatically there is no need to log in using the console, just wait until they are deployed to connect to them using SSH.

Final thoughts

KubeInit is a simple and intuitive way to show to potential users and customers how easy an OpenShift (OKD) cluster can be deployed, managed, and used for any purpose they might require (production or development environments). Once they have the environment deployed then it's always easier to learn how it works, hack it, and even start contributing to the upstream community, if you are interested in this last part, please read the contribution page from the official OKD website.

All the Ansible automation is hosted in https://github.com/ccamacho/kubeinit/.

Please if you like it, add some comments to the project, raise issues, test it, use it, hack it, break it, or become a stargazer ;)