Hacker News new | ask | show | jobs
by oauea 2109 days ago
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.

2 comments

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.
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.
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.

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