Skip to content

Instantly share code, notes, and snippets.

@alecmerdler

alecmerdler/proposal.md

Last active March 2, 2019 20:31
Show Gist options
  • Save alecmerdler/9a798afe06f46090231007f32b2a9512 to your computer and use it in GitHub Desktop.
Save alecmerdler/9a798afe06f46090231007f32b2a9512 to your computer and use it in GitHub Desktop.
Download ZIP
Extending Kubernetes using OLM
Raw
proposal.md

You Might Not Need a Custom UI

Red Hat has fully adopted the CoreOS vision of running applications by extending Kubernetes (rather than building on top using existing primitives). Operators use "provided APIs" (CRDs/apiservers) to give users a way to declaratively manage their apps. Now you can interact with your services and have the same experience as using the aws or gcloud command-line tool, because everything lives in the Kubernetes API. You have extended Kubernetes. The Operator Lifecycle Manager (OLM) is a comprehensive framework for resolving, installing, and upgrading these extensions in the same declarative way.

The OpenShift Console is a frontend for the Kubernetes API. Each list/detail view has an equivalent kubectl get (uses the raw REST endpoints). Naturally, the UI provides a lot of advantages over CLI: aggragating resources into a single view, hyperlinks to related views, cluster-aware autocompletion for YAML editor, etc). The goal of the original project (Tectonic Console) was summarized as pretty kubectl, and that has made the project simple to develop, debug, and use from an admin standpoint.

The OpenShift is becoming a monolithic frontend; teams are free to develop individual backend APIs (Operators), but they all converge at the single frontend. This is already scaling poorly in terms of development velocity, codebase size, bug fixing, testing, onboarding of new teams, and more. Fortunately, OLM provides a solution: each Operator is packaged with details of the APIs it provides, including descriptors for the spec and status fields. The OpenShift Console then reads these descriptions and renders a dynamic UI for the API.

Advantages

  • Consistent look-n-feel for interacting with every Operator's APIs
  • New Operators get UIs without touching openshift/console codebase at all (just applying descriptors to their CSV)
  • Testing is simplified: unit/e2e tests for individual descriptor components rather than full suites for the extension
  • Easy to support multiple versions of Operators (no need to hardcode apiVersion)

It's understandable that each team has ideas of the best UX for their service, but if your public API (CRDS) doesn't make sense without a complex frontend abstraction, your backend design may be off. You should start with basic CRUD views that the OLM descriptor model supports, and build a separate frontend if you need more abstraction.

Work Needed

  • More spec/status capabilities and associated React components
  • Introduce action descriptors, which are shortcuts to modifying some custom resource fields (kebab menu, modal, etc)
  • Dynamic forms for creating CR instances utilizing descriptors + API validation
  • Add ability to specify columns and sort fields for list views
  • Represent relationships between different "provided APIs" (ex. many EtcdBackups for an EtcdCluster)
  • Improve docs + contribution workflow for capability components for non-RH teams to make great UX for their Operators
  • Ability to promote certain APIs out of "Installed Operators" (sidebar, etc)
  • Ultimate goal: model "core" resource views using this framework (package k8s controllers as ClusterServiceVersions with "provided APIs") and remove components from codebase

Summary

  • We as a company have decided that extending Kubernetes happens using Operators.

  • The OpenShift Console is just a representation Kubernetes resources ("pretty kubectl")

  • OLM is the extension framework for Kubernetes

  • It also provides "descriptors" which let you describe aspects of the CRDs for your Operator

  • These "descriptors" can each have an associated React component in openshift/console

  • Instead of teams adding full list/detail/form views for their Operator, just package with OLM and get a UI for free using the existing code that the OLM team maintains

  • If you need new specific UI components that reflect fields in your custom resource, then you have a clear contribution workflow

  • For anything else, you will build your own webapp where you have more freedom and we can link to it in from the OpenShift console

  • By using a single extension mechanism, we will save an enormous amount of engineering effort from not having to track down bugs, skew between console/Operator versions, etc

  • NOTE: This doesn't solve 100% of extensibility product requirements, but it does address majority of Operator-based extensions that need UI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment