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.
I don't know how you read my post and came to the conclusion I didn't know what Kubernetes was.
> Kubernetes is a framework... There is no "one true solution/pattern", only what fits your needs.
Right, this is the opposite of what "framework" means in the rest of software development. If I choose RoR or Spring, it's because I want someone else to have made these decisions, reasonably, for me.
Kubernetes is instead like a random pile of tools, most of which are not directly useful to developers, with minimal guidance on which you should use or how you should put them together. All the sharp edges of the Unix shell, and none of the composability or fluency.
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
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).
In a large organization, you might see:
If you're building a SaaS product, you might see: But basically, you'll often have the following: 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:
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.