21–30 of 127 posts
We built this internally to test that the UI we built for Kubernetes deployments was producing the expected YAML. Thought it would be useful to share.
Thanks for sharing this useful resource! Paul, as an aside, we absolutely love how feature packed Octopus is nowadays. We have been using it since 2.0, and I don't think we will ever give it up. Thanks for making one of the best tools we use a daily basis!
We built this internally to test that the UI we built for Kubernetes deployments was producing the expected YAML. Thought it would be useful to share.
A UI like this is useful to so many. It makes the experience of creating these YAML files easier. Thanks for sharing it.
Earlier quoted context omitted.
heard good things about https://dhall-lang.org/#
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.
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 even a problem for the target audience?
I've no idea. I just know I'm a kubernetes admin and I can't write a deployment yaml without googling or copy/pasting.
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 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've always felt that Kubernetes isn't appropriate for most businesses to use directly, but rather it's a platform for simpler platforms--someone like Heroku would build on top of Kubernetes and expose a much simpler interface for their users so they don't have to think about SSL, DNS, logging, load balancing, auto-scaling, etc. Alternatively, maybe the problem is solved with "distributions" of Kubernetes analogous t…
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 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 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? Sure, here's a simple resource for that."
I think we'll start seeing a move towards more "opinionated" tools, just to outsource some of the decision making. No sense learning how to write your own pipelines if you can find a tool that says "we're gonna deploy every time you make a git tag and run `mvn package`, you figure the rest out".
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/
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 desired--many stupidly common things still can't be expressed (JSON, kwarg callbacks, etc), getting mypy to find/accept type annotations for libraries is stupidly hard, and the IDE integrations are pretty awful at this point. TypeScript users would enjoy a real leg-up here since its type system isn't half baked.
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've always felt that Kubernetes isn't appropriate for most businesses to use directly, but rather it's a platform for simpler platforms--someone like Heroku would build on top of Kubernetes and expose a much simpler interface for their users so they don't have to think about SSL, DNS, logging, load balancing, auto-scaling, etc. Alternatively, maybe the problem is solved with "distributions" of Kubernetes analogous t…
That is why in many businesses there is an OPS team managing the Kubernetes and providing tools like Cert-Manager, Istio, ... and the rest of the company who just use what the OPS team made.
Right now, everyone is building its own distro, proving IMHO the need for it.