51–60 of 138 posts
Another vote for K3s. Easy to set up on a Pi cluster. Pity Istio doesn’t offer an ARM build
The docs say recommended 4gb memory, but could I run a huge swap partition for that?
[1] https://ubuntu.com/tutorials/how-to-kubernetes-cluster-on-ra...
Deploying k8s has gotten a lot easier these days -- some alternatives in this space: - https://docs.k0sproject.io ( https://github.com/k0sproject/k0s ) - https://k3s.io ( https://github.com/k3s-io/k3s/ ) k0s is my personal favorite and what I run, the decisions they have made align very well with how I want to run my clusters versus k3s which is similar but slightly different. Of course you also can't go wrong with k…
k3s is brilliant. we run production clusters on it. The problem with k3s is that the architecture level libraries are a bit outdated. Early on, it was for a particular reason - ARM64 (raspberry pi) support. But today, like everyone is on ARM - even AWS. For example the network library is Flannel. Almost everyone switches to Calico for any real work stuff on k3s. it is not even a packaged alternative. Go-do-it-urself.…
Most of the other choices that k0s makes are also right up my alley as well. I personally like that they're not trying to ride this IoT/Edge wave. Nothing wrong with those use cases but I want to run k8s on powerful servers in the cloud, and I just want something that does it's best to get out of my way (and of course, k0s goes above and beyond on that front).
> The biggest reason for this is a core tenet of k3s - small size. k0s has taken the opposite approach here. 50mb vs 150mb is not really significant. But it opens up alternative paths which k3s is not willing to take.
Yup! 150MB is nothing to me -- I waste more space in wasted docker container layers, and since they don't particularly aim for IoT or edge so it's perfect for me.
k3s is great (alexellis is awesome), k0s is great (the team at mirantis is awesome) -- we're spoiled for choice these days.
Almost criminal how easy it is to get started with k8s (and with a relatively decent standards compliant setup at that!), almost makes me feel like all the time I spent standing up, blowing up, and recreating clusters was wasted! Though I do wonder if newcomers these days get enough exposure to things going wrong at the lower layers as I did though.
[0]: https://itnext.io/benchmark-results-of-kubernetes-network-pl...
Plain k8s has a fearsome reputation as being complex to deploy, which I don't think is quite deserved. It isn't totally straightforward, but the documentation does tend to make it sound a bit worse than it actually is. I run a couple of small clusters and my Ansible script for installing them is pretty much: * Set up the base system. Set up firewall. Add k8s repo. Keep back kubelet & kubeadm. * Install and configure…
I remember about 5 years ago I tried to deploy it on CoreOS using the available documentation and literally couldn't get it working. I haven't done a manual deployment since. I hope it got significantly better and I may be an idiot but the reputation isn't fully undeserved. The problem back then was also that this was usually the first thing you had to do to try it out. Doing a complicated deployment without knowing…
I moved from k3s to microk8s for local development. I gave up on k3s because I needed calico CNI and it was a pain to set up, on microk8s it's just `microk8s enable calico`. I also found k3s a bit too opinionated with the default Traefik ingress and service-lb.
[0]: https://vadosware.io/post/ingress-controller-considerations-...
[1]: https://vadosware.io/post/stuffing-both-ssh-and-https-on-por...
I moved from k3s to microk8s for local development. I gave up on k3s because I needed calico CNI and it was a pain to set up, on microk8s it's just `microk8s enable calico`. I also found k3s a bit too opinionated with the default Traefik ingress and service-lb.
Traefik is probably the best Ingress out there capability wise for now I think. I've written a bit on it[0] before, but IMO that choice is a good one. Even used it to do some fun external-in SSH connections[1]. I also use it to run a multi-tenant email setup (haraka @ the edge + maddy). It's not like NGINX can't run SMTP expose other ports, but Traefik is easier to manage -- CRDs instead of a ConfigMap update. [0]: h…
Plain k8s has a fearsome reputation as being complex to deploy, which I don't think is quite deserved. It isn't totally straightforward, but the documentation does tend to make it sound a bit worse than it actually is. I run a couple of small clusters and my Ansible script for installing them is pretty much: * Set up the base system. Set up firewall. Add k8s repo. Keep back kubelet & kubeadm. * Install and configure…
Earlier quoted context omitted.
k3s is brilliant. we run production clusters on it. The problem with k3s is that the architecture level libraries are a bit outdated. Early on, it was for a particular reason - ARM64 (raspberry pi) support. But today, like everyone is on ARM - even AWS. For example the network library is Flannel. Almost everyone switches to Calico for any real work stuff on k3s. it is not even a packaged alternative. Go-do-it-urself.…
Agreed on 100% of your points -- you've hit on some of the reasons I chose (and still choose) k0s -- Flannel is awesome but it's a little too basic (my very first cluster was the venerable Flannel setup, I've also done some Canal). I found that k0s's choice of Calico is the best -- I used to use kube-router (it was and still is amazing, great all-in-one tool) heavily but some really awesome benchmarking work[0] cause…
Things like proxy protocol support (which is pretty critical behind cloud loadbalancers), network plugin choice, etc is going to be very critical.
Interesting that this is supported and maintained by Canonical (Ubuntu). Maybe it will be shipped inside Ubuntu one day.