41–50 of 681 posts
It makes a bit more sense if you see Kubernetes as the new Linux: a common foundation that the industry agrees on, and that you can build other abstractions on top of. In particular Kubernetes is the Linux Kernel, while we are in the early days of discovering what the "Linux distro" equivalent is, which will make it much more friendly / usable to a wider audience
Earlier quoted context omitted.
According to the article you are wrong about "infrastructure as code". Kubernetes is infrastructure as data, specifically YAML files. Puppet and Chef are infrastructure as code. Edit: not sure why the down votes, I was just trying to point out what seems like a big distinction that the article is trying to make.
Maybe? I'm too lazy to formally verify if the YAML files k8s accepts are Turing complete. With kustomize they might very well be. How about "infrastructure-as-some-sort-of-text-file-versioned-in-my-repository". It's a mouthful, but maybe it'll catch on.
What does the Kubernetes configuration format offer over configuration management systems like Ansible, Salt, Puppet, Chef, etc?
What k8s brings to the table is a level of standardization. It's the difference between bringing some level of robotics to manual loading and unloading of classic cargo ships, vs. the fully automated containerized ports.
With k8s, you get structure where you can wrap individual program's idiosyncracies into a container that exposes standard interface. This standard interface allows you to then easily drop it into server, with various topologies, resources, networking etc. handled through common interfaces.
I said that for a long time before, but recently I got to understand just how much work k8s can "take away" when I foolishly said "eh, it's only one server, I will run this the classic way. Then I spent 5 days on something that could be handled within an hour on k8s, because k8s virtualized away HTTP reverse proxies, persistent storage, and load balancing in general.
Now I'm thinking of deploying k8s at home, not to learn, but because I know it's easier for me to deploy nextcloud, or an ebook catalog, or whatever, using k8s than by setting up more classical configuration management system and deal with inevitable drift over time.
What does the Kubernetes configuration format offer over configuration management systems like Ansible, Salt, Puppet, Chef, etc?
I'm not intimately familiar with those, but I did a lot of similar things with scripts. As far as I can tell: those are imperative. At least in some areas. Kubernetes is declarative. You mention the end state and it just "figures it out". Mind you, with issues sometimes. All abstractions leak. Note that k8s's adamance about declarative configuration can make you bend over backwards. Example: running a migration scrip…
I would be somewhat surprised to find out Puppet and Chef weren't declarative either. Because setting up a system in an imperative fashion is ripe for trouble. You may as well use bash scripts at that point.
I've used Ansible for close to 10 years for hobby projects. And setting up my development environment. Give me a freshly installed Ubuntu laptop, and I can have my development environment 100% setup with a single command.
For me, and many others: infrastructure as code. Kubernetes is very complex and took a long time to learn properly. And there have been fires among the way. I plan to write extensively on my blog about it. But at the end of the day: having my entire application stack as YAML files, fully reproducible [1] is invaluable. Even cron jobs. Note: I don't use micro services, service meshes, or any fancy stuff. Just a plain…
According to the article you are wrong about "infrastructure as code". Kubernetes is infrastructure as data, specifically YAML files. Puppet and Chef are infrastructure as code. Edit: not sure why the down votes, I was just trying to point out what seems like a big distinction that the article is trying to make.
It's not because of the networking stack. I've yet to meet anyone who can easily explain how the CNI, services, ingresses and pod network spaces all work together. Everything is so interlinked and complicated that you need to understand vast swathes of kubernetes before you can attach any sort of complexity to the networking side. I contrast that to it's scheduling and resourcing components which are relatively easy…
Kubernetes should have been IPv6 only, with optional IPv4 ingress controllers.
For me, and many others: infrastructure as code. Kubernetes is very complex and took a long time to learn properly. And there have been fires among the way. I plan to write extensively on my blog about it. But at the end of the day: having my entire application stack as YAML files, fully reproducible [1] is invaluable. Even cron jobs. Note: I don't use micro services, service meshes, or any fancy stuff. Just a plain…
Have you tried or considered Nomad (from the makers of Terraform)?
Cause those are the parts that I miss probably the most when dealing with non-k8s deployment, and I haven't had the occasion to use Nomad.
K8s is great - if you are solving infrastructure at a certain scale. That scale being a Bank, Insurance Company or mature digital company. If you're not in that class then it's largely overkill/overcomplex IMO when you can simply use Terraform plus managed Docker host like ECS and attach cloud-native managed services. Again the cross cloud portability is a non starter, unless you're really at scale.
And, we only have to learn one complex system and avoid learning each cloud, one of which decided product names which have little relation to what they do was a good idear
It's not because of the networking stack. I've yet to meet anyone who can easily explain how the CNI, services, ingresses and pod network spaces all work together. Everything is so interlinked and complicated that you need to understand vast swathes of kubernetes before you can attach any sort of complexity to the networking side. I contrast that to it's scheduling and resourcing components which are relatively easy…
Badly! That'll be $500, thanks for your business.
On a serious note, the whole stack is keeping ok-ish coherence considering the number of very different parties putting a ton of work into it.
In a few years' time it'll be the source of many war stories nobody cares about.
I still believe 90% of users would be better served by Nomad. And if someone says "developers want to use the most widely used tech", then I'm here to call bullshit, because the concepts between workload schedulers and orchestrators like k8s and nomad are easy enough to carry over from one side to the other. Learning either even if you end up using the other one is not a waste of time. Heck, I started out using CoreOS with fleetctl and even that taught me many valuable lessons.