Transcript
Hello and welcome to the OpenEBOLA Kubernetes Service Screencast. In this screencast, we will walk through the KHS deployment using the new 1KS service available in 7.2.1. OpenEBOLA leverages Cluster API to provision and manage Kubernetes clusters. Cluster API was firstly introduced in OpenEBOLA 7.0 and now is heavily used by 1KS. Unlike 1KE that was relying on one flow service, 1KS is available directly in Sunstone as a separate tab. This tab is fully dedicated to the purpose of running and managing Kubernetes clusters on top of OpenEBOLA. To use this new functionality, you must install the OpenEBOLA-KS package. For now, it's only available in the Enterprise Edition repository. The service must be installed and started. Before starting the service, it is mandatory to configure tproxy for 1Gate. If it's not configured, OpenEBOLA-KS service will detect it and will fail to start. Please refer to the official OpenEBOLA documentation for step-by-step instructions to configure and enable tproxy. To access Kubernetes Management, open the Kubernetes KHS Cluster tab. All provisioned clusters are listed here. Currently, there are no clusters, so the list is empty. Let's start by creating one. Press the Create button to initiate the wizard. Give your cluster a name and optionally a description. Now select a public network. This must be a routable network. For this demonstration, the routable network is named EVPN0. Next, select a private network. It may or may not be connected to the internet. Then, select the Kubernetes version for this cluster. Let's proceed with the latest available. Lastly, we must decide whether this cluster is a single node or HA deployment. In an HA setup, three control plane nodes are deployed instead of one. For this demonstration, we will proceed with a single node deployment. Press Finish to start provisioning the cluster. First, a specific virtual machine called the seed VM will be deployed. This virtual machine handles the cluster build and then performs a pivot to the actual control plane. After that, the seed VM is destroyed. During deployment, you can monitor the progress using the Logs tab. If any errors occur, this is the first place to check. Once the control plane is running, you can extract kube-config by simply navigating to the kube-config tab. By looking at the Instances VMs tab, we can find two virtual machines, the control plane and the virtual router. To run workloads, we must deploy a node group, which is a set of worker VMs. Under the Node Group tab, press the Add Node Group button. Give this node group a name. The value supplied here will become part of the virtual machine names. Then, select the size of your worker nodes. Currently, we have small, medium, and large worker nodes with their respective configuration. For this demonstration, we will proceed with small nodes. Verify that the size meets your needs and then set the number of nodes to two. Then, press Finish. The cluster now enters the scaling state. In the logs, you can see that deployed virtual machines are now joining the cluster. You can also find the virtual machine IDs there. Switching back to the VMs view, we see two virtual machines that are named Test App. Once the cluster returns to the running state, let's extract the kube-config and switch to the command line. Create the config file under your home directory .kube-config and paste the contents from your clipboard. Once saved, let's verify connectivity by running kubectl get pods nodes. There are no pods right now. However, we can confirm we are connected to the correct cluster by looking at the node names. The Test App prefix is present. Now it's time to deploy an application and verify that the cluster can handle the workload and expose it using a load balancer service. The test application YAML files were uploaded beforehand. It's a simple web-based application with a SQL-based backend that creates a schema and then writes and reads data, perfect for testing connectivity between pods and exposure via a load balancer. Simply execute kubectl apply –f and then put the dot to pick up YAML files from the exact same directory. Based on the output, we can confirm that the deployments and services have been created. Switch to the virtual machines view in Sunstone. We can locate a new virtual machine with the ID 9. This is a virtual router deployed because we requested a load balancer service. This appliance handles routing traffic from the routable network to the exposed service. Back to the command line, let's extract the external IP address of the load balancer so we can reach our application. As we can see, the web application is exposed and reachable. First, let's create the database schema. The schema was created without errors, meaning the application pod can communicate with the database. Now let's write data to the database. We will perform this action a few times to generate some entries. Our final test is to read the data from the database. As seen on the screen, the read was successful. The application has fulfilled its task and can be destroyed by executing the kubectl delete command. We can see confirmation that the resources were successfully deleted. Switching back to the virtual machines tab in Sunstone confirms that the virtual router with the virtual machine ID 9 is also gone. This proves that the resources are managed automatically by 1KS, requiring no manual interaction. And this concludes the screencast where we have shown the 1KS service that simplifies deployment and consumption of Kubernetes on top of OpenAbyllu. Thank you for watching and see you in the next screencast.
