Topology

Topology is a combination of Service and Workload Clusters, their namespaces and the Service Resource Lifecycle APIs that are to be made available from Service Clusters to one or more Workload Clusters.

The following two assumptions that must hold true for topologies currently supported by the Services Toolkit.

The presence of a “flat” network is assumed, which is to say that workloads running in one cluster can establish network connections (resolution and routing) to the Kubernetes API Server endpoints of all other clusters without any additional setup.
Application workloads can establish network connections to the endpoints of service instances without any additional setup.

Supported Topologies

Topologies currently supported by Service Toolkit have the following rules:

API Projection does not work within a single cluster but only across a set of distinct service and workload clusters.
An API group can be either projected into a cluster or installed/reconciled within that cluster, not both. For example, you cannot install the RabbitmqCluster Operator and project RabbitmqCluster resources from a Service cluster in the same Workload cluster. See Limitations for further details.
Resources of a projected API group must exist in identically named namespaces in the workload and service clusters. For a workload cluster, there can only be a single service cluster for a API group projection. For example, a workload cluster cannot receive projections of a RabbitmqCluster API from service cluster 1 and from service cluster 2.

Provide a Service Resource Lifecycle API

From one Service cluster to one Workload cluster

Service Operator wants to provide a Service Resource Lifecycle API from one service cluster to one workload cluster in the same named namespace. Box-and-line diagram. An API group in a namespace in a Service cluster projecting itself into a namespace in an Application Workload cluster.

Box-and-line diagram. API groups in Service clusters projecting into Application Workload clusters. One API group is the Postgres kind. The other is the Rabbit MQ Cluster kind.

From a Service cluster to multiple Workload clusters

Service Operator wants to provide a Service Resource Lifecycle API from a Service cluster to multiple Workload clusters with the same named namespace. Box-and-line diagram. An API group in a namespace in a Service cluster projecting itself into the namespaces of two different Application Workload clusters.

Provide different Service Resource Lifecycle APIs

From a Service cluster to a Workload cluster

Service Operator wants to provide different Service Resource Lifecycle APIs from one Service cluster and distinct namespaces to one Workload cluster in matching named namespaces. Box-and-line diagram. API groups in Service clusters projecting into Application Workload clusters. One API group is the Postgres kind and it is in prod namespaces. The other is the Rabbit MQ Cluster kind and it is in dev namespaces.

Provide multiple Service Resource Lifecycle APIs

From a Service Cluster to a Workload cluster

Service Operator wants to provide multiple Service Resource Lifecycle APIs from one Service Cluster and one namespace to one Workload cluster with the same named namespace. Box-and-line diagram. API groups within a shared namespace in a Service cluster projecting into a shared namespace in an Application Workload cluster. One API group is the Postgres kind. The other is the Rabbit MQ Cluster kind.

From multiple Service Clusters to one Workload cluster

Service Operator wants to provide multiple Service Resource Lifecycle APIs from multiple Service Clusters with the same namespace to one Workload cluster with the same named namespace. Box-and-line diagram. A Postgres API group in Service cluster 1 projects into a namespace in Application Workload cluster 1. A Rabbit MQ Cluster API group in Service cluster 2 projects into the same namespace in Application Workload cluster 1.

Caution: In this particular scenario, you might encounter name collisions in the application workload clusters for the core resources such as secrets. For example, if API-1 creates a secret called binding-secret and API-2 also creates a secret called binding-secret, Resource Replication component copies both of these secrets in the application workload cluster, but one is overridden by the other depending on which one is replicated second.

From multiple service clusters to multiple workload clusters

Service Operator wants to provide multiple Service Resource from multiple distinct Service Clusters with the same namespace name to multiple Workload clusters with matching named namespace. Box-and-line diagram. Two API groups of different kinds in different Service clusters both projecting into different Application Workload clusters.