Cluster architecture

Management clusters

Management clusters are where Shipper itself runs. It has the Shipper
Custom Resource Definitions installed, and is where application developers
interact with the Application or Release objects. The management
cluster stores the set of Cluster objects and associated Secrets that
enable Shipper to connect to the application clusters.

Typically you have one of these per large deployment, or one with a standby.

Application clusters

Application clusters are where Shipper installs and rolls out user
workloads. Shipper does not run any custom software in the application
clusters: it only needs a service account and associated RBAC configuration.

Patterns

One management, many application

This is the standard arrangement if you have a fleet of Kubernetes clusters
that you would like to manage with Shipper. The single management cluster
provides application developers with a single place to interface with Shipper's
objects and orchestrate their rollouts.

One-and-the-same

It is totally fine if the management cluster and the application
cluster are the same. This is how Shipper is developed, and also how you would
use Shipper if you only have a single Kubernetes cluster in your
infrastructure. You can think about this configuration as using Shipper to
provide a better Deployment object, but without any multi-cluster federation.

Multiple management, each with own set of application

While Shipper fully supports namespaces as units of multi-tenancy, it does not
yet have any way to limit the set of clusters that an Application can select.
So, if your organization has multiple groups of Kubernetes clusters that are
consumed by disjoint sets of users, it might make sense to create
a management cluster for each group of application clusters that need
strong isolation between each other.