From 3c66e4cdbaf4c0853cb3b5bcc3e5f876feb4aebc Mon Sep 17 00:00:00 2001 From: Matthew Mosesohn Date: Wed, 7 Dec 2016 16:33:08 +0300 Subject: [PATCH] Add document outlining upgrade process --- docs/upgrades.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) create mode 100644 docs/upgrades.md diff --git a/docs/upgrades.md b/docs/upgrades.md new file mode 100644 index 000000000..4a25bd622 --- /dev/null +++ b/docs/upgrades.md @@ -0,0 +1,47 @@ +Upgrading Kubernetes in Kargo +============================= + +#### Description + +Kargo handles upgrades the same way it handles initial deployment. That is to +say that each component is laid down in a fixed order. You should be able to +upgrade from Kargo tag 2.0 up to the current master without difficulty. You can +also individually control versions of components by explicitly defining their +versions. Here are all version vars for each component: + +* docker_version +* kube_version +* etcd_version +* calico_version +* calico_cni_version +* weave_version +* flannel_version +* kubedns_version + +#### Example + +If you wanted to upgrade just kube_version from v1.4.3 to v1.4.6, you could +deploy the following way: + +``` +ansible-playbook cluster.yml -i inventory/inventory.cfg -e kube_version=v1.4.3 +``` + +And then repeat with v1.4.6 as kube_version: + +``` +ansible-playbook cluster.yml -i inventory/inventory.cfg -e kube_version=v1.4.6 +``` + +#### Upgrade order + +As mentioned above, components are upgraded in the order in which they were +installed in the Ansible playbook. The order of component installation is as +follows: + +# Docker +# etcd +# kubelet and kube-proxy +# network_plugin (such as Calico or Weave) +# kube-apiserver, kube-scheduler, and kube-controller-manager +# Add-ons (such as KubeDNS)