|
| 1 | +--- |
| 2 | +reviewers: |
| 3 | +title: RuntimeClass |
| 4 | +content_type: concept |
| 5 | +weight: 20 |
| 6 | +--- |
| 7 | + |
| 8 | +<!-- overview --> |
| 9 | + |
| 10 | +{{< feature-state for_k8s_version="v1.20" state="stable" >}} |
| 11 | + |
| 12 | +Esta página describe el recurso RuntimeClass y el mecanismo de selección del |
| 13 | +motor de ejecución. |
| 14 | + |
| 15 | +RuntimeClass es una característica que permite seleccionar la configuración del |
| 16 | +motor de ejecución para los contenedores. La configuración del motor de ejecución para |
| 17 | +los contenedores se utiliza para ejecutar los contenedores de un Pod. |
| 18 | + |
| 19 | + |
| 20 | + |
| 21 | + |
| 22 | +<!-- body --> |
| 23 | + |
| 24 | +## Motivación |
| 25 | + |
| 26 | +Se puede seleccionar un RuntimeClass diferente entre diferentes Pods para |
| 27 | +proporcionar equilibrio entre rendimiento y seguridad. Por ejemplo, si parte de |
| 28 | +la carga de trabajo requiere un alto nivel de garantía de seguridad, se podrían |
| 29 | +planificar esos Pods para ejecutarse en un motor de ejecución que use |
| 30 | +virtualización de hardware. Así se beneficiaría con un mayor aislamiento del motor |
| 31 | +de ejecución alternativo, con el coste de alguna sobrecarga adicional. |
| 32 | + |
| 33 | +También se puede utilizar el RuntimeClass para ejecutar distintos Pods con el |
| 34 | +mismo motor de ejecución pero con distintos parámetros. |
| 35 | + |
| 36 | +## Configuración |
| 37 | + |
| 38 | +1. Configurar la implementación del CRI en los nodos (depende del motor de |
| 39 | + ejecución) |
| 40 | +2. Crear los recursos RuntimeClass correspondientes. |
| 41 | + |
| 42 | +### 1. Configurar la implementación del CRI en los nodos |
| 43 | + |
| 44 | +La configuración disponible utilizando RuntimeClass dependen de la |
| 45 | +implementación de la Interfaz del Motor de ejecución de Containers (CRI). Véase |
| 46 | +la sección [Configuración del CRI](#cri-configuration) para más |
| 47 | +información sobre cómo configurar la implementación del CRI. |
| 48 | + |
| 49 | +{{< note >}} |
| 50 | +RuntimeClass por defecto asume una configuración de nodos homogénea para todo el |
| 51 | +clúster (lo que significa que todos los nodos están configurados de la misma |
| 52 | +forma para el motor de ejecución de los contenedores). Para soportar configuraciones |
| 53 | +heterogéneas de nodos, véase [Planificación](#scheduling) más abajo. |
| 54 | +{{< /note >}} |
| 55 | + |
| 56 | +Las configuraciones tienen un nombre de `handler` (manipulador) correspondiente, referenciado |
| 57 | +por la RuntimeClass. El `handler` debe ser una etiqueta DNS 1123 válida |
| 58 | +(alfanumérico + caracter `-`). |
| 59 | + |
| 60 | +### 2. Crear los recursos RuntimeClass correspondientes. |
| 61 | + |
| 62 | +Cada configuración establecida en el paso 1 tiene un nombre de `handler`, que |
| 63 | +identifica a dicha configuración. Para cada `handler`, hay que crear un objeto |
| 64 | +RuntimeClass correspondiente. |
| 65 | + |
| 66 | +Actualmente el recurso RuntimeClass sólo tiene dos campos significativos: el |
| 67 | +nombre del RuntimeClass (`metadata.name`) y el `handler`. La |
| 68 | +definición del objeto se parece a ésta: |
| 69 | + |
| 70 | +```yaml |
| 71 | +apiVersion: node.k8s.io/v1 # La RuntimeClass se define en el grupo node.k8s.io |
| 72 | +kind: RuntimeClass |
| 73 | +metadata: |
| 74 | + name: myclass # Nombre por el que se referenciará la RuntimeClass |
| 75 | + # no contiene espacio de nombres |
| 76 | +handler: myconfiguration # El nombre de la configuración CRI correspondiente |
| 77 | +``` |
| 78 | +
|
| 79 | +El nombre de un objeto RuntimeClass debe ser un [nombre de subdominio |
| 80 | +DNS](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names) |
| 81 | +válido. |
| 82 | +
|
| 83 | +{{< note >}} |
| 84 | +Se recomienda que las operaciones de escritura de la RuntimeClass |
| 85 | +(creación/modificación/parcheo/elimiación) se restrinjan al administrador del |
| 86 | +clúster. Habitualmente es el valor por defecto. Véase [Visión general de la |
| 87 | +Autorización](/docs/reference/access-authn-authz/authorization/) para más |
| 88 | +detalles. |
| 89 | +{{< /note >}} |
| 90 | +
|
| 91 | +## Uso |
| 92 | +
|
| 93 | +Una vez se han configurado las RuntimeClasses para el clúster, el utilizarlas es |
| 94 | +muy sencillo. Solo se especifica un `runtimeClassName` en la especificación del Pod. |
| 95 | +Por ejemplo: |
| 96 | + |
| 97 | + |
| 98 | +```yaml |
| 99 | +apiVersion: v1 |
| 100 | +kind: Pod |
| 101 | +metadata: |
| 102 | + name: mypod |
| 103 | +spec: |
| 104 | + runtimeClassName: myclass |
| 105 | + # ... |
| 106 | +``` |
| 107 | + |
| 108 | +Así se informa a Kubelet del nombre de la RuntimeClass a utilizar para |
| 109 | +este pod. Si dicha RuntimeClass no existe, o el CRI no puede ejecutar el |
| 110 | +`handler` correspondiente, el pod entrará en la |
| 111 | +[fase](/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) final `Failed`. |
| 112 | +Se puede buscar por el correspondiente |
| 113 | +[evento](/docs/tasks/debug-application-cluster/debug-application-introspection/) |
| 114 | +con el mensaje de error. |
| 115 | + |
| 116 | +Si no se especifica ninguna `runtimeClassName`, se usará el RuntimeHandler por |
| 117 | +defecto, lo que equivale al comportamiento cuando la opción RuntimeClass está |
| 118 | +deshabilitada. |
| 119 | + |
| 120 | +### Configuración del CRI |
| 121 | + |
| 122 | +Para más detalles sobre cómo configurar los motores de ejecución del CRI, véase |
| 123 | +[instalación del CRI](/docs/setup/production-environment/container-runtimes/). |
| 124 | + |
| 125 | +#### dockershim |
| 126 | + |
| 127 | +El CRI dockershim incorporado por Kubernetes no soporta manejadores del motor de |
| 128 | +ejecución. |
| 129 | + |
| 130 | +#### {{< glossary_tooltip term_id="containerd" >}} |
| 131 | + |
| 132 | +Los `handlers` del motor de ejecución se configuran mediante la configuración |
| 133 | +de containerd en `/etc/containerd/config.toml`. Los `handlers` válidos se |
| 134 | +configuran en la sección de motores de ejecución: |
| 135 | + |
| 136 | +``` |
| 137 | +[plugins.cri.containerd.runtimes.${HANDLER_NAME}] |
| 138 | +``` |
| 139 | + |
| 140 | +Véase la configuración de containerd para más detalles: |
| 141 | +https://github.com/containerd/cri/blob/master/docs/config.md |
| 142 | + |
| 143 | +#### {{< glossary_tooltip term_id="cri-o" >}} |
| 144 | + |
| 145 | +Los `handlers` del motor de ejecución se configuran a través de la |
| 146 | +configuración del CRI-O en `/etc/crio/crio.conf`. Los manejadores válidos se |
| 147 | +configuran en la [tabla |
| 148 | +crio.runtime](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md#crioruntime-table) |
| 149 | + |
| 150 | +``` |
| 151 | +[crio.runtime.runtimes.${HANDLER_NAME}] |
| 152 | + runtime_path = "${PATH_TO_BINARY}" |
| 153 | +``` |
| 154 | +
|
| 155 | +Véase la [documentación de la |
| 156 | +configuración](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md) |
| 157 | +de CRI-O para más detalles. |
| 158 | +
|
| 159 | +## Planificación |
| 160 | +
|
| 161 | +{{< feature-state for_k8s_version="v1.16" state="beta" >}} |
| 162 | +
|
| 163 | +Especificando el campo `scheduling` en una RuntimeClass se pueden establecer |
| 164 | +restricciones para asegurar que los Pods ejecutándose con dicha RuntimeClass se |
| 165 | +planifican en los nodos que la soportan. |
| 166 | +
|
| 167 | +Para asegurar que los pods sean asignados en nodos que soportan una RuntimeClass |
| 168 | +determinada, ese conjunto de nodos debe tener una etiqueta común que se |
| 169 | +selecciona en el campo `runtimeclass.scheduling.nodeSelector`. El nodeSelector |
| 170 | +de la RuntimeClass se combina con el nodeSelector del pod durante la admisión, |
| 171 | +haciéndose efectiva la intersección del conjunto de nodos seleccionados por |
| 172 | +ambos. Si hay conflicto, el pod se rechazará. |
| 173 | +
|
| 174 | +Si los nodos soportados se marcan para evitar que los pods con otra RuntimeClass |
| 175 | +se ejecuten en el nodo, se pueden añadir `tolerations` al RuntimeClass. Igual |
| 176 | +que con el `nodeSelector`, las tolerancias se mezclan con las tolerancias del |
| 177 | +pod durante la admisión, haciéndose efectiva la unión del conjunto de nodos |
| 178 | +tolerados por ambos. |
| 179 | +
|
| 180 | +Para saber más sobre configurar el selector de nodos y las tolerancias, véase |
| 181 | +[Asignando Pods a Nodos](/docs/concepts/scheduling-eviction/assign-pod-node/). |
| 182 | +
|
| 183 | +### Sobrecarga del Pod |
| 184 | +
|
| 185 | +{{< feature-state for_k8s_version="v1.18" state="beta" >}} |
| 186 | +
|
| 187 | +Se pueden especificar recursos de _sobrecarga_ adicional que se asocian a los |
| 188 | +Pods que estén ejecutándose. Declarar la sobrecarga permite al clúster (incluido |
| 189 | +el planificador) contabilizarlo al tomar decisiones sobre los Pods y los |
| 190 | +recursos. Para utilizar la sobrecarga de pods, se debe haber habilitado la |
| 191 | +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) |
| 192 | +PodOverhead (lo está por defecto). |
| 193 | +
|
| 194 | +La sobrecarga de pods se define en la RuntimeClass a través del los campos de |
| 195 | +`overhead`. Con estos campos se puede especificar la sobrecarga de los pods en |
| 196 | +ejecución que utilizan esta RuntimeClass para asegurar que estas sobrecargas se |
| 197 | +cuentan en Kubernetes. |
| 198 | +
|
| 199 | +## {{% heading "whatsnext" %}} |
| 200 | +
|
| 201 | +
|
| 202 | +- [Diseño de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) |
| 203 | +- [Diseño de programación de RuntimeClass](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) |
| 204 | +- Leer sobre el concepto de [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) |
| 205 | +- [Diseño de capacidad de PodOverhead](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md) |
0 commit comments