References: <20221010173022.3aea41fe@ncopa-desktop.lan>
User-agent: mu4e 1.8.9; emacs 28.2
From: Nico Schottelius <nico.schottelius@ungleich.ch>
To: Natanael Copa <ncopa@alpinelinux.org>
Cc: ~alpine/devel@lists.alpinelinux.org
Subject: Including kubernetes in Alpine stable [was: Upcoming feature freeze]
Date: Mon, 10 Oct 2022 20:17:23 +0200
In-reply-to: <20221010173022.3aea41fe@ncopa-desktop.lan>
Message-ID: <87r0zfpl08.fsf@ungleich.ch>
MIME-Version: 1.0
Content-Type: text/plain


Hey Nate,

Natanael Copa <ncopa@alpinelinux.org> writes:

> Hi!
>
> I will start work on setting up the builders for 3.17 release this
> week. This means that significant changes to the toolchain and
> bootstrap packages (eg make, binutils, gcc, bison, autoconf, automake,
> cmake etc) needs to happen within a few days or they will have to be
> postponed to after 3.17 release.

one question from my side: is there any chance that we move the
kubernetes related components (crio, kubeadm, kubectl) from testing
to community so that we can versionise k8s releases to make upgrades a
bit more easy? Potentially before the 3.17 release so that we can begin
with "proper k8s" support?

Background:

- At the moment kubeadm, kubectl and friends are only in testing
- For upgrading a kubeadm created cluster, you need to have
  kubeadm version-1 (k8s 1.24.x upgraded by 1.25.y, 1.23.a upgraded by 1.24.b and so on)
- With upgrading via testing, it is possible to jump 1.22 to 1.25, which
  then makes it impossible to upgrade the cluster without getting a
  statically compiled kubeadm from somewhere else

Proposed solution:

- Within one Alpine version keep one specific Kubernetes minor version
  (i.e. k8s 1.25.x for Alpine 3.17, k8s 1.26.x for Alpine 3.18, etc.)

History/Stability:

- At ungleich we have been running k8s cluster for a bit more than 1.5
  years based on Alpine now and besides "jumpy upgrades", there are no
  significant issues
- In regards to schedule and version, a short review whether the
  proposal is feasible:

  2021-04-08 k8s 1.21.0 released
  2021-08-19 k8s 1.22.1 released
  2021-12-16 k8s 1.23.1 released

  2022-05-24 k8s 1.24.1 released
  2022-09-14 k8s 1.25.1 released
  2022-12-06 k8s 1.26.0 will be released

  2021-06-15 Alpine 3.14 released
  2021-11-24 Alpine 3.15 released

  2022-05-23 Alpine 3.16 released
  2022-10-xx Alpine 3.17 released

  Basically, k8s is being released 3x per year, Alpine 2x per year.
  We can change the k8s version within one minor version without
  problem, that upgrade is guaranteed to work.

  However, if we do that, switching from 3.xx to 3.xx+1, we might
  actually jump two versions, which will make the upgrade via kubeadm
  fail. However, we can solve this by adding one extra condition:

  - Every Alpine Linux release would contain 2 k8s releases and as a
    user I must first upgrade to the latest kubeadm version before
    upgrade to a new Alpine Linux minor version.

  How would that look? Given we had phased in k8s before, it would be
  like this:

  Alpine 3.14
         Originally 1.21.x, upgrades to 1.22.x
  Alpine 3.15
         Originally 1.22.x, upgrades to 1.23.x
  Alpine 3.16
         Originally 1.23.x, uprades to 1.24.x
  Alpine 3.17: users need to upgrade to latest 3.16 first!
         Originally 1.25.x, uprades to 1.26.x
  Alpine 3.18:
         Originally 1.26.x, uprades to 1.27.x
  ...


If it is too late for 3.17, no worries, but I wanted to kick off that
discussion, as currently running k8s on top of Alpine requires one to
carefully watch when new kubeadm releases come in.

Best regards,

Nico


--
Sustainable and modern Infrastructures by ungleich.ch