Hacker News Reader

Comment by deathanatos | Hacker News Reader

Do I need an operator, though?

I'd definitely take something over the insanity that is managed services and constant ticket filing with the cloud vendors, but my gut says I just need a Helm chart that makes it decently easy to, a.) bring up PG & some replicas that hopefully have a decent consistency story and b.) a backup job that can write to S3 et al.

I need a better "seduce to use" for a CRD for Postgres, I guess.

"It doesn’t rely on statefulsets [and manages disks itself]" and "The Kubernetes way" (and dark red on blue, yeesh) … just doesn't inspire me?

View on HN

CRs that simply instantiate an instance aren't all that useful IMO. they're much more useful if you have something like Prometheus' case where they want to attach configuration to various Kubernetes resources and can't easily fit it in annotations.

i don't know that i would actually recommend Helm for much though, since dealing with templates beyond a basic "sub string into field" use case is pain and misery. once you start dealing with named helper templates that operate at different scopes and all but the simplest control flow, the lack of tooling makes debugging templates a nightmare. the operator ecosystem has its own problems (i still can't tell what the extra Red Hat stuff beyond kubebuilder is really helping with and can't stand updating it), but having an actual programming language and all the accompanying type checking and testing tools available is a major benefit.

if you don't need something complex, kustomize feels much less breakage-prone than Helm, though its patches aren't as intuitive to write.

The limitations of helm chart templates are what I like. If you code review shenanigans, it should be a code smell that you’re doing something wrong.

Kustomize is terrible. Trying to build a mental model of the final output while writing is horrible.

Let's be clear: all of the YAML-cum-DSL K8s deployment options are terrible. It's still just templating with extra steps. But Kubernetes is, fundamentally, one big while(1) loop turning YAML into infrastructure, so, eventually, you have to target YAML. It's just unfortunate that we got to "spicy regexes with if statements" and then stopped, instead of using something more robust.

I don't understand this at all, a Kustomize base is far easier to read than a Helm Chart? It's a set of manifests with no templating. I find that it's easy to see what gets patched or replaced in the overlays and there's a lot more fail-fast rather than stringly-typed whitespace nonsense.

I guess your kustomizeations are relatively simple. Just wait until you have 4-5 layers of it, flipping between several files to figure out which file needs to change how, just to change an attribute. With a chart, I just make the change and can work it out, all in the same file.

The place the operator looks to be most useful is updating the db. It'll do "the right thing" updating the secondary pods first, doing a switch over of the primary, then updating the old primary pod.

That sort of action is real hard to do with just a plain helm chart (especially if you didn't plan for it up front).

This. If it’s a database, I’d like the deployment infrastructure to be aware during upgrades and able to execute complex actions

The operator also handles when a node fails or is taken down. An operator can handle replicating to a new replica on a new node and making sure everything stays consistent.

Reply on news.ycombinator.com