Spanish Translation (#14852)
This commit is contained in:
Enrique Medina Montenegro
Kubernetes Prow Robot
parent
546b719b30
commit
c1541a6f12
|
|
@ -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 %}}
|
||||
|
||||
|
||||
|
|
@ -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 %}}
|
||||
|
||||
|
|
@ -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 %}}
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
apiVersion: v1
|
||||
kind: ReplicationController
|
||||
metadata:
|
||||
name: nginx
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
app: nginx
|
||||
template:
|
||||
metadata:
|
||||
name: nginx
|
||||
labels:
|
||||
app: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
Loading…
Reference in New Issue