Log and Binary files location

Let's categorize the critical file system locations you need to know for operations, debugging, and security auditing. We can divide these into Binaries/Executables, Configuration & State, and Logging Directories.

The locations below primarily reflect standard Linux deployments (like those built with kubeadm), though I will note Windows paths where relevant.

1. Binaries and Executables

These are the static files required to bootstrap and run the node components.

• Core Kubernetes Binaries:
  • Location: /usr/bin/
  • Components: This typically includes kubeadm, kubelet, and kubectl.
  • Context: The kubelet is the primary node agent that must run directly on the host (usually via systemd), while kubectl and kubeadm are CLI tools.
• CNI Plugins (Container Network Interface):
  • Location: /opt/cni/bin/
  • Components: Network binaries like bridge, flannel, calico, or loopback.
  • Context: The container runtime looks here for the executables required to set up pod networking,.
• Container Runtime Interface (CRI) Tools:
  • Location: /usr/bin/ or /usr/local/bin/
  • Components: crictl (the CLI for CRI-compatible runtimes),.

2. Configuration, Certificates, and State

This is the "brain" of the node. These directories contain the identity of the cluster and the definition of what should be running.

• Static Pod Manifests:
  • Location: /etc/kubernetes/manifests
  • Purpose: The kubelet periodically scans this directory. Any YAML file found here is launched as a Static Pod.
  • Engineering Note: In kubeadm clusters, this is where the Control Plane components (API Server, Controller Manager, Scheduler, and sometimes etcd) live.
• PKI and Certificates:
  • Location: /etc/kubernetes/pki
  • Purpose: Contains the Certificate Authority (CA), API server certificates, and service account keys.
  • Security: This directory is highly sensitive. Compromise here equals total cluster compromise.
• Kubeconfig Files:
  • Location: /etc/kubernetes/
  • Files: admin.conf, kubelet.conf, controller-manager.conf, scheduler.conf.
  • Purpose: These define authentication/authorization context for the core components.
• Kubelet State and Config:
  • Location: /var/lib/kubelet
  • Files: config.yaml (downloaded cluster-wide config), kubeadm-flags.env (runtime flags).
• Etcd Data (Database):
  • Location: /var/lib/etcd
  • Purpose: The persistent storage for the etcd key-value store on control plane nodes.

3. Logging Locations

Logging architecture depends heavily on your OS and initialization system (usually systemd).

• Pod/Container Logs:
  • Location: /var/log/pods
  • Mechanism: The container runtime writes stdout/stderr streams here. The kubelet makes these available to kubectl logs.
  • Warning: Do not change this path lightly; many system processes imply this specific path.
• System Component Logs (Systemd):
  • Location: journald
  • Access: Use journalctl -u kubelet or journalctl -u containerd.
  • Context: On modern Linux nodes using systemd, the kubelet and container runtime write to the journal rather than a static file.
• System Component Logs (File-based/Legacy):
  • Location: /var/log/
  • Files: /var/log/kubelet.log, /var/log/kube-apiserver.log, /var/log/kube-scheduler.log,.
  • Context: This is common on systems without systemd or in specific cloud provider configurations.
• Windows Logs:
  • Location: /var/log/
  • Context: Similar to Linux, you may find logs in /var/log/ or via the application log provider.

Summary Table

Component	Path	Description
Manifests	/etc/kubernetes/manifests	Static Pod definitions (Control Plane).
Certificates	/etc/kubernetes/pki	TLS certs and keys (CA, API Server).
Kubeconfigs	/etc/kubernetes/	Auth files for system components.
Pod Logs	/var/log/pods	Stdout/Stderr from running containers.
CNI Binaries	/opt/cni/bin/	Network plugins (e.g., bridge, flannel).
Kubelet	/usr/bin/kubelet	The primary node agent binary.