ES localization: replaced {{< codenew ... >}} with {{% codenew ... %}…

…} in all files

content/es/docs/concepts/overview/working-with-objects/kubernetes-objects.md

@@ -39,7 +39,7 @@ Cuando creas un objeto en Kubernetes, debes especificar la spec del objeto que d
 
 Aquí hay un ejemplo de un archivo `.yaml` que muestra los campos requeridos y la spec del objeto Deployment de Kubernetes:
 
-{{< codenew file="application/deployment.yaml" >}}
+{{% codenew file="application/deployment.yaml" %}}
 
 Una forma de crear un Deployment utilizando un archivo `.yaml` como el indicado arriba sería ejecutar el comando
 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)

content/es/docs/concepts/services-networking/network-policies.md

@@ -47,7 +47,7 @@ Ver la referencia [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< p
 
 Un ejemplo de NetworkPolicy pudiera ser este:
 
-{{< codenew file="service/networking/networkpolicy.yaml" >}}
+{{% codenew file="service/networking/networkpolicy.yaml" %}}
 
 {{< 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.
@@ -150,7 +150,7 @@ Por defecto, si no existen políticas en un Namespace, se permite todo el tráfi
 
 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.
 
-{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
+{{% codenew file="service/networking/network-policy-default-deny-ingress.yaml" %}}
 
 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. 
 
@@ -159,7 +159,7 @@ Esto asegura que incluso los Pods que no están seleccionados por ninguna otra N
 
 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.
 
-{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
+{{% codenew file="service/networking/network-policy-allow-all-ingress.yaml" %}}
 
 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.
 
@@ -168,7 +168,7 @@ Con esta política en curso, ninguna política(s) adicional puede hacer que se n
 
 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.
 
-{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
+{{% codenew file="service/networking/network-policy-default-deny-egress.yaml" %}}
 
 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.
 
@@ -177,7 +177,7 @@ Esto asegura que incluso los Pods que no son seleccionados por ninguna otra Netw
 
 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.
 
-{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
+{{% codenew file="service/networking/network-policy-allow-all-egress.yaml" %}}
 
 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.
 
@@ -186,7 +186,7 @@ Con esta política en vigor, ninguna política(s) adicional puede hacer que se n
 
 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.
 
-{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
+{{% codenew file="service/networking/network-policy-default-deny-all.yaml" %}}
 
 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.
 

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

@@ -28,7 +28,7 @@ pero con diferentes parámetros y/o diferentes peticiones de CPU y memoria segú
 
 Un DaemonSet se describe por medio de un archivo YAML. Por ejemplo, el archivo `daemonset.yaml` de abajo describe un DaemonSet que ejecuta la imagen Docker de fluentd-elasticsearch:
 
-{{< codenew file="controllers/daemonset.yaml" >}}
+{{% codenew file="controllers/daemonset.yaml" %}}
 
 * Crear un DaemonSet basado en el archivo YAML:
 ```

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

@@ -44,7 +44,7 @@ A continuación se presentan los casos de uso típicos de los Deployments:
 
 El siguiente ejemplo de un Deployment crea un ReplicaSet para arrancar tres Pods con `nginx`:
 
-{{< codenew file="controllers/nginx-deployment.yaml" >}}
+{{% codenew file="controllers/nginx-deployment.yaml" %}}
 
 En este ejemplo:
 

content/es/docs/concepts/workloads/controllers/garbage-collection.md

@@ -30,7 +30,7 @@ de forma manual indicando el valor del campo `ownerReference`.
 
 Aquí se muestra un archivo de configuración para un ReplicaSet que tiene tres Pods:
 
-{{< codenew file="controllers/replicaset.yaml" >}}
+{{% codenew file="controllers/replicaset.yaml" %}}
 
 Si se crea el ReplicaSet y entonces se muestra los metadatos del Pod, se puede 
 observar el campo OwnerReferences:

content/es/docs/concepts/workloads/controllers/jobs-run-to-completion.md

@@ -31,7 +31,7 @@ También se puede usar un Job para ejecutar múltiples Pods en paralelo.
 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.
 
-{{< codenew file="controllers/job.yaml" >}}
+{{% codenew file="controllers/job.yaml" %}}
 
 Puedes ejecutar el ejemplo con este comando:
 

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

@@ -45,7 +45,7 @@ en vez de ello, usa un Deployment, y define tu aplicación en la sección spec.
 
 ## Ejemplo
 
-{{< codenew file="controllers/frontend.yaml" >}}
+{{% codenew file="controllers/frontend.yaml" %}}
 
 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.
@@ -151,7 +151,7 @@ especificados en su plantilla -- sino que puede adquirir otros Pods como se expl
 
 Toma el ejemplo anterior del ReplicaSet frontend, y los Pods especificados en el siguiente manifiesto:
 
-{{< codenew file="pods/pod-rs.yaml" >}}
+{{% codenew file="pods/pod-rs.yaml" %}}
 
 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.
@@ -308,7 +308,7 @@ Un ReplicaSet puede también ser el blanco de un
 un ReplicaSet puede auto-escalarse mediante un HPA. Aquí se muestra un ejemplo de HPA dirigido
 al ReplicaSet que creamos en el ejemplo anterior.
 
-{{< codenew file="controllers/hpa-rs.yaml" >}}
+{{% codenew file="controllers/hpa-rs.yaml" %}}
 
 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

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

@@ -49,7 +49,7 @@ de un Pod indefinidamente. Un caso de uso más complejo es ejecutar varias répl
 
 Esta configuración de un ReplicationController de ejemplo ejecuta tres copias del servidor web nginx.
 
-{{< codenew file="controllers/replication.yaml" >}}
+{{% codenew file="controllers/replication.yaml" %}}
 
 Ejecuta el ejemplo descargando el archivo de ejemplo y ejecutando este comando:
 

content/es/docs/tasks/configure-pod-container/configure-volume-storage.md

@@ -25,7 +25,7 @@ El sistema de ficheros de un Contenedor existe mientras el Contenedor exista. Po
 
 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:
 
-{{< codenew file="pods/storage/redis.yaml" >}}
+{{% codenew file="pods/storage/redis.yaml" %}}
 
 1. Crea el Pod:
 

content/es/docs/tasks/debug-application-cluster/audit.md

@@ -69,7 +69,7 @@ Un reglamento sin (0) reglas se considera ilegal.
 
 Abajo se presenta un ejemplo de un archivo de reglamento de auditoría:
 
-{{< codenew file="audit/audit-policy.yaml" >}}
+{{% codenew file="audit/audit-policy.yaml" %}}
 
 Puedes usar un archivo mínimo de reglamento de auditoría para registrar todas las peticiones al nivel `Metadata` de la siguiente forma:
 

content/es/docs/tasks/manage-kubernetes-objects/declarative-config.md

@@ -81,7 +81,7 @@ Agregue la opción `-R` para procesar un directorio de manera recursiva.
 
 El siguiente es un ejemplo de archivo de configuración para un objeto:
 
-{{< codenew file="application/simple_deployment.yaml" >}}
+{{% codenew file="application/simple_deployment.yaml" %}}
 
 Ejecute `kubectl diff` para visualizar el objeto que será creado:
 
@@ -175,7 +175,7 @@ Agregue la opción `-R` para procesar directorios de manera recursiva.
 
 Este es un ejemplo de archivo de configuración:
 
-{{< codenew file="application/simple_deployment.yaml" >}}
+{{% codenew file="application/simple_deployment.yaml" %}}
 
 Cree el objeto usando `kubectl apply`:
 
@@ -294,7 +294,7 @@ spec:
 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`:
 
-{{< codenew file="application/update_deployment.yaml" >}}
+{{% codenew file="application/update_deployment.yaml" %}}
 
 Aplique los cambios realizados al archivo de configuración:
 
@@ -450,7 +450,7 @@ son usados para calcular que campos deben ser eliminados o definidos:
 
 A continuación un ejemplo. Suponga que este es el archivo de configuración para un objeto de tipo Deployment:
 
-{{< codenew file="application/update_deployment.yaml" >}}
+{{% codenew file="application/update_deployment.yaml" %}}
 
 También, suponga que esta es la configuración activa para ese mismo objeto de tipo Deployment:
 
@@ -745,7 +745,7 @@ al momento de crear un objeto.
 Aquí puede ver un archivo de configuración para un Deployment. Este archivo no especifica
 el campo `strategy`:
 
-{{< codenew file="application/simple_deployment.yaml" >}}
+{{% codenew file="application/simple_deployment.yaml" %}}
 
 Cree un nuevo objeto `kubectl apply`:
 

content/es/docs/tasks/run-application/run-stateless-application-deployment.md

@@ -36,7 +36,7 @@ weight: 10
 
 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:
 
-{{< codenew file="application/deployment.yaml" >}}
+{{% codenew file="application/deployment.yaml" %}}
 
 
 1. Crea un `deployment` basado en el fichero YAML:
@@ -98,7 +98,7 @@ Puedes correr una aplicación creando un `deployment` de Kubernetes, y puedes de
 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.
 
-{{< codenew file="application/deployment-update.yaml" >}}
+{{% codenew file="application/deployment-update.yaml" %}}
 
 1. Aplica el nuevo fichero YAML:
 
@@ -113,7 +113,7 @@ especifica que el `deployment` debería ser actualizado para usar nginx 1.8.
 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:
 
-{{< codenew file="application/deployment-scale.yaml" >}}
+{{% codenew file="application/deployment-scale.yaml" %}}
 
 1. Aplica el nuevo fichero YAML:
 

content/es/docs/tutorials/hello-minikube.md

@@ -39,9 +39,9 @@ También se puede  seguir este tutorial si se ha instalado [Minikube localmente]
 
 Este tutorial provee una imagen de contenedor construida desde los siguientes archivos:
 
-{{< codenew language="js" file="minikube/server.js" >}}
+{{% codenew language="js" file="minikube/server.js" %}}
 
-{{< codenew language="conf" file="minikube/Dockerfile" >}}
+{{% codenew language="conf" file="minikube/Dockerfile" %}}
 
 Para más información sobre el comando `docker build`, lea la [documentación de Docker ](https://docs.docker.com/engine/reference/commandline/build/).