91–100 of 118 posts
Earlier quoted context omitted.
It does. Upstream kubeadm - authentic kubernetes - can even run on a single node. Not sure why people choose k3s or microk8s when you can just as easily deploy the real thing.
For smaller needs, K3s runs fast/stable on servers with 1-2 GB of RAM, whereas K8s proper tends to be a little shaky until you go to 2-4 GB, minimum.
Earlier quoted context omitted.
> I just don't trust Canonical much... They lost me when I've tried their ubuntu server when I was lazy one day and greeted with their Landscape advertisement in the MOTD display. Then I installed armbian's ubuntu version because Debian version was not ready and found out that MOTD was downloaded from web every time I log in. Add analytics (now opt-in), forcing snaps and their silent-ish efforts to monopolize the lan…
Putting a single commercial, once, on the MOTD file is a sure way to tarnish the reputation of a whole distribution and its derivatives forever.
I am all for this trend. Microk8s and k3s are both a joy to develop with (though I have ran into a few bugs with k3s so tend to prefer Microk8s). How many folks are running self-managed k8s in production though, out of curiosity? It seems so economical to deploy k3s or use something like Rancher on dirt cheap VPS's from some place like Hetzner -- but what's the ops burden and failure risk like? Never tried it myself…
Earlier quoted context omitted.
Make the telemetry opt-in to begin with. The comment I am replying to is complaining about Ubuntu calling home, IBM OpenShift is the same story.
that's what they call 'opinionated default configuration'; then they tie in subscription management with telemetry so that opting out of it isn't an option to begin with; https://docs.openshift.com/container-platform/4.1/telemetry/... Several further tie ins and the system as a whole becomes barely usable. But then integration is the whole point of openshift, isn't it?
https://docs.openshift.com/container-platform/4.5/support/re...
I will follow up on opt-out being the default for the evaluation version of OpenShift. It is already opt-in for OKD.
Earlier quoted context omitted.
> How is that related? I thought we were talking about running applications reliably. Why is complete linux userspace bundled separately in each container? > Environments and languages change. Yes. > That's entirely different to running programs with zero-downtime deployments, load-balancing and traffic management, health monitoring, logging and observability, secret and config management, storage volumes, security r…
It's a container and can be as thin or fat as you want with it's contents. You don't need to include linux inside if you don't want to. I've built containers with nothing more than a few native executables. It's just a packaging format, but easier to build and deploy than other formats like tarballs. If you don't need K8S then don't use it. What's the problem? Run your app on your server and ignore everything else. B…
See the original comment you replied to, he is clearly complaining about the whole infrastructure and solutions getting too complex for very little benefit, I just elaborated on that point because there is some truth to it. It is not the case for your scenario handling billions of requests per day in multiple regions - that's where it makes a lot of sense to use k8s! But very few applications need that.
> It's a container and can be as thin or fat as you want with it's contents.
But you can't rely on the platform, except for the kernel because linux kernel ABI is stable hence why the containers are done in this way. I am not complaining about it, I am exaplning the reasoning. Now imagine if you could rely on and share more services provided by the platform that just the kernel ;).
> I don't care about the ABI and don't see why that's relevant
Fair enough but then I don't understand why you replied to my comment saying the containers are designed in this way because of unstable userpace ABI if you don't care about this.
> "I want my application to reliably and quickly serve my customers and be easy to maintain and debug." >> That's what K8S helps with
For certain solutions, absolutely! For other solutions a simple stateful applications is simpler and easier to maintain and debug (again, that's how I read the first comment in this thread).
Earlier quoted context omitted.
I don't know of any clustering system that works without some sort of leader. In many cases, the leader is you. If your computer dies, you can walk to another one and still deploy software. If you disappear, that's a Big Problem, however. No modern clustering system is much different. Services aren't killed off if a leader can't be elected. It's just that having all your servers alive but uncontrollable is almost as…
Distributed consensus doesn't require a leader. The same process used to elect a leader (i.e. change leader state) can simply be used to change state generally. See, e.g., There Is More Consensus in Egalitarian Parliaments: https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf In fact, for something like what etcd is used for in k8s, as the root and lynchpin of all state, but not direct application I/O (pods use the…
Note that Kubernetes requires a total ordering of writes (which simplifies how hard it is for us puny humans to reason about) AND requires strong consistency in order to provide guarantees like “this pod only runs on one machine at a time” and “PVs aren’t released until the pods are really stopped”. Leaderless is a simple tradeoff - singleton or three instances. That’s the best possible choice in the world and it’s etcd and it’s relative simplicity that make it possible.
I’ve never seen a production Kube system with HA etcd go down due to non-human error, so I don’t believe single instance is going to give you better availability when single machine faults happen (they happen frequently; about 0.5-1% of the machines in the OpenShift fleet - cloud and on-premise - are down at any one time due to power, software, or hardware issues). Almost all of those clusters tick along fine when they lose that machine.
Earlier quoted context omitted.
A long wished for feature, but closed wontfix a long time ago: https://github.com/kubernetes/kubernetes/issues/1957 :-(
That's a pretty soft wontfix though. Might be reopenable at this point.
It’s more that the core team doesn’t have the time to support these, and we already have a fairly tight contract with storage, and we still find edge cases that need to be fixed, so the extra cost for the committers to support this is high.
Earlier quoted context omitted.
To some extent, the distributed consensus is kind of the important part. If you have a bunch of components that don't know what state they're supposed to be in, you don't really have a cluster. Looking at the marketing documentation (I didn't read the code), they just wrote their own consensus and datastore instead of using etcd. So the underlying fundamental computer science problems still exist, but nobody has been…
fwiw I think k3s also has an option to use canonical's dqlite. Edit: they deprecated the option https://rancher.com/docs/k3s/latest/en/installation/ha-embed...