feat: set a CPU request on the etcd container for Burstable QoS

[xrl]

What

Set a CPU request (never a limit) on the etcd container so the pod runs as Burstable instead of BestEffort QoS.

Without a CPU request, the etcd container gets the kernel-floor cpu.shares of 2 and is the first workload evicted / starved under node CPU pressure. A small request (default 50m) raises the scheduling floor without ever throttling etcd (no limit is set).

Details

• New controller-level flag --etcd-cpu-request (default "50m").
• Empty string or "0" applies no request, preserving the original BestEffort behavior.
• A malformed quantity is treated as unset, so a bad flag value can never wedge cluster creation.
• No API/CRD change — this is an operator-set default knob only.
• Documented in the flag help and docs/operator-flags.md (linked from the README).
• Table-driven test asserts the request is applied (with no CPU limit), that an override is honored, and that empty / "0" / malformed values disable it.

Sequencing / precedence

This introduces an operator-set etcd CPU-request / QoS default. It should land after #398 (podspec-scheduling). Any user-set resources must take precedence over this operator default — that layering is not yet reconciled against #398, which is why this is opened as a draft.

DCO

Commit is DCO signed-off (Signed-off-by: Xavier Lange <xrlange@gmail.com>).

[kubernetes-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[kubernetes-prow]

Hi @xrl. Thanks for your PR.

I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.