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

Remove trailing spaces from ES documents(#16742) (#16785)

Browse Source
This commit is contained in:
Yushiro FURUKAWA
2019-10-10 15:52:52 +09:00
committed by Kubernetes Prow Robot
parent 520caa1264
commit af66c0a274
40 changed files with 167 additions and 167 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/es/docs/concepts/workloads/controllers/replicationcontroller.md
+42 -42
View File
@@ -1,11 +1,11 @@
---
title: ReplicationController
feature:
feature:
title: Auto-reparación
anchor: Cómo funciona un ReplicationController
description: >
Reinicia contenedores que fallan, sustituye y reprograma contenedores cuando los nodos mueren,
mata los contenedores que no responden a tus pruebas de salud definidas,
Reinicia contenedores que fallan, sustituye y reprograma contenedores cuando los nodos mueren,
mata los contenedores que no responden a tus pruebas de salud definidas,
y no los expone a los clientes hasta que no están listo para servirse.
content_template: templates/concept
@@ -30,7 +30,7 @@ siempre esté arriba y disponible.
## Cómo Funciona un ReplicationController
Si hay muchos pods, el ReplicationController termina los pods extra. Si hay muy pocos, el
ReplicationController arranca más pods. A difrencia de los pods creados manualmente, los pods mantenidos por un
ReplicationController arranca más pods. A difrencia de los pods creados manualmente, los pods mantenidos por un
ReplicationController se sustituyen de forma automática si fallan, se borran, o se terminan.
Por ejemplo, tus pods se re-crean en un nodo durante una intervención disruptiva de mantenimiento como una actualización del kernel.
Por esta razón, deberías usar un ReplicationController incluso cuando tu aplicación sólo necesita
@@ -38,7 +38,7 @@ un único pod. Un ReplicationController es parecido a un supervisor de procesos,
pero en vez de supervisar procesos individuales en un único nodo,
el ReplicationController supervisa múltiples pods entre múltiples nodos.
A menudo nos referimos a un ReplicationController de forma abreviada como "rc" o "rcs", así como
A menudo nos referimos a un ReplicationController de forma abreviada como "rc" o "rcs", así como
atajo en los comandos de kubectl.
Un caso simple es crear un objeto ReplicationController para ejecutar de manera fiable una instancia
@@ -90,7 +90,7 @@ Events:
20s 20s 1 {replication-controller } Normal SuccessfulCreate Created pod: nginx-4ok8v
```
Como se puede observar, se han creado tres pods, pero ninguno se está ejecutándose todavía,
Como se puede observar, se han creado tres pods, pero ninguno se está ejecutándose todavía,
puede que porque la imagen todavía se está descargando.
Unos momentos después, el mismo comando puede que muestre:
@@ -98,7 +98,7 @@ Unos momentos después, el mismo comando puede que muestre:
Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed
```
Para listar todos los pods que pertenecen al ReplicationController de forma legible,
Para listar todos los pods que pertenecen al ReplicationController de forma legible,
puedes usar un comando como el siguiente:
```shell
@@ -126,13 +126,13 @@ Un ReplicationController también necesita un [sección `.spec`](https://git.k8s
El campo `.spec.template` es el único campo requerido de `.spec`.
El campo `.spec.template` es una [plantilla pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates).
El campo `.spec.template` es una [plantilla pod](/docs/concepts/workloads/pods/pod-overview/#pod-templates).
Tiene exactamente el mismo esquema que un [pod](/docs/concepts/workloads/pods/pod/), excepto por el hecho de que está anidado y no tiene los campos `apiVersion` ni `kind`.
Además de los campos obligatorios de un Pod, una plantilla pod de un ReplicationController debe especificar las etiquetas apropiadas
y la regla de reinicio apropiada. En el caso de las etiquetas, asegúrate que no se entremezclan con otros controladores. Ver el [selector de pod](#pod-selector).
Sólo se permite el valor `Always` para el campo [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy),
Sólo se permite el valor `Always` para el campo [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy),
que es el valor predeterminado si no se indica.
Para los reinicios locales de los contenedores, los ReplicationControllers delegan en los agentes del nodo,
@@ -154,7 +154,7 @@ pods que creó o eliminó, y pods que otra persona o proceso creó o eliminó. E
Si se indica, el valor de `.spec.template.metadata.labels` debe ser igual al de `.spec.selector`, o será rechazado por la API.
Si no se indica el valor de `.spec.selector`, se tomará como predeterminado el de `.spec.template.metadata.labels`.
Tampoco deberías crear ningún pod cuyas etiquetas coincidan con las de este selector, ni directamente con
Tampoco deberías crear ningún pod cuyas etiquetas coincidan con las de este selector, ni directamente con
otro ReplicationController, ni con otro controlador como un Job. Si lo haces, el
ReplicationController piensa que el creó también los otros pods. Kubernetes no te impide hacerlo.
@@ -197,48 +197,48 @@ Para actualizar los pods con una nueva especificación de forma controlada, util
### Aislar pods de un ReplicationController
Se puede aislar Pods del conjunto destino de un ReplicationController cambiando sus etiquetas.
Esta técnica puede usarse para eliminar pods de un servicio para poder depurarlos, recuperar datos, etc.
Se puede aislar Pods del conjunto destino de un ReplicationController cambiando sus etiquetas.
Esta técnica puede usarse para eliminar pods de un servicio para poder depurarlos, recuperar datos, etc.
Los Pods que se eliminan de esta forma serán sustituidos de forma automática (asumiendo que el número de réplicas no ha cambiado tampoco).
## Patrones comunes de uso
### Reprogramación
Como se comentó arriba, cuando tienes 1 pod que quieres mantener ejecutándose, o 1000, un ReplicationController se asegura de que el número indicado de pods exista,
Como se comentó arriba, cuando tienes 1 pod que quieres mantener ejecutándose, o 1000, un ReplicationController se asegura de que el número indicado de pods exista,
incluso si falla un nodo o se termina algún pod (por ejemplo, debido a alguna acción de otro agente de control).
### Escalado
El ReplicationController facilita el escalado del número de réplicas tanto para su aumento como para su disminución,
El ReplicationController facilita el escalado del número de réplicas tanto para su aumento como para su disminución,
bien manualmente o mediante un agente de auto-escalado, simplemente actualizando el campo `replicas`.
### Actualizaciones en línea
El ReplicationController se ha diseñado para facilitar las actualizaciones en línea de un servicio mediante la sustitución de sus pods uno por uno.
Cómo se explicó en [#1353](http://issue.k8s.io/1353), la estrategia recomendada es crear un nuevo ReplicationController con 1 réplica,
escalar el nuevo (+1) y el viejo (-1) controlador uno por uno, y entonces eliminar el viejo controlador una vez que alcanza las 0 réplicas.
Cómo se explicó en [#1353](http://issue.k8s.io/1353), la estrategia recomendada es crear un nuevo ReplicationController con 1 réplica,
escalar el nuevo (+1) y el viejo (-1) controlador uno por uno, y entonces eliminar el viejo controlador una vez que alcanza las 0 réplicas.
Esto actualiza de forma predecible el conjunto de pods independientemente de que se produzcan fallos inesperados.
De forma ideal, el controlador de actualización en línea tendrá en cuenta si la aplicación está lista, y
se asegurará de que un número suficiente de pods está en servicio en todo momento.
Los dos ReplicationControllers necesitarán crear pods con al menos una etiqueta diferenciadora, como la etiqueta de imagen del contenedor primario del pod,
Los dos ReplicationControllers necesitarán crear pods con al menos una etiqueta diferenciadora, como la etiqueta de imagen del contenedor primario del pod,
ya que las actualizaciones de imagen son las que normalmente desencadenan las actualizaciones en línea.
La actualización en línea se implementa a través de la herramienta cliente mediante
[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update).
La actualización en línea se implementa a través de la herramienta cliente mediante
[`kubectl rolling-update`](/docs/reference/generated/kubectl/kubectl-commands#rolling-update).
Echa un vistazo a la [tarea `kubectl rolling-update`](/docs/tasks/run-application/rolling-update-replication-controller/) para más ejemplos concretos.
### Múltiples operaciones de despliegue
Además de llevar a cabo múltiples despliegues de una aplicación cuando una actualización en línea está en progreso,
Además de llevar a cabo múltiples despliegues de una aplicación cuando una actualización en línea está en progreso,
es común ejecutar varios despliegues durante un período extendido de tiempo, o incluso de forma contínua, usando múltiples operaciones de despliegue. Dichas operaciones se diferenciarían por etiquetas.
Por ejemplo, un servicio puede que exponga todos los pods con etiquetas `tier in (frontend), environment in (prod)`. Ahora digamos que tenemos 10 pods replicados que forman este grupo.
Pero queremos poder desplegar una nueva versión 'canary' de este component. Se podría configurar un ReplicationController con el valor de `replicas` puesto a 9 para la mayor parte de las réplicas,
con etiquetas `tier=frontend, environment=prod, track=stable`, y otro ReplicationController con el valor de `replicas` puesto a 1 para el 'canary',
Pero queremos poder desplegar una nueva versión 'canary' de este component. Se podría configurar un ReplicationController con el valor de `replicas` puesto a 9 para la mayor parte de las réplicas,
con etiquetas `tier=frontend, environment=prod, track=stable`, y otro ReplicationController con el valor de `replicas` puesto a 1 para el 'canary',
con las etiquetas `tier=frontend, environment=prod, track=canary`. Así el servicio cubriría tanto los pods canary como el resto.
Pero también es posible trastear con los ReplicationControllers de forma separada para probar cosas, monitorizar los resultados, etc.
@@ -247,35 +247,35 @@ Pero también es posible trastear con los ReplicationControllers de forma separa
Un único servicio puede exponer múltiples ReplicationControllers, de forma que, por ejemplo, algo de tráfico
vaya a la versión vieja, y otro tanto vaya a la versión nueva.
Un ReplicationController nunca se terminará por sí mismo, pero tampoco se espera que se ejecute permanentemente como los servicios.
Los servicios puede que estén compuestos de pods controlados por múltiples ReplicationControllers,
y se espera que muchos ReplicationControllers se creen y se destruyan durante el ciclo de vida de un servicio (por ejemplo,
Un ReplicationController nunca se terminará por sí mismo, pero tampoco se espera que se ejecute permanentemente como los servicios.
Los servicios puede que estén compuestos de pods controlados por múltiples ReplicationControllers,
y se espera que muchos ReplicationControllers se creen y se destruyan durante el ciclo de vida de un servicio (por ejemplo,
para realizar una actualización de los pods que ejecutan el servicio). Ambos servicios mismos y sus clientes deberían permanecer
ajenos a los ReplicationControllers que mantienen los pods que proporcionan los servicios.
## Escribir aplicaciones que se repliquen
Los Pods creados por un ReplicationController están pensados para que sean intercambiables y semánticamente idénticos,
aunque sus configuraciones puede que sean heterogéneas a lo largo del tiempo. Este es un ajuste obvio para los servidores sin estado replicados,
pero los ReplicationControllers también pueden utilizarse para mantener la disponibilidad de aplicaciones que se elijen por un maestro, las particionadas, y las de grupos de trabajadores.
Dichas aplicaciones deberían usar los mecanismos de asignación dinámica de trabajo, como las [colas de trabajo RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-two-python.html),
en vez de la personalización estática/de una sola vez en la configuración de cada pod,
ya que se considera un anti-patrón. Cualquier personalización de pod que se haga, como el calibrado vertical automático de recursos (por ejemplo, cpu o memoria),
Los Pods creados por un ReplicationController están pensados para que sean intercambiables y semánticamente idénticos,
aunque sus configuraciones puede que sean heterogéneas a lo largo del tiempo. Este es un ajuste obvio para los servidores sin estado replicados,
pero los ReplicationControllers también pueden utilizarse para mantener la disponibilidad de aplicaciones que se elijen por un maestro, las particionadas, y las de grupos de trabajadores.
Dichas aplicaciones deberían usar los mecanismos de asignación dinámica de trabajo, como las [colas de trabajo RabbitMQ](https://www.rabbitmq.com/tutorials/tutorial-two-python.html),
en vez de la personalización estática/de una sola vez en la configuración de cada pod,
ya que se considera un anti-patrón. Cualquier personalización de pod que se haga, como el calibrado vertical automático de recursos (por ejemplo, cpu o memoria),
debería realizarse a través de otro proceso de controlador en línea, no con el mismo ReplicationController.
## Responsabilidades de un ReplicationController
El ReplicationController simplemente garantiza que el número deseado de pods coincide con su selector de etiqueta y que son operacionales.
El ReplicationController simplemente garantiza que el número deseado de pods coincide con su selector de etiqueta y que son operacionales.
Actualmente, sólo los pods que han terminado se excluyen de la cuenta. En el futuro, la [disponibilidad](http://issue.k8s.io/620) y otra información disponible en el sistema
se tendrá en cuenta, se añadirá más controles sobre la regla de sussitución, y se está planificando
se tendrá en cuenta, se añadirá más controles sobre la regla de sussitución, y se está planificando
emitir eventos que podrían ser aprovechados por clientes externos para implementar reglas complejas de sustitución y escalado de forma arbitraria.
El ReplicationController está siempre condicionado a esta reducida responsabilidad.
Él mismo no llevará a cabo ni pruebas de estar listo ni vivo. En vez de aplicar el auto-escalado,
se pretende que este sea realizado por un auto-escalador externo (como se vio en [#492](http://issue.k8s.io/492)), que sería el encargado de cambiar su campo `replicas`.
No se añadirá reglas de programación (por ejemplo, [propagación](http://issue.k8s.io/367#issuecomment-48428019)) al ReplicationController.
Ni se debería validar que los pods controlados coincidan con la plantilla actual especificada, ya que eso obstruiría el auto-calibrado y otros procesos automáticos.
De forma similar, los vencimientos de término, las dependencias de orden, la extensión de la configuración, y otras características se aplican en otro lado.
El ReplicationController está siempre condicionado a esta reducida responsabilidad.
Él mismo no llevará a cabo ni pruebas de estar listo ni vivo. En vez de aplicar el auto-escalado,
se pretende que este sea realizado por un auto-escalador externo (como se vio en [#492](http://issue.k8s.io/492)), que sería el encargado de cambiar su campo `replicas`.
No se añadirá reglas de programación (por ejemplo, [propagación](http://issue.k8s.io/367#issuecomment-48428019)) al ReplicationController.
Ni se debería validar que los pods controlados coincidan con la plantilla actual especificada, ya que eso obstruiría el auto-calibrado y otros procesos automáticos.
De forma similar, los vencimientos de término, las dependencias de orden, la extensión de la configuración, y otras características se aplican en otro lado.
Incluso se plantea excluir el mecanismo de creación de pods a granel ([#170](http://issue.k8s.io/170)).
El ReplicationController está pensado para ser una primitiva de bloques is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale, rolling-update) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
@@ -304,11 +304,11 @@ porque a diferencia del comando `kubectl rolling-update`, son declarativos, se e
### Pods simples
A diferencia del caso en que un usuario ha creado directamente pods, un ReplicationController sustituye los pods que han sido eliminador o terminados por cualquier motivo,
A diferencia del caso en que un usuario ha creado directamente pods, un ReplicationController sustituye los pods que han sido eliminador o terminados por cualquier motivo,
como en el caso de un fallo de un nodo o una intervención disruptiva de mantenimiento, como la actualización del kernel.
Por esta razón, se recomienda que se usa un ReplicationController incluso si tu aplicación sólo necesita un único pod.
Por esta razón, se recomienda que se usa un ReplicationController incluso si tu aplicación sólo necesita un único pod.
Piensa que es similar a un supervisor de proceso, sólo que supervisa múltiples pods entre múltiples nodos en vez de
procesos individuales en un único nodo. Un ReplicationController delega los reinicios locales de
procesos individuales en un único nodo. Un ReplicationController delega los reinicios locales de
los contenedores a algún agente del nodo (por ejemplo, Kubelet o Docker).
### Job
content/es/docs/concepts/workloads/controllers/statefulset.md
+15 -15
View File
@@ -104,12 +104,12 @@ spec:
```
## Selector de Pod
Debes poner el valor del campo `.spec.selector` de un StatefulSet para que coincida con las etiquetas de su campo `.spec.template.metadata.labels`. Antes de Kubernetes 1.8,
Debes poner el valor del campo `.spec.selector` de un StatefulSet para que coincida con las etiquetas de su campo `.spec.template.metadata.labels`. Antes de Kubernetes 1.8,
el campo `.spec.selector` se predeterminaba cuando se omitía. A partir de la versión 1.8, si no se especifica un selector de coincidencia de Pods, se produce un error de validación
durante la creación del StatefulSet.
## Identidad de Pod
Los Pods de un StatefulSet tienen una identidad única que está formada por un ordinal,
Los Pods de un StatefulSet tienen una identidad única que está formada por un ordinal,
una identidad estable de red, y almacenamiento estable. La identidad se asocia al Pod,
independientemente del nodo en que haya sido (re)programado.
@@ -131,7 +131,7 @@ Conforme se crea cada Pod, se le asigna un nombre DNS correspondiente de subdomi
`$(podname).$(governing service domain)`, donde el servicio en funciones se define por el campo
`serviceName` del StatefulSet.
Como se indicó en la sección [limitaciones](#limitaciones), la creación del
Como se indicó en la sección [limitaciones](#limitaciones), la creación del
[Servicio Headless](/docs/concepts/services-networking/service/#headless-services)
encargado de la identidad de red de los pods es enteramente tu responsabilidad.
@@ -153,17 +153,17 @@ El valor de Cluster Domain se pondrá a `cluster.local` a menos que
Kubernetes crea un [PersistentVolume](/docs/concepts/storage/persistent-volumes/) para cada
VolumeClaimTemplate. En el ejemplo de nginx de arriba, cada Pod recibirá un único PersistentVolume
con una StorageClass igual a `my-storage-class` y 1 Gib de almacenamiento provisionado. Si no se indica ninguna StorageClass,
con una StorageClass igual a `my-storage-class` y 1 Gib de almacenamiento provisionado. Si no se indica ninguna StorageClass,
entonces se usa la StorageClass por defecto. Cuando un Pod se (re)programa
en un nodo, sus `volumeMounts` montan los PersistentVolumes asociados con sus
PersistentVolume Claims. Nótese que los PersistentVolumes asociados con los
PersistentVolume Claims. Nótese que los PersistentVolumes asociados con los
PersistentVolume Claims de los Pods no se eliminan cuando los Pods, o los StatefulSet se eliminan.
Esto debe realizarse manualmente.
### Etiqueta de Nombre de Pod
Cuando el controlador del StatefulSet crea un Pod, añade una etiqueta, `statefulset.kubernetes.io/pod-name`,
que toma el valor del nombre del Pod. Esta etiqueta te permite enlazar un Service a un Pod específico
Cuando el controlador del StatefulSet crea un Pod, añade una etiqueta, `statefulset.kubernetes.io/pod-name`,
que toma el valor del nombre del Pod. Esta etiqueta te permite enlazar un Service a un Pod específico
en el StatefulSet.
## Garantías de Despliegue y Escalado
@@ -173,12 +173,12 @@ en el StatefulSet.
* Antes de que una operación de escalado se aplique a un Pod, todos sus predecesores deben estar Running y Ready.
* Antes de que se termine un Pod, todos sus sucesores deben haberse apagado completamente.
El StatefulSet no debería tener que indicar un valor 0 para el campo `pod.Spec.TerminationGracePeriodSeconds`.
El StatefulSet no debería tener que indicar un valor 0 para el campo `pod.Spec.TerminationGracePeriodSeconds`.
Esta práctica no es segura y se aconseja no hacerlo. Para una explicación más detallada, por favor echa un vistazo a cómo [forzar la eliminación de Pods de un StatefulSet](/docs/tasks/run-application/force-delete-stateful-set-pod/).
Cuando el ejemplo nginx de arriba se crea, se despliegan tres Pods en el orden
Cuando el ejemplo nginx de arriba se crea, se despliegan tres Pods en el orden
web-0, web-1, web-2. web-1 no se desplegará hasta que web-0 no esté
[Running y Ready](/docs/user-guide/pod-states/), y web-2 no se desplegará hasta que
[Running y Ready](/docs/user-guide/pod-states/), y web-2 no se desplegará hasta que
web-1 esté Running y Ready. En caso de que web-0 fallase, después de que web-1 estuviera Running y Ready, pero antes
de que se desplegara web-2, web-2 no se desplegaría hasta que web-0 se redesplegase con éxito y estuviera
Running y Ready.
@@ -207,7 +207,7 @@ y Ready o completamente terminados antes de lanzar o terminar otro Pod.
## Estrategias de Actualización
En Kubernetes 1.7 y a posteriori, el campo `.spec.updateStrategy` del StatefulSet permite configurar
y deshabilitar las actualizaciones automátizadas en línea para los contenedores, etiquetas, peticiones/límites de recursos,
y deshabilitar las actualizaciones automátizadas en línea para los contenedores, etiquetas, peticiones/límites de recursos,
y anotaciones de los Pods del StatefulSet.
### On Delete
@@ -228,14 +228,14 @@ actualizar su predecesor.
#### Particiones
La estrategia de actualización `RollingUpdate` puede particionarse, indicando el valor del campo
La estrategia de actualización `RollingUpdate` puede particionarse, indicando el valor del campo
`.spec.updateStrategy.rollingUpdate.partition`. Si se indica una partición, todos los Pods con un
número ordinal mayor o igual que el de la partición serán actualizados cuando el campo `.spec.template`
del StatefulSet se actualice. Todos los Pods con un número ordinal que sea menor que el de la partición
número ordinal mayor o igual que el de la partición serán actualizados cuando el campo `.spec.template`
del StatefulSet se actualice. Todos los Pods con un número ordinal que sea menor que el de la partición
no serán actualizados, e incluso si son eliminados, serán recreados con la versión anterior. Si el campo
`.spec.updateStrategy.rollingUpdate.partition` de un StatefulSet es mayor que el valor del campo `.spec.replicas`,
las modificaciones al campo `.spec.template` no se propagarán a sus Pods.
En la mayoría de ocasiones, no necesitarás usar una partición, pero pueden resultar útiles si quieres preparar una actualización,
En la mayoría de ocasiones, no necesitarás usar una partición, pero pueden resultar útiles si quieres preparar una actualización,
realizar un despliegue tipo canary, o llevar a cabo un despliegue en fases.
#### Retroceso Forzado
content/es/docs/concepts/workloads/controllers/ttlafterfinished.md
+7 -7
View File
@@ -29,11 +29,11 @@ Descargo de responsabilidad Alpha: esta característica está actualmente en ver
## Controlador TTL
El controlador TTL sólo soporta los Jobs por ahora. Un operador del clúster puede usar esta funcionalidad para limpiar
los Jobs terminados (bien `Complete` o `Failed`) automáticamente especificando el valor del campo
`.spec.ttlSecondsAfterFinished` del Job, como en este
los Jobs terminados (bien `Complete` o `Failed`) automáticamente especificando el valor del campo
`.spec.ttlSecondsAfterFinished` del Job, como en este
[ejemplo](/docs/concepts/workloads/controllers/jobs-run-to-completion/#clean-up-finished-jobs-automatically).
El controlador TTL asumirá que un recurso es candidato a ser limpiado
TTL segundos después de que el recurso haya terminado; dicho de otra forma, cuando el TTL haya expirado.
El controlador TTL asumirá que un recurso es candidato a ser limpiado
TTL segundos después de que el recurso haya terminado; dicho de otra forma, cuando el TTL haya expirado.
Cuando el controlador TTL limpia un recursos, lo elimina en cascada, esto es, borra
sus objetos subordinados juntos. Nótese que cuando se elimina un recurso,
se respetan las garantías de su ciclo de vida, como con los finalizadores.
@@ -47,9 +47,9 @@ Los segundos TTL pueden ser configurados en cualquier momento. Aquí se muestran
* Usando un [mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
para poner el valor de este campo dinámicamente en el momento de la creación del recursos. Los administradores del clúster pueden
usar este enfoque para forzar una regla TTL para los recursos terminados.
* Usando un
* Usando un
[mutating admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)
para poner el valor de este campo dinámicamente después de que el recurso haya terminado,
para poner el valor de este campo dinámicamente después de que el recurso haya terminado,
y eligiendo diferentes valores TTL basados en los estados de los recursos, etiquetas, etc.
## Advertencia
@@ -71,7 +71,7 @@ en momentos equivocados.
En Kubernetes, se necesita ejecutar NTP en todos los nodos
(ver [#6159](https://github.com/kubernetes/kubernetes/issues/6159#issuecomment-93844058))
para evitar este problema. Los relojes no siempre son correctos, pero la diferencia debería ser muy pequeña.
para evitar este problema. Los relojes no siempre son correctos, pero la diferencia debería ser muy pequeña.
Ten presente este riesgo cuando pongas un valor distinto de cero para el TTL.
{{% /capture %}}