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.
Standard control planes vs groups
In a standard control plane setup, each team configures and manages their own data plane nodes.
For example, in the following diagram, Team Blue configures Control Plane Blue, which then uses a set of data plane nodes that only run Blue configuration; the same happens with Team Yellow.
Figure 1: Standard control plane workflow
In a control plane group setup, each team still administers their own control plane, but the data plane nodes are shared.
The following diagram illustrates using a control plane group for a federated platform administrator model. In this example, Team Blue configures Control Plane Blue, which is then combined with the configuration from Team Yellow. In addition, the control plane group contains Control Plane Green, which is managed by a central platform team. The central team provides global plugin configuration, which is added to any configuration that teams Blue and Yellow provide.
The data plane nodes in the cluster use the combined configuration from all three groups.
Figure 2: Control plane group workflow
A control plane group can contain up to 256 control planes.
You can add or remove up to 50 member control planes at a time.
Each standard control plane can be a member of no more than 5 control plane groups.
Data plane nodes
In a control plane group, the combined configuration from all member control planes is pushed to each data plane node.
A data plane node can only connect to a single control plane in a cluster.
This means that in a control plane group, all data plane nodes must be managed from the control plane group itself.
Members of a control plane group can’t have their own data plane nodes.
When adding a standard control plane to a group, make sure it has no connected data plane nodes.
The data plane nodes of a control plane group are not visible to a member control plane.
Configuring core entities
There are some special cases and behaviors to note for core 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
it will cause a conflict which must be resolved to restore function.
A number of Kong entities can be associated with another Kong entity.
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.
||Type of Association
||Service, route, consumer
||By control plane
||By control plane
|GraphQL Rate Limiting cost decoration
The Kong Gateway resource associated with an entity must be part of the same standard control plane as the entity.
Entity-specific behavior exceptions:
Consumers: A consumer of a standard control plane becomes a consumer of the control plane group once the originating
control plane becomes a member of the control plane group.
The authentication credentials of a consumer in a standard control plane become valid credentials of the control plane group.
The ID of a consumer from one control plane group member can’t be used in authorization for another control plane group member.
Consumer groups: Only consumers from the same control plane can be added to a consumer group.
Consumer group names in the Rate Limiting Advanced plugin can reference group names from other control plane group members.
Vaults: The prefix of each Vault must be unique.
Once a Vault from a standard control plane becomes part of a control plane group, it becomes available to the whole control plane group.
An entity field in a standard control plane can successfully reference a secret in a Vault from another standard control plane, now both part of the control plane group.
Global plugins: A plugin that is globally scoped in the standard control plane remains globally scoped in the control plane group.
This plugin will affect the entire control plane group.
For example, two instances of the Rate Limiting plugin cannot be installed in the control plane group.
Note: If you want to limit which users can apply global plugins, add all global plugins into a single control plane, and then grant access to only your limited set of users. If any other member control planes add a global plugin to their configuration, a conflict will result and prevent the changed configuration from being applied.
A control plane group composition will be applied even if the configurations of the standard control planes are not combined successfully.
This means that even if there is some conflict and the member control planes weren’t merged successfully, a control plane group still gets created.
Control plane groups are read-only (with some exceptions), so configuration modifications must be made via a member control plane.
The following are exceptions to the read-only rule:
- A data plane node client certificate can be generated in the UI or uploaded to a control plane group.
- Data plane nodes can be connected to a control plane group, however, members of a control plane group cannot have any data plane nodes connected to them.
Kong Ingress Controller control planes can’t be part of a control plane group.
One control plane group cannot be a member of another control plane group.
Analytics for a control plane group are only available at the group level.
Member standard control planes have no individual analytics reporting.
Conflict detection in a control plane group happens only after you have added a data plane node to the control plane group.