API Groups in Kubernetes
In this tutorial, we are going to discuss about API groups in Kubernetes. Before we head into authorization it is necessary to understand about API groups in Kubernetes.
But first, what is the Kubernetes API? We already discussed about the Kube API Server. Whatever operations we have done so far with the cluster, we have been interacting with the API server one way or the other. Either through the kubectl utility or directly via REST.
Say we want to check the version, we can access the API server at the master nodes address followed by the port which is 6443 by default and the API version. It returns the version.
Similarly to get the list of pods, you would access the url api/v1/pods. Our focus in this tutorial is about these API paths. The /version and /api.
The Kubernetes API is grouped into multiple such groups based on their purpose. Such as one for apis, one for healthz, metrics and logs etc.
The version API is for viewing the version of the cluster. The metrics API and healthz API are used to monitor the health of the cluster. The logs for integrating with third party logging applications.
In this tutorial we will focus on the API is responsible for the cluster functionality. These APIs are categorized into two. The core group and the named group.
Core group
The core group is where all core functionality exists. Such as namespaces, PODs , replication controllers, events, endpoints, nodes, bindings, Persistent volumes, persistent volume claims, configmaps, secrets, services etc.
Named group
The named group API is are more organized and going forward all the newer features are going to be made available to these named groups. It has groups under it for apps, extensions, networking, storage, authentication, authorization certificates etc. Shown here are just a few.
Within apps, you have deployments, ReplicaSets, StatefulSets. Within networking you have network policies certificates have these certificates sign requests that we discussed about earlier.
So the ones at the top are API groups and the ones at the bottom are resources in those groups. Each resource in this has a set of actions associated with them.
Things that you can do with these resources such as list the deployments, get information about one of these deployments, create a deployment, delete a deployment, update a deployment watch a deployment etc. These are known as verbs.
API Reference
The Kubernetes API reference page can tell you what the API group is for each object select an object and the first section in the documentation page shows its group details v1/core is just v1.
You can also view these on your Kubernetes cluster. Access your Kube API server at port 6443, without any path and it will list you the available API groups. And then within the named API groups it returns all supported groups.
A quick note on accessing the cluster API like that. If you were to access the API directly through curl as shown here, then you will not be allowed access except for certain APIs like version, as you have not specified any authentication mechanisms.
So you have to authenticate to the API using your certificate files by passing them in the command line like below
$ curl http://localhost:6443 -k --key admin.key --cert admin.crt --cacert ca.crtKubectl proxy
An alternate option is to start a kubectl proxy client. The kubectl proxy command, launches a proxy service locally on port 8001 and uses credentials and certificates from your kubeconfig file to access the cluster. That way you don’t have to specify those in the curl command.
Now you can access the kubectl proxy service at port 8001 and the proxy will use the credentials from kube-config file to forward your request to the Kube API Server.
$ curl http://localhost:8001 -kAbove command will list all available APIs at root. So hear are 2 terms that kind of sound the same. The Kube proxy and kubectl proxy well they are not the same.
We discussed about kube-proxy earlier in previous tutorials. It is used to enable connectivity between parts and services across different nodes in the cluster.
We discuss about kube-proxy in much more detail in upcoming tutorials. Whereas kubectl proxy is an HTTP proxy service created by kubectl utility to access the Kube API Server.
So what to take away from this? All resources in Kubernetes are grouped into different API groups. At the top level you have core API group and named API group.
Under the named API group You have one for each section. Under this API group, You have the different resources and each resource has a set of associated actions known as verbs in the next tutorial on authorization. We can see how we use these to allow or deny access to users.