Live data from Hacker News

Kubernetes YAML Generator

k8syaml.com

111–120 of 127 posts

Re: Kubernetes YAML Generator

#111
post #67

Earlier quoted context omitted.

Ah right, guess I was thinking of the protobuf over HTTP API. In any case, I find using the protobuf types in your language of choice pretty ergonomic compared to YAML.

This is one thing that mesos/aurora got right (the "turing-complete-by-design" config files, written in Python). Templating yaml is like templating html. It works but absolutely sucks at scale if your job is to maintain it. It's good to know that such an interface could conceivably be built for Kubernetes, using the HTTP API. Even better that it supports any programming language (since it's a network interface); I'd…

> the "turing-complete-by-design" config files, written in Python

Funny you mention this, check out what is effectively this but for Kubernetes:

https://github.com/stripe/skycfg

Re: Kubernetes YAML Generator

#112
post #67

Earlier quoted context omitted.

This is one thing that mesos/aurora got right (the "turing-complete-by-design" config files, written in Python). Templating yaml is like templating html. It works but absolutely sucks at scale if your job is to maintain it. It's good to know that such an interface could conceivably be built for Kubernetes, using the HTTP API. Even better that it supports any programming language (since it's a network interface); I'd…

> the "turing-complete-by-design" config files, written in Python Funny you mention this, check out what is effectively this but for Kubernetes: https://github.com/stripe/skycfg

Wow, this is great! Thank you for sharing.

SMART_ORGANIZATIONS=$SMART_ORGANIZATIONS:stripe

I wonder if they were inspired by aurora, it's very similar.

Re: Kubernetes YAML Generator

#113

Earlier quoted context omitted.

Ah right, guess I was thinking of the protobuf over HTTP API. In any case, I find using the protobuf types in your language of choice pretty ergonomic compared to YAML.

Would you happen to have any links to Github repos that would be an example of this? From light googling I only see examples of building gRPC APIs and microservices.

I don't have an example offhand, but mentioned skycfg in the neighbor comment, which may be of some interest to you. I've used https://github.com/ericchiang/k8s in the past with great success.

Re: Kubernetes YAML Generator

#114
post #24

I wonder what the need for tools such as this or other "Kubernetes-by-example" type pages tell us about the complexity of configuring Kubernetes resources. Do we need a better layer of abstraction, i.e. better adoption and tighter integration for something like kustomize? Have we fucked up completely with Kubernetes due to it being outrageously complicated for simple tasks? How we redesign this to be simpler? Is the…

I think abstracting YAML generation to a tool is a good idea. Let the tool handle the underlying abstraction of converting the parameters to YAML.

If k8s changes notation having a layer of abstraction (hopefully) allows me to run the same command to generate new YAML (very helpful in automation)

Re: Kubernetes YAML Generator

#115
post #44

Earlier quoted context omitted.

> This is the way to go for sure. I've done similar by generating CloudFormation from Python (I wrote my own library because I felt Troposphere was not very friendly nor a significant improvement over YAML). Yes and no. Typing is a must, but a full-blown programming language is too powerful and all abstraction layers start to leak sooner rather than later. I always ended up with a "deployment" function that exposed a…

It depends. If you can reasonably trust your team to not to do I/O in the scripts, then you're fine. If you can't, then you should use something like Starlark (a subset of Python running in a constrained environment that precludes I/O, unbounded loops, etc); however, Starlark doesn't support types yet. I've looked at Cue a few times (principally out of frustration with the lack of types in Starlark), but I don't real…

I have used a bunch of jsonnet and was in your position. I picked up https://jkcfg.github.io and have been very happy. You get TypeScript with (some) hermeticity guarantees.

Re: Kubernetes YAML Generator

#116

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 long as the code is generating something like configs, you can write guard rail sanity check tests against the output, or apply linters, etc.

Re: Kubernetes YAML Generator

#117
post #94

Earlier quoted context omitted.

I think of Kubernetes as "the new Operating System", and these complex resources as fiddling with initscripts, fstab, /etc/interfaces, and so on. Writing an operator is like writing your own initscript. I wouldn't be surprised if we eventually see new abstractions for "you just want a plain 'ol deployment with CI/CD du jour, a persistent volume claim, and a service ingress, just like 90% of all other CRUD webapps? Su…

And the tower of ever more obscure abstractions just keeps on growing. Until one of these fragile layers starts to malfunction and the whole thing comes tumbling down and nobody has a clue how to fix it all up. Collectively, as an industry we have gone insane.

People have attempted simpler abstractions and it has always failed. CloudFoundry, Mesos+Marathon, Heroku were all simple at first and none of them revolutionized the industry.

Re: Kubernetes YAML Generator

#119
post #23

Earlier quoted context omitted.

I've used Dhall in production, pushed it fairly hard and can say with utmost certainty it's be an absolute pleasure. We use it as our application configuration format and derive fairly intricate Kubernetes resources from our app config. Although it is still in it's early days, it still is excellent to use and will only get better with additional tooling.

How does it differ from the CDK/CDK8s/terraform-cdk?

CDK uses existing fully featured programming languages that can preform side effecting actions thus lacking reproducibility and that are may not terminate. Dhall is a total language, meaning it will always terminate and a pure language, meaning that a function given an input will always yield the same output. That makes the output extremely predictable.

Re: Kubernetes YAML Generator

#120

Earlier quoted context omitted.

That's exactly what I am doing with https://primcloud.com :)

This seems really cool; I was poking around, but half of the links in your footer are broken (presumably placeholders for future pages?).

Yes sorry, I had a simple splash landing page up but people were asking for more info, so I put this up while I continue building the infra/platform.

I will over time expand on the content, but I'm focusing on the platform itself over marketing stuff.

Post reply on HN