Why is the Kubernetes API service in the default namespace even though the kube-apiserver pod runs in kube-system?

In Kubernetes the Service object that provides a stable API endpoint is created in the default namespace by design. Even though the kube-apiserver itself runs as a static pod in the kube-system namespace, the Service (often called "kubernetes") is placed in the default namespace so that client Pods and applications can easily discover and use the well-known DNS name (kubernetes.default.svc.cluster.local).

This separation provides several benefits:

• Stable Cluster DNS: The "kubernetes" Service in the default namespace has a known DNS record that other components can use to reliably access the API server. This is part of the core abstraction that Kubernetes builds into the cluster networking.
• Decoupling Implementation from Access Point: The actual location (namespace) where the kube-apiserver pod runs is independent from where its Service is defined. This decoupling lets the API server be restarted, scaled, or migrated without changing the consistent endpoint that clients refer to.
• Convention and Consistency: It’s a long-established convention. By having the API server Service in the default namespace, a standard and predictable configuration is maintained across clusters.

Thus, while the control plane components (including the kube-apiserver pod) are deployed in the kube-system namespace, the API Service is created in the default namespace to serve as a standard discovery mechanism for API requests.