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

101–110 of 124 posts

Re: Tanka: Our way of deploying to Kubernetes

#101

Post by markbnj »

sandstrom wrote: post #95
markbnj wrote: post #76

In our experience running production workloads on k8s for over three years templating (helm) and structured editing approaches both have their place, and both are valuable. We don't feel the need to replace declarative approaches with another imperative language, or to use complicated helm charts for straightforward service deployments. There are many ways to classify workloads, but one big distinction that we find v…

For anyone curious, this is what the prometheus chart look like (I think): https://github.com/helm/charts/blob/master/stable/prometheus...

That's the values file. The actual manifest templates are just as horrifyingly impressive :).

https://github.com/helm/charts/tree/master/stable/prometheus...

Re: Tanka: Our way of deploying to Kubernetes

#102

Post by kaidon »

cbushko wrote: post #98
nodesocket wrote: post #58

Earlier quoted context omitted.

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

I agree. Terraform and it's providers are unbelievably powerful for deployments. Being able to create any sort of resource and passing that information onto your kubernetes service to use is really great. An example would be creating a dynamically names S3 bucket and passing it onto your service to use/manage. The same goes with anything needing credentials. Very powerful.

I usually just deploy "GKE clusters, node pools, AWS route 53, S3 buckets, etc" in terraform. Then take the terraform output and convert it to command line options that I pass to helm when deploying a kubernetes cluster.

I'd be very tempted to just use terraform. But helm, with our forked charts, extensive values.yaml files, etc. has permiated the deployment.

So... rather than try to break up the helm beast; I leave it and keep the separation of concerns (infrastructure vs k8s) as described at the beginning. It works pretty well to be honest is rarely the source of problems.

Re: Tanka: Our way of deploying to Kubernetes

#103

Post by mdaniel »

zapita wrote: post #94
mdaniel wrote: post #93

Earlier quoted context omitted.

For those who don't already have an account on that slack, then going to https://cuelang.org/community/ appears to be the place one will find the magic invite link: https://join.slack.com/t/cuelang/shared_invite/enQtNzQwODc3N... off(but actually on)-topic: I can't wait for the use of slack for open source communities to die in a fire, not only because the onboarding experience is horrible, and search is a mess, but a…

I completely agree with you on slack for open-source projects. Especially with Mattermost being so good, there’s no good reason for a project to stick to Slack.

Even Mattermost doesn't offer free accounts to open source projects[1], and I think it's the _hosting_ that keeps projects off of almost any of the open source solutions. But one of the principals of Zulip almost always weighs in on discussions to point out that they have free hosting for any open source project that wants to use it: https://zulipchat.com/for/open-source/#free-hosting-at-zulip... and seem to even offer "import from slack" to make it less painful to switch.

1 = https://mattermost.com/nonprofit/ asks for a $390 "setup fee" and only for 1,000 users

Re: Tanka: Our way of deploying to Kubernetes

#104

Post by MuffinFlavored »

cbushko wrote: post #97

I spent about 6 months using helm and made around 20+ charts for the services. In the end we got rid of it and replaced it with Terraform. If your infrastructure is 100% kubernetes then I think helm is great. Our infrastructure is not. We have databases, dns, buckets, service accounts and more so we were splitting our setup between terraform and helm. Passing data between the two tools was going to be a pain. We foll…

Why don't more people use Terraform? I think Terraform is amazing. I wanted to make containerpen.io for docker-compose + dockerfiles + terraform files to compete with codepen.io

Re: Tanka: Our way of deploying to Kubernetes

#106

Post by ithkuil »

markbnj wrote: post #101
sandstrom wrote: post #95

Earlier quoted context omitted.

For anyone curious, this is what the prometheus chart look like (I think): https://github.com/helm/charts/blob/master/stable/prometheus...

That's the values file. The actual manifest templates are just as horrifyingly impressive :). https://github.com/helm/charts/tree/master/stable/prometheus...

One of the main problems with helm IMO is that it effectively turns the values.yaml file in a structure that almost mirrors the manifests themselves, and the biggest problem of that is hidden in the word "almost": there are many subtle ways this mapping can be done, including subtle or not so subtle field naming/spelling differences.

Re: Tanka: Our way of deploying to Kubernetes

#107

Post by xref »

cbushko wrote: post #97

I spent about 6 months using helm and made around 20+ charts for the services. In the end we got rid of it and replaced it with Terraform. If your infrastructure is 100% kubernetes then I think helm is great. Our infrastructure is not. We have databases, dns, buckets, service accounts and more so we were splitting our setup between terraform and helm. Passing data between the two tools was going to be a pain. We foll…

Curious about what is deploying your services, are they still containerized or are you using VMs? Any ansible along with it?

Re: Tanka: Our way of deploying to Kubernetes

#108

Post by NicoJuicy »

This won't be a popular opinion/implementation.

I'm on dot net. And although I can deploy as microservices ( clean architecture with core, application, Infrastructure and api).

I seem to integrate the api into my app ( Eg. Add the api dll). So my app does the provisioning like a monolith.

It exposes all api controllers by default.

Messaging is internal always then ( domain vs Integration).

Overhead is practically none.

If I have a heavy component/api, I can split up an API and put nginx in front of it for routing and nats for Integration Events

So, basically I have a DDD app at the beginning with the strangler pattern already in place for scaling porpose. Although none of my apps need scaling right now.

I also can do every deployment myself and more easily. Since I don't have a deployment complexity currently.

--

What I don't have, is that my stack is language agnostic at the beginning. But it could be using the same method as scaling, with nginx.

It seems that I have the best of both worlds at the beginning.

- maintainability by forcing DDD

- minimal devops

- testability

- no service mesh overhead ( eg. Consult brings a 30-50ms average overhead, I finish most of my requests in 8-12ms)

- fast development ( slower than monolith, much faster then microservice)

While scaling could be refactored within the day, if an insane amount of request come in ( see: refactoring)

Most microservices are fixed within a single language though. So that's not a concern currently.

The added benefit is, is that I have insane custom implementation options.

I just need to change the Infrastructure in a deployment to use a clients database as a source if a component needs it.

( Eg. An order service for a webshop. I can easily integrate with an clients existing magento for a niche of their shop)

TLDR: I currently don't have a devops overhead. I'm too small for that, I'm glad though.

--

if anyone thinks that isn't a good solution for my use-case ( small dev shop) or have any better ideas. Please share ;)

Re: Tanka: Our way of deploying to Kubernetes

#109

Post by shorez »

doru1980 wrote: post #80

> 1. Repetition: If information is required in multiple places (dev and prod environments, etc.), all YAML has to offer is copying and pasting those lines. Actually, YAML has anchors and aliases, which helps a lot when the same thing needs to be reused in several places.

But only as long as it stays in a single file :(. And it does not have support for arrays as well

Re: Tanka: Our way of deploying to Kubernetes

#110

Post by nojvek »

We use jsonnet at my workplace for all sorts of generated configs. Not just k8s configs. I cannot recommend jsonnet enough. simple and powerful tool.

Jsonnet is a godsend. Don’t use a string templating language for structured data like yaml/json. Use an object templating language like jsonnet. You’ll start to love life again.

We had used mustache templates before and it was a PITA.

Post reply on HN