Mailinglist Archive: opensuse-kubic (68 mails)

< Previous Next >
[opensuse-kubic] New Kubernetes Upgrade Mechanism Incoming
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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-kubic+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups