In addition, kops offers end-user management of addons via the channels tool (which is still experimental,but we are working on making it a recommended part of kubernetes addon management). We ship somecurated addons in the , more information in the addons document.

kops uses the channels tool for system addon management also. Because kops uses the same toolfor system addon management as it does for user addon management, this means thataddons installed by kops as part of cluster bringup can be managed alongside additional addons.(Though note that bootstrap addons are much more likely to be replaced during a kops upgrade).

The general kops philosophy is to try to make the set of bootstrap addons minimal, andto make installation of subsequent addons easy.

Thus, kube-dns and the networking overlay (if any) are the canonical bootstrap addons.But addons such as the dashboard or the EFK stack are easily installed after kops bootstrap,with a kubectl apply -f https://... or with the channels tool.

In future, we may as a convenience make it easy to add optional addons to the kops manifest,though this will just be a convenience wrapper around doing it manually.

The channels tool adds a manifest-of-manifests file, of Kind: Addons, which allows for a descriptionof the various manifest versions that are available. In this way kops can manage updatesas new versions of the addon are released. For example,the lists multiple versions.

That declares two versions of an addon, with manifests at v1.4.0.yaml and at v1.5.0.yaml.These are evaluated as relative paths to the Addons file itself. (The channels tool supportsa few more protocols than kubectl - for example s3://... for S3 hosted manifests).

The field gives meaning to the alternative manifests. This is interpreted as asemver. The channels tool keeps track of the current version installed (currently by meansof an annotation on the kube-system namespace), and it will not reapply the same versionof the manifest. This means that a user can edit a deployed addon, and changes will notbe replaced, until a new version of the addon is installed.

The long-term direction here is that addons will mostly be configured through a ConfigMap or Secret object,and that the addon manager will (TODO) not replace the ConfigMap.

The selector determines the objects which make up the addon. This will be usedto construct a --prune argument (TODO), so that objects that existed in theprevious but not the new version will be removed as part of an upgrade.

The addon manager now supports a kubernetesVersion field, which is a semver range specifieron the kubernetes version. If the targeted version of kubernetes does not match the semverspecified, the addon version will be ignored.

This allows you to have different versions of the manifest for significant changes to thekubernetes API. For example, 1.6 changed the taints & tolerations to a field, and RBAC movedto beta. As such it is easier to have two separate manifests.

On kubernetes versions before 1.6, we will install v1.5.0.yaml, whereas from kubernetesversions 1.6 on we will install v1.6.0.yaml.

Note that we remove the pre-release field of the kubernetes semver, so that 1.6.0-beta.1will match >=1.6.0. This matches the way kubernetes does pre-releases.

However, semver is insufficient here with the kubernetes version selection. The problemarises in the following scenario:

• Install k8s 1.5, 1.5 version of manifest is installed
• Upgrade to k8s 1.6, 1.6 version of manifest is installed

We need a way to break the ties between the semvers, and thus we introduce the id field.

Thus a manifest will actually look like this:

Note that the two addons have the same version, but a different kubernetesVersion selector.But they have different id values; addons with matching semvers but different ids willbe upgraded. (We will never downgrade to an older semver though, regardless of id)

A few tips:

• The version can now more closely mirror the upstream version.
• The manifest names should probably incorporate the id, for maintainability.