Control plane groups

A control plane group is a read-only control plane that combines configuration from its members, which are standard control planes. All of the standard control planes within a control plane group share the same cluster of Data Plane nodes.

The following diagram illustrates using a control plane group for a federated platform administrator model:

flowchart LR
  A(Team Blue)
  B(Team Green)
  C(Control plane Blue)
  D(Control plane Purple<br>global config)
  E(Control plane Green)
  F(Data Plane nodes)
  G(Data Plane nodes)

  A -- deck gateway sync --> C
  B -- deck gateway sync --> E

  subgraph id1 ["`**KONNECT ORG**`"]
    subgraph id2 [<br>control plane group Steel]
    C
    D
    E
    end
  end

  id2 -- Get config from 
  control plane group
  Steel--> F & G

  subgraph id3 [Data centers]
  F
  G
  end

In this diagram:

• Team Blue configures control plane Blue, which is then combined with the configuration from Team Green.
• The control plane group also contains control plane Purple, which is managed by a central platform team.
• The central platform team manages global plugin configuration in control plane Purple, which is added to any configuration that teams Blue and Green provide.

Konnect Workspaces: If you want to isolate configuration for separate teams on one data plane without a control plane per team, consider using Konnect Workspaces instead. A control plane group combines configuration from multiple standard control planes. Workspaces isolate teams within a single control plane instead. A control plane can’t be both Workspace-enabled and a member of a control plane group.

In Konnect, control plane groups can be created using the Control Planes API.

curl -X POST "$KONNECT_CONTROL_PLANE_URL/v2/control-planes" \
     --no-progress-meter --fail-with-body  \
     -H "Authorization: Bearer $KONNECT_TOKEN"\
     -H "Content-Type: application/json" \
     --json '{
       "name": "CPG",
       "cluster_type": "CLUSTER_TYPE_CONTROL_PLANE_GROUP"
     }'

After you have a control plane group, you can add control planes to the group using the Konnect UI or API.

curl -X POST "$KONNECT_CONTROL_PLANE_URL/v2/control-planes/$CONTROL_PLANE_GROUP_ID/group-memberships/add" \
     --no-progress-meter --fail-with-body  \
     -H "Authorization: Bearer $KONNECT_TOKEN"\
     -H "Content-Type: application/json" \
     --json '{
       "members": [
         {
           "id": "062e2f2c-0f42-4938-91b4-f73f399260f5"
         }
       ]
     }'

There are some special cases and behaviors to note for Gateway entities in a control plane group.

All entities in a control plane group must have unique names and IDs. For example, if two members of a control plane group both have a Service named example_service, it will cause a conflict which must be resolved to restore function.

A number of Kong Gateway entities can be associated with each other. Based on the type of association, the behavior of these associated entities in a control plane group follows one of these patterns:

• If the entity relationship is referenced by ID, associations remain constrained to the behavior of the individual control plane.
• If the entity relationship is referenced by a string, then associations across one or more member control planes are possible.

The Kong Gateway resource associated with an entity must be part of the same standard control plane as the entity.

Entity-specific behavior exceptions

The following are exceptions to the entity behavior:

If a Consumer is defined in one member control plane and the request it authorizes hits a Route or Gateway Service defined in a different member control plane of the same control plane group, Observability can’t resolve the Consumer across control planes. In this case, the Consumer displays as (deleted) in Requests, Explorer, and Dashboards, even though it exists and successfully authorized the request. This happens because Observability assumes all the data for a request comes from a single control plane.

To avoid this, use centrally-managed Consumers instead of concentrating shared Consumers in one member control plane. Centrally-managed Consumers only support Key Auth.

When combining configurations from individual control planes into a control plane group you may receive conflict errors in Konnect, for example:

Conflicts have been detected between these control planes: 
CONTROL-PLANE-EXAMPLE
CONTROL-PLANE-ANOTHER-EXAMPLE

The control plane won’t update a Data Plane configuration until the conflict is resolved. Review the following table of common issues and potential fixes: