I'd argue that just about every infrastructure that looks like this benefits from Kubernetes (that you're not setting up and managing), and that's a lot of them. The biggest problem is that not enough people have boiled down Kubernetes enough to look like heroku yet. Google Cloud Run is possibly the best example of what Kubernetes can look like/run like -- it runs on (probably a relatively heavily modified) KNative, a project that runs on top of kubernetes.
The "point" of Kubernetes is to drop the difficulty of building a service like Cloud Run to zero. It drops the cost of building a Heroku down to zero. I'd bet my bottom dollar that fly.io and render are running on Kubernetes (maybe they mentioned it somewhere already and I just missed it). With the right cluster set up, building one of those platforms (or others that I won't mention) is almost as simple as setting up stripe checkout and writing a web interface to turn form fields into JSON fields and send them to a kubernetes cluster (possibly with hard multi-tenancy! not to get too into it, but you can literally provision kubernetes clusters from kubernetes clusters, ephemeral or otherwise).
No other tool in the devops world except for maybe the initial orchestrator wave (ansible/puppet/salt/chef) has been this much of a force multiplier. Ok, maybe that's hyperbole, but if adhoc-bash-scripts->ansible is 1->2, Ansible->Kubernetes is similarly 1->2, especially if you consider baked in cloud provider support/innovation.
But here's the secret -- perversely, I'm happy deep down that everyone thinks k8s is too complicated/is a buzzword/isn't worth the effort. All it means to me is that I'm still ahead of the curve.
I think time will tell that ANY cluster setup is a high risk for smaller businesses. The amount of knowledge needed to run it in production is much higher than to set it up.
I have setup Kubernetes but never run it myself in production. But I work with a Hashicorp equivalent setup with Docker, Nomad and Consul. I also have several Service Fabric clusters. I think it all is just a complete waste of money. Buying services/metal in the cloud or going serverless or whatever is cheaper and with much lower risks for most minor businesses.
Ah sorry I think you may have misread the claim. K8s is my secret weapon, it’s useful for most teams when you don’t set it up (managed offering).
It really depends on what you do with that cluster, if all you do is run deployments with services and ingress (the equivalent of ECS + ELB), its easier than doing the terraform thing IMO. It’s certainly easier than cloud formation and building AMIs.
I completely agree that buying metal in the cloud is cheaper (that’s part of my secret, shhhh).
I disagree on server less because I think it’s only a matter of time before it becomes a frog boil scenario. Bit of a tin foil hat theory but I think there’s a reason companies want you to move to serverless — the complex flows you build make it sticky, the hidden costs are everywhere, they can simply raise the price at any time, and they scale cost with your business. I think we’ll see more and more of the “I got a thousand hits in a second and my bill was crazy because X” once this deluge of free credits runs out. Also definitely not sure about serverless for small business, it’s such a new paradigm, maybe if you get prebuilt flows but it’s definitely simpler to set up dokku/caprover on a droplet.
Can you point out any tutorials or guides on how to set up kubernetes simply? I'm wondering what the best way to deploy my app with minimal effort is - you make it sound like kubernetes is the answer.
If you're developing apps in containers, there are platforms that make it really simple to deploy. For example, Cloud Run (Google), Fargate (AWS), or Heroku. What the parent comment is suggesting is that building a platform like Cloud Run, Fargate, or Heroku is much easier on Kubernetes. Kelsey Hightower (principal engineer for Google Cloud) put it well when he stated, 'Kubernetes is a platform for building platforms.'¹
You can still deploy apps directly onto Kubernetes and it works very well for this purpose, but it will require a lot more learning than one of the platforms listed above. If you enjoy learning, Kubernetes is an incredibly powerful and satisfying tool to have in your kit, and the initial learning curve isn't as steep as some make it out to be. If your goal is to deploy apps as quickly and simply as possible however, go with one of the pre-existing platforms.
If you still want to learn Kubernetes then a really great book is Kubernetes Up and Running. It goes into just enough detail at the right point in time to make it simple while still being useful. If you do a bit of Googling, you might find a free copy of the book that used to be offered by Microsoft to promote their Azure Kubernetes Service. Otherwise there's Kubernetes the Hard Way² but that's more focused on administering the Kubernetes cluster itself, rather than how to use the cluster to deploy apps. You'd need a pretty convincing reason to administer your own cluster rather than spinning up a managed cluster on GKE or EKS.
My advice:
- Grab a copy of Kubernetes Up and Running
- Install minikube on your local PC
- Experiment and have fun learning
If you want to go from machine to cluster in no time, use the following:
- kubeadm (read the logs)
- k0s
- k3s
If you want to understand everything though, the way I started was:
- read the kubernetes documentation front to back
- go through setting up a cluster the hard way (look up the kubernetes the hard way guide)
- set up ingress on that cluster (nginx ingress), and make sure you understand the interplay between kube-proxy, ingress, services, and your deployment. The actual flow is more like kube-proxy->iptables/lvs->containerd but you want to be able to “think in k8s” (i.e know where to look and have an idea what to check when something goes wrong).
- install cert manager for free https certs
- tear that cluster down, and set a cluster up with kubeadm
(This will be much easier, and you’ll know what it’s doing because the logs are great and you’ve done it before)
- tear that down and make a cluster with k0s/k3s
I want to point out that it really depends on what your goals are. Kubernetes is useful to me because it’s a one stop shop for a wide range of possibilities.
If you just need to get an app up as fast as possible, install caprover/dokku on a DO droplet and git push to deploy.
> The problem is mitigated somewhat by our orchestration system. The control plane for Fly.io is Hashicorp Nomad, about which we will be writing more in the future.
The "point" of Kubernetes is to drop the difficulty of building a service like Cloud Run to zero. It drops the cost of building a Heroku down to zero. I'd bet my bottom dollar that fly.io and render are running on Kubernetes (maybe they mentioned it somewhere already and I just missed it). With the right cluster set up, building one of those platforms (or others that I won't mention) is almost as simple as setting up stripe checkout and writing a web interface to turn form fields into JSON fields and send them to a kubernetes cluster (possibly with hard multi-tenancy! not to get too into it, but you can literally provision kubernetes clusters from kubernetes clusters, ephemeral or otherwise).
No other tool in the devops world except for maybe the initial orchestrator wave (ansible/puppet/salt/chef) has been this much of a force multiplier. Ok, maybe that's hyperbole, but if adhoc-bash-scripts->ansible is 1->2, Ansible->Kubernetes is similarly 1->2, especially if you consider baked in cloud provider support/innovation.
But here's the secret -- perversely, I'm happy deep down that everyone thinks k8s is too complicated/is a buzzword/isn't worth the effort. All it means to me is that I'm still ahead of the curve.