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

Merge branch 'master' of https://github.com/kubernetes/website into es/docs/concepts_workloads_controllers/jobs-run_and_replicaset

Browse Source
This commit is contained in:
Enrique Medina Montenegro
2020-06-07 10:14:37 +02:00
parent edad9d9e8d 409243673d
commit 041daa48a3
4380 changed files with 418943 additions and 434664 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/es/docs/_index.md
+2 -2
View File
@@ -10,7 +10,7 @@ content_template: templates/concept
**¡Bienvenido a la documentación de Kubernetes en Castellano!**
Cómo podrá comprobar, la mayor parte de la documentación aún está disponible solo en inglés, pero no se preocupes, hay un equipo trabajando en la traducción al castellano.
Como podrá comprobar, la mayor parte de la documentación aún está disponible solo en inglés, pero no se preocupe, hay un equipo trabajando en la traducción al castellano.
{{% /capture %}}
@@ -20,4 +20,4 @@ Si quiere participar, puede entrar al canal de Slack [#kubernets-docs-es](http:/
También puede pasar por el canal para solicitar la traducción de alguna página en concreto o reportar algún error que se haya podido encontrar. ¡Cualquier aportación será bien recibida!
Para más información sobre como contribuir, echa un vistazo a [github.com/kubernetes/website](https://github.com/kubernetes/website/).
Para más información sobre cómo contribuir, echa un vistazo a [github.com/kubernetes/website](https://github.com/kubernetes/website/).
content/es/docs/concepts/_index.md
+1 -1
View File
@@ -15,7 +15,7 @@ La sección de conceptos te ayudará a conocer los componentes de Kubernetes as
## Introducción
En Kubernetes se utilizan objetos *objetos de la API de Kubernetes* para describir el *estado deseado* del clúster: qué aplicaciones u otras cargas de trabajo se quieren ejecutar, qué imagenes de contendores usan, el número de replicas, qué red y qué recursos de almacenamiento quieres que tengan disponibles, etc. Se especifica el estado deseado del clúster mediante la creación de objetos usando la API de Kubernetes, típicamente mediante la interfaz de línea de comandos, `kubectl`. También se puede usar la API de Kubernetes directamente para interactuar con el clúster y especificar o modificar tu estado deseado.
En Kubernetes se utilizan los *objetos de la API de Kubernetes* para describir el *estado deseado* del clúster: qué aplicaciones u otras cargas de trabajo se quieren ejecutar, qué imagenes de contenedores usan, el número de replicas, qué red y qué recursos de almacenamiento quieres que tengan disponibles, etc. Se especifica el estado deseado del clúster mediante la creación de objetos usando la API de Kubernetes, típicamente mediante la interfaz de línea de comandos, `kubectl`. También se puede usar la API de Kubernetes directamente para interactuar con el clúster y especificar o modificar tu estado deseado.
Una vez que se especifica el estado deseado, el *Plano de Control de Kubernetes* realizará las acciones necesarias para que el estado actual del clúster coincida con el estado deseado. Para ello, Kubernetes realiza diferentes tareas de forma automática, como pueden ser: parar o arrancar contenedores, escalar el número de réplicas de una aplicación dada, etc. El Plano de Control de Kubernetes consiste en un grupo de procesos que corren en tu clúster:
content/es/docs/concepts/architecture/cloud-controller.md
+7 -7
View File
@@ -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:
@@ -225,9 +225,9 @@ Los siguientes proveedores de servicios en la nube han implementado CCMs:
* [Digital Ocean](https://github.com/digitalocean/digitalocean-cloud-controller-manager)
* [Oracle](https://github.com/oracle/oci-cloud-controller-manager)
* [Azure](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/azure)
* [GCE](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/gce)
* [AWS](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider/providers/aws)
* [Azure](https://github.com/kubernetes/cloud-provider-azure)
* [GCP](https://github.com/kubernetes/cloud-provider-gcp)
* [AWS](https://github.com/kubernetes/cloud-provider-aws)
* [BaiduCloud](https://github.com/baidu/cloud-provider-baiducloud)
* [Linode](https://github.com/linode/linode-cloud-controller-manager)
content/es/docs/concepts/architecture/master-node-communication.md
+3 -3
View File
@@ -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
content/es/docs/concepts/architecture/nodes.md
+4 -4
View File
@@ -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.
@@ -114,7 +114,7 @@ El segundo es mantener actualizada la lista interna del controlador con la lista
El tercero es el de monitorizar la salud de los nodos. El controlador de nodos es el responsable de actualizar la condición `NodeReady` del campo `NodeStatus` a `ConditionUnknown` cuando un nodo deja de estar accesible (por ejemplo, si deja de recibir señales de vida del nodo indicando que está disponible, conocidas como latidos o `hearbeats` en inglés) y, también es responsable de posteriormente desalojar todos los pods del nodo si este continúa estando inalcanzable. Por defecto, cuando un nodo deja de responder, el controlador sigue re-intentando contactar con el nodo durante 40 segundos antes de marcar el nodo con `ConditionUnknown` y, si el nodo no se recupera de ese estado pasados 5 minutos, empezará a drenar los pods del nodo para desplegarlos en otro nodo que esté disponible. El controlador comprueba el estado de cada nodo cada `--node-monitor-period` segundos.
En versiones de Kubernetes previas a 1.13, `NodeStatus` es el `heartbeat` del nodo. Empezando con 1.13 la funcionalidad de `node lease` se introduce como alfa (`NodeLease`,
[KEP-0009](https://github.com/kubernetes/community/blob/master/keps/sig-node/0009-node-heartbeat.md)). Cuando la funcionalidad está habilitada, cada nodo tiene un objeto `Lease` asociado en el namespace `kube-node-lease` que se renueva periódicamente y ambos, el `NodeStatus` y el `Lease` son considerados como `hearbeats` del nodo. `Node leases` se renuevan con frecuencia, mientras que `NodeStatus` se transmite desde el nodo al máster únicamente si hay cambios o si ha pasado cierto tiempo (por defecto, 1 minuto, que es más que la cuenta atrás por defecto de 40 segundos que marca un nodo como inalcanzable). Al ser los `node lease` más ligeros que `NodeStatus`, los `hearbeats` resultan más económicos desde las perspectivas de escalabilidad y de rendimiento.
[KEP-0009](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md)). Cuando la funcionalidad está habilitada, cada nodo tiene un objeto `Lease` asociado en el namespace `kube-node-lease` que se renueva periódicamente y ambos, el `NodeStatus` y el `Lease` son considerados como `hearbeats` del nodo. `Node leases` se renuevan con frecuencia, mientras que `NodeStatus` se transmite desde el nodo al máster únicamente si hay cambios o si ha pasado cierto tiempo (por defecto, 1 minuto, que es más que la cuenta atrás por defecto de 40 segundos que marca un nodo como inalcanzable). Al ser los `node lease` más ligeros que `NodeStatus`, los `hearbeats` resultan más económicos desde las perspectivas de escalabilidad y de rendimiento.
En Kubernetes 1.4, se actualizó la lógica del controlador de nodos para gestionar mejor los casos en los que un gran número de nodos tiene problemas alcanzando el nodo máster (Por ejemplo, cuando el nodo máster es el que tiene un problema de red). Desde 1.4, el controlador de nodos observa el estado de todos los nodos en el clúster cuando toma decisiones sobre desalojo de pods.
@@ -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 >}}
content/es/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
+153
View File
@@ -0,0 +1,153 @@
---
title: Organizar el acceso a los clústeres utilizando archivos kubeconfig
content_template: templates/concept
weight: 60
---
{{% capture overview %}}
Utilice los archivos kubeconfig para organizar la información acerca de los clústeres, los
usuarios, los Namespaces y los mecanismos de autenticación. La herramienta de
línea de comandos `kubectl` utiliza los archivos kubeconfig para hallar la información que
necesita para escoger un clúster y comunicarse con el servidor API de un clúster.
{{< note >}}
Un archivo utilizado para configurar el acceso a los clústeres se denomina
*archivo kubeconfig*. Esta es una forma genérica de referirse a los archivos de
configuración. Esto no significa que exista un archivo llamado `kubeconfig`.
{{< /note >}}
Por defecto, `kubectl` busca un archivo llamado `config` en el directorio `$HOME/.kube`.
Puedes especificar otros archivos kubeconfig mediante la configuración de la variable
de entorno `KUBECONFIG` o mediante la configuracion del flag
[`--kubeconfig`](/docs/reference/generated/kubectl/kubectl/).
Para obtener instrucciones paso a paso acerca de cómo crear y especificar los archivos kubeconfig,
consulte el recurso
[Configurar El Acceso A Múltiples Clústeres](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
{{% /capture %}}
{{% capture body %}}
## Compatibilidad con múltiples clústeres, usuarios y mecanismos de autenticación
Suponga que tiene diversos clústeres y que sus usuarios y componentes se autentican
de diversas maneras. Por ejemplo:
- Un kubelet en ejecución se podría autenticar usando certificados.
- Un usuario se podría autenticar utilizando tokens.
- Los administradores podrían tener un conjunto de certificados que sean suministrados a los usuarios individualmente.
Con los archivos kubeconfig puedes organizar tus clústeres, usuarios y Namespaces.
También puedes definir diferentes contextos para realizar de forma rápida y
fácil cambios entre clústeres y Namespaces.
## Contexto
Un elemento *context* en un archivo kubeconfig se utiliza para agrupar los parámetros de
acceso bajo un nombre apropiado. Cada contexto tiene tres parámetros: clúster, Namespace
y usuario.
Por defecto, la herramienta de línea de comandos `kubectl` utiliza los parámetros del
*contexto actual* para comunicarse con el clúster.
Para seleccionar el contexto actual:
```shell
kubectl config use-context
```
## Variable de entorno KUBECONFIG
La variable de entorno `KUBECONFIG` contiene una lista de archivos kubeconfig.
En el caso de Linux y Mac, la lista está delimitada por dos puntos. Si se trata
de Windows, la lista está delimitada por punto y coma. La variable de entorno
`KUBECONFIG` no es indispensable. Si la variable de entorno `KUBECONFIG` no existe,
`kubectl` utiliza el archivo kubeconfig por defecto `$HOME/.kube/config`.
Si la variable de entorno `KUBECONFIG` existe, `kubectl` utiliza una
configuración eficiente que es el resultado de la fusión de los archivos
listados en la variable de entorno `KUBECONFIG`.
## Fusionando archivos kubeconfig
Para poder ver su configuración, escriba el siguiente comando:
```shell
kubectl config view
```
Como se ha descrito anteriormente, la respuesta de este comando podría resultar a partir de un solo
archivo kubeconfig, o podría ser el resultado de la fusión de varios archivos kubeconfig.
A continuación se muestran las reglas que usa `kubectl` cuando fusiona archivos kubeconfig:
1. Si el flag `--kubeconfig` está activado, usa solamente el archivo especificado. Sin fusionar.
Sólo se permite una instancia con este flag.
En caso contrario, si la variable de entorno `KUBECONFIG` está activada, sera usada
como un listado de los archivos a ser fusionados.
Fusionar los archivos listados en la variable de entorno `KUBECONFIG` de acuerdo
con estas reglas:
* Ignorar nombres de archivo vacíos.
* Producir errores para archivos con contenido que no pueden ser deserializados.
* El primer archivo que establezca un valor particular o una clave se impone.
* Nunca cambie el valor o la clave.
Ejemplo: Conserva el contexto del primer archivo para configurar el `contexto actual`.
Ejemplo: Si dos archivos especifican un `red-user`, utilice sólo los valores del primer archivo.
Incluso desechar el segundo archivo aunque tenga registros que no tengan conflictos.
Para obtener un ejemplo de configuración de la variable de entorno `KUBECONFIG`, consulte la sección
[Configuración de la variable de entorno KUBECONFIG](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable).
En caso contrario, utilice el archivo kubeconfig predeterminado `$HOME/.kube/config`, sin fusionar.
2. Determinar el contexto a utilizar con base en el primer acierto en esta secuencia:
1. Si es que existe, utilice el flag `---contexto` de la línea de comandos.
2. Utilice el `contexto actual` procedente de los archivos kubeconfig fusionados.
En este punto se permite un contexto vacío.
3. Determinar el clúster y el usuario. En este caso, puede o no haber un contexto.
Determine el clúster y el usuario con base en el primer acierto que se ejecute dos veces en
esta secuencia: una para el usuario y otra para el clúster:
1. Si es que existen, utilice el flag `--user` o `--cluster` de la línea de comandos.
2. Si el contexto no está vacío, tome el usuario o clúster del contexto.
En este caso el usuario y el clúster pueden estar vacíos.
4. Determinar la información del clúster a utilizar. En este caso, puede o no haber información del clúster.
Se construye cada pieza de la información del clúster con base en esta secuencia, el primer acierto se impone:
1. Si es que existen, use el flag `--server`, `--certificate-authority`, `--insecure-skip-tls-verify` en la línea de comandos.
2. Si existen atributos de información de clúster procedentes de los archivos kubeconfig fusionados, utilícelos.
3. Falla si no existe la ubicación del servidor.
5. Determinar la información del usuario a utilizar. Cree información de usuario utilizando las mismas reglas que
la información de clúster, con la excepción de permitir sólo un mecanismo de autenticación por usuario:
1. Si es que existen, utilice el flag `--client-certificate`, `--client-key`, `--username`, `--password`, `--token` de la línea de comandos.
2. Utilice los campos `user` de los archivos kubeconfig fusionados.
3. Falla si hay dos mecanismos de autenticación contradictorios.
6. Si todavía falta información, utilice los valores predeterminados y solicite
información de autenticación.
## Referencias de archivos
Las referencias, así también como, las rutas de un archivo kubeconfig son relativas a la ubicación del archivo kubeconfig.
Las referencias de un archivo en la línea de comandos son relativas al directorio actual de trabajo.
Dentro de `$HOME/.kube/config`, las rutas relativas se almacenan de manera relativa a la ubicación del archivo kubeconfig , al igual que las rutas absolutas
se almacenan absolutamente.
{{% /capture %}}
{{% capture whatsnext %}}
* [Configurar el acceso a multiples Clústeres](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
* [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config)
{{% /capture %}}
content/es/docs/concepts/containers/container-lifecycle-hooks.md
+120
View File
@@ -0,0 +1,120 @@
---
title: Container Lifecycle Hooks
content_template: templates/concept
weight: 30
---
{{% capture overview %}}
Esta página describe como los contenedores gestionados por kubelet pueden utilizar el framework _Container lifecycle hook_ (hook del ciclo de vida del contenedor)
para ejecutar código disparado por eventos durante la gestión de su ciclo de vida (lifecycle).
{{% /capture %}}
{{% capture body %}}
## Introducción
De manera análoga a muchos frameworks de lenguajes de programación que tienen componentes hooks de lifecycle, como Angular,
Kubernetes también proporciona esta funcionalidad para los contenedores.
Los hooks permiten a los contenedores conocer los eventos en su gestión de ciclo de vida
y ejecutar el código implementado en un controlador cuando el hook de ciclo de vida correspondiente es ejecutado.
## Hooks de contenedores
Hay dos hooks expuestos en los contenedores:
`PostStart`
Este hook se ejecuta inmediatamente después de crear un contenedor.
Sin embargo, no es posible garantizar que el hook se ejecute antes del ENTRYPOINT del contenedor.
No se le pasa ningún parámetro.
`PreStop`
Este hook se llama inmediatamente antes de que se finalice un contenedor debido a una solicitud de API o evento de gestión como un fallo liveness, o contención de recursos entre otros. Una llamada al hook de Prestop falla si el contenedor ya está en estado terminated (finalizado) o completed (completado).
Es bloqueante, lo que significa que es sincrónico,
por lo que debe completarse antes de que la llamada para eliminar el contenedor pueda ser enviada.
No se le pasa ningún parámetro.
Puedes encontrar información más detallada sobre el comportamiento de finalización de un contenedor
[Finalización de Pods](/docs/concepts/workloads/pods/pod/#termination-of-pods).
### Implementación de controladores de hooks
Los contenedores pueden acceder a un hook implementando y registrado en un controlador de este hook.
Hay dos tipos de controladores de hooks que se pueden implementar para los contenedores:
* Exec: ejecuta un comando específico, como `pre-stop.sh`, dentro de cgroups y namespaces del contenedor.
Los recursos consumidos por el comando serán tomados en cuenta para el contenedor.
* HTTP: ejecuta una petición HTTP contra un endpoint específico dentro del contenedor.
### Ejecución de controladores de hooks
Cuando se llama un hook de gestión de ciclo de vida de un contenedor,
el sistema de gestión de Kubernetes ejecuta el controlador en el contenedor registrado para este hook.
Las llamadas al controlador de hooks son síncronas dentro del contexto del Pod que contiene el contenedor.
Esto significa que para un hook `PostStart`,
el ENTRYPOINT del contenedor y el hook se disparan de forma asíncrona.
Sin embargo, si el hook tarda demasiado en ejecutarse o se cuelga,
el contenedor no puede alcanzar el estado de `running` (en ejecución).
El comportamiento es similar para un hook `PreStop`.
Si el hook se cuelga durante la ejecución,
la fase del Pod permanece en un estado de `terminating` (finalizando) y se cancela después del `terminationGracePeriodSeconds` (finalización después del periodo de gracia) del pod en cuestión.
Si un hook `PostStart` o` PreStop` falla, se mata el contenedor.
Los usuarios deben hacer que sus controladores de hooks sean lo más livianos posible.
Hay casos, sin embargo, que los comandos de larga ejecución tienen sentido,
como cuando se guarda el estado antes de detener un contenedor.
### Garantías de entrega de hooks
La entrega de un hook está destinada a ser enviada *al menos una vez*,
lo que significa que un hook puede ser llamado varias veces para cualquier evento dado,
tanto para `PostStart` como para ` PreStop`.
Depende de la implementación del hook manejar esto correctamente.
En general, solo se realizan entregas individuales.
Si, por ejemplo, un receptor hook HTTP está inactivo y no puede recibir tráfico,
no hay ningún reintento.
Sin embargo, en algunos casos puede ocurrir una doble entrega.
Por ejemplo, si un Kubelet se reinicia durante la ejecución de envio de un hook,
el hook puede volver a enviarse después de que el kubelet se levante.
### Depurando controladores de hooks
Los logs de un controlador de hooks no son expuestos en los eventos del Pod.
Si un controlador falla por alguna razón, emite un evento.
Para `PostStart`, es el evento `FailedPostStartHook`,
y para `PreStop`, el evento `FailedPreStopHook`.
Puedes ver que eventos están en ejecución con el comando `kubectl describe pod <pod_name>`.
El siguiente ejemplo muestra los eventos en ejecución a través del comando anterior:
```
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
1m 1m 1 {default-scheduler } Normal Scheduled Successfully assigned test-1730497541-cq1d2 to gke-test-cluster-default-pool-a07e5d30-siqd
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulling pulling image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Created Created container with docker id 5c6a256a2567; Security:[seccomp=unconfined]
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Pulled Successfully pulled image "test:1.0"
1m 1m 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Started Started container with docker id 5c6a256a2567
38s 38s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 5c6a256a2567: PostStart handler: Error executing in Docker Container: 1
37s 37s 1 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Normal Killing Killing container with docker id 8df9fdfd7054: PostStart handler: Error executing in Docker Container: 1
38s 37s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} Warning FailedSync Error syncing pod, skipping: failed to "StartContainer" for "main" with RunContainerError: "PostStart handler: Error executing in Docker Container: 1"
1m 22s 2 {kubelet gke-test-cluster-default-pool-a07e5d30-siqd} spec.containers{main} Warning FailedPostStartHook
```
{{% /capture %}}
{{% capture whatsnext %}}
* Aprende más sobre [variables de entorno de contenedores](/docs/concepts/containers/container-environment-variables/).
* Practica
[adjuntando controladores a los eventos de lifecycle de los contenedores](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/).
{{% /capture %}}
content/es/docs/concepts/overview/what-is-kubernetes.md
+164
View File
@@ -0,0 +1,164 @@
---
reviewers:
- raelga
title: ¿Qué es Kubernetes?
content_template: templates/concept
weight: 10
card:
name: concepts
weight: 10
---
{{% capture overview %}}
Esta página ofrece una visión general sobre Kubernetes.
{{% /capture %}}
{{% capture body %}}
Kubernetes es una plataforma portable y extensible de código abierto para
administrar cargas de trabajo y servicios. Kubernetes facilita la automatización
y la configuración declarativa. Tiene un ecosistema grande y en rápido crecimiento.
El soporte, las herramientas y los servicios para Kubernetes están ampliamente disponibles.
Google liberó el proyecto Kubernetes en el año 2014. Kubernetes se basa en [la experiencia de
Google corriendo aplicaciones en producción a gran escala por década y media](https://research.google.com/pubs/pub43438.html), junto a las mejores ideas y prácticas de la comunidad.
## ¿Por qué necesito Kubernetes y qué puede hacer por mi?
Kubernetes tiene varias características. Puedes pensar en Kubernetes como:
- una plataforma de contenedores
- una plataforma de microservicios
- una plataforma portable de nube
y mucho más.
Kubernetes ofrece un entorno de administración **centrado en contenedores**. Kubernetes
orquesta la infraestructura de cómputo, redes y almacenamiento para que las cargas de
trabajo de los usuarios no tengan que hacerlo. Esto ofrece la simplicidad de las Plataformas
como Servicio (PaaS) con la flexibilidad de la Infraestructura como Servicio (IaaS) y permite
la portabilidad entre proveedores de infraestructura.
## ¿Qué hace de Kubernetes una plataforma?
A pesar de que Kubernetes ya ofrece muchas funcionalidades, siempre hay nuevos
escenarios que se benefician de nuevas características. Los flujos de trabajo
de las aplicaciones pueden optimizarse para acelerar el tiempo de desarrollo.
Una solución de orquestación propia puede ser suficiente al principio, pero suele requerir
una automatización robusta cuando necesita escalar. Es por ello que Kubernetes fue diseñada como
una plataforma: para poder construir un ecosistema de componentes y herramientas que hacen
más fácil el desplegar, escalar y administrar aplicaciones.
Las etiquetas, o [Labels](/es/docs/concepts/overview/working-with-objects/labels/), le
permiten a los usuarios organizar sus recursos como deseen. Las anotaciones , o [Annotations](/es/docs/concepts/overview/working-with-objects/annotations/), les permiten asignar información arbitraria a un recurso para
facilitar sus flujos de trabajo y hacer más fácil a las herramientas administrativas inspeccionar el estado.
Además, el [Plano de Control](/docs/concepts/overview/components/) de Kubernetes usa las mismas
[APIs](/docs/reference/using-api/api-overview/) que usan los desarrolladores y usuarios finales.
Los usuarios pueden escribir sus propios controladores, como por ejemplo un planificador o [scheduler](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md),
usando [sus propias
APIs](/docs/concepts/api-extension/custom-resources/)
desde una [herramienta de línea de comandos](/docs/user-guide/kubectl-overview/).
Este
[diseño](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md)
ha permitido que otros sistemas sean construidos sobre Kubernetes.
## Lo que Kubernetes no es
Kubernetes no es una Plataforma como Servicio (PaaS) convencional. Ya que
Kubernetes opera a nivel del contenedor y no a nivel del hardware, ofrece
algunas características que las PaaS también ofrecen, como deployments,
escalado, balanceo de carga, registros y monitoreo. Dicho esto, Kubernetes
no es monolítico y las soluciones que se ofrecen de forma predeterminada
son opcionales e intercambiables.
Kubernetes ofrece los elementos esenciales para construir una plataforma
para desarrolladores, preservando la elección del usuario y la flexibilidad
en las partes más importantes.
Entonces, podemos decir que Kubernetes:
* No limita el tipo de aplicaciones que soporta. Kubernetes busca dar soporte a un número diverso de cargas de trabajo, que incluyen aplicaciones con y sin estado así como aplicaciones que procesan datos. Si la aplicación puede correr en un contenedor, debería correr bien en Kubernetes.
* No hace deployment de código fuente ni compila tu aplicación. Los flujos de integración, entrega y deployment continuo (CI/CD) vienen determinados por la cultura y preferencia organizacional y sus requerimientos técnicos.
* No provee servicios en capa de aplicación como middleware (por ejemplo, buses de mensaje), frameworks de procesamiento de datos (como Spark), bases de datos (como MySQL), caches o sistemas de almacenamiento (como Ceph). Es posible correr estas aplicaciones en Kubernetes, o acceder a ellos desde una aplicación usando un mecanismo portable como el Open Service Broker.
* No dictamina las soluciones de registros, monitoreo o alerta que se deben usar. Hay algunas integraciones que se ofrecen como prueba de concepto, y existen mecanismos para recolectar y exportar métricas.
* No provee ni obliga a usar un sistema o lenguaje de configuración (como [jsonnet](https://github.com/google/jsonnet)) sino que ofrece una API declarativa que puede ser usada con cualquier forma de especificación declarativa
* No provee ni adopta un sistema exhaustivo de mantenimiento, administración o corrección automática de errores
Además, Kubernetes no es un mero *sistema de orquestación*. De hecho, Kubernetes elimina la necesidad de orquestar. *Orquestación* se define como la ejecución de un flujo de trabajo definido: haz A, luego B y entonces C. Kubernetes está compuesto de un conjunto de procesos de control independientes y combinables entre si que llevan el estado actual hacia el estado deseado. No debería importar demasiado como llegar de A a C. No se requiere control centralizado y, como resultado, el sistema es más fácil de usar, más poderoso, robusto, resiliente y extensible.
## ¿Por qué usar contenedores?
¿Te preguntas las razones para usar contenedores?
![Why Containers?](/images/docs/why_containers.svg)
La *Manera Antigua* de desplegar aplicaciones era instalarlas en un
servidor usando el administrador de paquetes del sistema operativo.
La desventaja era que los ejecutables, la configuración, las librerías
y el ciclo de vida de todos estos componentes se entretejían unos a
otros. Podíamos construir imágenes de máquina virtual inmutables para
tener rollouts y rollbacks predecibles, pero las máquinas virtuales
son pesadas y poco portables.
La *Manera Nueva* es desplegar contenedores basados en virtualización
a nivel del sistema operativo, en vez del hardware. Estos contenedores
están aislados entre ellos y con el servidor anfitrión: tienen sus propios
sistemas de archivos, no ven los procesos de los demás y el uso de recursos
puede ser limitado. Son más fáciles de construir que una máquina virtual, y
porque no están acoplados a la infraestructura y sistema de archivos del
anfitrión, pueden llevarse entre nubes y distribuciones de sistema operativo.
Ya que los contenedores son pequeños y rápidos, una aplicación puede ser
empaquetada en una imagen de contenedor. Esta relación uno a uno entre
aplicación e imagen nos abre un abanico de beneficios para usar contenedores.
Con contenedores, podemos crear imágenes inmutables al momento de la compilación
en vez del despliegue ya que las aplicaciones no necesitan componerse junto al
resto del _stack_ ni atarse al entorno de infraestructura de producción. Generar
una imagen de contenedor al momento de la compilación permite tener un entorno
consistente que va desde desarrollo hasta producción. De igual forma, los contenedores
son más transparentes que las máquinas virtuales y eso hace que el monitoreo y la
administración sean más fáciles. Esto se aprecia más cuando los ciclos de vida de
los contenedores son administrados por la infraestructura en vez de un proceso supervisor
escondido en el contenedor. Por último, ya que solo hay una aplicación por contenedor,
administrar el despliegue de la aplicación se reduce a administrar el contenedor.
En resumen, los beneficios de usar contenedores incluyen:
* **Ágil creación y despliegue de aplicaciones**:
Mayor facilidad y eficiencia al crear imágenes de contenedor en vez de máquinas virtuales
* **Desarrollo, integración y despliegue continuos**:
Permite que la imagen de contenedor se construya y despliegue de forma frecuente y confiable,
facilitando los rollbacks pues la imagen es inmutable
* **Separación de tareas entre Dev y Ops**:
Puedes crear imágenes de contenedor al momento de compilar y no al desplegar, desacoplando la
aplicación de la infraestructura
* **Observabilidad**
No solamente se presenta la información y métricas del sistema operativo, sino la salud de la
aplicación y otras señales
* **Consistencia entre los entornos de desarrollo, pruebas y producción**:
La aplicación funciona igual en un laptop y en la nube
* **Portabilidad entre nubes y distribuciones**:
Funciona en Ubuntu, RHEL, CoreOS, tu datacenter físico, Google Kubernetes Engine y todo lo demás
* **Administración centrada en la aplicación**:
Eleva el nivel de abstracción del sistema operativo y el hardware virtualizado a la aplicación que funciona en un sistema con recursos lógicos
* **[Microservicios](https://martinfowler.com/articles/microservices.html)** distribuidos, elásticos, liberados y débilmente acoplados:
Las aplicaciones se separan en piezas pequeñas e independientes que pueden ser desplegadas y administradas de forma dinámica, y no como una aplicación monolítica que opera en una sola máquina de gran capacidad
* **Aislamiento de recursos**:
Hace el rendimiento de la aplicación más predecible
* **Utilización de recursos**:
Permite mayor eficiencia y densidad
## ¿Qué significa Kubernetes? ¿Qué significa K8S?
El nombre **Kubernetes** proviene del griego y significa *timonel* o *piloto*. Es la raíz de *gobernador* y de [cibernética](http://www.etymonline.com/index.php?term=cybernetics). *K8s*
es una abrevación que se obtiene al reemplazar las ocho letras "ubernete" con el número 8.
{{% /capture %}}
{{% capture whatsnext %}}
* ¿Estás listo para [empezar](/docs/setup/)?
* Para saber más, visita el resto de la [documentación de Kubernetes](/docs/home/).
{{% /capture %}}
content/es/docs/concepts/overview/working-with-objects/annotations.md
+4 -4
View File
@@ -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.
content/es/docs/concepts/overview/working-with-objects/common-labels.md
+6 -6
View File
@@ -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
content/es/docs/concepts/overview/working-with-objects/field-selectors.md
+1 -1
View File
@@ -56,5 +56,5 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway
Puedes usar los selectores de campo entre múltiples tipos de recursos. Este comando de `kubectl` selecciona todos los Statefulsets y Services que no están en el espacio de nombres `default`:
```shell
kubectl get statefulsets,services --field-selector metadata.namespace!=default
kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default
```
content/es/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+3 -3
View File
@@ -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).
content/es/docs/concepts/overview/working-with-objects/namespaces.md
+6 -6
View File
@@ -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
@@ -79,7 +79,7 @@ Puedes indicar de forma permanente el espacio de nombres para todas las llamadas
en dicho contexto.
```shell
kubectl config set-context $(kubectl config current-context) --namespace=<insert-namespace-name-here>
kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Validate it
kubectl config view | grep namespace:
```
content/es/docs/concepts/workloads/controllers/cron-jobs.md
+61
View File
@@ -0,0 +1,61 @@
---
title: CronJob
content_template: templates/concept
weight: 80
---
{{% capture overview %}}
Un _Cron Job_ ejecuta tareas, [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/), a intervalos regulares.
Un objeto CronJob es como una línea de un archivo _crontab_ (tabla cron). Ejecuta un trabajo de forma periódica
según un horario programado escrito en formato [Cron](https://en.wikipedia.org/wiki/Cron).
{{< note >}}
Todos los `horarios` **CronJob** se basan en la zona horaria del máster donde se inicia el trabajo.
{{< /note >}}
Para instrucciones sobre cómo crear y trabajar con trabajos programados,
incluyendo definiciones de ejemplo,
puedes consultar [Ejecutar tareas automatizadas con trabajos programados](/docs/tasks/job/automated-tasks-with-cron-jobs).
{{% /capture %}}
{{% capture body %}}
## Limitaciones de las tareas programados
Un trabajo programado crea un objeto job _como mínimo_ una vez por cada ejecución de su programación. Decimos "como mínimo" porque
hay determinadas circunstancias bajo las cuales dos trabajos pueden crearse, o ninguno de ellos se crea. Se intenta que estos casos sean residuales,
pero no pueden evitarse completamente. Por lo tanto, los trabajos deberían ser _idempotentes_, es decir, que se pueden ejecutar más de una vez con el mismo resultado.
Si el valor de `startingDeadlineSeconds` se establece a un valor grande o se deja sin especificar (por defecto)
y si el valor de `concurrencyPolicy` se establece a `Allow`, los trabajos siempre se ejecutarán por lo menos una vez.
Para cada CronJob, el controlador de CronJob verifica cuántas programaciones se han perdido desde la última programación hasta el momento actual.
Si hay más de 100 programaciones perdidas, entonces ya no vuelve a ejecutar el trabajo y registra el error:
````
Cannot determine if job needs to be started. Too many missed start time (> 100). Set or decrease .spec.startingDeadlineSeconds or check clock skew.
````
Es importante destacar que si el campo `startingDeadlineSeconds` está configurado, es decir, no es nulo (`nil`), el controlador cuenta cuántos trabajos perdidos se produjeron desde el valor de `startingDeadlineSeconds`
hasta el momento actual, en vez de la última programación. Por ejemplo, si `startingDeadlineSeconds` es `200`, el controlador cuenta cuántos trabajos perdidos se produjeron en los últimos 200 segundos.
Se cuenta un CronJob como perdido si no se ha podido crear a la hora programada. Por ejemplo, si establecemos el valor de `concurrencyPolicy` a `Forbid` y se intentó programar
un CronJob cuando otro previamente programado estaba todavía ejecutándose, entonces contará como perdido.
Por ejemplo, imagina que un CronJob se configura para programar un nuevo Job cada minuto a partir de las `08:30:00`, y su campo
`startingDeadlineSeconds` no se configura. Si el controlador del CronJob no estuviera disponible de `08:29:00` a `10:21:00`,
el trabajo no comenzaría porque el número de trabajos perdidos que se habría perdido en su programación sería superior a 100.
Para ilustrar este concepto mejor, vamos a suponer que programamos un CronJob para que ejecute un nuevo Job cada minuto comenzando a las `08:30:00`, y establecemos el valor del campo
`startingDeadlineSeconds` a 200 segundos. Si el controlador del CronJob no se encuentra disponible
durante el mismo período que en el ejemplo anterior (`08:29:00` a `10:21:00`,) aún así el Job comenzará a las 10:22:00.
Esto ocurre porque el controlador en este caso comprueba cuántas programaciones perdidas ha habido en los últimos 200 segundos (esto es, 3 programaciones que no se han ejecutado), en vez de comprobarlo a partir de la última programación hasta el momento actual.
El CronJob es únicamente responsable de crear los Jobs que coinciden con su programación, y
el Job por otro lado es el responsable de gestionar los Pods que representa.
{{% /capture %}}
content/es/docs/concepts/workloads/controllers/daemonset.md
+238
View File
@@ -0,0 +1,238 @@
---
title: DaemonSet
content_template: templates/concept
weight: 50
---
{{% capture overview %}}
Un _DaemonSet_ garantiza que todos (o algunos) de los nodos ejecuten una copia de un Pod. Conforme se añade más nodos
al clúster, nuevos Pods son añadidos a los mismos. Conforme se elimina nodos del clúster, dichos Pods se destruyen.
Al eliminar un DaemonSet se limpian todos los Pods que han sido creados.
Algunos casos de uso típicos de un DaemonSet son:
- ejecutar un proceso de almacenamiento en el clúster, como `glusterd`, `ceph`, en cada nodo.
- ejecutar un proceso de recolección de logs en cada nodo, como `fluentd` o `logstash`.
- ejecutar un proceso de monitorización de nodos en cada nodo, como [Prometheus Node Exporter](
https://github.com/prometheus/node_exporter), [Sysdig Agent] (https://sysdigdocs.atlassian.net/wiki/spaces/Platform), `collectd`,
[Dynatrace OneAgent](https://www.dynatrace.com/technologies/kubernetes-monitoring/),
[AppDynamics Agent](https://docs.appdynamics.com/display/CLOUD/Container+Visibility+with+Kubernetes),
[Datadog agent](https://docs.datadoghq.com/agent/kubernetes/daemonset_setup/),
[New Relic agent](https://docs.newrelic.com/docs/integrations/kubernetes-integration/installation/kubernetes-installation-configuration),
Ganglia `gmond` o un agente de Instana.
De forma básica, se debería usar un DaemonSet, cubriendo todos los nodos, por cada tipo de proceso.
En configuraciones más complejas se podría usar múltiples DaemonSets para un único tipo de proceso,
pero con diferentes parámetros y/o diferentes peticiones de CPU y memoria según el tipo de hardware.
{{% /capture %}}
{{% capture body %}}
## Escribir una especificación de DaemonSet
### Crear un DaemonSet
Un DaemonSet se describe por medio de un archivo YAML. Por ejemplo, el archivo `daemonset.yaml` de abajo describe un DaemonSet que ejecuta la imagen Docker de fluentd-elasticsearch:
{{< codenew file="controllers/daemonset.yaml" >}}
* Crear un DaemonSet basado en el archivo YAML:
```
kubectl apply -f https://k8s.io/examples/controllers/daemonset.yaml
```
### Campos requeridos
Como con cualquier otra configuración de Kubernetes, un DaemonSet requiere los campos `apiVersion`, `kind`, y `metadata`.
Para información general acerca de cómo trabajar con ficheros de configuración, ver los documentos [desplegar aplicaciones](/docs/user-guide/deploying-applications/),
[configurar contenedores](/docs/tasks/), y [gestión de objetos usando kubectl](/docs/concepts/overview/object-management-kubectl/overview/).
Un DaemonSet también necesita un sección [`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
### Plantilla Pod
El campo `.spec.template` es uno de los campos obligatorios de la sección `.spec`.
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` o `kind`.
Además de los campos obligatorios de un Pod, la plantilla Pod para un DaemonSet debe especificar
las etiquetas apropiadas (ver [selector de pod](#pod-selector)).
Una plantilla Pod para un DaemonSet debe tener una [`RestartPolicy`](/docs/user-guide/pod-states)
igual a `Always`, o no indicarse, lo cual asume por defecto el valor `Always`.
### Selector de Pod
El campo `.spec.selector` es un selector de pod. Funciona igual que el campo `.spec.selector`
de un [Job](/docs/concepts/jobs/run-to-completion-finite-workloads/).
A partir de Kubernetes 1.8, se debe configurar un selector de pod que coincida con las
etiquetas definidas en el `.spec.template`. Así, el selector de pod ya no asume valores por defecto cuando no se indica.
Dichos valores por defecto no eran compatibles con `kubectl apply`. Además, una vez que se ha creado el DaemonSet,
su campo `.spec.selector` no puede alterarse porque, si fuera el caso, ello podría resultar
en Pods huérfanos, lo cual confundiría a los usuarios.
El campo `.spec.selector` es un objeto que, a su vez, consiste en dos campos:
* `matchLabels` - funciona igual que el campo `.spec.selector` de un [ReplicationController](/docs/concepts/workloads/controllers/replicationcontroller/).
* `matchExpressions` - permite construir selectores más sofisticados indicando la clave,
la lista de valores y un operador para relacionar la clave y los valores.
Cuando se configura ambos campos, el resultado es conjuntivo (AND).
Si se especifica el campo `.spec.selector`, entonces debe coincidir con el campo `.spec.template.metadata.labels`. Aquellas configuraciones que no coinciden, son rechazadas por la API.
Además, normalmente no se debería crear ningún Pod con etiquetas que coincidan con el selector, bien sea de forma directa, via otro
DaemonSet, o via otro controlador como un ReplicaSet. De ser así, el controlador del DaemonSet
pensará que dichos Pods fueron en realidad creados por él mismo. Kubernetes, en cualquier caso, no te impide realizar esta
operación. Un caso donde puede que necesites hacer esto es cuando quieres crear manualmente un Pod con un valor diferente en un nodo para pruebas.
### Ejecutar Pods sólo en algunos Nodos
Si se configura un `.spec.template.spec.nodeSelector`, entonces el controlador del DaemonSet
creará los Pods en aquellos nodos que coincidan con el [selector de nodo](/docs/concepts/configuration/assign-pod-node/) indicado.
De forma similar, si se configura una `.spec.template.spec.affinity`,
entonces el controlador del DaemonSet creará los Pods en aquellos nodos que coincidan con la [afinidad de nodo](/docs/concepts/configuration/assign-pod-node/) indicada.
Si no se configura ninguno de los dos, entonces el controlador del DaemonSet creará los Pods en todos los nodos.
## Cómo se planifican los Pods procesos
### Planificados por el controlador del DaemonSet (deshabilitado por defecto a partir de 1.12)
Normalmente, el planificador de Kubernetes determina la máquina donde se ejecuta un Pod. Sin embargo, los Pods
creados por el controlador del DaemonSet ya tienen la máquina seleccionada (puesto que cuando se crea el Pod,
se indica el campo `.spec.nodeName`, y por ello el planificador los ignora). Por lo tanto:
- El controlador del DaemonSet no tiene en cuenta el campo [`unschedulable`](/docs/admin/node/#manual-node-administration) de un nodo.
- El controlador del DaemonSet puede crear Pods incluso cuando el planificador no ha arrancado, lo cual puede ayudar en el arranque del propio clúster.
### Planificados por el planificador por defecto de Kubernetes (habilitado por defecto desde 1.12)
{{< feature-state state="beta" for-kubernetes-version="1.12" >}}
Un DaemonSet garantiza que todos los nodos elegibles ejecuten una copia de un Pod.
Normalmente, es el planificador de Kubernetes quien determina el nodo donde se ejecuta un Pod. Sin embargo,
los pods del DaemonSet son creados y planificados por el mismo controlador del DaemonSet.
Esto introduce los siguientes inconvenientes:
* Comportamiento inconsistente de los Pods: Los Pods normales que están esperando
a ser creados, se encuentran en estado `Pending`, pero los pods del DaemonSet no pasan por el estado `Pending`.
Esto confunde a los usuarios.
* La [prioridad y el comportamiento de apropiación de Pods](/docs/concepts/configuration/pod-priority-preemption/)
se maneja por el planificador por defecto. Cuando se habilita la contaminación, el controlador del DaemonSet
tomará la decisiones de planificación sin considerar ni la prioridad ni la contaminación del pod.
`ScheduleDaemonSetPods` permite planificar DaemonSets usando el planificador por defecto
en vez del controlador del DaemonSet, añadiendo la condición `NodeAffinity`
a los pods del DaemonSet, en vez de la condición `.spec.nodeName`. El planificador por defecto
se usa entonces para asociar el pod a su servidor destino. Si la afinidad de nodo del
pod del DaemonSet ya existe, se sustituye. El controlador del DaemonSet sólo realiza
estas operaciones cuando crea o modifica los pods del DaemonSet, y no se realizan cambios
al `spec.template` del DaemonSet.
```yaml
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchFields:
- key: metadata.name
operator: In
values:
- target-host-name
```
Adicionalmente, se añade de forma automática la tolerancia `node.kubernetes.io/unschedulable:NoSchedule`
a los Pods del DaemonSet. Así, el planificador por defecto ignora los nodos
`unschedulable` cuando planifica los Pods del DaemonSet.
### Contaminaciones (taints) y Tolerancias (tolerations)
A pesar de que los Pods de proceso respetan las
[contaminaciones y tolerancias](/docs/concepts/configuration/taint-and-toleration),
la siguientes tolerancias son añadidas a los Pods del DaemonSet de forma automática
según las siguientes características:
| Clave de tolerancia | Efecto | Versión | Descripción |
| ---------------------------------------- | ---------- | ------- | ------------------------------------------------------------ |
| `node.kubernetes.io/not-ready` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. |
| `node.kubernetes.io/unreachable` | NoExecute | 1.13+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como una partición de red. |
| `node.kubernetes.io/disk-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de espacio en disco. |
| `node.kubernetes.io/memory-pressure` | NoSchedule | 1.8+ | Los pods del DaemonSet no son expulsados cuando hay problemas de nodo como la falta de memoria. |
| `node.kubernetes.io/unschedulable` | NoSchedule | 1.12+ | Los pods del DaemonSet toleran los atributos unschedulable del planificador por defecto. |
| `node.kubernetes.io/network-unavailable` | NoSchedule | 1.12+ | Los pods del DaemonSet, que usan la red del servidor anfitrión, toleran los atributos network-unavailable del planificador por defecto. |
## Comunicarse con los Pods de los DaemonSets
Algunos patrones posibles para la comunicación con los Pods de un DaemonSet son:
- **Push**: Los Pods del DaemonSet se configuran para enviar actualizaciones a otro servicio,
como una base de datos de estadísticas. No tienen clientes.
- **NodeIP y Known Port**: Los Pods del DaemonSet pueden usar un `hostPort`, de forma que se les puede alcanzar via las IPs del nodo. Los clientes conocen la lista de IPs del nodo de algún modo,
y conocen el puerto acordado.
- **DNS**: Se crea un [servicio headless](/docs/concepts/services-networking/service/#headless-services) con el mismo selector de pod,
y entonces se descubre a los DaemonSets usando los recursos `endpoints` o mediante múltiples registros de tipo A en el DNS.
- **Service**: Se crea un servicio con el mismo selector de Pod, y se usa el servicio para llegar al proceso de uno de los nodos. (No hay forma de determinar el nodo exacto.)
## Actualizar un DaemonSet
Si se cambian las etiquetas de nodo, el DaemonSet comenzará de forma inmediata a añadir Pods a los nuevos nodos que coincidan y a eliminar
los Pods de aquellos nuevos nodos donde no coincidan.
Puedes modificar los Pods que crea un DaemonSet. Sin embargo, no se permite actualizar todos los campos de los Pods.
Además, el controlador del DaemonSet utilizará la plantilla original la próxima vez que se cree un nodo (incluso con el mismo nombre).
Puedes eliminar un DaemonSet. Si indicas el parámetro `--cascade=false` al usar `kubectl`,
entonces los Pods continuarán ejecutándose en los nodos. Así, puedes crear entonces un nuevo DaemonSet con una plantilla diferente.
El nuevo DaemonSet con la plantilla diferente reconocerá a todos los Pods existentes que tengan etiquetas coincidentes y
no modificará o eliminará ningún Pod aunque la plantilla no coincida con los Pods desplegados.
Entonces, deberás forzar la creación del nuevo Pod eliminando el Pod mismo o el nodo.
A partir de las versión 1.6 de Kubernetes, puedes [llevar a cabo una actualización continua](/docs/tasks/manage-daemon/update-daemon-set/) en un DaemonSet.
## Alternativas al DaemonSet
### Secuencias de comandos de inicialización
Aunque es perfectamente posible ejecutar procesos arrancándolos directamente en un nodo (ej. usando
`init`, `upstartd`, o `systemd`), existen numerosas ventajas si se realiza via un DaemonSet:
- Capacidad de monitorizar y gestionar los logs de los procesos del mismo modo que para las aplicaciones.
- Mismo lenguaje y herramientas de configuración (ej. plantillas de Pod, `kubectl`) tanto para los procesos como para las aplicaciones.
- Los procesos que se ejecutan en contenedores con límitaciones de recursos aumentan el aislamiento entre dichos procesos y el resto de contenedores de aplicaciones.
Sin embargo, esto también se podría conseguir ejecutando los procesos en un contenedor en vez de un Pod
(ej. arrancarlos directamente via Docker).
### Pods individuales
Es posible crear Pods directamente sin indicar el nodo donde ejecutarse. Sin embargo,
la ventaja del DaemonSet es que sustituye los Pods que se eliminan o terminan por cualquier razón, como en el caso
de un fallo del nodo o una intervención disruptiva de mantenimiento del nodo, como la actualización del kernel.
Por esta razón, deberías siempre utilizar un DaemonSet en vez de crear Pods individuales.
### Pods estáticos
Es posible crear Pods a partir de archivos en el directorio donde está escuchando el proceso Kubelet.
Este tipo de Pods se denomina [pods estáticos](/docs/concepts/cluster-administration/static-pod/).
A diferencia del DaemonSet, los Pods estáticos no se pueden gestionar con kubectl
o cualquier otro cliente de la API de Kubernetes. Los Pods estáticos no dependen del apiserver, lo cual los hace
convenientes para el arranque inicial del clúster. Además, puede que los Pods estáticos se deprecien en el futuro.
### Deployments
Los DaemonSets son similares a los [Deployments](/docs/concepts/workloads/controllers/deployment/) en el sentido que
ambos crean Pods, y que dichos Pods tienen procesos que no se espera que terminen (ej. servidores web,
servidores de almacenamiento).
Utiliza un Deployment para definir servicios sin estado, como las interfaces de usuario, donde el escalado vertical y horizontal
del número de réplicas y las actualizaciones continuas son mucho más importantes que el control exacto del servidor donde se ejecuta el Pod.
Utiliza un DaemonSet cuando es importante que una copia de un Pod siempre se ejecute en cada uno de los nodos,
y cuando se necesite que arranque antes que el resto de Pods.
{{% /capture %}}
content/es/docs/concepts/workloads/controllers/replicationcontroller.md
+332
View File
@@ -0,0 +1,332 @@
---
title: ReplicationController
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,
y no los expone a los clientes hasta que no están listo para servirse.
content_template: templates/concept
weight: 20
---
{{% capture overview %}}
{{< note >}}
hoy en día la forma recomendada de configurar la replicación es con un [`Deployment`](/docs/concepts/workloads/controllers/deployment/) que configura un [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/).
{{< /note >}}
Un _ReplicationController_ garantiza que un número determinado de réplicas se estén ejecutando
en todo momento. En otras palabras, un ReplicationController se asegura que un pod o un conjunto homogéneo de pods
siempre esté arriba y disponible.
{{% /capture %}}
{{% capture body %}}
## 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 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
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
atajo en los comandos de kubectl.
Un caso simple es crear un objeto ReplicationController para ejecutar de manera fiable una instancia
de un Pod indefinidamente. Un caso de uso más complejo es ejecutar varias réplicas idénticas
de un servicio replicado, como los servidores web.
## Ejecutar un ejemplo de ReplicationController
Esta configuración de un ReplicationController de ejemplo ejecuta tres copias del servidor web nginx.
{{< codenew file="controllers/replication.yaml" >}}
Ejecuta el ejemplo descargando el archivo de ejemplo y ejecutando este comando:
```shell
kubectl apply -f https://k8s.io/examples/controllers/replication.yaml
```
```
replicationcontroller/nginx created
```
Comprueba el estado del ReplicationController con este comando:
```shell
kubectl describe replicationcontrollers/nginx
```
```
Name: nginx
Namespace: default
Selector: app=nginx
Labels: app=nginx
Annotations: <none>
Replicas: 3 current / 3 desired
Pods Status: 0 Running / 3 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx
Port: 80/TCP
Environment: <none>
Mounts: <none>
Volumes: <none>
Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- ---- ------ -------
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-qrm3m
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-3ntk0
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,
puede que porque la imagen todavía se está descargando.
Unos momentos después, el mismo comando puede que muestre:
```shell
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
```
Para listar todos los pods que pertenecen al ReplicationController de forma legible,
puedes usar un comando como el siguiente:
```shell
pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name})
echo $pods
```
```
nginx-3ntk0 nginx-4ok8v nginx-qrm3m
```
Como se puede ver, el selector es el mismo que el selector del ReplicationController (mostrado en la salida de
`kubectl describe`), y con una forma diferente a lo definido en el archivo `replication.yaml`.
La opción `--output=jsonpath` especifica una expresión que simplemente muestra el nombre
de cada pod en la lista devuelta.
## Escribir una especificación de ReplicationController
Al igual que con el resto de configuraciones de Kubernetes, un ReplicationController necesita los campos `apiVersion`, `kind`, y `metadata`.
Para información general acerca del trabajo con archivos de configuración, ver la [gestión de objetos](/docs/concepts/overview/object-management-kubectl/overview/).
Un ReplicationController también necesita un [sección `.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status).
### Plantilla Pod
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).
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),
que es el valor predeterminado si no se indica.
Para los reinicios locales de los contenedores, los ReplicationControllers delegan en los agentes del nodo,
por ejmplo el [Kubelet](/docs/admin/kubelet/) o Docker.
### Etiquetas en los ReplicationController
los ReplicationController puede tener sus propias (`.metadata.labels`). Normalmente, se indicaría dichas etiquetas
con los mismos valores que el campo `.spec.template.metadata.labels`; si el campo `.metadata.labels` no se indica,
entonces se predetermina al valor de `.spec.template.metadata.labels`. Sin embargo, se permite que sean diferentes,
y el valor de `.metadata.labels` no afecta al comportamiento del ReplicationController.
### Selector de Pod
El campo `.spec.selector` es un [selector de etiqueta](/docs/concepts/overview/working-with-objects/labels/#label-selectors). Un ReplicationController
gestiona todos los pods con etiquetas que coinciden con el selector. No distingue entre
pods que creó o eliminó, y pods que otra persona o proceso creó o eliminó. Esto permite sustituir al ReplicationController sin impactar a ninguno de sus pods que se esté ejecutando.
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
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.
Si al final terminas con múltiples controladores que tienen selectores que se entremezclan,
tendrás que gestionar la eliminación tú mismo (ver [abajo](#working-with-replicationcontrollers)).
### Múltiples Réplicas
Puedes configurar cuántos pods deberían ejecutarse de forma concurrente poniendo el valor de `.spec.replicas` al número
de pods que te gustaría tener ejecutándose a la vez. El número de ejecuciones en cualquier momento puede que sea superior
o inferior, dependiendo de si las réplicas se han incrementado o decrementado, o si un pod se ha apagado de forma controlada,
y su sustituto arranca más pronto.
Si no se indica el valor de `.spec.replicas`, entonces se predetermina a 1.
## Trabajar con ReplicationControllers
### Eliminar un ReplicationController y sus Pods
Para eliminar un ReplicationController y todos sus pods, usa el comando [`kubectl
delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). Kubectl reducirá el ReplicationController a cero y esperará
que elimine cada pod antes de eliminar al ReplicationController mismo. Si este comando kubectl
se interrumpe, puede ser reiniciado.
Cuando uses la API REST o la librería Go, necesitas realizar los pasos de forma explícita (reducir las réplicas a cero,
esperar a que se eliminen los pods, y entonces eliminar el ReplicationController).
### Eliminar sólo el ReplicationController
Puedes eliminar un ReplicationController sin impactar a ninguno de sus Pods.
Usando kubectl, indica la opción `--cascade=false` en el comando [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete).
Cuando uses la API REST o la librería Go, simplemente elimina objeto ReplicationController.
Una vez que el objeto original se ha eliminado, puedes crear un nuevo ReplicationController para sustituirlo.
Mientras el viejo y el nuevo valor del `.spec.selector` sea el mismo, el nuevo adoptará a los viejos pods.
Sin embargo, no se molestará en hacer que los pods actuales coincidan con una plantilla pod nueva, diferente.
Para actualizar los pods con una nueva especificación de forma controlada, utiliza la [actualización en línea](#rolling-updates).
### 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.
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,
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,
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.
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,
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).
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,
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',
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.
### Usar ReplicationControllers con servicios
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,
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),
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.
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
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.
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.
## Obejto API
El ReplicationController es un recurso de alto nivel en la API REST de Kubernetes. Más detalles acerca del
objeto API se pueden encontrar aquí:
[Objeto API ReplicationController](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#replicationcontroller-v1-core).
## Alternativas al ReplicationController
### ReplicaSet
El [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) es el ReplicationController de nueva generación que soporta el nuevo [selector de etiqueta basado en conjunto](/docs/concepts/overview/working-with-objects/labels/#set-based-requirement).
Se usa principalmente por el [`Deployment`](/docs/concepts/workloads/controllers/deployment/) como un mecanismo para orquestrar la creación de pods, la eliminación y las actualizaciones.
Nótese que se recomienda usar Deployments en vez de directamente usar los ReplicaSets, a menos que necesites una orquestración personalizada de actualizaciones o no quieras actualizaciones en absoluto.
### Deployment (Recomendado)
El [`Deployment`](/docs/concepts/workloads/controllers/deployment/) es un objeto de alto nivel de la API que actualiza sus ReplicaSets subyacenetes y sus Pods
de forma similar a cómo lo hace el comando `kubectl rolling-update`. Se recomienda el uso de Deployments si se quiere esta functionalidad de actualización en línea,
porque a diferencia del comando `kubectl rolling-update`, son declarativos, se ejecutan del lado del servidor, y tienen características adicionales.
### 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,
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.
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
los contenedores a algún agente del nodo (por ejemplo, Kubelet o Docker).
### Job
Usa un [`Job`](/docs/concepts/jobs/run-to-completion-finite-workloads/) en vez de un ReplicationController para aquellos pods que se espera que terminen por sí mismos
(esto es, trabajos por lotes).
### DaemonSet
Usa un [`DaemonSet`](/docs/concepts/workloads/controllers/daemonset/) en vez de un ReplicationController para aquellos pods que proporcionan
una función a nivel de servidor, como la monitorización o el loggin de servidor. Estos pods tienen un ciclo de vida que está asociado
al del servidor: el pod necesita ejecutarse en el servidor antes que los otros pods arranquen, y es seguro
terminarlo cuando el servidor está listo para reiniciarse/apagarse.
## Para más información
Lee [Ejecutar Aplicaciones sin Estado con un ReplicationController](/docs/tutorials/stateless-application/run-stateless-ap-replication-controller/).
{{% /capture %}}
content/es/docs/concepts/workloads/controllers/statefulset.md
+267
View File
@@ -0,0 +1,267 @@
---
title: StatefulSets
content_template: templates/concept
weight: 40
---
{{% capture overview %}}
Un StatefulSet es el objeto de la API workload que se usa para gestionar aplicaciones con estado.
{{< note >}}
Los StatefulSets son estables (GA) en la versión 1.9.
{{< /note >}}
{{< glossary_definition term_id="statefulset" length="all" >}}
{{% /capture %}}
{{% capture body %}}
## Usar StatefulSets
Los StatefulSets son valiosos para aquellas aplicaciones que necesitan uno o más de los siguientes:
* Identificadores de red estables, únicos.
* Almacenamiento estable, persistente.
* Despliegue y escalado ordenado, controlado.
* Actualizaciones en línea ordenadas, automatizadas.
De los de arriba, estable es sinónimo de persistencia entre (re)programaciones de Pods.
Si una aplicación no necesita ningún identificador estable o despliegue,
eliminación, o escalado ordenado, deberías desplegar tu aplicación con un controlador que
proporcione un conjunto de réplicas sin estado, como un
[Deployment](/docs/concepts/workloads/controllers/deployment/) o un
[ReplicaSet](/docs/concepts/workloads/controllers/replicaset/), ya que están mejor preparados
para tus necesidades sin estado.
## Limitaciones
* El almacenamiento de un determinado Pod debe provisionarse por un [Provisionador de PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) basado en la `storage class` requerida, o pre-provisionarse por un administrador.
* Eliminar y/o reducir un StatefulSet *no* eliminará los volúmenes asociados con el StatefulSet. Este comportamiento es intencional y sirve para garantizar la seguridad de los datos, que da más valor que la purga automática de los recursos relacionados del StatefulSet.
* Los StatefulSets actualmente necesitan un [Servicio Headless](/docs/concepts/services-networking/service/#headless-services) como responsable de la identidad de red de los Pods. Es tu responsabilidad crear este Service.
* Los StatefulSets no proporcionan ninguna garantía de la terminación de los pods cuando se elimina un StatefulSet. Para conseguir un término de los pods ordenado y controlado en el StatefulSet, es posible reducir el StatefulSet a 0 réplicas justo antes de eliminarlo.
* Cuando se usan las [Actualizaciones en línea](#rolling-updates) con la
[Regla de Gestión de Pod](#pod-management-policies) (`OrderedReady`) por defecto,
es posible entrar en un estado inconsistente que requiere de una
[intervención manual para su reparación](#retroceso-forzado).
## Componentes
El ejemplo de abajo demuestra los componentes de un StatefulSet:
* Un servicio Headless, llamado nginx, se usa para controlar el dominio de red.
* Un StatefulSet, llamado web, que tiene una especificación que indica que se lanzarán 3 réplicas del contenedor nginx en Pods únicos.
* Un volumeClaimTemplate que proporciona almacenamiento estable por medio de [PersistentVolumes](/docs/concepts/storage/persistent-volumes/) provisionados por un provisionador de tipo PersistentVolume.
```yaml
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # tiene que coincidir con .spec.template.metadata.labels
serviceName: "nginx"
replicas: 3 # por defecto es 1
template:
metadata:
labels:
app: nginx # tiene que coincidir con .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
resources:
requests:
storage: 1Gi
```
## 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,
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,
una identidad estable de red, y almacenamiento estable. La identidad se asocia al Pod,
independientemente del nodo en que haya sido (re)programado.
### Índice Ordinal
Para un StatefulSet con N réplicas, a cada Pod del StatefulSet se le asignará
un número entero ordinal, desde 0 hasta N-1, y que es único para el conjunto.
### ID estable de Red
El nombre de anfitrión (hostname) de cada Pod de un StatefulSet se deriva del nombre del StatefulSet
y del número ordinal del Pod. El patrón para construir dicho hostname
es `$(statefulset name)-$(ordinal)`. Así, el ejemplo de arriba creará tres Pods
denominados `web-0,web-1,web-2`.
Un StatefulSet puede usar un [Servicio Headless](/docs/concepts/services-networking/service/#headless-services)
para controlar el nombre de dominio de sus Pods. El nombre de dominio gestionado por este Service tiene la forma:
`$(service name).$(namespace).svc.cluster.local`, donde "cluster.local" es el nombre de dominio del clúster.
Conforme se crea cada Pod, se le asigna un nombre DNS correspondiente de subdominio, que tiene la forma:
`$(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
[Servicio Headless](/docs/concepts/services-networking/service/#headless-services)
encargado de la identidad de red de los pods es enteramente tu responsabilidad.
Aquí se muestran algunos ejemplos de elecciones de nombres de Cluster Domain, nombres de Service,
nombres de StatefulSet, y cómo impactan en los nombres DNS de los Pods del StatefulSet:
Cluster Domain | Service (ns/nombre) | StatefulSet (ns/nombre) | StatefulSet Domain | Pod DNS | Pod Hostname |
-------------- | ----------------- | ----------------- | -------------- | ------- | ------------ |
cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} |
cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} |
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
{{< note >}}
El valor de Cluster Domain se pondrá a `cluster.local` a menos que
[se configure de otra forma](/docs/concepts/services-networking/dns-pod-service/).
{{< /note >}}
### Almacenamiento estable
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,
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 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
en el StatefulSet.
## Garantías de Despliegue y Escalado
* Para un StatefulSet con N réplicas, cuando los Pods se despliegan, se crean secuencialmente, en orden de {0..N-1}.
* Cuando se eliminan los Pods, se terminan en orden opuesto, de {N-1..0}.
* 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`.
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
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
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.
Si un usuario fuera a escalar el ejemplo desplegado parcheando el StatefulSet de forma que
`replicas=1`, web-2 se terminaría primero. web-1 no se terminaría hasta que web-2
no se hubiera apagado y eliminado por completo. Si web-0 fallase después de que web-2 se hubiera terminado y
apagado completamente, pero antes del término de web-1, entonces web-1 no se terminaría hasta
que web-0 estuviera Running y Ready.
### Reglas de Gestión de Pods
En Kubernetes 1.7 y versiones posteriores, el StatefulSet permite flexibilizar sus garantías de ordenación
al mismo tiempo que preservar su garantía de singularidad e identidad a través del campo `.spec.podManagementPolicy`.
#### Gestión de tipo OrderedReady de Pods
La gestión de tipo `OrderedReady` de pods es la predeterminada para los StatefulSets. Implementa el comportamiento
descrito [arriba](#deployment-and-scaling-guarantees).
#### Gestión de tipo Parallel de Pods
La gestión de tipo `Parallel` de pods le dice al controlador del StatefulSet que lance y termine
todos los Pods en paralelo, y que no espere a que los Pods estén Running
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 anotaciones de los Pods del StatefulSet.
### On Delete
La estrategia de actualización `OnDelete` implementa el funcionamiento tradicional (1.6 y previo). Cuando el campo
`.spec.updateStrategy.type` de un StatefulSet se pone al valor `OnDelete`, el controlador del StatefulSet no actualizará automáticamente
los Pods del StatefulSet. Los usuarios deben eliminar manualmente los Pods para forzar al controlador a crear
nuevos Pods que reflejen las modificaciones hechas al campo `.spec.template` del StatefulSet.
### Rolling Updates
La estrategia de actualización `RollingUpdate` implementa una actualización automatizada en línea de los Pods del
StatefulSet. Es la estrategia por defecto cuando el campo `.spec.updateStrategy` se deja sin valor. Cuando el campo `.spec.updateStrategy.type` de un StatefulSet
se pone al valor `RollingUpdate`, el controlador del StatefulSet lo eliminará y recreará cada Pod en el StatefulSet. Procederá
en el mismo orden en que ha terminado los Pod (del número ordinal más grande al más pequeño), actualizando
cada Pod uno por uno. Esperará a que el Pod actualizado esté Running y Ready antes de
actualizar su predecesor.
#### Particiones
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
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,
realizar un despliegue tipo canary, o llevar a cabo un despliegue en fases.
#### Retroceso Forzado
Cuando se usa [Actualizaciones en línea](#rolling-updates) con el valor de la
[Regla de Gestión de Pod](#pod-management-policies) (`OrderedReady`) por defecto,
es posible acabar en un estado inconsistente que requiera de una intervención manual para arreglarlo.
Si actualizas la plantilla Pod a una configuración que nunca llega a Running y
Ready (por ejemplo, debido a un binario incorrecto o un error de configuración a nivel de aplicación),
el StatefulSet detendrá el despliegue y esperará.
En este estado, no es suficiente con revertir la plantilla Pod a la configuración buena.
Debido a un [problema conocido](https://github.com/kubernetes/kubernetes/issues/67250),
el StatefulSet seguirá esperando a que los Pod estropeados se pongan en Ready
(lo que nunca ocurre) antes de intentar revertirla a la configuración que funcionaba.
Antes de revertir la plantilla, debes también eliminar cualquier Pod que el StatefulSet haya
intentando ejecutar con la configuración incorrecta.
El StatefulSet comenzará entonces a recrear los Pods usando la plantilla revertida.
{{% /capture %}}
{{% capture whatsnext %}}
* Sigue el ejemplo de cómo [desplegar un aplicación con estado](/docs/tutorials/stateful-application/basic-stateful-set/).
* Sigue el ejemplo de cómo [desplegar Cassandra con StatefulSets](/docs/tutorials/stateful-application/cassandra/).
{{% /capture %}}
content/es/docs/concepts/workloads/controllers/ttlafterfinished.md
+85
View File
@@ -0,0 +1,85 @@
---
title: Controlador TTL para Recursos Finalizados
content_template: templates/concept
weight: 65
---
{{% capture overview %}}
{{< feature-state for_k8s_version="v1.12" state="alpha" >}}
El controlador TTL proporciona un mecanismo TTL para limitar el tiempo de vida de los objetos
de recurso que ya han terminado su ejecución. El controlador TTL sólo se ocupa de los
[Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/) por el momento,
y puede que se extienda para gestionar otros recursos que terminen su ejecución,
como los Pods y los recursos personalizados.
Descargo de responsabilidad Alpha: esta característica está actualmente en versión alpha, y puede habilitarse mediante el
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
`TTLAfterFinished`.
{{% /capture %}}
{{% capture body %}}
## 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
[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.
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.
Los segundos TTL pueden ser configurados en cualquier momento. Aquí se muestran algunos ejemplos para poner valores al campo
`.spec.ttlSecondsAfterFinished` de un Job:
* Indicando este campo en el manifiesto de los recursos, de forma que se pueda limpiar un Job
automáticamente un tiempo después de que haya finalizado.
* Haciendo que el campo de los recursos existentes, ya finalizados, adopte esta nueva característica.
* 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
[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,
y eligiendo diferentes valores TTL basados en los estados de los recursos, etiquetas, etc.
## Advertencia
### Actualizar los segundos TTL
Cabe señalar que el período TTL , ej. campo `.spec.ttlSecondsAfterFinished` de los Jobs,
puede modificarse después de que el recurso haya sido creado o terminado. Sin embargo, una vez
que el Job se convierte en candidato para ser eliminado (cuando el TTL ha expirado), el sistema
no garantiza que se mantendrán los Jobs, incluso si una modificación para extender el TTL
devuelve una respuesta API satisfactoria.
### Diferencia horaria
Como el controlador TTL usa marcas de fecha/hora almacenadas en los recursos de Kubernetes
para determinar si el TTL ha expirado o no, esta funcionalidad es sensible a las
diferencias horarias del clúster, lo que puede provocar que el controlador TTL limpie recursos
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.
Ten presente este riesgo cuando pongas un valor distinto de cero para el TTL.
{{% /capture %}}
{{% capture whatsnext %}}
[Limpiar Jobs automáticamente](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically)
[Documento de diseño](https://github.com/kubernetes/community/blob/master/keps/sig-apps/0026-ttl-after-finish.md)
{{% /capture %}}
content/es/docs/concepts/workloads/pods/ephemeral-containers.md
+214
View File
@@ -0,0 +1,214 @@
---
reviewers:
- astuky
- raelga
title: Containers Efímeros
content_template: templates/concept
weight: 80
---
{{% capture overview %}}
{{< feature-state state="alpha" >}}
Esta página proporciona una descripción general de los Containers efímeros: un tipo especial de Container
que se ejecuta temporalmente en un {{< glossary_tooltip text="Pod" term_id="pod" >}} ya existente para cumplir las
acciones iniciadas por el usuario, como por ejemplo, la solución de problemas. En vez de ser utilizadas para
crear aplicaciones, los Containers efímeros se utilizan para examinar los servicios.
{{< warning >}}
Los Containers efímeros se encuentran en una fase alfa inicial y no son aptos para clústers
de producción. Es de esperar que esta característica no funcione en algunas situaciones, por
ejemplo, al seleccionar los Namespaces de un Container. De acuerdo con la [Política de
Deprecación de Kubernetes](/docs/reference/using-api/deprecation-policy/), esta característica
alfa puede variar significativamente en el futuro o ser eliminada por completo.
{{< /warning >}}
{{% /capture %}}
{{% capture body %}}
## Entendiendo los Containers efímeros
{{< glossary_tooltip text="Pods" term_id="pod" >}} son el componente fundamental de las
aplicaciones de Kubernetes. Puesto que los Pods están previstos para ser desechables
y reemplazables, no se puede añadir un Container a un Pod una vez creado. Sin embargo, por lo
general se eliminan y se reemplazan los Pods de manera controlada utilizando
{{< glossary_tooltip text="Deployments" term_id="deployment" >}}.
En ocasiones es necesario examinar el estado de un Pod existente, como por ejemplo,
para poder solucionar un error difícil de reproducir. Puede ejecutar en estos casos
un Container efímero en un Pod ya existente para examinar su estado y para ejecutar
comandos de manera arbitraria.
### Qué es un Container efímero?
Los Containers efímeros se diferencian de otros Containers en que no garantizan ni los
recursos ni la ejecución, y en que nunca se reiniciarán automáticamente, de modo que no
son aptos para la construcción de aplicaciones. Los Containers efímeros se describen
usando la misma [ContainerSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core) que los Containers regulares, aunque muchos campos son
incompatibles y no están habilitados para los Containers efímeros.
- Los Containers efímeros no pueden tener puertos, por lo que campos como `ports`,
`livenessProbe`, `readinessProbe` no están habilitados.
- Las asignaciones de recursos del Pod son inmutables, por lo que no esta habilitado
configurar "resources".
- Para obtener una lista completa de los campos habilitados, consulte la documentación
de referencia [EphemeralContainer] (/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ephemeralcontainer-v1-core).
En vez de añadirlos de forma directa al `pod.spec`, los Containers efímeros se crean usando un
controlador especial de la API, `ephemeralcontainers`, por lo tanto no es posible añadir un
Container efímero utilizando `kubectl edit`.
Al igual en el caso de los Containers regulares, no se puede modificar o remover un Container
efímero después de haberlo agregado a un Pod.
## Casos de uso para los Containers efímeros
Los Containers efímeros resultan útiles para la solución interactiva de incidencias cuando
`kubectl exec` es insuficiente tanto porque un container se ha caído, como porque la imagen de un
Container no incluye las utilidades de depuración.
En particular, las [imágenes distroless](https://github.com/GoogleContainerTools/distroless)
le permiten desplegar imágenes de Containers mínimos que disminuyen la superficie de ataque
y la exposición a errores y vulnerabilidades. Ya que las imágenes distroless no contienen un
shell ni ninguna utilidad de depuración, resulta difícil solucionar los problemas de las imágenes
distroless usando solamente `kubectl exec`.
Cuando utilice Containers efímeros, es conveniente habilitar el [proceso Namespace de uso
compartido](/docs/tasks/configure-pod-container/share-process-namespace/) para poder ver los
procesos en otros containers.
### Ejemplos
{{< note >}}
Los ejemplos de esta sección requieren que los `EphemeralContainers` [feature
gate](/docs/reference/command-line-tools-reference/feature-gates/) estén habilitados
y que tanto el cliente como el servidor de Kubernetes tengan la version v1.16 o posterior.
{{< /note >}}
En los ejemplos de esta sección muestran la forma en que los Containers efímeros se
presentan en la API. Los usuarios normalmente usarían un plugin `kubectl` para la solución
de problemas que automatizaría estos pasos.
Los Containers efímeros son creados utilizando el subrecurso `ephemeralcontainers` del Pod,
que puede ser visto utilizando `kubectl --raw`. En primer lugar describa el Container
efímero a añadir como una lista de `EphemeralContainers`:
```json
{
"apiVersion": "v1",
"kind": "EphemeralContainers",
"metadata": {
"name": "example-pod"
},
"ephemeralContainers": [{
"command": [
"sh"
],
"image": "busybox",
"imagePullPolicy": "IfNotPresent",
"name": "debugger",
"stdin": true,
"tty": true,
"terminationMessagePolicy": "File"
}]
}
```
Para actualizar los Containers efímeros de los `example-pod` en ejecución:
```shell
kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
```
Esto devolverá una nueva lista de Containers efímeros:
```json
{
"kind":"EphemeralContainers",
"apiVersion":"v1",
"metadata":{
"name":"example-pod",
"namespace":"default",
"selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
"uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
"resourceVersion":"15886",
"creationTimestamp":"2019-08-29T06:41:42Z"
},
"ephemeralContainers":[
{
"name":"debugger",
"image":"busybox",
"command":[
"sh"
],
"resources":{
},
"terminationMessagePolicy":"File",
"imagePullPolicy":"IfNotPresent",
"stdin":true,
"tty":true
}
]
}
```
Se puede ver el estado del Container efímero creado usando `kubectl describe`:
```shell
kubectl describe pod example-pod
```
```
...
Ephemeral Containers:
debugger:
Container ID: docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
Image: busybox
Image ID: docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
Port: <none>
Host Port: <none>
Command:
sh
State: Running
Started: Thu, 29 Aug 2019 06:42:21 +0000
Ready: False
Restart Count: 0
Environment: <none>
Mounts: <none>
...
```
Se puede conectar al nuevo Container efímero usando `kubectl attach`:
```shell
kubectl attach -it example-pod -c debugger
```
Si el proceso Namespace de uso compartido está habilitado, se pueden visualizar los procesos de todos los Containers de ese Pod.
Por ejemplo, después de haber conectado, ejecute `ps` en el debugger del container:
```shell
ps auxww
```
La respuesta es semejante a:
```
PID USER TIME COMMAND
1 root 0:00 /pause
6 root 0:00 nginx: master process nginx -g daemon off;
11 101 0:00 nginx: worker process
12 101 0:00 nginx: worker process
13 101 0:00 nginx: worker process
14 101 0:00 nginx: worker process
15 101 0:00 nginx: worker process
16 101 0:00 nginx: worker process
17 101 0:00 nginx: worker process
18 101 0:00 nginx: worker process
19 root 0:00 /pause
24 root 0:00 sh
29 root 0:00 ps auxww
```
{{% /capture %}}
content/es/docs/concepts/workloads/pods/podpreset.md
+95
View File
@@ -0,0 +1,95 @@
---
reviewers:
- raelga
title: Pod Preset
content_template: templates/concept
weight: 50
---
{{% capture overview %}}
Esta página provee una descripción general de los Pod Presets, los cuales son
los objetos que se utilizan para inyectar cierta información en los Pods en
el momento de la creación. Esta información puede incluir secretos, volúmenes,
montajes de volúmenes y variables de entorno.
{{% /capture %}}
{{% capture body %}}
## Entendiendo los Pod Presets
Un `Pod Preset` es un recurso de la API utilizado para poder inyectar requerimientos
adicionales de tiempo de ejecución en un Pod en el momento de la creación.
Se utilizan los [selectores de etiquetas](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
para especificar los Pods a los que se aplica un Pod Preset determinado.
El uso de un Pod Preset permite a los autores de plantillas de Pods no tener que proporcionar
explícitamente toda la información de cada Pod. De esta manera, los autores de plantillas de
Pods que consuman un determinado servicio no tendrán que conocer todos los detalles de ese servicio.
Para más información sobre los detalles de los trasfondos, consulte la [propuesta de diseño de PodPreset](https://git.k8s.io/community/contributors/design-proposals/service-catalog/pod-preset.md).
## Cómo funciona
Kubernetes provee un controlador de admisión (`PodPreset`) que, cuando está habilitado,
aplica los Pod Presets a las peticiones de creación de Pods entrantes.
Cuando se realiza una solicitud de creación de Pods, el sistema hace lo siguiente:
1. Obtiene todos los `PodPresets` disponibles para usar.
2. Verifica si los selectores de etiquetas de cualquier `PodPreset` correspondan
con las etiquetas del Pod que se está creando.
3. Intenta fusionar los diversos recursos definidos por el `PodPreset` dentro del Pod
que se está creando.
4. Si se llegase a producir un error al intentar fusionar los recursos dentro del Pod,
lanza un evento que documente este error, luego crea el Pod _sin_ ningún recurso que se
inyecte desde el `PodPreset`.
5. Escribe una nota descriptiva de la especificación de Pod modificada resultante para
indicar que ha sido modificada por un `PodPreset`. La nota descriptiva presenta la forma
`podpreset.admission.kubernetes.io/podpreset-<pod-preset name>: "<resource version>"`.
Cada Pod puede ser correspondido por cero o más Pod Presets; y cada `Pod Preset` puede ser
aplicado a cero o más Pods. Cuando se aplica un `Pod Preset` a una o más Pods, Kubernetes
modifica la especificación del Pod. Para los cambios a `Env`, `EnvFrom`, y `VolumeMounts`,
Kubernetes modifica la especificación del Container para todos los Containers en el Pod;
para los cambios a `Volume`, Kubernetes modifica la especificación del Pod.
{{< note >}}
Un Pod Preset es capaz de modificar los siguientes campos en las especificaciones de un Pod
en caso de ser necesario:
- El campo `.spec.containers`.
- El campo `initContainers` (requiere Kubernetes versión 1.14.0 o posterior).
{{< /note >}}
### Deshabilitar un Pod Preset para un Pod específico
Puede haber casos en los que se desee que un Pod no se vea alterado por ninguna posible
modificación del Pod Preset. En estos casos, se puede añadir una observación en el Pod
Spec de la siguiente forma: `podpreset.admission.kubernetes.io/exclude: "true"`.
## Habilitando un Pod Preset
Con el fin de utilizar los Pod Presets en un clúster debe asegurarse de lo siguiente:
1. Que se ha configurado el tipo de API `settings.k8s.io/v1alpha1/podpreset`. Esto se puede hacer,
por ejemplo, incluyendo `settings.k8s.io/v1alpha1=true` como valor de la opción `--runtime-config`
en el servidor API. En minikube se debe añadir el flag
`--extra-config=apiserver.runtime-config=settings.k8s.io/v1alpha1=true` cuando el clúster
se está iniciando.
2. Que se ha habilitado el controlador de admisión `PodPreset`. Una forma de hacer esto es incluir
`PodPreset` como valor de la opción `--enable-admission-plugins` especificada
para el servidor API. En minikube se debe añadir el flag
```shell
--extra-config=apiserver.enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodPreset
```
cuando el clúster se está iniciando.
3. Que se han definido los Pod Presets mediante la creación de objetos `PodPreset` en el
namespace que se utilizará.
{{% /capture %}}
{{% capture whatsnext %}}
* [Inyectando datos en un Pod usando PodPreset](/docs/tasks/inject-data-application/podpreset/)
{{% /capture %}}
content/es/docs/home/_index.md
+1 -1
View File
@@ -3,7 +3,7 @@ title: Documentación de Kubernetes
noedit: true
cid: docsHome
layout: docsportal_home
class: gridPage
class: gridPage gridPageHome
linkTitle: "Home"
main_menu: true
weight: 10
content/es/docs/reference/glossary/application-architect.md
+3 -3
View File
@@ -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.
content/es/docs/reference/glossary/application-developer.md
+3 -3
View File
@@ -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.
content/es/docs/reference/glossary/applications.md
+13
View File
@@ -0,0 +1,13 @@
---
title: Applications
id: applications
date: 2019-08-06
full_link:
short_description: >
Es la capa donde se ejecutan varias aplicaciones en contenedores.
aka:
tags:
- fundamental
---
Es la capa donde se ejecutan varias aplicaciones en contenedores.
content/es/docs/reference/glossary/certificate.md
+2 -2
View File
@@ -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.
content/es/docs/reference/glossary/container-runtime.md
+21
View File
@@ -0,0 +1,21 @@
---
title: Container Runtime
id: container-runtime
date: 2019-06-05
full_link: /es/docs/reference/generated/container-runtime
short_description: >
El _Container Runtime_, entorno de ejecución de un contenedor, es el software responsable de ejecutar contenedores.
aka:
tags:
- fundamental
- workload
---
El _Container Runtime_ es el software responsable de ejecutar contenedores.
<!--more-->
Kubernetes soporta varios _Container Runtimes_: [Docker](http://www.docker.com),
[containerd](https://containerd.io), [cri-o](https://cri-o.io/),
[rktlet](https://github.com/kubernetes-incubator/rktlet) y cualquier implementación de
[Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md).
content/es/docs/reference/glossary/container.md
+20
View File
@@ -0,0 +1,20 @@
---
title: Contenedor
id: container
date: 2018-04-12
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:
tags:
- fundamental
- workload
---
Una imagen ligera y portátil que contiene un software y todas sus dependencias.
<!--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.
content/es/docs/reference/glossary/deployment.md
+21
View File
@@ -0,0 +1,21 @@
---
title: Deployment
id: deployment
date: 2018-04-12
full_link: /docs/concepts/workloads/controllers/deployment/
short_description: >
Un objeto API que gestiona una aplicación replicada.
aka:
tags:
- fundamental
- core-object
- workload
---
Un objeto API que gestiona una aplicación replicada.
<!--more-->
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.
content/es/docs/reference/glossary/docker.md
Executable
+17
View File
@@ -0,0 +1,17 @@
---
title: Docker
id: docker
date: 2018-04-12
full_link: https://docs.docker.com/engine/
short_description: >
Docker es una tecnología de software que proporciona virtualización a nivel de sistema operativo, también conocida como contenedores.
aka:
tags:
- fundamental
---
Docker (especialmente, Docker Engine) es una tecnología de software que proporciona virtualización a nivel de sistema operativo, también conocida como {{< glossary_tooltip text="contenedores" term_id="container" >}}.
<!--more-->
Docker utiliza características de aislamiento del Kernel de Linux como cgroups y namespaces, además de sistemas de archivos con capacidad de unión como OverlayFS para permitir que contenedores independientes se ejecuten dentro de una misma instancia de Linux, evitando el coste de iniciar y mantener máquinas virtuales (VM).
content/es/docs/reference/glossary/image.md
+3 -3
View File
@@ -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.
content/es/docs/reference/glossary/job.md
+2 -2
View File
@@ -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.
content/es/docs/reference/glossary/kops.md
Executable
+27
View File
@@ -0,0 +1,27 @@
---
title: Kops
id: kops
date: 2018-04-12
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:
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-->
`kops` provisiona el clúster con:
* Instalación totalmente automatizada
* Identificación de clúster basada en DNS
* Autoreparación ya que todo se ejecuta en grupos de instancias gestionados
* Soporte de Sistema Operativo limitado (Debian como opción recomendada, aunque soporta versiones de Ubuntu posteriores a la 16.04 y también ofrece soporte experimental para CentOS y RHEL)
* Soporte de Alta disponibilidad (HA)
* Habilidad para provisionar directamente la plataforma o generar los _manifests_ de Terraform equivalentes como salida
También puedes construir tu propio clúster utilizando directamente {{< glossary_tooltip term_id="kubeadm" >}}, que es la herramienta en la que se basa `kops`.
content/es/docs/reference/glossary/kube-proxy.md
Executable
+25
View File
@@ -0,0 +1,25 @@
---
title: kube-proxy
id: kube-proxy
date: 2018-04-12
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:
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
parte del concepto de Kubernetes {{< glossary_tooltip term_id="service">}}.
<!--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
y está disponible; de lo contrario, kube-proxy reenvía el tráfico por sí mismo.
content/es/docs/reference/glossary/kubeadm.md
Executable
+18
View File
@@ -0,0 +1,18 @@
---
title: Kubeadm
id: kubeadm
date: 2018-04-12
full_link: /docs/admin/kubeadm/
short_description: >
Utilidad para instalar Kubernetes con rapidez y configurar un clúster seguro.
aka:
tags:
- tool
- operation
---
Utilidad para instalar Kubernetes con rapidez y configurar un clúster seguro.
<!--more-->
Puedes usar kubeadm para instalar el Control Plane, formado por los nodos _master_, y también los componentes de nodos _worker_.
content/es/docs/reference/glossary/kubectl.md
Executable
+18
View File
@@ -0,0 +1,18 @@
---
title: Kubectl
id: kubectl
date: 2018-04-12
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:
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-->
Puedes usar kubectl para crear, inspeccionar, actualizar y borrar objetos de Kubernetes.
content/es/docs/reference/glossary/kubelet.md
Executable
+20
View File
@@ -0,0 +1,20 @@
---
title: Kubelet
id: kubelet
date: 2018-04-12
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:
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-->
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.
content/es/docs/reference/glossary/label.md
Executable
+16
View File
@@ -0,0 +1,16 @@
---
title: Label
id: label
date: 2019-10-26
full_link: /docs/concepts/overview/working-with-objects/labels
short_description: >
Metadatos en forma de clave-valor que permite añadir a los objetos atributos que sean relevantes para los usuarios para identificarlos.
aka:
tags:
- fundamental
---
Metadatos en forma de clave-valor que permite añadir a los objetos atributos que sean relevantes para los usuarios para identificarlos.
<!--more-->
Las etiquetas son pares clave-valor que se adhieren a los diferentes objetos, como los {{< glossary_tooltip text="Pods" term_id="pod" >}}, y que se utilizan para identificar, organizar y seleccionar subconjuntos de objetos.
content/es/docs/reference/glossary/minikube.md
Executable
+18
View File
@@ -0,0 +1,18 @@
---
title: Minikube
id: minikube
date: 2018-04-12
full_link: /docs/getting-started-guides/minikube/
short_description: >
Herramienta para ejecutar Kubernetes de forma local.
aka:
tags:
- fundamental
- tool
---
Herramienta para ejecutar Kubernetes de forma local.
<!--more-->
Minikube ejecuta un clúster de un solo nodo en una máquina virtual (VM) en tu máquina local.
content/es/docs/reference/glossary/name.md
+2 -2
View File
@@ -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.
content/es/docs/reference/glossary/persistent-volume-claim.md
Executable
+18
View File
@@ -0,0 +1,18 @@
---
title: Persistent Volume Claim
id: persistent-volume-claim
date: 2018-04-12
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:
tags:
- core-object
- storage
---
Reserva el recurso de almacenamiento definido en un PersistentVolume para poderlo montar como un volúmen en un contenedor.
<!--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.
content/es/docs/reference/glossary/pod-priority.md
+17
View File
@@ -0,0 +1,17 @@
---
title: Pod Priority
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" >}}.
aka:
tags:
- operation
---
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" >}}.
<!--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.
content/es/docs/reference/glossary/pod.md
+2 -2
View File
@@ -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" >}}.
content/es/docs/reference/glossary/replica-set.md
Executable
+19
View File
@@ -0,0 +1,19 @@
---
title: ReplicaSet
id: replica-set
date: 2018-05-16
full_link: /docs/concepts/workloads/controllers/replicaset/
short_description: >
El ReplicaSet es la nueva generación del ReplicationController.
aka:
tags:
- fundamental
- core-object
- workload
---
El ReplicaSet es la nueva generación del ReplicationController.
<!--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`.
content/es/docs/reference/glossary/secret.md
+2 -2
View File
@@ -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.
content/es/docs/reference/glossary/selector.md
+2 -2
View File
@@ -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" >}}.
content/es/docs/reference/glossary/sig.md
+20
View File
@@ -0,0 +1,20 @@
---
title: SIG (special interest group)
id: sig
date: 2018-04-12
full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-sig-list
short_description: >
Grupo de miembros de la comunidad que gestionan una pieza o parte del proyecto Kubernetes de forma colectiva.
aka:
tags:
- community
---
Grupo de {{< glossary_tooltip text="miembros de la comunidad" term_id="member" >}} que colectivamente gestionan una pieza o parte del proyecto Kubernetes.
<!--more-->
Los miembros dentro de un SIG tienen un interés compartido en avanzar en una área específica, como puede ser la arquitectura, la maquinaria detrás de las APIs, la usabilidad o la documentación.
Los SIGs deben cumplir las guías de SIG [pautas de gobernanza](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md), pero pueden tener sus propias normas de contribución y canales de comunicación.
Para más información, consulta el repositorio [kubernetes/community](https://github.com/kubernetes/community) y la lista de los [SIGs y Grupos de Trabajo (WGs)](https://github.com/kubernetes/community/blob/master/sig-list.md).
content/es/docs/reference/glossary/statefulset.md
+30
View File
@@ -0,0 +1,30 @@
---
title: StatefulSet
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,
*y garantiza el orden y unicidad* de dichos Pods.
tags:
- fundamental
- core-object
- workload
- storage
---
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-->
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
las actualizaciones que sean necesarias para alcanzarlo a partir del estado actual.
content/es/docs/reference/glossary/sysctl.md
+2 -2
View File
@@ -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`.
content/es/docs/reference/glossary/uid.md
+2 -2
View File
@@ -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.
content/es/docs/reference/glossary/volume.md
Executable
+18
View File
@@ -0,0 +1,18 @@
---
title: Volume
id: volume
date: 2018-04-12
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:
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-->
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" >}}.
content/es/docs/reference/kubernetes-api/index.md → content/es/docs/reference/kubernetes-api/api-index.md
View File
content/es/docs/setup/_index.md
+1 -1
View File
@@ -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 %}}
content/es/docs/setup/release/building-from-source.md
+1 -1
View File
@@ -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/)
content/es/docs/tasks/run-application/configure-pdb.md
+1 -1
View File
@@ -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
content/es/docs/tasks/tools/install-kubectl.md
+9 -10
View File
@@ -1,6 +1,5 @@
---
reviewers:
- bgrant0607
- mikedanese
title: Instalar y Configurar kubectl
content_template: templates/task
@@ -92,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:
```
@@ -109,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:
@@ -165,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
@@ -178,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:
```
@@ -191,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
```
@@ -226,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
```
@@ -262,7 +261,7 @@ Puedes instalar kubectl como parte del Google Cloud SDK.
## Configurar kubectl
Para que kubectl pueda encontrar y acceder a un clúster de Kubernetes, necesita un [fichero kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), que se crea de forma automática cuando creas un clúster usando kube-up.sh o despliegas de forma satisfactoria un clúster de Minikube. Revisa las [guías para comenzar](/docs/setup/) para más información acerca de crear clústers. Si necesitas acceso a un clúster que no has creado, ver el [documento de Compartir Acceso a un Clúster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
Para que kubectl pueda encontrar y acceder a un clúster de Kubernetes, necesita un [fichero kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/), que se crea de forma automática cuando creas un clúster usando [kube-up.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/kube-up.sh) o despliegas de forma satisfactoria un clúster de Minikube. Revisa las [guías para comenzar](/docs/setup/) para más información acerca de crear clústers. Si necesitas acceso a un clúster que no has creado, ver el [documento de Compartir Acceso a un Clúster](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/).
Por defecto, la configuración de kubectl se encuentra en `~/.kube/config`.
## Comprobar la configuración kubectl
content/es/docs/tasks/tools/install-minikube.md
+1 -1
View File
@@ -49,7 +49,7 @@ Minikube también soporta una opción `--vm-driver=none` que ejecuta los compone
La forma más fácil de instalar Minikube en macOS es usar [Homebrew](https://brew.sh):
```shell
brew cask install minikube
brew install minikube
```
También puedes instalarlo en macOS descargando un ejecutable autocontenido:
content/es/docs/tutorials/_index.md
+1 -1
View File
@@ -27,7 +27,7 @@ Antes de recorrer cada tutorial, recomendamos añadir un marcador a
* [Introduction to Kubernetes (edX)](https://www.edx.org/course/introduction-kubernetes-linuxfoundationx-lfs158x#)
* [Hello Minikube](/docs/tutorials/hello-minikube/)
* [Hello Minikube](/es/docs/tutorials/hello-minikube/)
## Configuración
content/es/docs/tutorials/hello-minikube.md
+275
View File
@@ -0,0 +1,275 @@
---
title: Hello Minikube
content_template: templates/tutorial
weight: 5
menu:
main:
title: "Get Started"
weight: 10
post: >
<p>¿Listo para poner manos a la obra? Construye un clúster sencillo de Kubernetes que ejecuta un Hola Mundo para Node.js</p>
card:
name: tutorials
weight: 10
---
{{% capture overview %}}
Este tutorial muestra como ejecutar una aplicación Node.js Hola Mundo en Kubernetes utilizando
[Minikube](/docs/setup/learning-environment/minikube) y Katacoda.
Katacoda provee un ambiente de Kubernetes desde el navegador.
{{< note >}}
También se puede seguir este tutorial si se ha instalado [Minikube localmente](/docs/tasks/tools/install-minikube/).
{{< /note >}}
{{% /capture %}}
{{% capture objectives %}}
* Desplegar una aplicación Hola Mundo en Minikube.
* Ejecutar la aplicación.
* Ver los logs de la aplicación.
{{% /capture %}}
{{% capture prerequisites %}}
Este tutorial provee una imagen de contenedor construida desde los siguientes archivos:
{{< codenew language="js" file="minikube/server.js" >}}
{{< codenew language="conf" file="minikube/Dockerfile" >}}
Para más información sobre el comando `docker build`, lea la [documentación de Docker ](https://docs.docker.com/engine/reference/commandline/build/).
{{% /capture %}}
{{% capture lessoncontent %}}
## Crear un clúster Minikube
1. Haz clic en **Launch Terminal**
{{< kat-button >}}
{{< note >}}Si se tiene instalado Minikube local, ejecutar `minikube start`.{{< /note >}}
2. Abrir el tablero de Kubernetes dashboard en un navegador:
```shell
minikube dashboard
```
3. Solo en el ambiente de Katacoda: En la parte superior de la terminal, haz clic en el símbolo + y luego clic en **Select port to view on Host 1**.
4. Solo en el ambiente de Katacoda: Escribir `30000`, y hacer clic en **Display Port**.
## Crear un Deployment
Un [*Pod*](/docs/concepts/workloads/pods/pod/) en Kubernetes es un grupo de uno o más contenedores,
asociados con propósitos de administración y redes. El Pod en este tutorial tiene solo un contenedor.
Un [*Deployment*](/docs/concepts/workloads/controllers/deployment/) en Kubernetes verifica la salud del Pod y reinicia su contenedor si este es eliminado. Los Deployments son la manera recomendada de manejar la creación y escalación.
1. Ejecutar el comando `kubectl create` para crear un Deployment que maneje un Pod. El Pod ejecuta un contenedor basado en la imagen proveida por Docker.
```shell
kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4
```
2. Ver el Deployment:
```shell
kubectl get deployments
```
El resultado es similar a:
```
NAME READY UP-TO-DATE AVAILABLE AGE
hello-node 1/1 1 1 1m
```
3. Ver el Pod:
```shell
kubectl get pods
```
El resultado es similar a:
```
NAME READY STATUS RESTARTS AGE
hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m
```
4. Ver los eventos del clúster:
```shell
kubectl get events
```
5. Ver la configuración `kubectl`:
```shell
kubectl config view
```
{{< note >}} Para más información sobre el comando `kubectl`, ver [kubectl overview](/docs/user-guide/kubectl-overview/).{{< /note >}}
## Crear un Service
Por defecto, el Pod es accedido por su dirección IP interna dentro del clúster de Kubernetes, para hacer que el contenedor `hello-node` sea accesible desde afuera de la red virtual Kubernetes, se debe exponer el Pod como un
[*Service*](/docs/concepts/services-networking/service/) de Kubernetes.
1. Exponer el Pod a la red pública de internet utilizando el comando `kubectl expose`:
```shell
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
```
El flag `--type=LoadBalancer` indica que se quiere exponer el Service fuera del clúster.
2. Ver el Service creado:
```shell
kubectl get services
```
El resultado es similar a:
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-node LoadBalancer 10.108.144.78 <pending> 8080:30369/TCP 21s
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 23m
```
Para los proveedores Cloud que soportan balanceadores de carga, una dirección IP externa será provisionada para acceder al servicio, en Minikube, el tipo `LoadBalancer` permite que el servicio sea accesible a través del comando `minikube service`.
3. Ejecutar el siguiente comando:
```shell
minikube service hello-node
```
4. Solo en el ambiente de Katacoda: Hacer clic sobre el símbolo +, y luego en **Select port to view on Host 1**.
5. Solo en el ambiente de Katacoda: Anotar el puerto de 5 dígitos ubicado al lado del valor de `8080` en el resultado de servicios. Este número de puerto es generado aleatoriamente y puede ser diferente al indicado en el ejemplo. Escribir el número de puerto en el cuadro de texto y hacer clic en Display Port. Usando el ejemplo anterior, usted escribiría `30369`.
Esto abre una ventana de navegador que contiene la aplicación y muestra el mensaje "Hello World".
## Habilitar Extensiones
Minikube tiene un conjunto de {{< glossary_tooltip text="Extensiones" term_id="addons" >}} que pueden ser habilitados y desahabilitados en el ambiente local de Kubernetes.
1. Listar las extensiones soportadas actualmente:
```shell
minikube addons list
```
El resultado es similar a:
```
addon-manager: enabled
dashboard: enabled
default-storageclass: enabled
efk: disabled
freshpod: disabled
gvisor: disabled
helm-tiller: disabled
ingress: disabled
ingress-dns: disabled
logviewer: disabled
metrics-server: disabled
nvidia-driver-installer: disabled
nvidia-gpu-device-plugin: disabled
registry: disabled
registry-creds: disabled
storage-provisioner: enabled
storage-provisioner-gluster: disabled
```
2. Habilitar una extensión, por ejemplo, `metrics-server`:
```shell
minikube addons enable metrics-server
```
El resultado es similar a:
```
metrics-server was successfully enabled
```
3. Ver el Pod y Service creados:
```shell
kubectl get pod,svc -n kube-system
```
El resultado es similar a:
```
NAME READY STATUS RESTARTS AGE
pod/coredns-5644d7b6d9-mh9ll 1/1 Running 0 34m
pod/coredns-5644d7b6d9-pqd2t 1/1 Running 0 34m
pod/metrics-server-67fb648c5 1/1 Running 0 26s
pod/etcd-minikube 1/1 Running 0 34m
pod/influxdb-grafana-b29w8 2/2 Running 0 26s
pod/kube-addon-manager-minikube 1/1 Running 0 34m
pod/kube-apiserver-minikube 1/1 Running 0 34m
pod/kube-controller-manager-minikube 1/1 Running 0 34m
pod/kube-proxy-rnlps 1/1 Running 0 34m
pod/kube-scheduler-minikube 1/1 Running 0 34m
pod/storage-provisioner 1/1 Running 0 34m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/metrics-server ClusterIP 10.96.241.45 <none> 80/TCP 26s
service/kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP 34m
service/monitoring-grafana NodePort 10.99.24.54 <none> 80:30002/TCP 26s
service/monitoring-influxdb ClusterIP 10.111.169.94 <none> 8083/TCP,8086/TCP 26s
```
4. Deshabilitar `metrics-server`:
```shell
minikube addons disable metrics-server
```
El resultado es similar a:
```
metrics-server was successfully disabled
```
## Limpieza
Ahora se puede eliminar los recursos creados en el clúster:
```shell
kubectl delete service hello-node
kubectl delete deployment hello-node
```
Opcional, detener la máquina virtual de Minikube:
```shell
minikube stop
```
Opcional, eliminar la máquina virtual de Minikube:
```shell
minikube delete
```
{{% /capture %}}
{{% capture whatsnext %}}
* Leer más sobre [Deployments](/docs/concepts/workloads/controllers/deployment/).
* Leer más sobre [Desplegando aplicaciones](/docs/tasks/run-application/run-stateless-application-deployment/).
* Leer más sobre [Services](/docs/concepts/services-networking/service/).
{{% /capture %}}
content/es/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+37
View File
@@ -0,0 +1,37 @@
---
title: Tutorial interactivo - Crear un clúster
weight: 20
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<div class="katacoda">
<div class="katacoda__alert">
Para interactuar con la Terminal, use la versión de escritorio / tableta
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="es" data-katacoda-id="kubernetes-bootcamp/1" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;"></div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro/" role="button">Continuar con el Módulo 2<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>
content/es/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html
+41
View File
@@ -0,0 +1,41 @@
---
title: Tutorial interactivo - Implementando una aplicación
weight: 20
---
<!DOCTYPE html>
<html lang="en">
<body>
<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">
<link href="/docs/tutorials/kubernetes-basics/public/css/overrides.css" rel="stylesheet">
<script src="https://katacoda.com/embed.js"></script>
<div class="layout" id="top">
<main class="content katacoda-content">
<br>
<div class="katacoda">
<div class="katacoda__alert">
Para interactuar con la Terminal, use la versión de escritorio / tableta
</div>
<div class="katacoda__box" id="inline-terminal-1" data-katacoda-lang="es" data-katacoda-id="kubernetes-bootcamp/7" data-katacoda-color="326de6" data-katacoda-secondary="273d6d" data-katacoda-hideintro="false" data-katacoda-font="Roboto" data-katacoda-fontheader="Roboto Slab" data-katacoda-prompt="Kubernetes Bootcamp Terminal" style="height: 600px;">
</div>
</div>
<div class="row">
<div class="col-md-12">
<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/explore/explore-intro/" role="button">Continuar con el Módulo 3<span class="btn__next">›</span></a>
</div>
</div>
</main>
</div>
</body>
</html>