Live data from Hacker News

Kubernetes YAML Generator

k8syaml.com

121–127 of 127 posts

Re: Kubernetes YAML Generator

#121
post #38

Would be nice to have a linter or something that you know is best practice. Eg if you check your yaml and its more complex than it could be.

There are a number of such tools out there. Here's a short list. I'd be interested in any experiences people have had with them in largish production environments. https://www.kubeval.com/ https://github.com/zegl/kube-score https://stelligent.github.io/config-lint/#/ https://github.com/cloud66-oss/copper https://www.conftest.dev/ https://github.com/FairwindsOps/polaris#cli

Hey, I'm the author of kube-score, and originally built the tool to support an organization using Kubernetes at a fairly large scale as measured in number of engineers, services, and Kubernetes clusters.

I'm obviously biased, but it's been hugely successful! kube-score is working very well out of the box, and there's only a handful of cases where the "ignore" annotation has been used to disable a check that's too strict for the particular use case.

Feel free to reach out if you have any questions or comments.

Re: Kubernetes YAML Generator

#122
post #102

Earlier quoted context omitted.

> Is it anymore complex than all the old ways? > Was Apache, Asterisk, or loading and hardening a Linux host on bare metal easier? Yes, and by far. Adding a layer on top of all the traditional Linux daemons, tools and libraries does not decrease the total complexity - quite the contrary. When you have a bug in an application that is related to something in on another layer you have to walk through the whole stack. Ex…

But wouldn’t the point be that you don’t care about hardware level problems anymore? When I find a node with issues, I can just delete it from the pool and get a fresh one back. The bad network card? That’s for Google/Amazon/DigitalOcean to deal with. I find the bog-standard Prometheus chart provides me a pretty incredible level of monitoring out of the box, usually it’s pretty easy to pick the bad one out of a graph…

> But wouldn’t the point be that you don’t care about hardware level problems anymore?

No. Read my post again: I did not wrote about hardware issues.

Most work around optimization, reliability or security require digging through the whole stack sometimes down to the kernel.

> When I find a node with issues, I can just delete it from the pool and get a fresh one back.

However, a lot of k8s deployments are on-premise, where you have to debug your own hardware.

> The bad network card? That’s for Google/Amazon/DigitalOcean to deal with.

First you have to pinpoint the root cause of that glitch affecting all the containers running on VMs using the same bad drivers. Often it could be the same in 50% of your fleet.

> is gonna take you a week to set up properly.

Most certainly not. I've been deploying large production fleets in minutes since 2005.

Re: Kubernetes YAML Generator

#123
post #73

Earlier quoted context omitted.

In my opinion, Kube's yaml blobs are comparable to binary programs. Complaining that an executable has its settings, paths, ports, memory limits, etc, hard coded inside of it is an obvious code smell. Tools like Helm solve this problem.

Abstractions have a cost and a value. Programming languages are more expressive than writing out binary opcodes by hand, but don't really remove any features from the underlying machine. If your machine can do something, your C program can probably do something. So we use C. (It even ADDS the value that you can describe a procedure without knowledge of the underlying hardware. It may not be optimal on every machine,…

Templating within yaml is an absolute mess, I harped on ansible in the past for the same reason. However, dealing with that once is far, far better than dealing with thousands of hand-maintained kube yamls multiplied by your number of environments. Helm of course has its own pain points, but that doesn't subtract from the fact that it solves problems.

I see putting your example of two, unrelated, containers in the same pod as the same binary problem I mentioned earlier. I get your point, but it's a scenario one must wedge themselves into by making other poor choices. Why must the frontend and backend be the exact same version? The most obvious possible reason could be that the API used between them isn't versioned. Or maybe there's not even an API!

> You will have to read the code or hope I wrote documentation for my ad-hoc Kubernetes extension.

No, helm's approach to inserting variables into templates means this isn't the case. Every option and default appears in values.yaml and it's a one stop shop to see everything you can customize. The code example you wrote could be better written as:

      containers:
        - name: frontend
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
With values.yaml having

    image:
      repository: my_default_image
      tag: my_default_tag
Note that values.yaml is part of the template and values passed to helm's cli can override individual values in it.

I'm not sure what you mean about helm charts having no upgrade path. IME you can un-deploy, upgrade, and rollback helm deployments and it takes care of adding/removing kube resources that where also added or removed in the yaml for you. [1]

[1] https://helm.sh/docs/helm/helm_rollback/

Re: Kubernetes YAML Generator

#124

Earlier quoted context omitted.

Are you not worried about people writing arbitrary code to do stuff? I've been burnt before where devs used Turing complete languages (python in my case) to generate configs in probably the most convoluted and complicated manner possible. It was impossible to debug and understand, there were side-effects literally everywhere. It was everything you'd imagine from a normal bit of bad code, but it also happened to spin…

As long as the code is generating something like configs, you can write guard rail sanity check tests against the output, or apply linters, etc.

But now you’re writing code to generate config and code to verify your configs.

Re: Kubernetes YAML Generator

#125

We're using Pulumi https://www.pulumi.com/ to do our K8 configuration. We can use TypeScript interfaces (which give us nice ide code completion) to define our yaml. we can then create functions where we would normally duplicate Yaml. Really nice. https://www.pulumi.com/kubernetes/

Are you not worried about people writing arbitrary code to do stuff? I've been burnt before where devs used Turing complete languages (python in my case) to generate configs in probably the most convoluted and complicated manner possible. It was impossible to debug and understand, there were side-effects literally everywhere. It was everything you'd imagine from a normal bit of bad code, but it also happened to spin…

As it's infrastructure as code it would go through code review. So in that case I wouldn't be worried.

Re: Kubernetes YAML Generator

#126
post #69
post #35

Earlier quoted context omitted.

A lot of other "bleeding edge" technologies that blow up and become difficult to use end up with new abstractions, and then abstractions for the abstractions, and the original problem the tool was meant to solve is now not the focus any longer.

https://xkcd.com/1319/

there is always a relevant xkcd!
Post reply on HN