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

Merge branch 'master' into release-1.8

Browse Source
This commit is contained in:
zacharysarah
2017-12-12 10:51:24 -06:00
parent 1b1d0701c0 6b0458c706
commit 7dcc87ce97
10 changed files with 92 additions and 79 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/tasks/administer-cluster/opaque-integer-resource-node.md → docs/tasks/administer-cluster/extended-resource-node.md
+26 -27
View File
@@ -1,15 +1,15 @@
---
title: Advertise Opaque Integer Resources for a Node
title: Advertise Extended Resources for a Node
---
{% capture overview %}
This page shows how to specify opaque integer resources for a Node.
Opaque integer resources allow cluster administrators to advertise node-level
This page shows how to specify extended resources for a Node.
Extended resources allow cluster administrators to advertise node-level
resources that would otherwise be unknown to Kubernetes.
{% include feature-state-deprecated.md %}
{% include feature-state-stable.md %}
{% endcapture %}
@@ -31,9 +31,9 @@ kubectl get nodes
Choose one of your Nodes to use for this exercise.
## Advertise a new opaque integer resource on one of your Nodes
## Advertise a new extended resource on one of your Nodes
To advertise a new opaque integer resource on a Node, send an HTTP PATCH request to
To advertise a new extended resource on a Node, send an HTTP PATCH request to
the Kubernetes API server. For example, suppose one of your Nodes has four dongles
attached. Here's an example of a PATCH request that advertises four dongle resources
for your Node.
@@ -47,7 +47,7 @@ Host: k8s-master:8080
[
{
"op": "add",
"path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-dongle",
"path": "/status/capacity/example.com~1dongle",
"value": "4"
}
]
@@ -69,7 +69,7 @@ Replace `<your-node-name>` with the name of your Node:
```shell
curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "add", "path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-dongle", "value": "4"}]' \
--data '[{"op": "add", "path": "/status/capacity/example.com~1dongle", "value": "4"}]' \
http://localhost:8001/api/v1/nodes/<your-node-name>/status
```
@@ -85,7 +85,7 @@ The output shows that the Node has a capacity of 4 dongles:
"alpha.kubernetes.io/nvidia-gpu": "0",
"cpu": "2",
"memory": "2049008Ki",
"pod.alpha.kubernetes.io/opaque-int-resource-dongle": "4",
"example.com/dongle": "4",
```
Describe your Node:
@@ -98,53 +98,52 @@ Once again, the output shows the dongle resource:
```yaml
Capacity:
alpha.kubernetes.io/nvidia-gpu: 0
cpu: 2
memory: 2049008Ki
pod.alpha.kubernetes.io/opaque-int-resource-dongle: 4
alpha.kubernetes.io/nvidia-gpu: 0
cpu: 2
memory: 2049008Ki
example.com/dongle: 4
```
Now, application developers can create Pods that request a certain
number of dongles. See
[Assign Opaque Integer Resources to a Container](/docs/tasks/configure-pod-container/opaque-integer-resource/).
[Assign Extended Resources to a Container](/docs/tasks/configure-pod-container/extended-resource/).
## Discussion
Opaque integer resources are similar to memory and CPU resources. For example,
Extended resources are similar to memory and CPU resources. For example,
just as a Node has a certain amount of memory and CPU to be shared by all components
running on the Node, it can have a certain number of dongles to be shared
by all components running on the Node. And just as application developers
can create Pods that request a certain amount of memory and CPU, they can
create Pods that request a certain number of dongles.
Opaque integer resources are called opaque because Kubernetes does not
Extended resources are opaque to Kubernetes; Kubernetes does not
know anything about what they are. Kubernetes knows only that a Node
has a certain number of them. They are called integer resources because
they must be advertised in integer amounts. For example, a Node can advertise
four dongles, but not 4.5 dongles.
has a certain number of them. Extended resources must be advertised in integer
amounts. For example, a Node can advertise four dongles, but not 4.5 dongles.
### Storage example
Suppose a Node has 800 GiB of a special kind of disk storage. You could
create a name for the special storage, say opaque-int-resource-special-storage.
create a name for the special storage, say example.com/special-storage.
Then you could advertise it in chunks of a certain size, say 100 GiB. In that case,
your Node would advertise that it has eight resources of type
opaque-int-resource-special-storage.
example.com/special-storage.
```yaml
Capacity:
...
pod.alpha.kubernetes.io/opaque-int-resource-special-storage: 8
example.com/special-storage: 8
```
If you want to allow arbitrary requests for special storage, you
could advertise special storage in chunks of size 1 byte. In that case, you would advertise
800Gi resources of type opaque-int-resource-special-storage.
800Gi resources of type example.com/special-storage.
```yaml
Capacity:
...
pod.alpha.kubernetes.io/opaque-int-resource-special-storage: 800Gi
example.com/special-storage: 800Gi
```
Then a Container could request any number of bytes of special storage, up to 800Gi.
@@ -162,7 +161,7 @@ Host: k8s-master:8080
[
{
"op": "remove",
"path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-dongle",
"path": "/status/capacity/example.com~1dongle",
}
]
```
@@ -179,7 +178,7 @@ Replace `<your-node-name>` with the name of your Node:
```shell
curl --header "Content-Type: application/json-patch+json" \
--request PATCH \
--data '[{"op": "remove", "path": "/status/capacity/pod.alpha.kubernetes.io~1opaque-int-resource-dongle"}]' \
--data '[{"op": "remove", "path": "/status/capacity/example.com~1dongle"}]' \
http://localhost:8001/api/v1/nodes/<your-node-name>/status
```
@@ -196,7 +195,7 @@ kubectl describe node <your-node-name> | grep dongle
### For application developers
* [Assign Opaque Integer Resources to a Container](/docs/tasks/configure-pod-container/opaque-integer-resource/)
* [Assign Extended Resources to a Container](/docs/tasks/configure-pod-container/extended-resource/)
### For cluster administrators
docs/tasks/administer-cluster/out-of-resource.md
+8 -8
View File
@@ -19,8 +19,8 @@ nodes become unstable.
## Eviction Policy
The `kubelet` can proactively monitor for and prevent total starvation of a
compute resource. In those cases, the `kubelet` can reclaim the starved
resource by proactively failing one or more Pods. When the `kubelet` fails
compute resource. In those cases, the `kubelet` can reclaim the starved
resource by proactively failing one or more Pods. When the `kubelet` fails
a Pod, it terminates all of its containers and transitions its `PodPhase` to `Failed`.
### Eviction Signals
@@ -42,11 +42,11 @@ The percentage based value is calculated relative to the total capacity
associated with each signal.
The value for `memory.available` is derived from the cgroupfs instead of tools
like `free -m`. This is important because `free -m` does not work in a
like `free -m`. This is important because `free -m` does not work in a
container, and if users use the [node
allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) feature, out of resource decisions
are made local to the end user Pod part of the cgroup hierarchy as well as the
root node. This
root node. This
[script](/docs/tasks/administer-cluster/out-of-resource/memory-available.sh)
reproduces the same set of steps that the `kubelet` performs to calculate
`memory.available`. The `kubelet` excludes inactive_file (i.e. # of bytes of
@@ -60,7 +60,7 @@ memory is reclaimable under pressure.
container writable layers.
`imagefs` is optional. `kubelet` auto-discovers these filesystems using
cAdvisor. `kubelet` does not care about any other filesystems. Any other types
cAdvisor. `kubelet` does not care about any other filesystems. Any other types
of configurations are not currently supported by the kubelet. For example, it is
*not OK* to store volumes and logs in a dedicated `filesystem`.
@@ -78,7 +78,7 @@ Each threshold has the following form:
where:
* `eviction-signal` is a eviction signal token as defined in the previous table.
* `eviction-signal` is an eviction signal token as defined in the previous table.
* `operator` is the desired relational operator, such as `<` (less than).
* `quantity` is the eviction threshhold quantity, such as `1Gi`. These tokens must
match the quantity representation used by Kubernetes. An eviction threshold can also
@@ -208,7 +208,7 @@ relative to their request for that resource are killed first. If no Pod
has exceeded its request, the strategy targets the largest consumer of the
starved resource.
* `Guaranteed` Pods are guaranteed only when requests and limits are specified
for all the containers and they are equal A `Guaranteed` Pod is guaranteed to
for all the containers and they are equal. A `Guaranteed` Pod is guaranteed to
never be evicted because of another Pod's resource consumption. If a system
daemon (such as `kubelet`, `docker`, and `journald`) is consuming more resources
than were reserved via `system-reserved` or `kube-reserved` allocations, and the
@@ -322,7 +322,7 @@ and trigger eviction assuming those Pods use less than their configured request.
### DaemonSet
It is never desired for a `kubelet` to evict a `DaemonSet` Pod, since the Pod is
It is never desired for `kubelet` to evict a `DaemonSet` Pod, since the Pod is
immediately recreated and rescheduled back to the same node.
At the moment, the `kubelet` has no ability to distinguish a Pod created
docs/tasks/administer-cluster/reserve-compute-resources.md
+5 -5
View File
@@ -52,8 +52,8 @@ Resources can be reserved for two categories of system daemons in the `kubelet`.
### Enabling QoS and Pod level cgroups
To properly enforce node allocatable constraints on the node, you must
enable the new cgroup hierarchy via the `--cgroups-per-qos` flag. This flag is
enabled by default. When enabled, the `kubelet` will parent all end-user pods
enable the new cgroup hierarchy via the `--cgroups-per-qos` flag. This flag is
enabled by default. When enabled, the `kubelet` will parent all end-user pods
under a cgroup hierarchy managed by the `kubelet`.
### Configuring a cgroup driver
@@ -71,7 +71,7 @@ transient slices for resources that are supported by that init system.
Depending on the configuration of the associated container runtime,
operators may have to choose a particular cgroup driver to ensure
proper system behavior. For example, if operators use the `systemd`
proper system behavior. For example, if operators use the `systemd`
cgroup driver provided by the `docker` runtime, the `kubelet` must
be configured to use the `systemd` cgroup driver.
@@ -199,7 +199,7 @@ Under this scenario, `Allocatable` will be `14.5 CPUs`, `28.5Gi` of memory and
`98Gi` of local storage.
Scheduler ensures that the total memory `requests` across all pods on this node does
not exceed `28.5Gi` and storage doesn't exceed `88Gi`.
Kubelet evicts pods whenever the overall memory usage exceeds across pods exceed `28.5Gi`,
Kubelet evicts pods whenever the overall memory usage across pods exceeds `28.5Gi`,
or if overall disk usage exceeds `88Gi` If all processes on the node consume as
much CPU as they can, pods together cannot consume more than `14.5 CPUs`.
@@ -224,7 +224,7 @@ kubelet flag. Note that unless `--kube-reserved`, or `--system-reserved` or
not affect existing deployments.
As of Kubernetes version 1.6, `kubelet` launches pods in their own cgroup
sandbox in a dedicated part of the cgroup hierarchy it manages. Operators are
sandbox in a dedicated part of the cgroup hierarchy it manages. Operators are
required to drain their nodes prior to upgrade of the `kubelet` from prior
versions in order to ensure pods and their associated containers are launched in
the proper part of the cgroup hierarchy.