[es] Add content/es/docs/concepts/configuration/manage-resources-containers.md (#25920)
* content/es/docs/concepts/configuration/manage-resources-containers.md * Apply review comment Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Apply suggestions Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Rael Garcia <rael@rael.io> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update content/es/docs/concepts/configuration/manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> * Update manage-resources-containers.md Co-authored-by: Victor Morales <chipahuac@hotmail.com> Co-authored-by: Rael Garcia <rael@rael.io>
This commit is contained in:
Anynou
GitHub
parent
b41a02de59
commit
5685768847
|
|
@ -0,0 +1,757 @@
|
||||||
|
---
|
||||||
|
title: Administrando los recursos de los contenedores
|
||||||
|
content_type: concept
|
||||||
|
weight: 40
|
||||||
|
feature:
|
||||||
|
title: Bin packing automático
|
||||||
|
description: >
|
||||||
|
Coloca los contenedores automáticamente en base a los recursos solicitados y otras limitaciones, mientras no se afecte la
|
||||||
|
disponibilidad. Combina cargas críticas y best-effort para mejorar el uso y ahorrar recursos.
|
||||||
|
---
|
||||||
|
|
||||||
|
<!-- overview -->
|
||||||
|
|
||||||
|
Cuando especificas un {{< glossary_tooltip term_id="pod" >}}, opcionalmente puedes especificar
|
||||||
|
los recursos que necesita un {{< glossary_tooltip text="Contenedor" term_id="container" >}}.
|
||||||
|
Los recursos que normalmente se definen son CPU y memoria (RAM); pero hay otros.
|
||||||
|
|
||||||
|
Cuando especificas el recurso _request_ para Contenedores en un {{< glossary_tooltip term_id="pod" >}},
|
||||||
|
el {{< glossary_tooltip text="Scheduler de Kubernetes " term_id="kube-scheduler" >}} usa esta información para decidir en qué nodo colocar el {{< glossary_tooltip term_id="pod" >}}.
|
||||||
|
Cuando especificas el recurso _limit_ para un Contenedor, Kubelet impone estos límites, así que el contenedor no
|
||||||
|
puede utilizar más recursos que el límite que le definimos. Kubelet también reserva al menos la cantidad
|
||||||
|
especificada en _request_ para el contenedor.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
<!-- body -->
|
||||||
|
|
||||||
|
## Peticiones y límites
|
||||||
|
|
||||||
|
Si el nodo donde está corriendo un pod tiene suficientes recursos disponibles, es posible
|
||||||
|
(y válido) que el {{< glossary_tooltip text="contenedor" term_id="container" >}} utilice más recursos de los especificados en `request`.
|
||||||
|
Sin embargo, un {{< glossary_tooltip text="contenedor" term_id="container" >}} no está autorizado a utilizar más de lo especificado en `limit`.
|
||||||
|
|
||||||
|
Por ejemplo, si configuras una petición de `memory` de 256 MiB para un {{< glossary_tooltip text="contenedor" term_id="container" >}}, y ese contenedor está
|
||||||
|
en un {{< glossary_tooltip term_id="pod" >}} colocado en un nodo con 8GiB de memoria y no hay otros {{< glossary_tooltip term_id="pod" >}}, entonces el contenedor puede intentar usar
|
||||||
|
más RAM.
|
||||||
|
|
||||||
|
Si configuras un límite de `memory` de 4GiB para el contenedor, {{< glossary_tooltip text="kubelet" term_id="kubelet" >}})
|
||||||
|
(y
|
||||||
|
{{< glossary_tooltip text="motor de ejecución del contenedor" term_id="container-runtime" >}}) impone el límite.
|
||||||
|
El Runtime evita que el {{< glossary_tooltip text="contenedor" term_id="container" >}} use más recursos de los configurados en el límite. Por ejemplo:
|
||||||
|
cuando un proceso en el {{< glossary_tooltip text="contenedor" term_id="container" >}} intenta consumir más cantidad de memoria de la permitida,
|
||||||
|
el Kernel del sistema termina el proceso que intentó la utilización de la memoria, con un error de out of memory (OOM).
|
||||||
|
|
||||||
|
Los límites se pueden implementar de forma reactiva (el sistema interviene cuando ve la violación)
|
||||||
|
o por imposición (el sistema previene al contenedor de exceder el límite). Diferentes Runtimes pueden tener distintas
|
||||||
|
implementaciones a las mismas restricciones.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Si un contenedor especifica su propio límite de memoria, pero no especifica la petición de memoria, Kubernetes
|
||||||
|
automáticamente asigna una petición de memoria igual a la del límite. De igual manera, si un contenedor especifica su propio límite de CPU, pero no especifica una petición de CPU, Kubernetes automáticamente asigna una petición de CPU igual a la especificada en el límite.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
## Tipos de recursos
|
||||||
|
|
||||||
|
*CPU* y *memoria* son cada uno un *tipo de recurso*. Un tipo de recurso tiene una unidad base.
|
||||||
|
CPU representa procesos de computación y es especificada en unidades de [Kubernetes CPUs](#meaning-of-cpu).
|
||||||
|
Memoria es especificada en unidades de bytes.
|
||||||
|
Si estás usando Kubernetes v1.14 o posterior, puedes especificar recursos _huge page_.
|
||||||
|
Huge pages son una característica de Linux específica donde el kernel del nodo asigna bloques
|
||||||
|
de memoria que son más grandes que el tamaño de paginación por defecto.
|
||||||
|
|
||||||
|
Por ejemplo, en un sistema donde el tamaño de paginación por defecto es de 4KiB, podrías
|
||||||
|
especificar un límite, `hugepages-2Mi: 80Mi`. Si el contenedor intenta asignar
|
||||||
|
más de 40 2MiB huge pages (un total de 80 MiB), la asignación fallará.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
No se pueden sobreasignar recursos `hugepages-*`.
|
||||||
|
A diferencia de los recursos de `memoria` y `cpu`.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
CPU y memoria son colectivamente conocidos como *recursos de computación*, o simplemente como
|
||||||
|
*recursos*. Los recursos de computación son cantidades medibles que pueden ser solicitadas, asignadas
|
||||||
|
y consumidas. Son distintas a los [Recursos API](/docs/concepts/overview/kubernetes-api/). Los recursos API , como {{< glossary_tooltip text="Pods" term_id="pod" >}} y
|
||||||
|
[Services](/docs/concepts/services-networking/service/) son objetos que pueden ser leídos y modificados
|
||||||
|
a través de la API de Kubernetes.
|
||||||
|
|
||||||
|
## Peticiones y límites de recursos de Pods y Contenedores
|
||||||
|
|
||||||
|
Cada contenedor de un Pod puede especificar uno o más de los siguientes:
|
||||||
|
|
||||||
|
* `spec.containers[].resources.limits.cpu`
|
||||||
|
* `spec.containers[].resources.limits.memory`
|
||||||
|
* `spec.containers[].resources.limits.hugepages-<size>`
|
||||||
|
* `spec.containers[].resources.requests.cpu`
|
||||||
|
* `spec.containers[].resources.requests.memory`
|
||||||
|
* `spec.containers[].resources.requests.hugepages-<size>`
|
||||||
|
|
||||||
|
Aunque las peticiones y límites pueden ser especificadas solo en contenedores individuales, es conveniente hablar
|
||||||
|
sobre los recursos de peticiones y límites del Pod. Un *limite/petición
|
||||||
|
de recursos de un Pod* para un tipo de recurso particular es la suma de
|
||||||
|
peticiones/límites de cada tipo para cada contenedor del Pod.
|
||||||
|
|
||||||
|
## Unidades de recursos en Kubernetes
|
||||||
|
|
||||||
|
### Significado de CPU
|
||||||
|
|
||||||
|
Límites y peticiones para recursos de CPU son medidos en unidades de *cpu*.
|
||||||
|
Una cpu, en Kubernetes, es equivalente a **1 vCPU/Core** para proveedores de cloud y **1 hyperthread** en procesadores bare-metal Intel.
|
||||||
|
|
||||||
|
Las peticiones fraccionadas están permitidas. Un contenedor con `spec.containers[].resources.requests.cpu` de `0.5` tiene garantizada la mitad, tanto
|
||||||
|
CPU como otro que requiere 1 CPU. La expresión `0.1` es equivalente a la expresión `100m`, que puede ser leída como "cien millicpus". Algunas personas dicen
|
||||||
|
"cienmilicores", y se entiende que quiere decir lo mismo. Una solicitud con un punto decimal, como `0.1`, es convertido a `100m` por la API, y no se permite
|
||||||
|
una precisión mayor que `1m`. Por esta razón, la forma `100m` es la preferente.
|
||||||
|
CPU es siempre solicitada como una cantidad absoluta, nunca como una cantidad relativa;
|
||||||
|
0.1 es la misma cantidad de cpu que un core-simple, dual-core, o máquina de 48-core.
|
||||||
|
|
||||||
|
### Significado de memoria
|
||||||
|
|
||||||
|
Los límites y peticiones de `memoria` son medidos en bytes. Puedes expresar la memoria como
|
||||||
|
un número entero o como un número decimal usando alguno de estos sufijos:
|
||||||
|
E, P, T, G, M, K. También puedes usar los equivalentes en potencia de dos: Ei, Pi, Ti, Gi,
|
||||||
|
Mi, Ki. Por ejemplo, los siguientes valores representan lo mismo:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
128974848, 129e6, 129M, 123Mi
|
||||||
|
```
|
||||||
|
|
||||||
|
Aquí un ejemplo.
|
||||||
|
El siguiente {{< glossary_tooltip text="Pod" term_id="pod" >}} tiene dos contenedores. Cada contenedor tiene una petición de 0.25 cpu
|
||||||
|
y 64MiB (2<sup>26</sup> bytes) de memoria. Cada contenedor tiene un límite de 0.5 cpu
|
||||||
|
y 128MiB de memoria. Puedes decirle al Pod que solicite 0.5 cpu y 128MiB de memoria
|
||||||
|
y un límite de 1 cpu y 256MiB de memoria.
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Pod
|
||||||
|
metadata:
|
||||||
|
name: frontend
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: app
|
||||||
|
image: images.my-company.example/app:v4
|
||||||
|
resources:
|
||||||
|
requests:
|
||||||
|
memory: "64Mi"
|
||||||
|
cpu: "250m"
|
||||||
|
limits:
|
||||||
|
memory: "128Mi"
|
||||||
|
cpu: "500m"
|
||||||
|
- name: log-aggregator
|
||||||
|
image: images.my-company.example/log-aggregator:v6
|
||||||
|
resources:
|
||||||
|
requests:
|
||||||
|
memory: "64Mi"
|
||||||
|
cpu: "250m"
|
||||||
|
limits:
|
||||||
|
memory: "128Mi"
|
||||||
|
cpu: "500m"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Cómo son programados los Pods con solicitudes de recursos
|
||||||
|
|
||||||
|
Cuando creas un {{< glossary_tooltip text="Pod" term_id="pod" >}}, el {{< glossary_tooltip text="planificador de Kubernetes " term_id="kube-scheduler" >}} determina el nodo para correr dicho {{< glossary_tooltip text="Pod" term_id="pod" >}}.
|
||||||
|
Cada nodo tiene una capacidad máxima para cada tipo de recurso:
|
||||||
|
la cantidad de CPU y memoria que dispone para los Pods. El {{< glossary_tooltip text="planificador de Kubernetes" term_id="kube-scheduler" >}} se asegura de que,
|
||||||
|
para cada tipo de recurso, la suma de los recursos solicitados de los contenedores programados sea menor a la capacidad del nodo. Cabe mencionar que aunque la memoria actual o CPU
|
||||||
|
en uso de los nodos sea muy baja, el {{< glossary_tooltip text="planificador" term_id="kube-scheduler" >}} todavía rechaza programar un {{< glossary_tooltip text="Pod" term_id="pod" >}} en un nodo si
|
||||||
|
la comprobación de capacidad falla. Esto protege contra escasez de recursos en un nodo
|
||||||
|
cuando el uso de recursos posterior crece, por ejemplo, durante un pico diario de
|
||||||
|
solicitud de recursos.
|
||||||
|
|
||||||
|
## Cómo corren los Pods con límites de recursos
|
||||||
|
|
||||||
|
Cuando el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} inicia un {{< glossary_tooltip text="contenedor" term_id="container" >}} de un {{< glossary_tooltip text="Pod" term_id="pod" >}}, este pasa los límites de CPU y
|
||||||
|
memoria al {{< glossary_tooltip text="runtime del contenedor" term_id="container-runtime" >}}.
|
||||||
|
|
||||||
|
Cuando usas Docker:
|
||||||
|
|
||||||
|
- El `spec.containers[].resources.requests.cpu` es convertido a su valor interno,
|
||||||
|
el cuál es fraccional, y multiplicado por 1024. El mayor valor de este número o
|
||||||
|
2 es usado por el valor de
|
||||||
|
[`--cpu-shares`](https://docs.docker.com/engine/reference/run/#cpu-share-constraint)
|
||||||
|
en el comando `docker run`.
|
||||||
|
|
||||||
|
- El `spec.containers[].resources.limits.cpu` se convierte a su valor en milicore y
|
||||||
|
multiplicado por 100. El resultado es el tiempo total de CPU que un contenedor puede usar
|
||||||
|
cada 100ms. Un contenedor no puede usar más tiempo de CPU que del solicitado durante este intervalo.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
El período por defecto es de 100ms. La resolución mínima de cuota mínima es 1ms.
|
||||||
|
{{</ note >}}
|
||||||
|
|
||||||
|
- El `spec.containers[].resources.limits.memory` se convierte a entero, y
|
||||||
|
se usa como valor de
|
||||||
|
[`--memory`](https://docs.docker.com/engine/reference/run/#/user-memory-constraints)
|
||||||
|
del comando `docker run`.
|
||||||
|
|
||||||
|
Si el {{< glossary_tooltip text="contenedor" term_id="container" >}} excede su límite de memoria, este quizá se detenga. Si es reiniciable,
|
||||||
|
el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} lo reiniciará, así como cualquier otro error.
|
||||||
|
|
||||||
|
Si un Contenedor excede su petición de memoria, es probable que ese Pod sea
|
||||||
|
desalojado en cualquier momento que el nodo se quede sin memoria.
|
||||||
|
|
||||||
|
Un Contenedor puede o no tener permitido exceder el límite de CPU por
|
||||||
|
algunos períodos de tiempo. Sin embargo, esto no lo destruirá por uso excesivo de CPU.
|
||||||
|
|
||||||
|
Para conocer cuando un Contenedor no puede ser programado o será destruido debido a
|
||||||
|
límite de recursos, revisa la sección de [Troubleshooting](#troubleshooting).
|
||||||
|
|
||||||
|
### Monitorización del uso de recursos de computación y memoria.
|
||||||
|
|
||||||
|
El uso de recursos de un Pod es reportado como parte del estado del Pod.
|
||||||
|
|
||||||
|
Si [herramientas opcionales para monitorización](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
|
||||||
|
están disponibles en tu cluster, entonces el uso de recursos del Pod puede extraerse directamente de
|
||||||
|
[Métricas API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
|
||||||
|
o desde tus herramientas de monitorización.
|
||||||
|
|
||||||
|
## Almacenamiento local efímero
|
||||||
|
|
||||||
|
<!-- feature gate LocalStorageCapacityIsolation -->
|
||||||
|
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||||
|
|
||||||
|
Los nodos tienen almacenamiento local efímero, respaldado por
|
||||||
|
dispositivos de escritura agregados o, a veces, por RAM.
|
||||||
|
"Efímero" significa que no se garantiza la durabilidad a largo plazo.
|
||||||
|
.
|
||||||
|
Los Pods usan el almacenamiento local efímero para añadir espacio, caché, y para logs.
|
||||||
|
Kubelet puede proveer espacio añadido a los Pods usando almacenamiento local efímero para
|
||||||
|
montar [`emptyDir`](/docs/concepts/storage/volumes/#emptydir)
|
||||||
|
{{< glossary_tooltip term_id="volume" text="volumes" >}} en los contenedores.
|
||||||
|
|
||||||
|
Kubelet también usa este tipo de almacenamiento para guardar
|
||||||
|
[logs de contenedores a nivel de nodo](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level),
|
||||||
|
imágenes de contenedores, y la capa de escritura de los contenedores.
|
||||||
|
|
||||||
|
{{< caution >}}
|
||||||
|
Si un nodo falla, los datos en el almacenamiento efímero se pueden perder.
|
||||||
|
Tus aplicaciones no pueden esperar ningun SLA (IOPS de disco, por ejemplo)
|
||||||
|
del almacenamiento local efímero.
|
||||||
|
{{< /caution >}}
|
||||||
|
|
||||||
|
Como característica beta, Kubernetes te deja probar, reservar y limitar la cantidad
|
||||||
|
de almacenamiento local efímero que un Pod puede consumir.
|
||||||
|
|
||||||
|
### Configuraciones para almacenamiento local efímero
|
||||||
|
|
||||||
|
Kubernetes soporta 2 maneras de configurar el almacenamiento local efímero en un nodo:
|
||||||
|
{{< tabs name="local_storage_configurations" >}}
|
||||||
|
{{% tab name="Single filesystem" %}}
|
||||||
|
En esta configuración, colocas todos los tipos de datos (`emptyDir` volúmenes, capa de escritura,
|
||||||
|
imágenes de contenedores, logs) en un solo sistema de ficheros.
|
||||||
|
La manera más efectiva de configurar Kubelet es dedicando este sistema de archivos para los datos de Kubernetes (kubelet).
|
||||||
|
|
||||||
|
Kubelet también escribe
|
||||||
|
[logs de contenedores a nivel de nodo](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
|
||||||
|
y trata estos de manera similar al almacenamiento efímero.
|
||||||
|
|
||||||
|
Kubelet escribe logs en ficheros dentro del directorio de logs (por defecto `/var/log`
|
||||||
|
); y tiene un directorio base para otros datos almacenados localmente
|
||||||
|
(`/var/lib/kubelet` por defecto).
|
||||||
|
|
||||||
|
Por lo general, `/var/lib/kubelet` y `/var/log` están en el sistema de archivos de root,
|
||||||
|
y Kubelet es diseñado con ese objetivo en mente.
|
||||||
|
|
||||||
|
Tu nodo puede tener tantos otros sistema de archivos, no usados por Kubernetes,
|
||||||
|
como quieras.
|
||||||
|
{{% /tab %}}
|
||||||
|
{{% tab name="Two filesystems" %}}
|
||||||
|
Tienes un sistema de archivos en el nodo que estás usando para datos efímeros que
|
||||||
|
provienen de los Pods corriendo: logs, y volúmenes `emptyDir`.
|
||||||
|
Puedes usar este sistema de archivos para otros datos (por ejemplo: logs del sistema no relacionados
|
||||||
|
con Kubernetes); estos pueden ser incluso del sistema de archivos root.
|
||||||
|
|
||||||
|
Kubelet también escribe
|
||||||
|
[logs de contenedores a nivel de nodo](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
|
||||||
|
en el primer sistema de archivos, y trata estos de manera similar al almacenamiento efímero.
|
||||||
|
|
||||||
|
También usas un sistema de archivos distinto, respaldado por un dispositivo de almacenamiento lógico diferente.
|
||||||
|
En esta configuración, el directorio donde le dices a Kubelet que coloque
|
||||||
|
las capas de imágenes de los contenedores y capas de escritura es este segundo sistema de archivos.
|
||||||
|
|
||||||
|
El primer sistema de archivos no guarda ninguna capa de imágenes o de escritura.
|
||||||
|
|
||||||
|
Tu nodo puede tener tantos sistemas de archivos, no usados por Kubernetes, como quieras.
|
||||||
|
{{% /tab %}}
|
||||||
|
{{< /tabs >}}
|
||||||
|
|
||||||
|
Kubelet puede medir la cantidad de almacenamiento local que se está usando. Esto es posible por:
|
||||||
|
|
||||||
|
- el `LocalStorageCapacityIsolation`
|
||||||
|
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||||
|
está habilitado (esta caracterísitca está habilitada por defecto), y
|
||||||
|
- has configurado el nodo usando una de las configuraciones soportadas
|
||||||
|
para almacenamiento local efímero..
|
||||||
|
|
||||||
|
Si tienes una configuración diferente, entonces Kubelet no aplica límites de recursos
|
||||||
|
para almacenamiento local efímero.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Kubelet rastrea `tmpfs` volúmenes emptyDir como uso de memoria de contenedor, en lugar de
|
||||||
|
almacenamiento local efímero.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
### Configurando solicitudes y límites para almacenamiento local efímero
|
||||||
|
|
||||||
|
Puedes usar _ephemeral-storage_ para manejar almacenamiento local efímero. Cada contenedor de un Pod puede especificar
|
||||||
|
uno o más de los siguientes:
|
||||||
|
|
||||||
|
* `spec.containers[].resources.limits.ephemeral-storage`
|
||||||
|
* `spec.containers[].resources.requests.ephemeral-storage`
|
||||||
|
|
||||||
|
Los límites y solicitudes para `almacenamiento-efímero` son medidos en bytes. Puedes expresar el almacenamiento
|
||||||
|
como un numero entero o flotante usando los siguientes sufijos:
|
||||||
|
E, P, T, G, M, K. También puedes usar las siguientes equivalencias: Ei, Pi, Ti, Gi,
|
||||||
|
Mi, Ki. Por ejemplo, los siguientes representan el mismo valor:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
128974848, 129e6, 129M, 123Mi
|
||||||
|
```
|
||||||
|
|
||||||
|
En el siguiente ejemplo, el Pod tiene dos contenedores. Cada contenedor tiene una petición de 2GiB de almacenamiento local efímero. Cada
|
||||||
|
contenedor tiene un límite de 4GiB de almacenamiento local efímero. Sin embargo, el Pod tiene una petición de 4GiB de almacenamiento efímero
|
||||||
|
, y un límite de 8GiB de almacenamiento local efímero.
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Pod
|
||||||
|
metadata:
|
||||||
|
name: frontend
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: app
|
||||||
|
image: images.my-company.example/app:v4
|
||||||
|
resources:
|
||||||
|
requests:
|
||||||
|
ephemeral-storage: "2Gi"
|
||||||
|
limits:
|
||||||
|
ephemeral-storage: "4Gi"
|
||||||
|
- name: log-aggregator
|
||||||
|
image: images.my-company.example/log-aggregator:v6
|
||||||
|
resources:
|
||||||
|
requests:
|
||||||
|
ephemeral-storage: "2Gi"
|
||||||
|
limits:
|
||||||
|
ephemeral-storage: "4Gi"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Como son programados los Pods con solicitudes de almacenamiento efímero
|
||||||
|
|
||||||
|
Cuando creas un Pod, el planificador de Kubernetes selecciona un nodo para el Pod donde sera creado.
|
||||||
|
Cada nodo tiene una cantidad máxima de almacenamiento local efímero que puede proveer a los Pods. Para
|
||||||
|
más información, mira [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).
|
||||||
|
|
||||||
|
El planificador se asegura de que el total de los recursos solicitados para los contenedores sea menor que la capacidad del nodo.
|
||||||
|
|
||||||
|
### Manejo del consumo de almacenamiento efímero {#resource-emphemeralstorage-consumption}
|
||||||
|
|
||||||
|
Si Kubelet está manejando el almacenamiento efímero local como un recurso, entonces
|
||||||
|
Kubelet mide el uso de almacenamiento en:
|
||||||
|
|
||||||
|
- volúmenes `emptyDir`, excepto _tmpfs_ volúmenes`emptyDir`
|
||||||
|
- directorios que guardan logs de nivel de nodo
|
||||||
|
- capas de escritura de contenedores
|
||||||
|
|
||||||
|
Si un Pod está usando más almacenamiento efímero que el permitido, Kubelet
|
||||||
|
establece una señal de desalojo que desencadena el desalojo del Pod.
|
||||||
|
|
||||||
|
Para aislamiento a nivel de contenedor, si una capa de escritura del contenedor y
|
||||||
|
logs excede el límite de uso del almacenamiento, Kubelet marca el Pod para desalojo.
|
||||||
|
|
||||||
|
Para aislamiento a nivel de Pod, Kubelet calcula un límite de almacenamiento
|
||||||
|
general para el Pod sumando los límites de los contenedores de ese Pod.
|
||||||
|
En este caso, si la suma del uso de almacenamiento local efímero para todos los contenedores
|
||||||
|
y los volúmenes `emptyDir` de los Pods excede el límite de almacenamiento general del
|
||||||
|
Pod, Kubelet marca el Pod para desalojo.
|
||||||
|
|
||||||
|
{{< caution >}}
|
||||||
|
Si Kubelet no está midiendo el almacenamiento local efímero, entonces el Pod
|
||||||
|
que excede este límite de almacenamiento, no será desalojado para liberar
|
||||||
|
el límite del recurso de almacenamiento.
|
||||||
|
|
||||||
|
Sin embargo, si el espacio del sistema de archivos para la capa de escritura del contenedor,
|
||||||
|
logs a nivel de nodo o volúmenes `emptyDir` decae, el
|
||||||
|
{{< glossary_tooltip text="taints" term_id="taint" >}} del nodo lanza la desalojo para
|
||||||
|
cualquier Pod que no tolere dicho taint.
|
||||||
|
|
||||||
|
Mira las [configuraciones soportadas](#configurations-for-local-ephemeral-storage)
|
||||||
|
para almacenamiento local efímero.
|
||||||
|
{{< /caution >}}
|
||||||
|
|
||||||
|
Kubelet soporta diferentes maneras de medir el uso de almacenamiento del Pod:
|
||||||
|
|
||||||
|
|
||||||
|
{{< tabs name="resource-emphemeralstorage-measurement" >}}
|
||||||
|
{{% tab name="Periodic scanning" %}}
|
||||||
|
Kubelet realiza frecuentemente, verificaciones programadas que revisan cada
|
||||||
|
volumen `emptyDir`, directorio de logs del contenedor, y capa de escritura
|
||||||
|
del contenedor.
|
||||||
|
|
||||||
|
El escáner mide cuanto espacio está en uso.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
En este modo, Kubelet no rastrea descriptores de archivos abiertos
|
||||||
|
para archivos eliminados.
|
||||||
|
|
||||||
|
Si tú (o un contenedor) creas un archivo dentro de un volumen `emptyDir`,
|
||||||
|
y algo mas abre ese archivo, y tú lo borras mientras este está abierto,
|
||||||
|
entonces el inodo para este archivo borrado se mantiene hasta que cierras
|
||||||
|
el archivo, pero Kubelet no cataloga este espacio como en uso.
|
||||||
|
{{< /note >}}
|
||||||
|
{{% /tab %}}
|
||||||
|
{{% tab name="Filesystem project quota" %}}
|
||||||
|
|
||||||
|
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
|
||||||
|
|
||||||
|
Las cuotas de proyecto están definidas a nivel de sistema operativo
|
||||||
|
para el manejo de uso de almacenamiento en uso de sistema de archivos.
|
||||||
|
Con Kubernetes, puedes habilitar las cuotas de proyecto para el uso
|
||||||
|
de la monitorización del almacenamiento. Asegúrate que el respaldo del
|
||||||
|
Sistema de archivos de los volúmenes `emptyDir` , en el nodo, provee soporte de
|
||||||
|
cuotas de proyecto.
|
||||||
|
Por ejemplo, XFS y ext4fs ofrecen cuotas de proyecto.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Las cuotas de proyecto te permiten monitorear el uso del almacenamiento; no
|
||||||
|
fuerzan los límites.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
Kubernetes usa IDs de proyecto empezando por `1048576`. Los IDs en uso
|
||||||
|
son registrados en `/etc/projects` y `/etc/projid`. Si los IDs de proyecto
|
||||||
|
en este rango son usados para otros propósitos en el sistema, esos IDs
|
||||||
|
de proyecto deben ser registrados en `/etc/projects` y `/etc/projid` para
|
||||||
|
que Kubernetes no los use.
|
||||||
|
|
||||||
|
Las cuotas son más rápidas y más precisas que el escáner de directorios.
|
||||||
|
Cuando un directorio es asignado a un proyecto, todos los ficheros creados
|
||||||
|
bajo un directorio son creados en ese proyecto, y el kernel simplemente
|
||||||
|
tiene que mantener rastreados cuántos bloques están en uso por ficheros
|
||||||
|
en ese proyecto. Si un fichero es creado y borrado, pero tiene un fichero abierto,
|
||||||
|
continúa consumiendo espacio. El seguimiento de cuotas registra ese espacio
|
||||||
|
con precisión mientras que los escaneos de directorios pasan por alto
|
||||||
|
el almacenamiento utilizado por los archivos eliminados
|
||||||
|
|
||||||
|
Si quieres usar cuotas de proyecto, debes:
|
||||||
|
|
||||||
|
* Habilitar el `LocalStorageCapacityIsolationFSQuotaMonitoring=true`
|
||||||
|
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
|
||||||
|
en la configuración del kubelet.
|
||||||
|
|
||||||
|
* Asegúrese de que el sistema de archivos raíz (o el sistema de archivos en tiempo de ejecución opcional)
|
||||||
|
tiene las cuotas de proyectos habilitadas. Todos los sistemas de archivos XFS admiten cuotas de proyectos.
|
||||||
|
Para los sistemas de archivos ext4, debe habilitar la función de seguimiento de cuotas del proyecto
|
||||||
|
mientras el sistema de archivos no está montado.
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# For ext4, with /dev/block-device not mounted
|
||||||
|
sudo tune2fs -O project -Q prjquota /dev/block-device
|
||||||
|
```
|
||||||
|
|
||||||
|
* Asegúrese de que el sistema de archivos raíz (o el sistema de archivos de tiempo de ejecución opcional) esté
|
||||||
|
montado con cuotas de proyecto habilitadas. Tanto para XFS como para ext4fs, la opción de montaje
|
||||||
|
se llama `prjquota`.
|
||||||
|
|
||||||
|
{{% /tab %}}
|
||||||
|
{{< /tabs >}}
|
||||||
|
|
||||||
|
## Recursos extendidos
|
||||||
|
|
||||||
|
Los recursos extendidos son nombres de recursos calificados fuera del
|
||||||
|
dominio `kubernetes.io`. Permiten que los operadores de clústers publiciten y los usuarios
|
||||||
|
consuman los recursos no integrados de Kubernetes.
|
||||||
|
|
||||||
|
Hay dos pasos necesarios para utilizar los recursos extendidos. Primero, el operador del clúster
|
||||||
|
debe anunciar un Recurso Extendido. En segundo lugar, los usuarios deben solicitar
|
||||||
|
el Recurso Extendido en los Pods.
|
||||||
|
|
||||||
|
### Manejando recursos extendidos
|
||||||
|
|
||||||
|
#### Recursos extendido a nivel de nodo
|
||||||
|
|
||||||
|
Los recursos extendidos a nivel de nodo están vinculados a los nodos
|
||||||
|
|
||||||
|
##### Device plugin managed resources
|
||||||
|
Mira [Plugins de
|
||||||
|
Dispositivos](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
|
||||||
|
para percibir como los plugins de dispositivos manejan los recursos
|
||||||
|
en cada nodo.
|
||||||
|
|
||||||
|
##### Otros recursos
|
||||||
|
|
||||||
|
Para anunciar un nuevo recurso extendido a nivel de nodo, el operador del clúster puede
|
||||||
|
enviar una solicitud HTTP `PATCH` al servidor API para especificar la cantidad
|
||||||
|
disponible en el `status.capacity` para un nodo en el clúster. Después de esta
|
||||||
|
operación, el `status.capacity` del nodo incluirá un nuevo recurso. El campo
|
||||||
|
`status.allocatable` se actualiza automáticamente con el nuevo recurso
|
||||||
|
de forma asíncrona por el {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}. Tenga en cuenta que debido a que el {{< glossary_tooltip text="planificador" term_id="kube-scheduler" >}}
|
||||||
|
utiliza el valor de `status.allocatable` del nodo cuando evalúa la aptitud del {{< glossary_tooltip text="Pod" term_id="pod" >}}, puede haber un breve
|
||||||
|
retraso entre parchear la capacidad del nodo con un nuevo recurso y el primer Pod
|
||||||
|
que solicita el recurso en ese nodo.
|
||||||
|
|
||||||
|
**Ejemplo:**
|
||||||
|
|
||||||
|
Aquí hay un ejemplo que muestra cómo usar `curl` para formar una solicitud HTTP que
|
||||||
|
anuncia cinco recursos "example.com/foo" en el nodo `k8s-node-1` cuyo nodo master
|
||||||
|
es `k8s-master`.
|
||||||
|
|
||||||
|
```shell
|
||||||
|
curl --header "Content-Type: application/json-patch+json" \
|
||||||
|
--request PATCH \
|
||||||
|
--data '[{"op": "add", "path": "/status/capacity/example.com~1foo", "value": "5"}]' \
|
||||||
|
http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
|
||||||
|
```
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
En la solicitud anterior, `~ 1` es la codificación del carácter` / `
|
||||||
|
en la ruta del parche. El valor de la ruta de operación en JSON-Patch se interpreta como un
|
||||||
|
puntero JSON. Para obtener más detalles, consulte
|
||||||
|
[IETF RFC 6901, sección 3](https://tools.ietf.org/html/rfc6901#section-3).
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
#### Recursos extendidos a nivel de Clúster
|
||||||
|
|
||||||
|
Los recursos extendidos a nivel de clúster no están vinculados a los nodos. Suelen estar gestionados
|
||||||
|
por extensores del scheduler, que manejan el consumo de recursos y la cuota de recursos.
|
||||||
|
|
||||||
|
Puedes especificar los recursos extendidos que son mantenidos por los extensores del scheduler en
|
||||||
|
[configuración de políticas del scheduler](https://github.com/kubernetes/kubernetes/blob/release-1.10/pkg/scheduler/api/v1/types.go#L31).
|
||||||
|
|
||||||
|
**Ejemplo:**
|
||||||
|
|
||||||
|
La siguiente configuración para una política del scheduler indica que el
|
||||||
|
recurso extendido a nivel de clúster "example.com/foo" es mantenido
|
||||||
|
por el extensor del scheduler.
|
||||||
|
|
||||||
|
- El scheduler envía un Pod al extensor del scheduler solo si la solicitud del Pod "example.com/foo".
|
||||||
|
- El campo `ignoredByScheduler` especifica que el schduler no compruba el recurso
|
||||||
|
"example.com/foo" en su predicado `PodFitsResources`.
|
||||||
|
|
||||||
|
```json
|
||||||
|
{
|
||||||
|
"kind": "Policy",
|
||||||
|
"apiVersion": "v1",
|
||||||
|
"extenders": [
|
||||||
|
{
|
||||||
|
"urlPrefix":"<extender-endpoint>",
|
||||||
|
"bindVerb": "bind",
|
||||||
|
"managedResources": [
|
||||||
|
{
|
||||||
|
"name": "example.com/foo",
|
||||||
|
"ignoredByScheduler": true
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
]
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Consumiendo recursos extendidos
|
||||||
|
|
||||||
|
Los usuarios pueden consumir recursos extendidos en las especificaciones del Pod, como la CPU y la memoria.
|
||||||
|
El {{< glossary_tooltip text="planificador" term_id="kube-scheduler" >}} se encarga de la contabilidad de recursos para que no más de
|
||||||
|
la cantidad disponible sea asignada simultáneamente a los Pods.
|
||||||
|
|
||||||
|
El servidor de API restringe las cantidades de recursos extendidos a números enteros.
|
||||||
|
Ejemplos de cantidades _validas_ son `3`,` 3000m` y `3Ki`. Ejemplos de
|
||||||
|
_cantidades no válidas_ son `0.5` y` 1500m`.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Los recursos extendidos reemplazan los Recursos Integrales Opacos.
|
||||||
|
Los usuarios pueden usar cualquier otro prefijo de dominio que `kubernetes.io`
|
||||||
|
tenga reservado.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
Para consumir un recurso extendido en un Pod, incluye un nombre de recurso
|
||||||
|
como clave en `spec.containers[].resources.limits` en las especificaciones del contenedor.
|
||||||
|
|
||||||
|
{{< note >}}
|
||||||
|
Los Recursos Extendidos no pueden ser sobreescritos, así que solicitudes y límites
|
||||||
|
deben ser iguales si ambos están presentes en las especificaciones de un contenedor.
|
||||||
|
{{< /note >}}
|
||||||
|
|
||||||
|
Un pod se programa solo si se satisfacen todas las solicitudes de recursos, incluidas
|
||||||
|
CPU, memoria y cualquier recurso extendido. El {{< glossary_tooltip text="Pod" term_id="pod" >}} permanece en estado `PENDING`
|
||||||
|
siempre que no se pueda satisfacer la solicitud de recursos.
|
||||||
|
|
||||||
|
**Ejemplo:**
|
||||||
|
|
||||||
|
El siguiente {{< glossary_tooltip text="Pod" term_id="pod" >}} solicita 2CPUs y 1 "example.com/foo" (un recurso extendido).
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
apiVersion: v1
|
||||||
|
kind: Pod
|
||||||
|
metadata:
|
||||||
|
name: my-pod
|
||||||
|
spec:
|
||||||
|
containers:
|
||||||
|
- name: my-container
|
||||||
|
image: myimage
|
||||||
|
resources:
|
||||||
|
requests:
|
||||||
|
cpu: 2
|
||||||
|
example.com/foo: 1
|
||||||
|
limits:
|
||||||
|
example.com/foo: 1
|
||||||
|
```
|
||||||
|
|
||||||
|
## Solución de problemas
|
||||||
|
|
||||||
|
### Mis Pods están en estado pendiente con un mensaje de failedScheduling
|
||||||
|
|
||||||
|
Si el {{< glossary_tooltip text="planificador" term_id="kube-scheduler" >}} no puede encontrar ningún nodo donde pueda colocar un {{< glossary_tooltip text="Pod" term_id="pod" >}}, el {{< glossary_tooltip text="Pod" term_id="pod" >}} permanece
|
||||||
|
no programado hasta que se pueda encontrar un lugar. Se produce un evento cada vez que
|
||||||
|
el {{< glossary_tooltip text="planificador" term_id="kube-scheduler" >}} no encuentra un lugar para el {{< glossary_tooltip text="Pod" term_id="pod" >}}, como este:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl describe pod frontend | grep -A 3 Events
|
||||||
|
```
|
||||||
|
```
|
||||||
|
Events:
|
||||||
|
FirstSeen LastSeen Count From Subobject PathReason Message
|
||||||
|
36s 5s 6 {scheduler } FailedScheduling Failed for reason PodExceedsFreeCPU and possibly others
|
||||||
|
```
|
||||||
|
En el ejemplo anterior, el Pod llamado "frontend" no se puede programar debido a
|
||||||
|
recursos de CPU insuficientes en el nodo. Mensajes de error similares también pueden sugerir
|
||||||
|
fallo debido a memoria insuficiente (PodExceedsFreeMemory). En general, si un Pod
|
||||||
|
está pendiente con un mensaje de este tipo, hay varias cosas para probar:
|
||||||
|
|
||||||
|
- Añadir más nodos al clúster.
|
||||||
|
- Terminar Pods innecesarios para hacer hueco a los Pods en estado pendiente.
|
||||||
|
- Compruebe que el Pod no sea más grande que todos los nodos. Por ejemplo, si todos los
|
||||||
|
los nodos tienen una capacidad de `cpu: 1`, entonces un Pod con una solicitud de` cpu: 1.1`
|
||||||
|
nunca se programará.
|
||||||
|
|
||||||
|
Puedes comprobar las capacidades del nodo y cantidad utilizada con el comando
|
||||||
|
`kubectl describe nodes`. Por ejemplo:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl describe nodes e2e-test-node-pool-4lw4
|
||||||
|
```
|
||||||
|
```
|
||||||
|
Name: e2e-test-node-pool-4lw4
|
||||||
|
[ ... lines removed for clarity ...]
|
||||||
|
Capacity:
|
||||||
|
cpu: 2
|
||||||
|
memory: 7679792Ki
|
||||||
|
pods: 110
|
||||||
|
Allocatable:
|
||||||
|
cpu: 1800m
|
||||||
|
memory: 7474992Ki
|
||||||
|
pods: 110
|
||||||
|
[ ... lines removed for clarity ...]
|
||||||
|
Non-terminated Pods: (5 in total)
|
||||||
|
Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
|
||||||
|
--------- ---- ------------ ---------- --------------- -------------
|
||||||
|
kube-system fluentd-gcp-v1.38-28bv1 100m (5%) 0 (0%) 200Mi (2%) 200Mi (2%)
|
||||||
|
kube-system kube-dns-3297075139-61lj3 260m (13%) 0 (0%) 100Mi (1%) 170Mi (2%)
|
||||||
|
kube-system kube-proxy-e2e-test-... 100m (5%) 0 (0%) 0 (0%) 0 (0%)
|
||||||
|
kube-system monitoring-influxdb-grafana-v4-z1m12 200m (10%) 200m (10%) 600Mi (8%) 600Mi (8%)
|
||||||
|
kube-system node-problem-detector-v0.1-fj7m3 20m (1%) 200m (10%) 20Mi (0%) 100Mi (1%)
|
||||||
|
Allocated resources:
|
||||||
|
(Total limits may be over 100 percent, i.e., overcommitted.)
|
||||||
|
CPU Requests CPU Limits Memory Requests Memory Limits
|
||||||
|
------------ ---------- --------------- -------------
|
||||||
|
680m (34%) 400m (20%) 920Mi (11%) 1070Mi (13%)
|
||||||
|
```
|
||||||
|
|
||||||
|
EN la salida anterior, puedes ver si una solicitud de Pod mayor que 1120m
|
||||||
|
CPUs o 6.23Gi de memoria, no cabrán en el nodo.
|
||||||
|
|
||||||
|
Echando un vistazo a la sección `Pods`, puedes ver qué Pods están ocupando espacio
|
||||||
|
en el nodo.
|
||||||
|
|
||||||
|
La cantidad de recursos disponibles para los pods es menor que la capacidad del nodo, porque
|
||||||
|
los demonios del sistema utilizan una parte de los recursos disponibles. El campo `allocatable`
|
||||||
|
[NodeStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodestatus-v1-core)
|
||||||
|
indica la cantidad de recursos que están disponibles para los Pods. Para más información, mira
|
||||||
|
[Node Allocatable Resources](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md).
|
||||||
|
|
||||||
|
La característica [resource quota](/docs/concepts/policy/resource-quotas/) se puede configurar
|
||||||
|
para limitar la cantidad total de recursos que se pueden consumir. Si se usa en conjunto
|
||||||
|
con espacios de nombres, puede evitar que un equipo acapare todos los recursos.
|
||||||
|
|
||||||
|
### Mi contenedor está terminado
|
||||||
|
|
||||||
|
Es posible que su contenedor se cancele porque carece de recursos. Para verificar
|
||||||
|
si un contenedor está siendo eliminado porque está alcanzando un límite de recursos, ejecute
|
||||||
|
`kubectl describe pod` en el Pod de interés:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl describe pod simmemleak-hra99
|
||||||
|
```
|
||||||
|
```
|
||||||
|
Name: simmemleak-hra99
|
||||||
|
Namespace: default
|
||||||
|
Image(s): saadali/simmemleak
|
||||||
|
Node: kubernetes-node-tf0f/10.240.216.66
|
||||||
|
Labels: name=simmemleak
|
||||||
|
Status: Running
|
||||||
|
Reason:
|
||||||
|
Message:
|
||||||
|
IP: 10.244.2.75
|
||||||
|
Replication Controllers: simmemleak (1/1 replicas created)
|
||||||
|
Containers:
|
||||||
|
simmemleak:
|
||||||
|
Image: saadali/simmemleak
|
||||||
|
Limits:
|
||||||
|
cpu: 100m
|
||||||
|
memory: 50Mi
|
||||||
|
State: Running
|
||||||
|
Started: Tue, 07 Jul 2015 12:54:41 -0700
|
||||||
|
Last Termination State: Terminated
|
||||||
|
Exit Code: 1
|
||||||
|
Started: Fri, 07 Jul 2015 12:54:30 -0700
|
||||||
|
Finished: Fri, 07 Jul 2015 12:54:33 -0700
|
||||||
|
Ready: False
|
||||||
|
Restart Count: 5
|
||||||
|
Conditions:
|
||||||
|
Type Status
|
||||||
|
Ready False
|
||||||
|
Events:
|
||||||
|
FirstSeen LastSeen Count From SubobjectPath Reason Message
|
||||||
|
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {scheduler } scheduled Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
|
||||||
|
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD pulled Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
|
||||||
|
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD created Created with docker id 6a41280f516d
|
||||||
|
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} implicitly required container POD started Started with docker id 6a41280f516d
|
||||||
|
Tue, 07 Jul 2015 12:53:51 -0700 Tue, 07 Jul 2015 12:53:51 -0700 1 {kubelet kubernetes-node-tf0f} spec.containers{simmemleak} created Created with docker id 87348f12526a
|
||||||
|
```
|
||||||
|
|
||||||
|
En el ejemplo anterior, `Restart Count: 5` indica que el contenedor `simmemleak`
|
||||||
|
del Pod se reinició cinco veces.
|
||||||
|
|
||||||
|
Puedes ejecutar `kubectl get pod` con la opción `-o go-template=...` para extraer el estado
|
||||||
|
previos de los Contenedores terminados:
|
||||||
|
|
||||||
|
```shell
|
||||||
|
kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' simmemleak-hra99
|
||||||
|
```
|
||||||
|
```
|
||||||
|
Container Name: simmemleak
|
||||||
|
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]
|
||||||
|
```
|
||||||
|
|
||||||
|
Puedes ver que el Contenedor fué terminado a causa de `reason:OOM Killed`, donde `OOM` indica una falta de memoria.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## {{% heading "whatsnext" %}}
|
||||||
|
|
||||||
|
|
||||||
|
* Obtén experiencia práctica [assigning Memory resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/).
|
||||||
|
|
||||||
|
* Obtén experiencia práctica [assigning CPU resources to Containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/).
|
||||||
|
|
||||||
|
* Para más detalles sobre la diferencia entre solicitudes y límites, mira
|
||||||
|
[Resource QoS](https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md).
|
||||||
|
|
||||||
|
* Lee [Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) referencia de API
|
||||||
|
|
||||||
|
* Lee [ResourceRequirements](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcerequirements-v1-core) referencia de API
|
||||||
|
|
||||||
|
* Lee sobre [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) en XFS
|
||||||
Loading…
Reference in New Issue