I have a question to the Mainframe Linux community that is interested in running Kubernetes on the Mainframe.
As most of you are probably aware, the standard Kubernetes requires three master nodes, that should be in independent environments for availability reasons. At least from what I know, most Mainframe shops with a GDPs setup have just two synchronous sites, and therefore cannot directly fulfill that requirement. To my knowledge, the following options exist to solve this in case of desaster:
a) Utilize z/OS methods to restart the missing master nodes on the remaining site
b) Rely on external Kubernetes management like x86 to run the master nodes and just have worker nodes on s390x (openshift solution)
c) Use k3s as Kubernetes solution with an external highly available database to be able to run with just 2 master nodes
Is there more options available that I am not aware of?
Method a) would mean, you don’t rely on Kubernetes built in availability functionality, and you might just as well run with a single node cluster
Method b) looks like a good working solution if you are prepared to run openshift in multiple environments
Method c) seem the natural solution to me, however they just removed s390x support, and I wonder if that is because nobody knew about this option, or if there are other reasons. For more information about that, see Please readd s390x support · Issue #9222
regarding b) on Mainframe OpenShift can be installed as an Multi-Arch Cluster on X86 and have nodes on IBM Z but this is not an required setup. depending on which environment you install your cluster KVM / zVM / zCX multiple solutions are available. Your solution a) points to zCX running either kubernetes / OpenShift on that plattform.
For distributed platforms like KVM / zVM if decided to have a stretched cluster which is crossing the sites, you might pre-pare in case of an desaster anyway a concept to allocate enough resources to get the compute nodes backup on the other side. Therefore for control nodes, it is the same way to have replica of your guest disks on the second side and reboot the control nodes (and compute) to be back in operation or re-install control nodes, since those are re-integrate and re-sync the etcd database.
For distributed platforms like KVM / zVM if decided to have a stretched cluster which is crossing the sites, you might pre-pare in case of an desaster anyway a concept to allocate enough resources to get the compute nodes backup on the other side.
Yes, this is a requirement
Therefore for control nodes, it is the same way to have replica of your guest disks on the second side
Typically you would have the same disks from the same storage. The main requirement would be that it is always the same control node, and that node must only exist once.
and reboot the control nodes (and compute) to be back in operation or re-install control nodes, since those are re-integrate and re-sync the etcd database.
Yes, and no. Yes, it makes it easy to recover from an outage, however the Kubernetes builtin high availability mechanisms are not used during desaster. It would be the same to have just a single node kubernetes that is restarted on the other side with the same disk set.
Considering that the HA feature of kubernetes requires a three node cluster and has considerable overhead with regards to CPU and Memory requirements, I wonder where the advantage of having a fully built Kubernetes is to be seen.