Update Task topics on resource management. (#4158)
This commit is contained in:
Steve Perry
@@ -1,122 +0,0 @@
|
||||
---
|
||||
title: Assign CPU and RAM Resources to a Container
|
||||
description: When you create a Pod, you can request CPU and RAM resources for the containers that run in the Pod. You can also set limits for CPU and RAM use.
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
This page shows how to assign CPU and RAM resources to containers running
|
||||
in a Kubernetes Pod.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## Assign CPU and RAM resources to a container
|
||||
|
||||
When you create a Pod, you can request CPU and RAM resources for the containers
|
||||
that run in the Pod. You can also set limits for CPU and RAM resources. To
|
||||
request CPU and RAM resources, include the `resources:requests` field in the
|
||||
configuration file. To set limits on CPU and RAM resources, include the
|
||||
`resources:limits` field.
|
||||
|
||||
Kubernetes schedules a Pod to run on a Node only if the Node has enough CPU and
|
||||
RAM available to satisfy the total CPU and RAM requested by all of the
|
||||
containers in the Pod. Also, as a container runs on a Node, Kubernetes doesn't
|
||||
allow the CPU and RAM consumed by the container to exceed the limits you specify
|
||||
for the container. If a container exceeds its RAM limit, it is terminated. If a
|
||||
container exceeds its CPU limit, it becomes a candidate for having its CPU use
|
||||
throttled.
|
||||
|
||||
In this exercise, you create a Pod that runs one container. The configuration
|
||||
file for the Pod requests 250 milicpu and 64 mebibytes of RAM. It also sets
|
||||
upper limits of 1 cpu and 128 mebibytes of RAM. Here is the configuration file
|
||||
for the `Pod`:
|
||||
|
||||
{% include code.html language="yaml" file="cpu-ram.yaml" ghlink="/docs/tasks/configure-pod-container/cpu-ram.yaml" %}
|
||||
|
||||
1. Create a Pod based on the YAML configuration file:
|
||||
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/cpu-ram.yaml
|
||||
|
||||
1. Display information about the pod:
|
||||
|
||||
kubectl describe pod cpu-ram-demo
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
Name: cpu-ram-demo
|
||||
...
|
||||
Containers:
|
||||
cpu-ram-demo-container:
|
||||
...
|
||||
Limits:
|
||||
cpu: 1
|
||||
memory: 128Mi
|
||||
Requests:
|
||||
cpu: 250m
|
||||
memory: 64Mi
|
||||
|
||||
## CPU and RAM units
|
||||
|
||||
The CPU resource is measured in *cpu*s. Fractional values are allowed. You can
|
||||
use the suffix *m* to mean mili. For example 100m cpu is 100 milicpu, and is
|
||||
the same as 0.1 cpu.
|
||||
|
||||
The RAM resource is measured in bytes. You can express RAM as a plain integer
|
||||
or a fixed-point integer with one of these suffixes: E, P, T, G, M, K, Ei, Pi,
|
||||
Ti, Gi, Mi, Ki. For example, the following represent approximately the same value:
|
||||
|
||||
128974848, 129e6, 129M , 123Mi
|
||||
|
||||
If you're not sure how much resources to request, you can first launch the
|
||||
application without specifying resources, and use
|
||||
[resource usage monitoring](/docs/user-guide/monitoring) to determine
|
||||
appropriate values.
|
||||
|
||||
If a Container exceeds its RAM limit, it dies from an out-of-memory condition.
|
||||
You can improve reliability by specifying a value that is a little higher
|
||||
than what you expect to use.
|
||||
|
||||
If you specify a request, a Pod is guaranteed to be able to use that much
|
||||
of the resource. See
|
||||
[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/resource-qos.md) for the difference between resource limits and requests.
|
||||
|
||||
## If you don't specify limits or requests
|
||||
|
||||
If you don't specify a RAM limit, Kubernetes places no upper bound on the
|
||||
amount of RAM a Container can use. A Container could use all the RAM
|
||||
available on the Node where the Container is running. Similarly, if you don't
|
||||
specify a CPU limit, Kubernetes places no upper bound on CPU resources, and a
|
||||
Container could use all of the CPU resources available on the Node.
|
||||
|
||||
Default limits are applied according to a limit range for the default
|
||||
[namespace](/docs/user-guide/namespaces). You can use `kubectl describe limitrange limits`
|
||||
to see the default limits.
|
||||
|
||||
For information about why you would want to specify limits, see
|
||||
[Setting Pod CPU and Memory Limits](/docs/tasks/configure-pod-container/limit-range/).
|
||||
|
||||
For information about what happens if you don't specify CPU and RAM requests, see
|
||||
[Resource Requests and Limits of Pod and Container](/docs/concepts/configuration/manage-compute-resources-container/).
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
* Learn more about [managing compute resources](/docs/concepts/configuration/manage-compute-resources-container/).
|
||||
* See [ResourceRequirements](/docs/api-reference/{{page.version}}/#resourcerequirements-v1-core).
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
@@ -0,0 +1,273 @@
|
||||
---
|
||||
title: Assign CPU Resources to Containers and Pods
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
This page shows how to assign a CPU *request* and a CPU *limit* to
|
||||
a Container. A Container is guaranteed to have as much CPU as it requests,
|
||||
but is not allowed to use more CPU than its limit.
|
||||
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
Each node in your cluster must have at least 1 CPU.
|
||||
|
||||
A few of the steps on this page require that the
|
||||
[Heapster](https://github.com/kubernetes/heapster) service is running
|
||||
in your cluster. But if you don't have Heapster running, you can do most
|
||||
of the steps, and it won't be a problem if you skip the Heapster steps.
|
||||
|
||||
To see whether the Heapster service is running, enter this command:
|
||||
|
||||
```shell
|
||||
kubectl get services --namespace=kube-system
|
||||
```
|
||||
|
||||
If the heapster service is running, it shows in the output:
|
||||
|
||||
```shell
|
||||
NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
kube-system heapster 10.11.240.9 <none> 80/TCP 6d
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## Create a namespace
|
||||
|
||||
Create a namespace so that the resources you create in this exercise are
|
||||
isolated from the rest of your cluster.
|
||||
|
||||
```shell
|
||||
kubectl create namespace cpu-example
|
||||
```
|
||||
|
||||
## Specify a CPU request and a CPU limit
|
||||
|
||||
To specify a CPU request for a Container, include the `resources:requests` field
|
||||
in the Container's resource manifest. To specify a CPU limit, include `resources:limits`.
|
||||
|
||||
In this exercise, you create a Pod that has one Container. The container has a CPU
|
||||
request of 0.5 cpu and a CPU limit of 1 cpu. Here's the configuration file
|
||||
for the Pod:
|
||||
|
||||
{% include code.html language="yaml" file="cpu-request-limit.yaml" ghlink="/docs/tasks/configure-pod-container/cpu-request-limit.yaml" %}
|
||||
|
||||
In the configuration file, the `args` section provides arguments for the Container when it starts.
|
||||
The `-cpus "2"` argument tells the Container to attempt to use 2 cpus.
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/cpu-request-limit.yaml --namespace=cpu-example
|
||||
```
|
||||
|
||||
Verify that the Pod's Container is running:
|
||||
|
||||
```shell
|
||||
kubectl get pod cpu-demo --namespace=cpu-example
|
||||
```
|
||||
|
||||
View detailed information about the Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pod cpu-demo --output=yaml --namespace=cpu-example
|
||||
```
|
||||
|
||||
The output shows that the one Container in the Pod has a CPU request of 500 millicpu
|
||||
and a CPU limit of 1 cpu.
|
||||
|
||||
```shell
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
requests:
|
||||
cpu: 500m
|
||||
```
|
||||
|
||||
Start a proxy so that you can call the heapster service:
|
||||
|
||||
```shell
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
In another command window, get the CPU usage rate from the heapster service:
|
||||
|
||||
```
|
||||
curl http://localhost:8001/api/v1/proxy/namespaces/kube-system/services/heapster/api/v1/model/namespaces/cpu-example/pods/cpu-demo/metrics/cpu/usage_rate
|
||||
```
|
||||
|
||||
The output shows that the Pod is using 974 millicpu, which is just a bit less than
|
||||
the limit of 1 cpu specified in the Pod's configuration file.
|
||||
|
||||
```json
|
||||
{
|
||||
"timestamp": "2017-06-22T18:48:00Z",
|
||||
"value": 974
|
||||
}
|
||||
```
|
||||
|
||||
Recall that by setting `-cpu "2"`, you configured the Container to attempt to use 2 cpus.
|
||||
But the container is only being allowed to use about 1 cpu. The Container's CPU use is being
|
||||
throttled, because the Container is attempting to use more CPU resources than its limit.
|
||||
|
||||
Note: There's another possible explanation for the CPU throttling. The Node might not have
|
||||
enough CPU resources available. Recall that the prerequisites for this exercise require that each of
|
||||
your Nodes has at least 1 cpu. If your Container is running on a Node that has only 1 cpu, the Container
|
||||
cannot use more than 1 cpu regardless of the CPU limit specified for the Container.
|
||||
|
||||
## CPU units
|
||||
|
||||
The CPU resource is measured in *cpu* units. One cpu, in Kubernetes, is equivalent to:
|
||||
|
||||
* 1 AWS vCPU
|
||||
* 1 GCP Core
|
||||
* 1 Azure vCore
|
||||
* 1 Hyperthread on a bare-metal Intel processor with Hyperthreading
|
||||
|
||||
Fractional values are allowed. A Container that requests 0.5 cpu is guaranteed half as much
|
||||
CPU as a Container that requests 1 cpu. You can use the suffix m to mean milli. For example
|
||||
100m cpu, 100 millicpu, and 0.1 cpu are all the same. Precision finer than 1m is not allowed.
|
||||
|
||||
CPU is always requested as an absolute quantity, never as a relative quantity; 0.1 is the same
|
||||
amount of CPU on a single-core, dual-core, or 48-core machine.
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod cpu-demo --namespace=cpu-example
|
||||
```
|
||||
|
||||
## Specify a CPU request that is too big for your Nodes
|
||||
|
||||
CPU requests and limits are associated with Containers, but it is useful to think
|
||||
of a Pod as having a CPU request and limit. The CPU request for a Pod is the sum
|
||||
of the CPU requests for all the Containers in the Pod. Likewise, the CPU limit for
|
||||
a Pod is the sum of the CPU limits for all the Containers in the Pod.
|
||||
|
||||
Pod scheduling is based on requests. A Pod is scheduled to run on a Node only if
|
||||
the Node has enough CPU resources available to satisfy the Pod’s CPU request.
|
||||
|
||||
In this exercise, you create a Pod that has a CPU request so big that it exceeds
|
||||
the capacity of any Node in your cluster. Here is the configuration file for a Pod
|
||||
that has one Container. The Container requests 100 cpu, which is likely to exceed the
|
||||
capacity of any Node in your cluster.
|
||||
|
||||
{% include code.html language="yaml" file="cpu-request-limit-2.yaml" ghlink="/docs/tasks/configure-pod-container/cpu-request-limit-2.yaml" %}
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/cpu-request-limit-2.yaml --namespace=cpu-example
|
||||
```
|
||||
|
||||
View the Pod's status:
|
||||
|
||||
```shell
|
||||
kubectl get pod cpu-demo-2 --namespace=cpu-example
|
||||
```
|
||||
|
||||
The output shows that the Pod's status is Pending. That is, the Pod has not been
|
||||
scheduled to run on any Node, and it will remain in the Pending state indefinitely:
|
||||
|
||||
|
||||
```
|
||||
kubectl get pod cpu-demo-2 --namespace=cpu-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
cpu-demo-2 0/1 Pending 0 7m
|
||||
```
|
||||
|
||||
View detailed information about the Pod, including events:
|
||||
|
||||
|
||||
```shell
|
||||
kubectl describe pod cpu-demo-2 --namespace=cpu-example
|
||||
```
|
||||
|
||||
The output shows that the Container cannot be scheduled because of insufficient
|
||||
CPU resources on the Nodes:
|
||||
|
||||
|
||||
```shell
|
||||
Events:
|
||||
Reason Message
|
||||
------ -------
|
||||
FailedScheduling No nodes are available that match all of the following predicates:: Insufficient cpu (3).
|
||||
|
||||
```
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod cpu-demo-2 --namespace=cpu-example
|
||||
```
|
||||
|
||||
## If you don’t specify a CPU limit
|
||||
|
||||
If you don’t specify a CPU limit for a Container, then one of these situations applies:
|
||||
|
||||
* The Container has no upper bound on the CPU resources it can use. The Container
|
||||
could use all of the CPU resources available on the Node where it is running.
|
||||
|
||||
* The Container is running in a namespace that has a default CPU limit, and the
|
||||
Container is automatically assigned the default limit. Cluster administrators can use a
|
||||
[LimitRange](https://kubernetes.io/docs/api-reference/v1.6/)
|
||||
to specify a default value for the CPU limit.
|
||||
|
||||
## Motivation for CPU requests and limits
|
||||
|
||||
By configuring the CPU requests and limits of the Containers that run in your
|
||||
cluster, you can make efficient use of the CPU resources available on your cluster's
|
||||
Nodes. By keeping a Pod's CPU request low, you give the Pod a good chance of being
|
||||
scheduled. By having a CPU limit that is greater than the CPU request, you accomplish two things:
|
||||
|
||||
* The Pod can have bursts of activity where it makes use of CPU resources that happen to be available.
|
||||
* The amount of CPU resources a Pod can use during a burst is limited to some reasonable amount.
|
||||
|
||||
## Clean up
|
||||
|
||||
Delete your namespace:
|
||||
|
||||
```shell
|
||||
kubectl delete namespace cpu-example
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
|
||||
### For app developers
|
||||
|
||||
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
|
||||
|
||||
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
|
||||
|
||||
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
@@ -0,0 +1,368 @@
|
||||
---
|
||||
title: Assign Memory Resources to Containers and Pods
|
||||
---
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
This page shows how to assign a memory *request* and a memory *limit* to a
|
||||
Container. A Container is guaranteed to have as much memory as it requests,
|
||||
but is not allowed to use more memory than its limit.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
Each node in your cluster must have at least 300 MiB of memory.
|
||||
|
||||
A few of the steps on this page require that the
|
||||
[Heapster](https://github.com/kubernetes/heapster) service is running
|
||||
in your cluster. But if you don't have Heapster running, you can do most
|
||||
of the steps, and it won't be a problem if you skip the Heapster steps.
|
||||
|
||||
To see whether the Heapster service is running, enter this command:
|
||||
|
||||
```shell
|
||||
kubectl get services --namespace=kube-system
|
||||
```
|
||||
|
||||
If the Heapster service is running, it shows in the output:
|
||||
|
||||
```shell
|
||||
NAMESPACE NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
||||
kube-system heapster 10.11.240.9 <none> 80/TCP 6d
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## Create a namespace
|
||||
|
||||
Create a namespace so that the resources you create in this exercise are
|
||||
isolated from the rest of your cluster.
|
||||
|
||||
```shell
|
||||
kubectl create namespace mem-example
|
||||
```
|
||||
|
||||
## Specify a memory request and a memory limit
|
||||
|
||||
To specify a memory request for a Container, include the `resources:requests` field
|
||||
in the Container's resource manifest. To specify a memory limit, include `resources:limits`.
|
||||
|
||||
In this exercise, you create a Pod that has one Container. The container has a memory
|
||||
request of 100 MiB and a memory limit of 200 MiB. Here's the configuration file
|
||||
for the Pod:
|
||||
|
||||
{% include code.html language="yaml" file="memory-request-limit.yaml" ghlink="/docs/tasks/configure-pod-container/memory-request-limit.yaml" %}
|
||||
|
||||
In the configuration file, the `args` section provides arguments for the Container when it starts.
|
||||
The `-mem-total 150Mi` argument tells the Container to attempt to allocate 150 MiB of memory.
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/memory-request-limit.yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
Verify that the Pod's Container is running:
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo --namespace=mem-example
|
||||
```
|
||||
|
||||
View detailed information about the Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo --output=yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
The output shows that the one Container in the Pod has a memory request of 100 MiB
|
||||
and a memory limit of 200 MiB.
|
||||
|
||||
|
||||
```yaml
|
||||
...
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
memory: 100Mi
|
||||
...
|
||||
```
|
||||
|
||||
Start a proxy so that you can call the Heapster service:
|
||||
|
||||
```shell
|
||||
kubectl proxy
|
||||
```
|
||||
|
||||
In another command window, get the memory usage from the Heapster service:
|
||||
|
||||
```
|
||||
curl http://localhost:8001/api/v1/proxy/namespaces/kube-system/services/heapster/api/v1/model/namespaces/mem-example/pods/memory-demo/metrics/memory/usage
|
||||
```
|
||||
|
||||
The output shows that the Pod is using about 162,900,000 bytes of memory, which
|
||||
is about 150 MiB. This is greater than the Pod's 100 MiB request, but within the
|
||||
Pod's 200 MiB limit.
|
||||
|
||||
```json
|
||||
{
|
||||
"timestamp": "2017-06-20T18:54:00Z",
|
||||
"value": 162856960
|
||||
}
|
||||
```
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod memory-demo --namespace=mem-example
|
||||
```
|
||||
|
||||
## Exceed a Container's memory limit
|
||||
|
||||
A Container can exceed its memory request if the Node has memory available. But a Container
|
||||
is not allowed to use more than its memory limit. If a container allocates more memory than
|
||||
its limit, the Container becomes a candidate for termination. If the Container continues to
|
||||
to consume memory beyond its limit, the Container is terminated. If a terminated Container is
|
||||
restartable, the kubelet will restart it, as with any other type of runtime failure.
|
||||
|
||||
In this exercise, you create a Pod that attempts to allocate more memory than its limit.
|
||||
Here is the configuration file for a Pod that has one Container. The Container has a
|
||||
memory request of 50 MiB and a memory limit of 100 MiB.
|
||||
|
||||
{% include code.html language="yaml" file="memory-request-limit-2.yaml" ghlink="/docs/tasks/configure-pod-container/memory-request-limit-2.yaml" %}
|
||||
|
||||
In the configuration file, in the `args` section, you can see that the Container
|
||||
will attempt to allocate 250 MiB of memory, which is well above the 100 MiB limit.
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/memory-request-limit-2.yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
View detailed information about the Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
```
|
||||
|
||||
At this point, the Container might be running, or it might have been killed. If the
|
||||
Container has not yet been killed, repeat the preceding command until you see that
|
||||
the Container has been killed:
|
||||
|
||||
```shell
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-2 0/1 OOMKilled 1 24s
|
||||
```
|
||||
|
||||
Get a more detailed view of the Container's status:
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
The output shows that the Container has been killed because it is out of memory (OOM).
|
||||
|
||||
```shell
|
||||
lastState:
|
||||
terminated:
|
||||
containerID: docker://65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f
|
||||
exitCode: 137
|
||||
finishedAt: 2017-06-20T20:52:19Z
|
||||
reason: OOMKilled
|
||||
startedAt: null
|
||||
```
|
||||
|
||||
The Container in this exercise is restartable, so the kubelet will restart it. Enter
|
||||
this command several times to see that the Container gets repeatedly killed and restarted:
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
```
|
||||
|
||||
The output shows that the Container gets killed, restarted, killed again, restarted again, and so on:
|
||||
|
||||
```
|
||||
stevepe@sperry-1:~/steveperry-53.github.io$ kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-2 0/1 OOMKilled 1 37s
|
||||
stevepe@sperry-1:~/steveperry-53.github.io$ kubectl get pod memory-demo-2 --namespace=mem-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-2 1/1 Running 2 40s
|
||||
```
|
||||
|
||||
View detailed information about the Pod's history:
|
||||
|
||||
|
||||
```
|
||||
kubectl describe pod memory-demo-2 --namespace=mem-example
|
||||
```
|
||||
|
||||
The output shows that the Container starts and fails repeatedly:
|
||||
|
||||
|
||||
```
|
||||
... Normal Created Created container with id 66a3a20aa7980e61be4922780bf9d24d1a1d8b7395c09861225b0eba1b1f8511
|
||||
... Warning BackOff Back-off restarting failed container
|
||||
|
||||
```
|
||||
|
||||
View detailed information about your cluster's Nodes:
|
||||
|
||||
|
||||
```
|
||||
kubectl describe nodes
|
||||
```
|
||||
|
||||
The output includes a record of the Container being killed because of an out-of-memory condition:
|
||||
|
||||
```
|
||||
Warning OOMKilling Memory cgroup out of memory: Kill process 4481 (stress) score 1994 or sacrifice child
|
||||
```
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod memory-demo-2 --namespace=mem-example
|
||||
```
|
||||
|
||||
## Specify a memory request that is too big for your Nodes
|
||||
|
||||
Memory requests and limits are associated with Containers, but it is useful to think
|
||||
of a Pod as having a memory request and limit. The memory request for the Pod is the
|
||||
sum of the memory requests for all the Containers in the Pod. Likewise, the memory
|
||||
limit for the Pod is the sum of the limits of all the Containers in the Pod.
|
||||
|
||||
Pod scheduling is based on requests. A Pod is scheduled to run on a Node only if the Node
|
||||
has enough available memory to satisfy the Pod's memory request.
|
||||
|
||||
In this exercise, you create a Pod that has a memory request so big that it exceeds the
|
||||
capacity of any Node in your cluster. Here is the configuration file for a Pod that has one
|
||||
Container. The Container requests 1000 GiB of memory, which is likely to exceed the capacity
|
||||
of any Node in your cluster.
|
||||
|
||||
{% include code.html language="yaml" file="memory-request-limit-3.yaml" ghlink="/docs/tasks/configure-pod-container/memory-request-limit-3.yaml" %}
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/memory-request-limit-3.yaml --namespace=mem-example
|
||||
```
|
||||
|
||||
View the Pod's status:
|
||||
|
||||
```shell
|
||||
kubectl get pod memory-demo-3 --namespace=mem-example
|
||||
```
|
||||
|
||||
The output shows that the Pod's status is PENDING. That is, the Pod has not been
|
||||
scheduled to run on any Node, and it will remain in the PENDING state indefinitely:
|
||||
|
||||
|
||||
```
|
||||
kubectl get pod memory-demo-3 --namespace=mem-example
|
||||
NAME READY STATUS RESTARTS AGE
|
||||
memory-demo-3 0/1 Pending 0 25s
|
||||
```
|
||||
|
||||
View detailed information about the Pod, including events:
|
||||
|
||||
|
||||
```shell
|
||||
kubectl describe pod memory-demo-3 --namespace=mem-example
|
||||
```
|
||||
|
||||
The output shows that the Container cannot be scheduled because of insufficient memory on the Nodes:
|
||||
|
||||
|
||||
```shell
|
||||
Events:
|
||||
... Reason Message
|
||||
------ -------
|
||||
... FailedScheduling No nodes are available that match all of the following predicates:: Insufficient memory (3).
|
||||
```
|
||||
|
||||
## Memory units
|
||||
|
||||
The memory resource is measured in bytes. You can express memory as a plain integer or a
|
||||
fixed-point integer with one of these suffixes: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki.
|
||||
For example, the following represent approximately the same value:
|
||||
|
||||
```shell
|
||||
128974848, 129e6, 129M , 123Mi
|
||||
```
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod memory-demo-3 --namespace=mem-example
|
||||
```
|
||||
|
||||
## If you don’t specify a memory limit
|
||||
|
||||
If you don’t specify a memory limit for a Container, then one of these situations applies:
|
||||
|
||||
* The Container has no upper bound on the amount of memory it uses. The Container
|
||||
could use all of the memory available on the Node where it is running.
|
||||
|
||||
* The Container is running in a namespace that has a default memory limit, and the
|
||||
Container is automatically assigned the default limit. Cluster administrators can use a
|
||||
[LimitRange](https://kubernetes.io/docs/api-reference/v1.6/)
|
||||
to specify a default value for the memory limit.
|
||||
|
||||
## Motivation for memory requests and limits
|
||||
|
||||
By configuring memory requests and limits for the Containers that run in your
|
||||
cluster, you can make efficient use of the memory resources available on your cluster's
|
||||
Nodes. By keeping a Pod's memory request low, you give the Pod a good chance of being
|
||||
scheduled. By having a memory limit that is greater than the memory request, you accomplish two things:
|
||||
|
||||
* The Pod can have bursts of activity where it makes use of memory that happens to be available.
|
||||
* The amount of memory a Pod can use during a burst is limited to some reasonable amount.
|
||||
|
||||
## Clean up
|
||||
|
||||
Delete your namespace. This deletes all the Pods that you created for this task:
|
||||
|
||||
```shell
|
||||
kubectl delete namespace mem-example
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
### For app developers
|
||||
|
||||
* [Assign CPU Resources to Containers and Pods](docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
* [Configure Quality of Service for Pods](/docs/tasks/configure-pod-container/quality-service-pod/)
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
|
||||
|
||||
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
|
||||
|
||||
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
@@ -1,15 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: cpu-ram-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: cpu-ram-demo-container
|
||||
image: gcr.io/google-samples/node-hello:1.0
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
cpu: "250m"
|
||||
limits:
|
||||
memory: "128Mi"
|
||||
cpu: "1"
|
||||
@@ -0,0 +1,16 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: cpu-demo-2
|
||||
spec:
|
||||
containers:
|
||||
- name: cpu-demo-ctr-2
|
||||
image: vish/stress
|
||||
resources:
|
||||
limits:
|
||||
cpu: "100"
|
||||
requests:
|
||||
cpu: "100"
|
||||
args:
|
||||
- -cpus
|
||||
- "2"
|
||||
@@ -0,0 +1,16 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: cpu-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: cpu-demo-ctr
|
||||
image: vish/stress
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
requests:
|
||||
cpu: "0.5"
|
||||
args:
|
||||
- -cpus
|
||||
- "2"
|
||||
@@ -1,12 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: invalid-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: kubernetes-serve-hostname
|
||||
image: gcr.io/google_containers/serve_hostname
|
||||
resources:
|
||||
limits:
|
||||
cpu: "3"
|
||||
memory: 100Mi
|
||||
@@ -1,26 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: LimitRange
|
||||
metadata:
|
||||
name: mylimits
|
||||
spec:
|
||||
limits:
|
||||
- max:
|
||||
cpu: "2"
|
||||
memory: 1Gi
|
||||
min:
|
||||
cpu: 200m
|
||||
memory: 6Mi
|
||||
type: Pod
|
||||
- default:
|
||||
cpu: 300m
|
||||
memory: 200Mi
|
||||
defaultRequest:
|
||||
cpu: 200m
|
||||
memory: 100Mi
|
||||
max:
|
||||
cpu: "2"
|
||||
memory: 1Gi
|
||||
min:
|
||||
cpu: 100m
|
||||
memory: 3Mi
|
||||
type: Container
|
||||
Executable → Regular
+1
-3
@@ -1,13 +1,11 @@
|
||||
apiVersion: v1
|
||||
kind: LimitRange
|
||||
metadata:
|
||||
name: limits
|
||||
name: mem-limit-range
|
||||
spec:
|
||||
limits:
|
||||
- default:
|
||||
cpu: 200m
|
||||
memory: 512Mi
|
||||
defaultRequest:
|
||||
cpu: 100m
|
||||
memory: 256Mi
|
||||
type: Container
|
||||
@@ -0,0 +1,20 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: memory-demo-2
|
||||
spec:
|
||||
containers:
|
||||
- name: memory-demo-2-ctr
|
||||
image: vish/stress
|
||||
resources:
|
||||
requests:
|
||||
memory: 50Mi
|
||||
limits:
|
||||
memory: "100Mi"
|
||||
args:
|
||||
- -mem-total
|
||||
- 250Mi
|
||||
- -mem-alloc-size
|
||||
- 10Mi
|
||||
- -mem-alloc-sleep
|
||||
- 1s
|
||||
@@ -0,0 +1,20 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: memory-demo-3
|
||||
spec:
|
||||
containers:
|
||||
- name: memory-demo-3-ctr
|
||||
image: vish/stress
|
||||
resources:
|
||||
limits:
|
||||
memory: "1000Gi"
|
||||
requests:
|
||||
memory: "1000Gi"
|
||||
args:
|
||||
- -mem-total
|
||||
- 150Mi
|
||||
- -mem-alloc-size
|
||||
- 10Mi
|
||||
- -mem-alloc-sleep
|
||||
- 1s
|
||||
@@ -0,0 +1,20 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: memory-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: memory-demo-ctr
|
||||
image: vish/stress
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
requests:
|
||||
memory: "100Mi"
|
||||
args:
|
||||
- -mem-total
|
||||
- 150Mi
|
||||
- -mem-alloc-size
|
||||
- 10Mi
|
||||
- -mem-alloc-sleep
|
||||
- 1s
|
||||
@@ -0,0 +1,13 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: qos-demo-2
|
||||
spec:
|
||||
containers:
|
||||
- name: qos-demo-2-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
requests:
|
||||
memory: "100Mi"
|
||||
@@ -0,0 +1,8 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: qos-demo-3
|
||||
spec:
|
||||
containers:
|
||||
- name: qos-demo-3-ctr
|
||||
image: nginx
|
||||
@@ -0,0 +1,15 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: qos-demo-4
|
||||
spec:
|
||||
containers:
|
||||
|
||||
- name: qos-demo-4-ctr-1
|
||||
image: nginx
|
||||
resources:
|
||||
requests:
|
||||
memory: "200Mi"
|
||||
|
||||
- name: qos-demo-4-ctr-2
|
||||
image: redis
|
||||
@@ -0,0 +1,15 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: qos-demo
|
||||
spec:
|
||||
containers:
|
||||
- name: qos-demo-ctr
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "200Mi"
|
||||
cpu: "700m"
|
||||
requests:
|
||||
memory: "200Mi"
|
||||
cpu: "700m"
|
||||
@@ -0,0 +1,265 @@
|
||||
---
|
||||
title: Configure Quality of Service for Pods
|
||||
---
|
||||
|
||||
|
||||
{% capture overview %}
|
||||
|
||||
This page shows how to configure Pods so that they will be assigned particular
|
||||
Quality of Service (QoS) classes. Kubernetes uses QoS classes to make decisions about
|
||||
scheduling and evicting Pods.
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture prerequisites %}
|
||||
|
||||
{% include task-tutorial-prereqs.md %}
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% capture steps %}
|
||||
|
||||
## QoS classes
|
||||
|
||||
When Kubernetes creates a Pod it assigns one of these QoS classes to the Pod:
|
||||
|
||||
* Guaranteed
|
||||
* Burstable
|
||||
* BestEffort
|
||||
|
||||
## Create a namespace
|
||||
|
||||
Create a namespace so that the resources you create in this exercise are
|
||||
isolated from the rest of your cluster.
|
||||
|
||||
```shell
|
||||
kubectl create namespace qos-example
|
||||
```
|
||||
|
||||
## Create a Pod that gets assigned a QoS class of Guaranteed
|
||||
|
||||
For a Pod to be given a QoS class of Guaranteed:
|
||||
|
||||
* Every Container in the Pod must have a memory limit and a memory request, and they must be the same.
|
||||
* Every Container in the Pod must have a cpu limit and a cpu request, and they must be the same.
|
||||
|
||||
Here is the configuration file for a Pod that has one Container. The Container has a memory limit and a
|
||||
memory request, both equal to 200 MiB. The Container has a cpu limit and a cpu request, both equal to 700 millicpu:
|
||||
|
||||
{% include code.html language="yaml" file="qos-pod.yaml" ghlink="/docs/tasks/configure-pod-container/qos-pod.yaml" %}
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/qos-pod.yaml --namespace=qos-example
|
||||
```
|
||||
|
||||
View detailed information about the Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pod qos-demo --namespace=qos-example --output=yaml
|
||||
```
|
||||
|
||||
The output shows that Kubernetes gave the Pod a QoS class of Guaranteed. The output also
|
||||
verifies that the Pod's Container has a memory request that matches its memory limit, and it has
|
||||
a cpu request that matches its cpu limit.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
...
|
||||
resources:
|
||||
limits:
|
||||
cpu: 700m
|
||||
memory: 200Mi
|
||||
requests:
|
||||
cpu: 700m
|
||||
memory: 200Mi
|
||||
...
|
||||
qosClass: Guaranteed
|
||||
```
|
||||
|
||||
**Note**: If a Container specifies its own memory limit, but does not specify a memory request, Kubernetes
|
||||
automatically assigns a memory request that matches the limit. Similarly, if a Container specifies its own
|
||||
cpu limit, but does not specify a cpu request, Kubernetes automatically assigns a cpu request that matches
|
||||
the limit.
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod qos-demo --namespace=qos-example
|
||||
```
|
||||
|
||||
## Create a Pod that gets assigned a QoS class of Burstable
|
||||
|
||||
A Pod is given a QoS class of Burstable if:
|
||||
|
||||
* The Pod does not meet the criteria for QoS class Guaranteed.
|
||||
* At least one Container in the Pod has a memory or cpu request.
|
||||
|
||||
Here is the configuration file for a Pod that has one Container. The Container has a memory limit of 200 MiB
|
||||
and a memory request of 100 MiB.
|
||||
|
||||
{% include code.html language="yaml" file="qos-pod-2.yaml" ghlink="/docs/tasks/configure-pod-container/qos-pod-2.yaml" %}
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/qos-pod-2.yaml --namespace=qos-example
|
||||
```
|
||||
|
||||
View detailed information about the Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml
|
||||
```
|
||||
|
||||
The output shows that Kubernetes gave the Pod a QoS class of Burstable.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
- image: nginx
|
||||
imagePullPolicy: Always
|
||||
name: qos-demo-2-ctr
|
||||
resources:
|
||||
limits:
|
||||
memory: 200Mi
|
||||
requests:
|
||||
memory: 100Mi
|
||||
...
|
||||
qosClass: Burstable
|
||||
```
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod qos-demo-2 --namespace=qos-example
|
||||
```
|
||||
|
||||
## Create a Pod that gets assigned a QoS class of BestEffort
|
||||
|
||||
For a Pod to be given a QoS class of BestEffort, the Containers in the Pod must not
|
||||
have any memory or cpu limits or requests.
|
||||
|
||||
Here is the configuration file for a Pod that has one Container. The Container has no memory or cpu
|
||||
limits or requests:
|
||||
|
||||
{% include code.html language="yaml" file="qos-pod-3.yaml" ghlink="/docs/tasks/configure-pod-container/qos-pod-3.yaml" %}
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/qos-pod-3.yaml --namespace=qos-example
|
||||
```
|
||||
|
||||
View detailed information about the Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml
|
||||
```
|
||||
|
||||
The output shows that Kubernetes gave the Pod a QoS class of BestEffort.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
...
|
||||
resources: {}
|
||||
...
|
||||
qosClass: BestEffort
|
||||
```
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod qos-demo-3 --namespace=qos-example
|
||||
```
|
||||
|
||||
## Create a Pod that has two Containers
|
||||
|
||||
Here is the configuration file for a Pod that has two Containers. One container specifies a memory
|
||||
request of 200 MiB. The other Container does not specify any requests or limits.
|
||||
|
||||
{% include code.html language="yaml" file="qos-pod-4.yaml" ghlink="/docs/tasks/configure-pod-container/qos-pod-4.yaml" %}
|
||||
|
||||
Notice that this Pod meets the criteria for QoS class Burstable. That is, it does not meet the
|
||||
criteria for QoS class Guaranteed, and one of its Containers has a memory request.
|
||||
|
||||
Create the Pod:
|
||||
|
||||
```shell
|
||||
kubectl create -f https://k8s.io/docs/tasks/configure-pod-container/qos-pod-4.yaml --namespace=qos-example
|
||||
```
|
||||
|
||||
View detailed information about the Pod:
|
||||
|
||||
```shell
|
||||
kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml
|
||||
```
|
||||
|
||||
The output shows that Kubernetes gave the Pod a QoS class of Burstable:
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
containers:
|
||||
...
|
||||
name: qos-demo-4-ctr-1
|
||||
resources:
|
||||
requests:
|
||||
memory: 200Mi
|
||||
...
|
||||
name: qos-demo-4-ctr-2
|
||||
resources: {}
|
||||
...
|
||||
qosClass: Burstable
|
||||
```
|
||||
|
||||
Delete your Pod:
|
||||
|
||||
```shell
|
||||
kubectl delete pod qos-demo-4 --namespace=qos-example
|
||||
```
|
||||
|
||||
## Clean up
|
||||
|
||||
Delete your namespace:
|
||||
|
||||
```shell
|
||||
kubectl delete namespace qos-example
|
||||
```
|
||||
|
||||
{% endcapture %}
|
||||
|
||||
{% capture whatsnext %}
|
||||
|
||||
|
||||
### For app developers
|
||||
|
||||
* [Assign Memory Resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/)
|
||||
|
||||
* [Assign CPU Resources to Containers and Pods](docs/tasks/configure-pod-container/assign-cpu-resource/)
|
||||
|
||||
### For cluster administrators
|
||||
|
||||
* [Configure Default Memory Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-memory-request-limit/)
|
||||
|
||||
* [Configure Default CPU Requests and Limits for a Namespace](docs/tasks/administer-cluster/default-cpu-request-limit/)
|
||||
|
||||
* [Configure Minimum and Maximum Memory Constraints for a Namespace](/docs/tasks/administer-cluster/memory-constraint-namespace/)
|
||||
|
||||
* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/cpu-constraint-namespace/)
|
||||
|
||||
* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/quota-memory-cpu-namespace/)
|
||||
|
||||
* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/quota-pod-namespace/)
|
||||
|
||||
* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/)
|
||||
{% endcapture %}
|
||||
|
||||
|
||||
{% include templates/task.md %}
|
||||
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: ResourceQuota
|
||||
metadata:
|
||||
name: best-effort
|
||||
spec:
|
||||
hard:
|
||||
pods: "10"
|
||||
scopes:
|
||||
- BestEffort
|
||||
@@ -1,13 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: ResourceQuota
|
||||
metadata:
|
||||
name: not-best-effort
|
||||
spec:
|
||||
hard:
|
||||
pods: "4"
|
||||
requests.cpu: "1"
|
||||
requests.memory: 1Gi
|
||||
limits.cpu: "2"
|
||||
limits.memory: 2Gi
|
||||
scopes:
|
||||
- NotBestEffort
|
||||
@@ -1,9 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: ResourceQuota
|
||||
metadata:
|
||||
name: object-counts
|
||||
spec:
|
||||
hard:
|
||||
persistentvolumeclaims: "2"
|
||||
services.loadbalancers: "2"
|
||||
services.nodeports: "0"
|
||||
@@ -1,14 +0,0 @@
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: valid-pod
|
||||
labels:
|
||||
name: valid-pod
|
||||
spec:
|
||||
containers:
|
||||
- name: kubernetes-serve-hostname
|
||||
image: gcr.io/google_containers/serve_hostname
|
||||
resources:
|
||||
limits:
|
||||
cpu: "1"
|
||||
memory: 512Mi
|
||||
Reference in New Issue
Block a user