5

Decisions: How Many Clusters?, Authentication, and Encryption

 1 year ago
source link: https://devm.io/kubernetes/kubernetes-clusters-authentication-encryption
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Kubernetes, Decisions — Part 2

Decisions: How Many Clusters?, Authentication, and Encryption

Kubernetes is a container orchestrator that has rapidly gained popularity among developers and IT operations teams alike. While it started out as a tool to manage containerized applications, it has evolved into much more than that — Kubernetes is a microcosmos and it is “eating the world.”

A few months ago, I was honored to receive an invitation to speak at DevOPSCon, Munich. I delivered a session on architectural decisions for companies building a Kubernetes platform. Having spent time with strategic companies adopting Kubernetes, I've been able to spot trends, and I am keen to share these learnings with anyone building a Kubernetes platform. I had many interesting ‘corridor’ discussions after my session (seemed like I touched a raw nerve), and this led me to write this article series.

You can find the first part of this series here: Decisions: Multi-Tenancy, Purpose-Built Operating System

Opinions expressed in this article are solely my own and do not express the views or opinions of my employer.

The challenge(s)

So, you decided to run your containerised applications on Kubernetes, because everyone seems to be doing it these days. Day 0 looks fantastic. You deploy, scale, and observe. Then Day 1 and Day 2 arrive. Day 3 is around the corner. You suddenly notice that Kubernetes is a microcosmos. You are challenged to make decisions. How many clusters should I create? Which tenancy model should I use? How should I encrypt service-to-service communication?

Decision #3, how many clusters?

Should you have a large number of small-scale clusters or a small number of large-scale clusters? Without getting too deep into the Kubernetes scalability envelope, the following diagram is a good start.

The challenge

Possible decision model to follow:

  • Step 1 - Analyze constraints: untrusted tenants, organizational boundaries, areas of impact concerns
  • Step 2 - Optimize within constraints: Fewer cluster leads to more efficient bin packing and use of resources but will increase the blast radius

Conclusions

  • Any production workload should be isolated from any non-production workload. This should be hard isolation (separated network boundaries, separated clusters).
  • For each cluster, try to define the business deployment unit while you analyze the constraints (i.e., cluster A will host 5 customers, 10 node group, 10 VMs per node group)
  • Tooling for creating multiple clusters is the new norm (Terraform, CrossPlane, cloud provider-specific IaC tools). If you opt in for multiple clusters, I recommend...

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK