I am using kOps to perform a manual cluster upgrade (from 1.17 to 1.18) as explained at https://kops.sigs.k8s.io/operations/updates_and_upgrades/#upgrading-kubernetes
I’ve noticed that kOps does not update the ami-image defined at spec.image
at ig nodes, that means after cluster upgrade nodes are going to use the same base OS despite the kubernetes upgrade. But if you install 1.18 from scratch kOps uses the latest image available for that version.
should i update the version and configure it the same as the one kOps would use in case of an installation from scratch?
In 1.18 ami has moved from Debian to Ubuntu, should i take any precautions due to the change of operating system?
2
Answers
if you edit the manifests directly and do "kops update" etc … then you need to also update the images, another alternative is to let kops do it for you by running "kops upgrade cluster " it will update the remote state and set the correct defaults etc ..
regarding the image change, i don’t see any major issues there, what you can do is grab the current ami and do "sort of rollbacks" by replacing the image and updating the cluster ( or applying previous version of the manifest assuming you have s3 revisions on the state )
There was a bug up until kOps 1.18.2 where Ubuntu images were considered "custom" and therefore not upgraded by
kops upgrade
. See this bugAs of 1.18.2, you should see upgrades for Ubuntu as well.
There is no particular need to take any precaution when switching from Debian to Ubuntu unless you are using kOps hooks that would be Debian. kOps will take care of this change for you.