[FLINK-24093] Supports setting the percentage of kubernetes Request resources

[spoon-lz]

What is the purpose of the change

For the current native Kubernetes, we start the job to apply for resources (CPU,Memory) of the same limit and request, so as to achieve the best performance. However, in general, when the kubernetes cluster resources are used up by request allocation, In fact, there are still some physical resources left. If there is a way to reduce the number of requests per job, more jobs can be run and the resource utilization of the cluster can be improved.

Here are some simple configurations to scale down the value of request:

kubernetes.cpu.request.percent 
kubernetes.mem.request.percent

kubernetes.mem.request.percent： the default value is 1.0, the effective range of 0.0 to 1.0, the meaning of this value is: If the value is 0.5 and the total memory of taskmanager/jobmanager is 2048MB, the value of request is 2048MB*0.5=1024MB. That is, if the remaining memory of nodes is larger than 1024MB, pods can be allocated to run

kubernetes.cpu.request.percent: the default value is 1.0, the effective range of 0.0 to 1.0, the meaning of this value is: If the value is 0.5 and the number of cpus requested by TaskManager/JobManager is 1, the value of request is 1 x 0.5=0.5, that is, the remaining CPU usage of Nodes is greater than 0.5 to allocate pods to run

Brief change log

Supports setting the percentage of kubernetes Request resources

Verifying this change

This change added tests and can be verified as follows:
org.apache.flink.kubernetes.utils.KubernetesUtilsTest#testRequestMemory
org.apache.flink.kubernetes.utils.KubernetesUtilsTest#testRequestCpu

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): no
• The public API, i.e., is any changed class annotated with @Public(Evolving): no
• The serializers: no
• The runtime per-record code paths (performance sensitive): no
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: yes
• The S3 file system connector: no

Documentation

• Does this pull request introduce a new feature? no
• If yes, how is the feature documented? not documented

[flinkbot]

Thanks a lot for your contribution to the Apache Flink project. I'm the @flinkbot. I help the community
to review your pull request. We will use this comment to track the progress of the review.

Automated Checks

Last check on commit a4cfc14 (Wed Sep 01 03:42:13 UTC 2021)

Warnings:

• No documentation files were touched! Remember to keep the Flink docs up to date!
• This pull request references an unassigned Jira ticket. According to the code contribution guide, tickets need to be assigned before starting with the implementation work.

_{Mention the bot in a comment to re-run the automated checks.}

Review Progress

• ❓ 1. The [description] looks good.
• ❓ 2. There is [consensus] that the contribution should go into to Flink.
• ❓ 3. Needs [attention] from.
• ❓ 4. The change fits into the overall [architecture].
• ❓ 5. Overall code [quality] is good.

Please see the Pull Request Review Guide for a full explanation of the review process.

The Bot is tracking the review progress through labels. Labels are applied according to the order of the review items. For consensus, approval by a Flink committer of PMC member is required

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot approve description to approve one or more aspects (aspects: description, consensus, architecture and quality)
• @flinkbot approve all to approve all aspects
• @flinkbot approve-until architecture to approve everything until architecture
• @flinkbot attention @username1 [@username2 ..] to require somebody's attention
• @flinkbot disapprove architecture to remove an approval you gave earlier

[flinkbot]

CI report:

• a4cfc14 Azure: FAILURE

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build