61–70 of 681 posts
Because everyone chases the newest, shiniest thing in tech, and it's not cool nor fun to make boring old stuff in C then copy one binary and maybe a config to the server.
The kubernetes ecosystem is really amazing and full of invaluable resources. It's vast, complex, but well-thought. Getting to know all ins and outs of the project is time consuming. So much things to learn and so little time to practice...
What does the Kubernetes configuration format offer over configuration management systems like Ansible, Salt, Puppet, Chef, etc?
Kubernetes is one way to deploy containers. Configuration systems like Ansible/Salt/Puppet/Chef/etc are another way to deploy containers.
Kubernetes also makes it possible to dynamically scale your workload. But so does Auto Scaling Groups (AWS terminology) and GCP/Azure equivalents.
The reality is that 99% of users don't actually need Kubernetes. It introduces a huge amount of complexity, overhead, and instability for no benefit in most cases. The tech industry is highly trend driven. There is a lot of cargo culting. People want to build their resumes. They like novelty. Many people incorrectly believe that Kubernetes is the way to deploy containers.
And they (and their employers) suffer for it. Most users would be far better off using boring statically deployed containers from a configuration management system. Auto-scaled when required. This can also be entirely infrastructure-as-code compliant.
Containers are the real magic. But somehow people confused Kubernetes as a replacement for Docker containers, when it was actually a replacement for Docker's orchestration framework: Docker Swarm.
In fact, Kubernetes is a very dangerous chainsaw that most people are using to whittle in their laps.
Earlier quoted context omitted.
So terraform is a higher-order, meta-Kubernetes. It's very rarely used, but who provisions the cluster itself? That's terraform. So terraform creates the cluster, DNS and VPC. Then k8s runs pretty much everything.
Why would you want to provision your own k8s cluster, if you can use EKS, AKS or similar?
Earlier quoted context omitted.
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've only ever used cfengine and Ansible, but they are both declarative. Hell, Ansible uses yaml files too. 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. G…
Sure, the steps are things like "if X hasn't been done yet, do it." That means it's idempotent imperative code. It doesn't mean it's declarative.
CFEngine is slightly less imperative, but when I was doing heavy CFEngine work I had a printout on my cubicle wall of the "normal ordering" because it was extremely relevant that CFEngine ran each step in a specific order and looped over that order until it converged, and I cared about things like whether a files promise or packages promise executed first so I could depend on one in the other.
Kubernetes - largely because it insists you use containers - doesn't have any concept of "steps". You tell it what you want your deployment to look like and it makes it happen. You simply do not have the ability to say, install this package, then edit this config file, then start this service, then start these five clients. It does make it harder to lift an existing design onto Kubernetes, but it means the result is much more robust. (For some of these things, you can use Dockerfiles, which are in fact imperative steps - but once a build has happened you use the image as an artifact. For other things, you're expected to write your systems so that the order between steps doesn't matter, which is quite a big thing to ask, but it is the only manageable way to automate large-scale deployments. On the flip side, it's overkill for scale-of-one tasks like setting up your development environment on a new laptop.)
as a sys-admin, I like k8s because it solves sys-admin problems in a standardized way. Things like, safe rolling deploys, consolidated logging, liveness and readiness probes, etc. And yes, also because it's repeatable. It takes all the boring tasks of my job and let's me focus on more meaningful work, like dashboards and monitoring.
What does the Kubernetes configuration format offer over configuration management systems like Ansible, Salt, Puppet, Chef, etc?
Having extensively used Chef and K8s, the difference is that they try to deal with chaos in unmanaged way (Puppet is the closest to "managed"), but when dealing with wild chaos you lack many ways of enforcing the order. Plus they don't really do multi-server computation of resources. What k8s brings to the table is a level of standardization. It's the difference between bringing some level of robotics to manual loadi…
can't you do that just with containers?
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)?
Earlier quoted context omitted.
So terraform is a higher-order, meta-Kubernetes. It's very rarely used, but who provisions the cluster itself? That's terraform. So terraform creates the cluster, DNS and VPC. Then k8s runs pretty much everything.
Why would you want to provision your own k8s cluster, if you can use EKS, AKS or similar?
What does the Kubernetes configuration format offer over configuration management systems like Ansible, Salt, Puppet, Chef, etc?
Containers are the big difference. Kubernetes is one way to deploy containers. Configuration systems like Ansible/Salt/Puppet/Chef/etc are another way to deploy containers. Kubernetes also makes it possible to dynamically scale your workload. But so does Auto Scaling Groups (AWS terminology) and GCP/Azure equivalents. The reality is that 99% of users don't actually need Kubernetes. It introduces a huge amount of comp…
So many people miss this. k8s is a very complex system and the talent it takes to manage it well, rare.
Extremely rare.