101–110 of 127 posts
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/
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? 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. Ex…
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.
Running your own VMs without something like k8s? Yeah this setup I can deploy and have working in an hour is gonna take you a week to set up properly. Standardization is valuable. Abstraction is valuable.
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…
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.
Earlier quoted context omitted.
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…
>Complexity always exists somewhere. You can't remove it, only try it make it easier to deal with. This is simply not true. Most complexity in today's systems is completely avoidable. Most developers are just mentally stuck and don't even try. "Managing" complexity is a great way to achieve job security without becoming good at anything specific. Instead of learning how to design system people are learning how to wri…
If you don't need Kubernetes then don't use it. But if you do then you can't make it any simpler than the complexity needed to deliver the functionality.
Built in deployments, process health, logging, load balancing, security, high availability, config and secret management, volumes and persistence, and much more in exchange for some YAML files is a pretty good encapsulation of complexity though.
I don’t know how to feel about Kubernetes configuration apparently being so complicated that you need a generator for it, instead of just having the docs and your IDE open in split screen like with Docker Compose. That said, this still looks cool. I just hope we won’t need a Kubernetes configuration generator generator anytime soon.
Earlier quoted context omitted.
Thanks for the shout-out! We’re trying to be like an “open-Heroku” - back when I worked on OpenStack it was called “the open cloud” and no one knew what we were on about - open stack was enterprise as enterprise gets! Our goal is to make a Heroku-ish platform for getting an app online - but one that doesn’t hold you over a barrel later on. You can even host from a spare home server :) (Disclosure: I’m the CTO)
Do you still expose the k8s bits? I'm interested in/have previously given up on a product where the control plane is managed for me, I can join the cluster with bare metal nodes, and then it's just Kubernetes.
Right now we don't do "hosted control plane", rather - you can either use our hosted clusters where you have namespace-level access (so you still get to use Kubernetes, just not all of the resources, for example, no `Nodes`), or you can attach your own cluster to our UI (with the advantage that we can setup ingress and forward traffic to you, which is perfect for a home-hosting setup).
Hosted control plane is something im watching closely though - I'd really love to offer that as a service, but since we're small, we're trying to focus hard on a core offering. Will be considered in the future though!
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…
Well prepare to be unsurprised! The CI/CD abstraction already exists in Tekton - https://cloud.google.com/tekton The rest are soon to follow I’m sure.
Don’t get me wrong, I actually love tekton because I hate everything that is Jenkins and most other CICD tool integration with k8s. So tekton is just amazing in that regard.
But there is a huge learning curve for people who are used to old school tools like Jenkins and its pipelines .
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 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 really hope we move more towards these opinionated tools that can handle 90% of the use cases. Most people just want to host an app on a port, and it's a pain to have to develop that pipeline at every company that wants to adopt Kubernetes.
Earlier quoted context omitted.
IMO it needs two things: - a dedicated editor with intelligent autocomplete - stop using YAML, it soon becomes unreadable. JSON is easier to grok.
Unfortunately, JSON is much more annoying to edit. Best way is to stop using both, and generate the objects from higher level language, at least something like Jsonnet (which is really just a step up, so better not stop there but I will take what I can)
I'm on the fence about this, something like Dahl seems good, but I am not a fan of using fully-fledged higher level languages (the Pulumi approach) as I've been burnt before with devs writing bad code and generating configs in the most confusing, convoluted way possible.
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/