typos and extra files
This commit is contained in:
jesus
parent
0739fff9c1
commit
f30e82fe33
|
|
@ -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,8 +339,7 @@ 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:
|
||||
|
|
@ -348,19 +347,19 @@ spec:
|
|||
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),
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
Loading…
Reference in New Issue