You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

359 lines
12 KiB

  1. Upgrading Kubernetes in Kubespray
  2. =============================
  3. #### Description
  4. Kubespray handles upgrades the same way it handles initial deployment. That is to
  5. say that each component is laid down in a fixed order.
  6. You can also individually control versions of components by explicitly defining their
  7. versions. Here are all version vars for each component:
  8. * docker_version
  9. * kube_version
  10. * etcd_version
  11. * calico_version
  12. * calico_cni_version
  13. * weave_version
  14. * flannel_version
  15. * kubedns_version
  16. :warning: [Attempting to upgrade from an older release straight to the latest release is unsupported and likely to break something](https://github.com/kubernetes-sigs/kubespray/issues/3849#issuecomment-451386515) :warning:
  17. See [Multiple Upgrades](#multiple-upgrades) for how to upgrade from older releases to the latest release
  18. #### Unsafe upgrade example
  19. If you wanted to upgrade just kube_version from v1.4.3 to v1.4.6, you could
  20. deploy the following way:
  21. ```
  22. ansible-playbook cluster.yml -i inventory/sample/hosts.ini -e kube_version=v1.4.3
  23. ```
  24. And then repeat with v1.4.6 as kube_version:
  25. ```
  26. ansible-playbook cluster.yml -i inventory/sample/hosts.ini -e kube_version=v1.4.6
  27. ```
  28. #### Graceful upgrade
  29. Kubespray also supports cordon, drain and uncordoning of nodes when performing
  30. a cluster upgrade. There is a separate playbook used for this purpose. It is
  31. important to note that upgrade-cluster.yml can only be used for upgrading an
  32. existing cluster. That means there must be at least 1 kube-master already
  33. deployed.
  34. ```
  35. ansible-playbook upgrade-cluster.yml -b -i inventory/sample/hosts.ini -e kube_version=v1.6.0
  36. ```
  37. After a successful upgrade, the Server Version should be updated:
  38. ```
  39. $ kubectl version
  40. Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"fff5156092b56e6bd60fff75aad4dc9de6b6ef37", GitTreeState:"clean", BuildDate:"2017-03-28T19:15:41Z", GoVersion:"go1.8", Compiler:"gc", Platform:"darwin/amd64"}
  41. Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0+coreos.0", GitCommit:"8031716957d697332f9234ddf85febb07ac6c3e3", GitTreeState:"clean", BuildDate:"2017-03-29T04:33:09Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}
  42. ```
  43. #### Multiple upgrades
  44. :warning: [Do not skip releases when upgrading--upgrade by one tag at a time.](https://github.com/kubernetes-sigs/kubespray/issues/3849#issuecomment-451386515) :warning:
  45. For instance, if you're on v2.6.0, then check out v2.7.0, run the upgrade, check out the next tag, and run the next upgrade, etc.
  46. Assuming you don't explicitly define a kubernetes version in your k8s-cluster.yml, you simply check out the next tag and run the upgrade-cluster.yml playbook
  47. * If you do define kubernetes version in your inventory (e.g. group_vars/k8s-cluster.yml) then either make sure to update it before running upgrade-cluster, or specify the new version you're upgrading to: `ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml -e kube_version=v1.11.3`
  48. Otherwise, the upgrade will leave your cluster at the same k8s version defined in your inventory vars.
  49. The below example shows taking a cluster that was set up for v2.6.0 up to v2.10.0
  50. ```
  51. $ kubectl get node
  52. NAME STATUS ROLES AGE VERSION
  53. apollo Ready master,node 1h v1.10.4
  54. boomer Ready master,node 42m v1.10.4
  55. caprica Ready master,node 42m v1.10.4
  56. $ git describe --tags
  57. v2.6.0
  58. $ git tag
  59. ...
  60. v2.6.0
  61. v2.7.0
  62. v2.8.0
  63. v2.8.1
  64. v2.8.2
  65. ...
  66. $ git checkout v2.7.0
  67. Previous HEAD position was 8b3ce6e4 bump upgrade tests to v2.5.0 commit (#3087)
  68. HEAD is now at 05dabb7e Fix Bionic networking restart error #3430 (#3431)
  69. # NOTE: May need to sudo pip3 install -r requirements.txt when upgrading.
  70. $ ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml
  71. ...
  72. $ kubectl get node
  73. NAME STATUS ROLES AGE VERSION
  74. apollo Ready master,node 1h v1.11.3
  75. boomer Ready master,node 1h v1.11.3
  76. caprica Ready master,node 1h v1.11.3
  77. $ git checkout v2.8.0
  78. Previous HEAD position was 05dabb7e Fix Bionic networking restart error #3430 (#3431)
  79. HEAD is now at 9051aa52 Fix ubuntu-contiv test failed (#3808)
  80. ```
  81. :info: NOTE: Review changes between the sample inventory and your inventory when upgrading versions. :info:
  82. Some deprecations between versions that mean you can't just upgrade straight from 2.7.0 to 2.8.0 if you started with the sample inventory.
  83. In this case, I set "kubeadm_enabled" to false, knowing that it is deprecated and removed by 2.9.0, to delay converting the cluster to kubeadm as long as I could.
  84. ```
  85. $ ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml
  86. ...
  87. "msg": "DEPRECATION: non-kubeadm deployment is deprecated from v2.9. Will be removed in next release."
  88. ...
  89. Are you sure you want to deploy cluster using the deprecated non-kubeadm mode. (output is hidden):
  90. yes
  91. ...
  92. $ kubectl get node
  93. NAME STATUS ROLES AGE VERSION
  94. apollo Ready master,node 114m v1.12.3
  95. boomer Ready master,node 114m v1.12.3
  96. caprica Ready master,node 114m v1.12.3
  97. $ git checkout v2.8.1
  98. Previous HEAD position was 9051aa52 Fix ubuntu-contiv test failed (#3808)
  99. HEAD is now at 2ac1c756 More Feature/2.8 backports for 2.8.1 (#3911)
  100. $ ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml
  101. ...
  102. "msg": "DEPRECATION: non-kubeadm deployment is deprecated from v2.9. Will be removed in next release."
  103. ...
  104. Are you sure you want to deploy cluster using the deprecated non-kubeadm mode. (output is hidden):
  105. yes
  106. ...
  107. $ kubectl get node
  108. NAME STATUS ROLES AGE VERSION
  109. apollo Ready master,node 2h36m v1.12.4
  110. boomer Ready master,node 2h36m v1.12.4
  111. caprica Ready master,node 2h36m v1.12.4
  112. $ git checkout v2.8.2
  113. Previous HEAD position was 2ac1c756 More Feature/2.8 backports for 2.8.1 (#3911)
  114. HEAD is now at 4167807f Upgrade to 1.12.5 (#4066)
  115. $ ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml
  116. ...
  117. "msg": "DEPRECATION: non-kubeadm deployment is deprecated from v2.9. Will be removed in next release."
  118. ...
  119. Are you sure you want to deploy cluster using the deprecated non-kubeadm mode. (output is hidden):
  120. yes
  121. ...
  122. $ kubectl get node
  123. NAME STATUS ROLES AGE VERSION
  124. apollo Ready master,node 3h3m v1.12.5
  125. boomer Ready master,node 3h3m v1.12.5
  126. caprica Ready master,node 3h3m v1.12.5
  127. $ git checkout v2.8.3
  128. Previous HEAD position was 4167807f Upgrade to 1.12.5 (#4066)
  129. HEAD is now at ea41fc5e backport cve-2019-5736 to release-2.8 (#4234)
  130. $ ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml
  131. ...
  132. "msg": "DEPRECATION: non-kubeadm deployment is deprecated from v2.9. Will be removed in next release."
  133. ...
  134. Are you sure you want to deploy cluster using the deprecated non-kubeadm mode. (output is hidden):
  135. yes
  136. ...
  137. $ kubectl get node
  138. NAME STATUS ROLES AGE VERSION
  139. apollo Ready master,node 5h18m v1.12.5
  140. boomer Ready master,node 5h18m v1.12.5
  141. caprica Ready master,node 5h18m v1.12.5
  142. $ git checkout v2.8.4
  143. Previous HEAD position was ea41fc5e backport cve-2019-5736 to release-2.8 (#4234)
  144. HEAD is now at 3901480b go to k8s 1.12.7 (#4400)
  145. $ ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml
  146. ...
  147. "msg": "DEPRECATION: non-kubeadm deployment is deprecated from v2.9. Will be removed in next release."
  148. ...
  149. Are you sure you want to deploy cluster using the deprecated non-kubeadm mode. (output is hidden):
  150. yes
  151. ...
  152. $ kubectl get node
  153. NAME STATUS ROLES AGE VERSION
  154. apollo Ready master,node 5h37m v1.12.7
  155. boomer Ready master,node 5h37m v1.12.7
  156. caprica Ready master,node 5h37m v1.12.7
  157. $ git checkout v2.8.5
  158. Previous HEAD position was 3901480b go to k8s 1.12.7 (#4400)
  159. HEAD is now at 6f97687d Release 2.8 robust san handling (#4478)
  160. $ ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml
  161. ...
  162. "msg": "DEPRECATION: non-kubeadm deployment is deprecated from v2.9. Will be removed in next release."
  163. ...
  164. Are you sure you want to deploy cluster using the deprecated non-kubeadm mode. (output is hidden):
  165. yes
  166. ...
  167. $ kubectl get node
  168. NAME STATUS ROLES AGE VERSION
  169. apollo Ready master,node 5h45m v1.12.7
  170. boomer Ready master,node 5h45m v1.12.7
  171. caprica Ready master,node 5h45m v1.12.7
  172. $ git checkout v2.9.0
  173. Previous HEAD position was 6f97687d Release 2.8 robust san handling (#4478)
  174. HEAD is now at a4e65c7c Upgrade to Ansible >2.7.0 (#4471)
  175. ```
  176. :warning: IMPORTANT: Some of the variable formats changed in the k8s-cluster.yml between 2.8.5 and 2.9.0 :warning:
  177. If you do not keep your inventory copy up to date, **your upgrade will fail** and your first master will be left non-functional until fixed and re-run.
  178. It is at this point the cluster was upgraded from non-kubeadm to kubeadm as per the deprecation warning.
  179. ```
  180. $ ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml
  181. ...
  182. $ kubectl get node
  183. NAME STATUS ROLES AGE VERSION
  184. apollo Ready master,node 6h54m v1.13.5
  185. boomer Ready master,node 6h55m v1.13.5
  186. caprica Ready master,node 6h54m v1.13.5
  187. # Watch out: 2.10.0 is hiding between 2.1.2 and 2.2.0
  188. $ git tag
  189. ...
  190. v2.1.0
  191. v2.1.1
  192. v2.1.2
  193. v2.10.0
  194. v2.2.0
  195. ...
  196. $ git checkout v2.10.0
  197. Previous HEAD position was a4e65c7c Upgrade to Ansible >2.7.0 (#4471)
  198. HEAD is now at dcd9c950 Add etcd role dependency on kube user to avoid etcd role failure when running scale.yml with a fresh node. (#3240) (#4479)
  199. $ ansible-playbook -i inventory/mycluster/hosts.ini -b upgrade-cluster.yml
  200. ...
  201. $ kubectl get node
  202. NAME STATUS ROLES AGE VERSION
  203. apollo Ready master,node 7h40m v1.14.1
  204. boomer Ready master,node 7h40m v1.14.1
  205. caprica Ready master,node 7h40m v1.14.1
  206. ```
  207. #### Upgrade order
  208. As mentioned above, components are upgraded in the order in which they were
  209. installed in the Ansible playbook. The order of component installation is as
  210. follows:
  211. * Docker
  212. * etcd
  213. * kubelet and kube-proxy
  214. * network_plugin (such as Calico or Weave)
  215. * kube-apiserver, kube-scheduler, and kube-controller-manager
  216. * Add-ons (such as KubeDNS)
  217. #### Upgrade considerations
  218. Kubespray supports rotating certificates used for etcd and Kubernetes
  219. components, but some manual steps may be required. If you have a pod that
  220. requires use of a service token and is deployed in a namespace other than
  221. `kube-system`, you will need to manually delete the affected pods after
  222. rotating certificates. This is because all service account tokens are dependent
  223. on the apiserver token that is used to generate them. When the certificate
  224. rotates, all service account tokens must be rotated as well. During the
  225. kubernetes-apps/rotate_tokens role, only pods in kube-system are destroyed and
  226. recreated. All other invalidated service account tokens are cleaned up
  227. automatically, but other pods are not deleted out of an abundance of caution
  228. for impact to user deployed pods.
  229. ### Component-based upgrades
  230. A deployer may want to upgrade specific components in order to minimize risk
  231. or save time. This strategy is not covered by CI as of this writing, so it is
  232. not guaranteed to work.
  233. These commands are useful only for upgrading fully-deployed, healthy, existing
  234. hosts. This will definitely not work for undeployed or partially deployed
  235. hosts.
  236. Upgrade docker:
  237. ```
  238. ansible-playbook -b -i inventory/sample/hosts.ini cluster.yml --tags=docker
  239. ```
  240. Upgrade etcd:
  241. ```
  242. ansible-playbook -b -i inventory/sample/hosts.ini cluster.yml --tags=etcd
  243. ```
  244. Upgrade vault:
  245. ```
  246. ansible-playbook -b -i inventory/sample/hosts.ini cluster.yml --tags=vault
  247. ```
  248. Upgrade kubelet:
  249. ```
  250. ansible-playbook -b -i inventory/sample/hosts.ini cluster.yml --tags=node --skip-tags=k8s-gen-certs,k8s-gen-tokens
  251. ```
  252. Upgrade Kubernetes master components:
  253. ```
  254. ansible-playbook -b -i inventory/sample/hosts.ini cluster.yml --tags=master
  255. ```
  256. Upgrade network plugins:
  257. ```
  258. ansible-playbook -b -i inventory/sample/hosts.ini cluster.yml --tags=network
  259. ```
  260. Upgrade all add-ons:
  261. ```
  262. ansible-playbook -b -i inventory/sample/hosts.ini cluster.yml --tags=apps
  263. ```
  264. Upgrade just helm (assuming `helm_enabled` is true):
  265. ```
  266. ansible-playbook -b -i inventory/sample/hosts.ini cluster.yml --tags=helm
  267. ```