4 ms·

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

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.
        orf 5y ago
        A pod is a collection of containers. The original suggestion was to pair them, so you’d have a backend container and a frontend container living within the same pod. This is wasteful for the reasons I listed. You can shove the backend and the frontend into the same container, but it’s needless. > 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. They are still two different concerns and don’t need to both be served from the same pod (the BFF pattern doesn’t even remotely require this). You of course can do whatever you want, but shoving different things together (even if coupled via an API) is an anti pattern.
- coopreme 5y ago
  Well there are use cases where this is appropriate, the common multi-pod design patterns -> https://matthewpalmer.net/kubernetes-app-developer/articles/multi-container-pod-design-patterns.html https://matthewpalmer.net/kubernetes-app-developer/articles/... Generally I don’t see them and where they might be useful, I end up using a K8S Cronjob instead. But why? I want each pod to have its own liveness probe and be able to scale independently.

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.
      - orf 5y ago
        A pod is a collection of containers. The original suggestion was to pair them, so you’d have a backend container and a frontend container living within the same pod. This is wasteful for the reasons I listed. You can shove the backend and the frontend into the same container, but it’s needless. > 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. They are still two different concerns and don’t need to both be served from the same pod (the BFF pattern doesn’t even remotely require this). You of course can do whatever you want, but shoving different things together (even if coupled via an API) is an anti pattern.
coopreme 5y ago
Well there are use cases where this is appropriate, the common multi-pod design patterns -> https://matthewpalmer.net/kubernetes-app-developer/articles/multi-container-pod-design-patterns.html https://matthewpalmer.net/kubernetes-app-developer/articles/... Generally I don’t see them and where they might be useful, I end up using a K8S Cronjob instead. But why? I want each pod to have its own liveness probe and be able to scale independently.