> “The biggest mistake was to miss Kubernetes. We were in that collective thought bubble where internally we thought Kubernetes was way too complicated and Swarm would be much more successful,” Jérôme Petazzoni, one of Docker’s first and longest serving employees, said. “It was our collective failure to not realize that.”
They were not wrong on saying that Kubernetes was very complicated, at least in some sense. In the beginning no one wanted to use it because they could easily setup Docker Swarm with minimal effort. This argument still pops up frequently on HN when there's a new post about Kubernetes.
I guess the problem was they didn't realize why Kubernetes needs to be that complicated. And if a system is complicated for good reasons, that's actually good business opportunity and tons of people and companies will be willing to make the effort to fill that gap.
K8S is great if you have Google problems, but most people don't and I think much of hype around it is much like the hype that existed a decade ago around "web scale" and "big data" and "NoSQL for everything". Docker Swarm is (with some use-case specific exceptions) more than sufficient for any shop running a few hundred nodes with a few thousand containers – and it is two orders of magnitude less complex than k8s.
You can read Docker Swarm's docs end-to-end in < 30 minutes, and have a cluster running in roughly the amount of time it takes to install Docker on three boxes.
Docker's failing was a failure to market Docker Swarm. Most people don't even know it exists, yet every single machine with Docker has it already! The last time I checked, they only had a single dev that was part-time allocated to supporting it.
So it's not so much that Docker failed to jump on the k8s bandwagon, so much as they built a wonderful thing that they never marketed and semi-abandoned, to focus on Docker Hub and other core Docker things they thought they'd be able to more directly monetize.
Fortunately, Docker Swarm remains a wonderful piece of software, even without particularly active investment, because it is a fairly complete offering for most use cases. And it seems to be growing in adoption.
Unfortunately for Docker, I don't trust or want to use Swarm because of their attempts to monetize and because of the frequency that they push breaking bugs or breaking changes into production releases. To the extent that they made downgrading a paid option, not upgrading. And I'm in the process of switching everything I've got over to Podman now.
Swarm might be great, but the ecosystem around k8s is massive. So my two choices are: ignore Docker entirely and do it like I've always done (Heroku, chef, puppet, etc. just managing my servers myself), or buy into containers and go with K8S.
To that extent, I only ever deal with K8S at work, and for my personal stuff I don't go near Docker at all. Why would I when I can get an 8GB/4CPU VPS for $9/mo and serve everything I care about from that? I've got fail2ban, systemd, caddy, and plenty of resources.
I can host mysql on the same machine because there isn't a god-given law about hosting your DB on a separate box. Same with anything else.
Who do you use for your VPS provider? Those specs for that price are much better than what I typically see price wise on DigitalOcean, Linode, Vultr, AWS, etc.
I ignore docker myself. It's been too unstable for me and historically just costs me time, I'd rather just use systemd on a VPS. Occasionally when someone else has setup a complex system in docker I want to play with it has been convenient. Still, I avoid installing it at all.
This is exactly why I think new-cloud companies like fly.io, stackpath, deno.land, vercel.app are the future. No one wants to deal with muck if they can avoid it.
Cloud exposed data center primitives. Then, cloud-native laid bare the at-scale primitives. Imho, I think the industry is ripe for both NoCloud and NewCloud.
Did you read the article? It was about a company struggling to monetize an open source project. It hardly seems time for teenagerish M$-Windows asides on how you don't like people monetizing the software they are giving you for free.
What was implicit was the view that any "attempt to monetize" is hostile. Which, as I said, is something one associates with Linux hobbyists from the early 2000s.
> To the extent that they made downgrading a paid option, not upgrading.
Except that they didn't. With even a little bit of research you can easily find out that they made skipping updates a paid feature, and then even removed that after negative feedback!
People were even talking about downgrading below the version that introduced the 'paid update skipping', so any way you look at it, your comment doesn't make any sense.
It’s not a good look and that matters. If I’m going to rely on something for production, and that thing ships breaking changes and considers weird, terrible monetization strategies, I go elsewhere.
Spewing FUD is not a good look either. Introducing paid features is not a 'breaking change'–your pipelines and production code continued to work throughout all this–and charging large commercial enterprises for premium features is not a 'weird, terrible monetization strategy'.
IMO the complexity of k8s tends to be overstated. Of course its a vast and complex system, but its also incredibly well documented and based on simple design principles. The reason people have such a hard time with it is -
- deploying k8s on bare metal is not easy. It was never really designed for this and to be fair Google has a vested interest in making you use GCP. EKS is nothing more than cobbled together scripts and you still need to do a lot of manual work
- k8s introduces a ton of terminology and new concepts (pods/service/deployment/ingress) not to mention the whole host of addons built on top like Istio.
It shouldn't take any decent dev more than a couple days to install minikube/k3s or use a cloud provider, play around and get comfortable with k8s.
Coming from a long career in ops and systems administration, k8s was very straightforward to learn. All the complexity is in automating the things that I’ve already had to know how to do - scaling, failover, resource planning, etc etc.
You're trading for structured environment at the cost of complexity for sure, but I think there's something to be said about the degree of complexity. Ansible for example only requires python + some handful library + ssh connection whereas Chef/Puppet requires agent install + SSL for correct functionality.
Why only Google problems? Why not homelab problems where I'm managing upwards of 20 apps and I don't want to come up with custom automation to do things like cert renewal, tls termiantion, dynamic storage, and disaster recovery? What if I don't want to come up with my own system for organizing and grouping resources? Lots of homelab people (I assume) chain together hacky scripts and probably many things are not repeatable. With k8s, all my configs are in a single repo and I can spin back up my entire cluster on new hardware anywhere provided I've backed up my storage. How does Swarm handle all of these problems in a more unified or complete way that k8s does?
I'd heavily encourage you to read the docs. If the scenarios you outlined are your top concern for your homelab, I suspect the complexity and resource overhead of k8s isn't warranted.
- TLS Termination: Arguably this is an application layer concern and out of scope for an orchestration layer, but in either case use Nginx (or your favorite TLS terminating proxy) as your ingress point. This is equivalent to the Nginx ingress controller in k8s.
- Storage: Docker volumes (local or ceph, for distributed).
- Disaster Recovery: Node failure? Cluster failure? Data loss? What kind of DR? The strategies you'd use with Swarm will be very similar to those you'd use with k8s.
- Grouping resources: Labels and/or services.
In a Swarm world you'll have fewer moving pieces, far lower resource requirements, and will manage it all in a docker-compose file(s). You'll also get things like service discovery, routing, and secrets management for "free". No additional configuration needed.
I would argue the myriad of alternatives you've suggested as alternatives produce significantly more overhead.
You linked Swarm CA renewal operations; this is maybe 1/50 of the functionality of cert-manager. Is there a product like cert-manager that I can run on Swarm that's tightly integrated?
Why not have ingress intrinsically linked to the underlying reaources like k8s does? Your suggestion means that someone needs to come up with a methodology and automation to update ingress with Swarm. Yeah, it's obviously possible but imo, Traefik ingress reaources are way easier to manage with config spread across far fewer places.
Storage.. I have an nfs storage provider in k8s which allows me to dynamically create storage with lifecycle management included... for free... just because I'm using k8s.
DR as in something happens to my house or other technical issues which bring down my cluster. I would posit that it's much easier for me to restore a cluster because it's all yaml and imo more descriptive and capable than swarm yaml syntax.
I think you get my point. Yes, you can do it all with Swarm but with things like k3s and k0s, it's just as easy to start using k8s. And way more help, docs, and tooling to boot.
Honestly, this is such a common refrain in open-source communities.
"I'm going to use this product/project."
"You shouldn't use that, use this instead."
"But this product/project has all these features I want."
"Sure but you can just build and maintain those features yourself if you want. It's open source, after all!"
Or alternately:
"Well no one really needs those anyway, it's just people being told that they do."
I've been hearing this same refrain for over twenty years now. It seems as though some people don't understand that there's actual value in having a system that just works, rather than one that you have to build and maintain yourself just to emulate the system that works.
So, I don't use either of these things, but still tend to read the arguments between people who do, and that isn't what it feels like to me (as again, someone who doesn't use either of these things).
Specifically, it feels like you are missing that the people who argue against k8s are saying that it is extremely difficult to configure, and so instead of this clean "some people don't understand that it is nice to have a system that just works", it feels like the argument is actually about a tradeoff between what you think is easier to put together: a single system with a million options that seem to all need to be configured or it doesn't work or a handful of systems that are each easy to understand in separate, but where you will need to do all the glue manually.
I do partially agree with the point that you're making, but perhaps from a slightly different angle - i'd say that the biggest value that Kubernetes provides (or at least tries to, with varying results), is having a common set of abstractions that allow both reusing skills and also treating different vendors' clusters as very similar resources.
> It seems as though some people don't understand that there's actual value in having a system that just works, rather than one that you have to build and maintain yourself just to emulate the system that works.
This, however, feels like a lie.
It might "just work" because of the efforts of hundreds of engineers that are in the employ of the larger cloud vendors, because they're handling all of the problems in the background, however that will also cost you. It might also "just work" in on prem deployments because you simply haven't run into any problems yet... and in my experience it's not a matter of "Whether?" but rather one of "When?"
And when these problems inevitably do surface, you have to ask yourself, whether you have the capacity to debug them and mitigate them. In the case of K3s clusters, or another lightweight Kubernetes distro that might be doable. However, if you're dealing with a large distro like RKE or your own custom one, then you might have to debug this complex, fragmented and distributed system to get to the root cause and then figure out how to solve it.
There's definitely a reason why so many DevOps specialists with Kubernetes credentials are so well paid right now. There's also a reason for why many of the enterprise deployments of Kubernetes that i've seen are essentially black holes of manhours, much like implementing Apache Kafka when something like RabbitMQ might have sufficed - sometimes because of chasing after hype and doing CV driven development, other times because the people didn't know enough about the other options out there. There's also a reason for why Docker Swarm is still alive and kicking despite how its maintenance and development have been mismanaged, as well as why HashiCorp Nomad is liked by many.
In short:
The people who will try to build their own complex systems will most likely fail and will build something undocumented, unmaintainable, buggy and unstable.
The people who try to adapt the technologies that are better suited for large scale deployments for their own needs, might find that the complexity grinds their velocity to a halt and makes them waste huge amounts of effort in maintaining this solution.
The people who want to make someone else deal with these complexities and just want the benefits of the tech, will probably have to pay appropriately for this, which sometimes is a good deal, but other times is a bad one and also ensures vendor lock.
The people who reevaluate what they're trying to do and how much they actually need to do, might sometimes settle for a lightweight solution which does what's necessary, not much more and leads to vaguely positive outcomes.
> the biggest value that Kubernetes provides is having a common set of abstractions that allow both reusing skills and treating different vendors' clusters as very similar resources
This is the real value of Kubernetes. I'm at my fourth kubernetes shop and the deployments, service, ingress, pod specs all look largely the same. From an operations standpoint the actual production system looks the same, the only difference between companies is how the deployments are updated and what triggers the container build and how fast they're growing. Giant development/engineering systems went from very specialized, highly complex systems, to a mundane, even boring part of the company. Infrastructure should be boring, and it should be easy to hire for these roles. That's what Kubernetes does.
Oh, and it scales too, but I'd say 95% of companies running their workloads on k8s don't need the scaling it is capable of.
Yeah I've heard the endless "Kubernetes is too complicated arguments" but at a glance it's a container deployment/management service that the big three cloud providers all support which makes it close enough to a standard.
The issues with large clusters you've surfaced are ones I've never once experienced in my homelab. I'm already an experienced devops (?) engineer so the transition to k8s only took a few weeks and a couple sleepness nights which will not be everyone's experience, especially beginners. But it's a cohesive system and once you learn it, you understand the various patterns and you make it work for you vs you sucking time into it. For myself, learning k8s was way easier than keeping track of various little scripts to do this or that in a swarm cluster.
Folks here are making sound arguments for swarm and alternatives and they are totally valid. But for an experienced engineer who needed to start their homelab back up after a long hiatus, I will never look back once for choosing k8s. Honestly some of the most fun I've had with computers in a long time and great experience for when I move into a k8s related $job.
> the transition to k8s only took a few weeks and a couple sleepness nights
Only?
I have had a home server for fifteen years and used to have a homemade router. That's significantly more time than I have ever spent on them. I don't even bother maintaining scripts for my home installation. I have reinstalled it once in the past decade and it took me significantly less time than writing said scripts would have. There was enough things I wanted to do differently that any scripts would have been useless by that point anyway.
At that point, it sounds more like a hobby than something saving you time.
I guess I never considered self-hosting as not a hobby? Web apps with modern stacks are usually pretty complex, so hard for me to imagine someone just casually jumping in as a non-hobby and not running into big problems at some point. Or getting hacked because you didn't bother or forgot to secure something.
> Web apps with modern stacks are usually pretty complex, so hard for me to imagine someone just casually jumping in as a non-hobby and not running into big problems at some point. Or getting hacked because you didn't bother or forgot to secure something.
That's not my experience at all. Plenty of web apps for self hosting are pretty simple. You just install the packet, read the config files, turn on and off what you need and you are good to go. Since systemd made that easy, most apps now come preconfigured to use a dedicated users and drop the capabilities they don't need. If they don't, you are two lines aways from doing it in their service file.
Then I just throw Caddy in front of everything I want to access from outside my local network and call it a day.
Out of all of those, my experiences have only been positive with K3s (though i haven't tried k0s) and RKE, especially when using the latter with Rancher ( https://rancher.com/ ) or when using the former with Portainer ( https://www.portainer.io/solutions ).
In most of the other cases, i've run into a variety of problems:
- different networking implementations that work inconsistently ( https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy )
- general problems with networking, communication between nodes, and certain node components refusing to talk to others and thus nodes not allowing anything to be scheduled on them
- large CPU/RAM resource usage for even small clusters, which is unfortunate, given that i'm too poor to afford lots of either
- no overprovisioning support (when i last tried), leading to pods not being scheduled on nodes when there's plenty of resources available, due to unnecessary reservations
- problems with PVCs and storing data in host directories, like how Docker has bind mounts with few to no issues
- also, they recently stopped supporting the Docker shim and now you have to use containerd, which is unfortunate from a debugging perspective (since a lot of people out there actually like Docker CLI)
If i could afford proper server hardware instead of 200GEs with value RAM then i bet the situation would be different, but in my experience this is a representation of how things would run in typical small VPSes (should you self host the control plane), which doesn't inspire confidence.
That said, when i compared the RAM usage of Docker Swarm with that of K3s, the picture was far better! My current approach is to introduce clients and companies to containers in the following fashion, if they don't use the cloud vendors: Docker --> Docker Compose --> Docker Swarm --> (check if there's need for more functionality) --> K3s.
The beautiful think is that because of the OCI standard you can choose where and how to run your app, as well as use tools like Kompose to make migration very easy: https://kompose.io/
Traefik, for example, handles certificates for your services. I've set it up this morning on our Docker Swarm at work, 5 domains are now served by it with automated ACME certificates.
It's not like cert-manager does rocket science that is possible only on k8s
> You linked Swarm CA renewal operations; this is maybe 1/50 of the functionality of cert-manager. Is there a product like cert-manager that I can run on Swarm that's tightly integrated?
> Why not have ingress intrinsically linked to the underlying reaources like k8s does? Your suggestion means that someone needs to come up with a methodology and automation to update ingress with Swarm. Yeah, it's obviously possible but imo, Traefik ingress reaources are way easier to manage with config spread across far fewer places.
Traefik can provide a lightweight ingress for Docker Swarm clusters alongside ensuring most of the certificate related functionality that you might want for web apps: https://traefik.io/
It integrates well enough that you can set up listening for particular ports, domain names, set up basicauth, use Let's Encrypt for certificates and do many other things with labels inside of your Docker Compose file!
> Storage.. I have an nfs storage provider in k8s which allows me to dynamically create storage with lifecycle management included... for free... just because I'm using k8s.
Docker also supports volume plugins, some of which were carried out of the base offering not to create needless bloat (much like what K3s does with many other in tree plugins of the heavyweight Kubernetes distros): https://docs.docker.com/engine/extend/plugins_volume/
You'll find examples of SSHFS, NFS, CIFS/Samba there, which should cover most base use cases. The latter two are supported by the default "local" driver (which feels like a naming failure on their part), so it's safe to say that Docker and Docker Swarm support both NFS and CIFS/Samba out of the box.
> DR as in something happens to my house or other technical issues which bring down my cluster. I would posit that it's much easier for me to restore a cluster because it's all yaml and imo more descriptive and capable than swarm yaml syntax.
With Swarm, i've actually found that it's actually very easy to both manage the cluster, resolve any issues (because of very few moving parts), or even just wipe it all and create it anew with all of the deployments in a few commands. Furthermore, there is a very lovely Ansible Swarm module if you'd like: https://docs.ansible.com/ansible/latest/collections/communit...
In short, fewer moving parts equal easier administration and fewer Byzantine failures in this case.
> I think you get my point. Yes, you can do it all with Swarm but with things like k3s and k0s, it's just as easy to start using k8s. And way more help, docs, and tooling to boot.
K3s and other projects like it are a step in the right direction for Kubernetes in smaller deployments! That said, in my experience, the documentation of Docker Swarm is comparatively better to that of many of the Kubernetes distro projects, simply because of how mature and stable Docker and Docker Swarm both are.
I don't doubt that the situation will change in a few years, but until then, Swarm is more than enough.
My problem with swarm is that the overlay networking was super flaky. Dead containers still being registered on the network cause every X requests to fail (since it’s round robin) because it’s routing to an overlay IP that doesn’t exist.
Further, I could never find storage adapters for cloud storage that continued to be maintained. Rexray was the longest standing but hasn’t had a commit since Jan 2019.
I personally use Docker Compose for homelab deployment. It handles internetworking dependencies, and with nginx-proxy + letsencrypt-nginx-proxy-companion you get automatic subdomain redirection and certificate renewal.
I will say that it's still a fair amount of complexity, but it's a workable amount of complexity on a day-to-day basis.
I've been using Ansible's Docker module to manage my containers in my homelab, and I've been meaning to switch it to Docker-Compose for a while now, because it's kind of a pain to have to wait for the playbook to run for simple container changes (among other annoyances).
Overall, though: Traefik proxying to Docker Containers has been _very_ smooth in my Homelab: I'm loving it.
I got all my personal services dockerized and running in a bunch of Docker Compose (not even Swarm) and an nginx as an ingress and SSL termination point. I have all the configs in one repo too. I chose nginx because I am quite familiar with it, but I believe that Caddy may do the same work even easier.
The problem with solutions bigger than `docker-compose up -d` and smaller than k8s is that they have a growth ceiling, real or imaginary. Sooner or later you will hit some limitation and will either thrash against it or have to upgrade to k8s. As a decision maker in an IT org, you can either:
- pick up Swarm or Nomad now, and then potentially be blamed for the expensive and costly migration to k8s
- pick up k8s now, waste the time of your (voiceless) devs and ops on an overengineered solution, but retain access to the larger pool of technologies and a smooth upgrade path should the need arise
You've posed a false dichotomoy. I've worked at multiple billion dollar startups that got by just fine without k8s. And I've worked at startups that started on completely different stacks and migrated to k8s. If you're already containerized, you've reserved a good amount of optionality.
The kind of reasoning you pose is similar to "SQL doesn't scale to infinity, so start with an infinitely scalable eventually consistent document store". This line of thinking is dangerous to most companies, and often the death of startups. Assume YAGNI.
There's some truth to "Nobody ever got fired for choosing IBM", but IBM was never a good choice for anyone except consultants. k8s isn't too far from that.
But you are posing a similar false dichotomy. k8s isn't some massive intractable beast that needs an army of consultants to run and maintain.
It can run small loads just fine as well.
Anyone can leann k8s basic principles in a day or 2. And managing a cluster is arguably easier than managing a typical bunch of EX2 instances+ALB etc that almost everyone uses.
k8s also has the advantage of ubiquity. If I had to manage a bunch of containers on a cluster with > 10 nodes, I'd pick k8s over swarm/nomad etc.
Your argument is 'k8s isn't a good choice for anyone except Google-scale' and I don't think thats true at all.
> k8s isn't some massive intractable beast that needs an army of consultants to run and maintain.
As someone who has actively avoided k8s (despite enjoying devops), my observation has been quite the opposite. At my current (small) org we have one devops guy who spends all day working on k8s related work (configuration, troubleshooting, automation, etc.) And we're about to start looking for another devops engineer because he's swamped. We only have a handful of clusters up and running so far.
k8s is the poster child for overcomplicating matters for folks that don't have Google-scale problems.
You might be doing it wrong. I use k8s for my personal projects and the maintenance overhead is lighter than what it cost me to log into my VPS every 3 months and renew the Let's Encrypt certificate. (Which was literally just pressing the up arrow and enter, because it was always the last thing in my shell history.) At work, a team of 5 people maintain our production Kubernetes clusters (that host our cloud product and app), and develop the app itself. Which by the way, creates Kubernetes clusters for individual customers, of which we have created thousands of. Overall, it's not that hard and we don't spend much time managing computers. (We do have all of the good stuff, like all K8s changes in Git, one-click deploys, etc. I did spend a little time making Shipit run in Kubernetes, but it certainly wasn't my full time job for any extended period of time.)
There are problems that people run into. One is not needing more than one computer -- if everything you need to run fits on one computer, you might as well use systemd as your orchestrator. (Which people also say is overly complicated, but really it's just extremely misunderstood.) The other is not understanding Kubernetes enough. A lot of people just explode random helm charts into their cluster and are mad that it's hard to maintain. Basically, adding another abstraction layer only helps if you can debug the actual thing on the surface -- otherwise, you're just setting a time bomb for yourself. (And, helm charts require you beg the maintainers for every feature you could possibly need, and once enough people have done that you just have raw k8s manifests where everything is called some random word instead of its actual thing. Really bad. Use Kustomize or jsonnet!)
Compared to something proprietary like AWS ECS, K8s seems like it's almost impenetrable to learn. If you're already on one of the cloud providers, likely they will have something else to offer.
ECS isn't exactly simple either, but it is manageable for small shops where the developer is the devops guy.
it’s not only suitable for google scale problems, rather it isn’t for all problems. Like a lot of new shiny tech, it takes time investment to find out if something really is the solution to a problem. Don’t just jump in with both feet.
As one of the mentioned consultants, I think the statement that one can learn Kubernetes in a day or two grossly unfair. It is a complicated beast, for better and for worse. The (almost) unique selling point is that it is an orchestration layer that is pretty much provider agnostic in a believable way.
I didn't mean to imply you can learn it in a few days, but you can certainly learn the basic design principles and overall approach, and its pretty consistent across all the k8s products.
And that is a sound solution if you have limitless VC bux to burn while you implement your over-engineered solution, but most shops have to be a little bit scrappier.
Not to mention that you end up scaling to a size where k8s is a sound solution, that "costly" migration is going to be a rounding error on your balance sheet
> that "costly" migration is going to be a rounding error on your balance sheet
This. Just because your services are containerized doesn't mean they'll scale well with each order of magnitude. Likely you'll need to re-architect other parts of the system to work at your new scale.
> smaller than k8s is that they have a growth ceiling
Kubernetes has a serious growth ceiling - way below what Nomad has. So if you actually have a problem of interesting scale, it's almost certainly "pick Nomad now, or get blamed for a costly migration later when you realise that Kubernetes is not for you".
I've hemmed and hawed over this as well, but I believe that sometimes software can be complete and stable and not need constant iteration. As long as they add security patches and don't remove it from Docker, I'll still default to Swarm.
My fallback, if Swarm is ever removed, is Hashicorp's Nomad. I've only used it in a hobby capacity, but is (at face value, at least) another wonderful piece of software. I've used k8s a bunch in production (including right now at my current employer) and just can't recommend it – it's a technical distraction for most teams.
The dream is to be able to take a software and yeet it into the cloud with minimal effort. That's not kubernetes at all.
That said, if your tooling or products or software supports kubernetes, which a lot more are these days, then it becomes a lot easier. A lot of companies these days are saying "Here's how to install it, or just grab this helm chart"; Gitlab, for example. We even had one piece of software we were testing which only had two options: cloud-hosted, or self-hosted on k8s. Nothing else was supported.
k8s doesn't seem to be any easier to configure, with the possible exception of microk8s (which has its own issues), but the amount of things you can do with it once it's up and running is compelling.
Pretty much. Fundamentally Kubernetes “won.” Try to pitch your company on something else and you’re asking them to bet on something else “without particularly active investment” to use your words. As well as much less of a complementary software ecosystem.
K8S based on distros like k3s or microk8s is a great and simple solution for manufacturing and managing edge devices, IoT solutions and similar products that are setup once on a single box that runs half a dozen or more things and are shipped to business clients.
It is very simple to spin a minimal distro based cluster. It is relatively simple to have it up and running your solution. Sure getting Kubernetes from the source and tailoring all the required components to run cluster with full HA etc' is a complex stuff, but building a private cloud based on vanilla Kubernetes isn't the only or the most common use case.
I've also seen more of it being used for deployments of on-prem versions of SaaS services. I think the idea is that if you're already hosting your SaaS services on k8s distributing a machine image to your Enterprise customers running a scaled down deployment of your services on a single node kube cluster makes some of the packaging and updating challenges easier.
I suspect that there is a tendency to pick more powerful and complex tools and infrastructure than needed. For us as engineers it's easy to foresee some of the scaling-related, technical problems of the far future. It's so tempting to prepare for those, especially if you need to learn a new technology anyways and it looks great on your resume. In addition everyone knows intellectually that their own startup is unlikely to reach Google scale, but we do badly want to believed it will. So maybe the right bet is to always put your money on the more powerful and complex technology as long as the complexity is inherent and not incidental. Of course this is also limited to infrastructure. Consumer products and other markets would be totally different
One of the tough lessons of my years as a developer is many developers love to adopt Google scale solutions and Google practices because they’re from Google and they come with prestige and a feeling of proximity to the most visible technology company. Whether their problems are a good fit for Google scale solutions or not. It’s inevitable and it takes a lot of soft skills to argue against even if it’s dead obvious you’re going to be running a few instances of an application maximum. The simple solution is far less sexy than the Google solution.
On this note, HN users and several HC employees (including some enterprise architects) I've spoken to love to mention Nomad and how it's much lighter and simpler to run, completely oblivious that many with bigger names have tried and failed to go up against K8s.
Kubernetes has become a speeding bullet, it won't be easy to catch and it has to run through a lot of walls to slow down for a competitor to do any damage to it's dominance.
> completely oblivious that many with bigger names have tried and failed to go up against K8s
Ha, I can at least assure you we're not oblivious. Nomad has a product manager from Mesosphere and most of HashiCorp's products integrate deeply with Kubernetes. We're well aware Kubernetes is the juggernaut to which every other scheduler has succumbed.
I believe there's room for both Nomad and Kubernetes. Whether as competitors or complements, having more than one vibrant project in the orchestration space will hopefully make all the projects better for users. Any one project has to make tradeoffs that improve the user experience for some while degrading it for others. For example Kubernetes has an IP-per-Pod network abstraction which provides an excellent out of the box PaaS-like experience for microservices in the cloud. On the other hand Nomad's more flexible network model more easily supports networks outside of flat cloud topologies whether it's small home raspberrypi clusters or globally distributed edge compute.
Sorry, I think I came across dismissive of Nomad which I am not. I work with multiple products in the HC stack daily, but have yet to work with Nomad, however, the bits that I have seen and read about Nomad, it seems like a great tool, and I agree there is place for Nomad in the current ecosystem, just like there is place for ECS. Even if I didn't think so, at the very least, like you said, it's good to have competition.
What I was calling out is the abundance of people who claim it is the greatest thing since the tech equivalent of sliced bread, and love to point out how simple it is despite requiring the need for Consul to run it at enterprise scale and likely also Vault if you need secret management in any form, which then also needs Consul if you want to run it at scale. I have intimate experience with running Vault and Consul and have advised colleagues for the better part of 2 years on utilising Vault (either as basic secrets management or some of its more advanced features). IIRC the recommendation from HC is also running a third Consul cluster for service discovery. If running Nomad at scale is anything like Vault, then it isn't as simple as people make it out to be, never mind the fact that you'll probably be running 5 different clusters of 3 different products to provide functionality that doesn't fulfill half of what Kubernetes gives.
> If running Nomad at scale is anything like Vault, then it isn't as simple as people make it out to be, never mind the fact that you'll probably be running 5 different clusters of 3 different products to provide functionality that doesn't fulfill half of what Kubernetes gives.
The complexity of setting up a Nomad cluster due to Vault and Consul being soft requirements is very real and something we're hoping to (finally!) make progress on in the coming months.
you would need to make it as simple as running k3s on 1,3,5 nodes and probably also have stuff like system-upgrade-manager and another good idea is to work on flatcar linux, etc.
k3s is so good for small-middle sized metal clusters and also works on a single node. it's so simple to start, you will have a rough time to actually try to gain momentum in this space which will also not generate a lot of revenue.
the only thing which is not so easy is LoadBalancing to extern i.e. kube-vip/metallb both can be a pain (externalTrafficPolicy: Local is still a shit show).
k3s basically creates a k8s cluster with everything except good load balancing over multiple nodes
A single Nomad process can be the server (scheduler) and client (worker). Nomad can run in single server mode if highly available scheduling is not a concern (workloads will not be interrupted if your server does go down) by setting bootstrap_expect=1 (instead of 3, 5, 7, etc). You can always add more servers later to make a non-HA cluster HA. No need to use different projects to setup different clusters. Clients can be added or removed at any time with no configuration changes (people using Nomad in the cloud generally put servers in 1 ASG and clients in another ASG).
Nomad does not have a first class LoadBalancing concept in keeping with its unopinionated network model, although we may add ingress/loadbalancing someday. Right now most people use Traefik or Nginx with Consul for ingress, and Consul Connect is popular for internal service mesh. Obviously unfortunate extra complexity over having it builtin, but Nomad has been focused more on core scheduling than these ancillary services so far.
Thing is, Nomad isn't trying to go up against K8S. It's part of the Hashicorp family of products, so if you use a couple of those, it's easy to add Nomad into the mix, or just use K8S. While other competitors have tried to out-do K8S, Hashicorp seem to try to work with the broader eco-system, which means some will just use Nomad to keep it simple, but don't need to for Hashicorp to continue working for them in other areas.
It's an incredible litmus test for developer v sysadmin. Developers think the complexity is unnecessary and so don't want to learn k8s. For sysadmins it's mostly just nice automation around all the chores we used to do with home-brewed bash scripts.
As a developer, I hate k8s, but mostly because my management does not understand difference between developers and devops. They changed our job titles to devops engineers and fired sys admins. I understand k8s is complex for people who specialize in it, try imagining as a developer, you need to setup private vlan ingress. At least, on regular Linux, I know how to setup ip tables or look up 1000s of tutorial.
K8s and devops has destroyed us developers' productivity, confidence, and morale.
I don't disagree but I don't know where they are getting their marketing material where they think developers can do devops. I suspect it might some sales tactics from these Cloud/DevOps companies.
I wonder if some of the derision is at least due in part to k8s effectively forcing you to think about certain application characteristics upfront instead of addressing them later when you outgrow the single instance performance or suffer an outage.
I’ve seen a number of companies going for k8s and not other solution not because they needed the complexity, but because it was first party supported.
To me what killed Swarm is Google needing to spread k8s.
If you are eyeing at GCE but decide you want a bit more flexibility, going for a Google backed solution gives you k8s, and Swarm isn’t even on the choice list.
Choosing a third party means you’re on your own to bootstrap/make it live, or contract a vendor that might not live longer than you. That’s fine for companies who strategically choose to invest for the long term, sadly that’s not most of the companies out there.
I think docker itself had plenty of time to innovate. They could have solved the problem long before mainstream got a hold of kubernetes. They just didn't solve the actual problems users where having at that time, which was container orchestration across multiple servers. They went very very deep with a lot of drivers and API changes and what not. If I am not mistaken docker-compose wasn't even a part of docker first before it got bundled, someone else was solving docker's same-server orchestration problems.
Kubernetes is for a lot of organisations pretty difficult and way too much for a start. We used rancher for solving our problems which did a fine job, rancher got a worse when they made the move to Kubernetes.
In the beginning they (docker) also removed a lot of options like cpu throttling and configuration and such that LXC had from the start. They also had their own version (a shim) of pid 1, some point at the time. And other things that made it a little painful to properly containerise. I was often very frustrated by docker and fell back on lxc.
There was also something with the management of docker images like pruning and cleaning and other of much needed functionality that just didn't get included.
Also something with the container registries which I a this point can't remember (maybe deleting images or authentication out of the box or something that made it hard to host yourself).
Anyway I think it's failed because it failed to listen to its users and act upon them. They really had a lot of chances I think. I think they just made some wrong business decisions. I always felt they had a strong technical CTO that really was deep on the product but not on the whole pipeline from dev->x->prod workflows.
> We used rancher for solving our problems which did a fine job, rancher got a worse when they made the move to Kubernetes.
(Early Rancher employee)
We liked our Cattle orchestration and ease of use of 1.x as much as the next person. Hell, I still like a lot of it better.
But just as this article talks about with Swarm, embracing K8s was absolutely the right move. We were the smallest of at least 4 major choices.
Picking the right horse early enough and making K8s easier to use led us to a successful exit and continued relevance (now in SUSE) instead of a slow painful spiral to irrelevance like Swarm, Mesos, and others and eventual fire-sale.
Ah nice to hear from a rancher employee <3. Ah yeah, I totally understand the move, no blame there. But cattle was just amazing, it was easy and elegant!
If you're talking about a hosted k8s like EKS or a toy/single-node k8s, in 2021, then nothing: k8s is much better.
But if you're on-prem, and have a tonne of metal and just arrived in 2014 via a time machine, swarm was so much simpler and simpler that if you were a sysadmin who already had their own scripts -- their own jenkins-powered IC and git-hooks that built and deployed -- whatever it is you were building -- then swarm looked like a nice gradual extension of that, and k8s looked more like starting over and admitting defeat.
I mean k8s is basically an infra rewrite in any shop that was/is currently VM based. "Hey you know that fundamental unit of isolation you've built all your tooling around. Throw it all away."
Don't get me wrong, I would absolutely go with k8s on any greenfield project but there's a huge huge opportunity for someone to take everyone's VM orchestration tools and quietly and semi-transparently add k8s support for gradual migrations.
Personally, k8s is one of the easiest system I learned to use in the past few years. It has many components, too many that one can't practically understand all of them well. But every component follows the same design principle, so there's a clear path for a noob like me to get the full picture step by step.
The first thing I read on k8s was controller pattern[0]. Then everything becomes so easy to learn. Something wrong with a pod? Find its controller and start troubleshooting from there. Oh, the pod is controlled by a replicaset? Check replicaset controller. The replicaset is managed by a deployment? You know where to go.
That's why I said it is only complicated in some sense. I saw a lot of people started learning this system by going through a list of popular components and their concepts. I would've gotten lost easily and probably given up if I did the same in the beginning.
k8s is just a bunch of processes working together. The downside is that if something goes wrong, it is unclear which process is faulty and how to fix it. A misconfigured DNS may take down the whole cluster, and the symptoms are that every process fails because the network is out. Difficult to backtrack to the fault source, there are a lot of configs pertaining to the network that could be faulty.
On the plus side, if someone else configured the cluster correctly for you (e.g. a Cloud service like GKE), then it's a breeze to use.
As a guy who's been running stuff with docker-compose and is learning k8s, the learning curve for k8s is a cliff. Every single layer of the stack gets added complexity.
Look at the history: In the beginning Kubernetes didn't have deployments - only replicasets, it didn't have ingress, it lacked the cloud provider integration you have today...
It was barebones like Mesos but they managed to focus on the right things early on. Once these features and a bit of an ecosystem started to build, the question if we should stay on Mesos with a bunch of homegrown management tooling or move to Kubernetes wasn't even a decision anymore. There was still a significant amount of code which we later just deleted because it became a first class feature or the community implemented something much better.
> I guess the problem was they didn't realize why Kubernetes needs to be that complicated.
Does it?
It seems like there are three kinds of complexity involved here: the essential complexity of the total problem set, the essential complexity of a specific company's problems, and the amount of complexity experienced by a user as they try to solve those problems.
Let's stipulate that Kubernetes needs to be that complicated for Google's needs. I'm not totally sure that's true, but let's pretend for now. So we'll say you're right for the first kind.
But I'm still not seeing it for the other two.
For modest deployment efforts, Kubernetes is a giant pain in the ass. It's just way more complicated than needed for many non-Google use cases. I tried setting up Kubernetes for a bunch of personal stuff I run and it was egregious overkill. I persisted until my home lighting system went dark because some internal Kubernetes keys expired and it decided that just not working was a good failure mode. Last time I mentioned this on HN several people said, well duh, obviously you shouldn't run it just for yourself. And that's fine; every technology has an expected operational envelope. But there are an awful lot of projects out there that have between 0.0 and 0.5 sysadmins. For them it's too complex. Kubernetes is just too complex for many people's needs.
And the other side of that is complexity of experience. Modern processors are fantastically complicated. I'm on a mailing list for people in finance who micro-optimize everything to maximize response speed. Those people know incredible amounts about exactly what different processors do. And they have to. But most working developers know about 1% of that because a lot of people work very hard to hide the complexity from them. I don't think that really happened with Kubernetes.
At this point, it is what it is. It's much easier to scale a technology up than down, so I expect it'll always be like this. But For whatever comes after Kubernetes, I'd like to see much more attention paid to more common use cases.
It's really unfortunate. I am a kubernetes user today, but I LOVED swarm. K8S' main differentiator is that specific intentional "cross-cloud" features such as ingress and volume mapping that help the implementing cloud understand the deployment topology. It's basically the new PaaS but instead of working on one cloud it can work on any.
I don't know that if Swarm had those features if it would really catch on like Kubernetes did. They didn't have the same budget as Google on that side of things.
What I haven’t seen mentioned here is at least by my recollection swarm was incredibly bug ridden especially in networking layer around ‘17/18 when k8s really started pulling away
I beleive that wide k8s adoption is the same dead end as JS frameworks. It is not actually needed and is too complex, so it introduced it's own class of pain. VMs were a great abstraction with very little added complexity, so was Docker. K8s doesn't abstract anything away compared with Docker swarm, just adding unnecessary complexity.
The ironic thing is that Docker became successful only because of the tremendous hype they generated about themselves, and then failed to see the K8s hype train barreling towards them.
Swarm is still what 99% of companies need when they adopt Kubernetes, and is probably 1/10th to 1/20th the cost. Somebody needs to re-invent swarm as an independent project so that we can stop investing in K8s. The cost of K8s isn't even in the complexity, it's in all the millions of side-effects of the complexity, like security, fragmentation, and specialization.
> I guess the problem was they didn't realize why Kubernetes needs to be that complicated.
I guess this strongly depends on one's needs. I mean, if all you want to do is glue together a couple of nodes and have a few stacks running on them, do we really need all the bells and whistles?
I mean, with Docker Swarm anyone can get ingress right from the start on any bare ones cloud provider. Deploy your Docker Swarm cluster, slap a service like Traefik, and you're done. It's a 10min job. What else does Kubernetes brings to the table?
They were not wrong on saying that Kubernetes was very complicated, at least in some sense. In the beginning no one wanted to use it because they could easily setup Docker Swarm with minimal effort. This argument still pops up frequently on HN when there's a new post about Kubernetes.
I guess the problem was they didn't realize why Kubernetes needs to be that complicated. And if a system is complicated for good reasons, that's actually good business opportunity and tons of people and companies will be willing to make the effort to fill that gap.