thoughts on k3s and supporting builds of more than one k8s version

thoughts on k3s and supporting builds of more than one k8s version

[Joakim Roubert]

Hi!

I was thinking about k3s, and now that the latest stable k3s is a Kubernetes 1.21 version:
Do we want to have recipes for multiple k3s versions? I'm thinking someone perhaps wants, say, 1.20 to go with a system with 1.21, while someone else perhaps wants 1.21 to go with 1.21 components.
And then have a common .inc-file with everything that is not individual for the versions, and small recipes with the source revision and such for each version.
What are your thoughts on this?

BR,

/Joakim

Re: [meta-virtualization] thoughts on k3s and supporting builds of more than one k8s version

[Yocto]

On Friday 10 September 2021 13:49:24 PM (+07:00), Joakim Roubert wrote:

 > Hi!
 >
 > I was thinking about k3s, and now that the latest stable k3s is a 
Kubernetes 1.21 version:
 > Do we want to have recipes for multiple k3s versions? I'm thinking 
someone perhaps wants, say, 1.20 to go with a system with 1.21, while 
someone else perhaps wants 1.21 to go with 1.21 components.
 > And then have a common .inc-file with everything that is not individual 
for the versions, and small recipes with the source revision and such for 
each version.
 > What are your thoughts on this?
 >
 > BR,
 >
 > /Joakim

I would rather see KubeEdge packaged then another specifically k3s, which 
well i feel is pretty useless overall as kubernetes itself does the job
kubeedge provides more benefit to low resource edge nodes then k3s 
mini-kube would.


 >
-- 
Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com

Re: [meta-virtualization] thoughts on k3s and supporting builds of more than one k8s version

[Paul Barker]

On Fri, 10 Sep 2021, at 09:34, Yocto wrote:
> 

Please don't use "Yocto" as your name on this list, it may come across to folks who are new to our community as if you're speaking for the project.

-- 
Paul Barker
https://pbarker.dev/

Re: [meta-virtualization] thoughts on k3s and supporting builds of more than one k8s version

[Bruce Ashfield]

On Fri, Sep 10, 2021 at 2:49 AM Joakim Roubert <joakim.roubert@axis.com> wrote:
>
> Hi!
>
> I was thinking about k3s, and now that the latest stable k3s is a Kubernetes 1.21 version:
> Do we want to have recipes for multiple k3s versions? I'm thinking someone perhaps wants, say, 1.20 to go with a system with 1.21, while someone else perhaps wants 1.21 to go with 1.21 components.
> And then have a common .inc-file with everything that is not individual for the versions, and small recipes with the source revision and such for each version.
> What are your thoughts on this?

I've held pretty firm on not having multiple versions of anything in
the layer. Multiple providers, yes, multiple versions .. no.

It quite simply splits the testing,  multiplies the support and is
distracting. And honestly, you'll never get any agreement on versions
.. I've been there and done that.

We don't even like to do that with the kernel in oe-core, but our hand
was a bit forced on that front (and arguably the kernel is actually
easier to test).

For a version of the layer that might be released against a LTS, the
plan was to match up a LTS version and "the latest", but for
intermediate/non-LTS releases sticking with one is the goal.

Bruce

>
> BR,
>
> /Joakim
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [meta-virtualization] thoughts on k3s and supporting builds of more than one k8s version

[Bruce Ashfield]

On Fri, Sep 10, 2021 at 4:34 AM Yocto <yocto@optimcloud.com> wrote:
>
>
>
> On Friday 10 September 2021 13:49:24 PM (+07:00), Joakim Roubert wrote:
>
>  > Hi!
>  >
>  > I was thinking about k3s, and now that the latest stable k3s is a
> Kubernetes 1.21 version:
>  > Do we want to have recipes for multiple k3s versions? I'm thinking
> someone perhaps wants, say, 1.20 to go with a system with 1.21, while
> someone else perhaps wants 1.21 to go with 1.21 components.
>  > And then have a common .inc-file with everything that is not individual
> for the versions, and small recipes with the source revision and such for
> each version.
>  > What are your thoughts on this?
>  >
>  > BR,
>  >
>  > /Joakim
>
> I would rather see KubeEdge packaged then another specifically k3s, which
> well i feel is pretty useless overall as kubernetes itself does the job
> kubeedge provides more benefit to low resource edge nodes then k3s
> mini-kube would.

And you'll find just as many people with the exact opposite opinion ..
getting agreement on what flavour / combination of k*s people want to
use, is like us all agreeing on an editor.

Packaging another version of k3s isn't really on the radar, but not
for reasons related to KubeEdge.

I actually have some initial work towards packaging it (as I did for
microk8s), but that won't arrive until after the release, and until
after I've completed refactoring the components and gotten rid of some
of the massive duplication we have in the layer (and have a proper set
of tests for all flavours ...).

Cheers,

Bruce

>
>
>  >
> --
> Sent with Vivaldi Mail. Download Vivaldi for free at vivaldi.com
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: thoughts on k3s and supporting builds of more than one k8s version

[Mark Abrams]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

Bruce this sounds reasonable from a packaging standpoint and also presents an interesting challenge - and one that seems to be broader than just yocto projects. It is a challenge we are seeing for edge deployments of k8s everywhere. Embedded systems are traditionally shipped with longer update/upgrade lifecycles than cloud native software. A typical embedded lifecycle seems to be anywhere from 2-5 years minimum. Kubernetes on the other hand ships new releases about 3x / year.

As we move toward projects that include cloud native technology at the edge, I think we will need to resolve for a more rapid software lifecycle.

One solution I know of when using k3s is the system-upgrade-controller. This can upgrade the k3s binary according to a configured plan. It is also possible to use the same controller to update any arbitrary binary in the system - assuming, of course that these are not residing on the immutable part of the file system. Also, the system-upgrade-controller works with any kubernetes not just k3s.

[-- Attachment #2: Type: text/html, Size: 1058 bytes --]

Re: [meta-virtualization] thoughts on k3s and supporting builds of more than one k8s version

[Joakim Roubert]

On 2021-09-10 14:34, Bruce Ashfield wrote:
>> What are your thoughts on this?
> 
> I've held pretty firm on not having multiple versions of anything in
> the layer. Multiple providers, yes, multiple versions .. no.
[...]

I reckoned you had given good thought to this already—thank you for 
clarifying and sharing those thoughts! Makes sense.

BR,


/Joakim
-- 
Joakim Roubert
Senior Engineer

Axis Communications AB
Emdalavägen 14, SE-223 69 Lund, Sweden
Tel: +46 46 272 18 00, Tel (direct): +46 46 272 27 48
Fax: +46 46 13 61 30, www.axis.com