Add Support for Component Priority Class Configuration in Karmada Operator

[jabellard]

What type of PR is this?

/kind feature

What this PR does / why we need it:
This is an implementation of this proposal to add support for configuring the priority class name of Karmada control plane components.

Which issue(s) this PR fixes:
Fixes #6009
Partof #6042
Special notes for your reviewer:

Does this PR introduce a user-facing change?:

`karmada-operator`: The new `PriorityClassName` field added as part of the Karmada control plane component configurations can be used to specify the priority class name of that component.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

Attention: Patch coverage is 81.25000% with 3 lines in your changes missing coverage. Please review.

Project coverage is 48.36%. Comparing base (820fd06) to head (954ee76).
Report is 6 commits behind head on master.

Files with missing lines	Patch %	Lines
operator/pkg/util/patcher/pather.go	40.00%	3 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6068      +/-   ##
==========================================
+ Coverage   48.33%   48.36%   +0.02%     
==========================================
  Files         666      666              
  Lines       54858    54889      +31     
==========================================
+ Hits        26518    26545      +27     
- Misses      26616    26619       +3     
- Partials     1724     1725       +1     

Flag	Coverage Δ
unittests	48.36% <81.25%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zhzhuang-zju]

/kind api-change

[zhzhuang-zju]

thanks @jabellard Generally LGTM. This is merely a suggestion: for the fields in CommonSettings, I recommend using patcher to handle the passing of field values. This approach can centralize modifications and make them easier to manage. For instance:

// Patcher defines multiple variables that need to be patched.
type Patcher struct {
	labels            map[string]string
        ... ...
	resources         corev1.ResourceRequirements
        priorityClassName string
}

func (p *Patcher) WithPriorityClassName(priorityClassName string) *Patcher {
	p.priorityClassName = priorityClassName
	return p
}

func (p *Patcher) ForDeployment(deployment *appsv1.Deployment) {
	deployment.Annotations = labels.Merge(deployment.Annotations, p.annotations)
	deployment.Spec.Template.Annotations = labels.Merge(deployment.Spec.Template.Annotations, p.annotations)

	deployment.Spec.Template.Spec.PriorityClassName = p.priorityClassName
        ... ...
}

func (p *Patcher) ForStatefulSet(sts *appsv1.StatefulSet) {
	sts.Labels = labels.Merge(sts.Labels, p.labels)
	sts.Spec.Template.Labels = labels.Merge(sts.Spec.Template.Labels, p.labels)
	
	sts.Spec.Template.Spec.PriorityClassName = p.priorityClassName
        ... ...
}

[RainbowMango]

/assign

[RainbowMango]

thanks @jabellard Generally LGTM. This is merely a suggestion: for the fields in CommonSettings, I recommend using patcher to handle the passing of field values. This approach can centralize modifications and make them easier to manage

Make sense to me. It seems we have a lesson learned after introducing a new configuration led to configuration chaos because failed to properly handle the order of the variables.

[jabellard]

I recommend using patcher to handle the passing of field values.

That's a great idea. Will push some changes shortly to incorporate that.

[karmada-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from rainbowmango. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• charts/OWNERS
• operator/OWNERS
• operator/pkg/apis/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[jabellard]

@RainbowMango , @zhzhuang-zju: Thanks for the constructive feedback. Just pushed changes to address your moments.

[zhzhuang-zju]

/lgtm
leave the approval to @RainbowMango

[zhzhuang-zju]

@jabellard It would be nice to merge the commit

[karmada-bot]

New changes are detected. LGTM label has been removed.

[jabellard]

@jabellard It would be nice to merge the commit

Just squashed.