Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tanka: Our way of deploying to Kubernetes

grafana.com

Post reply on HN
Print view View original

41–50 of 124 posts

Re: Tanka: Our way of deploying to Kubernetes

#41

Post by shorez »

candiddevmike wrote: post #15

The shortcomings for Helm are relatively spot on, but I feel like the ship has sailed for tools that aren't Helm based. The ecosystem partners (and thus, end users) have rallied around Helm charts as the defacto manifest format, so a tool that doesn't understand Helm charts will not see a lot of adoption. Are there any plans for Tanka to support importing existing Charts?

(Tanka dev here)

Nobody can neglect the power of helm charts (because so many already exist), so I think Tanka will add support soon.

Even though we are focused on Jsonnet right now, this does not necessarily need to stay that way forever.

Grafana for example is popular because it supports multiple datasources, Tanka should probably do as well (e.g. Jsonnet, CUE, Helm, whatever results in JSON)

Re: Tanka: Our way of deploying to Kubernetes

#42

Post by shorez »

MetalMatze wrote: post #39
wikibob wrote: post #24

What are folks thoughts on CurLang these days? Anyone using it for serious configuration yet? https://cuelang.org/ It’s designed by the BCL/GCL author as a replacement (Jsonnet is apparently a copy of BCL/GCL)

Maintainer of jsonnet-bundler, kube-prometheus and some monitoring mixins, that are all based on jsonnet, here: Currently we're mostly keeping a close look at CUE, but not really using it as of right now. However, during the holiday break I've been trying to get into CUE again and there are some things I need to figure out before being able to tell how to incorporate or replace some of our jsonnet projects with CUE,…

On the same track as well! CUE looks exciting and we might very much implement add it to Tanka when it proves to be useful.

We have chosen Jsonnet because it already had an ecosystem and served us well, but Tanka is open to other languages as well

Re: Tanka: Our way of deploying to Kubernetes

#43

Post by MetalMatze »

jka wrote: post #22
nouney wrote: post #13

Earlier quoted context omitted.

Take a look into kustomize https://github.com/kubernetes-sigs/kustomize

Thanks! I had briefly used kustomize in the past, and it looks really useful for creating alternative dev/staging/production environments from a common base. In the end I decided that I'd collapse all environments down to behave identically, which is simpler, but does add a few constraints for development in particular. Will take another browse through while considering options for upcoming infrastructure :)

The problem for us monitoring / observability people with kustomize is its limitation to be purely templating for Kubernetes. However we also want to template a lot of things like for example Prometheus configuration. Jsonnet can bridge that gap between the two worlds and in the end generate a ConfigMap YAML file that includes another YAML file Prometheus, as an example.

Re: Tanka: Our way of deploying to Kubernetes

#44

Post by shorez »

chris11 wrote: post #23

This seems interesting, but would have liked to see dashboard and chart configs cleaned up. Grafana's json configs have the same issue. I have a dashboard for one project. The json is over 13k lines long. Less than 5% of that is unique.

You could use Tanka and Jsonnet to improve this for Grafana dashboards: https://github.com/grafana/grafonnet-lib.

Would that work for you?

Re: Tanka: Our way of deploying to Kubernetes

#46

Post by arpa »

loriverkutya wrote: post #32

I'm not a big fan of helm, but using json syntax instead of yaml sounds like getting shot in the leg. Json as far as I'm aware never meant to be human readable or human writable.

I would argue the same about yaml and whitespace being meaningful. Oh you forgot a single space? Your markup is screwed. Xml is much better...

Re: Tanka: Our way of deploying to Kubernetes

#48

Post by idan »

Naive question from someone who doesn't know the ecosystem well:

It seems to me like Terraform is good at describing desired deployment shapes and detecting drift between actual state and desired state.

Can someone clue me into why Terraform hasn't caught on as the abstraction above/that drives K8S?

Re: Tanka: Our way of deploying to Kubernetes

#50

Post by shorez »

idan wrote: post #48

Naive question from someone who doesn't know the ecosystem well: It seems to me like Terraform is good at describing desired deployment shapes and detecting drift between actual state and desired state. Can someone clue me into why Terraform hasn't caught on as the abstraction above/that drives K8S?

Kubernetes is very good at keeping track of state and maintaining it. You "just" tell it the state you want and it makes sure it becomes reality (this is the whole point of k8s actually). Terraform is doing the same thing, just for imperative (instead of declarative) APIs (like public clouds, etc).

The issue with Kubernetes is more expressing the state. Kube uses YAML, which quickly becomes verbose and hard to maintain. More on our blogpost: https://grafana.com/blog/2020/01/09/introducing-tanka-our-wa...

Tanka is trying to solve this issue by providing a more powerful language that overcomes these limitations hopefully.

Post reply on HN