A Kubelet has several endpoint paths it listens on, such as /metrics
, /metrics/cadvisor
, /logs
, etc. One can easily query these endpoints by running kubectl get --raw /api/v1/nodes/<node-name>/proxy/<path>
(after running kubectl proxy
).
My question is how can one obtain the list of all these paths that Kubelet is serving? A list can be found in the Kubelet's own code here, but that's just a subset. There's for example /pods
which is not on that list, but defined further down in the code as well. But there are others that aren't explicitly listed in the code, such as /healthz
, which one guesses by looking at other lines of the code. I'd also venture to believe that other addons or 3rd party products could result in the Kubelet exposing more paths.
I tried using /healthz?verbose
, but it only returns basic information, and nothing near a list of paths:
[+]ping ok
[+]log ok
[+]syncloop ok
healthz check passed
The Kubernetes API Server returns a very nice list of paths using kubectl get --raw /
as seen below (truncated due to length). Is there something equivalent for Kubelet's own paths?
{
"paths": [
"/.well-known/openid-configuration",
"/api",
"/api/v1",
"/apis",
"/apis/",
"/apis/admissionregistration.k8s.io",
"/apis/admissionregistration.k8s.io/v1",
"/apis/admissionregistration.k8s.io/v1beta1",
"/apis/apiextensions.k8s.io",
"/apis/apiextensions.k8s.io/v1",
"/apis/apiextensions.k8s.io/v1beta1",
"/apis/apiregistration.k8s.io",
"/apis/apiregistration.k8s.io/v1",
"/apis/apiregistration.k8s.io/v1beta1",
"/apis/apps",
"/apis/apps/v1",
"/apis/authentication.k8s.io",
"/apis/authentication.k8s.io/v1",
"/apis/authentication.k8s.io/v1beta1",
"/apis/authorization.k8s.io",
"/apis/authorization.k8s.io/v1",
"/apis/authorization.k8s.io/v1beta1",
"/apis/autoscaling",
"/apis/autoscaling/v1",
"/apis/autoscaling/v2beta1",
"/apis/autoscaling/v2beta2",
"/apis/batch",
"/apis/batch/v1",
"/apis/batch/v1beta1",
"/apis/certificates.k8s.io",
....
Based on the information from different sources, below provided some endpoints for kubelet.
From the code of kubelet server:
/metrics
/metrics/cadvisor
/metrics/resource
/metrics/probes
/stats/
/logs/
/debug/pprof/
/debug/flags/v
also:
/pods/*
and:
/run/*
/exec/*
/attach/*
/portForward/*
/containerLogs/*
/configz
/runningpods/
here:
"/attach/{podNamespace}/{podID}/{containerName}": "proxy",
"/attach/{podNamespace}/{podID}/{uid}/{containerName}": "proxy",
"/configz": "proxy",
"/containerLogs/{podNamespace}/{podID}/{containerName}": "proxy",
"/debug/flags/v": "proxy",
"/debug/pprof/{subpath:*}": "proxy",
"/exec/{podNamespace}/{podID}/{containerName}": "proxy",
"/exec/{podNamespace}/{podID}/{uid}/{containerName}": "proxy",
"/healthz": "proxy",
"/healthz/log": "proxy",
"/healthz/ping": "proxy",
"/healthz/syncloop": "proxy",
"/logs/": "log",
"/logs/{logpath:*}": "log",
"/metrics": "metrics",
"/metrics/cadvisor": "metrics",
"/metrics/probes": "metrics",
"/metrics/resource": "metrics",
"/pods/": "proxy",
"/portForward/{podNamespace}/{podID}": "proxy",
"/portForward/{podNamespace}/{podID}/{uid}": "proxy",
"/run/{podNamespace}/{podID}/{containerName}": "proxy",
"/run/{podNamespace}/{podID}/{uid}/{containerName}": "proxy",
"/runningpods/": "proxy",
"/stats/": "stats",
"/stats/summary": "stats"
The asterisk indicates that full request should be updated with some parameters. For example for /containerLogs/*
with adding /{podNamespace}/{podID}/{containerName}
:
kubectl get --raw /api/v1/nodes/<node-name>/proxy/containerLogs/{podNamespace}/{podID}/{containerName}
Some information from kubernetes site about kubelet API:
/stats/*
/metrics/*
/logs/*
/spec/*
Also you can look at this page from kubeletctl. It's a bit outdated, but may provide some useful information about the kubelet API and HTTP requests.
And this article about the kubelet API is good too.
In any case, it is recommended to check the kubernetes documentation before using it to see what is deprecated in current / old releases.
p.s. If you are interested in this topic, you can create an issue on kubernetes GitHub page to propose an improvement for kubelet documentation.