typos and extra files

Author: jcozain

content/es/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md

@@ -1,14 +1,14 @@
 ---
 title: Actualiza Objetos del API sin reemplazo (in Place) usando kubectl patch 
-description:  Usa kubectl patch para actualizar objetos del API de kubernetes sin reemplazarlos. usa strategic merge patch o JSON merge patch.
+description:  Usa kubectl patch para actualizar objetos del API de kubernetes sin reemplazarlos. Usa strategic merge patch o JSON merge patch.
 content_type: task
 weight: 50
 ---
 
 <!-- overview -->
 
-esta tarea muestra como utilizar `kubectl patch` para actualizar un objeto del API sin reemplazarlo.
-los ejercicios de esta tarea demuestran e uso de "strategic merge patch" y "JSON merge patch"
+Esta tarea muestra cómo utilizar `kubectl patch` para actualizar un objeto del API sin reemplazarlo.
+Los ejercicios de esta tarea demuestran el uso de "strategic merge patch" y "JSON merge patch"
 
 ## {{% heading "prerequisites" %}}
 
@@ -23,7 +23,7 @@ los ejercicios de esta tarea demuestran e uso de "strategic merge patch" y "JSON
 ## Usa strategic merge patch para actualizar un Deployment
 
 Aquí está el archivo de configuración para un Deployment con dos réplicas. 
-cáda réplica es un pod que tiene un contenedor:
+Cada réplica es un pod que tiene un contenedor:
 
 {{% code_sample file="application/deployment-patch.yaml" %}}
 
@@ -38,7 +38,7 @@ Revisa los Pods asociados con tu Deployment:
 ```shell
 kubectl get pods
 ```
-El resultado muestra que el Deployment tiene dos Pods. el `1/1` indica
+El resultado muestra que el Deployment tiene dos Pods. El `1/1` indica
 que cada Pod tiene un contenedor:
 
 
@@ -48,10 +48,10 @@ patch-demo-28633765-670qr   1/1       Running   0          23s
 patch-demo-28633765-j5qs3   1/1       Running   0          23s
 ```
 
-Toma nota de los nombres de los Pods que se están ejecutando. Verás que estos pods son 
+Toma nota de los nombres de los Pods que se están ejecutando. Verás que estos Pods son 
 terminados y reemplazados posteriormente.
 
-En este punto cada Pod tiene un contenedor que ejecuta una imágen de nginx. Ahora
+En este punto cada Pod tiene un contenedor que ejecuta una imagen de nginx. Ahora
 supón que quieres que cada pod tenga dos contenedores: uno que ejecute nginx 
 y otro que ejecute redis.
 
@@ -78,7 +78,7 @@ Revisa el Deployment modificado:
 kubectl get deployment patch-demo --output yaml
 ```
 
-el resultado muestra que el PodSpec del Deployment tiene dos contenedores:
+El resultado muestra que el PodSpec del Deployment tiene dos contenedores:
 
 ```yaml
 containers:
@@ -100,7 +100,7 @@ kubectl get pods
 
 El resultado muestra que los Pods tienen un nombre distinto a los que se estaban
 ejecutando anteriormente. El Deployment terminó los Pods viejos y creo dos nuevos
-que cumplen con la especificación actualizada del Deployment. el `2/2` indica que
+que cumplen con la especificación actualizada del Deployment. El `2/2` indica que
 cada Pod tiene dos contenedores:
 
 ```
@@ -109,13 +109,13 @@ patch-demo-1081991389-2wrn5   2/2       Running   0          1m
 patch-demo-1081991389-jmg7b   2/2       Running   0          1m
 ```
 
-Un vistazo mas de cerca a uno de los Pods del patch-demo:
+Un vistazo más de cerca a uno de los Pods del patch-demo:
 
 ```shell
 kubectl get pod <your-pod-name> --output yaml
 ```
 
-El resultado muestra que los pods tienen dos contenedores: uno ejecutando nginx y otro redis:
+El resultado muestra que el Pod tienen dos contenedores: uno ejecutando nginx y otro redis:
 
 ```
 containers:
@@ -128,14 +128,14 @@ containers:
 ### Notas acerca de strategic merge patch
 
 El patch que hiciste en el ejercicio anterior se llama *strategic merge patch*.
-Toma en cuenta que el path no reemplazó la lista `containers`. si no que agregó
+Toma en cuenta que el path no reemplazó la lista `containers`. Sino que agregó
 un contenedor nuevo a la lista. En otras palabras, la lista en el patch fue agregada
 a la lista ya existente. Esto no es lo que pasa siempre que se utiliza strategic merge patch
-en una lista. en algunos casos la lista existente podría ser reemplazada en lugar de unir ambas.
+en una lista. En algunos casos la lista existente podría ser reemplazada en lugar de unir ambas.
 
 Con strategic merge patch, la lista existente puede ser reemplazada o unida con la nueva
 dependiendo de la estrategia de patch. La estrategia de patch se especifica en el valor del key
-`patchStrategy`en un field tag del código fuente de Kubernetes. por ejemplo el 
+`patchStrategy`en un field tag del código fuente de Kubernetes. Por ejemplo el 
 campo `Containers` de la struct `PodSpec` tiene un valor de `merge` en su key `patchStrategy`:
 
 ```go
@@ -145,7 +145,7 @@ type PodSpec struct {
   ...
 }
 ```
-También se puede consultar la estrategia de patch en 
+También puedes consultar la estrategia de patch en 
 [OpenApi spec](https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json):
 
 ```yaml
@@ -160,7 +160,7 @@ También se puede consultar la estrategia de patch en
 ```
 <!-- for editors: intentionally use yaml instead of json here, to prevent syntax highlight error. -->
 
-Y se puede conlsultar la estrategia de patch en la 
+Y puedes conlsultar la estrategia de patch en la 
 [Documentación del API Kubernetes](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core).
 
 Crea un archivo llamado `patch-file-tolerations.yaml` que tenga el siguiente contenido:
@@ -196,7 +196,7 @@ tolerations:
 ```
 
 Toma en cuenta que la lista de `tolerations` en el PodSpec fue reemplazada, no unida.
-esto es por que el campo de Tolerations del PodSpec no tiene un key `patchStrategy` en su field tag.
+Esto es porque el campo de Tolerations del PodSpec no tiene un key `patchStrategy` en su field tag.
 por lo tanto strategic merge patch utiliza la estrategia de patch de default, la cual es `replace`.
 
 ```go
@@ -216,7 +216,7 @@ Con JSON merge patch, si quieres actualizar una lista
 tienes que especificar la lista nueva en su totalidad
 y reemplazar la lista existente con la lista nueva.
 
-el comando `kubectl patch` tiene un parámetro `type` que acepta los siguientes valores:
+El comando `kubectl patch` tiene un parámetro `type` que acepta los siguientes valores:
 
 <table>
   <tr><th>Valor del parámetro</th><th>tipo de unión</th></tr>
@@ -228,10 +228,10 @@ el comando `kubectl patch` tiene un parámetro `type` que acepta los siguientes
 Para una comparación entre JSON patch y JSON merge patch, revisa
 [JSON Patch y JSON Merge Patch](https://erosb.github.io/post/json-patch-vs-merge-patch/).
 
-El valor predeterminado para el vparametro `type` es  `strategic`. entonces en el ejercicio
+El valor predeterminado para el parametro `type` es  `strategic`. Entonces en el ejercicio
 anterior hiciste un strategic merge patch.
 
-A continuación has un JSON merge path en el mismo Deployment. crea un archivo llamado
+A continuación haz un JSON merge path en el mismo Deployment. Crea un archivo llamado
 `patch-file-2.yaml` que tenga el siguiente contenido:
 
 ```yaml
@@ -243,7 +243,7 @@ spec:
         image: gcr.io/google-samples/node-hello:1.0
 ```
 
-en el comando patch configura el valor de `type` como `merge`
+En el comando patch configura el valor de `type` como `merge`
 
 ```shell
 kubectl patch deployment patch-demo --type merge --patch-file patch-file-2.yaml
@@ -255,8 +255,8 @@ Revisa el Deployment modificado:
 kubectl get deployment patch-demo --output yaml
 ```
 
-la lista `containers` que especificaste en el patch solo tiene un contenedor.
-el resultado muestra que tu lista con un contenedor reemplazo a la lista `containers` preexistente.
+La lista `containers` que especificaste en el patch solo tiene un contenedor.
+el resultado muestra que tu lista con un contenedor reemplazó a la lista `containers` preexistente.
 
 ```yaml
 spec:
@@ -265,14 +265,14 @@ spec:
     ...
     name: patch-demo-ctr-3
 ```
-revisa los Pods en ejecución:
+Revisa los Pods en ejecución:
 
 ```shell
 kubectl get pods
 ```
 
-En el resultado se puede ver que los Pods existentes fueron temrinados y se
-crearon Pods nuevos. el `1/1` indica que cada Pod nuevo esta ejecutando un solo
+En el resultado se puede ver que los Pods existentes fueron terminados y se
+crearon Pods nuevos. El `1/1` indica que cada Pod nuevo esta ejecutando un solo
 contenedor.
 
 ```shell
@@ -283,17 +283,17 @@ patch-demo-1307768864-c86dc   1/1       Running   0          1m
 
 ## Usa strategic merge patch para actualizar un Deployment utilizando la estrategia retainKeys  
 
-Aquí esta el archivo de configuración para un deployment que usa la estrategia `RollingUpdate`:
+Aquí esta el archivo de configuración para un Deployment que usa la estrategia `RollingUpdate`:
 
 {{% code_sample file="application/deployment-retainkeys.yaml" %}}
 
-Crea el deployment:
+Crea el Deployment:
 
 ```shell
 kubectl apply -f https://k8s.io/examples/application/deployment-retainkeys.yaml
 ```
 
-En este punto, el deployment es creado y está usando la estrategia `RollingUpdate`.
+En este punto, el Deployment es creado y está usando la estrategia `RollingUpdate`.
 
 Crea un archivo llamado `patch-file-no-retainkeys.yaml` con el siguiente contenido:
 
@@ -315,9 +315,9 @@ En el resultado se puede ver que no es posible definir el `type` como `Recreate`
 The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate'
 ```
 
-La forma para quitar el value para `spec.strategy.rollingUpdate` al momento de cambiar el valor `type` es usar la estrategia `retainKeys` para el stragegic merge.
+La forma para quitar el value para `spec.strategy.rollingUpdate` al momento de cambiar el valor `type` es usar la estrategia `retainKeys` para el strategic merge.
 
-Crea otro archivo llamaod `patch-file-retainkeys.yaml` con el siguiente contenido:
+Crea otro archivo llamado `patch-file-retainkeys.yaml` con el siguiente contenido:
 
 ```yaml
 spec:
@@ -327,7 +327,7 @@ spec:
     type: Recreate
 ```
 
-Con este Patch definimos que solo queremos conservar el key `type` del objeto `strategy`. por lo tanto la llave `rollingUpdate` será eliminado durante la operación de modificación.
+Con este Patch definimos que solo queremos conservar el key `type` del objeto `strategy`. Por lo tanto la llave `rollingUpdate` será eliminada durante la operación de modificación.
 
 Modifica tu Deployment de nuevo con este nuevo Patch:
 
@@ -339,28 +339,27 @@ Revisa el contenido del Deployment:
 ```shell
 kubectl get deployment retainkeys-demo --output yaml
 ```
-El resultado muestra que el objeto `strategy` en el Deployment ya no contiene la llave `rollingUpdate`
-The output shows that the strategy object in the Deployment does not contain the `rollingUpdate` key anymore:
+El resultado muestra que el objeto `strategy` en el Deployment ya no contiene la llave `rollingUpdate`:
 
 ```yaml
 spec:
   strategy:
     type: Recreate
   template:
 ```
-### Notas a cerca de strategic merge patch utilizando la estrategia retainKeys
+### Notas acerca de strategic merge patch utilizando la estrategia retainKeys
 
-La modificación realizada en el ejercicio anterior tiene el nombre de *strategic merge patch con estrategia retainKeys*. este metodo introduce una
+La modificación realizada en el ejercicio anterior tiene el nombre de *strategic merge patch con estrategia retainKeys*. Este método introduce una
 nueva directiva `$retainKeys` que tiene las siguientes estrategias:
 
-- contiene una lista de strings.
+- Contiene una lista de strings.
 - Todos los campos que necesiten ser preservados deben estar presentes en la lista `$retainKeys`.
-- Todos los campos que estén presentes serán convinados con el objeto existente.
+- Todos los campos que estén presentes serán combinados con el objeto existente.
 - Todos los campos faltantes serán removidos o vaciados al momento de la modificación.
-- todos los campos en la lista `$retainKeys` deberan ser un superconjunto o idéntico a los campos presentes en el Patch.
+- Todos los campos en la lista `$retainKeys` deberán ser un superconjunto o idéntico a los campos presentes en el Patch.
 
-La estrategia `retainKeys` no funciona para todos los objetos. solo funciona cuando el valor de la key `patchStrategy`en el field tag de el código fuente de 
-kubernetes contenga `retainKeys`. Por ejemplo, el campo `Strategy` del struct `DeploymentSpec` tiene un valor de `retainKeys` en tu tag `patchStrategy`
+La estrategia `retainKeys` no funciona para todos los objetos. Solo funciona cuando el valor de la key `patchStrategy`en el field tag de el código fuente de 
+Kubernetes contenga `retainKeys`. Por ejemplo, el campo `Strategy` del struct `DeploymentSpec` tiene un valor de `retainKeys` en tu tag `patchStrategy`
 
 
 ```go
@@ -386,11 +385,11 @@ También puedes revisar la estrategia `retainKeys` en la especificación de [Ope
 ```
 <!-- para los editiores: intencionalmente se utilizó yaml en lugar de json para evitar errores de resaltado por sintaxis. -->
 
-A demás de revisar la estrategia `retainKeys` en la [documentación del API de k8s](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
+Además puedes revisar la estrategia `retainKeys` en la [documentación del API de k8s](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps).
 
 ### Formas alternativas del comando kubectl patch
 
-el comando `kubectl patch` toma como entrada un archivo en formato YAML o JSON desde el filesystem o la linea de comandos.
+El comando `kubectl patch` toma como entrada un archivo en formato YAML o JSON desde el filesystem o la línea de comandos.
 
 Crea un archivo llamado `patch-file.json` que contenga lo siguiente:
 
@@ -411,7 +410,7 @@ Crea un archivo llamado `patch-file.json` que contenga lo siguiente:
 }
 ```
 
-los siguientes comandos son equivalentes:
+Los siguientes comandos son equivalentes:
 
 
 ```shell
@@ -428,7 +427,7 @@ kubectl patch deployment patch-demo --patch '{"spec": {"template": {"spec": {"co
 
 La bandera `--subresource=[subresource-name]` es utilizada con comandos de kubectl como get,
 patch y replace para obtener y actualizar los subrecursos `status` y `scale` de los recursos 
-(aplicable para las versiones de kubectl de v1.24 en adelante). esta bandera se utiliza con
+(aplicable para las versiones de kubectl de v1.24 en adelante). Esta bandera se utiliza con
 todos los recursos del API (incluidos en k8s o CRs) que tengan los subrecursos `status` or `scale`.
 Deployment es un ejemplo de un objeto con estos subrecursos.
 
@@ -474,7 +473,7 @@ Revisa los Pods asociados al Deployment modificado:
 kubectl get pods -l app=nginx
 ```
 
-en el resultado se puede apreciar que se ha creado un pod nuevo. ahora tienes 3 Pods en ejecución.
+En el resultado se puede apreciar que se ha creado un Pod nuevo. Ahora tienes 3 Pods en ejecución.
 
 ```
 NAME                                READY   STATUS    RESTARTS   AGE
@@ -503,13 +502,13 @@ status:
 
 {{< note >}}
 Si ejecutas `kubectl patch` y especificas la bandera `--subresource` para un recurso que no soporte
-un subrecurso en particular, el servidor del api regresará un error 404 Not found.
+un subrecurso en particular, el servidor del API regresará un error 404 Not Found.
 {{< /note >}}
 
 ## Resumen
 
 En este ejercicio utilizaste `kubectl patch` para cambiar la configuración en ejecución de 
-un objeto de tipo deployment. No hubo cambios al archivo de configuración que se utilizó 
+un objeto de tipo Deployment. No hubo cambios al archivo de configuración que se utilizó 
 originalmente para crear el Deployment. Otros comandos utilizados para actualizar objetos del API 
 incluyen:
 [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands/#annotate),

content/es/examples/application/deployment-patch.yaml

@@ -0,0 +1,21 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: patch-demo
+spec:
+  replicas: 2
+  selector:
+    matchLabels:
+      app: nginx
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: patch-demo-ctr
+        image: nginx
+      tolerations:
+      - effect: NoSchedule
+        key: dedicated
+        value: test-team

content/es/examples/application/deployment-retainkeys.yaml

@@ -0,0 +1,19 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: retainkeys-demo
+spec:
+  selector:
+    matchLabels:
+      app: nginx
+  strategy:
+    rollingUpdate:
+      maxSurge: 30%
+  template:
+    metadata:
+      labels:
+        app: nginx
+    spec:
+      containers:
+      - name: retainkeys-demo-ctr
+        image: nginx