6 ms·

So, trying to get a clear handle on just what Kubernetes is - its basically supervisord but for containers, across a pool of servers? With the addition of: - A

So, trying to get a clear handle on just what Kubernetes is - its basically supervisord but for containers, across a pool of servers? With the addition of: - 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?

drdaeman 9y ago
Basically, yes. It's a scheduler, a networking layer (cross-communication across nodes if pods that need to talk to each other are scheduled on different nodes), and some storage management (so you define a volume and tell MySQL to persist there etc etc). And an optional LB/router for ingress traffic to the pods. That, and a loads of very verbose YAML to describe things.
dominotw 9y ago
>A complete application e.g. wordpress + mysql containers, can be represented as pods 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.
- jalfresi 9y ago
  Right, so in the WordPress example you would have: - 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...
  - liotier 9y ago
    > 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.
    - jalfresi 9y ago
      Absolutely! I can definitely see the payoff there. It just seems that everyone is packaging projects as Docker now and its a bit confusing that orchestration seems to be a bit of an afterthought in the docker world, when I'm sure most applications will require a database. Still, I'll keep on plugging away at kubernetes; I actually quite like the design of the system, very tidy!
  - teraflop 9y ago
    > this seems like SO MUCH MORE WORK than just running them traditionally 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.
    - jalfresi 9y ago
      Another great explanation - so its kinda-like a package manager for complete systems (like my above WordPress example). Neat! Think I'm getting the appeal now
      - raesene9 9y ago
        TBH the package manager for applications thing that was described is just Docker, you don't need Kubernetes for that. Kubernetes makes more sense if you're running big clusters of systems.
  - nickik 9y ago
    Take a look at the Helm Package Manager. Once you have Kubernetes running you can very easily install MySQL (even more complex high availability clusters). If you can put your application in a docker you are almost there. 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.
gtirloni 9y ago
More information: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ https://kubernetes.io/docs/concepts/overview/what-is-kuberne...
ownagefool 9y ago
Yeah, pretty much. 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.
bkeroack 9y ago
More generally, Kubernetes is an abstraction layer between your application and hardware/cloud that allows you to declaratively define what your app is, how it runs, where it runs and what dependencies it needs. All in a standardized format that allows versioning and easy modification. 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."
- jalfresi 9y ago
  Thats a pretty good explanation! Thanks!
- rhizome 9y ago
  "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... 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. :)
  - StevePerkins 9y ago
    > since when does development tell ops [deployment details]? 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.

drdaeman 9y ago

Basically, yes. It's a scheduler, a networking layer (cross-communication across nodes if pods that need to talk to each other are scheduled on different nodes), and some storage management (so you define a volume and tell MySQL to persist there etc etc). And an optional LB/router for ingress traffic to the pods. That, and a loads of very verbose YAML to describe things.

dominotw 9y ago

>A complete application e.g. wordpress + mysql containers, can be represented as pods 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.

jalfresi 9y ago
Right, so in the WordPress example you would have: - 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...
- liotier 9y ago
  > 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.
  - jalfresi 9y ago
    Absolutely! I can definitely see the payoff there. It just seems that everyone is packaging projects as Docker now and its a bit confusing that orchestration seems to be a bit of an afterthought in the docker world, when I'm sure most applications will require a database. Still, I'll keep on plugging away at kubernetes; I actually quite like the design of the system, very tidy!
- teraflop 9y ago
  > this seems like SO MUCH MORE WORK than just running them traditionally 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.
  - jalfresi 9y ago
    Another great explanation - so its kinda-like a package manager for complete systems (like my above WordPress example). Neat! Think I'm getting the appeal now
    - raesene9 9y ago
      TBH the package manager for applications thing that was described is just Docker, you don't need Kubernetes for that. Kubernetes makes more sense if you're running big clusters of systems.
- nickik 9y ago
  Take a look at the Helm Package Manager. Once you have Kubernetes running you can very easily install MySQL (even more complex high availability clusters). If you can put your application in a docker you are almost there. 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.

gtirloni 9y ago

More information: https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/ https://kubernetes.io/docs/concepts/overview/what-is-kuberne...

ownagefool 9y ago

Yeah, pretty much. 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.

bkeroack 9y ago

More generally, Kubernetes is an abstraction layer between your application and hardware/cloud that allows you to declaratively define what your app is, how it runs, where it runs and what dependencies it needs. All in a standardized format that allows versioning and easy modification. 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."

jalfresi 9y ago
Thats a pretty good explanation! Thanks!
rhizome 9y ago
"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... 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. :)
- StevePerkins 9y ago
  > since when does development tell ops [deployment details]? 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.