151–160 of 194 posts
I mean, I've built a Kubernetes-y thing for my own needs, mostly "scheduling" LXC and FreeBSD Jails, and it needs hella less than 256MB of RAM and it's around 20MBs. Maybe I should clean the code and publish it.
I find it humorous how many people in this thread seem so willing to use this in production. If you can't make Vanilla upstream Kubernetes work, it is very ill advised to think you will be met with success using a heavily modified fork that has a fraction of the support of K8S.
> Only Uses only 512 MB of RAM. One can literally run a full fledged Java EE server in 64mb of Ram. What?
Earlier quoted context omitted.
Based on the README [0], quickly comparing to Swarm: - this has the same great K8S API, that Swarm lacks. (Deployment is a first class citizen in kube land, but you only have to make do with the service YMLs in the Swarm sphere.) - k3s lacks some in-tree plugins, that swarm might have (mount cloud provider managed block device), but there are out of tree addons - sqlite instead of etcd3 [but available], so out of the…
> this has the same great K8S API, that Swarm lacks. (Deployment is a first class citizen in kube land, but you only have to make do with the service YMLs in the Swarm sphere.) With all due respect, some (like me) consider that a feature of Swarm. If k3s comes with the same API (and implicit yaml complexity) of k8s, but just reduces RAM usage...well that's not very interesting for me. Docker Swarm is very lean - ther…
Would love this or something similar for local development. Currently using the Docker for Mac k8s and it shreds my machine and end up with an hour of battery life. Had similar experience with minikube.
Also curious if this can run on osx.
I mean, I've built a Kubernetes-y thing for my own needs, mostly "scheduling" LXC and FreeBSD Jails, and it needs hella less than 256MB of RAM and it's around 20MBs. Maybe I should clean the code and publish it.
Your project does sound very cool but I don't think provides a fair basis of comparison re: size and RAM usage.
This is extremely welcome. Kube needs to glom on to all available architectures to fulfill its destiny, to some extent, and the memory/cpu usage of kubeapi et al. can be prohibitive for small setups. Having to revert to ansible/systemd in "some cases" really weakens the story of a universal datacenter O/S. My hope is for more competition for development k8s (or k3s!) - minikube and docker-for-desktop is plagued with…
Earlier quoted context omitted.
I think (s)he was talking about BEAM. Using RabbitMQ makes no difference if you're not programming in Erlang. If you look at the BEAM VM you will see isolated processes, supervisors, restart strategies etc. Wikipedia[1] lists Erlang's runtime system characteristics: "Distributed, Fault-tolerant, Soft real-time, Highly available, non-stop applications, Hot swapping, where code can be changed without stopping a system.…
So you're suggesting we use BEAM instead of Kubernetes? So just rewrite all our code in Erlang, including off the shelf products we didn't write? Then use some other technology to deploy the software, configure the machine, come up with a way to do service discovery, attach block devices to nodes, and automatically provision new machines based on resource usage? It doesn't make sense yet it's seemingly repeated on ev…
Similar to what Envoy is when you do service mesh, you don't need to integrate libraries into your code to get service mesh features using Envoy as side car proxy.
I have that conversation with Erlang users on every k8s topics, they seem to miss the point that decoupling features outside of the language / runtime is the way to go.