How I think about Kubernetes

Post by NewJazz » Sat, Dec 27, 2025, 5:03 AM UTC

bigstrat2003 wrote: post #17

websiteapi wrote: post #4

I always wonder if things can be simpler. When you think of a really simple DB you think of SQLite. What's the really simple K8s? Even doing a single node deployment these days seems complicate with Prometheus, Grafana, etc. etc. docker/podman compose up with quadlets and all of this stuff just seems so eh. I really like the idea of something like Firebase, but it never seems to work out or just move the complexity t…

> What's the really simple K8s? It's k3s. You drop a single binary onto the node, run it, and you have a fully functional one-node k8s cluster.

Post by zsoltkacsandi » Sat, Dec 27, 2025, 6:50 AM UTC

antonvs wrote: post #35

zsoltkacsandi wrote: post #7

> Thinking of Kubernetes as a runtime for declarative infrastructure instead of a mere orchestrator results in very practical approaches to operate your cluster. Unpopular opinion, but the source of most of the problems I've seen with infrastructures using Kubernetes came from exactly this kind of approach. Problems usually come when we use tools to solve things that they weren't made for. That is why - in my opinion…

Kubernetes is explicitly designed to do what the article describes. In that respect the article is just describing what you can find in the standard Kubernetes docs. > it is super important to treat a container orchestrator a container orchestrator. Which products do you think are only “container orchestrators”? Even Docker Compose is designed to achieve a desired state from a declarative infrastructure definition.

Post by liampulles » Sat, Dec 27, 2025, 9:45 AM UTC

EdwardDiego wrote: post #42

liampulles wrote: post #33

On the use of GitOps for k8s, I think it makes sense for application workloads, and less sense for raw infrastructure definitions (unless you are running at such a scale that your infrastructure is often scaled like an application). For my infrastructure definition repo, I will apply it in my terminal with kubectl, watch, and then merge the PR/commit to master. I often need to do this progressively just to roll back…

When you say infrastructure in this context, are you referring to the actual K8s cluster infra? Or is it what I tend to call "intra-cluster infra" - DBs / Prometheus / Kafka etc. Infra that support apps?

Post by liampulles » Sat, Dec 27, 2025, 9:54 AM UTC

EdwardDiego wrote: post #43

liampulles wrote: post #34

Earlier quoted context omitted.

One of the issues is that the open source Helm charts (or whatever) for something like Grafana do not come out-of-the-box with good config. I spent a significant amount of time a little while ago reading blogs to get Grafana to use up to date indexing algorithms, and better settings, etc. Considering these companies make money when you use their hosted solution, this is not surprising, and it just goes to show TANSTA…

I like to use operators for intra-cluster infra, they tend to offer a "sorta-managed" experience. I'll use a Helm chart deployed by ArgoCD to provision the operator, then go from there - mainly because I try to limit Helm usage as much as possible.

Post by hbogert » Sat, Dec 27, 2025, 11:13 AM UTC

oogali wrote: post #39

I sometimes joke that Kubernetes is a mass experiment in teaching people how to write Go via YAML. The giant nested YAML you come across is the input (pre-deserialization)/output (post-serialization) for the declared types: https://github.com/kubernetes/api/blob/master/core/v1/types.... Fortunately, or unfortunately, I am the only person that finds humor in this.