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.

NB It is important to note the following two assumptions that must hold true for topologies currently supported by the Services Toolkit.

  1. The presence of a "flat" network is assumed, which is to say that workloads running in one cluster are able to establish network connections (resolution and routing) to the Kubernetes API Server endpoints of all other clusters without any additional setup
  2. Application workloads can establish network connections to the endpoints of Service Instances without any additional setup

We are considering ideas that will allow us to relax these assumptions in the future but do not yet have a firm date in mind for when such functionality may be released.

Supported Topologies

Topologies that are currently supported by the Services Toolkit are documented below. Please also note the following rules that apply.

  • API Projection does NOT work within a single cluster but only across a set of distinct service and workload clusters.
    • We have no plans on changing this with subsequent releases.
  • An API group can be either projected into a given cluster or installed/reconciled within that cluster, not both.
    • For example, you cannot install the RabbitmqCluster Operator and project RabbitmqClusters from a Service cluster in the same Workload cluster.
    • Right now, we have no plans on changing this with subsequent releases.
    • Refer to Limitations for further details.
  • Resources of a projected API group must exist in identically named namespaces in the workload and service clusters.

    • For a given workload cluster, there can only be a single service cluster for a given API group projection.
    • For example, a workload cluster cannot receive projections of a RabbitmqCluster API from service cluster 1 as well as from service cluster 2.
    • We think this is a legitimate use case, so we may change this in the future.
  • As a Service Operator I want to provide a Service Resource Lifecycle API from one Service cluster to one Workload cluster in the same named namespace. two-clusters-one-ns-one-api

    diff-clusters-one-ns-diff-apis

  • As a Service Operator I want to provide different Service Resource Lifecycle APIs from one Service cluster and distinct namespaces to one Workload cluster in matching named namespaces. two-clusters-multiple-ns-one-api

  • As Service Operator I want to provide a Service Resource Lifecycle API from a Service cluster to multiple Workload clusters with the same named namespace. multiple-clusters-one-ns-one-api

  • As Service Operator I want to provide multiple Service Resource Lifecycle APIs from one Service Cluster and one namespace to one Workload cluster with the same named namespace. two-clusters-one-ns-multiple-apis

  • As Service Operator I want to provide multiple Service Resource Lifecycle APIs from multiple Service Clusters with the same namespace to one Workload cluster with the same named namespace. diff-clusters-one-ns-diff-apis

    Warning: In this particular scenario, you might encounter name collisions in the Application Workload Clusters for the core resources like 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 will copy both of these secrets in the Application Workload Cluster but one will be overridden by the other depending on which one is replicated second.

  • As Service Operator I want to **provide multiple Service Resource from multiple distinct Service Clusters with the same namespace name to multiple Workload clusters with matching named namespace. diff-clusters-one-ns-diff-apis

check-circle-line exclamation-circle-line close-line
Scroll to top icon