61–70 of 213 posts
Kubernetes isn't supposed to be simple; it's supposed to be a box of tools that you pull from to represent literally any workload. Once you know what tools to ignore, and build scripts around the ones you need, it's very powerful. This line of thinking is like faulting the golang stdlib for having a lot of useful stuff in it.
> available 99.5% of the time with decent alerting for operators to kick it An operator should never have to "kick" a service. It should repair itself, except for the occasional hardware replacement if one is working with bare metal. And for anything that's being sold as a product, as opposed to an internal tool, I think 99.9% availability should be the minimum. But I don't know enough about Kubernetes to say whether…
Have you ever been a sysadmin? There are very few services that don’t need a kick every now and then.
The Cloud Foundry community has started exploring a switch from their own container management system to K8s. If that becomes real, CF would "just" become a nice user interface on top of k8s. The right move imho.
> available 99.5% of the time with decent alerting for operators to kick it An operator should never have to "kick" a service. It should repair itself, except for the occasional hardware replacement if one is working with bare metal. And for anything that's being sold as a product, as opposed to an internal tool, I think 99.9% availability should be the minimum. But I don't know enough about Kubernetes to say whether…
> An operator should never have to "kick" a service. Have you ever been a sysadmin? There are very few services that don’t need a kick every now and then.
Earlier quoted context omitted.
I disagree. Kubernetes came out of Google, but has exploded in popularity due to its capability (which comes with extreme complexity): it can scale to extreme levels, but wrapping your head around it requires far more time and trouble for your most basic apps. Thus, you see the software consultants race to become the next Kubernetes experts, since choosing to deploy it essentially requires that you have dedicated pro…
If you can use docker swarm you can use Kubernetes. At that point k8s is just plain better. The core of Kubernetes is super simple and all the hard parts are hidden away on actually setting up and maintaining kubernetes the hard way on bare metal machines. Odds are, if you're doing that, you have the resources to take some time to dive deeper into how it works. I've done multiple single engineer Kubernetes setups tha…
The ingress story in kubernetes is bring-your-own and usually people run their clusters behind Google or AWS LB which are supported as ingress in k8s. Running k8s on metal is a super daunting task. Choosing your network plugin is another task and usually you have to install a different system service on each of your nodes - Swarm has this built in.
And lastly the Compose file format. 10 lines of Swarm compose file literally translate into multiple dozens of separate k8s yml file. Creating this in k8s is super complex in itself.
Swarm is really pretty nice for someone setting up a few dozen nodes and services.
Earlier quoted context omitted.
> An operator should never have to "kick" a service. Have you ever been a sysadmin? There are very few services that don’t need a kick every now and then.
Yes I have. And if a service ever needs a manual kick, I consider that a bug. At least when running in a public cloud.
Running OpenShift has felt like early Rails to me. You can get started with a hosted version, switch to on AWS easily and dive deep down into Kubernetes whenever you feel ready. It is also opinionated so it’s easy to get started on the golden path and modify it to suit your needs. The only real frustration has been upgrading clusters which has gotten easier each new release.
I’m constantly trying to figure out what it’s hiding from the Kubernetes layer or what it is being manipulated to provide its behaviour.
I personally wouldn’t recommend Openshift->Kubernetes but the other way round would be a better approach once you know you need the additional functionality.
(Edit: fix typo)
Rook sort of does this. You deploy a Rook operator, then just one other kubectl command to get an object store, database, shared filesystem, etc...
https://blog.rook.io/rooks-framework-for-cloud-native-storag...
Coming from someone who gave a talk at Kubecon I'm very surprised to read something like this. Maybe I'm the one with the misunderstanding, but I'm going to try and refute the things this article said/is implying.
1. Kubernetes is complex
This is kind of right, but it's also kind of not -- Kubernetes is essentially complex, given that it encourages write-once solutions to all the problems it faces. Here are the pieces that make a basic Kubernetes "cluster":
- apiserver => you send commands to this to change/query cluster state
- controller-manager => works to make your ensure that the cluster is in the state you want it to be (making workloads replicate/restart/etc)
- scheduler => figures out where to put workloads
- kubelet => runs containers -- one on each node that can do work
- kube-proxy => maintains the routing infrastructure necessary to enable containers on any node to hit a container on another one.
All of those pieces are needed -- the only concession I would make is that they could all be in the same daemon (one executable), but that's actually worse at scale, and harder to debug -- all of these services can produce a lot of logs.
2. Application developers can't use kubernetes as it is
Application developers can use kubernetes as it is. Learning to write a kubernetes resource definition is not any harder than figuring out the conventions and configuration you have to write for Heroku, or AWS ElasticBeanstalk, or AWS ECS. In fact, I would argue that it's simpler.
We've touched on another problem here -- the competitor for kubernetes is not SSH, it's not heroku -- it's tools like CloudFormation/ECS. I don't know if you've CloudFormation, but it's kind of a clusterfuck, hard to set up quite right, and the dynamic yaml approach they've taken is enough rope for one clever developer to hang you and your whole team with.
Bold prediction, but I think AWS is going to abandon CloudFormation and ECS in favor of Kubernetes resources once it stabilizes.
OK, let's say you disagreed with everything I've said up until this point -- at the very least, you can deploy tools like the following to your kubernetes cluster:
https://gitkube.sh => heroku workflow
https://helm.sh => cloud-formation/elastic-beanstalk workflow (with kubernetes primitives)
And presto, you have a completely different interface to your cluster, WITHOUT changing anything fundamental underneath.
3. Developers who only focus on the application-level are the goal
Why would you even want this? Not only is it basically impossible to hide the underlying infrastructure so well that the application developer doesn't have to know about it, it's arguably not even a good idea.
Take session management -- if you want to handle it in the context of more than one frontend running at a time, you generally outsource that state to a cache like redis. An application developer who grew up in this imaginary world where app developers never touch infrastructure is not who I want solving this issue, assuming there isn't a qualified ops person. If you needed to optimize even further, app-local caches could be deployed, but this requires knowledge of "sticky sessions" -- this very much is a deployment/infrastructure specific question, again, that app-only developer is just about useless here.
I'm no hiring manager but the desire to stay an "application" developer who only worries about that part of the stack when the "application" as a whole is so much more would be a red flag for me. Even if you were delivering a desktop application, the developer who worries about underlying OS-specific enhancements (for example knowing how to optimize the app for MacOS) is the one I want, the one I want to pay the big bucks for.
4. It's hard to deploy the usual app+backing store+caching+worker pool structure
The author touches on this a little bit with the "maybe operators and helm charts solve this", and that's exactly what the operator pattern (Custom Resource Definitions, AKA CRDs, plus custom controllers) were meant to solve -- now you can actually give declarative specifications of what you want your Redis/Postgres/Celery/whatever cluster to look like, and `kubectl apply`, and the platform handles it. There's arguably no difference here between how you'd use this and a tool like heroku.
Also, for the record you can trivially extend `kubectl`: https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plug...
Microsoft Word is also incredibly complex software with decades of development and features, and yet it's just a word processor. Everyone uses a small subset of the actual functionality which is why the entire system can be complex and simple at the same time, depending on your needs. It's exactly the same with Kubernetes. It's just clustering software that ties multiple servers together to give you an PaaS-like work…
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.