Skip to content

Commit e01dc1d

Browse files
committed
ES localization: replaced {{< codenew ... >}} with {{% codenew ... %}} in all files
1 parent ff6d646 commit e01dc1d

File tree

13 files changed

+27
-27
lines changed

13 files changed

+27
-27
lines changed

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -39,7 +39,7 @@ Cuando creas un objeto en Kubernetes, debes especificar la spec del objeto que d
3939

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

42-
{{< codenew file="application/deployment.yaml" >}}
42+
{{% codenew file="application/deployment.yaml" %}}
4343

4444
Una forma de crear un Deployment utilizando un archivo `.yaml` como el indicado arriba sería ejecutar el comando
4545
[`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply)

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

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -47,7 +47,7 @@ Ver la referencia [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< p
4747

4848
Un ejemplo de NetworkPolicy pudiera ser este:
4949

50-
{{< codenew file="service/networking/networkpolicy.yaml" >}}
50+
{{% codenew file="service/networking/networkpolicy.yaml" %}}
5151

5252
{{< note >}}
5353
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
150150

151151
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.
152152

153-
{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}}
153+
{{% codenew file="service/networking/network-policy-default-deny-ingress.yaml" %}}
154154

155155
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.
156156

@@ -159,7 +159,7 @@ Esto asegura que incluso los Pods que no están seleccionados por ninguna otra N
159159

160160
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.
161161

162-
{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}}
162+
{{% codenew file="service/networking/network-policy-allow-all-ingress.yaml" %}}
163163

164164
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.
165165

@@ -168,7 +168,7 @@ Con esta política en curso, ninguna política(s) adicional puede hacer que se n
168168

169169
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.
170170

171-
{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}}
171+
{{% codenew file="service/networking/network-policy-default-deny-egress.yaml" %}}
172172

173173
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.
174174

@@ -177,7 +177,7 @@ Esto asegura que incluso los Pods que no son seleccionados por ninguna otra Netw
177177

178178
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.
179179

180-
{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}}
180+
{{% codenew file="service/networking/network-policy-allow-all-egress.yaml" %}}
181181

182182
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.
183183

@@ -186,7 +186,7 @@ Con esta política en vigor, ninguna política(s) adicional puede hacer que se n
186186

187187
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.
188188

189-
{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}}
189+
{{% codenew file="service/networking/network-policy-default-deny-all.yaml" %}}
190190

191191
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.
192192

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ pero con diferentes parámetros y/o diferentes peticiones de CPU y memoria segú
2828

2929
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:
3030

31-
{{< codenew file="controllers/daemonset.yaml" >}}
31+
{{% codenew file="controllers/daemonset.yaml" %}}
3232

3333
* Crear un DaemonSet basado en el archivo YAML:
3434
```

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -44,7 +44,7 @@ A continuación se presentan los casos de uso típicos de los Deployments:
4444

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

47-
{{< codenew file="controllers/nginx-deployment.yaml" >}}
47+
{{% codenew file="controllers/nginx-deployment.yaml" %}}
4848

4949
En este ejemplo:
5050

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -30,7 +30,7 @@ de forma manual indicando el valor del campo `ownerReference`.
3030

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

33-
{{< codenew file="controllers/replicaset.yaml" >}}
33+
{{% codenew file="controllers/replicaset.yaml" %}}
3434

3535
Si se crea el ReplicaSet y entonces se muestra los metadatos del Pod, se puede
3636
observar el campo OwnerReferences:

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -31,7 +31,7 @@ También se puede usar un Job para ejecutar múltiples Pods en paralelo.
3131
Aquí se muestra un ejemplo de configuración de Job. Este ejemplo calcula los primeros 2000 decimales de π y los imprime por pantalla.
3232
Tarda unos 10s en completarse.
3333

34-
{{< codenew file="controllers/job.yaml" >}}
34+
{{% codenew file="controllers/job.yaml" %}}
3535

3636
Puedes ejecutar el ejemplo con este comando:
3737

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

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -45,7 +45,7 @@ en vez de ello, usa un Deployment, y define tu aplicación en la sección spec.
4545

4646
## Ejemplo
4747

48-
{{< codenew file="controllers/frontend.yaml" >}}
48+
{{% codenew file="controllers/frontend.yaml" %}}
4949

5050
Si guardas este manifiesto en un archivo llamado `frontend.yaml` y lo lanzas en un clúster de Kubernetes,
5151
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
151151

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

154-
{{< codenew file="pods/pod-rs.yaml" >}}
154+
{{% codenew file="pods/pod-rs.yaml" %}}
155155

156156
Como estos Pods no tienen un Controlador (o cualquier otro objeto) como referencia de propietario
157157
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
308308
un ReplicaSet puede auto-escalarse mediante un HPA. Aquí se muestra un ejemplo de HPA dirigido
309309
al ReplicaSet que creamos en el ejemplo anterior.
310310

311-
{{< codenew file="controllers/hpa-rs.yaml" >}}
311+
{{% codenew file="controllers/hpa-rs.yaml" %}}
312312

313313
Si guardas este manifiesto en un archivo `hpa-rs.yaml` y lo lanzas contra el clúster de Kubernetes,
314314
debería crear el HPA definido que auto-escala el ReplicaSet destino dependiendo del uso

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -49,7 +49,7 @@ de un Pod indefinidamente. Un caso de uso más complejo es ejecutar varias répl
4949

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

52-
{{< codenew file="controllers/replication.yaml" >}}
52+
{{% codenew file="controllers/replication.yaml" %}}
5353

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

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ El sistema de ficheros de un Contenedor existe mientras el Contenedor exista. Po
2525

2626
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:
2727

28-
{{< codenew file="pods/storage/redis.yaml" >}}
28+
{{% codenew file="pods/storage/redis.yaml" %}}
2929

3030
1. Crea el Pod:
3131

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

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -69,7 +69,7 @@ Un reglamento sin (0) reglas se considera ilegal.
6969

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

72-
{{< codenew file="audit/audit-policy.yaml" >}}
72+
{{% codenew file="audit/audit-policy.yaml" %}}
7373

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

0 commit comments

Comments
 (0)