When Kubernetes was first developed, many deployments used systemd to manage control plane components (like kube-apiserver, kube-controller-manager, etc.). This made sense because systemd was the standard way to manage services on Linux systems.
Static pods are pods that are managed directly by the kubelet on a specific node, not by the Kubernetes API server. The kubelet watches a specific directory (typically /etc/kubernetes/manifests/) for YAML files that define pods. Any pod defined in this directory will be automatically created and monitored by the kubelet.
Why is Systemd Considered Legacy?
Separate Management Plane: When using systemd, you need to manage control plane components differently from other Kubernetes workloads, requiring separate tooling and processes.
OS Dependency: Systemd ties your Kubernetes deployment more closely to the host operating system, making it harder to create portable, consistent deployments.
Manual Configuration: Systemd service files require more manual configuration and can be more error-prone than the declarative YAML used for static pods.
Less Isolation: Services running directly on the host have less isolation than containerized components.