Insertar proxies de sidecar con Cloud Service Mesh

En este documento se explica cómo configurar la inyección de proxy sidecar con Cloud Service Mesh para mejorar la seguridad, la fiabilidad y la observabilidad de la red. Estas funciones se abstraen del contenedor principal de la aplicación y se implementan en un proxy común fuera del proceso (el sidecar), que se entrega como un contenedor independiente en el mismo pod. De esta forma, puedes usar las funciones de Cloud Service Mesh sin tener que rediseñar tus aplicaciones de producción para que participen en una malla de servicios.

La inyección automática de proxy sidecar se produce cuando Cloud Service Mesh detecta una etiqueta de espacio de nombres que has configurado para el pod de la carga de trabajo. El proxy intercepta todo el tráfico entrante y saliente de las cargas de trabajo y se comunica con Cloud Service Mesh.

Permisos necesarios para estas tareas

Para realizar las tareas de esta página, debes tener el rol de roles/container.clusterAdmin o uno superior. Consulta los roles de Google Kubernetes Engine para obtener más información sobre los permisos incluidos en este rol.

Habilitar la inyección automática de sidecars

La forma recomendada de insertar proxies sidecar es usar el inyector automático de sidecar basado en webhooks, aunque puedes actualizar manualmente la configuración de Kubernetes de tus pods.

Para habilitar la inyección automática, debe etiquetar sus espacios de nombres con las etiquetas de inyección predeterminadas si la etiqueta predeterminada está configurada, o con la etiqueta de revisión de su espacio de nombres. La etiqueta que añadas también depende de si has implementado Cloud Service Mesh gestionado (con la API Fleet o con asmcli) o si has instalado el plano de control en el clúster. El webhook del inyector de sidecar usa la etiqueta para asociar los sidecars inyectados con una revisión concreta del plano de control.

Para habilitar la inyección automática, sigue estos pasos:

En el clúster

Usa el siguiente comando para localizar la etiqueta de revisión en istiod:

kubectl -n istio-system get pods -l app=istiod --show-labels

El resultado es similar al siguiente:

NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1264-1-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1264-1,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1264-1-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1264-1,istio=istiod,pod-template-hash=5788d57586

En el resultado, en la columna LABELS, anote el valor de la etiqueta de revisión istiod que sigue al prefijo istio.io/rev=. En este ejemplo, el valor es asm-1264-1.

Nota: Puedes sustituir istio.io/rev por la etiqueta istio-injection=enabled si la etiqueta predeterminada está configurada. Verifica que la etiqueta predeterminada existe ejecutando istioctl tag list con el istioctl de OUTPUT_DIR.

Aplica la etiqueta de revisión a los espacios de nombres y elimina la etiqueta istio-injection (si existe). En el siguiente comando, NAMESPACE es el nombre del espacio de nombres en el que quieres habilitar la inyección automática y REVISION es la etiqueta de revisión que has anotado en el paso anterior.
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
Puedes ignorar el mensaje "istio-injection not found" en la salida. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection, que debería aparecer en las nuevas instalaciones o implementaciones de Cloud Service Mesh. Como el comportamiento de la inyección automática no está definido cuando un espacio de nombres tiene tanto la etiqueta istio-injection como la de revisión, todos los comandos kubectl label de la documentación de Cloud Service Mesh se aseguran explícitamente de que solo se defina una.
Reinicia los pods afectados siguiendo los pasos de la siguiente sección.

Malla de servicios gestionada

Usa el siguiente comando para localizar los canales de lanzamiento disponibles:
```
kubectl -n istio-system get controlplanerevision
```
El resultado debería ser similar al siguiente:
```
NAME                AGE
asm-managed         6d7h
```
En el resultado, seleccione el valor de la columna NAME. Se trata de la etiqueta REVISION que corresponde al canal de lanzamiento disponible de la versión de Cloud Service Mesh. Aplica esta etiqueta a tus espacios de nombres y quita la etiqueta istio-injection (si existe). En el siguiente comando, sustituye REVISION por la etiqueta de revisión que has anotado más arriba y NAMESPACE por el nombre del espacio de nombres en el que quieras habilitar la inyección automática:
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
Puedes ignorar el mensaje "istio-injection not found" en la salida. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection, que debería aparecer en las nuevas instalaciones o implementaciones de Cloud Service Mesh. Como el comportamiento de la inyección automática no está definido cuando un espacio de nombres tiene tanto la etiqueta istio-injection como la de revisión, todos los comandos kubectl label de la documentación de Cloud Service Mesh se aseguran explícitamente de que solo se defina una.
Reinicia los pods afectados siguiendo los pasos de la siguiente sección.
Si también has implementado el plano de datos gestionado por Google opcional, anota el espacio de nombres demo de la siguiente manera:
```
kubectl annotate --overwrite namespace YOUR_NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'
```

Reiniciar los pods para actualizar los proxies adicionales

Con la inserción automática de sidecars, puedes actualizar los sidecars de los pods que ya tengas reiniciando los pods:

La forma de reiniciar los pods depende de si se han creado como parte de una implementación.

Si has usado un Deployment, reinícialo para que se reinicien todos los pods con sidecars:
```
kubectl rollout restart deployment -n YOUR_NAMESPACE
```
Si no has usado un Deployment, elimina los pods y se volverán a crear automáticamente con sidecars:
```
kubectl delete pod -n YOUR_NAMESPACE --all
```
Comprueba que todos los pods del espacio de nombres tengan sidecars insertados:
```
kubectl get pod -n YOUR_NAMESPACE
```
En el siguiente ejemplo de salida del comando anterior, observe que la columna READY indica que hay dos contenedores para cada una de sus cargas de trabajo: el contenedor principal y el contenedor del proxy sidecar.
```
NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...
```

Siguientes pasos

Consulta más información sobre lo siguiente: