Introduction to HostedClusters

Agenda

• What is Hypershift?
• Why Hypershift?
• Concepts
• Providers
• HostedClusters Management
• Separation ControlPlane/DataPlane
• Networking Internals
• Main Objects and APIs
• Demos
• References

What is Hypershift?

• Middleware to host multiple Openshift Clusters into another Openshift Management cluster
• Installed as an operator, but not a regular one with OLM.
• We have a CLI!
• Cross cloud compatibility

What is Hypershift?

HostedClusters are fully compliant as regular Openshift, with some small differences:

• No masters from HostedCluster user PoV
• No self awareness (A HC does not know that is a HostedCluster)
• A final user only will see workloads, no ControlPlane things
• A HostedCluster Control Plane runs in a separated Namespace in the Management Cluster

Why Hypershift?

• Less time to provision.
• Less cost for the customer.
• More security, decoupled Control plane and Data plane.
• Also no direct communication from HostedCluster to Management cluster.
• Enable segregation of ownership and responsibility for different personas.

Concepts

• Management Cluster: Openshift cluster which holds HostedClusters
• Hosted Cluster: Openshift cluster for the final customer (Stored in a separated NS)
• Hosted Control Plane: Openshift Control Plane for the HostedCluster (Stored in a separated NS)
• Hosted Control Plane Infrastructure: Infra created in the external provider
• Management Cluster Infra: Infra dedicated for the Management cluster in the external provider
• HostedCluster Infra: Infra dedicated for the HostedCluster in the external provider

Providers

Focus on:

• AWS
• Bare Metal

For Later:

• Azure
• Assisted Installer
• Kubevirt
• PowerVS
• None

HostedCluster Management

We have 3 topics here:

• Upgrades - Control Plane and Data Plane
• MachineConfigs
• Tuned Config

In general this kind of managment topics are ruled by the SRE or Openshift Management Cluster people

HostedCluster Management: Upgrades

Support policy of 2 versions back.

Control Plane: To perform the upgrade it's matter of edit the HostedCluster CR

  release:
    image: quay.io/openshift-release-dev/ocp-release:4.13.0-ec.2-x86_64

Data Plane: To perform the upgrade it's matter of edit the NodePool/s CR

  release:
    image: quay.io/openshift-release-dev/ocp-release:4.13.0-ec.2-x86_64
  replicas: 2

• InPlace: Mostly for Bare Metal servers and involves a server restart and apply of the new ignition config.
• Replace: Mostly for Cloud providers. Involves a creation of new instance to replace the older one.

HostedCluster Management: MachineConfigs

In order to apply a MachineConfig we will differ a bit from the tipical OCP approach because we don't have any MachineConfig Operator. More info here:

• Create a ConfigMap in the same NS as the HostedCluster CRs are located

  config: |
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: config-change-01
    spec:
      config:
        ignition:

• Edit the NodePool:

spec:
  config:
    - name: config-change-01

HostedCluster Management: Tuned

In order to apply a Tuned configuration we follows the same procedure as MachineConfig. More info here:

• Create a ConfigMap in the same NS as the HostedCluster CRs are located

data:
  tuning: |
    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      name: tuned-1
      namespace: openshift-cluster-node-tuning-operator
    spec:
      profile:
      - data: |

• Edit the NodePool:

  tuningConfig:
    - name: tuned-1

Separation ControlPlane/DataPlane

Features:

• For security, multiple customers could use the same Management Cluster without know about the other ones.
• We can perform an upgrade of the ControlPlane without affect the NodePool versions, then the customer workloads will not be affected
• The customer cannot communicate with the Management Cluster, only the HostedCluster one.
• The HostedCluster nodes will only run customer workloads and some pods to allow the communication with the KAS.
• The customer will not be allowed to modify the Hypershift CRs (HostedCluster or NodePools)

Networking Internals

Networking Internals

Hosted ControlPlane and Data plane will use Konnectivity to establish a tunnel for communications from KAS to Computes and works as follows:

• The Konnectivity agent in the compute nodes, connects with the server in the Hosted ControlPlane establishing a tunnel
• The KAS will use that tunnel to communicate with the compute nodes
• The compute nodes will use an “Exposed Service” (AWS: KAS Load Balancer) to reach the Hosted Cluster API
• The Hosted Controlplane will consume the OLM, Oauth, Openshift API using Konnectivity server-agent which could reach the services located in the Management cluster

The diagram shows an agnostic approach, but for example, if you deploys a HostedCluster in AWS, the “Exposed Services” are AWS Load balancers. That means that in every platform we deploy we will maintain the same core pieces.

Main Objects and APIs

• NodePool - Inplace
• NodePool - Replace
• HostedCluster
• MachineConfig Patches
• Node Tuning
• Official Doc

Demos

• AWS
• Assisted Installer
• Kubevirt
• Live Demo by Lucas!

References

• Official Doc
• CRs and Snippets
• Jira
• Getting Started

Questions?

Thanks!