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

51–60 of 124 posts

Re: Tanka: Our way of deploying to Kubernetes

#51

Post by nyxxie »

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?

Terraform is really good at describing how infrastructure should be provisioned (VMs, load balancers, dns entries, networking, etc). Provisioning software on a VM and keeping it in a consistent state, however, is not something it's very good at. Userdata is very difficult to do anything complex with (limited size payloads, optimized for uploading a single shell script), and the provisioner system is explicitly described as a "last resort". This makes Terraform not so good at describing how software should be provisioned.

There is a bit of a movement, however, behind using it to deploy software by pairing it with Packer. You use Packer to create an e.g. AMI whose sole job it is to run your software (like a Docker container) then use Terraform to launch a bunch of EC2 instances that have juuuust enough resources to effectively run your software. That'd allow you to eliminate k8s from your stack, though it remains to be seen which stack would be more cost-efficient to run on.

Re: Tanka: Our way of deploying to Kubernetes

#52

Post by shorez »

dcchambers wrote: post #49

Getting a HSTS cert error on the site they link in the blog post - tanka.dev :(

Oh, too bad :(

The site is hosted on Netlify and seems to be working for most other people.

Maybe reset your browser cache, check your network or try on your phone using cellular data instead?

If the issue persists, I'll take a closer look :D

Re: Tanka: Our way of deploying to Kubernetes

#53

Post by slig »

nouney wrote: post #13
jka wrote: post #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] - http…

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

I tried to use kustomize recently but could not figure out how to write Job/CronJob properly. I wanted to use the configGenerator/secretGenerator, with prod/stage/dev.

Re: Tanka: Our way of deploying to Kubernetes

#54

Post by shorez »

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.

Hi, you won't have much contact with JSON at all.

While Jsonnet is technically a superset, all you will see during use is most probably function calls and imports.

You won't have to actually write the Kubernetes objects anymore, they are generated using helper functions, just like real programming languages would do.

Re: Tanka: Our way of deploying to Kubernetes

#55

Post by shorez »

csunbird wrote: post #3

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

Exactly like YAML does.

With Tanka you would usually use the functions provided by `k.libsonnet` to generate your manifests.

For CRD's, there are no helpers available, so you either just write the plain manifest as a Jsonnet object (JSON syntax), as YAML and `import` it (gives you an object as well) or even better write some helper functions yourself, publish them as a library on GitHub and make future users happy :D

Re: Tanka: Our way of deploying to Kubernetes

#56

Post by rsanders »

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?

My last company used Terraform to manage Kubernetes. The main issue is that the TF Kubernetes provider supports a limited subset of K8S object types, and of fields within those K8S objects. For example: TF didn't even support Deployment objects until sometime in mid/late 2019 (I may be wrong on timing, but it was long after they were the primary method for general scheduling of long-running containers).

We ended up using TF's Helm provider, sometimes with hacks like a helm chart which deploys an arbitrary YAML file (the so-called "raw" chart). At that point, Terraform is blind to what's actually happening inside K8S. You can still benefit from the ability of TF to pass data from your other infra automation into the Helm charts, of course, but it's really Helm actually managing the configuration of your K8S cluster. And that's the app we all love to hate.

The situation may have been improved, but my conclusion was that it would always be a somewhat incomplete interface.

Re: Tanka: Our way of deploying to Kubernetes

#57

Post by jalfresi »

nyxxie wrote: post #51
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?

Terraform is really good at describing how infrastructure should be provisioned (VMs, load balancers, dns entries, networking, etc). Provisioning software on a VM and keeping it in a consistent state, however, is not something it's very good at. Userdata is very difficult to do anything complex with (limited size payloads, optimized for uploading a single shell script), and the provisioner system is explicitly descri…

This is interesting... not heard of this. Any pointers/links to more info on this?

Re: Tanka: Our way of deploying to Kubernetes

#58

Post by nodesocket »

jka wrote: post #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] - http…

I'd also recommended taking a look at using Terraform[1] to manage Kubernetes resources instead of yaml files and kubectl.

[1] https://www.terraform.io/docs/providers/kubernetes/guides/ge...

Re: Tanka: Our way of deploying to Kubernetes

#60

Post by joseph »

nyxxie wrote: post #51
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?

Terraform is really good at describing how infrastructure should be provisioned (VMs, load balancers, dns entries, networking, etc). Provisioning software on a VM and keeping it in a consistent state, however, is not something it's very good at. Userdata is very difficult to do anything complex with (limited size payloads, optimized for uploading a single shell script), and the provisioner system is explicitly descri…

Check out https://www.terraform.io/docs/providers/template/d/cloudinit... if you want to do something more complex than a single shell script.
Post reply on HN