Aquí hay un ejemplo de un archivo `.yaml` que muestra los campos requeridos y la spec del objeto Deployment de Kubernetes:

Una forma de crear un Deployment utilizando un archivo `.yaml` como el indicado arriba sería ejecutar el comando

Un ejemplo de NetworkPolicy pudiera ser este:

{{< note >}}

Enviar esto al API Server de su clúster no tendrá ningún efecto a menos que su solución de red soporte de políticas de red.

Puedes crear una política que "por defecto" aisle a un Namespace del tráfico de entrada con la creación de una política que seleccione todos los Pods del Namespace pero no permite ningún tráfico de entrada en esos Pods.

Esto asegura que incluso los Pods que no están seleccionados por ninguna otra NetworkPolicy también serán aislados del tráfico de entrada. Esta política no afecta el aislamiento en el tráfico de salida desde cualquier Pod.

Si tu quieres permitir todo el tráfico de entrada a todos los Pods en un Namespace, puedes crear una política que explícitamente permita eso.

Con esta política en curso, ninguna política(s) adicional puede hacer que se niegue cualquier conexión entrante a esos Pods. Esta política no tiene efecto sobre el aislamiento del tráfico de salida de cualquier Pod.

Puedes crear una política que "por defecto" aisle el tráfico de salida para un Namespace, creando una NetworkPolicy que seleccione todos los Pods pero que no permita ningún tráfico de salida desde esos Pods.

Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tengan permitido el tráfico de salida. Esta política no cambia el comportamiento de aislamiento para el tráfico de entrada de ningún Pod.

Si quieres permitir todas las conexiones desde todos los Pods de un Namespace, puedes crear una política que permita explícitamente todas las conexiones salientes de los Pods de ese Namespace.

Con esta política en vigor, ninguna política(s) adicional puede hacer que se niegue cualquier conexión de salida desde esos Pods. Esta política no tiene efecto sobre el aislamiento para el tráfico de entrada a cualquier Pod.

Puede crear una política que "por defecto" en un Namespace impida todo el tráfico de entrada y de salida creando la siguiente NetworkPolicy en ese Namespace.

Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tendrán permitido el tráfico de entrada o salida.

Un DaemonSet se describe por medio de un archivo YAML. Por ejemplo, el archivo `daemonset.yaml` de abajo describe un DaemonSet que ejecuta la imagen Docker de fluentd-elasticsearch:

* Crear un DaemonSet basado en el archivo YAML:

El siguiente ejemplo de un Deployment crea un ReplicaSet para arrancar tres Pods con `nginx`:

En este ejemplo:

Aquí se muestra un archivo de configuración para un ReplicaSet que tiene tres Pods:

Si se crea el ReplicaSet y entonces se muestra los metadatos del Pod, se puede

observar el campo OwnerReferences:

Aquí se muestra un ejemplo de configuración de Job. Este ejemplo calcula los primeros 2000 decimales de π y los imprime por pantalla.

Tarda unos 10s en completarse.

Puedes ejecutar el ejemplo con este comando:

Si guardas este manifiesto en un archivo llamado `frontend.yaml` y lo lanzas en un clúster de Kubernetes,

se creará el ReplicaSet definido y los Pods que maneja.

Toma el ejemplo anterior del ReplicaSet frontend, y los Pods especificados en el siguiente manifiesto:

Como estos Pods no tienen un Controlador (o cualquier otro objeto) como referencia de propietario

y como además su selector coincide con el del ReplicaSet frontend, este último los terminará adquiriendo de forma inmediata.

un ReplicaSet puede auto-escalarse mediante un HPA. Aquí se muestra un ejemplo de HPA dirigido

al ReplicaSet que creamos en el ejemplo anterior.

Si guardas este manifiesto en un archivo `hpa-rs.yaml` y lo lanzas contra el clúster de Kubernetes,

debería crear el HPA definido que auto-escala el ReplicaSet destino dependiendo del uso

Esta configuración de un ReplicationController de ejemplo ejecuta tres copias del servidor web nginx.

Ejecuta el ejemplo descargando el archivo de ejemplo y ejecutando este comando:

En este ejercicio crearás un Pod que ejecuta un único Contenedor. Este Pod tiene un Volume de tipo [emptyDir](/docs/concepts/storage/volumes/#emptydir) (directorio vacío) que existe durante todo el ciclo de vida del Pod, incluso cuando el Contenedor es destruido y reiniciado. Aquí está el fichero de configuración del Pod:

1. Crea el Pod:

Abajo se presenta un ejemplo de un archivo de reglamento de auditoría:

Puedes usar un archivo mínimo de reglamento de auditoría para registrar todas las peticiones al nivel `Metadata` de la siguiente forma:

El siguiente es un ejemplo de archivo de configuración para un objeto:

Ejecute `kubectl diff` para visualizar el objeto que será creado:

Este es un ejemplo de archivo de configuración:

Cree el objeto usando `kubectl apply`:

Actualice el archivo de configuración `simple_deployment.yaml` para cambiar el campo `image`

de `nginx:1.14.2` a `nginx:1.16.1`, y elimine el campo `minReadySeconds`:

Aplique los cambios realizados al archivo de configuración:

A continuación un ejemplo. Suponga que este es el archivo de configuración para un objeto de tipo Deployment:

También, suponga que esta es la configuración activa para ese mismo objeto de tipo Deployment:

el campo `strategy`:

Cree un nuevo objeto `kubectl apply`:

Puedes correr una aplicación creando un `deployment` de Kubernetes, y puedes describir el `deployment` en un fichero YAML. Por ejemplo, el siguiente fichero YAML describe un `deployment` que corre la imágen Docker nginx:1.7.9:

1. Crea un `deployment` basado en el fichero YAML:

Puedes actualizar el `deployment` aplicando un nuevo fichero YAML. El siguiente fichero YAML

especifica que el `deployment` debería ser actualizado para usar nginx 1.8.

1. Aplica el nuevo fichero YAML:

Puedes aumentar el número de pods en tu `deployment` aplicando un nuevo fichero YAML.

El siguiente fichero YAML especifica un total de 4 `replicas`, lo que significa que el `deployment` debería tener cuatro pods:

1. Aplica el nuevo fichero YAML:

Este tutorial provee una imagen de contenedor construida desde los siguientes archivos:

Para más información sobre el comando `docker build`, lea la [documentación de Docker ](https://docs.docker.com/engine/reference/commandline/build/).