Skip to content
Snippets Groups Projects
Select Git revision
  • c2d4822c38c15815ef5b58a05e5359950f097808
  • master default protected
  • v2.28.0
  • v2.27.0
  • v2.25.1
  • v2.24.3
  • v2.26.0
  • v2.24.2
  • v2.25.0
  • v2.24.1
  • v2.22.2
  • v2.23.3
  • v2.24.0
  • v2.23.2
  • v2.23.1
  • v2.23.0
  • v2.22.1
  • v2.22.0
  • v2.21.0
  • v2.20.0
  • v2.19.1
  • v2.18.2
22 results

centos8.md

Blame
  • upgrades.md 16.43 KiB

    Upgrading Kubernetes in Kubespray

    Kubespray handles upgrades the same way it handles initial deployment. That is to say that each component is laid down in a fixed order.

    You can also individually control versions of components by explicitly defining their versions. Here are all version vars for each component:

    • docker_version
    • docker_containerd_version (relevant when container_manager == docker)
    • containerd_version (relevant when container_manager == containerd)
    • kube_version
    • etcd_version
    • calico_version
    • calico_cni_version
    • weave_version
    • flannel_version
    • kubedns_version

    Warning Attempting to upgrade from an older release straight to the latest release is unsupported and likely to break something

    See Multiple Upgrades for how to upgrade from older Kubespray release to the latest release

    Unsafe upgrade example

    If you wanted to upgrade just kube_version from v1.18.10 to v1.19.7, you could deploy the following way:

    ansible-playbook cluster.yml -i inventory/sample/hosts.ini -e kube_version=v1.18.10 -e upgrade_cluster_setup=true

    And then repeat with v1.19.7 as kube_version:

    ansible-playbook cluster.yml -i inventory/sample/hosts.ini -e kube_version=v1.19.7 -e upgrade_cluster_setup=true

    The var -e upgrade_cluster_setup=true is needed to be set in order to migrate the deploys of e.g kube-apiserver inside the cluster immediately which is usually only done in the graceful upgrade. (Refer to #4139 and #4736)

    Graceful upgrade

    Kubespray also supports cordon, drain and uncordoning of nodes when performing a cluster upgrade. There is a separate playbook used for this purpose. It is important to note that upgrade-cluster.yml can only be used for upgrading an existing cluster. That means there must be at least 1 kube_control_plane already deployed.

    ansible-playbook upgrade-cluster.yml -b -i inventory/sample/hosts.ini -e kube_version=v1.19.7

    After a successful upgrade, the Server Version should be updated:

    $ kubectl version
    Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.7", GitCommit:"1dd5338295409edcfff11505e7bb246f0d325d15", GitTreeState:"clean", BuildDate:"2021-01-13T13:23:52Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}
    Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.7", GitCommit:"1dd5338295409edcfff11505e7bb246f0d325d15", GitTreeState:"clean", BuildDate:"2021-01-13T13:15:20Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

    Pausing the upgrade

    If you want to manually control the upgrade procedure, you can set some variables to pause the upgrade playbook. Pausing before upgrading each upgrade may be useful for inspecting pods running on that node, or performing manual actions on the node:

    • upgrade_node_confirm: true - This will pause the playbook execution prior to upgrading each node. The play will resume when manually approved by typing "yes" at the terminal.
    • upgrade_node_pause_seconds: 60 - This will pause the playbook execution for 60 seconds prior to upgrading each node. The play will resume automatically after 60 seconds.