What would you like to be added:

Add support in the Karmada Operator Helm chart for configuring:

• A priorityClassName field for the operator Deployment
• A PodDisruptionBudget (PDB) resource dedicated to the operator

These should be optional features configurable via values.yaml, disabled by default for backward compatibility.

Concretely:

1. Allow setting:

   operator:
     priorityClassName: "system-cluster-critical"

2. Introduce a PDB template, disabled by default:

   operator:
     pdb:
       enabled: true
       minAvailable: 1

Why is this needed:

1. The operator is a critical control-plane component
   The Karmada Operator manages the lifecycle and configuration of the Karmada control planes. If it becomes unavailable, even momentarily, reconciliation, and component updates all stall. This places the operator in the same category as other mission‑critical system components, which typically include protections like disruption budgets and scheduling priority.

2. Lack of PriorityClass can delay recovery or break upgrades
   During events such as node pressure, rolling OS updates, or autoscaler scale‑downs, the operator may have its pod evicted and consequently fail to reconcile Karmada instances

   Exposing priorityClassName ensures the operator is always scheduled ahead of standard workloads, consistent with Kubernetes best practices for core system components.

3. No PDB exposes the operator to full eviction during maintenance
   Without a PodDisruptionBudget, a node drain can evict all operator pods simultaneously. This risks interrupting reconciliation loops

   A PDB ensures at least one instance stays available during voluntary disruptions such as node drains or cluster‑autoscaler actions.

4. Improves resilience and cluster‑wide stability
   Environments with multiple nodes, autoscaling, or regular scheduled maintenance rely on predictable disruption handling. Adding PriorityClass + PDB support:

   • Reduces operational risk
   • Prevents subtle downtime
   • Aligns behavior with user expectations for high‑availability operator components.

5. Aligns with best practices from upstream and ecosystem charts
   Many Kubernetes system charts (cert‑manager, Kyverno etc.) already provide support for PDBs and PriorityClasses. Adding support brings Karmada Operator to parity with modern operational standards.

🛠 Proposed Implementation

1. Add optional priorityClassName

Example values:

operator:
  priorityClassName: ""

Rendered into the Deployment only when non‑empty.

2. Add optional PodDisruptionBudget

Example values:

operator:
  pdb:
    enabled: true
    minAvailable: 1

Rendered as a dedicated PDB manifest when enabled.

3. Documentation updates

• Document recommended PriorityClasses (e.g., system‑cluster‑critical).
• Explain safe behavior when replicas = 1 (use minAvailable: 1).
• Add example values and guidance for cluster operators.

🚀 Summary

Supporting PriorityClass and PDB in the Karmada Operator Helm chart:

• Improves scheduling guarantees during node pressure
• Ensures at least one operator instance is always available
• Aligns the chart with Kubernetes ecosystem best practices
• Reduces operational risk and unexpected downtime

These enhancements meaningfully improve Karmada’s resilience and bring the operator’s deployment model in line with expectations for critical cluster infrastructure.