- A complete application e.g. wordpress + mysql containers, can be represented as pods
- Pods can be "scheduled" e.g. auto-scaled, across "nodes" e.g. servers, with load balancing etc
Is that right?
As opposed to the old-school method of having to describe all that in words to an ops team (or not and just expecting them to figure it out): "This is a Java app. It needs JDK 1.6 and at least 1GB of RAM. It expects to write logs at /var/log/foo.log. It needs a MySQL database and Redis and Elasticsearch at configured hostnames and ports. We need to run at least 6 instances horizontally scaled behind a load balancer."
Wow, brittle. Can't Java use environment variables? And since when does development tell ops what hostnames a machine should have, not to mention how many instances to run?
Sorry, don't mean to jump all over you, but your words apparently jumped all over me. :)
Not to be cheeky, but since "devops"!
Docker, Kuburnetes, etc... all of these things live on the point of intersection between developers and operations. Some of the config artifacts (e.g. dockerfiles) typically live in source control, which is usually the domain of developers. But the values with which they're populated are typically set by operations.
It is indeed a dance that the two groups have to work out among themselves, and different organizations will handle it differently. Ultimately, I think you find that it really isn't FUNDAMENTALLY different from the dance that they already do in the old school. There will always have to be a handshake, where dynamic values are stored someplace and code knows to point to that place. How you handle that handshake is ultimately a human process thing.
The point is it all comes as part of the framework though, so hopefully building for kubernetes will be consistent.
Also, whilst you could put wordpress in a pod (php, mysql) it's probably more typical to put nginx + php-fpm inside containers next to each other (a pod) rather than mysql. You'd probably run mysql as another service, at least that's how I typically do it.
That, and a loads of very verbose YAML to describe things.
Thats probably not a good idea since
1. A pod runs on a single machine .
2. A pod is a basic scaling unit, you probably don't want scale both Wordpress and MySQL together.
> its basically supervisord but for containers, across a pool of servers?
Thats just ReplicationController part of kubernetes.
- a WebApp pod for the WordPress, which can be scheduled/load balanced across several nodes
- a MySQL Mast pod, and possibly MySQL Slave pods which would be scheduled/load balanced
I REALLY want to get into all this but this seems like SO MUCH MORE WORK than just running them traditionally...
It is... Unless you have hundreds of servers - and then it pays off handsomely.
Still, I'll keep on plugging away at kubernetes; I actually quite like the design of the system, very tidy!
Here's an analogy: let's say you've written a command line tool and you want to install it. The simple answer is to just copy the binary to /usr/bin. Does it need config files? Library dependencies? That's fine, copy them to the appropriate directories. But then you, as the sysadmin, have the responsibility of remembering exactly what the state of the system is. If you need to make changes later on, you need to spend time figuring out exactly what needs to be updated, and then manually apply those changes without making mistakes.
The cleaner solution is to use a package manager like rpm or apt-get. You have to spend some time up front to package your code, including explicitly defining things like package dependencies and clean-up scripts. But once that's done, you can let the package manager do the work of figuring out how to get the system into the desired overall state. You're doing more work in the short term, but it pays dividends in terms of maintainability.
Neat! Think I'm getting the appeal now
Kubernetes makes more sense if you're running big clusters of systems.
If you don't manage Kubernetes yourself this is actually not that much more work. It is sort of a shift in thinking, and you have to retrain, but once you do that it should actually be faster.
I am doing this right now and the paradigm shift is just really big, that's why it seems to take so much longer.