1.Proposed title of this feature request

Enable the Machine Config Operator to support two Machine Config Pools for managing two HW-specific types of control plane nodes

2. What is the nature and description of the request?

The Machine Config Operator (MCO) design restricts control plane nodes to the single, default master MachineConfigPool (MCP). This limitation prevents the necessary temporal coexistence of different hardware-specific control plane configuration (e.g., new kernel arguments for a hardware refresh or specialized kernel tuning from a PerformanceProfile) when replacing control plane hardware without resorting to a full cluster redeployment.

3. Why does the customer need this? (List the business requirements here)

Multiple control-plane MCPs is particularly relevant for clusters with schedulable control planes, where:

• PerformanceProfiles are used to partition the workloads away from the control plane pods.
  • The PerformanceProfiles is per MCP
  • The PerformanceProfiles includes the list (reserved=,isolated=) of the CPU, meaning that it depends on the HW (CPU number and topology, which is always different - typically more)
• Workloads may drive requirements for MachineConfigs, kubelet config (eg sysctls), and kernel arguments. 

During hardware refresh a full replacement of schedulable control plane hardware (HW) may be necessary, particularly when existing HW reaches End-of-Life (EoL). Currently, when using schedulable control planes the nodes belong to a single MachineConfigPool (MCP). With any required node tuning in place, replacing them typically requires a complete cluster redeployment.

In these scenarios, to avoid a full redeployment of the cluster, it is required the temporal coexistence of two different control plane MCPs (HW profiles). But today there can only be one MCP associated with control plane nodes.

4. List any affected packages or components.

Machine config operator.