4 ms·

Containers are the big difference. Kubernetes is one way to deploy containers. Configuration systems like Ansible/Salt/Puppet/Chef/etc are another way to deplo

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 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.

geggam 6y ago
>In fact, Kubernetes is a very dangerous chainsaw that most people are using to whittle in their laps. So many people miss this. k8s is a very complex system and the talent it takes to manage it well, rare. Extremely rare.
- geggam 6y ago
  At some point I think I will setup an email account so I can offer to interview those downvoters 1st Question : Define k8s network, in detail, with all of the services and a set of services IF you make it out of that one and the follow ups we can move on to the rest
- adolfojp 6y ago
  Expectations have been set unrealistically high and online communities like this one make matters worse. Big players with dedicated devops teams use Kubernetes all the time so why shouldn't I? It's only a matter of time before "Hello world" tutorials include a chapter on container orchestration. So we end up with a plethora of full stack developers who can barely keep up with their current development stacks willfully deploying their software on systems that they're just barely competent with. I know this because I almost deployed a side project with Kubernetes because it was expected of me despite the fact that being mediocre at it was the best that I could hope to become and that's an easy way to chop off a leg or three.
closeparen 6y ago
Hm. Systemd already runs all your services in cgroups, so the same resource limit handles are available. It doesn't do filesystem isolation by default, but when we're talking about Go / Java / Python / Ruby software does that even matter? You statically link or package all your dependencies anyway.
- notyourday 6y ago
  Not only systemd runs your code it also does file system isolation built-in, runs containers, both privileged and non-privileged and sets up virtual networking for free. systemd-nspawn / machined makes the other systems look like very complicated solutions in search of a problem
  - mekster 6y ago
    systemd-nspawn seems overlooked by many. Name may not be pretty but it's an official feature of systemd which is used to debug the systemd development and it is far easier to take backups incrementally because the container files are just plain files in /var/lib/machines/ and apparently you already have it if systemd is on your system. (May need an additional package to be installed from OS package repo.) I run nspawn instances as development environments for developers and I can also run docker inside it.
radarsat1 6y ago
> It introduces a huge amount of complexity, overhead, and instability I've never used it but might find myself using it in the future.. can you elaborate on these a bit? I'm curious what the pitfalls might be

geggam 6y ago

>In fact, Kubernetes is a very dangerous chainsaw that most people are using to whittle in their laps. So many people miss this. k8s is a very complex system and the talent it takes to manage it well, rare. Extremely rare.

geggam 6y ago
At some point I think I will setup an email account so I can offer to interview those downvoters 1st Question : Define k8s network, in detail, with all of the services and a set of services IF you make it out of that one and the follow ups we can move on to the rest
adolfojp 6y ago
Expectations have been set unrealistically high and online communities like this one make matters worse. Big players with dedicated devops teams use Kubernetes all the time so why shouldn't I? It's only a matter of time before "Hello world" tutorials include a chapter on container orchestration. So we end up with a plethora of full stack developers who can barely keep up with their current development stacks willfully deploying their software on systems that they're just barely competent with. I know this because I almost deployed a side project with Kubernetes because it was expected of me despite the fact that being mediocre at it was the best that I could hope to become and that's an easy way to chop off a leg or three.

closeparen 6y ago

Hm. Systemd already runs all your services in cgroups, so the same resource limit handles are available. It doesn't do filesystem isolation by default, but when we're talking about Go / Java / Python / Ruby software does that even matter? You statically link or package all your dependencies anyway.

notyourday 6y ago
Not only systemd runs your code it also does file system isolation built-in, runs containers, both privileged and non-privileged and sets up virtual networking for free. systemd-nspawn / machined makes the other systems look like very complicated solutions in search of a problem
- mekster 6y ago
  systemd-nspawn seems overlooked by many. Name may not be pretty but it's an official feature of systemd which is used to debug the systemd development and it is far easier to take backups incrementally because the container files are just plain files in /var/lib/machines/ and apparently you already have it if systemd is on your system. (May need an additional package to be installed from OS package repo.) I run nspawn instances as development environments for developers and I can also run docker inside it.

radarsat1 6y ago

> It introduces a huge amount of complexity, overhead, and instability I've never used it but might find myself using it in the future.. can you elaborate on these a bit? I'm curious what the pitfalls might be