Live data from Hacker News

Tanka: Our way of deploying to Kubernetes

grafana.com

1–10 of 124 posts

Re: Tanka: Our way of deploying to Kubernetes

#6
post #2

This article seems to have a major factual error. YAML does support “Repetition” with anchors. Am I missing something?

Anchors are fairly limited:

- they are bound to a single file. This won’t help you when trying to maintain multiple similar sets of Config

- anchors do not support patching. If you need to change a nested key, you can’t do so without it affecting all other nested keys as well

Re: Tanka: Our way of deploying to Kubernetes

#7
post #2

This article seems to have a major factual error. YAML does support “Repetition” with anchors. Am I missing something?

I found that odd too. Typical examples like https://confluence.atlassian.com/bitbucket/yaml-anchors-9601... are pretty easy to map to their example of why they need repetition.

Re: Tanka: Our way of deploying to Kubernetes

#9
post #3

This is an interesting project! But I wonder how it handles custom kubernetes extensions.

Which extensions are you talking about? Do you mean CRDs? Then it take plain JSON or you can write a function to generate those.

Yes, that is why I am talking about. I guess just providing a new object type for your custom extension should work fine.

Re: Tanka: Our way of deploying to Kubernetes

#10
Very interesting. I've been reluctant to adopt Helm for Kubernetes resource management because of a gut feeling that it's a heavyweight solution for what seems broadly like a templating problem.

With ksonnet having gone quiet[0] this looks like a promising initiative.

I'd imagine that it'll need something like a package manager (or at least a curated list of common packages) in order to gain good adoption.

[0] - https://blogs.vmware.com/cloudnative/2019/02/05/welcoming-he...

Post reply on HN