karmada/docs/proposals/karmada-operator/component-priority-class-name

title	authors	reviewers	approvers	creation-date
Support Priority Class Configuration for Karmada Control Plane Components	@jabellard	@RainbowMango	@RainbowMango	2025-01-01

Support Priority Class Configuration for Karmada Control Plane Components

Summary

This proposal aims to extend the Karmada operator by introducing support for configuring the priority class name for Karmada control plane components. By enabling users to configure a custom priority class name, this feature ensures critical components are scheduled with appropriate priority, enhancing overall system reliability and stability.

Motivation

Currently, the priority class name for Karmada components is hardcoded to system-node-critical for some components, while others do not specify a priority class at all. This limitation can compromise the reliability and stability of the system in environments where scheduling of critical components is essential.

By allowing users to configure the priority class name, this feature ensures:

• Greater control over scheduling of critical Karmada control plane components, enhancing system reliability and stability.
• Alignment with organizational policies for resource prioritization and workload management.
• Flexibility to adapt priority classes for specific operational environments and use cases.

Goals

• Provide a mechanism for configuring the scheduling priority of all in-cluster Karmada control plane components.
• Ensure the feature integrates seamlessly with existing deployments while maintaining backward compatibility.

Non-Goals

• Address scheduling priorities for components outside the Karmada control plane.

Proposal

Introduce a new optional priorityClassName field in the CommonSettings struct, which is used across all Karmada components.

API Changes

// CommonSettings describes the common settings of all Karmada Components.
type CommonSettings struct {
	
    // PriorityClassName specifies the priority class name for the component.
    // If not specified, it defaults to "system-node-critical".
    // +kubebuilder:default="system-node-critical"
    // +optional
    PriorityClassName string `json:"priorityClassName,omitempty"`
    
    // Other, existing fields omitted for brevity...
}

User Stories

Story 1

As an infrastructure engineer, I need to configure the priority class for Karmada control plane components to ensure critical components are reliably scheduled to ensure system stability and reliability.

Story 2

As an infrastructure engineer managing a multi-tenant cluster, I want the ability to override the default priority class for Karmada control plane components with a custom priority class that aligns with my organization’s policies, ensuring reliable resource allocation and system stability across workloads.

Risks and Mitigations

1. Backward Compatibility: Existing deployments might rely on the current hardcoded system-node-critical priority class for some components.

   • Mitigation: The priorityClassName field defaults to system-node-critical when not explicitly specified, preserving the current behavior.

Design Details

During the reconciliation process, the Karmada operator will:

• Check if priorityClassName is specified in the component’s CommonSettings.
• If specified:
  • Apply the specified priority class to the component’s Pod spec.
• If not specified:
  • Default to system-node-critical to maintain backward compatibility.