sshd is kind of a poor example. Kubernetes has an idea of a pod -- a group of containers that share an netns and have an IP. Reasons you might want a pod: * A

sshd is kind of a poor example. Kubernetes has an idea of a pod -- a group of containers that share an netns and have an IP. Reasons you might want a pod: * A thick client or client side proxy that follows the ambassador pattern for service discovery and access. * A data-loader and data-server pair. The loader would grab data from some persistent source and write it to disk or a shared memory segment. The data-server would then use that data and serve it up. You'd could run the data-loader at a lower QoS so it doesn't stall the data-server. * Some sort of server and a log saver. The log saver could periodically batch up and compress structured log data and upload it to a persistent store (such as BigQuery in GCP). You want to build/configure/restart/upgrade the log saver separately from the server. You'd also run the log saver at a lower QoS. Inside of Google we have all sorts of examples where we have sets of containers/tasks/processes that are co-scheduled onto a machine and work together.