Kubernetes Addon Architecture

Kubernetes Addon Architecture is the arrangement of cluster addons, DNS, the metrics pipeline, the dashboard, network and storage plugins, as workloads that run inside the cluster itself, deployed as ordinary Kubernetes objects in a reserved namespace, rather than as compiled-in parts of the control plane binaries. An addon is architecturally indistinguishable from any other workload once running: it is scheduled onto nodes, subject to the same resource governance, and reconciled by the same controller mechanisms as an application team's own Deployments, even though it provides infrastructure the rest of the cluster depends on.

Addons as Ordinary Workloads

No Special Object Kind

There is formally no distinct API kind for an "addon"; a cluster addon is built from the same Deployment, DaemonSet, Service, and ConfigMap kinds available to any workload, distinguished only by convention, typically residing in the kube-system namespace, and by the specific infrastructure role it fulfills.

kubectl get all -n kube-system
kubectl get deployments -n kube-system -l k8s-app

Bootstrapping Circularity

Because addons run as ordinary cluster workloads, some addons face a bootstrapping circularity: cluster DNS, for instance, itself depends on the cluster's networking already being functional, which in turn may depend on a CNI plugin that is itself deployed as an addon; cluster provisioning tooling formally sequences addon installation to resolve these dependencies in the correct order.

Common Addon Categories

DNS

Cluster DNS, typically CoreDNS, runs as a Deployment with an accompanying ClusterIP Service, itself a Kubernetes workload providing the DNS resolution service every other workload in the cluster relies on for Service discovery.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coredns
  namespace: kube-system

Metrics Pipeline

The Metrics Server, and any additional custom or external metrics adapters, run as Deployments exposing an aggregated API, registered via an APIService object, that the Horizontal Pod Autoscaler and kubectl top consume.

Networking and Storage Plugins

CNI plugins and CSI drivers formally run as DaemonSets (for their node-local components) and Deployments or StatefulSets (for their controller components), themselves subject to scheduling, resource requests, and rolling updates like any other workload, despite providing foundational infrastructure.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: calico-node
  namespace: kube-system

Dashboard and Auxiliary Tooling

Web-based dashboards, log aggregation agents, and similar auxiliary tools are formally packaged and deployed the same way, as Deployments or DaemonSets with associated RBAC objects granting them exactly the API permissions their function requires.

Installation Mechanisms

Cluster Bootstrap Tooling

Cluster provisioning tools, kubeadm, managed cloud offerings, or cluster-lifecycle operators, commonly install a baseline set of addons automatically as part of initial cluster creation, applying their manifests during the bootstrap sequence before the cluster is considered ready for general workloads.

Manual and Package-Manager Installation

Addons not installed automatically are commonly added afterward using the same tooling used for any other workload, direct manifest application, Helm charts, or Kustomize overlays, reflecting that from an installation-tooling perspective, an addon requires nothing beyond what any application deployment requires.

helm install cilium cilium/cilium -n kube-system
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/metrics-server/.../components.yaml

RBAC and Privilege Considerations

Elevated Permissions by Necessity

Many addons formally require RBAC permissions considerably broader than a typical application workload, a CNI plugin's controller may need to watch and modify Node objects, a CSI driver may need to create PersistentVolumes, reflecting that their infrastructure role genuinely requires visibility or control over cluster-wide resources rather than any special, addon-specific privilege escalation mechanism outside ordinary RBAC.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: calico-node
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]

Managed Addons in Managed Clusters

Provider-Operated Lifecycle

In managed Kubernetes offerings, a defined set of addons, commonly DNS, the CNI plugin, and cloud-integration components, are formally operated and upgraded by the provider as part of the managed service, with the customer typically able to enable, disable, or configure them through the provider's own management interface rather than applying manifests directly.

kubectl get pods -n kube-system --field-selector=status.phase=Running

Why Addons Are Architected as Ordinary Workloads

Building addons from the same primitives as any application, rather than as specially privileged, separately managed system processes, is what formally allows the same tooling, kubectl, RBAC, resource governance, rolling updates, health probes, to apply uniformly across both infrastructure and application workloads, avoiding a parallel, addon-specific management system alongside the one used for everything else running in the cluster.