On Sunday, August 13, 2017 at 12:32:24 AM UTC-7, Timo Reimann wrote: > Somewhat of a middle ground solution might be to create "sub-clusters" using > taints and tolerations -- that is, have dedicated nodes for dedicated > application classes or workloads inside a given cluster. It may reduce the > general overhead inherent to managing separate clusters while still being > able to leverage a lot of the built-in Kubernetes tooling.
Timo, I'm glad you brought that up, that's a varation of what we were debating originally. However we would accomplish it, taints + tolerations, node selectors, or node affinities, we're basically forcing k8s to only run certain pods on certain nodes. Extactly as you mentioned, this would be a middle ground approach instead of creating separate clusters. It would neatly solve the problem I was concerned about with applying different egress rules to different pods. It would even provide some fencing, so really bad misbehaviors caused by an app (e.g. network saturation) can only effect so many nodes. Controlling which nodes a pod can be deployed on wouldn't solve our cluster network security needs (pod-to-pod security). But, of course, I've seen there are new-ish NetworkPolicies and freely available providers (e.g. calico) to account for that. The sticky part for me, and the reason for the quesiton here, was "what's the best idea in k8s today?". I can absolutely see handling deployments in either way and the most common way I've seen people describe their installations was using a cluster per application. Being new to k8s, I'm keen on following as many well-worn paths as possible for our initial deployments :-). -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
