Transcript
Center Cloud Edge Continuum screencast. In this screencast, we will walk through the Distributed Kubernetes lifecycle management on OpenAbula. The goal is to show how 1KS, the OpenAbula Kubernetes service, can create, manage, and validate Kubernetes clusters across different infrastructure locations, from an on-premises data center to a cloud or edge environment. The demonstration focuses on a practical scenario, using a single OpenAbula deployment to manage Kubernetes clusters across two hypervisor hosts, creating one cluster through Sunstone, another through the 1KS command-line interface, and validating the result by deploying an NGINX workload. By the end of the screencast, we will have shown how OpenAbula and 1KS simplify Kubernetes consumption across distributed infrastructure while keeping cluster lifecycle operations under a single service model. Distributed applications increasingly need infrastructure that spans the data center, the cloud, and the edge. This is not only a matter of capacity. It's also about performance, locality, operation consistency, and the ability to place workloads close to where they are needed. The challenge is that these environments are often heterogeneous and operationally fragmented. Operators may need to provision clusters in different locations, manage workload capacity, retrieve access credentials, validate readiness, and keep the configuration consistent over time. Doing this manually increases operation complexity and rises the risk of configuration drift. 1KS addresses this by providing Kubernetes lifecycle management as an OpenAbula service. It is built on RKE2 and integrates with ClusterAPI through CAP1, OpenAbula's cluster API provider. This allows operators to create and manage Kubernetes clusters on top of OpenAbula infrastructure using a structured and repeatable workflow. In this demonstration, we validate the approach by deploying an NGINX workload on the cloud cluster, confirming that the cluster can schedule and serve applications correctly. Here we can find the role of 1KS inside the OpenAbula stack. At the bottom, OpenAbula provides the infrastructure layer. It manages the underlying fertile machines, bare metal resources, and infrastructure abstraction. Above that, 1KS provides the managed Kubernetes layer. It turns infrastructure capacity into a ready-to-use Kubernetes cluster. At the top, users can run their cloud-native applications, AI workloads, and other containerized services without having to manage all the underlying provisioning details manually. Instead of asking operators to assemble Kubernetes clusters from low-level primitives every time, 1KS provides a service-oriented lifecycle model for creating, accessing, scaling, upgrading, recovering, and retrieving clusters. 1KS provides the core lifecycle operations required for Kubernetes management on distributed OpenAbula infrastructure. The first capability is cluster scaling. Operators can adjust cluster capacity as workload demand changes. The second capability is HA-ready deployment. At deployment time, users can choose whether the cluster should be created in a high availability or non-high availability configuration. The third capability is cluster upgrades. Cluster nodes can be updated without requiring a full rebuild from scratch. The fourth capability is basic recovery. 1KS provides mechanisms to recover from common operational issues without forcing operators to manually recreate the whole cluster. Together, these capabilities move Kubernetes management away from one-off provisioning and towards a controlled lifecycle model. The demo uses a single OpenAbula deployment managing two hypervisor hosts across distributed infrastructure. Host O represents the on-premises data center location. This is the local infrastructure location where the first 1KS cluster is deployed. Host 1 represents the cloud or edge location. This is the remote infrastructure location where the second 1KS cluster is deployed. The demo follows two operational workflows. First, we create a Kubernetes cluster from Sunstone, OpenAbula's graphical UI. Second, we create another Kubernetes cluster through 1KS command-line interface. After both clusters are created, we retrieve the kubectl check cluster readiness and deploy an NGINX workload on a cloud cluster. That NGINX deployment is the validation step. It proves that the cluster is not only created but actually able to schedule and serve an application. From Sunstone, we can see both hypervisor hosts registered in OpenAbula, each one with a different pool of resources in terms of CPU and memory. Before creating the first cluster, we configure 1KS placement so that the control plane and the worker nodes are scheduled on host 0. This represents deploying a Kubernetes cluster in the on-prem location. This placement step is currently performed from the configurational layer. In future versions, the workflow can be improved to make location selection easier for users. Now, we create the first 1KS cluster from the Sunstone web UI. We select the Kubernetes version, the public and private networks, and the control plane flavor. Once submitted, 1KS starts provisioning the required infrastructure. After a few moments, the cluster reaches the running state. We can verify that the control plane virtual machine has been created and is running on the on-premises host. Next, we add worker capacity by creating a node group from the cluster view. We retrieve the kube-config and validate the cluster with kubectl. Now, we switch the placement configuration to host 1, which represents the cloud or Azure location. This allows us to deploy a second Kubernetes cluster in a different infrastructure location managed by the same Openable environment. For the second cluster, we use the 1KS CLI to show the interactive deployment flow. The CLI asks for the cluster name, Kubernetes version, control plane flavor, public network, and private network. Once the second cluster is running, we add a node group from the command line and select the worker flavor and a node count. This demonstrates the same 1KS lifecycle operations through the command line interface. Before the final validation, we deploy a simple workload in the cloud or edge cluster to confirm that the Kubernetes cluster is not only provisioned but also able to run applications. Once the pod is created, we check that it reaches the running state. Then expose the pod as a Kubernetes service. To validate in-cluster connectivity, we launch a temporary curl pod and send a request to the engine service. A response code 200 confirms that the workload is running, the service is reachable, and the cloud or edge cluster can schedule and serve a basic application. This screencast was developed in the scope of EAP-SciS project. Thank you for watching and see you in the next screencast.
