All right, for a clock. Thanks for coming, so my name is Tom, I'm a bit of an alien here,
because I'm one of the guys from the cloud native communities, so usually we operate
with APIs and not with hardware, so this is going to be interesting, oh, this is maybe,
we need that for the recording, right? Okay. Yeah, so I'm about to tell you about something
about Kubernetes on Resk 5, so I'm a maintainer of KZOS, which is a CNCF host at Kubernetes
distribution. I'm working at Mirantes at the open source program office, and I'm one of the
maintainers, and we have KZOS, and it's sibling project Cosmachon. KZOS is, does anybody know what
that is? Actually, no one does anybody know what K3 is? Yeah, it's kind of like that, it's a Kubernetes
distribution, so like you have a Linux kernel and like your distributions, it's rather like this,
right? And I'm not going to tell you anything that you already know, because like I'm coming
from the complete out of front, I have been here in this room for the whole day, and I was listening
to the stuff that you were presenting, and I was thinking, wow, I don't have, I didn't have a clue
about this, so this is not, so I'm coming from the direct, the other angle, but I can tell you what
I will do today, so as a fast maintainer of Kubernetes related project, I will just try to share my
experiences, and what it took us to make KZOS workable on risk five, and what does Kubernetes
on risk five mean for me, or for you, maybe it's clear to you, maybe not, let's see, and if you
have any questions or comments just like shoot and ask directly and don't wait until the end
of these, and yeah, so what does that mean for the KZOS project, and one, one more important,
the most important part of all of this is like how to build, what's your architecture, or the
IMGs, so, because that is how Kubernetes distributes its stuff, and so we will be talking about
a bit of, a bit how to do that, right? And in the end, I will also have a demo, if the demo
starts with me, I have a set up there with the risk five, four, which is a battery powered,
so let's see if the Wi-Fi, let's thank you, let's see if the Wi-Fi has good connectivity,
otherwise I will need to switch back to the serial cable, let's see, okay, so what, what,
why did I even try to do it, right? So I, I was not nerds night on this, I promise, you know,
yeah, so I have to come up with some considerations, why do I want to do this? Obviously a risk five
is the future, but for me, this is not enough to justify work on this, so I have to come up with
some other like considerations, in this case, porting stuff makes the project better,
it usually also like uncovers backs in everything, and it makes the whole software a bit
better and and rounder and everything, and also of course it's the hot stuff and it's interesting to
do that, right? And yeah, finally enough, I mean, yeah, I mean, I learned today a risk has a 32-bit
mode, I'm not talking about this, we do support 32-bit architecture, and this is not that easy
for example, RMB7, it's especially like in the in the high level of the stack that is always like
problems if you're trying to build something for RMB7, all right, but what does it even mean,
Kubernetes on risk five, so for once you need to know like Kubernetes is basically
analogous to Linux kernel, right? If you're saying you're running Linux, you're not saying
anything, and like it's the Linux kernel, but you all know there has to be a distribution that you
will be using, you have to have the user land in place and all that stuff, and it's comparable
to that in the Kubernetes landscape as well, so Kubernetes at the core, like the cloud kernel,
if you want to call it like this, and then you need basically on top of that whole ship load of
other software that you will be running on that, and from that point of view, it is like if you're
running Kubernetes on risk five, it's like an app or it's like an empty app store, you know,
and OS with an empty app store, you can run the OS, yes, but you can't do anything with it, and
where this is a bit different from like where the analogy no longer holds with all those
distros, so if you're deploying Kubernetes, you're just having that foundation, and there is no
like distribution that packages everything else for you, like if you're installing fedora or arch
or whatever, you have a whole sheet load of software repositories where you can just grab your software
and run on it, so if you would like, for example, go and convince the distribution to support
risk five, they will have a coherent place where they can work on software, and where they can
make it, where they can define processes, build standards, and all those kinds of things,
they can, for example, also like set up a test farm to like build and test the software on
the native architectures, and all of that is not true for Kubernetes, so Kubernetes, like
the software that you run on that is containerized, of course, so you have all those OSI images,
and along with those OSI images, you also have like helm charts, configuration files,
all your Kubernetes resource manifests, right, so for example, the OSI images are
so to say the binary, the binary chart balls, which contain all your binaries,
and the resource manifests in the helm charts are basically installation scripts, if you want to
follow that analogy, and that leads to the fact that you have all of your software stack,
which is like cluttered around like how many different organizations and and upstream projects
and whatnot, and they all have to find their own solution, how to support risk file,
and so let's have a look at Kubernetes, the core itself, it currently doesn't officially
support risk file, so you can find pre-built binaries for risk file or any test coverage or
anything of that, it's just that you're on your own, there has been like community
requests of supporting that, but for the aforementioned reasons, they're usually not
willing to like put that into official upstream for the lack of manpower, for the lack of
testing infrastructure, and all of those kinds of things, and there's currently not enough like
downstream demand from folks to support that, and that is also like well, why most of the big
are companies, which are usually like playing in that cloud native area, and supporting a lot
of the resource work that's happening there, they're not having this on their radar, and they're
not putting money into this, and that's hence it's not very much moving there, right?
That's it, like if you grab the sources and go for it, it mostly works, right?
But then you're basically like Linux from scratch, you're Kubernetes from scratch, right?
So you're doing all this stuff yourself, for case 0S, which is a Kubernetes distribution, so
we are packaging like core Kubernetes plus plus a few add-ons and make it easy to install and run
more or less, hopefully, if not like showed at me, we're currently at like a
quote-unquote TS3 level for risk file, so we are officially supporting it, but we're not doing anything
like testing or preparing binaries for this, and all of our stock, all the images, most of all
are stocking, all the images support risk file, there is like a few things missing, but that will
be just a matter of time until we fix that as well, and what you can actually do with KZRS,
you can like check out the sources from GitHub and run make on a risk file board, or on a risk
file machine, and then you get a risk file binary for KZRS that you can directly run.
Some features are not supported, which is mostly because of the OSI images haven't been
converted yet, for example, the Kalyko, which one of the CNIs, the container network,
which king implementations, it's not supported, so we have in KZRS, we have two of them,
so you can only use cube router at the moment, that set like a few days ago,
I just try to make that happen for Kalyko as well, and yeah, it worked in my tests,
so I have to just upstream that to KZRS itself, and then we will have that fixed as well,
and that would be another feature of KZRS, which requires envoy, and envoy is built on basil,
and I'm not sure, does anybody know if the basil blitz system works on a risk file?
Yeah, so there you go, yeah, that is basically the problem with that, okay, um,
so we still have, we have KZRS now, but you don't have anything of these, and if you're usually
running a Kubernetes cluster or multiple Kubernetes clusters, you will all want to have those things,
and there is no, and then you're basically in the land of Kubernetes from scratch,
you have to find all of your projects, check how you can run them on a risk file,
and you manage may vary, so support is growing, especially because of all of all of the
main distributions, which are usually being used in bucket files to build stuff,
they are usually now, they're also supporting a risk file right now,
so that makes things a lot easier for an upstream project to basically adopt a risk file,
but there's of course more to it, so the problem is that you have, you don't have the hardware available,
so of course there's hardware, right, so we have seen a lot of hardware, I mean there's hardware over there,
but the thing is for those projects, it has to be like easily accessible, right,
so the problem is you can't just click on the top or you get left, what have you,
and select risk files in architecture, that is not the thing, you can't go to cloud provider
and get risk file, I do know that scale way has that offering with the risk file on demand machines,
I tried to get some for the demo for today, they're out of stock, so, and that's just what I'm
talking about, and then we're going back again to the initial fact that for distributions, it's
easy, they are building tens of thousands of packages, they have their build farms, they can manage it,
right, it doesn't work for the random cloud native project on the internet, they do need to
rely on public services which make that available for them, so, and I mean for knsurice itself,
I also have the problem that GitHub actions run us on a risk file are more or less, I mean the
last time I checked it was not that easy to run them on real hardware because they're based on
that and there's anybody know how good that network works on risk file, kind of, right,
do they have official builds, okay, second, a build, okay, there are a lot of
community, okay, right, so, right, the community is basically on it, but still no upstream support,
right, and that is a basic problem because like all of those, see, I set up that those projects
are running into it in case you're as of course, they're heavily based on those things and if they
can't run natively, then you have a problem and it is very hard to convince a project for the
single architecture to switch the whole CI system or to like introduce another CI system just to support
that architecture, so that is also like a very, very important requirement to make the adoption
better, that's it, what we can of course do is emulation and cross compiling, which you probably
are all aware of, so we've been funding this game QMO, you can just run your talker builds just
like you do for the other architectures and then you cross your fingers, wait, six hours also,
and I maybe have built a successful build, so this works, but it is very slow and usually it's
it's not what you usually want to do, you just want to build on the native architecture,
that's usually what we strive for, but you know, things are as they are, so we can't do it like this,
so, the other thing is cross compiling of course, so it depends on what what you're
letting, what the language you're using, like the cloud native ecosystem has, has its edge on go,
so many of the projects are in go, which makes things a lot of easier because go as a cross compiling
from the beginning, so you can usually just say on your native architecture that you want to build for
it's five and then it will produce risk five binaries, just like for example LLDM can do the same
with playing and so on, which is not as easy with GCC because it's not the cross compiling
from the beginning, so you always have to install a lot of cross-to-root chains and stuff like this,
which makes things rather complicated and I'm not really an expert in this, but I think most of
you will agree if I say it is not that easy, especially for your random project on the internet,
and yeah, of course you can also like mix a niche that, this is what we are doing for our
KZOS images, we use like both approaches where applicable because we do have a certain
stuff which is built on C and we need to see compile out there and those are usually run by
our emulation because like setting up a cross compiling to a Chinese is just to just to complicated
in comparison to for example for Go, right, and Kubernetes itself, like it's as I said,
it doesn't support a risk five out of the box, but you can just grab the sources, you need to
patch the build system which is a bit ugly because they are hard coding the architecture they're
supporting there, so the build, the patches are of a trivial but you do need to patch the source
tree and then you can just compile it, so there's no problem in that, but you know the delivery
boy is still not satisfied with this, and there you go, and that brings us to the most important
part of this of of bringing risk five or bringing Kubernetes to risk five, where risk five to
Kubernetes are both together, you have to have a look at how Kubernetes package software,
so how many of you do have a good idea about multi-arch, OCI images, what that is, not so many,
okay and OCI images basically five systems snapshot plus a layered five systems snapshot that you
can download from the internet and then you extract that and and run that containerized and multi-arch,
OCI images are basically an envelope version with different images, so you can basically look
up in the envelope which image to choose, so you have basically multiple architectures in one
envelope and when you're downloading that image you can select the right architecture for your
target, and that's how you usually want to build the OCI images, the thing is why do you want to
use it like that, because otherwise you would have to publish a new image under a new name,
so you have usually OCI registries where images have names and versions, and for example if you
want to have a cluster which has which runs x86, arm 64 and risk five together in in one cluster,
you don't want to configure all your stuff differently for each architecture, so you just want to say,
okay well I will install engine x, so and that's the system figure out what engine x actually needs to
be pulled like the risk five one or the 164 one and so on and so on and so forth, so that is the
way to go, and then we can like you look at how to how to actually build OCI images, you can
various different techniques like you can just use plain Docker build and put them build and
build all those images separately and then package them together by a manifest, there is also like
commands for this, then you can like do low level planning, with CLI tools, with build a and stuff
like this, so there is a lot of ways to do it, we are doing it with Docker build links and put
main build links, which is probably for KZ West the most easy part, and if you want to know more about
this just ask me, just connect I'm happy to talk about that, so that is usually the way you do it
with Docker build links, you just say you run the same Docker file for multiple architectures,
and the result will be that you have like the same the same image being built for those architectures,
and this automatically includes things like emulation with a Qemu and Benfund miss,
and this is usually an easy way to get started with risk five, you can do cross compilation without
without emulation in the same Docker file, so there is for example the trick that you can say
dash dash platform equals build platform, that means that you're even if you're targeting risk five,
you're building on the on the build machine, like you on x8664, and that that way you can like
just do the usual cross compilation natively without Benfund miss, and that's usually a kind of
easy way, kind of easy way to to cross compile go, and for example if you use for example
a sequpilar you wouldn't specify platform dash a equals build platform, and then automatically
you would get an emulated build with Qemu, Qemu, another problem is what is if my
what is my upstream build image that I'm using for building doesn't support risk five because of
reasons, then you basically need to like have a switch case in your Docker file to select the
right one, this is the trick, this is a trick that we're using in case you asked to do that for
for the destroyless image, so you can basically hardcode your select statement, so here, so that
you basically select the image via the target argument, which is a bit ugly because you need to
list all the support platforms in advance, even if the base image would support them, but that's
currently the only way to make it work without external tooling, like having different Docker files,
and writing scripts made files whatever around that. Okay, um, when I do my off, obviously I am
in just what I'm doing with this, I want to test them, I need perform it hardware for that,
then we have the upstream kernel support, my experience with risk five is usually that, for example,
for that TH, 15, 20 bucks I have over there, there is usually weird kernel force trees out there,
which are not very much aligned with upstream, and then like things like the CNI, which is networking
stack, or CSI, which is storage, storage, stack, storage, stack in the cloud native world,
come along and want to require what not kind of kernel features that you need to enable,
and usually then you're in a in a in a bad trouble and trying to fix your fix your kernel
builds and try to to compile the right modules and then you realize that it's not easy as you would
just take an upstream kernel, which is much easier. Yeah, and get out of actions I already mentioned.
All right, so let's see, if I have connectivity to my little, to my little system there,
oh yeah, it's working. So basically this is the, this is the risk five board over there,
it's T8, 15, 20, as I said, and now I also like have thanks to Natanel Cooper from from the
outpine community, I also have a thing in the cloud, which is also the same device, but this is one
of the outpine risk five CI nodes, which which Natanel has landed to me for this demo today,
so I have something in the internet, and we have a source free there, right, we have a source free
here, which is like the latest KZRS tech, and you can build it with make,
which I did it and we tried it before, I just I'm just skipping it right now, because I,
oh god, this is, I hope it won't yell at me. All right, so we do have the KZRS binary here,
and now we want to run a Kubernetes control on this machine, I have set up a config file here,
so what I, what I need to do is I do need to run Q Bruta as a network provider, I want to run
kind as a storage engine at CD would work, but at CD still wants this pesky at CD at some
portage argument, so we still we just want to have a single controller, so like that
thing is fine, that we can just use kind, you just need at CD if you want to have a highly available
control plane, and then we need to patch the connectivity image, because like when I prepared that
demo like a few days ago, I realized that missing test coverage may break things that have been
working before, I needed to patch our risk file variant exactly in the in the code that I showed
before, where I had that select statement for the code, where I had different base images,
and the base image for risk file was a bit different from from that from the rest of the
architectures, and we needed a single instruction to add there to make that work, so I have
to override the connectivity image, and we can't use the baseline KZRS common activity image,
but I mean that's just the fix is a pull request away, you know that, so I'm just installing
a controller here, KZRS install controller right, and then I want to run that controller, KZRS
start, looking all H top, five, okay now things start to work, you need to wait a bit,
kind comes on, connectivity server, cube API so it's a fourth, so this is starting up nicely
apparently, and now we want to have a worker, so the worker will be the device on the on the desk
over there, to join a worker we need to token, we create a token, what on typing are there any questions
so far, okay, okay I have a token here, now I'm going back to my desk system, now I'm trying to
join
oh gosh the connection slow, a Cp, oh there it, there you go, I'm copying over the token hopefully,
yeah, and now I can just run my KZRS worker,
I'll of course not,
there you go and hopefully, we see things happening, yeah let's see
boy vice, a bit slower
Where's my?
There is.
Ah sure, I'm an idiot.
I have to do it on the control plane.
Right.
There you go.
It's a bit slower than expected, but it will be working in the end.
I just wanted to deploy an engine X on top of that.
Just a standard engine X deployment.
Just to prove that we can actually run something on it.
Right.
And now.
So that.
Okay, the Wi-Fi is a bit slow.
But in theory, like the engine X should come up.
And you should be able to test it from the Wi-Fi if you have the IPv4 Wi-Fi on.
By the port.
380.
And.
The address is 151.16.
132.51.
Which might be in my browser history.
And maybe.
Maybe I see something.
Or not.
All right.
So.
I'm over time already.
So any questions.
Yeah.
That's the slide.
Yeah.
Sorry.
What.
What would it take to make KZRS?
T1 platform or risk 5.
T1 platform for KZRS.
So it is.
The built hardware.
We need to build and test it somehow.
So right now.
One thing could be you could like try to contribute upstream cross compilation support.
So that you can cross compile KZRS more easily.
So that we can could like set up the pre compiled binary is already cross compiled.
But then we could could at least not provide test support for it.
For that we definitely need real hardware.
Yes.
So the question was that K3S has of course the same problem with that city.
How do we get at city folks to make risk 5.
Supportive platform?
I think just pushing for it.
I'm not even sure what what it even means to not be supported.
I mean it compiles it runs.
Maybe they do it for the same reasons as we are doing it to tell them.
Okay.
This is unsupported because they don't have test coverage.
I think I'm not sure.
I'm just guessing.
But that would be my guess for the same reason that many projects don't support risk 5.
So the problem is the image portion is not really.
Can not handle this 5 yet.
Can not push the range or it's may or because they may or hold the image.
No, no you're kidding me it's that easy.
I mean okay the statement was that there's the container registry which doesn't support risk 5
because they're doing some mirroring with container registry and everything.
So it's not even that they can't build the risk 5 image.
They can't distribute it.
You can't build it because I build both of them.
We do too.
Yeah.
So maybe just going just going to the Etsy report just going to the CNCFs,
like or Kubernetes like whatever they use and just ask,
be kind and ask.
Would be good.
I mean it's working.
It just needs that pesky environment variable exposed.
Yeah.
Okay, now we talked about Etsy.
Now we're talking about Kubernetes upstream itself.
I think we need to kick some big company asses.
Sorry for that.
I mean it's all about like if there's money behind it,
they will like do it directly.
And right now it's mostly community driven and like the hot asset,
the hotware isn't there.
So the folks are not there.
Like many folks are contributing for bigger companies.
So I think that's a bit of momentum that is missing there.
But that's just my two cents.
I could be wrong on that.
It's just me guessing.
A couple of days ago, cloud fee has mirrored all the
builds to Kubernetes.
And I'm not providing this pipe in.
Can I have a second?
Cloud fee project started.
And that fit now all the people of the images for this five.
About six.
Okay, cloud fee.
Okay.
And they are doing what exactly?
The native Kubernetes.
Oh.
Okay.
So cloud fee is publishing risk five.
Builds of Kubernetes itself.
A couple of days ago, I saw the heat today.
But then I saw that they are doing that now.
Nice.
The build that are just five to support them.
Yeah.
Nice.
Cool.
Anything else?
Okay.
I'm done anyways.
Time-wise.
Thanks.
Thank you.