2.13 Kubernetes Addon Architecture
Kubernetes Addon Architecture extends Kubernetes' core with modular components for observability, networking, and management in containerized environments.
Kubernetes Addon Architecture is the specific arrangement by which cluster-wide support components, such as DNS, the metrics server, and networking or storage plugins, are deployed and managed using the same ordinary workload primitives, Deployments and DaemonSets, that any application uses, rather than through any special, privileged addon-only mechanism.
Addons Run as Ordinary Workloads
No Special Object Kind for Addons
Kubernetes is architected without a distinct "addon" resource type; cluster DNS, metrics collection, and similar system-level services are deployed as regular Deployments, DaemonSets, or other standard workload objects, typically placed in a reserved namespace such as kube-system rather than being represented through any privileged mechanism unavailable to ordinary applications.
Distinguished by Convention and Placement, Not Mechanism
What marks a workload as an addon is architectural convention, its placement in a system namespace and its role in supporting cluster-wide functionality, rather than any structural difference in how the underlying objects are created or reconciled.
DaemonSet-Based Addon Architecture
Node-Local Addons
Addons that need a presence on every node, such as CNI plugins, log collectors, or node-level monitoring agents, are architected as DaemonSets, relying on that controller's built-in guarantee of one Pod per eligible node rather than any addon-specific scheduling logic.
Deployment-Based Addon Architecture
Cluster-Wide, Centralized Addons
Addons that provide a single, cluster-wide service, such as cluster DNS or the metrics server, are architected as Deployments, often with multiple replicas for availability, exposed through a Service the same way any application-level Deployment would be.
Bootstrapping and Lifecycle Architecture
Installed After or Alongside Cluster Creation
Addons are architected to be installed as a separate step from core control plane initialization, either through manifests applied immediately after the cluster becomes available or through a packaging mechanism, meaning their availability is not a hard prerequisite for the control plane itself to start functioning.
Managed Independently of Control Plane Upgrades
Because addons are ordinary workloads, their versions and configurations are architected to be upgraded independently of control plane component versions, allowing DNS, metrics, or networking plugin updates to proceed on their own schedule.
Extension Points Addons Commonly Rely On
CRDs and Controllers as the Underlying Pattern
Many more sophisticated addons are architected using the same CRD-and-controller pattern used for Operators generally, registering their own custom resources to configure their behavior while still running their controller logic as an ordinary Deployment.