initializing the client
- talk about fromKubeconfig
- KUBECONFIG - `-n <namespace>` - `--kubeconfig <kubeconfig>` - all default auth - would it work inside a pod?
having the client, we can try retrieving the logs of a container of a pod by
given that the client allows us to wrap the roundtripper with one of our own, we can discover what endpoints are used by printing that communication
(yeah, this is somewhat similar to doing a
using the api
kubectl proxy curl ...
from which containers can you get logs from?
- still initializing? can’t
- got the logs reaped alread
what’s a subresource?
how does it work internally?
k8s.io/kubernetes: under “pkg/registry/core/pod/rest/log.go” we can find the
implementation of the handler for the
kubectl /api/v1/pods/namespace/pod/log/contianer? --> the handler for `/log` subresource --> gets inforamtion about the pod --> creates a connection to the kubelet --> /containerLogs/%s/%s/%s (namespace, name, container) (e.g. localhost:8001/api/v1/nodes/kind-control-plane/proxy/containerLogs/default/redis/redis)
(i.e., yeah, the logs come straight from the node, not from a central location)
--previous? how does that work?
naturally, you’re not going to be able to retrieve through
kube-apiserver’s API the logs from system components that don’t run as pods, e.g., kubelet and whatever container runtime you have (e.g., docker / containerd)
seems like the kubelet is able to return (via metrics api) how many bytes are being used for logs (
default logs container annotation