Container orchestration top trumps: Let's just pretend you don't use Kubernetes already Container orchestration comes in different flavours, but actual effort must be put into identifying the system most palatable. Yes, features matter, but so too does the long-term viability of the platform. There's been plenty of great technologies in the history of the industry, but what's mattered has been their viability, as …
I’m new to Docker - and it seems like a very useful tool. I’m using docker-compose which is suitably lightweight, and allows me to easily move from one host to another. Given all that, and that I’m running less than 10 containers, what benefit does Kubernetes (or one of the other solutions given here) offer?
That’s a serious question by the way - I’d really like to know whether this is something that I need to pay attention to!
It does a whole load of stuff, but at its simplest it lets you think in terms of a cluster, rather than individual machines. So you basically end up with X amount of resources, and you just ask it to run your workloads, without having to figure out where to put them. Here's a few things you get with Kubernetes to give you an idea:
* If you have something like a web server that you want to be able to horizontally scale depending on load, you can create a service that automatically creates a load balancer for you, and figures out what containers to send requests to. It can add and remove containers to the pool depending on overall load.
* Linked to the previous point, it has built-in support for liveness (is my container running properly) and readiness (is it ready to serve requests / do its work) checks, so it can avoid routing traffic to containers until they've started up properly.
* You can Ingresses to do SSL termination at the edge of the cluster so the containers don't need to worry about it.
* It can handle automatically connecting storage to your containers via volumes (so you don't need to make sure that the container is running on a particular node, for example), and can automatically provision that storage using Persistent Volume Claims.
I'm sure that's only just scratching the surface as well.
As Adam said, k8s is about managing collections of containers of the same type, and groups of collections of different types. Once you have collections of containers, and tools for routing between them, you can start doing very cool things:
* canary deploys. Create a new release, create some updated nodes, and put some users traffic through them, whilst 99% of users continue to use the old app
* blue/green deploys: for when you need to switch everyone all at once, roll out your new nodes and then switch traffic to go to them, switch back if it goes wrong.
* auto load balancers - no more editing haproxy configs when you add nodes
* integrated monitoring
"Just beware Amazon, Azure and Google – these are Hotel California"
Sorry if this comes across as being picky, but I feel like this is a bit misleading. Azure currently offers both ACS and AKS (in public preview). ACS is a way of deploying a cluster using your orchestrator of choice (Mesos, Kubernetes, etc), whereas AKS is a slightly more managed version that only supports Kubernetes. Either way, you're not locked in - you're running your own Kubernetes cluster that just happens to be in Azure. So if you want to move to another cloud provider or bare metal it's a case of setting up your new cluster and deploying to it.
Obviously this may not be quite as simple as I make out if you use other Azure services (database servers, storage, load balancers, etc), but you're no more locked in than if you were just using Azure to host virtual machines IMO.
I believe AWS and Google also both have similar offerings, although AFAIK the AWS one is in a private preview rather than being publicly available.
So yes, you can be locked in with the public cloud providers, but they're all currently building / have available services that allow you to create a managed Kubernetes cluster, rather than using their own proprietary container services.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
