Feature Overview

Increasingly customers are looking for ways to manage heterogeneous Kubernetes environments. This feature seeks to allow a single set of tools to be used on (m)any K8s platforms to handle lifecycle tasks such as provisioning, upgrades, and patching. It does not seek to offer full cluster management, such as policy and gitops, at this time.

We do not seek to replace provisioning tools native to each platform but instead to offer a simple, open, consistent, lightweight Kubernetes deployment engine for many platforms.

Goals

Providing a way to run the same tooling on most K8s offerings.

Allow an OCM/ACM (MCE) "hub" to run on *KS and conformant (DIY) K8s. 

Provide installation tooling that is easy to use and is supported across K8s platforms for these key components. 

Offer customer platform choice when it comes to running a simplified multicluster management lifecycle solution.

Requirements

This Section: A list of specific needs or objectives that a Feature must
deliver to satisfy the Feature.. Some requirements will be flagged as MVP.
If an MVP gets shifted, the feature shifts. If a non MVP requirement slips,
it does not shift the feature.

(Optional) Use Cases

• Support for MCE on AKS
• Support for MCE on EKS
• Support for MCE on GKE
• Support for MCE on conforment K8s.

Questions to answer

• Should the installer be generic and cross platform or utilise the tools provided by each platform?

Out of Scope

• Full multicluster management from a non-OCP MCE. 

Background, and strategic fit

As a Kubernetes lifecycle management tool MCE is useful regardless of environment. Currently it requires a customer to use OCP, which many prefer to use for workloads and not raw infra requirements. Enabling a simplified MCE deployment for non-OCP clusters would allow for a cheap "infrastructure" cluster to manage from. It would also allow customers who are using non-OCP deployments to easily try OCP and other flavours of K8s more easily without needing to bootstrap the environment - they could simply add it to what they know, build a new environment of something they don't know, and try it out. Good for the community, the projects, and the products.

Assumptions

• We don't make these cause you know what happens to people who do ...

Customer Considerations

• $ Costs to run something small like MCE on a more fully priced platform.
• Onramp costs to learn a new platform to host a provisioning engine - customer want to get this running quickly and then build more useful clusters from it.

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this
  product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have a doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content
  Strategy.
• What concepts do customers need to understand to be successful in
  [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical
  Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or
  Release Note)?