Selecting a snap channel

General Discussions microk8s
1

Microk8s is a snap deploying Kubernetes. The MicroK8s snap closely follows upstream Kubernetes, so understanding a bit about the Kubernetes release cycle is helpful for more insight into MicroK8s releases.

Upstream Kubernetes ships a new release series (e.g. 1.27.x) approximately every three months. Prior release series may get periodic bugfix releases: for example, the latest 1.24 release is 1.24.8.

Choosing the right channel

When installing the MicroK8s you can specify a channel. The channel specified is made up of two components; the track and the risk level. For example to install MicroK8s v1.29 with risk level set to stable you need to:

sudo snap install microk8s --classic --channel=1.29/stable

The track denotes the upstream Kubernetes version while the risk level reflects the maturity level of the release. The stable risk level indicates that your cluster is updated when the MicroK8s team decides a release is ready and no issues have been revealed by users running the same revision on riskier branches (edge and candidate).

All the currently available channels are shown if you run snap info microk8s:

...
channels:
  1.29/stable:           v1.29.2  2024-03-07 (6641) 169MB classic
  1.29/candidate:        v1.29.3  2024-04-13 (6727) 170MB classic
  1.29/beta:             v1.29.3  2024-04-13 (6727) 170MB classic
  1.29/edge:             v1.29.4  2024-04-16 (6757) 170MB classic
  latest/stable:         v1.29.0  2024-01-25 (6364) 168MB classic
  latest/candidate:      v1.30.0  2024-04-18 (6776) 168MB classic
  latest/beta:           v1.30.0  2024-04-18 (6776) 168MB classic
  latest/edge:           v1.30.0  2024-04-19 (6798) 168MB classic
  1.30-strict/stable:    v1.30.0  2024-04-18 (6783) 168MB -
  1.30-strict/candidate: v1.30.0  2024-04-18 (6783) 168MB -
  1.30-strict/beta:      v1.30.0  2024-04-18 (6783) 168MB -
  1.30-strict/edge:      v1.30.0  2024-04-18 (6783) 168MB -
  1.30/stable:           v1.30.0  2024-04-18 (6782) 168MB classic
  1.30/candidate:        v1.30.0  2024-04-18 (6782) 168MB classic
  1.30/beta:             v1.30.0  2024-04-18 (6782) 168MB classic
  1.30/edge:             v1.30.0  2024-04-19 (6797) 168MB classic
  1.29-strict/stable:    v1.29.2  2024-02-20 (6529) 169MB -
  1.29-strict/candidate: v1.29.2  2024-02-20 (6529) 169MB -
  1.29-strict/beta:      v1.29.2  2024-02-20 (6529) 169MB -
  1.29-strict/edge:      v1.29.4  2024-04-16 (6756) 170MB -
  1.28-strict/stable:    v1.28.7  2024-02-20 (6532) 186MB -
  1.28-strict/candidate: v1.28.7  2024-02-20 (6532) 186MB -
  ...

If you do not set a channel at install time…

snap install microk8s --classic

…the snap install will default to the latest current stable version, e.g. ‘1.27/stable’.

In this case you will get periodic snap updates to the current stable release at the time of the installation. Updates will not include a new series, only patch releases. This means that MicroK8s should continue running normally, even when a new series is released.

To use a specific version of Kubernetes, you can use the --channel option. For example, to install MicroK8s and let it follow the v1.24 stable release series you can run:

snap install microk8s --classic --channel=1.24/stable

In this case you will only receive updates for the 1.24 release of Kubernetes, and MicroK8s will never upgrade to 1.25, unless you explicitly refresh the snap.

Stable, candidate, beta and edge releases

The */stable channels serve the latest stable upstream Kubernetes release of the respective release series. Upstream releases are propagated to the MicroK8s snap in about a week. This means your MicroK8s will upgrade to the latest upstream release in your selected channel roughly one week after the upstream release.

The */candidate and */beta channels get updated within hours of an upstream release. Getting a MicroK8s deployment pointing to 1.26/beta is as simple as:

snap install microk8s --classic --channel=1.26/beta

The */edge channels get updated on each MicroK8s patch or upstream Kubernetes patch release.

Keep in mind that edge and beta are snap constructs and do not relate to specific Kubernetes release names.

Tracks with pre-stable releases

On tracks where no stable Kubernetes release is available, MicroK8s ships pre-release versions under the following scheme:

  • The */edge channel (eg 1.26/edge) holds the alpha upstream releases.
  • The */beta channel (eg 1.26/beta) holds the beta upstream releases.
  • The */candidate channel (eg 1.26/candidate) holds the release candidate
    of upstream releases.

Pre-release versions will be available the same day they are released upstream.

For example, to test your work against the alpha v1.26 release simply run:

sudo snap install microk8s --classic --channel=1.26/edge

However, be aware that pre-release versions may require you to configure the Kubernetes services on your own.

Strict confinement tracks

MicroK8s now supports a track which conforms to the strictmode of snap installs. Strictly confined MicroK8s is installed via the tracks that include strict in their name. For example:

snap install microk8s --channel 1.26-strict

For more information on the differences between strictly-confined MicroK8s and the classic version, please see this explanation.

I am confused. Which channel is right for me?

The single question you need to focus on is what channel should be used below:

sudo snap install microk8s --classic --channel=<which_channel?>

Here are some suggestions for the channel to use based on your needs:

  • I want to always be on the latest stable Kubernetes.

    – Use --channel=latest/stable

  • I want to always be on the latest release in a specific upstream K8s release.

    – Use --channel=<release>/stable, eg --channel=1.25/stable.

  • I want to test-drive a pre-stable release.

    – Use --channel=<next_release>/edge for alpha releases.

    – Use --channel=<next_release>/beta for beta releases.

    – Use --channel=<next_release>/candidate for candidate releases.

  • I am waiting for a bug fix on MicroK8s:

    – Use --channel=<release>/edge.

  • I am waiting for a bug fix on upstream Kubernetes:

    – Use --channel=<release>/candidate.

Changing channels

It is possible to change the snap channel using the refresh command. E.g. to transition to the latest alpha:

sudo snap refresh microk8s --channel=latest/edge

Changing the refresh schedule

By default, snaps are set to check for updates and automatically refresh to the
latest version (for your selected channel) four times per day. For deployments where this behavior is undesirable you are given the option to postpone, schedule or even block automatic updates. The snap refreshes page outlines how to configure these options.

2

I see latest/stable in my “snap info microk8s”. Should I not follow that? Would that upgrade my cluster to a different series?
Also one of the benefits of having channels is having the ability to have some of your installs follow the beta channel or edge channel. If I have a ha cluster is it ok to have some nodes in the cluster follow different channels?
Also it looks like you can upgrade between release series on other platforms like gke. Are they doing something special? Are they doing the equivalent of “reinstalling microk8s” like what is being suggested here?
The version skew policy shows compatibility between different release series… Is that just API compatibility and not compatibility of information in dqlite or something?

3

@sixcorners The idea of selecting channels is so that you know what you have got and aren’t surprised when a new release may upgrade to a new series. So, for example if you follow latest, you will be kept in sync with the latest stable version (currently 1.19). However, when 1.20 is released, your node will upgrade itself to that. In the case of MicroK8s itself, apart from when mentioned in the release notes, this is unlikely to cause any issues. However, Kubernetes itself is only guaranteed to be backward compatible within its own series (and every release comes with plenty of API changes and deprecations) so the issue really is that your workloads may not continue to work after an upgrade, which is something MicroK8s can’t know in advance. So, which channel to use really depends on your use. If you are running workloads you want to continue running, it is useful to stick to a specific series, and/or upgrade when you choose to. If you are running more ephemeral workloads for tests etc, then you may be better off just following latest.

4

Ah. So for instance my rbac.authorization.k8s.io/v1beta1 stuff might end up breaking? The API is already deprecated. When it’s removed kubernetes probably won’t upgrade it. If I followed latest then I should expect that eventually it will just essentially disappear? Is there a script or something to check to see if it’s safe to upgrade? I wonder what gke does if I attempt to upgrade and am using APIs that are removed in the new version…

Also does it make sense to have different nodes in a cluster have different versions? Is it ok to set a node to 1.19/stable, another to 1.19/beta, and the last to 1.19/edge? I’m guessing it’s not ok to have a cluster with nodes of different release series.

5

Yes, exactly that. We don’t currently have any tools which check your deployments to see if they are safe to upgrade, and there is no upstream tool either. I have been looking at this:

which maybe useful

I think things are always going to run better if everything is running the same version, but I don’t think running /stable and /beta would cause many problems if you needed to do that. @kjackal - you have any advice here?

6

I do not think this makes much sense. You would better run a separate staging cluster with all its nodes follow the beta or edge channels.

Running a “mixed” cluster with nodes from beta/edge and stable will not help in reliably identify breaking changes and will make debugging really challenging. Let me give you an example, suppose you have one such “mixed” cluster and your workload breaks on a specific snap revision. You will need some luck to get k8s schedule your workload on the node from edge and then you should have great timing to catch the error before k8s reschedules any failing pods to other nodes.

7

It would be helpful to have some explanation of how channels can be traced to a commits and branches/tags. For example. I enabled helm3 and found that it’s version is 3.0.2. The latest version of helm is 3.5.2. I see that the enable.helm3.sh has been updated to 3.5.0 in github , but It isn’t clear to me how I determine which channels currently include that commit.

8

Hi folks,

Installing 1.20 and enabling storage and dns leads me to this error, but with 1.21 everything works fine.

Shouldn’t we suggest installing 1.21 rather than 1.20?

$ snap install microk8s --classic --channel=1.21
9

Thanks, I updated the example, but it is really an example. We aren’t suggesting that people should choose 1.20 over 1.21, just pointing out that you can if you want to! The main install page has specified 1.21 as the current version since the release.