6 ms·

This is a strange comparison. Pods are a group of containers, just like you can do with docker compose. I am not sure why one would present this as one versus t

This is a strange comparison. Pods are a group of containers, just like you can do with docker compose. I am not sure why one would present this as one versus the other.

morelisp 5y ago
Moving from various Docker products to Kubernetes, the initial role of pods was not clear to me at all. Kubernetes has a lot of grouping mechanisms. Containers are grouped into pods, which are grouped into various workloads (deployments, statefulsets, cronjobs), which are grouped into namespaces. If you're using e.g. Rancher, namespaces are further grouped into projects. If I'm writing a docker compose file, maybe I write something with a DB container, and 3x backend containers, and 2x frontend containers. If I'm using Docker Swarm, then that's probably what I deploy as a "stack." But there's no immediate analogue of this in Kubernetes. Are my DB, backend, and frontend containers grouped in the same pod? ("Just like you can do with docker compose" as you say.) No, absolutely not! Otherwise I'm scaling up DBs when I scale up my frontend/backend. The DB is only finally grouped with them at the namespace level. OK, so split off the DB. Do I also split the frontend/backend? Well, maybe not. Both for performance reasons that don't exist in compose/swarm and for practicality of scaling, maybe I tie those together so there's always 1:1 frontend:backend, even if I'm wasting some resources. Or maybe I don't, and put all three as separate workloads in a namespace so I can scale each appropriately. But is a namespace like a Docker Swarm stack? Oh dear no, it's also the basis for access control (sometimes) and resource discovery (sometimes) and for service discovery (almost always, at least). How many namespaces do I need? Where should I split stuff? Are namespaces for isolating different environments (staging, prod, feature branches)? For isolating business units? For isolating all the way down to the workload level, with only one deployment + configmap + serviceaccount + etc? To this day I don't know, even talking to the same ops folks I see their opinions change over time, and not consistently in the same direction. So in the end there's nothing in Kubernetes that really looks like a Docker compose file / Docker swarm "stack", and that kind of sucks because that's really the "project" or "application" level a lot of developers outside microservice hellworld or FAANG hyperspecialization work with on a day-to-day basis. And there doesn't seem to be a congealing best practice over how to structure full applications in spite of this. So for anyone who just wants to orchestrate a couple dozen containers for a 10 person team, you're really just throwing YAML in a despair hole and hoping the next tool you want doesn't have a different opinion than the five you already have.
- linkdd 5y ago
  Kubernetes is a framework. You split/group things according to your needs. In a large organization, you might see: - a cluster per environment (staging, dev, prod, ...) - a namespace per team (or business unit) - some more namespaces for operators like cert-manager, tekton, ... - an Helm chart for each application deployed in the team's namespace If you're building a SaaS product, you might see: - a namespace per client - an helm chart for your product deployed in each namespace But basically, you'll often have the following: - one "service" per container (frontend, backend, db, ...) - one container per pod + sidecar containers like kube-proxy, or vault (to refresh secrets as they change) - a deployment/statefulset/daemonset to scale the pods - a service resource to access the pods (DNS resolution) - maybe an Ingres resource to expose your services to outside trafic Your Helm chart (or any other packaging solution) may group multiple Deployments/StatefulSets/DaemonSets and Services into a single package, describing your application. Then you deploy however you want this package. Personally, I use namespaces to split things by features: - one namespace for monitoring (kubirds, prometheus, ...) - one namespace for secrets (cert-manager, kubevault, ...) - one namespace for databases (kubedb, ...) - one namespace for cicd (tekton, kapp-controller, ...) - etc... Then one namespace per "project" (a set of applications and resources provided by the operators running in the "feature" namespaces). TL;DR: There is no "one true solution/pattern", only what fits your needs.
  - moondev 5y ago
    K8s actually doesn't support deploying a single container, only a pod which can have 1 or more containers. This is very powerful and enables all kinds of other patterns like sidecars and init containers
    - linkdd 5y ago
      Could you cheat by mounting the node's docker socket in a privileged pod and execute `docker run` from that pod? But yeah, when I said "one service per container" I was thinking about the step before deploying to K8s. It's because I've seen a few years ago some python projects completely encapsulated in a Docker container, with an init system like supervisord (running a redis, a django app, and celery workers).
t-writescode 5y ago
Aren't pods groups of containers _that also share resources like hdd space_? so they're not quite the same as containers?
- miked85 5y ago
  Right, they are deployed as a group to share resources, otherwise they could just be deployed standalone. They are just containers though.

This is a strange comparison. Pods are a group of containers, just like you can do with docker compose. I am not sure why one would present this as one versus the other.

morelisp 5y ago

Moving from various Docker products to Kubernetes, the initial role of pods was not clear to me at all. Kubernetes has a lot of grouping mechanisms. Containers are grouped into pods, which are grouped into various workloads (deployments, statefulsets, cronjobs), which are grouped into namespaces. If you're using e.g. Rancher, namespaces are further grouped into projects. If I'm writing a docker compose file, maybe I write something with a DB container, and 3x backend containers, and 2x frontend containers. If I'm using Docker Swarm, then that's probably what I deploy as a "stack." But there's no immediate analogue of this in Kubernetes. Are my DB, backend, and frontend containers grouped in the same pod? ("Just like you can do with docker compose" as you say.) No, absolutely not! Otherwise I'm scaling up DBs when I scale up my frontend/backend. The DB is only finally grouped with them at the namespace level. OK, so split off the DB. Do I also split the frontend/backend? Well, maybe not. Both for performance reasons that don't exist in compose/swarm and for practicality of scaling, maybe I tie those together so there's always 1:1 frontend:backend, even if I'm wasting some resources. Or maybe I don't, and put all three as separate workloads in a namespace so I can scale each appropriately. But is a namespace like a Docker Swarm stack? Oh dear no, it's also the basis for access control (sometimes) and resource discovery (sometimes) and for service discovery (almost always, at least). How many namespaces do I need? Where should I split stuff? Are namespaces for isolating different environments (staging, prod, feature branches)? For isolating business units? For isolating all the way down to the workload level, with only one deployment + configmap + serviceaccount + etc? To this day I don't know, even talking to the same ops folks I see their opinions change over time, and not consistently in the same direction. So in the end there's nothing in Kubernetes that really looks like a Docker compose file / Docker swarm "stack", and that kind of sucks because that's really the "project" or "application" level a lot of developers outside microservice hellworld or FAANG hyperspecialization work with on a day-to-day basis. And there doesn't seem to be a congealing best practice over how to structure full applications in spite of this. So for anyone who just wants to orchestrate a couple dozen containers for a 10 person team, you're really just throwing YAML in a despair hole and hoping the next tool you want doesn't have a different opinion than the five you already have.

linkdd 5y ago
Kubernetes is a framework. You split/group things according to your needs. In a large organization, you might see: - a cluster per environment (staging, dev, prod, ...) - a namespace per team (or business unit) - some more namespaces for operators like cert-manager, tekton, ... - an Helm chart for each application deployed in the team's namespace If you're building a SaaS product, you might see: - a namespace per client - an helm chart for your product deployed in each namespace But basically, you'll often have the following: - one "service" per container (frontend, backend, db, ...) - one container per pod + sidecar containers like kube-proxy, or vault (to refresh secrets as they change) - a deployment/statefulset/daemonset to scale the pods - a service resource to access the pods (DNS resolution) - maybe an Ingres resource to expose your services to outside trafic Your Helm chart (or any other packaging solution) may group multiple Deployments/StatefulSets/DaemonSets and Services into a single package, describing your application. Then you deploy however you want this package. Personally, I use namespaces to split things by features: - one namespace for monitoring (kubirds, prometheus, ...) - one namespace for secrets (cert-manager, kubevault, ...) - one namespace for databases (kubedb, ...) - one namespace for cicd (tekton, kapp-controller, ...) - etc... Then one namespace per "project" (a set of applications and resources provided by the operators running in the "feature" namespaces). TL;DR: There is no "one true solution/pattern", only what fits your needs.
- moondev 5y ago
  K8s actually doesn't support deploying a single container, only a pod which can have 1 or more containers. This is very powerful and enables all kinds of other patterns like sidecars and init containers
  - linkdd 5y ago
    Could you cheat by mounting the node's docker socket in a privileged pod and execute `docker run` from that pod? But yeah, when I said "one service per container" I was thinking about the step before deploying to K8s. It's because I've seen a few years ago some python projects completely encapsulated in a Docker container, with an init system like supervisord (running a redis, a django app, and celery workers).

t-writescode 5y ago

Aren't pods groups of containers _that also share resources like hdd space_? so they're not quite the same as containers?

miked85 5y ago
Right, they are deployed as a group to share resources, otherwise they could just be deployed standalone. They are just containers though.