Old legacy applications cannot be containerized easily. However, even from a legacy perspective, it is interesting to explore Kubernetes and its possibilities. But how can we use Kubernetes when our workload consists mostly of monolithic software on virtual machines? And how is the experience with SAP systems in such environments?
KubeVirt Project
One solution for the first problem is the
KubeVirt project from RedHat. It bridges the gap between the old VM world and the new container orchestration experience by providing a so-called
custom resource definition for virtual machines on Kubernetes. That way, we can orchestrate containers and VMs side by side. From a Kubernetes point of view, both are within
pods. So, what exactly are pods?
"Pods are the smallest deployable units of computing that can be created and managed in Kubernetes. […]
A pod (as in a pod of whales or pea pod) is a group of one or more containers (such as Docker containers), with shared storage/network, and a specification for how to run the containers." (from the Kubernetes documentation)
Since the workload within a pod shares network and storage, it could also run jointly on one virtual machine. Hence, the concept of a pod suits also for virtual machines and RedHat enabled the actual use of pods for running VMs.
Our Experience
We installed Kubernetes on virtual as well as on physical machines using Fedora and Ubuntu as operating systems. Both work equally fine. The installation of the KubeVirt addon is a very simple task, described in the
quickstart tutorial which also covers the start of a small CirrOS VM. However, we are interested in running a Windows VM with SAP Netweaver, so these examples are not sufficient for us. But thanks to the immense help from the community, creating a Windows VM is also a straightforward matter.
Our first impression was very good: We were able to add the fresh Windows system to the local domain and to access our internal shares without any problems - a simple thing that we were struggling with when using Windows Containers. But, in contrast to regular virtual machines, the ports of these KubeVirt ones are not accessible by default. That's why we cannot connect to them via remote desktop connection - even if RDP is activated in the Windows system settings. To change this, we must forward the corresponding port (here 3389 for RDP) on the host machine. Only then, we can access the VM via the forwarded port of its host machine.
For testing, we installed a traditional SAP Netweaver system with SQL server. The installation went smoothly - just as one would expect from a "regular" virtual machine. We challenged the VM by using a common test tool to put load on the SAP system. All of it went well and we achieved equivalent results compared to our usual VMs.
There was only one disadvantage we noticed: It was not possible to access the SAP system from another machine. This is caused by the forwarded ports which unfortunately do not fit together with the SAP Logon application. However, this might be solved with
KubeVirt version 0.8.0 which enables having multiple network interfaces. With that, we should be able to access KubeVirt VMs just as normal VMs - without any port forwarding.
Conclusion
KubeVirt is a great project for combining Kubernetes and virtual machines. We observed great stability and performance and, most importantly, awesome support from the KubeVirt community! Thanks again to Fabian Deutsch who helped us launch Windows VMs.
If you are interested in sharing experiences, please get in touch with us.
