microk8s restarted without supervision

Created on 22 Jan 2020 · 5Comments · Source: ubuntu/microk8s

When you make a new release, you turn off and on microk8s on my production servers, sometimes breaking it, that seems pretty ridiculous.

Obviously I would like you to keep updating this code, but until this bug is fixed it seems like a pretty risky endeavor.

Source

termie

Most helpful comment

Hi @termie,

If you want a long lasting kubernetes cluster you will have to follow the stable channel of a specific track. For example sudo snap install microk8s --classic --channel=1.17/stable. This way your deployment will stay in v1.17 even if the latest stable kubernetes changes. You should also set the snap update schedule [1] as suggested above so that updates do not reach you in an inconvenient time. If you do not specify a channel you will be following the latest stable track meaning that you will get backwards incompatible changes introduced either by upstream Kubernetes or by the MicroK8s distribution. We try to do our best to transition users from one release to the next but this is not always possible. Read more on channels and upgrades in [2]

[1] https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--controlling-updates
[2] https://microk8s.io/docs/setting-snap-channel

ktsakalozos on 22 Jan 2020

👍2

All 5 comments

While I too find it a inconvenient, this is not a bug. microk8s is delivered as a snap package and these are automatically updated by your system: https://snapcraft.io/docs/keeping-snaps-up-to-date#heading--controlling-updates

A couple suggestions... Use the stable release channel to reduce the release frequency. Try putting your different nodes on different snap upgrade schedules to allow for more of a rolling upgrade schedule. Scale out your deployments so that losing a node does not impact your application.

strigona-worksight on 22 Jan 2020

👎3 👍1

The "stable" channel literally removed docker from the system in the 1.13 - 1.14 upgrade.

"We reserve the right to restart your application platform whenever we release." This is an outrageous expectation for software that is used to provide the infrastructure for other running applications.

These are not iPhones, we own our hardware and are running open source software, whatever happened to controlling your own system?

termie on 22 Jan 2020

My solution was to maintain a custom build of microk8s and completely remove the canonical/microk8s channel from my production systems. As this is an obvious amount of work to deploy this "fix" I have not rolled it out yet. A custom build should not be a requirement for people who don't want their production systems to restart at unannounced times.