whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master' into dev-1.20 to keep in sync - 11-25-2020

Browse Source
This commit is contained in:
reylejano-rxm
2020-11-25 07:03:22 -08:00
parent 6fa3e91eb8 b4df624a5e
commit d8ae37587e
139 changed files with 6562 additions and 5229 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/concepts/architecture/controller.md
+2 -3
View File
@@ -92,9 +92,8 @@ Controllers that interact with external state find their desired state from
the API server, then communicate directly with an external system to bring
the current state closer in line.
(There actually is a controller that horizontally scales the
nodes in your cluster. See
[Cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling)).
(There actually is a [controller](https://github.com/kubernetes/autoscaler/)
that horizontally scales the nodes in your cluster.)
The important point here is that the controller makes some change to bring about
your desired state, and then reports current state back to your cluster's API server.
content/en/docs/concepts/architecture/nodes.md
-1
View File
@@ -358,5 +358,4 @@ For example, if `ShutdownGracePeriod=30s`, and `ShutdownGracePeriodCriticalPods=
* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
section of the architecture design document.
* Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/).
* Read about [cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
content/en/docs/concepts/cluster-administration/_index.md
-2
View File
@@ -39,8 +39,6 @@ Before choosing a guide, here are some considerations:
## Managing a cluster
* [Managing a cluster](/docs/tasks/administer-cluster/cluster-management/) describes several topics related to the lifecycle of a cluster: creating a new cluster, upgrading your cluster's master and worker nodes, performing node maintenance (e.g. kernel upgrades), and upgrading the Kubernetes API version of a running cluster.
* Learn how to [manage nodes](/docs/concepts/architecture/nodes/).
* Learn how to set up and manage the [resource quota](/docs/concepts/policy/resource-quotas/) for shared clusters.
content/en/docs/concepts/cluster-administration/flow-control.md
+1 -1
View File
@@ -440,7 +440,7 @@ poorly-behaved workloads that may be harming system health.
{{< /note >}}
* `apiserver_flowcontrol_request_concurrency_limit` is a gauge vector
hoding the computed concurrency limit (based on the API server's
holding the computed concurrency limit (based on the API server's
total concurrency limit and PriorityLevelConfigurations' concurrency
shares), broken down by the label `priority_level`.
content/en/docs/concepts/configuration/pod-priority-preemption.md
+1 -3
View File
@@ -321,9 +321,7 @@ Pod may be created that fits on the same Node. In this case, the scheduler will
schedule the higher priority Pod instead of the preemptor.
This is expected behavior: the Pod with the higher priority should take the place
of a Pod with a lower priority. Other controller actions, such as
[cluster autoscaling](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling),
may eventually provide capacity to schedule the pending Pods.
of a Pod with a lower priority.
### Higher priority Pods are preempted before lower priority pods
content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md
+104 -78
View File
@@ -12,125 +12,147 @@ weight: 50
{{< feature-state for_k8s_version="v1.16" state="alpha" >}}
The kube-scheduler can be configured to enable bin packing of resources along with extended resources using `RequestedToCapacityRatioResourceAllocation` priority function. Priority functions can be used to fine-tune the kube-scheduler as per custom needs.
The kube-scheduler can be configured to enable bin packing of resources along
with extended resources using `RequestedToCapacityRatioResourceAllocation`
priority function. Priority functions can be used to fine-tune the
kube-scheduler as per custom needs.
<!-- body -->
## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation
Before Kubernetes 1.15, Kube-scheduler used to allow scoring nodes based on the request to capacity ratio of primary resources like CPU and Memory. Kubernetes 1.16 added a new parameter to the priority function that allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters and improves the utilization of scarce resources in large clusters. The behavior of the `RequestedToCapacityRatioResourceAllocation` priority function can be controlled by a configuration option called `requestedToCapacityRatioArguments`. This argument consists of two parameters `shape` and `resources`. Shape allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. Resources
consists of `name` which specifies the resource to be considered during scoring and `weight` specify the weight of each resource.
Kubernetes allows the users to specify the resources along with weights for
each resource to score nodes based on the request to capacity ratio. This
allows users to bin pack extended resources by using appropriate parameters
and improves the utilization of scarce resources in large clusters. The
behavior of the `RequestedToCapacityRatioResourceAllocation` priority function
can be controlled by a configuration option called
`requestedToCapacityRatioArguments`. This argument consists of two parameters
`shape` and `resources`. The `shape` parameter allows the user to tune the
function as least requested or most requested based on `utilization` and
`score` values. The `resources` parameter consists of `name` of the resource
to be considered during scoring and `weight` specify the weight of each
resource.
Below is an example configuration that sets `requestedToCapacityRatioArguments` to bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar`
Below is an example configuration that sets
`requestedToCapacityRatioArguments` to bin packing behavior for extended
resources `intel.com/foo` and `intel.com/bar`.
```json
{
"kind" : "Policy",
"apiVersion" : "v1",
...
"priorities" : [
...
{
"name": "RequestedToCapacityRatioPriority",
"weight": 2,
"argument": {
"requestedToCapacityRatioArguments": {
"shape": [
{"utilization": 0, "score": 0},
{"utilization": 100, "score": 10}
],
"resources": [
{"name": "intel.com/foo", "weight": 3},
{"name": "intel.com/bar", "weight": 5}
]
}
}
}
],
}
```yaml
apiVersion: v1
kind: Policy
# ...
priorities:
# ...
- name: RequestedToCapacityRatioPriority
weight: 2
argument:
requestedToCapacityRatioArguments:
shape:
- utilization: 0
score: 0
- utilization: 100
score: 10
resources:
- name: intel.com/foo
weight: 3
- name: intel.com/bar
weight: 5
```
**This feature is disabled by default**
### Tuning RequestedToCapacityRatioResourceAllocation Priority Function
### Tuning the Priority Function
`shape` is used to specify the behavior of the `RequestedToCapacityRatioPriority` function.
`shape` is used to specify the behavior of the
`RequestedToCapacityRatioPriority` function.
```yaml
{"utilization": 0, "score": 0},
{"utilization": 100, "score": 10}
shape:
- utilization: 0
score: 0
- utilization: 100
score: 10
```
The above arguments give the node a score of 0 if utilization is 0% and 10 for utilization 100%, thus enabling bin packing behavior. To enable least requested the score value must be reversed as follows.
The above arguments give the node a `score` of 0 if `utilization` is 0% and 10 for
`utilization` 100%, thus enabling bin packing behavior. To enable least
requested the score value must be reversed as follows.
```yaml
{"utilization": 0, "score": 100},
{"utilization": 100, "score": 0}
shape:
- utilization: 0
score: 100
- utilization: 100
score: 0
```
`resources` is an optional parameter which by defaults is set to:
`resources` is an optional parameter which defaults to:
``` yaml
"resources": [
{"name": "CPU", "weight": 1},
{"name": "Memory", "weight": 1}
]
resources:
- name: CPU
weight: 1
- name: Memory
weight: 1
```
It can be used to add extended resources as follows:
```yaml
"resources": [
{"name": "intel.com/foo", "weight": 5},
{"name": "CPU", "weight": 3},
{"name": "Memory", "weight": 1}
]
resources:
- name: intel.com/foo
weight: 5
- name: CPU
weight: 3
- name: Memory
weight: 1
```
The weight parameter is optional and is set to 1 if not specified. Also, the weight cannot be set to a negative value.
The `weight` parameter is optional and is set to 1 if not specified. Also, the
`weight` cannot be set to a negative value.
### How the RequestedToCapacityRatioResourceAllocation Priority Function Scores Nodes
### Node scoring for capacity allocation
This section is intended for those who want to understand the internal details
of this feature.
Below is an example of how the node score is calculated for a given set of values.
```
Requested Resources
Requested resources:
```
intel.com/foo : 2
Memory: 256MB
CPU: 2
```
Resource Weights
Resource weights:
```
intel.com/foo : 5
Memory: 1
CPU: 3
```
FunctionShapePoint {{0, 0}, {100, 10}}
Node 1 Spec
Node 1 spec:
```
Available:
intel.com/foo : 4
Memory : 1 GB
CPU: 8
intel.com/foo: 4
Memory: 1 GB
CPU: 8
Used:
intel.com/foo: 1
Memory: 256MB
CPU: 1
intel.com/foo: 1
Memory: 256MB
CPU: 1
```
Node score:
Node Score:
```
intel.com/foo = resourceScoringFunction((2+1),4)
= (100 - ((4-3)*100/4)
= (100 - 25)
@@ -152,24 +174,24 @@ CPU = resourceScoringFunction((2+1),8)
NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3)
= 5
```
Node 2 spec:
Node 2 Spec
```
Available:
intel.com/foo: 8
Memory: 1GB
CPU: 8
intel.com/foo: 8
Memory: 1GB
CPU: 8
Used:
intel.com/foo: 2
Memory: 512MB
CPU: 6
```
intel.com/foo: 2
Memory: 512MB
CPU: 6
Node Score:
Node score:
```
intel.com/foo = resourceScoringFunction((2+2),8)
= (100 - ((8-4)*100/8)
= (100 - 50)
@@ -194,4 +216,8 @@ NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3)
```
## {{% heading "whatsnext" %}}
- Read more about the [scheduling framework](/docs/concepts/scheduling-eviction/scheduling-framework/)
- Read more about [scheduler configuration](/docs/reference/scheduling/config/)
content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md
+1 -1
View File
@@ -40,7 +40,7 @@ This means that no pod will be able to schedule onto `node1` unless it has a mat
To remove the taint added by the command above, you can run:
```shell
kubectl taint nodes node1 key:NoSchedule-
kubectl taint nodes node1 key=value:NoSchedule-
```
You specify a toleration for a pod in the PodSpec. Both of the following tolerations "match" the