Yes you can write a dissertation with a ton of support from Word to make you life easier, but doing simple things is simple.
It sounds like that’s what missing from kubectl. Even for a small start it takes a lot of knowledge.
To continue the Word analogy, that sounds like LaTeX. It’s very powerful, but no normal person is going to get started for the first time very fast for basic tasks. Certainly not compared to Word.
The Rails analogy from the article seems very apt.
kubectl run appname --image=yourimage
kubectl apply -f yourfile.yaml
Or just remain a bit more strict and look at typewriters. Word is a typewriter. People look at typewriters and sort of understand them after pushing one-two buttons. Yes, there are hidden gems and details and a long road from mechanical typewriters to Word and laser printers (e.g. https://www.youtube.com/watch?v=bRCNenhcvpw ), but people are a lot more intuitive about these pieces of hardware and software, because they are simply updates on existing tech.
Distributed systems is a new, and hitherto an explicitly unknown concept for many people.
And with minikube you can set up k8s as easily as MS Office. (Or you can use Typhoon https://typhoon.psdn.io .. )
And it's trivial to package up all this into a website, like Office 365 and GKE https://cloud.google.com/kubernetes-engine/ .
Or you can run it on your own PC with minikube and Virtualbox/KVM/qemu, and similarly you can install Office locally. But it does not make sense for one and it increasingly makes less for the other too.
Kubernetes is not going to be simpler or easier than the software that it's designed to run on top of itself, but it's not that hard anymore either. The installers work well, there are several distros with varying capabilities, or you can just use the public clouds like most where it's 1 button.
E.g. over years of using Etcd. I've come to the conclusion that none of the uses I've actually used it for were necessary, and so I've generally stopped using it. I'll use it again if I come across instances where consistency is sufficiently critical and the system needs to be distributed, but that's a rare situation to be in. E.g. I've seen lots of systems try to use it to distribute configuration data. Most of the time this doesn't need to be consistent, as long as you can determine whether or not it is (and so take outdated instances out of rotation, or not put them back in rotation). Same for load balancer configs, for example.
It's gone to the point where whenever someone mentions "distributed database" alarm bells goes off in my head. 9 out of 10 times it's a sign of someone over-engineering a system and building in unnecessary complexity.
What I want out of a system to manage my containers is something that reduces complexity of deployment and operation, not something that introduces more complexity. So far I've seen nothing of Kubernetes that indicates it fits that bill. Maybe it does on the very high end. My largest systems have "only" been in the few hundred containers/VM range over dozens of servers in 4-5 physical locations (on premises/co-location, managed and public cloud). For that scale, I've personally found Kubernetes overkill and adding too much complexity.
Maybe that'll change some day as it matures, but I'm not in a rush to complicate my stacks.
My main point in all of this is that concepts must be understood to run large distributed applications. If you don't have such an app, nothing applies. If you do, then you have a choice of tools to use, and one of them is Kubernetes which offers a great foundation and set of features. There are other tools like Nomad, Chef or your own code and scripts - it doesn't matter what you use as long as you understand what you're doing.
You have 1000 machines. Each runs 1000 containers with an average runtime of 1 hour per container.
Design a scheduler that runs on a single machine with a cold spare. For failover, assume you have access to a reliable RDBMS or relible NFS server.
Plugging in numbers for my $1000 synology, which runs a half dozen dockers, a vm, and is off-site backed up (for $120/yr), it tells me that I’ll pay $135/month to run comparable kubernetes at google.
Even if you pretend my $75/month broadband connection is only used by the synology, and include power costs, the synology still wins by $10’s/month.
(I included 3TB of storage for kubernetes, and 6TB usable for synology, with 3TB used, and sized for the high-memory 4 core machine, since dram is the synology bottleneck, even with a low wattage cpu. The synology is intentionally over-sized and is basically idle, so “but scalability!” isn’t a valid complaint.)
Also, the 9’s I’ve observed were trouncing amazon for a while, though they may be catching up, thanks to comcast...
But if you want to roll your own, then you can, it's FOSS after all. kubeadm works very well.
Comparing Synology with anything Google is silly, but useful. You can rent dedicated machines easily. Leaseweb is nice. And then you can build your infrastructure for cheaper.
Yes, different things are different levels of complexity, and using a managed service means paying someone else to handle it.
K8s is also not that complicated after you grok it. It's also pretty easy to get started for simple cases. It's just that you need to switch your mindset a bit; but the benefits from the mental switch are non-negligble.
Writing (or code-generating) a bunch of YAML configs is the easiest part about K8s. Diagnosing why in the world it misbehaves in some weird manner is where the real complexity is.
Of course, this does not apply when you're not a system administrator, but just an user of someone's else (Google) K8s.
With GitLab you can deploy to k8s directly. Like Word and let's say SharePoint.
Also, there are a lot of folks doing this commoditization and packaging up k8s in various ways to make it more usable for a wider audience.
You're comparing k8s to Word instead of Windows kernel. Or maybe instead of .NET.
I'm a single-person ops team for my startup. Granted, I MAY be an exceptional learner and not realize it, but I mostly consider myself an under-achieving stoner.
I chose Kubernetes as our platform a few years ago and it's been absolutely wonderful and only getting better. Every once in a while I do a thought experiment with my co-workers to ensure Kubernetes is still the product for us. It is. We all love it and it makes my job easier. And it's really not that complicated.
Let's go ahead and list a few things Kubernetes Provides at the cost of writing a few YAML files and provisioning some docker containers in our CI/CD stack:
- Service discovery and health checks
- Zero downtime upgrades with rollouts and rollbacks
- Horizontal auto-scaling ( VM AND container )
- Configuration management and secret storage
- Immutable infrastructure
- Automatic SSL provisioning and routing via kube-lego and GCE ingress controller
- Log aggregation and monitoring via Heapster
- Cloud-provider agnostic configurations
- A consistent and approachable API to implement required features onto.
- ( With Google GKE ) Automatic security updates with a set maintenance window.
- Easy deployments with Kubernetes Keel
There are more benefits but these are the ones that come off of the top of my head.
ALSO, it's an opinionated framework that makes doing things "The Right Way" easy and intuitive to do.
In my TINY organization's reckoning, K8 actually makes our lives EASIER rather than more complicated and is considered one of the best decisions we ever made. It gets out of our way and lets us work on the fun stuff.
> In the case of applications that simply don’t have the scale problem, they usually don’t need the added complexity of a self-healing, horizontally scalable system.
If you build on a swamp your castle is going to sink into the swamp. Don't obsess over scale, but plan to scale, even if it's just "We can throw more servers at it."
Self-healing? The author is correct: Probably not necessary.
But scaling goes both ways: Our start-up is counting pennies and saving money wherever we can. Having an auto-scaling pod and node cluster makes so much sense. Our cluster automatically scales up and down based on load, saving us thousands of dollars a month.
> The problem I see with Kubernetes is that the cognitive load in the early parts of a project are simply too high. The number of things you need to create and worry about are a barrier to starting a project and iterating on it quickly. In the early days of a project, feature velocity and iteration speed are the most important factors. I view the Heroku model as the ideal development model. You have a managed hosted Postgres database and you just git push to get new code deployed and out the door. There’s very little to think about. It may not scale to infinity and it may get expensive, but you can worry about those things once you’ve actually got a hit on your hands.
I disagree with the assertion that starting out is difficult ( Or, that it is more difficult than other solutions ), and heroku is EXPENSIVE. With GKE, you are paying for the VMs and little more and get a BUCKET-LOAD more features.
What is this nebulous "complicated part" of setting up kubernetes? You literally hit a button and it creates your cluster.
You can have an application ready to go with three objects: a service, an ingress, and a deployment. I find Heroku to be of a similar complexity with less flexibility.
I get EXCELLENT monitoring and log aggregation by running `helm install datadog` and providing my key. I get a good-enough rabbitmq cluster by calling `helm install rabbitmq`. I get automatically provisioned SSL by calling `helm install kube-lego.`
So I suppose my response would be: No, I don't think it will. I think the complexity is over stated.
This is because you don't manage K8s and don't deal with this complexity. Google does.
Now, imagine a case where suddenly one pod can't ping another, but packets flow okay in reverse direction. The cost suddenly goes up from "writing a few YAML files" to "debugging CNI".
> What is this nebulous "complicated part" of setting up kubernetes? You literally hit a button and it creates your cluster.
That is, if you want to depend on other companies to provide your infrastructure. Which is perfectly reasonable business decision, but the opposite (self-managed bare-metal colocated servers) is also perfectly reasonable.
It's exactly the same with Kubernetes. It's just clustering software that ties multiple servers together to give you an PaaS-like workspace to run containers, but there are 1000s of details you can use if you need them to build much more intelligence into operations. If you don't need them, you can just run a single container and still benefit from simple declarative deployments and automated oversight.