31–40 of 118 posts
Anyone know how this compares to k3s? I’ve been using k3s for a while, and there have been a few bugs that made me a bit annoyed
I don't see all of these in microk8s. I'm not sure if this is on the roadmap.
I'm also not sure how customisable microk8s is. We run k3s with haproxy ingress (which is not the default) and calico for network (again nog the default)
writing one application was hard so instead let's assume writing lots of tiny applications will be easier (???) but isolating them is hard so let's put them in containers but running containers is complicated so we need orchestration managers like kubernetes or something but running those things is too hard for someone whose job isn't to run kubernetes for a living so microk8s or minikube or k3s or whatever? that's t…
No, that's not what we're doing at all. I agree that "microservices" is mostly useless hype but running applications reliably and efficiently is an ongoing challenge which Kubernetes solves pretty well. Of course it does shift the complexity into the underlying K8S so installing and operating it can be difficult but there are manys to avoid that as a user. Overall you gain much more in productivity and usability, whi…
Is it? I can take a program written for Windows 95 and run it on Windows 7 (maybe even newer) just fine and it will run reliable and efficiently and integrate better than containers.
It is problem only on Linux because user space ABI keeps breaking.
Notice that the containers run on the same linux kernel and not in VMs, why? Because "we do not break userspace!".
writing one application was hard so instead let's assume writing lots of tiny applications will be easier (???) but isolating them is hard so let's put them in containers but running containers is complicated so we need orchestration managers like kubernetes or something but running those things is too hard for someone whose job isn't to run kubernetes for a living so microk8s or minikube or k3s or whatever? that's t…
Gotta say, the docker ps output on those machines looks like line noise to me.
Not all movement is progress. Young developers are incentivized to embrace new technology because it levels a playing field where time with a tool is your most important asset. That playing field is not real, but a lot of managers seem to think it is, so the strategy works. I don't know how we sell a different version of reality there, but we need to figure it out.
At my first big job, the oldest developer told me shortly before he left that essentially we keep facing the same set of problems in a loop, and that if I watch for it I'll see it happening. That was in many ways a very big shoulder to stand on.
That challenge, added to historical information I had learned in a class on distributed computing, changed my perception of my first loop, like I'd found a shortcut. In my second loop, I found myself having productive conversations with people on their third loop, while my coworkers were still chirping on about how it's going to be different this time.
We just keep playing a game where the rules (like cost inequalities between resource classes) get tweaked every game, but quite often they revert back to the previous rules in the following game (because the people who make hardware for that resource finally figure out how to fix their bottleneck). But instead of recycling or democratizing the tech that worked last time the rules looked that way, we reinvent it badly with new names.
Elixir is a rare exception in this case, which is part of what attracts me to it. It's essentially recycling 25% of Erlang and 45% of Rails and being transparent about it, creating a new recipe out of old ingredients that have worked well in the previous 4 tech cycles.
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 because it seems intimidating. Use managed k8s services.
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…
Same story with IBM OpenShift and their telemetry.
Earlier quoted context omitted.
Same story with IBM OpenShift and their telemetry.
As the person who has worked on making sure telemetry is useful and valuable for users and customers (helping drive insight into quality of kube and close the loop on fixing persistent issues), can you provide some more details about how we’ve let you down? We tried to be as responsible as possible but obviously we’ve failed along the way - what can be done to improve it?
The comment I am replying to is complaining about Ubuntu calling home, IBM OpenShift is the same story.
Is there a run down on how much memory these Kubernetes flavors use? I run Docker Swarm at home because my cluster is older, decommissioned machines. The Swarm daemon uses about 50MB of resident memory, which leaves a lot of room to run containers with little overhead.
It doesn't use a ton, but in order of least-to-most lightweight IME it's Minikube -> Microk8s -> k3s
But again, the overhead is marginal so it's not a world of difference.
If you can run Swarm you can definitely run one of the lightweight k8s distributions.
Earlier quoted context omitted.
I work in this space (being purposefully vague), you are getting a customized image of some sort - PXE really isn't related in this way, that's just a method to get the image onto the destination disk. The official Canonical Ubuntu Cloud Images produced for use this way have the MOTD behaviour and snapd in place based on my exposure to them. https://cloud-images.ubuntu.com/
we are using this thing — http://archive.ubuntu.com/ubuntu/ubuntu/dists/focal/main/ins... , it is loaded with PXE. It doesn't put a "customized image of some sort" on servers, it literally iterates through installer steps with the autoanswers provided by preseed file. You might say that it is customized since we wrote a preseed file. Well maybe, but it's not a "customized image". Also we didn't write any specific cod…
I say all this above, but I'm sure there are still shops out there burning ISOs to CDs (maybe USB now!) and hand installing everything - if I've learned anything, it's that nobody seems to agree on how to do stuff the same way. :) Each company is it's own beautiful unique snowflake full of their own design and deployment patterns.
This is very interesting, we're seeing a lot of Kubernetes "flavors" coming out that remove the etcd requirement. It's no secret that etcd is a key part of why Kubernetes is complex--etcd scaling/securing/recovery is really hard. I think Kubernetes would do well to make swapping out the storage backend possible without having all of these forks. Kubernetes is too tightly coupled to etcd, and for little benefit. I wou…
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…