Addons are a mechanism used to deploy Kubernetes resources after provisioning the cluster. Addons allow operators to use KubeOne to deploy various components such as CNI and CCM, and various stacks such as logging and monitoring, backups and recovery, log rotating, and more.
This document explains how to use addons in your workflow. If you want to learn more about how addons are implemented, you can check the design proposal for more details.
Addons are represented as Kubernetes YAML manifests. To deploy an addon, the operator needs to put a YAML manifest in a directory and provide it as the addons directory in the KubeOne cluster configuration.
Manifests support templating based on Go templates. The following data is available out of the box:
.Config
.Credentials
On top of that, you can use the sprig
functions in your templates.
For list of available functions, consider the sprig
docs.
The following snippet shows how an addon looks like and how to use templating:
apiVersion: v1
kind: Namespace
metadata:
name: example-{{ .Config.Name }} # will be rendered as 'example-cluster_name'
---
apiVersion: v1
kind: Secret
metadata:
name: credentials
namespace: kube-system
type: Opaque
data:
AWS_ACCESS_KEY_ID: {{ .Credentials.AWS_ACCESS_KEY_ID | b64enc }} # will be rendered as base64-encoded AWS access key
AWS_SECRET_ACCESS_KEY: {{ .Credentials.AWS_SECRET_ACCESS_KEY | b64enc }} # will be rendered as base64-encoded AWS secret access key
Note: The b64enc
function is a sprig
function.
To enable addons, you need to modify the KubeOne cluster configuration to add
the addons
config:
apiVersion: kubeone.io/v1beta1
kind: KubeOneCluster
versions:
kubernetes: 1.16.1
cloudProvider:
aws: {}
# Addons are Kubernetes manifests to be deployed after provisioning the cluster
addons:
enable: true
# In case when the relative path is provided, the path is relative
# to the KubeOne configuration file.
path: "./addons"
The addons path is normalized on the runtime. If you provide a relative path,
the path is relative to the KubeOne configuration file. This means that
./addons
will be parsed depending on the kubeone
command you use:
kubeone install -m config.yaml
- ./addons
kubeone install -m other/dir/config.yaml
- ./other/dir/addons/config.yaml
Subdirectories are not considered when applying addons. Only addons in the root of the provided directory will be applied.
The addons are reconciled after initializing and joining the control plane
nodes nodes when running kubeone install
, kubeone upgrade
, or
kubeone apply
. You can also reconcile addons after the cluster is provisioned
by using kubeone apply
.
kubeone apply --manifest kubeone.yaml -t .
The reconciliation is done using kubectl
over SSH, using a
command such as:
kubectl apply -f addons.yaml --prune -l kubeone.io/addon
Using the --prune
options means that the next time you run kubeone
:
The --prune
option can be dangerous. Always make sure that you have all
needed manifests present in the addons directory and correct addons
configuration before running kubeone
.
The addons are applied in the alphabetical order. This means that you can control in which order addons will be applied by setting the appropriate file name.
We provide the example addons that you can use as a template or to handle
various tasks, such as cluster backups. You can find the example addons in
the addons
directory.