9 ms·

Indeed. Helm offers great features but it suffers from the kubernetes unnecessary complexity and by using golang templates in YAML. When I started with kuberne

Indeed. Helm offers great features but it suffers from the kubernetes unnecessary complexity and by using golang templates in YAML. When I started with kubernetes I converted my small Docker compose files to kubernetes files. Later I rewrote everything in helm charts. Now it's almost more YAML and golang templates lines than business logic lines in my applications. I'm considering to go back to Docker compose files. It's simple, readable, and easy to maintain.

q3k 6y ago
Highly recommend trying Jsonnet (via https://github.com/bitnami/kubecfg https://github.com/bitnami/kubecfg and https://github.com/bitnami-labs/kube-libsonnet https://github.com/bitnami-labs/kube-libsonnet) as an alternative. It makes writing Kubernetes manifests much more expressive and integrates better with Git/VCS based workflows. Another language like Dhall or CUE might also work, but I'm not aware of a kubecfg equivalent for them. Jsonnet in general is a pretty damn good configuration language, not only for Kubernetes. And much more powerful than HCL.
- kraig 6y ago
  Funny, I thought jsonnet was an even worse experience than templating yaml
  - q3k 6y ago
    My experience with jsonnet varied: there's good jsonnet code, and there's bad one, too. Just like with any programming language, you have to apply good software engineering practices. Text templated YAML, however, is terrible by design.
  - p_l 6y ago
    The problem with templating YAML is that you're templating text, in a very sensitive to whitespace syntax. By definition, Jsonnet avoids that because it operates on the data structure, not on their stringified representation.
- threentaway 6y ago
  If you like those, I'd take a look at Grafana's Tanka [0]. It also uses jsonnet but has some additional features such as showing a diff of your changes before you apply, easy vendored libraries using jsonnet-bundler, and the concept of "environments" which prevents you from accidentally applying changes to the wrong namespace/cluster. [0] https://github.com/grafana/tanka https://github.com/grafana/tanka
  - q3k 6y ago
    I looked at it, I don't like it for the same reason as I dislike many other tools in this space: it imposes its own directory structure, abstraction (environments) and workflow. I'm a fan of the kubecfg-style approach, where it lets you use whatever sort of structure makes sense for you and your project. It's a 'framework' vs 'library' thing, but in the devops context.
    - dilyevsky 6y ago
      I worked on this at previous gig - https://github.com/cruise-automation/isopod https://github.com/cruise-automation/isopod Same use-case but uses Starlark dsl instead of jsonnet
- AlphaSite 6y ago
  Ive found the whole k14s eco system is pretty great to (ytt + kbld + kapp).
  - q3k 6y ago
    ytt is even more templating-yaml-with-yaml, so it all ends up being a bargain bin Helm. There's no reason to do this over just serializing plain structures into YAML/JSON/...
    - AlphaSite 6y ago
      It avoids the whole set of issues you get with templating yaml with helm since its structure aware. Also you can actually write pure code libraries in starlark (basically a subset of Python)
      - q3k 6y ago
        I'm aware, but I just don't understand the point of it. How is it in any way better than a purpose-specific configuration language like Dhall/CUE/Jsonnet? What's the point of having it look like YAML at all?
sandGorgon 6y ago
We just moved to the kubernetes ecosystem - specifically for integration with spot instances of AWS (and cut our costs by 60%). But I hate the UX of kubernetes. Compose was beautiful. I have hope - since compose files have become an independent specification. https://www.docker.com/blog/announcing-the-compose-specification/ https://www.docker.com/blog/announcing-the-compose-specifica... Kubernetes distro built around the compose file specification would be a unicorn.

q3k 6y ago

Highly recommend trying Jsonnet (via https://github.com/bitnami/kubecfg https://github.com/bitnami/kubecfg and https://github.com/bitnami-labs/kube-libsonnet https://github.com/bitnami-labs/kube-libsonnet) as an alternative. It makes writing Kubernetes manifests much more expressive and integrates better with Git/VCS based workflows. Another language like Dhall or CUE might also work, but I'm not aware of a kubecfg equivalent for them. Jsonnet in general is a pretty damn good configuration language, not only for Kubernetes. And much more powerful than HCL.

kraig 6y ago
Funny, I thought jsonnet was an even worse experience than templating yaml
- q3k 6y ago
  My experience with jsonnet varied: there's good jsonnet code, and there's bad one, too. Just like with any programming language, you have to apply good software engineering practices. Text templated YAML, however, is terrible by design.
- p_l 6y ago
  The problem with templating YAML is that you're templating text, in a very sensitive to whitespace syntax. By definition, Jsonnet avoids that because it operates on the data structure, not on their stringified representation.
threentaway 6y ago
If you like those, I'd take a look at Grafana's Tanka [0]. It also uses jsonnet but has some additional features such as showing a diff of your changes before you apply, easy vendored libraries using jsonnet-bundler, and the concept of "environments" which prevents you from accidentally applying changes to the wrong namespace/cluster. [0] https://github.com/grafana/tanka https://github.com/grafana/tanka
- q3k 6y ago
  I looked at it, I don't like it for the same reason as I dislike many other tools in this space: it imposes its own directory structure, abstraction (environments) and workflow. I'm a fan of the kubecfg-style approach, where it lets you use whatever sort of structure makes sense for you and your project. It's a 'framework' vs 'library' thing, but in the devops context.
  - dilyevsky 6y ago
    I worked on this at previous gig - https://github.com/cruise-automation/isopod https://github.com/cruise-automation/isopod Same use-case but uses Starlark dsl instead of jsonnet
AlphaSite 6y ago
Ive found the whole k14s eco system is pretty great to (ytt + kbld + kapp).
- q3k 6y ago
  ytt is even more templating-yaml-with-yaml, so it all ends up being a bargain bin Helm. There's no reason to do this over just serializing plain structures into YAML/JSON/...
  - AlphaSite 6y ago
    It avoids the whole set of issues you get with templating yaml with helm since its structure aware. Also you can actually write pure code libraries in starlark (basically a subset of Python)
    - q3k 6y ago
      I'm aware, but I just don't understand the point of it. How is it in any way better than a purpose-specific configuration language like Dhall/CUE/Jsonnet? What's the point of having it look like YAML at all?

sandGorgon 6y ago

We just moved to the kubernetes ecosystem - specifically for integration with spot instances of AWS (and cut our costs by 60%). But I hate the UX of kubernetes. Compose was beautiful. I have hope - since compose files have become an independent specification. https://www.docker.com/blog/announcing-the-compose-specification/ https://www.docker.com/blog/announcing-the-compose-specifica... Kubernetes distro built around the compose file specification would be a unicorn.