Introduction

For Kubernetes 1.1, the “correct” way to install add-ons was historically to deploy them as Kubernetes manifests, usually into kube-system, using the cluster’s supported management path rather than treating them as node-local software. The exact mechanics depended on the distribution, but the core idea was the same: add-ons were cluster workloads managed by the API server, not manual binaries copied onto each machine.

Think of Add-ons as Cluster Workloads

Even in early Kubernetes versions, add-ons such as DNS, dashboard, and monitoring components were typically represented as ordinary Kubernetes objects:

• replication controllers or pods
• services
• config maps or earlier config equivalents
• service accounts and permissions where needed

That means the durable installation method was to apply manifests to the cluster rather than hand-configuring each node independently.

Use the Provider or Addon-Manager Path If Available

Many early Kubernetes setups shipped with an addon-manager pattern that watched a designated manifest directory and kept those add-ons present in the cluster. If your distribution supported that mechanism, it was usually the cleanest way to manage core cluster add-ons because the cluster tooling would keep them reconciled.

When that addon-manager path was not part of the environment, the next best approach was still manifest-based installation through kubectl.

A minimal example looked like this:

1apiVersion: v1
2kind: Namespace
3metadata:
4  name: kube-system
5---
6apiVersion: v1
7kind: ReplicationController
8metadata:
9  name: example-addon
10  namespace: kube-system
11spec:
12  replicas: 1
13  selector:
14    app: example-addon
15  template:
16    metadata:
17      labels:
18        app: example-addon
19    spec:
20      containers:
21        - name: example-addon
22          image: example/addon:1.0

Then:

kubectl create -f addon.yaml

That kept the installation visible, declarative, and managed by Kubernetes itself.

Use kube-system for Cluster-Level Add-ons

System-level add-ons were typically placed in the kube-system namespace so operators could distinguish them from ordinary application workloads. That convention also made it easier to reason about cluster services, permissions, and lifecycle.

If the add-on serves the whole cluster, such as DNS or dashboard, kube-system is usually the right historical placement. Application-specific tools might belong elsewhere, but core add-ons were generally treated as system components.

Match Versions Carefully

Kubernetes 1.1 is very old, so version compatibility matters much more than with modern clusters. Many add-ons released later will assume APIs, controllers, or RBAC behavior that did not exist yet or looked very different in that era.

So the practical rule is:

• choose add-on manifests made for Kubernetes 1.1 or nearby versions
• do not assume modern manifests apply cleanly
• inspect deprecated or missing API fields before deploying

This is one of the biggest reasons historical Kubernetes operations can be tricky today.

Avoid Node-by-Node Installation Logic

A frequent wrong turn is treating an add-on like a piece of host software that should be installed separately on each node outside the cluster API. That breaks the main Kubernetes benefit of declarative lifecycle management.

If the add-on is supposed to run as a cluster component, install it as a Kubernetes-managed workload whenever possible. The cluster should schedule and restart it, not a manual shell script on each machine.

Common Pitfalls

The most common mistake is using manifests from a much newer Kubernetes release and expecting them to work unchanged on 1.1. The API surface and operational conventions were very different.

Another pitfall is installing add-ons manually on nodes instead of representing them as Kubernetes objects. That makes the add-on harder to audit, upgrade, and recover.

It is also easy to ignore the cluster’s own supported addon-manager path if one exists. For core system add-ons, working with the cluster’s management model is usually better than bypassing it.

Finally, remember that Kubernetes 1.1 predates many later conveniences. Historical examples should be read in the context of that older control-plane and API model rather than modern Helm-first workflows.

Summary

• On Kubernetes 1.1, add-ons were generally installed as cluster manifests, not as ad hoc node software.
• Use the distribution’s addon-manager path if the cluster provides one.
• Otherwise, install add-ons through kubectl into the cluster, usually in kube-system for system services.
• Match add-on manifests to the old Kubernetes version carefully.
• Treat add-ons as Kubernetes-managed workloads so the cluster can own their lifecycle.