Add content/es/docs/concepts_workloads_controllers/replicationcontroller_statefulset_and_ttl

content/es/docs/concepts/workloads/controllers/statefulset.md

@@ -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/#how-it-works).
+{{< /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

@@ -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/reference/glossary/container.md

@@ -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

@@ -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.
+