Cluster must haves

[danielepolencic]

@ipedrazas has just presented at Cloud Native Wales and he has a "must-have" list which looks quite interesting.

We might need to borrow a few items.

Slides

[weibeld]

We're actually already covering many of them in our TODO, but I added those that were missing.

Here are some questions that I still have about some of the items:

• Upgrade story: what does it mean?
• Shared storage: what kind of storage?
• Docker registry/Helm registry: self-hosting in the cluster?
• Service to dependencies <- own the DNS: running your own DNS servers?

[ipedrazas]

Let see if I can bring some light to these questions :) Usually, I describe them a bit in my talks, so, I understand that in isolation are a bit less useful.

• Upgrade story: Define how you're going to upgrade your clusters and define the risks. This can be something from "using the upgrade functionality in GKE" to "rolling out a new bare-metal cluster and moving the workloads to it". The importance here is to define what do you do, how do you do it and what can go wrong (and what do you do to minimise disruption).

• shared storage, or Storage: what kind of storage your cluster offers (ephemeral, block storage, S3-like) and what are the limitations of it. It's not enough with defining this PVC or that PV, the key here is to put on the table the rules that manage storage so everybody consuming these APIs understands the risks and the operability of the storage.

• Docker registry: This part was a bit more of calling out a dependency. People need to understand the limitations (and advantages) of using docker hub, or quay or artifactory or... etc. There are different strategies to deal with different use cases. It's ok putting Docker registry: quay but you have to understand what would happen if for any reason quay is not available.

• Service to Dependencies: this is an anti-pattern that I've been using for years now. An application that has dependencies (a database, for example) does not consume a service deployed by another app/team, it creates its own service to that dependency. This guarantees that the application controls the DNS to that dependency. Service can be of any kubernetes service type. That's not the important bit, the important part is to explicitly define all the objects, and resources that define an application.

[danielepolencic]

Thanks for this Ivan!

[weibeld]

@ipedrazas thanks a lot for the clarifications!