[Suggestion] regular k8s nodes in OpenShift

[sr229]

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.

[jwforres]

@openshift/sig-pod

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[sr229]

/lifecycle frozen