[Suggestion] regular k8s nodes in OpenShift #19255

Synopsis

OpenShift builds from Kubernetes. However, since oc already runs openshift/origin in a Docker container, then it might be possible to federate/include existing k8s nodes as OpenShift Nodes.

Introduction

OpenShift and Kubernetes has known to co-exist since OpenShift v3. OpenShift contributes back to Kubernetes as they develop features in their own distribution. Kubernetes itself is a container orchestration tool while OpenShift builds upon this and adds Container-as-a-Service/Platform-as-a-Service features. Origin has a oc CLI that deploys the openshift/origin container. Since it runs on regular Docker, then it might be possible to use it to provide OpenShift features to a existing K8s cluster.

Purpose

This feature request serves at least two purposes:

• Allowing end-users to use OpenShift features on regular Kubernetes clusters.
• Provide end-users that used Kubernetes to have a easy migration scheme by "polyfilling" on regular k8s nodes to be a pseudo-OpenShift cluster until they have switched to OpenShift.

Strategy

OpenShift needs to consider at least two situations to include a Kubernetes node as part of its cluster.

Situation 1: Joining as Worker

if a K8s node is joining to a OpenShift cluster:

• Check if it meets the minimum Kubernetes version set by the cluster admin
• Install necessary services in the node in kube-system namespace.
• Include it in the cluster once it passes health checks.

Situation 2: Joining as a cluster with a manager node

• Manager Node might have to be switched to a worker node. This would consider the host node it tries to connect to as a Manager.
• Install necessary service in the node in kube-system namespace.
• Include the cluster once it passes health checks.

Benefits

• It would allow provisioning of OpenShift to providers that only supports Kubernetes (ie, IBM Cloud).
• It would let the users consume OpenShift Nodes and Kubernetes Nodes together.

Drawbacks

• Because of Situation 2, if you run any essential service within the manager node, it might not work at all within the migration process.
• There would be no known possible strategy to revert it to its last known state once connected to the OpenShift manager node.

I accept feedback regarding this proposal, if you find any discrepancies or some ideas need to be deliberated properly, please do tell me.