Kubernetes extensibility story keeps on getting bigger and bigger. Kubernetes extensions can be categorized into 4 categories: Kubernetes Operators, Admission Controllers, Scheduler plugins, CLI plugins. Every KubeCon has a dedicated track for extensibility related topics. KubeCon NA 2020 also had a good coverage on these categories through their track on Customizing and Extensibility. It had talks on Operators, scheduler plugins and admission controllers. While this track is the primary place for extensibility related talks, occasionally you also find some interesting talks on extensibility in the Application + Development track.
Based on activities at KubeCon NA 2020, here are our 3 takeaways on the current trends in Kubernetes extensibility space:
- Operator/CRD adoption continues to grow:
Operator/CRD as a mechanism to package an application in cloud native manner is a standard practice now. You can see that by observing the growing list of CNCF projects where a lot of these projects are designed using the Operator pattern. Canonical hosted Open Operator day on the first day of Kubecon. CloudARK had a session on Being a Good Citizen of the Multi-operator World.
2. There is lot of interest in admission controllers:
Admission controllers enable establishing control on Kubernetes resources at the time of resource creation using certain policies. While we see two community projects, OPA (incubating) and Kyverno (sandbox), offering general purpose admission controllers, recent KubeCons have had talks covering how to write an admission controller from scratch. This indicates that the knowledge to build admission controllers is considered important, which makes sense as admission controllers offer platform teams a way to govern resources being created by the cluster users.
3. Community is exploring customizing Kubernetes scheduler for specific use cases:
We saw talks at KubeCon NA 2020 on building scheduler plugins that serve requirements of specific use-cases e.g. SuperComputing, Machine Learning, etc. The pluggable scheduling architecture makes it possible to add your custom plugins to the Kubernetes scheduler. We believe there will be more industry and use-case specific customizations in this space in future.
Today, every Kubernetes cluster out there is essentially a custom platform consisting of extensions coming from various sources — those packaged by Kubernetes distributions, community extensions supporting required workloads, or extensions written by the enterprise internal platform teams. Often the common element of the variety of extensions is that they add new Custom Resources / APIs to a cluster. Platform engineering teams managing these extended Kubernetes environments need to invest in tools that help them gain control over these Custom Resources / APIs.
Check out Platform-as-Code to learn more about how platform engineering teams can govern and monitor their extended Kubernetes environments.