Hello all, TL;DR version: We're changing how upgrading existing clusters work before Kubernetes 1.18 is released in a few weeks. You don't need do anything right now, there will be simple documentation you will need to follow when 1.18 is released. For those who want to know more.... Long version: I've just submitted Kubernetes 1.17.4 to Factory, but more importantly this submission includes the framework for a new way of handling upgrades of existing clusters. For those who are unaware of the problem, on any kubernetes cluster (regardless of whether it's running on Kubic or a non-transactional system) it is relatively easy to break the cluster during operating system upgrades. This is because our containerised kubernetes components need to be upgraded before the kubelet running on the host is, but we need to have the updated kubeadm on the host in order to update the containerised components. This is what we saw in https://bugzilla.opensuse.org/show_bug.cgi?id=1161289 where 1.16.x clusters got broken because the kubelet binary got moved to 1.17.x before the user had any opportunity to migrate their cluster to 1.17.x The new approach will be as follows: - We will no longer have a kubernetes-kubelet package providing /usr/bin/kubelet - Instead we will have kubernetes-kubelet1.XX packages, providing /usr/bin/kubelet1.XX (eg /usr/bin/kubelet1.17) - /usr/bin/kubelet is now a shell script that runs the correct version of the kubelet for the deployed cluster - the 'correct version' is defined in the 'KUBELET_VER=' parameter in /etc/sysconfig/kubelet Once Kubernetes 1.17.4 is merged into Factory most of the above changes will happen automatically to your machine - You will not need to do anything immediately. When Kubernetes 1.18.x is released in a few weeks, we will continue to build and offer kubernetes-kubelet1.17 in all of the Kubic snapshots containing 1.18 This means clusters that you deploy today with 1.17 will continue to work until you either `kubeadm upgrade` or `kubicctl upgrade` your cluster to 1.18 Then you/something will need to edit /etc/sysconfig/kubelet and change `KUBELET_VER=1.17` on each node to read `KUBELET_VER=1.18` We are looking at possible ways to automating this step before 1.18's release, so I wont be updating the wiki documentation until then. This approach has a nice benefit compared to the regular upstream kubernetes upgrade process. Normally you need to manually update your kubelet package after doing your cluster upgrade. On a transactional system this would also mean rebooting. With our approach Kubic machines will already have the new kubelet present on the system and the configuration change to use the new version can take effect on the with a simple restart of the kubelet service. Fingers crossed, 1.18 will hopefully be the smoothest kubernetes release we have in Kubic yet. -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org