Understanding Kubernetes Extensibility

When Google first released Kubernetes into open source in 2014, the architecture of the container-orchestration platform was designed around a stateless model, meaning that containers did not maintain, for example, state about user session, and they did not natively have access to external storage. In addition, Kubernetes could not interface with external devices such as graphics processing units (GPUs) and networking capabilities were basic. However, Kubernetes enables API access to its core functions allowing them to be extended. 

To address these types of needs, various mechanisms have evolved over time in Kubernetes and have been carried over into Azure Kubernetes Service (AKS), Azure’s managed version. The types of add-ons available include the following:

CLI and API extensions. Kubernetes (and AKS) support extensibility through a wide range of APIs which can include the Kubernetes command-line interface, kubectl, which manages Kubernetes resources. Over 50 such resources are supported out of the box and a “plugin handler” can find and execute extensions, which can be created by developers or downloaded from repositories such as Krew (analogous to a package manager like .NET’s nuget.org). Kubectl plugins can be used for a wide variety of purposes, including interacting with custom resources, viewing cost information, reporting the state of Kubernetes resources, and managing permissions, among others.