5 ms·
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
by deathanatos 3y ago
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?
- cortesoft 3y agoThe 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.
- cogman10 3y agoThe 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).
- lyjackal 3y agoThis. If it’s a database, I’d like the deployment infrastructure to be aware during upgrades and able to execute complex actions
- fivre 3y agoCRs 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.
- withinboredom 3y agoThe 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.
- getrealyall 3y agoLet'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.
- PickledJesus 3y agoI 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.
- withinboredom 3y agoI 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.
- deleted 3y ago[deleted]