First of all, YES! Kubernetes API can be extended.
Kubernetes introduces the concepts of resources, controllers and custom resources/controllers. In brief, resource is an endpoint for storing API objects of a certain kind. Controllers are control loops that watch the state of your cluster. Not sure what it means? check Kubernetes Reconciliation Loop.
Using custom resources help make K8s modular where we can pick the resources needed for our cluster. For example, a core built-in resource is Pod.
Resources can also be called - objects.
The custom resource created is also stored in the etcd cluster with proper replication and lifecycle management.
We can add or remove custom resources using dynamic registration while the cluster is up and running. Once a resource is installed, the user can access it using kubectl (K8s command line) just like they would access the core resource pods:
kubectl get pods
kubectl get {your_new_resource}
In order to create a full declarative API, one will need to add custom controllers as well. This helps us to specify the desired state of the resource and try to keep the current state of K8s objects in sync with the desired state.
We can leverage custom controllers to encode domain knowledge for specific applications into an extension of the Kubernetes API.
There are two main ways to extend the Kubernetes API:
What about a use case?
For example, we might want to introduce our own SSL Configuration information for specific domain, for that we can leverage resources and controllers.
Want to deep deeper and try it for yourself? Check the sample-api server repo.
This was Extending Kubernetes API in under 2 minutes. Learn something new in every bite !
🐦 Happy to take content suggestions, questions and more on twitter.
Top comments (0)