Earlier quoted context omitted.
I want to use them because I'm not paying for it and managing your own hardware is a pain in the ass I'd rather avoid when I could just code instead. Which is not to say that using your own hardware isn't smart, but it is definitely miserable.
But you don't "manage your own hardware" if you are renting VMs, which was the question here. Also managing a cloud infrastructure is a lot more complex than running Debian and Ansible on a VM.
I Didn't Need Kubernetes, and You Probably Don't Either
421–430 of 436 posts
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#422OP I'm on firefox 131 on Ubuntu and your site is basically unreadable. Dark background and the text is the faintest of shades lighter. I don't mean this in a nitpicky way. Normally I'm fine with most sites. I have to highlight the text to read it.
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#423Earlier quoted context omitted.
What about your integration makes it a huge pita?
It's just a lot of stuff; we have a couple hundred services, and when I've had to add shit, it ends up with me updating like two hundred files. Infrastructure as code is great, but lets be honest, most people are not thoroughly reading through a PR with 200+ files. There's of course tpl files to help reduce duplication, and I'm grateful for that stuff when I can get it, but for one reason or another, I can't always d…
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#424Earlier quoted context omitted.
Kubernetes in Action
A book from 2017? Is that still relevant to understand a modern Kubernetes cluster? The CNCF ecosystem looked a lot different back then.
Then you can hit other resources (in my case working with a team who've been using K8S for a few years).
If you (or anyone else) has suggestions for something newer and covering more than just the core (like various different components you can use, Helm, Argo, ISTIO etc etc) then I'd appreciate it :-)
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#425Earlier quoted context omitted.
Kubernetes in Action
A book from 2017? Is that still relevant to understand a modern Kubernetes cluster? The CNCF ecosystem looked a lot different back then.
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#426Earlier quoted context omitted.
Is nomad still around?
Thanks, hadn't heard of that. Seems pretty active per its commit activity: https://github.com/hashicorp/nomad/graphs/commit-activity But the fact that I hadn't heard of it before makes it sound not very popular, at least not for the bubble I live in :). Does anyone have any practical experiences to share about it?
If that's popularity that you need, then sure, nobody ever got fired for choosing kubernetes.
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#427Earlier quoted context omitted.
Yaml is declarative, you tell k8s what you want and how it looks. For shell scripts, try proper error handling. You start doing some catch hooks, you have issues cehcking error codes of different tools, debugging is hard too. In one infra project we swtiched from shell scripts to golang just to have a lot more control/stability of our scripts.
YAML is not declarative, it's a format. Well, according to Wikipedia it's a "data serialization language". IMO It's also bad choice for this, and those files become unreadable and hard to work with. Agree that shell scripts are also hard to work with, especially if you did not write them yourselves. I guess it's a combo of the language features of, say bash, and that no one who writes them really know bash. I mean, a…
What i like with that declaritive setup: The other side, the executer, can be actually something reasonable to build and be reused. This strategy or architecture, feels a lot better than the classical approach especially because its so so often always the same thing.
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#428Earlier quoted context omitted.
I can imagine. Do you have complete automation setup around maintaining the cluster? We are now on-prem using “pet” clusters with namespace as a service automated on it. This causes all kinds of issues with different workloads with different performance characteristics and requirements. They also share ingress and egress nodes so impact on those has a large blast radius. This leads to more rules and requirements. Hav…
> This causes all kinds of issues with different workloads with different performance characteristics and requirements. Most of these issues can be fixed by setting resource requests equal to limits and using integer CPU values to guarantee QoS. You should also have an interface with developers explaining which nodes in your datacenter have which characteristics, using node labels and taints, and force developers to…
When running on “bare” VMs each VM is its own member in the network. The pods in the cluster use an overlay network and egress is limited to egress nodes which are now shared by all workloads.
Having dedicated K8s clusters would reduce the sharing of network ingress and egress as well as choose the vm size for my workloads.
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#429People talk about Kubernetes as container orchestration, but I think that's kind of backwards. Kubernetes is a tool for creating computer clusters. Hence the name "Borg" (Kubernetes's grandpa) referring to assimilating heterogeneous hardware into a collective entity. Containers are an implementation detail. Do you need a computer cluster? If so k8s is pretty great. If you don't care about redundancy and can get all t…
This has got to be the most out there k8s take I've read in a while. k8s doesn't save you from learning your cloud providers infrastructure, you have to learn k8s in addition to your cloud provider's infrastructure. It's all ALBs, ASGs, Security Groups, EBS Volumbes and IAM policy underneath and k8s, while very clever, isn't so clever as to abstract much of any of it away from you. On EKS you get to enjoy more odd li…
But the idea of Borg is that all of that's abstracted away for the typical developer. It's the same with k8s. The infrastructure team in your org needs to understand the implementation details, but really only a few.
You can also configure load balancers, IAM groups & policy etc as k8s CRDs. So all that stuff can be in one place in the code base alongside the rest of your infrastructure. So in that sense it does abstract those concepts. You still need to know something about them, but you don't have to configure them programmatically yourself since k8s will do that.
Re: I Didn't Need Kubernetes, and You Probably Don't Either
#430Earlier quoted context omitted.
Just because you're using VMs doesn't mean you're now dealing with state. It's 100% possible to have stateless VMs running in an auto-scaling instance group (in GCP speak, I forget what AWS calls them)
Once you have the tools to manage all of that, you effectively have kubernetes. Container vs VM is largely irrelevant to what the op is complaining about when it comes to k8s. People that don’t like k8s tend to be fine with docker. It’s usually that they don’t like declarative state or thinking in selectors and other abstractions.
I paired with one of our platform engineers several months ago. For a simple app that listens on Kafka, stores stuff in PostgreSQL and only has one exposed port... and that needed at least 8 YAML files. Ingress, service ports and whatever other things k8s feels should be described. I forgot almost all of them the same day.
I don't doubt that doing it every day will have me get used to it and even find it intuitive, I suppose. But it's absolutely not coming natural to me.
I'd vastly prefer just a single config block with a declarative DSL in it, a la nginx or Caddy, and describe all these service artifacts in one place. (Or similar to a systemd service file.)
Too many files. Fold stuff in much less of them and I'll probably become an enthusiastic k8s supporter.