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

Merge branch 'master' of github.com:kubernetes/website

Browse Source
This commit is contained in:
Leonardo Murillo
2021-03-19 09:10:29 +00:00
parent 06f1e784b8 d79edc1438
commit a94ff065fc
369 changed files with 9514 additions and 8068 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/es/docs/concepts/containers/runtime-class.md
+205
View File
@@ -0,0 +1,205 @@
---
reviewers:
title: RuntimeClass
content_type: concept
weight: 20
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.20" state="stable" >}}
Esta página describe el recurso RuntimeClass y el mecanismo de selección del
motor de ejecución.
RuntimeClass es una característica que permite seleccionar la configuración del
motor de ejecución para los contenedores. La configuración del motor de ejecución para
los contenedores se utiliza para ejecutar los contenedores de un Pod.
<!-- body -->
## Motivación
Se puede seleccionar un RuntimeClass diferente entre diferentes Pods para
proporcionar equilibrio entre rendimiento y seguridad. Por ejemplo, si parte de
la carga de trabajo requiere un alto nivel de garantía de seguridad, se podrían
planificar esos Pods para ejecutarse en un motor de ejecución que use
virtualización de hardware. Así se beneficiaría con un mayor aislamiento del motor
de ejecución alternativo, con el coste de alguna sobrecarga adicional.
También se puede utilizar el RuntimeClass para ejecutar distintos Pods con el
mismo motor de ejecución pero con distintos parámetros.
## Configuración
1. Configurar la implementación del CRI en los nodos (depende del motor de
ejecución)
2. Crear los recursos RuntimeClass correspondientes.
### 1. Configurar la implementación del CRI en los nodos
La configuración disponible utilizando RuntimeClass dependen de la
implementación de la Interfaz del Motor de ejecución de Containers (CRI). Véase
la sección [Configuración del CRI](#cri-configuration) para más
información sobre cómo configurar la implementación del CRI.
{{< note >}}
RuntimeClass por defecto asume una configuración de nodos homogénea para todo el
clúster (lo que significa que todos los nodos están configurados de la misma
forma para el motor de ejecución de los contenedores). Para soportar configuraciones
heterogéneas de nodos, véase [Planificación](#scheduling) más abajo.
{{< /note >}}
Las configuraciones tienen un nombre de `handler` (manipulador) correspondiente, referenciado
por la RuntimeClass. El `handler` debe ser una etiqueta DNS 1123 válida
(alfanumérico + caracter `-`).
### 2. Crear los recursos RuntimeClass correspondientes.
Cada configuración establecida en el paso 1 tiene un nombre de `handler`, que
identifica a dicha configuración. Para cada `handler`, hay que crear un objeto
RuntimeClass correspondiente.
Actualmente el recurso RuntimeClass sólo tiene dos campos significativos: el
nombre del RuntimeClass (`metadata.name`) y el `handler`. La
definición del objeto se parece a ésta:
```yaml
apiVersion: node.k8s.io/v1 # La RuntimeClass se define en el grupo node.k8s.io
kind: RuntimeClass
metadata:
name: myclass # Nombre por el que se referenciará la RuntimeClass
# no contiene espacio de nombres
handler: myconfiguration # El nombre de la configuración CRI correspondiente
```
El nombre de un objeto RuntimeClass debe ser un [nombre de subdominio
DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)
válido.
{{< note >}}
Se recomienda que las operaciones de escritura de la RuntimeClass
(creación/modificación/parcheo/elimiación) se restrinjan al administrador del
clúster. Habitualmente es el valor por defecto. Véase [Visión general de la
Autorización](/docs/reference/access-authn-authz/authorization/) para más
detalles.
{{< /note >}}
## Uso
Una vez se han configurado las RuntimeClasses para el clúster, el utilizarlas es
muy sencillo. Solo se especifica un `runtimeClassName` en la especificación del Pod.
Por ejemplo:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
runtimeClassName: myclass
# ...
```
Así se informa a Kubelet del nombre de la RuntimeClass a utilizar para
este pod. Si dicha RuntimeClass no existe, o el CRI no puede ejecutar el
`handler` correspondiente, el pod entrará en la
[fase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) final `Failed`.
Se puede buscar por el correspondiente
[evento](/docs/tasks/debug-application-cluster/debug-application-introspection/)
con el mensaje de error.
Si no se especifica ninguna `runtimeClassName`, se usará el RuntimeHandler por
defecto, lo que equivale al comportamiento cuando la opción RuntimeClass está
deshabilitada.
### Configuración del CRI
Para más detalles sobre cómo configurar los motores de ejecución del CRI, véase
[instalación del CRI](/docs/setup/production-environment/container-runtimes/).
#### dockershim
El CRI dockershim incorporado por Kubernetes no soporta manejadores del motor de
ejecución.
#### {{< glossary_tooltip term_id="containerd" >}}
Los `handlers` del motor de ejecución se configuran mediante la configuración
de containerd en `/etc/containerd/config.toml`. Los `handlers` válidos se
configuran en la sección de motores de ejecución:
```
[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
```
Véase la configuración de containerd para más detalles:
https://github.com/containerd/cri/blob/master/docs/config.md
#### {{< glossary_tooltip term_id="cri-o" >}}
Los `handlers` del motor de ejecución se configuran a través de la
configuración del CRI-O en `/etc/crio/crio.conf`. Los manejadores válidos se
configuran en la [tabla
crio.runtime](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table)
```
[crio.runtime.runtimes.${HANDLER_NAME}]
runtime_path = "${PATH_TO_BINARY}"
```
Véase la [documentación de la
configuración](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)
de CRI-O para más detalles.
## Planificación
{{< feature-state for_k8s_version="v1.16" state="beta" >}}
Especificando el campo `scheduling` en una RuntimeClass se pueden establecer
restricciones para asegurar que los Pods ejecutándose con dicha RuntimeClass se
planifican en los nodos que la soportan.
Para asegurar que los pods sean asignados en nodos que soportan una RuntimeClass
determinada, ese conjunto de nodos debe tener una etiqueta común que se
selecciona en el campo `runtimeclass.scheduling.nodeSelector`. El nodeSelector
de la RuntimeClass se combina con el nodeSelector del pod durante la admisión,
haciéndose efectiva la intersección del conjunto de nodos seleccionados por
ambos. Si hay conflicto, el pod se rechazará.
Si los nodos soportados se marcan para evitar que los pods con otra RuntimeClass
se ejecuten en el nodo, se pueden añadir `tolerations` al RuntimeClass. Igual
que con el `nodeSelector`, las tolerancias se mezclan con las tolerancias del
pod durante la admisión, haciéndose efectiva la unión del conjunto de nodos
tolerados por ambos.
Para saber más sobre configurar el selector de nodos y las tolerancias, véase
[Asignando Pods a Nodos](/docs/concepts/scheduling-eviction/assign-pod-node/).
### Sobrecarga del Pod
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
Se pueden especificar recursos de _sobrecarga_ adicional que se asocian a los
Pods que estén ejecutándose. Declarar la sobrecarga permite al clúster (incluido
el planificador) contabilizarlo al tomar decisiones sobre los Pods y los
recursos. Para utilizar la sobrecarga de pods, se debe haber habilitado la
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
PodOverhead (lo está por defecto).
La sobrecarga de pods se define en la RuntimeClass a través del los campos de
`overhead`. Con estos campos se puede especificar la sobrecarga de los pods en
ejecución que utilizan esta RuntimeClass para asegurar que estas sobrecargas se
cuentan en Kubernetes.
## {{% heading "whatsnext" %}}
- [Diseño de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
- [Diseño de programación de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
- Leer sobre el concepto de [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/)
- [Diseño de capacidad de PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
content/es/docs/concepts/policy/_index.md
+6 -2
View File
@@ -1,4 +1,8 @@
---
title: "Políticas"
title: Políticas
weight: 90
---
description: >
Políticas configurables que se aplican a grupos de recursos.
---
La sección de Políticas describe las diferentes políticas configurables que se aplican a grupos de recursos:
content/es/docs/concepts/policy/limit-range.md
+70
View File
@@ -0,0 +1,70 @@
---
reviewers:
- raelga
title: Rangos de límites (Limit Ranges)
description: >
Aplica límites de recursos a un Namespace para restringir y garantizar la asignación y consumo de recursos informáticos.
content_type: concept
weight: 10
---
<!-- overview -->
### Contexto
Por defecto, los contenedores se ejecutan sin restricciones sobre los [recursos informáticos disponibles en un clúster de Kubernetes](/docs/concepts/configuration/manage-resources-containers/).
Si el {{< glossary_tooltip text="Nodo" term_id="node" >}} dispone de los recursos informáticos, un {{< glossary_tooltip text="Pod" term_id="pod" >}} o sus {{< glossary_tooltip text="Contenedores" term_id="container" >}} tienen permitido consumir por encima de la cuota solicitada si no superan el límite establecido en su especificación.
Existe la preocupación de que un Pod o Contenedor pueda monopolizar todos los recursos disponibles.
### Utilidad
Aplicando restricciones de asignación de recursos, los administradores de clústeres se aseguran del cumplimiento del consumo de recursos por espacio de nombre ({{< glossary_tooltip text="Namespace" term_id="namespace" >}}).
Un **{{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}** es la política que permite:
- Imponer restricciones de requisitos de recursos a {{< glossary_tooltip text="Pods" term_id="pod" >}} o {{< glossary_tooltip text="Contenedores" term_id="container" >}} por Namespace.
- Imponer las limitaciones de recursos mínimas/máximas para Pods o Contenedores dentro de un Namespace.
- Especificar requisitos y límites de recursos predeterminados para Pods o Contenedores de un Namespace.
- Imponer una relación de proporción entre los requisitos y el límite de un recurso.
- Imponer el cumplimiento de las demandas de almacenamiento mínimo/máximo para {{< glossary_tooltip text="Solicitudes de Volúmenes Persistentes" term_id="persistent-volume-claim" >}}.
### Habilitar el LimitRange
La compatibilidad con LimitRange está habilitada por defecto en Kubernetes desde la versión 1.10.
Para que un LimitRange se active en un {{< glossary_tooltip text="Namespace" term_id="namespace" >}} en particular, el LimitRange debe definirse con el Namespace, o aplicarse a éste.
El nombre de recurso de un objeto LimitRange debe ser un
[nombre de subdominio DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) válido.
### Aplicando LimitRanges
- El administrador crea un LimitRange en un {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.
- Los usuarios crean recursos como {{< glossary_tooltip text="Pods" term_id="pod" >}}, {{< glossary_tooltip text="Contenedores" term_id="container" >}} o {{< glossary_tooltip text="Solicitudes de Volúmenes Persistentes" term_id="persistent-volume-claim" >}} en el Namespace.
- El controlador de admisión `LimitRanger` aplicará valores predeterminados y límites, para todos los Pods o Contenedores que no establezcan requisitos de recursos informáticos. Y realizará un seguimiento del uso para garantizar que no excedan el mínimo, el máximo, y la proporción de ningún LimitRange definido en el Namespace.
- Si al crear o actualizar un recurso del ejemplo (Pods, Contenedores, {{< glossary_tooltip text="Solicitudes de Volúmenes Persistentes" term_id="persistent-volume-claim" >}}) se viola una restricción al LimitRange, la solicitud al servidor API fallará con un código de estado HTTP "403 FORBIDDEN" y un mensaje que explica la restricción que se ha violado.
- En caso de que en se active un LimitRange para recursos de cómputos como `cpu` y `memory`, los usuarios deberán especificar los requisitos y/o límites de recursos a dichos valores. De lo contrario, el sistema puede rechazar la creación del Pod.
- Las validaciones de LimitRange ocurren solo en la etapa de Admisión de Pod, no en Pods que ya se han iniciado (Running {{< glossary_tooltip text="Pods" term_id="pod" >}}).
Algunos ejemplos de políticas que se pueden crear utilizando rangos de límites son:
- En un clúster de 2 nodos con una capacidad de 8 GiB de RAM y 16 núcleos, podría restringirse los {{< glossary_tooltip text="Pods" term_id="pod" >}} en un {{< glossary_tooltip text="Namespace" term_id="namespace" >}} a requerir `100m` de CPU con un límite máximo de `500m` para CPU y requerir `200Mi` de memoria con un límite máximo de `600Mi` de memoria.
- Definir el valor por defecto de límite y requisitos de CPU a `150m` y el valor por defecto de requisito de memoria a `300Mi` {{< glossary_tooltip text="Contenedores" term_id="container" >}} que se iniciaron sin requisitos de CPU y memoria en sus especificaciones.
En el caso de que los límites totales del {{< glossary_tooltip text="Namespace" term_id="namespace" >}} sean menores que la suma de los límites de los {{< glossary_tooltip text="Pods" term_id="pod" >}},
puede haber contienda por los recursos. En este caso, los contenedores o pods no seran creados.
Ni la contención ni los cambios en un LimitRange afectarán a los recursos ya creados.
## {{% heading "whatsnext" %}}
Consulte el [documento de diseño del LimitRanger](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) para más información.
Los siguientes ejemplos utilizan límites y están pendientes de su traducción:
- [how to configure minimum and maximum CPU constraints per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/).
- [how to configure minimum and maximum Memory constraints per namespace](/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/).
- [how to configure default CPU Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/).
- [how to configure default Memory Requests and Limits per namespace](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/).
- [how to configure minimum and maximum Storage consumption per namespace](/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage).
- [a detailed example on configuring quota per namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/).
content/es/docs/reference/glossary/limitrange.md
Executable
+23
View File
@@ -0,0 +1,23 @@
---
title: LimitRange
id: limitrange
date: 2019-04-15
full_link: /docs/concepts/policy/limit-range/
short_description: >
Proporciona restricciones para limitar el consumo de recursos por Contenedores o Pods en un espacio de nombres
aka:
tags:
- core-object
- fundamental
- architecture
related:
- pod
- container
---
Proporciona restricciones para limitar el consumo de recursos por {{< glossary_tooltip text="Contenedores" term_id="container" >}} o {{< glossary_tooltip text="Pods" term_id="pod" >}} en un espacio de nombres ({{< glossary_tooltip text="Namespace" term_id="namespace" >}})
<!--more-->
LimitRange limita la cantidad de objetos que se pueden crear por tipo, así como la cantidad de recursos informáticos que pueden ser requeridos/consumidos por {{< glossary_tooltip text="Pods" term_id="pod" >}} o {{< glossary_tooltip text="Contenedores" term_id="container" >}} individuales en un {{< glossary_tooltip text="Namespace" term_id="namespace" >}}.