[kevinmgranger]

I think of Kubernetes as "the new Operating System", and these complex resources as fiddling with initscripts, fstab, /etc/interfaces, and so on. Writing an operator is like writing your own initscript.

I wouldn't be surprised if we eventually see new abstractions for "you just want a plain 'ol deployment with CI/CD du jour, a persistent volume claim, and a service ingress, just like 90% of all other CRUD webapps? Sure, here's a simple resource for that."

I think we'll start seeing a move towards more "opinionated" tools, just to outsource some of the decision making. No sense learning how to write your own pipelines if you can find a tool that says "we're gonna deploy every time you make a git tag and run `mvn package`, you figure the rest out".

[oauea]

Helm has been doing this since the early days. 99% of our charts are created using:

* `helm create` to get the default scaffold

* modify a handful of entries in the generated values file

* done!

Only thing is the default helm chart starter does not allow for autoconfiguring of volumes, and since we're porting a lot of stateful apps to kubernetes we just modified the default starter to include that capability.

Of course it would be nice to not have to maintain a bunch of different virtually identical templates.

Pulumi looks interesting but unfortunately seems to insist on vendor lock-in (see the jerk-around on https://github.com/pulumi/pulumi/pull/2697). So I'm looking forward to the AWS CDK (https://aws.amazon.com/cdk/) maturing a bit.

[jwatte]

Helm is an example of what I mean by "pusing against the boundaries." We tried using helm, but we kept running into limitations, and the complexity of trying to customize charts that didn't work right ended up being worse than the original problem. Currently, we're using kustomize, plus a thought out manifest hierarchy, which is working out better.

[wronglebowski]

As someone attempting to port a docker-compose application to a Helm chart I'd love to hear more about the resources you used. As someone working with a very simple application I've found the processes to be more difficult than I anticipated.

[oauea]

Kubernetes will be far more complex than docker compose. It'll let you do much, much more also.

Some potentially useful tips:

* One docker container usually maps to one pod, which is created by a deployment. You can put multiple containers in a single pod, but this couples them together tightly.

* Use services to assign hostnames to pods

* Have pods communicate to each other using the service names. This works the same as putting them in the same docker network.

* Volumes depend on your cloud provider or if you're running on bare metal. In the cloud it's easy, you just request one and it gets created on demand and backed by a cloud disk.

* If you're using volumes, you probably want to use the Recreate updatePolicy for your deployment. This will ensure the old pod is shutdown before creating a new one. Which is necessary to work with block volumes.

When using helm start with a `helm create CHARTNAME` and take a look at what it generated for you. You'll get some heavily templated yaml that if you're lucky you will barely have to touch.

But it's best to go through these tutorials and learn how to use the basic building blocks of kubernetes directly: https://kubernetes.io/docs/tutorials/kubernetes-basics/

Once you're familiar with what a Deployment, Service, Ingress and PersistentVolumeClaim are you can use helm to template this for you where necessary.

[skzo]

You can give a shot at kompose (https://github.com/kubernetes/kompose) It will convert your docker-compose.yml to kubernetes automatically

[abraxas]

And the tower of ever more obscure abstractions just keeps on growing. Until one of these fragile layers starts to malfunction and the whole thing comes tumbling down and nobody has a clue how to fix it all up.

Collectively, as an industry we have gone insane.

[harpratap]

People have attempted simpler abstractions and it has always failed. CloudFoundry, Mesos+Marathon, Heroku were all simple at first and none of them revolutionized the industry.

[oso2k]

I think of writing Operators more as writing your own Device Driver but I can see the correlation you're trying to make.

[taywrobel]

Well prepare to be unsurprised! The CI/CD abstraction already exists in Tekton - https://cloud.google.com/tekton

The rest are soon to follow I’m sure.

[jml78]

If people think deployment yamls are complicated, what til they see tekton.

Don’t get me wrong, I actually love tekton because I hate everything that is Jenkins and most other CICD tool integration with k8s. So tekton is just amazing in that regard.

But there is a huge learning curve for people who are used to old school tools like Jenkins and its pipelines .

[person3]

Agreed. Where I work we have a core team that created a framework that manages the Kubernetes configuration for us. As a backend developer I basically just have to throw a config file into my service with some basic options like which port to listen on and where the docker container is, and then it gets deployed with everything setup for me (using helm I believe).

I really hope we move more towards these opinionated tools that can handle 90% of the use cases. Most people just want to host an app on a port, and it's a pain to have to develop that pipeline at every company that wants to adopt Kubernetes.

[sushshshsh]

Agreed. Just like how I don't want to roll my own desktop environment on Linux, I will happily accept a good config rollef for me, even if opinionated.