Yushiro FURUKAWA
Kubernetes Prow Robot
parent
520caa1264
commit
af66c0a274
|
|
@ -62,7 +62,7 @@ El CCM hereda sus funciones de componentes que son dependientes de un proveedor
|
|||
|
||||
### 1. Kubernetes Controller Manager
|
||||
|
||||
La mayoría de las funciones del CCM derivan del KCM. Como se ha mencionado en la sección anterior, el CCM es responsable de los siguientes circuitos de control:
|
||||
La mayoría de las funciones del CCM derivan del KCM. Como se ha mencionado en la sección anterior, el CCM es responsable de los siguientes circuitos de control:
|
||||
|
||||
* Controlador de Nodos
|
||||
* Controlador de Rutas
|
||||
|
|
@ -70,7 +70,7 @@ La mayoría de las funciones del CCM derivan del KCM. Como se ha mencionado en l
|
|||
|
||||
#### Controlador de Nodos
|
||||
|
||||
El controlador de nodos es responsable de inicializar un nodo obteniendo información del proveedor de servicios sobre los nodos ejecutándose en el clúster. El controlador de nodos lleva a cabo las siguientes funciones:
|
||||
El controlador de nodos es responsable de inicializar un nodo obteniendo información del proveedor de servicios sobre los nodos ejecutándose en el clúster. El controlador de nodos lleva a cabo las siguientes funciones:
|
||||
|
||||
1. Inicializa un nodo con etiquetas de región y zona específicas del proveedor.
|
||||
2. Inicializa un nodo con detalles de la instancia específicos del proveedor, como por ejemplo, el tipo o el tamaño.
|
||||
|
|
@ -95,7 +95,7 @@ En este nuevo modelo, el kubelet inicializa un nodo sin información especifica
|
|||
|
||||
El Cloud Controller Manager utiliza interfaces Go(lang), lo que permite que implementaciones de cualquier proveedor de servicios sean conectadas. Específicamente, utiliza el CloudProvider Interface definido [aquí](https://github.com/kubernetes/cloud-provider/blob/9b77dc1c384685cb732b3025ed5689dd597a5971/cloud.go#L42-L62).
|
||||
|
||||
La implementación de los cuatro controladores referenciados en este documento, algunas estructuras de inicialización junto con el interface CloudProvider, permanecerán como parte del núcleo de Kubernetes.
|
||||
La implementación de los cuatro controladores referenciados en este documento, algunas estructuras de inicialización junto con el interface CloudProvider, permanecerán como parte del núcleo de Kubernetes.
|
||||
|
||||
Para más información sobre el desarrollo de extensiones/plugins, consultar [Desarrollo del CCM](https://kubernetes.io/docs/tasks/administer-cluster/developing-cloud-controller-manager/).
|
||||
|
||||
|
|
@ -119,7 +119,7 @@ v1/Node:
|
|||
|
||||
### Controlador de Rutas
|
||||
|
||||
El controlador de rutas permanece a la escucha de eventos de creación de nodos y configura sus rutas. Necesita acceso a los objetos Nodo.
|
||||
El controlador de rutas permanece a la escucha de eventos de creación de nodos y configura sus rutas. Necesita acceso a los objetos Nodo.
|
||||
|
||||
v1/Node:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
reviewers:
|
||||
reviewers:
|
||||
- glo-pena
|
||||
title: Comunicación Nodo-Maestro
|
||||
content_template: templates/concept
|
||||
|
|
@ -15,7 +15,7 @@ Este documento cataloga las diferentes vías de comunicación entre el nodo más
|
|||
{{% capture body %}}
|
||||
|
||||
### Clúster a Máster
|
||||
|
||||
|
||||
Todos los canales de comunicación desde el clúster hacia el máster terminan en el apiserver (ningún otro componente del máster está diseñado para exponer servicios remotos). En un despliegue típico, el apiserver está configurado para escuchar conexiones remotas en un canal seguro cómo HTTPS en el puerto (443) con una o más formas de [autenticación de clientes](/docs/reference/access-authn-authz/authentication/) habilitada. Una o más formas de [autorización](/docs/reference/access-authn-authz/authorization/) deberían ser habilitadas, especialmente si se permiten [peticiones anónimas](/docs/reference/access-authn-authz/authentication/#anonymous-requests)
|
||||
o [tokens de cuenta de servicio](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ Finalmente, [autenticación y/o autorización al kubelet](/docs/admin/kubelet-au
|
|||
|
||||
### apiserver a nodos, pods y servicios
|
||||
|
||||
Las conexiones desde el apiserver a un nodo, pod o servicio se realizan por defecto con HTTP y, por consiguiente, no son autentificadas o encriptadas. Pueden ser ejecutadas en una conexión HTTPS segura añadiendo el prefijo `https:` al nodo, pod o nombre de servicio en la API URL, pero los receptores no validan el certificado provisto por el endpoint HTTPS ni facilitan credenciales de cliente asi que, aunque la conexión esté encriptada, esta no ofrece garantía de integridad. Estas conexiones **no son seguras** para conectar a través de redes públicas o inseguras.
|
||||
Las conexiones desde el apiserver a un nodo, pod o servicio se realizan por defecto con HTTP y, por consiguiente, no son autentificadas o encriptadas. Pueden ser ejecutadas en una conexión HTTPS segura añadiendo el prefijo `https:` al nodo, pod o nombre de servicio en la API URL, pero los receptores no validan el certificado provisto por el endpoint HTTPS ni facilitan credenciales de cliente asi que, aunque la conexión esté encriptada, esta no ofrece garantía de integridad. Estas conexiones **no son seguras** para conectar a través de redes públicas o inseguras.
|
||||
|
||||
### Túneles SSH
|
||||
|
||||
|
|
|
|||
|
|
@ -60,7 +60,7 @@ Si el `status` de la condición `Ready` se mantiene como `Unknown` o `False` por
|
|||
|
||||
En versiones de Kubernetes anteriores a 1.5, el controlador de nodos [forzaba el borrado](/docs/concepts/workloads/pods/pod/#force-deletion-of-pods) de dichos pods inaccesibles desde el API Server. Sin embargo, desde la versión 1.5, el nodo controlador no fuerza el borrado de pods hasta que se confirma que dichos pods han dejado de ejecutarse en el clúster. Pods que podrían estar ejecutándose en un nodo inalcanzable se muestran como `Terminating` o `Unknown`. En aquellos casos en los que Kubernetes no puede deducir si un nodo ha abandonado el clúster de forma permanente, puede que sea el administrador el que tenga que borrar el nodo de forma manual. Borrar un objeto `Node` en un clúster de Kubernetes provoca que los objetos Pod que se ejecutaban en el nodo sean eliminados en el API Server y libera sus nombres.
|
||||
|
||||
En la versión 1.12, la funcionalidad `TaintNodesByCondition` se eleva a beta, de forma que el controlador del ciclo de vida de nodos crea [taints](/docs/concepts/configuration/taint-and-toleration/) de forma automática, que representan estados de nodos.
|
||||
En la versión 1.12, la funcionalidad `TaintNodesByCondition` se eleva a beta, de forma que el controlador del ciclo de vida de nodos crea [taints](/docs/concepts/configuration/taint-and-toleration/) de forma automática, que representan estados de nodos.
|
||||
De forma similar, el planificador de tareas ignora estados cuando evalúa un nodo; en su lugar mira los taints del nodo y las tolerancias de los pods.
|
||||
|
||||
En la actualidad, los usuarios pueden elegir entre la versión de planificación antigua y el nuevo, más flexible, modelo de planificación.
|
||||
|
|
@ -123,7 +123,7 @@ En la mayoría de los casos, el controlador de nodos limita el ritmo de desalojo
|
|||
El comportamiento de desalojo de nodos cambia cuando un nodo en una zona de disponibilidad tiene problemas. El controlador de nodos comprobará qué porcentaje de nodos en la zona no se encuentran en buen estado (es decir, que su condición `NodeReady` tiene un valor `ConditionUnknown` o `ConditionFalse`) al mismo tiempo. Si la fracción de nodos con problemas es de al menos `--unhealthy-zone-threshold` (0.55 por defecto) entonces se reduce el ratio de desalojos: si el clúster es pequeño (por ejemplo, tiene menos o los mismos nodos que `--large-cluster-size-threshold` - 50 por defecto) entonces los desalojos se paran. Sino, el ratio se reduce a `--secondary-node-eviction-rate` (0.01 por defecto) por segundo. La razón por la que estas políticas se implementan por zonas de disponibilidad es debido a que una zona puede quedarse aislada del nodo máster mientras que las demás continúan conectadas. Si un clúster no comprende más de una zona, todo el clúster se considera una única zona.
|
||||
|
||||
La razón principal por la que se distribuyen nodos entre varias zonas de disponibilidad es para que el volumen de trabajo se transfiera a aquellas zonas que se encuentren en buen estado cuando una de las zonas se caiga.
|
||||
Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se re-establece la conectividad.
|
||||
Por consiguiente, si todos los nodos de una zona se encuentran en mal estado, el nodo controlador desaloja al ritmo normal `--node-eviction-rate`. En el caso extremo de que todas las zonas se encuentran en mal estado (es decir, no responda ningún nodo del clúster), el controlador de nodos asume que hay algún tipo de problema con la conectividad del nodo máster y paraliza todos los desalojos hasta que se re-establece la conectividad.
|
||||
|
||||
Desde la versión 1.6 de Kubernetes el controlador de nodos también es el responsable de desalojar pods que están ejecutándose en nodos con `NoExecute` taints, cuando los pods no permiten dichos taints. De forma adicional, como una funcionalidad alfa que permanece deshabilitada por defecto, el `NodeController` es responsable de añadir taints que se corresponden con problemas en los nodos del tipo nodo inalcanzable o nodo no preparado. En [esta sección de la documentación](/docs/concepts/configuration/taint-and-toleration/) hay más detalles acerca de los taints `NoExecute` y de la funcionalidad alfa.
|
||||
|
||||
|
|
@ -161,7 +161,7 @@ Marcar un nodo como no-planificable impide que nuevos pods sean planificados en
|
|||
kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
{{< note >}}
|
||||
Los pods creados por un controlador DaemonSet ignoran el planificador de Kubernetes y no respetan el atributo no-planificable de un nodo. Se asume que los daemons pertenecen a la máquina huésped y que se ejecutan incluso cuando esta está siendo drenada de aplicaciones en preparación de un reinicio.
|
||||
{{< /note >}}
|
||||
|
||||
|
|
|
|||
|
|
@ -114,7 +114,7 @@ Events:
|
|||
{{% capture whatsnext %}}
|
||||
|
||||
* Aprende más sobre [variables de entorno de contenedores](/docs/concepts/containers/container-environment-variables/).
|
||||
* Practica
|
||||
* Practica
|
||||
[adjuntando controladores a los eventos de lifecycle de los contenedores](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ reviewers:
|
|||
title: ¿Qué es Kubernetes?
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 10
|
||||
---
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Puedes usar las anotaciones de Kubernetes para adjuntar metadatos arbitrarios a
|
|||
{{% capture body %}}
|
||||
## Adjuntar metadatos a los objetos
|
||||
|
||||
Puedes usar las etiquetas o anotaciones para adjuntar metadatos a los objetos de Kubernetes.
|
||||
Puedes usar las etiquetas o anotaciones para adjuntar metadatos a los objetos de Kubernetes.
|
||||
Las etiquetas pueden utilizarse para seleccionar objetos y para encontrar colecciones de objetos que satisfacen ciertas condiciones.
|
||||
Por el contrario, las anotaciones no se utilizan para identificar y seleccionar objetos.
|
||||
Los metadatos de una anotación pueden ser pequeños o grandes, estructurados o no estructurados,
|
||||
|
|
@ -32,7 +32,7 @@ Aquí se presentan algunos ejemplos de información que podría ser indicada com
|
|||
|
||||
* Campos gestionados por una capa de configuración declarativa.
|
||||
Adjuntando dichos campos como anotaciones permitiría diferenciarlos de los
|
||||
valores por defecto establecidos por clientes o servidores, además de los
|
||||
valores por defecto establecidos por clientes o servidores, además de los
|
||||
campos auto-generados y los campos modificados por sistemas de auto-escalado.
|
||||
|
||||
* Información acerca de la construcción, entrega, o imagen como marcas de fecha, IDs de entrega, rama de Git,
|
||||
|
|
@ -56,12 +56,12 @@ Aquí se presentan algunos ejemplos de información que podría ser indicada com
|
|||
|
||||
En vez de usar anotaciones, podrías almacenar este tipo de información en una
|
||||
base de datos externa o un directorio, pero eso complicaría enormemente la posibilidad
|
||||
de crear librerías compartidas de cliente, así como herramientas para el
|
||||
de crear librerías compartidas de cliente, así como herramientas para el
|
||||
despliegue, gestión, introspección, y similares.
|
||||
|
||||
## Sintaxis y conjunto de caracteres
|
||||
|
||||
Las _Anotaciones_ son entradas clave/valor. Una clave válida para una anotación tiene dos partes: un prefijo opcional y un nombre, separados por una barra (`/`). La parte del nombre es obligatoria y debe tener 63 caracteres o menos, empezando y terminando con un carácter alfanumérico (`[a-z0-9A-Z]`) con guiones (`-`), guiones bajos (`_`), puntos (`.`) en medio. El prefijo es opcional. Si se indica,
|
||||
Las _Anotaciones_ son entradas clave/valor. Una clave válida para una anotación tiene dos partes: un prefijo opcional y un nombre, separados por una barra (`/`). La parte del nombre es obligatoria y debe tener 63 caracteres o menos, empezando y terminando con un carácter alfanumérico (`[a-z0-9A-Z]`) con guiones (`-`), guiones bajos (`_`), puntos (`.`) en medio. El prefijo es opcional. Si se indica,
|
||||
el prefijo debe ser un subdominio DNS: una serie de etiquetas DNS separadas por puntos (`.`), no superior a 253 caracteres en total, seguida de una barra (`/`).
|
||||
|
||||
Si se omite el prefijo, la clave de la anotación se entiende que es privada para el usuario. Los componentes automatizados del sistema (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, u otros de terceros) que añaden anotaciones a los objetos de usuario deben, pues, especificar un prefijo.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ content_template: templates/concept
|
|||
|
||||
{{% capture overview %}}
|
||||
Puedes visualizar y gestionar los objetos de Kubernetes con herramientas adicionales a kubectl
|
||||
y el propio tablero de control. Un conjunto común de etiquetas permite a dichas herramientas
|
||||
y el propio tablero de control. Un conjunto común de etiquetas permite a dichas herramientas
|
||||
trabajar de forma interoperable, describiendo los objetos de una forma común que todas las
|
||||
herramientas puedan entender.
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Estas son las etiquetas recomendadas. Estas facilitan la gestión de aplicacione
|
|||
pero no son obligatorias para las herramientas en general.
|
||||
{{< /note >}}
|
||||
|
||||
Las etiquetas compartidas y las anotaciones comparten un prefijo común: `app.kubernetes.io`.
|
||||
Las etiquetas compartidas y las anotaciones comparten un prefijo común: `app.kubernetes.io`.
|
||||
Las etiquetas sin un prefijo son privadas para los usuarios. El prefijo compartido
|
||||
garantiza que las etiquetas compartidas no entran en conflicto con las etiquetas
|
||||
personalizadas de usuario.
|
||||
|
|
@ -63,10 +63,10 @@ Una misma aplicación puede desplegarse una o más veces en un clúster de Kuber
|
|||
incluso, el mismo espacio de nombres. Por ejemplo, wordpress puede instalarse más de una
|
||||
vez de forma que sitios web diferentes sean instalaciones diferentes de wordpress.
|
||||
|
||||
El nombre de una aplicación y el nombre de la instancia se almacenan de forma separada.
|
||||
Por ejemplo, WordPress tiene un `app.kubernetes.io/name` igual a `wordpress` mientras que
|
||||
tiene un nombre de instancia, representado como `app.kubernetes.io/instance` con un valor de
|
||||
`wordpress-abcxzy`. Esto permite identificar tanto a la aplicación como a sus instancias.
|
||||
El nombre de una aplicación y el nombre de la instancia se almacenan de forma separada.
|
||||
Por ejemplo, WordPress tiene un `app.kubernetes.io/name` igual a `wordpress` mientras que
|
||||
tiene un nombre de instancia, representado como `app.kubernetes.io/instance` con un valor de
|
||||
`wordpress-abcxzy`. Esto permite identificar tanto a la aplicación como a sus instancias.
|
||||
Cada instancia de una aplicación tiene su propio nombre único.
|
||||
|
||||
## Ejemplos
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
title: Entender los Objetos de Kubernetes
|
||||
content_template: templates/concept
|
||||
weight: 10
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 40
|
||||
---
|
||||
|
|
@ -42,7 +42,7 @@ Aquí hay un ejemplo de un archivo `.yaml` que muestra los campos requeridos y l
|
|||
{{< codenew file="application/deployment.yaml" >}}
|
||||
|
||||
Una forma de crear un Deployment utilizando un archivo `.yaml` como el indicado arriba sería ejecutar el comando
|
||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)
|
||||
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)
|
||||
en el interfaz de línea de comandos, pasándole el archivo `.yaml` como argumento. Aquí tienes un ejemplo de cómo hacerlo:
|
||||
|
||||
```shell
|
||||
|
|
@ -64,7 +64,7 @@ En el archivo `.yaml` del objeto de Kubernetes que quieras crear, obligatoriamen
|
|||
* `metadata` - Datos que permiten identificar unívocamente al objeto, incluyendo una cadena de texto para el `name`, UID, y opcionalmente el `namespace`
|
||||
|
||||
También deberás indicar el campo `spec` del objeto. El formato del campo `spec` es diferente según el tipo de objeto de Kubernetes, y contiene campos anidados específicos de cada objeto. La [Referencia de la API de Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) puede servirte de ayuda para encontrar el formato de la spec para cada uno de los objetos que puedes crear usando Kubernetes.
|
||||
Por ejemplo, el formato de la `spec` para un objeto de tipo `Pod` lo puedes encontrar
|
||||
Por ejemplo, el formato de la `spec` para un objeto de tipo `Pod` lo puedes encontrar
|
||||
[aquí](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core),
|
||||
y el formato de la `spec` para un objeto de tipo `Deployment` lo puedes encontrar
|
||||
[aquí](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
|
||||
|
|
|
|||
|
|
@ -17,8 +17,8 @@ Estos clústeres virtuales se denominan espacios de nombres (namespaces).
|
|||
## Cuándo Usar Múltiple Espacios de Nombre
|
||||
|
||||
Los espacios de nombres están pensados para utilizarse en entornos con muchos usuarios
|
||||
distribuidos entre múltiples equipos, o proyectos. Para aquellos clústeres con
|
||||
unas pocas decenas de usuarios, no deberías necesitar crear o pensar en espacios de
|
||||
distribuidos entre múltiples equipos, o proyectos. Para aquellos clústeres con
|
||||
unas pocas decenas de usuarios, no deberías necesitar crear o pensar en espacios de
|
||||
nombres en absoluto. Empieza a usarlos solamente si necesitas las características
|
||||
que proporcionan.
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ entre múltiples usuarios (via [cuotas de recursos](/docs/concepts/policy/resour
|
|||
En futuras versiones de Kubernetes, los objetos de un mismo espacio de nombres
|
||||
tendrán las mismas políticas de control de acceso por defecto.
|
||||
|
||||
No es necesario usar múltiples espacios de nombres sólo para separar recursos
|
||||
No es necesario usar múltiples espacios de nombres sólo para separar recursos
|
||||
ligeramente diferentes, como versiones diferentes de la misma aplicación: para ello
|
||||
utiliza [etiquetas](/docs/user-guide/labels) para distinguir tus recursos dentro
|
||||
del mismo espacio de nombres.
|
||||
|
|
@ -58,8 +58,8 @@ Kubernetes arranca con tres espacios de nombres inicialmente:
|
|||
|
||||
* `default` El espacio de nombres por defecto para aquellos objetos que no especifican ningún espacio de nombres
|
||||
* `kube-system` El espacio de nombres para aquellos objetos creados por el sistema de Kubernetes
|
||||
* `kube-public` Este espacio de nombres se crea de forma automática y es legible por todos los usuarios (incluyendo aquellos no autenticados).
|
||||
Este espacio de nombres se reserva principalmente para uso interno del clúster, en caso de que algunos recursos necesiten ser visibles y legibles de forma pública para todo el clúster.
|
||||
* `kube-public` Este espacio de nombres se crea de forma automática y es legible por todos los usuarios (incluyendo aquellos no autenticados).
|
||||
Este espacio de nombres se reserva principalmente para uso interno del clúster, en caso de que algunos recursos necesiten ser visibles y legibles de forma pública para todo el clúster.
|
||||
La naturaleza pública de este espacio de nombres es simplemente por convención, no es un requisito.
|
||||
|
||||
### Establecer el espacio de nombres para una petición
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
---
|
||||
title: ReplicationController
|
||||
feature:
|
||||
feature:
|
||||
title: Auto-reparación
|
||||
anchor: Cómo funciona un ReplicationController
|
||||
description: >
|
||||
Reinicia contenedores que fallan, sustituye y reprograma contenedores cuando los nodos mueren,
|
||||
mata los contenedores que no responden a tus pruebas de salud definidas,
|
||||
Reinicia contenedores que fallan, sustituye y reprograma contenedores cuando los nodos mueren,
|
||||
mata los contenedores que no responden a tus pruebas de salud definidas,
|
||||
y no los expone a los clientes hasta que no están listo para servirse.
|
||||
|
||||
content_template: templates/concept
|
||||
|
|
@ -30,7 +30,7 @@ siempre esté arriba y disponible.
|
|||
## Cómo Funciona un ReplicationController
|
||||
|
||||
Si hay muchos pods, el ReplicationController termina los pods extra. Si hay muy pocos, el
|
||||
ReplicationController arranca más pods. A difrencia de los pods creados manualmente, los pods mantenidos por un
|
||||
ReplicationController arranca más pods. A difrencia de los pods creados manualmente, los pods mantenidos por un
|
||||
ReplicationController se sustituyen de forma automática si fallan, se borran, o se terminan.
|
||||
Por ejemplo, tus pods se re-crean en un nodo durante una intervención disruptiva de mantenimiento como una actualización del kernel.
|
||||
Por esta razón, deberías usar un ReplicationController incluso cuando tu aplicación sólo necesita
|
||||
|
|
@ -38,7 +38,7 @@ un único pod. Un ReplicationController es parecido a un supervisor de procesos,
|
|||
pero en vez de supervisar procesos individuales en un único nodo,
|
||||
el ReplicationController supervisa múltiples pods entre múltiples nodos.
|
||||
|
||||
A menudo nos referimos a un ReplicationController de forma abreviada como "rc" o "rcs", así como
|
||||
A menudo nos referimos a un ReplicationController de forma abreviada como "rc" o "rcs", así como
|
||||
atajo en los comandos de kubectl.
|
||||
|
||||
Un caso simple es crear un objeto ReplicationController para ejecutar de manera fiable una instancia
|
||||
|
|
@ -90,7 +90,7 @@ Events:
|
|||
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-4ok8v
|
||||
```
|
||||
|
||||
Como se puede observar, se han creado tres pods, pero ninguno se está ejecutándose todavía,
|
||||
Como se puede observar, se han creado tres pods, pero ninguno se está ejecutándose todavía,
|
||||
puede que porque la imagen todavía se está descargando.
|
||||
Unos momentos después, el mismo comando puede que muestre:
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ Unos momentos después, el mismo comando puede que muestre:
|
|||
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
|
||||
```
|
||||
|
||||
Para listar todos los pods que pertenecen al ReplicationController de forma legible,
|
||||
Para listar todos los pods que pertenecen al ReplicationController de forma legible,
|
||||
puedes usar un comando como el siguiente:
|
||||
|
||||
```shell
|
||||
|
|
@ -126,13 +126,13 @@ Un ReplicationController también necesita un [sección `.spec`](https://git.k8s
|
|||
|
||||
El campo `.spec.template` es el único campo requerido de `.spec`.
|
||||
|
||||
El campo `.spec.template` es una [plantilla pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates).
|
||||
El campo `.spec.template` es una [plantilla pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates).
|
||||
Tiene exactamente el mismo esquema que un [pod](/docs/concepts/workloads/pods/pod/), excepto por el hecho de que está anidado y no tiene los campos `apiVersion` ni `kind`.
|
||||
|
||||
Además de los campos obligatorios de un Pod, una plantilla pod de un ReplicationController debe especificar las etiquetas apropiadas
|
||||
y la regla de reinicio apropiada. En el caso de las etiquetas, asegúrate que no se entremezclan con otros controladores. Ver el [selector de pod](#pod-selector).
|
||||
|
||||
Sólo se permite el valor `Always` para el campo [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy),
|
||||
Sólo se permite el valor `Always` para el campo [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy),
|
||||
que es el valor predeterminado si no se indica.
|
||||
|
||||
Para los reinicios locales de los contenedores, los ReplicationControllers delegan en los agentes del nodo,
|
||||
|
|
@ -154,7 +154,7 @@ pods que creó o eliminó, y pods que otra persona o proceso creó o eliminó. E
|
|||
Si se indica, el valor de `.spec.template.metadata.labels` debe ser igual al de `.spec.selector`, o será rechazado por la API.
|
||||
Si no se indica el valor de `.spec.selector`, se tomará como predeterminado el de `.spec.template.metadata.labels`.
|
||||
|
||||
Tampoco deberías crear ningún pod cuyas etiquetas coincidan con las de este selector, ni directamente con
|
||||
Tampoco deberías crear ningún pod cuyas etiquetas coincidan con las de este selector, ni directamente con
|
||||
otro ReplicationController, ni con otro controlador como un Job. Si lo haces, el
|
||||
ReplicationController piensa que el creó también los otros pods. Kubernetes no te impide hacerlo.
|
||||
|
||||
|
|
@ -197,48 +197,48 @@ Para actualizar los pods con una nueva especificación de forma controlada, util
|
|||
|
||||
### Aislar pods de un ReplicationController
|
||||
|
||||
Se puede aislar Pods del conjunto destino de un ReplicationController cambiando sus etiquetas.
|
||||
Esta técnica puede usarse para eliminar pods de un servicio para poder depurarlos, recuperar datos, etc.
|
||||
Se puede aislar Pods del conjunto destino de un ReplicationController cambiando sus etiquetas.
|
||||
Esta técnica puede usarse para eliminar pods de un servicio para poder depurarlos, recuperar datos, etc.
|
||||
Los Pods que se eliminan de esta forma serán sustituidos de forma automática (asumiendo que el número de réplicas no ha cambiado tampoco).
|
||||
|
||||
## Patrones comunes de uso
|
||||
|
||||
### Reprogramación
|
||||
|
||||
Como se comentó arriba, cuando tienes 1 pod que quieres mantener ejecutándose, o 1000, un ReplicationController se asegura de que el número indicado de pods exista,
|
||||
Como se comentó arriba, cuando tienes 1 pod que quieres mantener ejecutándose, o 1000, un ReplicationController se asegura de que el número indicado de pods exista,
|
||||
incluso si falla un nodo o se termina algún pod (por ejemplo, debido a alguna acción de otro agente de control).
|
||||
|
||||
### Escalado
|
||||
|
||||
El ReplicationController facilita el escalado del número de réplicas tanto para su aumento como para su disminución,
|
||||
El ReplicationController facilita el escalado del número de réplicas tanto para su aumento como para su disminución,
|
||||
bien manualmente o mediante un agente de auto-escalado, simplemente actualizando el campo `replicas`.
|
||||
|
||||
### Actualizaciones en línea
|
||||
|
||||
El ReplicationController se ha diseñado para facilitar las actualizaciones en línea de un servicio mediante la sustitución de sus pods uno por uno.
|
||||
|
||||
Cómo se explicó en [#1353](http://issue.k8s.io/1353), la estrategia recomendada es crear un nuevo ReplicationController con 1 réplica,
|
||||
escalar el nuevo (+1) y el viejo (-1) controlador uno por uno, y entonces eliminar el viejo controlador una vez que alcanza las 0 réplicas.
|
||||
Cómo se explicó en [#1353](http://issue.k8s.io/1353), la estrategia recomendada es crear un nuevo ReplicationController con 1 réplica,
|
||||
escalar el nuevo (+1) y el viejo (-1) controlador uno por uno, y entonces eliminar el viejo controlador una vez que alcanza las 0 réplicas.
|
||||
Esto actualiza de forma predecible el conjunto de pods independientemente de que se produzcan fallos inesperados.
|
||||
|
||||
De forma ideal, el controlador de actualización en línea tendrá en cuenta si la aplicación está lista, y
|
||||
se asegurará de que un número suficiente de pods está en servicio en todo momento.
|
||||
|
||||
Los dos ReplicationControllers necesitarán crear pods con al menos una etiqueta diferenciadora, como la etiqueta de imagen del contenedor primario del pod,
|
||||
Los dos ReplicationControllers necesitarán crear pods con al menos una etiqueta diferenciadora, como la etiqueta de imagen del contenedor primario del pod,
|
||||
ya que las actualizaciones de imagen son las que normalmente desencadenan las actualizaciones en línea.
|
||||
|
||||
La actualización en línea se implementa a través de la herramienta cliente mediante
|
||||
[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update).
|
||||
La actualización en línea se implementa a través de la herramienta cliente mediante
|
||||
[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update).
|
||||
Echa un vistazo a la [tarea `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/) para más ejemplos concretos.
|
||||
|
||||
### Múltiples operaciones de despliegue
|
||||
|
||||
Además de llevar a cabo múltiples despliegues de una aplicación cuando una actualización en línea está en progreso,
|
||||
Además de llevar a cabo múltiples despliegues de una aplicación cuando una actualización en línea está en progreso,
|
||||
es común ejecutar varios despliegues durante un período extendido de tiempo, o incluso de forma contínua, usando múltiples operaciones de despliegue. Dichas operaciones se diferenciarían por etiquetas.
|
||||
|
||||
Por ejemplo, un servicio puede que exponga todos los pods con etiquetas `tier in (frontend), environment in (prod)`. Ahora digamos que tenemos 10 pods replicados que forman este grupo.
|
||||
Pero queremos poder desplegar una nueva versión 'canary' de este component. Se podría configurar un ReplicationController con el valor de `replicas` puesto a 9 para la mayor parte de las réplicas,
|
||||
con etiquetas `tier=frontend, environment=prod, track=stable`, y otro ReplicationController con el valor de `replicas` puesto a 1 para el 'canary',
|
||||
Pero queremos poder desplegar una nueva versión 'canary' de este component. Se podría configurar un ReplicationController con el valor de `replicas` puesto a 9 para la mayor parte de las réplicas,
|
||||
con etiquetas `tier=frontend, environment=prod, track=stable`, y otro ReplicationController con el valor de `replicas` puesto a 1 para el 'canary',
|
||||
con las etiquetas `tier=frontend, environment=prod, track=canary`. Así el servicio cubriría tanto los pods canary como el resto.
|
||||
Pero también es posible trastear con los ReplicationControllers de forma separada para probar cosas, monitorizar los resultados, etc.
|
||||
|
||||
|
|
@ -247,35 +247,35 @@ Pero también es posible trastear con los ReplicationControllers de forma separa
|
|||
Un único servicio puede exponer múltiples ReplicationControllers, de forma que, por ejemplo, algo de tráfico
|
||||
vaya a la versión vieja, y otro tanto vaya a la versión nueva.
|
||||
|
||||
Un ReplicationController nunca se terminará por sí mismo, pero tampoco se espera que se ejecute permanentemente como los servicios.
|
||||
Los servicios puede que estén compuestos de pods controlados por múltiples ReplicationControllers,
|
||||
y se espera que muchos ReplicationControllers se creen y se destruyan durante el ciclo de vida de un servicio (por ejemplo,
|
||||
Un ReplicationController nunca se terminará por sí mismo, pero tampoco se espera que se ejecute permanentemente como los servicios.
|
||||
Los servicios puede que estén compuestos de pods controlados por múltiples ReplicationControllers,
|
||||
y se espera que muchos ReplicationControllers se creen y se destruyan durante el ciclo de vida de un servicio (por ejemplo,
|
||||
para realizar una actualización de los pods que ejecutan el servicio). Ambos servicios mismos y sus clientes deberían permanecer
|
||||
ajenos a los ReplicationControllers que mantienen los pods que proporcionan los servicios.
|
||||
|
||||
## Escribir aplicaciones que se repliquen
|
||||
|
||||
Los Pods creados por un ReplicationController están pensados para que sean intercambiables y semánticamente idénticos,
|
||||
aunque sus configuraciones puede que sean heterogéneas a lo largo del tiempo. Este es un ajuste obvio para los servidores sin estado replicados,
|
||||
pero los ReplicationControllers también pueden utilizarse para mantener la disponibilidad de aplicaciones que se elijen por un maestro, las particionadas, y las de grupos de trabajadores.
|
||||
Dichas aplicaciones deberían usar los mecanismos de asignación dinámica de trabajo, como las [colas de trabajo RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-two-python.html),
|
||||
en vez de la personalización estática/de una sola vez en la configuración de cada pod,
|
||||
ya que se considera un anti-patrón. Cualquier personalización de pod que se haga, como el calibrado vertical automático de recursos (por ejemplo, cpu o memoria),
|
||||
Los Pods creados por un ReplicationController están pensados para que sean intercambiables y semánticamente idénticos,
|
||||
aunque sus configuraciones puede que sean heterogéneas a lo largo del tiempo. Este es un ajuste obvio para los servidores sin estado replicados,
|
||||
pero los ReplicationControllers también pueden utilizarse para mantener la disponibilidad de aplicaciones que se elijen por un maestro, las particionadas, y las de grupos de trabajadores.
|
||||
Dichas aplicaciones deberían usar los mecanismos de asignación dinámica de trabajo, como las [colas de trabajo RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-two-python.html),
|
||||
en vez de la personalización estática/de una sola vez en la configuración de cada pod,
|
||||
ya que se considera un anti-patrón. Cualquier personalización de pod que se haga, como el calibrado vertical automático de recursos (por ejemplo, cpu o memoria),
|
||||
debería realizarse a través de otro proceso de controlador en línea, no con el mismo ReplicationController.
|
||||
|
||||
## Responsabilidades de un ReplicationController
|
||||
|
||||
El ReplicationController simplemente garantiza que el número deseado de pods coincide con su selector de etiqueta y que son operacionales.
|
||||
El ReplicationController simplemente garantiza que el número deseado de pods coincide con su selector de etiqueta y que son operacionales.
|
||||
Actualmente, sólo los pods que han terminado se excluyen de la cuenta. En el futuro, la [disponibilidad](http://issue.k8s.io/620) y otra información disponible en el sistema
|
||||
se tendrá en cuenta, se añadirá más controles sobre la regla de sussitución, y se está planificando
|
||||
se tendrá en cuenta, se añadirá más controles sobre la regla de sussitución, y se está planificando
|
||||
emitir eventos que podrían ser aprovechados por clientes externos para implementar reglas complejas de sustitución y escalado de forma arbitraria.
|
||||
|
||||
El ReplicationController está siempre condicionado a esta reducida responsabilidad.
|
||||
Él mismo no llevará a cabo ni pruebas de estar listo ni vivo. En vez de aplicar el auto-escalado,
|
||||
se pretende que este sea realizado por un auto-escalador externo (como se vio en [#492](http://issue.k8s.io/492)), que sería el encargado de cambiar su campo `replicas`.
|
||||
No se añadirá reglas de programación (por ejemplo, [propagación](http://issue.k8s.io/367#issuecomment-48428019)) al ReplicationController.
|
||||
Ni se debería validar que los pods controlados coincidan con la plantilla actual especificada, ya que eso obstruiría el auto-calibrado y otros procesos automáticos.
|
||||
De forma similar, los vencimientos de término, las dependencias de orden, la extensión de la configuración, y otras características se aplican en otro lado.
|
||||
El ReplicationController está siempre condicionado a esta reducida responsabilidad.
|
||||
Él mismo no llevará a cabo ni pruebas de estar listo ni vivo. En vez de aplicar el auto-escalado,
|
||||
se pretende que este sea realizado por un auto-escalador externo (como se vio en [#492](http://issue.k8s.io/492)), que sería el encargado de cambiar su campo `replicas`.
|
||||
No se añadirá reglas de programación (por ejemplo, [propagación](http://issue.k8s.io/367#issuecomment-48428019)) al ReplicationController.
|
||||
Ni se debería validar que los pods controlados coincidan con la plantilla actual especificada, ya que eso obstruiría el auto-calibrado y otros procesos automáticos.
|
||||
De forma similar, los vencimientos de término, las dependencias de orden, la extensión de la configuración, y otras características se aplican en otro lado.
|
||||
Incluso se plantea excluir el mecanismo de creación de pods a granel ([#170](http://issue.k8s.io/170)).
|
||||
|
||||
El ReplicationController está pensado para ser una primitiva de bloques is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
|
||||
|
|
@ -304,11 +304,11 @@ porque a diferencia del comando `kubectl rolling-update`, son declarativos, se e
|
|||
|
||||
### Pods simples
|
||||
|
||||
A diferencia del caso en que un usuario ha creado directamente pods, un ReplicationController sustituye los pods que han sido eliminador o terminados por cualquier motivo,
|
||||
A diferencia del caso en que un usuario ha creado directamente pods, un ReplicationController sustituye los pods que han sido eliminador o terminados por cualquier motivo,
|
||||
como en el caso de un fallo de un nodo o una intervención disruptiva de mantenimiento, como la actualización del kernel.
|
||||
Por esta razón, se recomienda que se usa un ReplicationController incluso si tu aplicación sólo necesita un único pod.
|
||||
Por esta razón, se recomienda que se usa un ReplicationController incluso si tu aplicación sólo necesita un único pod.
|
||||
Piensa que es similar a un supervisor de proceso, sólo que supervisa múltiples pods entre múltiples nodos en vez de
|
||||
procesos individuales en un único nodo. Un ReplicationController delega los reinicios locales de
|
||||
procesos individuales en un único nodo. Un ReplicationController delega los reinicios locales de
|
||||
los contenedores a algún agente del nodo (por ejemplo, Kubelet o Docker).
|
||||
|
||||
### Job
|
||||
|
|
|
|||
|
|
@ -104,12 +104,12 @@ spec:
|
|||
```
|
||||
|
||||
## Selector de Pod
|
||||
Debes poner el valor del campo `.spec.selector` de un StatefulSet para que coincida con las etiquetas de su campo `.spec.template.metadata.labels`. Antes de Kubernetes 1.8,
|
||||
Debes poner el valor del campo `.spec.selector` de un StatefulSet para que coincida con las etiquetas de su campo `.spec.template.metadata.labels`. Antes de Kubernetes 1.8,
|
||||
el campo `.spec.selector` se predeterminaba cuando se omitía. A partir de la versión 1.8, si no se especifica un selector de coincidencia de Pods, se produce un error de validación
|
||||
durante la creación del StatefulSet.
|
||||
|
||||
## Identidad de Pod
|
||||
Los Pods de un StatefulSet tienen una identidad única que está formada por un ordinal,
|
||||
Los Pods de un StatefulSet tienen una identidad única que está formada por un ordinal,
|
||||
una identidad estable de red, y almacenamiento estable. La identidad se asocia al Pod,
|
||||
independientemente del nodo en que haya sido (re)programado.
|
||||
|
||||
|
|
@ -131,7 +131,7 @@ Conforme se crea cada Pod, se le asigna un nombre DNS correspondiente de subdomi
|
|||
`$(podname).$(governing service domain)`, donde el servicio en funciones se define por el campo
|
||||
`serviceName` del StatefulSet.
|
||||
|
||||
Como se indicó en la sección [limitaciones](#limitaciones), la creación del
|
||||
Como se indicó en la sección [limitaciones](#limitaciones), la creación del
|
||||
[Servicio Headless](/docs/concepts/services-networking/service/#headless-services)
|
||||
encargado de la identidad de red de los pods es enteramente tu responsabilidad.
|
||||
|
||||
|
|
@ -153,17 +153,17 @@ El valor de Cluster Domain se pondrá a `cluster.local` a menos que
|
|||
|
||||
Kubernetes crea un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) para cada
|
||||
VolumeClaimTemplate. En el ejemplo de nginx de arriba, cada Pod recibirá un único PersistentVolume
|
||||
con una StorageClass igual a `my-storage-class` y 1 Gib de almacenamiento provisionado. Si no se indica ninguna StorageClass,
|
||||
con una StorageClass igual a `my-storage-class` y 1 Gib de almacenamiento provisionado. Si no se indica ninguna StorageClass,
|
||||
entonces se usa la StorageClass por defecto. Cuando un Pod se (re)programa
|
||||
en un nodo, sus `volumeMounts` montan los PersistentVolumes asociados con sus
|
||||
PersistentVolume Claims. Nótese que los PersistentVolumes asociados con los
|
||||
PersistentVolume Claims. Nótese que los PersistentVolumes asociados con los
|
||||
PersistentVolume Claims de los Pods no se eliminan cuando los Pods, o los StatefulSet se eliminan.
|
||||
Esto debe realizarse manualmente.
|
||||
|
||||
### Etiqueta de Nombre de Pod
|
||||
|
||||
Cuando el controlador del StatefulSet crea un Pod, añade una etiqueta, `statefulset.kubernetes.io/pod-name`,
|
||||
que toma el valor del nombre del Pod. Esta etiqueta te permite enlazar un Service a un Pod específico
|
||||
Cuando el controlador del StatefulSet crea un Pod, añade una etiqueta, `statefulset.kubernetes.io/pod-name`,
|
||||
que toma el valor del nombre del Pod. Esta etiqueta te permite enlazar un Service a un Pod específico
|
||||
en el StatefulSet.
|
||||
|
||||
## Garantías de Despliegue y Escalado
|
||||
|
|
@ -173,12 +173,12 @@ en el StatefulSet.
|
|||
* Antes de que una operación de escalado se aplique a un Pod, todos sus predecesores deben estar Running y Ready.
|
||||
* Antes de que se termine un Pod, todos sus sucesores deben haberse apagado completamente.
|
||||
|
||||
El StatefulSet no debería tener que indicar un valor 0 para el campo `pod.Spec.TerminationGracePeriodSeconds`.
|
||||
El StatefulSet no debería tener que indicar un valor 0 para el campo `pod.Spec.TerminationGracePeriodSeconds`.
|
||||
Esta práctica no es segura y se aconseja no hacerlo. Para una explicación más detallada, por favor echa un vistazo a cómo [forzar la eliminación de Pods de un StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
|
||||
|
||||
Cuando el ejemplo nginx de arriba se crea, se despliegan tres Pods en el orden
|
||||
Cuando el ejemplo nginx de arriba se crea, se despliegan tres Pods en el orden
|
||||
web-0, web-1, web-2. web-1 no se desplegará hasta que web-0 no esté
|
||||
[Running y Ready](/docs/user-guide/pod-states/), y web-2 no se desplegará hasta que
|
||||
[Running y Ready](/docs/user-guide/pod-states/), y web-2 no se desplegará hasta que
|
||||
web-1 esté Running y Ready. En caso de que web-0 fallase, después de que web-1 estuviera Running y Ready, pero antes
|
||||
de que se desplegara web-2, web-2 no se desplegaría hasta que web-0 se redesplegase con éxito y estuviera
|
||||
Running y Ready.
|
||||
|
|
@ -207,7 +207,7 @@ y Ready o completamente terminados antes de lanzar o terminar otro Pod.
|
|||
## Estrategias de Actualización
|
||||
|
||||
En Kubernetes 1.7 y a posteriori, el campo `.spec.updateStrategy` del StatefulSet permite configurar
|
||||
y deshabilitar las actualizaciones automátizadas en línea para los contenedores, etiquetas, peticiones/límites de recursos,
|
||||
y deshabilitar las actualizaciones automátizadas en línea para los contenedores, etiquetas, peticiones/límites de recursos,
|
||||
y anotaciones de los Pods del StatefulSet.
|
||||
|
||||
### On Delete
|
||||
|
|
@ -228,14 +228,14 @@ actualizar su predecesor.
|
|||
|
||||
#### Particiones
|
||||
|
||||
La estrategia de actualización `RollingUpdate` puede particionarse, indicando el valor del campo
|
||||
La estrategia de actualización `RollingUpdate` puede particionarse, indicando el valor del campo
|
||||
`.spec.updateStrategy.rollingUpdate.partition`. Si se indica una partición, todos los Pods con un
|
||||
número ordinal mayor o igual que el de la partición serán actualizados cuando el campo `.spec.template`
|
||||
del StatefulSet se actualice. Todos los Pods con un número ordinal que sea menor que el de la partición
|
||||
número ordinal mayor o igual que el de la partición serán actualizados cuando el campo `.spec.template`
|
||||
del StatefulSet se actualice. Todos los Pods con un número ordinal que sea menor que el de la partición
|
||||
no serán actualizados, e incluso si son eliminados, serán recreados con la versión anterior. Si el campo
|
||||
`.spec.updateStrategy.rollingUpdate.partition` de un StatefulSet es mayor que el valor del campo `.spec.replicas`,
|
||||
las modificaciones al campo `.spec.template` no se propagarán a sus Pods.
|
||||
En la mayoría de ocasiones, no necesitarás usar una partición, pero pueden resultar útiles si quieres preparar una actualización,
|
||||
En la mayoría de ocasiones, no necesitarás usar una partición, pero pueden resultar útiles si quieres preparar una actualización,
|
||||
realizar un despliegue tipo canary, o llevar a cabo un despliegue en fases.
|
||||
|
||||
#### Retroceso Forzado
|
||||
|
|
|
|||
|
|
@ -29,11 +29,11 @@ Descargo de responsabilidad Alpha: esta característica está actualmente en ver
|
|||
## Controlador TTL
|
||||
|
||||
El controlador TTL sólo soporta los Jobs por ahora. Un operador del clúster puede usar esta funcionalidad para limpiar
|
||||
los Jobs terminados (bien `Complete` o `Failed`) automáticamente especificando el valor del campo
|
||||
`.spec.ttlSecondsAfterFinished` del Job, como en este
|
||||
los Jobs terminados (bien `Complete` o `Failed`) automáticamente especificando el valor del campo
|
||||
`.spec.ttlSecondsAfterFinished` del Job, como en este
|
||||
[ejemplo](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
|
||||
El controlador TTL asumirá que un recurso es candidato a ser limpiado
|
||||
TTL segundos después de que el recurso haya terminado; dicho de otra forma, cuando el TTL haya expirado.
|
||||
El controlador TTL asumirá que un recurso es candidato a ser limpiado
|
||||
TTL segundos después de que el recurso haya terminado; dicho de otra forma, cuando el TTL haya expirado.
|
||||
Cuando el controlador TTL limpia un recursos, lo elimina en cascada, esto es, borra
|
||||
sus objetos subordinados juntos. Nótese que cuando se elimina un recurso,
|
||||
se respetan las garantías de su ciclo de vida, como con los finalizadores.
|
||||
|
|
@ -47,9 +47,9 @@ Los segundos TTL pueden ser configurados en cualquier momento. Aquí se muestran
|
|||
* Usando un [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
para poner el valor de este campo dinámicamente en el momento de la creación del recursos. Los administradores del clúster pueden
|
||||
usar este enfoque para forzar una regla TTL para los recursos terminados.
|
||||
* Usando un
|
||||
* Usando un
|
||||
[mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
|
||||
para poner el valor de este campo dinámicamente después de que el recurso haya terminado,
|
||||
para poner el valor de este campo dinámicamente después de que el recurso haya terminado,
|
||||
y eligiendo diferentes valores TTL basados en los estados de los recursos, etiquetas, etc.
|
||||
|
||||
## Advertencia
|
||||
|
|
@ -71,7 +71,7 @@ en momentos equivocados.
|
|||
|
||||
En Kubernetes, se necesita ejecutar NTP en todos los nodos
|
||||
(ver [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058))
|
||||
para evitar este problema. Los relojes no siempre son correctos, pero la diferencia debería ser muy pequeña.
|
||||
para evitar este problema. Los relojes no siempre son correctos, pero la diferencia debería ser muy pequeña.
|
||||
Ten presente este riesgo cuando pongas un valor distinto de cero para el TTL.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -2,17 +2,17 @@
|
|||
title: Arquitecto/a de aplicaciones
|
||||
id: application-architect
|
||||
date: 2019-05-16
|
||||
full_link:
|
||||
full_link:
|
||||
short_description: >
|
||||
Una de las personas responsables del diseño a alto nivel de una aplicación.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- user-type
|
||||
---
|
||||
Una de las personas responsables del diseño a alto nivel de una aplicación.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Un/a arquitecto/a garantiza que la implementación de una aplicación le permita interactuar con otros componentes de su entorno de forma escalable y mantenible. Estos componentes pueden ser bases de datos, infraestructura de _logs_ u otros microservicios.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,17 +2,17 @@
|
|||
title: Desarrollador/a de aplicaciones
|
||||
id: application-developer
|
||||
date: 2019-05-16
|
||||
full_link:
|
||||
full_link:
|
||||
short_description: >
|
||||
Una persona que escribe una aplicación que se ejecutará en un clúster de Kubernetes.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- user-type
|
||||
---
|
||||
Una persona que escribe una aplicación que se ejecutará en un clúster de Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Un/a desarrollador/a de aplicaciones escribe, depura y mantiene el código fuente de la aplicación. La aplicación puede ser el resultado del trabajo de una sola persona o de un equipo.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,12 +6,12 @@ full_link: /docs/tasks/tls/managing-tls-in-a-cluster/
|
|||
short_description: >
|
||||
Un fichero criptográficamente seguro usado para validar el acceso al clúster de Kubernetes.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- security
|
||||
---
|
||||
Un fichero criptográficamente seguro usado para validar el acceso al clúster de Kubernetes.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Los Certificates (certificados en español) permiten que las aplicaciones dentro del clúster accedan a la API de Kubernetes de forma segura. Los certificados sirven para validar que un cliente tiene permiso para acceder a la API.
|
||||
|
|
@ -6,14 +6,14 @@ full_link: /docs/concepts/overview/what-is-kubernetes/#why-containers
|
|||
short_description: >
|
||||
Una imagen ligera y portátil que contiene un software y todas sus dependencias.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- workload
|
||||
---
|
||||
Una imagen ligera y portátil que contiene un software y todas sus dependencias.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Los contenedores desacoplan la aplicaciones de la infraestructura subyacente del servidor
|
||||
donde se ejecutan para facilitar el despliegue en diferentes proveedores de nube o entornos de SO, y para un escalado más eficiente.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ full_link: /docs/concepts/workloads/controllers/deployment/
|
|||
short_description: >
|
||||
Un objeto API que gestiona una aplicación replicada.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
|
|
@ -14,8 +14,8 @@ tags:
|
|||
---
|
||||
Un objeto API que gestiona una aplicación replicada.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Cada réplica se representa por un {{< glossary_tooltip term_id="pod" >}},
|
||||
Cada réplica se representa por un {{< glossary_tooltip term_id="pod" >}},
|
||||
y los Pods se distribuyen a lo largo de los nodos del clúster.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,16 +2,16 @@
|
|||
title: Image
|
||||
id: image
|
||||
date: 2018-04-12
|
||||
full_link:
|
||||
full_link:
|
||||
short_description: >
|
||||
Instantánea de un contenedor que contiene un conjunto de librerías necesarias para ejecutar la aplicación.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Instantánea de un contenedor que contiene un conjunto de librerías necesarias para ejecutar la aplicación.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Mecanismo para empaquetar software que permite almacenarlo en un registro de contenedores, descargarlo al entorno local y ejecutarlo como una aplicación. Los metadatos se incluyen en la imagen y proporcionan información diversa como el ejecutable por defecto o quién la ha construido.
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ full_link: /docs/concepts/workloads/controllers/jobs-run-to-completion
|
|||
short_description: >
|
||||
Una tarea finita o por lotes que se ejecuta hasta su finalización.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
|
|
@ -14,7 +14,7 @@ tags:
|
|||
---
|
||||
Una tarea finita o por lotes que se ejecuta hasta su finalización.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Crea uno o más objetos {{< glossary_tooltip term_id="pod" >}} y se asegura que un número específico de los mismos finalicen con éxito. A medida que los Pods terminan, el objeto Job registra las ejecuciones completadas correctamente.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,14 +6,14 @@ full_link: /docs/getting-started-guides/kops/
|
|||
short_description: >
|
||||
Herramienta de línea de comandos que facilita la creación, destrucción, actualización y mantenimiento de clústeres de Kubernetes en alta disponibilidad para entornos de producción. *NOTA: Oficialmente solo soporta AWS, aunque también ofrece soporte para GCE en beta y WMware vSphere en versión alpha*.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
- operation
|
||||
---
|
||||
Herramienta de línea de comandos que facilita la creación, destrucción, actualización y mantenimiento de clústeres de Kubernetes en alta disponibilidad para entornos de producción. *NOTA: Oficialmente solo soporta AWS, aunque también ofrece soporte para GCE en beta y WMware vSphere en versión alpha*.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
`kops` provisiona el clúster con:
|
||||
|
||||
|
|
|
|||
|
|
@ -6,20 +6,20 @@ full_link: /docs/reference/command-line-tools-reference/kube-proxy/
|
|||
short_description: >
|
||||
`kube-proxy` es un componente de red que se ejecuta en cada nodo del clúster.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- networking
|
||||
---
|
||||
[kube-proxy](/es/docs/reference/command-line-tools-reference/kube-proxy/) es un
|
||||
componente de red que se ejecuta en cada uno de los nodos del clúster, implementando
|
||||
componente de red que se ejecuta en cada uno de los nodos del clúster, implementando
|
||||
parte del concepto de Kubernetes {{< glossary_tooltip term_id="service">}}.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
kube-proxy mantiene las reglas de red en los nodos, permitiendo la
|
||||
comunicación entre sus Pods desde las sesiones de red dentro o fuera
|
||||
del clúster.
|
||||
|
||||
kube-proxy usa la capa de filtrado de paquetes del sistema operativo si la hay
|
||||
kube-proxy usa la capa de filtrado de paquetes del sistema operativo si la hay
|
||||
y está disponible; de lo contrario, kube-proxy reenvía el tráfico por sí mismo.
|
||||
|
|
|
|||
|
|
@ -6,13 +6,13 @@ full_link: /docs/admin/kubeadm/
|
|||
short_description: >
|
||||
Utilidad para instalar Kubernetes con rapidez y configurar un clúster seguro.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
- operation
|
||||
---
|
||||
Utilidad para instalar Kubernetes con rapidez y configurar un clúster seguro.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Puedes usar kubeadm para instalar el Control Plane, formado por los nodos _master_, y también los componentes de nodos _worker_.
|
||||
|
|
|
|||
|
|
@ -6,13 +6,13 @@ full_link: /docs/user-guide/kubectl-overview/
|
|||
short_description: >
|
||||
Herramienta de línea de comandos para comunicarse con un servidor ejecutando la API de Kubernetes.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- tool
|
||||
- fundamental
|
||||
---
|
||||
Herramienta de línea de comandos para comunicarse con un servidor ejecutando la {{< glossary_tooltip text="API de Kubernetes" term_id="kubernetes-api" >}}.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Puedes usar kubectl para crear, inspeccionar, actualizar y borrar objetos de Kubernetes.
|
||||
|
|
|
|||
|
|
@ -6,15 +6,15 @@ full_link: /docs/reference/generated/kubelet
|
|||
short_description: >
|
||||
Agente que se ejecuta en cada nodo de un clúster. Se asegura de que los contenedores estén corriendo en un pod.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
---
|
||||
Agente que se ejecuta en cada nodo de un clúster. Se asegura de que los contenedores estén corriendo en un pod.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
El agente kubelet toma un conjunto de especificaciones de {{< glossary_tooltip text="Pod" term_id="pod" >}}, llamados
|
||||
PodSpecs, que han sido creados por Kubernetes y garantiza que los contenedores descritos en ellos estén funcionando y
|
||||
El agente kubelet toma un conjunto de especificaciones de {{< glossary_tooltip text="Pod" term_id="pod" >}}, llamados
|
||||
PodSpecs, que han sido creados por Kubernetes y garantiza que los contenedores descritos en ellos estén funcionando y
|
||||
en buen estado.
|
||||
|
|
|
|||
|
|
@ -6,13 +6,13 @@ full_link: /docs/getting-started-guides/minikube/
|
|||
short_description: >
|
||||
Herramienta para ejecutar Kubernetes de forma local.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- tool
|
||||
---
|
||||
Herramienta para ejecutar Kubernetes de forma local.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Minikube ejecuta un clúster de un solo nodo en una máquina virtual (VM) en tu máquina local.
|
||||
|
|
|
|||
|
|
@ -6,12 +6,12 @@ full_link: /docs/concepts/overview/working-with-objects/names
|
|||
short_description: >
|
||||
Una cadena de caracteres proporcionada por el cliente que identifica un objeto en la URL de un recurso, como por ejemplo, `/api/v1/pods/nombre-del-objeto`.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Una cadena de caracteres proporcionada por el cliente que identifica un objeto en la URL de un recurso, como por ejemplo, `/api/v1/pods/nombre-del-objeto`.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Los nombres de los objetos son únicos para cada tipo de objeto. Sin embargo, si se elimina el objeto, se puede crear un nuevo objeto con el mismo nombre.
|
||||
|
|
@ -6,13 +6,13 @@ full_link: /docs/concepts/storage/persistent-volumes/
|
|||
short_description: >
|
||||
Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- storage
|
||||
---
|
||||
Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Especifica la cantidad de almacenamiento, cómo acceder a él (sólo lectura, lectura y escritura y/o exclusivo) y qué hacer una vez eliminemos el PersistentVolumeClaim (mantener, reciclar o eliminar). Los detalles sobre almacenamiento están disponibles en la especificación de PersistentVolume.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ id: pod-priority
|
|||
date: 2019-01-31
|
||||
full_link: /docs/concepts/configuration/pod-priority-preemption/#pod-priority
|
||||
short_description: >
|
||||
Pod Priority indica la importancia de un {{< glossary_tooltip text="Pod" term_id="pod" >}} con relación a otros {{< glossary_tooltip text="Pods" term_id="pod" >}}.
|
||||
Pod Priority indica la importancia de un {{< glossary_tooltip text="Pod" term_id="pod" >}} con relación a otros {{< glossary_tooltip text="Pods" term_id="pod" >}}.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
|
|
@ -14,4 +14,4 @@ tags:
|
|||
|
||||
<!--more-->
|
||||
|
||||
[Pod Priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) da la habilidad de configurar prioridades del programador de un {{< glossary_tooltip text="Pod" term_id="pod" >}} más altas o bajas que otros {{< glossary_tooltip text="Pods" term_id="pod" >}} - lo cual es una característica importante para cargas de trabajo en producción.
|
||||
[Pod Priority](/docs/concepts/configuration/pod-priority-preemption/#pod-priority) da la habilidad de configurar prioridades del programador de un {{< glossary_tooltip text="Pod" term_id="pod" >}} más altas o bajas que otros {{< glossary_tooltip text="Pods" term_id="pod" >}} - lo cual es una característica importante para cargas de trabajo en producción.
|
||||
|
|
|
|||
|
|
@ -6,14 +6,14 @@ full_link: /docs/concepts/workloads/pods/pod-overview/
|
|||
short_description: >
|
||||
El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más contenedores ejecutándose en el clúster.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
El objeto más pequeño y simple de Kubernetes. Un Pod es la unidad mínima de computación en Kubernetes y representa uno o más {{< glossary_tooltip text="contenedores" term_id="container" >}} ejecutándose en el clúster.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Normalmente un Pod se configura para ejecutar un solo contenedor primario, pero también puede ejecutar contenedores adicionales para implementar diferentes patrones como _sidecar_ o _ambassador_. Estos contenedores pueden ser parte de la aplicación o simplemente añadir funcionalidades adicionales como gestión de logs o actuar de proxy. Los Pods son comúnmente gestionados por un {{< glossary_tooltip term_id="deployment" >}}.
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ full_link: /docs/concepts/workloads/controllers/replicaset/
|
|||
short_description: >
|
||||
El ReplicaSet es la nueva generación del ReplicationController.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- core-object
|
||||
|
|
@ -14,6 +14,6 @@ tags:
|
|||
---
|
||||
El ReplicaSet es la nueva generación del ReplicationController.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Un ReplicaSet, análogamente a un {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}, garantiza que un número establecido de réplicas de un pod estén corriendo en un momento dado. El ReplicaSet tiene soporte para selectores del tipo set-based, lo que permite el filtrado de claves por grupos de valores como por ejemplo todos los pods cuya etiqueta `environment` no sea `production` ni `qa`. Por otro lado, el ReplicationController solo soporta selectores equality-based, es decir, que solo puedes filtrar por valores exactos como por ejemplo, los pods que tengan la etiqueta `tier` con valor `frontend`.
|
||||
|
|
|
|||
|
|
@ -6,13 +6,13 @@ full_link: /docs/concepts/configuration/secret/
|
|||
short_description: >
|
||||
Almacena información sensible, como contraseñas, tokens OAuth o claves ssh.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- security
|
||||
---
|
||||
Un Secret, secreto en castellano, almacena información sensible, como contraseñas, tokens OAuth o claves ssh.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Ofrece un mayor control sobre cómo usar información sensible y reduce el riesgo de exposición accidental, incluyendo [encriptado](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) en reposo. Un {{< glossary_tooltip text="Pod" term_id="pod" >}} referencia el secreto como un simple fichero en un volumen montado o como variables de entorno accesibles en los Containers. Los secretos son ideales para datos confidenciales y los [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) para datos no confidenciales.
|
||||
|
|
|
|||
|
|
@ -6,13 +6,13 @@ full_link: /docs/concepts/overview/working-with-objects/labels/
|
|||
short_description: >
|
||||
Permite a los usuarios filtrar recursos por {{< glossary_tooltip text="Labels" term_id="label" >}}.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Permite a los usuarios filtrar recursos por Labels.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Los Selectors se aplican al realizar consultas de listas de recursos para ser filtrados por {{< glossary_tooltip text="Labels" term_id="label" >}}.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ id: statefulset
|
|||
date: 2018-04-12
|
||||
full_link: /docs/concepts/workloads/controllers/statefulset/
|
||||
short_description: >
|
||||
Gestiona el despliegue y escalado de un conjunto de Pods,
|
||||
Gestiona el despliegue y escalado de un conjunto de Pods,
|
||||
*y garantiza el orden y unicidad* de dichos Pods.
|
||||
|
||||
tags:
|
||||
|
|
@ -13,18 +13,18 @@ tags:
|
|||
- workload
|
||||
- storage
|
||||
---
|
||||
Gestiona el despliegue y escalado de un conjunto de {{< glossary_tooltip text="Pods" term_id="pod" >}},
|
||||
Gestiona el despliegue y escalado de un conjunto de {{< glossary_tooltip text="Pods" term_id="pod" >}},
|
||||
*y garantiza el orden y unicidad* de dichos Pods.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Al igual que un {{< glossary_tooltip term_id="deployment" >}}, un StatefulSet gestiona Pods
|
||||
que se basan en una especificación idéntica de contenedor. A diferencia de un Deployment, un
|
||||
Al igual que un {{< glossary_tooltip term_id="deployment" >}}, un StatefulSet gestiona Pods
|
||||
que se basan en una especificación idéntica de contenedor. A diferencia de un Deployment, un
|
||||
StatefulSet mantiene una identidad asociada a sus Pods. Estos pods se crean a partir de la
|
||||
misma especificación, pero no pueden intercambiarse; cada uno tiene su propio identificador persistente
|
||||
que mantiene a lo largo de cualquier re-programación.
|
||||
|
||||
Un StatefulSet opera bajo el mismo patrón que cualquier otro controlador.
|
||||
Se define el estado deseado en un *objeto* StatefulSet, y el *controlador* del StatefulSet efectúa
|
||||
Un StatefulSet opera bajo el mismo patrón que cualquier otro controlador.
|
||||
Se define el estado deseado en un *objeto* StatefulSet, y el *controlador* del StatefulSet efectúa
|
||||
las actualizaciones que sean necesarias para alcanzarlo a partir del estado actual.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ aka:
|
|||
tags:
|
||||
- tool
|
||||
---
|
||||
`sysctl` es una interfaz común usada para consultar o modificar atributos del
|
||||
`sysctl` es una interfaz común usada para consultar o modificar atributos del
|
||||
núcleo Unix durante su ejecución.
|
||||
|
||||
<!--more-->
|
||||
|
|
@ -19,5 +19,5 @@ En los sistemas Unix-like, `sysctl` es el comando que usan los administradores,
|
|||
para ver o modificar esos valores y también el nombre de la llamada al sistema
|
||||
que realiza esta función.
|
||||
|
||||
La ejecución del {{< glossary_tooltip text="Contenedor" term_id="container" >}}
|
||||
La ejecución del {{< glossary_tooltip text="Contenedor" term_id="container" >}}
|
||||
y de los complementos de red puede depender de los valores asignados via `sysctl`.
|
||||
|
|
|
|||
|
|
@ -6,12 +6,12 @@ full_link: /docs/concepts/overview/working-with-objects/names
|
|||
short_description: >
|
||||
Una cadena de caracteres generada por Kubernetes para identificar objetos de forma única.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
---
|
||||
Una cadena de caracteres generada por Kubernetes para identificar objetos de forma única.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Cada objeto creado a lo largo de toda la vida de un clúster Kubernetes tiene un UID distinto. Está pensado para distinguir entre ocurrencias históricas de entidades similares.
|
||||
|
|
@ -6,13 +6,13 @@ full_link: /docs/concepts/storage/volumes/
|
|||
short_description: >
|
||||
Un directorio que contiene datos y que es accesible desde los contenedores corriendo en un pod.
|
||||
|
||||
aka:
|
||||
aka:
|
||||
tags:
|
||||
- core-object
|
||||
- fundamental
|
||||
---
|
||||
Un directorio que contiene datos y que es accesible desde los contenedores corriendo en un {{< glossary_tooltip text="pod" term_id="pod" >}}.
|
||||
|
||||
<!--more-->
|
||||
<!--more-->
|
||||
|
||||
Un volumen de Kubernetes vive mientras exista el {{< glossary_tooltip text="pod" term_id="pod" >}} que lo contiene, no depende de la vida del {{< glossary_tooltip text="contenedor" term_id="container" >}} por eso se conservan los datos entre los reinicios de los {{< glossary_tooltip text="contenedores" term_id="container" >}}.
|
||||
Un volumen de Kubernetes vive mientras exista el {{< glossary_tooltip text="pod" term_id="pod" >}} que lo contiene, no depende de la vida del {{< glossary_tooltip text="contenedor" term_id="container" >}} por eso se conservan los datos entre los reinicios de los {{< glossary_tooltip text="contenedores" term_id="container" >}}.
|
||||
|
|
|
|||
|
|
@ -80,6 +80,6 @@ Deberías elegir una solución de este tipo si:
|
|||
## Soluciones personalizadas
|
||||
|
||||
Una solución personalizadas proporciona total libertad sobre los clústeres
|
||||
pero requiere más conocimiento y experiencia.
|
||||
pero requiere más conocimiento y experiencia.
|
||||
|
||||
{{% /capture %}}
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ cd kubernetes
|
|||
make release
|
||||
```
|
||||
|
||||
Para más detalles sobre el proceso de compilación de una release, visita la carpeta kubernetes/kubernetes [`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)
|
||||
Para más detalles sobre el proceso de compilación de una release, visita la carpeta kubernetes/kubernetes [`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/)
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@ En el uso típico, se usaría un solo presupuesto para una colección de pods ad
|
|||
un controlador, por ejemplo, los pods en un solo ReplicaSet o StatefulSet.
|
||||
|
||||
{{< note >}}
|
||||
Un presupuesto de disrupción no garantiza que el número/porcentaje de pods especificado
|
||||
Un presupuesto de disrupción no garantiza que el número/porcentaje de pods especificado
|
||||
siempre estarán disponibles. Por ejemplo, un nodo que alberga un
|
||||
pod del grupo puede fallar cuando el grupo está en el tamaño mínimo
|
||||
especificados en el presupuesto, lo que hace que el número de pods disponibles este por debajo del tamaño especificado. El presupuesto solo puede proteger contra
|
||||
|
|
|
|||
|
|
@ -91,7 +91,7 @@ Si estás en macOS y usando el gestor de paquetes [Macports](https://macports.or
|
|||
sudo port selfupdate
|
||||
sudo port install kubectl
|
||||
```
|
||||
|
||||
|
||||
2. Para asegurar que la versión utilizada sea la más actual puedes probar:
|
||||
|
||||
```
|
||||
|
|
@ -108,9 +108,9 @@ Si estás en Windows y usando el gestor de paquetes [Powershell Gallery](https:/
|
|||
Install-Script -Name install-kubectl -Scope CurrentUser -Force
|
||||
install-kubectl.ps1 [-DownloadLocation <path>]
|
||||
```
|
||||
|
||||
|
||||
{{< note >}}Si no especificas una `DownloadLocation`, `kubectl` se instalará en el directorio temporal del usuario.{{< /note >}}
|
||||
|
||||
|
||||
El instalador crea `$HOME/.kube` y crea un archivo de configuración
|
||||
|
||||
2. Para asegurar que la versión utilizada sea la más actual puedes probar:
|
||||
|
|
@ -164,7 +164,7 @@ Para instalar kubectl en Windows puedes usar bien el gestor de paquetes [Chocola
|
|||
```
|
||||
New-Item config -type file
|
||||
```
|
||||
|
||||
|
||||
{{< note >}}Edita el fichero de configuración con un editor de texto de tu elección, como Notepad.{{< /note >}}
|
||||
|
||||
## Descarga como parte del Google Cloud SDK
|
||||
|
|
@ -177,7 +177,7 @@ Puedes instalar kubectl como parte del Google Cloud SDK.
|
|||
```
|
||||
gcloud components install kubectl
|
||||
```
|
||||
|
||||
|
||||
3. Para asegurar que la versión utilizada sea la más actual puedes probar:
|
||||
|
||||
```
|
||||
|
|
@ -190,14 +190,14 @@ Puedes instalar kubectl como parte del Google Cloud SDK.
|
|||
{{% tab name="macOS" %}}
|
||||
1. Descarga la última entrega:
|
||||
|
||||
```
|
||||
```
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/darwin/amd64/kubectl
|
||||
```
|
||||
|
||||
Para descargar una versión específica, remplaza el comando `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` con la versión específica.
|
||||
|
||||
Por ejemplo, para descargar la versión {{< param "fullversion" >}} en macOS, teclea:
|
||||
|
||||
|
||||
```
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/darwin/amd64/kubectl
|
||||
```
|
||||
|
|
@ -225,7 +225,7 @@ Puedes instalar kubectl como parte del Google Cloud SDK.
|
|||
Para descargar una versión específica, remplaza el trozo del comando `$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)` con la versión específica.
|
||||
|
||||
Por ejemplo, para descargar la versión {{< param "fullversion" >}} en Linux, teclea:
|
||||
|
||||
|
||||
```
|
||||
curl -LO https://storage.googleapis.com/kubernetes-release/release/{{< param "fullversion" >}}/bin/linux/amd64/kubectl
|
||||
```
|
||||
|
|
|
|||
Loading…
Reference in New Issue