With the standalone mode, the control-plane is usually residing on the master / control-plane nodes. These nodes are dedicated only to host control-plane of a cluster (API-server, scheduler, etcd, KCM, etc). Furthermore, the communication model between the CP and the DP is flat, the CNI is taking care of setting up the networking for the CP and the DP, network policies are defined for components in the same cluster.

With Hypershift and the introduction of the external control-plane model, the situation is different. Since the control-plane resides on a different cluster (the management cluster), there is a different CNI taking care of setting up networking for control-plane pods. Control-plane components might be distributed across different namespaces (e.g., two namespaces per cluster-control-plane), also more than one control-plane will be sharing the same cluster, which means stronger network boundries might be required.

In addition to networking, there is control-plane component locality which is also related. I.e., where would a guest cluster control-plane components live on the management cluster and which components are really needed to be hosted on the management cluster Vs. the guest cluster [1].

Goal(s)

• Finalize the component locality discussion after weighing the pros and cons.
• Finalize the network topology for the control-plane and the data-plane.
• Decide on the network architecture required to bridge CP and DP (e.g., tunnels, CNI, DNS, etc)

References

[1] https://docs.google.com/document/d/1BDoo3hchNz1C3QSeixnGMX6HaYCS11hp6J4j-9ZNL3E/edit#