Türken
Kubernetes YAML Generator
51–60 of 127 posts
Re: Kubernetes YAML Generator
#52Awesome work for the deployment resource! Now do this for all the other native k8s types and popular custom resources. :)
Re: Kubernetes YAML Generator
#53I 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 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…
I think of writing Operators more as writing your own Device Driver but I can see the correlation you're trying to make.
Re: Kubernetes YAML Generator
#54Earlier quoted context omitted.
> we can then create functions where we would normally duplicate Yaml. 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). Typing turns out to be pretty useful when you're generating YAML. While my library was fully typed, Python's type checking left a lot to be des…
> 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 really "get it". What I want is a typed embeddable scripting language--specifically the ability to expressively generate YAML, and I'm pretty sure that's not what Cue is. I'm open to the argument that Cue is better than what I want (a la "if Henry Ford asked people what they really want, they'd've said faster horses"), but the value proposition isn't clear to me from perusing the docs. Maybe you can correct me?
Re: Kubernetes YAML Generator
#55Earlier quoted context omitted.
Most of my colleagues find the yaml interface to be a lost cause. I tend to prefer to use the gRPC API as it's effectively the same declarative operations but you get to control it in software, which just feels right. YAML is just a crutch for specifying the API calls the client needs to make.
You mean the Kubernetes HTTP API? That one isn’t gRPC based, right?
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.
Re: Kubernetes YAML Generator
#56Earlier quoted context omitted.
Right, but that's not as much of a Kubernetes issue as a VSCode issue. Everything's there for you to write something like this for your text editor, open source code doesn't grow on trees :).
My point being if k8s configuration was developed UI centrically, this problem would not exist in the first place. Because there would be official K8s GUI for configuration, one would not hunt and beg bits and pieces of docs every time editing a config file. As a side note, usually the schema languages fail at some point, thus I referred to TypeScript interfaces, which are very flexible way to write validation. There…
If it was developed UI-centric, it would have failed much earlier to do anything useful.
The real power of Kubernetes is that it has very simple basic model that allows building complex constructs out of simple pieces, and in fact basic help (which is even used for UI in kubectl explain.
All the bits for good UI support are there.
Re: Kubernetes YAML Generator
#57I 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 can't write a deployment yaml without googling or copy/pasting
What about Nginx or Apache configuration files? Could you write them without googling?
Re: Kubernetes YAML Generator
#58I 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…
IMO it needs two things:
- a dedicated editor with intelligent autocomplete
- stop using YAML, it soon becomes unreadable. JSON is easier to grok.
Re: Kubernetes YAML Generator
#59I 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…
Complexity always exists somewhere. You can't remove it, only try it make it easier to deal with.
What Kubernetes allows you to do is very complex so you need a capable system to express it all. YAML isn't always the best but it works fine for most and tools like these are very helpful.
Do you use an IDE? Does that mean the language and framework is too complex? No, it's just a tool to help you get things done. More tools aren't a bad thing.
Re: Kubernetes YAML Generator
#60I 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…
Is it anymore complex than all the old ways? Was Apache, Asterisk, or loading and hardening a Linux host on bare metal easier? I seem to remember a lot of wrangling custom kernels to get Asterisk sounding just right, bizarre Apache, & network configs. It’s just text? It’s always going to turn into a nebulous mess without literal edges and boundaries. That’s Google’s play with it, IMO. Train tracks. Which is what I ha…
> 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.
Examples: A bug in a network card impacting only large UDP packets. A race condition of file access triggered by NFS or a storage device driver. A vulnerability based on a timing attack due to CPU caches.
The deeper the stack, the worse.