concept custom api server in category kubernetes

This is an excerpt from Manning's book Kubernetes in Action. Login to get full access to this book.

In your case, you could create an API server responsible for handling your Website objects. It could validate those objects the way the core Kubernetes API server validates them. You’d no longer need to create a CRD to represent those objects, because you’d implement the Website object type into the custom API server directly.

Registering a custom API server

To add a custom API server to your cluster, you’d deploy it as a pod and expose it through a Service. Then, to integrate it into the main API server, you’d deploy a YAML manifest describing an APIService resource like the one in the following listing.

Listing 18.8. An APIService YAML definition

apiVersion: apiregistration.k8s.io/v1beta1   #1
kind: APIService                             #1
metadata:
  name: v1alpha1.extensions.example.com
spec:
  group: extensions.example.com              #2
  version: v1alpha1                          #3
  priority: 150
  service:                                   #4
    name: website-api                        #4
    namespace: default                       #4

copy

After creating the APIService resource from the previous listing, client requests sent to the main API server that contain any resource from the extensions.example.com API group and version v1alpha1 would be forwarded to the custom API server pod(s) exposed through the website-api Service.