Kubermatic provides live updates of your Kubernetes cluster
without disrupting your daily business. The allowed updates are defined in the file
updates.yaml. You find it in your Kubermatic installer clone directory:
git clone email@example.com:kubermatic/kubermatic-installer.git cd kubermatic-installer/ ls charts/kubermatic/static/master/
The file contains the supported upgrade paths for Kubernetes. The file format is YAML.
updates: # ======= 1.12 ======= # Allow to change to any patch version - from: 1.12.* to: 1.12.* automatic: false # CVE-2018-1002105 - from: <= 1.12.2, >= 1.12.0 to: 1.12.3 automatic: true # Allow to next minor release - from: 1.12.* to: 1.13.* automatic: false # ======= 1.13 ======= # Allow to change to any patch version - from: 1.13.* to: 1.13.* automatic: false # Allow to next minor release - from: 1.13.* to: 1.14.* automatic: false # ======= 1.14 ======= # Allow to change to any patch version - from: 1.14.* to: 1.14.* automatic: false # Allow to next minor release - from: 1.14.* to: 1.15.* automatic: false
As you can see it is a list containing the keys
automatic. The fields
to contain patterns descibing the Kubernetes version numbers. These can be absolut,
contain wildcards, or be ranges. This way Kubermatic can check which updates are allowed for
the current version.
automatic determines if an update has to be initiated manually or if the system will
do it immediatelly in case of a matching version path. So in case of the example above a cluster
running in any Kubernetes version from 1.12.0 to 1.12.2 would automatically upgrade to 1.12.3.
This way known vulnerabilities can be handled directly.
Note: The automatic update only updates the control plane. kubelets on the nodes still have to be updated manually.
After editing the list Kubermatic has to be upgraded by using
cd kubermatic-installer/charts/kubermatic vim static/master/updates.yaml helm upgrade kubermatic .
Afterwards the new update paths are available.