diff --git a/content/es/docs/concepts/configuration/manage-resources-containers.md b/content/es/docs/concepts/configuration/manage-resources-containers.md new file mode 100644 index 0000000000..f936b9107e --- /dev/null +++ b/content/es/docs/concepts/configuration/manage-resources-containers.md @@ -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. +--- + + + +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. + + + + + + +## 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-` +* `spec.containers[].resources.requests.cpu` +* `spec.containers[].resources.requests.memory` +* `spec.containers[].resources.requests.hugepages-` + +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 (226 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. + {{}} + +- 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-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":"", + "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