<p>I'm wondering about the best practices for architecting my Kubernetes clusters.
For 1 environment (e.g. production), what organisation should I have in my clusters?</p>
<p>Examples: 1 cluster per technology stack, 1 cluster per exposure area (internet, private...), 1 cluster with everything ... ?</p>
<p>Thanks for your help</p>

Xire
<p>I'm not a Kubernetes expert, so I'll give you some generic guidance to help until someone who knows more weighs in.</p>
<ul>
<li>By technology stack - no.  That wouldn't provide any value I can think of.</li>
<li>By 'exposure' - yes.  If one cluster is compromised the damage will hopefully be limited to that cluster only.</li>
<li>By solution - yes.</li>
</ul>
<p><strong>Solution vs Technology Stack</strong></p>
<p>&quot;Solution&quot; is where you have a number of systems that exist to addresses a specific business problem or domain.  This could be functional e.g. finance vs CRM vs HR.</p>
<p>Technology stacks in the literal sense is not likely to be relevant.  True, it's not uncommon for different solutions &amp; systems to be comprised of different technology (is that what you were meaning?) - but that's usually a by-product, not the primary driver.</p>
<p>Let's say you have two major solutions (e.g. the finance and CRM).  It's likely that you will have situations that impacts one but shouldn't impact the other.</p>
<ul>
<li><p>Planned functional changes: e.g. rolling out a major release.  Object Orientated programmers and architects have had this nailed for years through designing systems that are cohesive but loosely-coupled (see: <a href="https://stackoverflow.com/questions/3085285/difference-between-cohesion-and-coupling">Difference Between Cohesion and Coupling</a>), and through stuff like the Stable Dependencies Principle.  Having both solutions dependent on the same cluster makes them coupled in that respect, which.</p>
</li>
<li><p>Planned infrastructure changes: e.g. patching, maintenance, resource reallocation, etc.</p>
</li>
<li><p>Unplanned changes: e.g. un-planned outage, security breaches.</p>
</li>
</ul>
<p><strong>Conclusion</strong></p>
<p>Look at what will be running on the cluster(s), and what solutions they are part of, and consider separation along those lines.</p>
<p>The final answer might be a combination of both, some sort of balance between security concerns and solution (i.e. change) boundaries.</p>
