4 ms·

> Not a single example that a newbie can understand. K8S (imo) isn’t for noobs. A car factory isn’t for noobs. Ideally you would want to understand how a car i

> Not a single example that a newbie can understand. K8S (imo) isn’t for noobs. A car factory isn’t for noobs. Ideally you would want to understand how a car is made and works, how to run an assembly line, and how to build a factory communication systems before building and running the car factory. Similarly, you should understand how docker containers works, how to run infrastructure, and how to configure system networks and dns before building and running a K8S platform. The analogy may not be perfect… K8S is complicated but not impossibly so. Practice, working with something like Rancher, and classes will go along way to help understand it.

Hackbraten 5y ago
Let’s say my app has two containers: container A serves a static page for my SPA, and container B is a back-end that exposes an API for A. So which set of containers would be a pod here? And which would be the nodes? And what would be the cluster? (For the sake of the example, let’s assume that both A and B scale independently.)
- coopreme 5y ago
  That would be two pods. Each pod would have one container. The nodes would be the underlying Infrastructure at the containers are running on, so you would have n number of worker nodes which are each a full system running either on premises, or in a cloud. K8S Will schedule those pods to run on those nodes… same as how docker containers run on your host system in development. The cluster is the K8S body representing the control plane nodes ( your mgmt computers running etcd and K8S backend ) and the worker nodes (where your pods, demons, statefull sets, containers, etc etc etc are running ). Now if you configure it right, those two pods are two deployments. You can scale those up and have a load balancer sitting in front of them. That load balancer will expose app and send in traffic to the stateless containers in the cluster.
  - yawaramin 5y ago
    Why not one pod with two containers?
    - HillRat 5y ago
      You probably need to scale the two features — SPA serving and APIs — independently, so you’d deploy them in separate pods. Multi-pod containers should be so tightly coupled that they should always deploy together. If you can insert decoupling between containers, do it.
      - yawaramin 5y ago
        But it doesn't really make sense for them to scale independently, right? E.g., you would never want the FE to scale higher than the BE, because that would 'starve' the FE. And you wouldn't really want the BE to scale higher than the FE, because why waste the resources? If they scale together, that solves both problems.
        orf 5y ago
        Not at all. They both have different scaling characteristics - serving a static file (assuming you didn’t do it via a CDN for some reason) uses a lot less resources than serving a backend request. If it doesn’t, you’re doing something terribly wrong. If you couple them like you’re suggesting then you’re wasting resources by scaling out your FE serving infrastructure needlessly. And at some point you’ll possibly end up splitting your backend into multiple services. Would you couple a frontend container to each of those?
        yawaramin 5y ago
        > If you couple them like you’re suggesting then you’re wasting resources by scaling out your FE serving infrastructure needlessly. But if I'm coupling them in the same pod then am I really wasting resources? Aren't pods the equivalent of 'hosts' in the Kubernetes world, i.e. aren't resources allocated at the pod level? And as you said, > serving a static file (assuming you didn’t do it via a CDN for some reason) uses a lot less resources than serving a backend request. If I'm serving static files from the same pod as my backend, the pod shouldn't really need any more resources than if it was just serving the BE, right? > And at some point you’ll possibly end up splitting your backend into multiple services. Would you couple a frontend container to each of those? The most likely scenario in that case would be having a backend-for-frontend pattern, so the FE and its BFF would still go in the same pod, and the other services would probably go in different pods.
StreamBright 5y ago
Yeah not for noobs is another way of saying that the creator of that particular thing did not do a good job.
papito 5y ago
I've been in this business since the early 2000s when we did not have these toys and had to roll everything on our own. I myself had to set up a high availability cluster using, eh, I forget what it was called now, something like LVH, and "containers" using Linux jails. K8S is absolutely not a sustainable thing with its learning curve, and it is destined to be abstracted by a "dumb" layer, sort of like Git has two APIs - for developers and for the users. In fact, I believe that is already happening. Few companies can afford a team of devs doing care and feeding for this thing full time.

Hackbraten 5y ago

Let’s say my app has two containers: container A serves a static page for my SPA, and container B is a back-end that exposes an API for A. So which set of containers would be a pod here? And which would be the nodes? And what would be the cluster? (For the sake of the example, let’s assume that both A and B scale independently.)

coopreme 5y ago
That would be two pods. Each pod would have one container. The nodes would be the underlying Infrastructure at the containers are running on, so you would have n number of worker nodes which are each a full system running either on premises, or in a cloud. K8S Will schedule those pods to run on those nodes… same as how docker containers run on your host system in development. The cluster is the K8S body representing the control plane nodes ( your mgmt computers running etcd and K8S backend ) and the worker nodes (where your pods, demons, statefull sets, containers, etc etc etc are running ). Now if you configure it right, those two pods are two deployments. You can scale those up and have a load balancer sitting in front of them. That load balancer will expose app and send in traffic to the stateless containers in the cluster.
- yawaramin 5y ago
  Why not one pod with two containers?
  - HillRat 5y ago
    You probably need to scale the two features — SPA serving and APIs — independently, so you’d deploy them in separate pods. Multi-pod containers should be so tightly coupled that they should always deploy together. If you can insert decoupling between containers, do it.
    - yawaramin 5y ago
      But it doesn't really make sense for them to scale independently, right? E.g., you would never want the FE to scale higher than the BE, because that would 'starve' the FE. And you wouldn't really want the BE to scale higher than the FE, because why waste the resources? If they scale together, that solves both problems.
      - orf 5y ago
        Not at all. They both have different scaling characteristics - serving a static file (assuming you didn’t do it via a CDN for some reason) uses a lot less resources than serving a backend request. If it doesn’t, you’re doing something terribly wrong. If you couple them like you’re suggesting then you’re wasting resources by scaling out your FE serving infrastructure needlessly. And at some point you’ll possibly end up splitting your backend into multiple services. Would you couple a frontend container to each of those?
        yawaramin 5y ago
        > If you couple them like you’re suggesting then you’re wasting resources by scaling out your FE serving infrastructure needlessly. But if I'm coupling them in the same pod then am I really wasting resources? Aren't pods the equivalent of 'hosts' in the Kubernetes world, i.e. aren't resources allocated at the pod level? And as you said, > serving a static file (assuming you didn’t do it via a CDN for some reason) uses a lot less resources than serving a backend request. If I'm serving static files from the same pod as my backend, the pod shouldn't really need any more resources than if it was just serving the BE, right? > And at some point you’ll possibly end up splitting your backend into multiple services. Would you couple a frontend container to each of those? The most likely scenario in that case would be having a backend-for-frontend pattern, so the FE and its BFF would still go in the same pod, and the other services would probably go in different pods.

StreamBright 5y ago

Yeah not for noobs is another way of saying that the creator of that particular thing did not do a good job.

papito 5y ago

I've been in this business since the early 2000s when we did not have these toys and had to roll everything on our own. I myself had to set up a high availability cluster using, eh, I forget what it was called now, something like LVH, and "containers" using Linux jails. K8S is absolutely not a sustainable thing with its learning curve, and it is destined to be abstracted by a "dumb" layer, sort of like Git has two APIs - for developers and for the users. In fact, I believe that is already happening. Few companies can afford a team of devs doing care and feeding for this thing full time.