> Developers want to use Kubernetes in the edge, but it uses too much memory for most devices
...wow, I had absolutely no idea that this was a thing people wanted or a problem folks were out there trying to solve. No judgement, who am I to say with so little information whether it’s a good idea or not, just — what a concept eh
These devices often have bespoke toolchains for deploying and managing software on them. This is an additional barrier of entry: cloud teams need to learn a new toolchain to move to the edge. Moreover, these toolchains often need changes to how release management works. So naturally, the question arises "why can't we just use the same tools that we use in the cloud?"
Right now, Kubernetes isn't the greatest fit for the edge. Distributions such as K3s and KubeEdge try to solve some of the problems with Kubernetes itself, but that's only half of the picture. A large advantage of Kubernetes is the ecosystem of third party operators. So that's what we're trying to address.
I can't think of many projects I've worked on where I've come across that need for performance. How do you handle connecting to a database or cache? Do you have a bunch of databases shaded at the edge? Does the edge talk back to your database that isn't at the edge?
Buzzwords: Kubernetes, WebAssembly, edge
Not saying that with any negative connotation. Interested in learning typical every day problems that require this. I thought edge was for like... get static HTML/CSS/JS/images/video to customers as quickly as possible (sub 50ms)
Why run docker if you can push k8s further down with perhaps less features?
K8s could be as lightweight as nomad.
My quarkus kotlin native image build results in 80mb last time I checked
> Developers want to use Kubernetes in the edge
Why?
Ultimately people want to deploy all their tech infrastructure in such a way that they can address the "treat X as cattle, not pets" problem. No one wants to be SSH-ing into boxes to update container image SHAs. Kubernetes is one way to do this.
You get a lot of stuff for free with k8s that you'd need to reinvent the wheel for otherwise.
Kubernetes is perfect for this kind of scenario--Chick-fil-A HQ runs a k8s control plane that all of the stores and registers connect to as nodes and receive explicit code and other state to run. From a central command they can instantly update everything, monitor it, add/remove nodes, etc. They can do it all with just k8s and kubectl, they aren't bodging together piles of shell scripts, ansible scripts, custom tools, etc.
None of that works or even makes sense if you have end-user devices. Nodes are not interchangeable, you can't route around breakage (if one point of sale goes down, that's one physical device with a dark screen, adding one pod somewhere else won't help), the networking is mostly useless, zero-downtime impossible (you have only one physical screen to use, can't have two containers grab it during a rolling upgrade), service discovery is irrelevant unless you are running your database on those cash registers for some reason.
Use Ansible/Salt/... instead. Kubernetes is hype, and it's what people know, and it can technically do some of those things, but it's a terrible tool for this job.
Have the clients update themselves when new releases are done. Have a backup access method, say, ssh if there are issues.
Corporate can pull all relevant data from couch to know the exact state of the distributed network.
