Start by using kubectl’s proxy to make the requests. This avoids having to deal with authentication headers.

kubectl proxy

Test the connection with a basic call.

curl http://localhost:8001/api/

To check the APIs groups available, access the root.

curl http://localhost:8001/apis/

Based on the groups list, you can create the URLs for next requests.

For cluster-scoped resources, use:

• /apis/GROUP/VERSION/RESOURCETYPE
• /apis/GROUP/VERSION/RESOURCETYPE/NAME

For namespace-scoped resources:

• /apis/GROUP/VERSION/RESOURCETYPE
• /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE
• /apis/GROUP/VERSION/namespaces/NAMESPACE/RESOURCETYPE/NAME

To get deployment data, the API Group is “apps”, Version is “v1” and Resourcetype is “deployments”. The final request looks like this:

curl http://localhost:8001/apis/apps/v1/deployments

If the Kubernetes cluster has a metrics-server, the following request will get node resource usage data:

curl http://localhost:8001/apis/metrics.k8s.io/v1beta1/nodes

Rancher users

However, if your cluster has been created using Rancher, you need to have “Authorized Cluster Endpoint” activated, so your requests can reach the API Server directly. If not, your URL paths will differ from the examples above.

On your command line, you will also have to select the correct context for kubectl before activating the proxy.

# List availabe contexts
kubectl config get-contexts

# Select the direct API context
# Its name has the format <cluster_name>-<pilot_name>
kubectl config use-context <direct_context>

Further reading

Overview of the Kubernetes API

More info about API concepts

Accessing the API without kubectl proxy

Full list of Groups, Versions and Resourcetypes