Cómo insertar proxies de sidecar con Cloud Service Mesh

En este documento, se explica cómo configurar la inserción del proxy de sidecar con Cloud Service Mesh para mejorar la seguridad, la confiabilidad y la observabilidad de la red. Estas funciones se abstraen del contenedor principal de la aplicación y se implementan en un proxy fuera del proceso común (el archivo adicional), que se entrega como un contenedor por separado en el mismo Pod. Esto proporciona las funciones de Cloud Service Mesh sin rediseñar las aplicaciones de producción para participar en una malla de servicios.

La inserción automática del proxy de sidecar (la inserción automática) ocurre cuando Cloud Service Mesh detecta una etiqueta de espacio de nombres que se configura para el Pod de la carga de trabajo. El proxy intercepta todo el tráfico de entrada y de salida 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 la función roles/container.clusterAdmin o una superior. Consulta las funciones de Google Kubernetes Engine para obtener detalles sobre los permisos incluidos en esta función.

Habilita la inserción automática de sidecar

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

Para habilitar la inserción automática, etiqueta tus espacios de nombres con las etiquetas de inyección predeterminadas si la etiqueta predeterminada está configurada o con la etiqueta de revisión en tu espacio de nombres. La etiqueta que agregues también depende de si implementaste Cloud Service Mesh administrado (con la API de Fleet o con asmcli) o si instalaste el plano de control en el clúster. El webhook de inyector de sidecar usa la etiqueta para asociar los sidecars insertados con una revisión de plano de control en particular.

Para habilitarla, usa este comando:

En el clúster

Usa el siguiente comando para encontrar 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-1233-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1233-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1233-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1233-2,istio=istiod,pod-template-hash=5788d57586

En el resultado, en la columna LABELS, observa el valor de la etiqueta de revisión istiod, que está después del prefijo istio.io/rev=. En este ejemplo, el valor es asm-1233-2.

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

Aplica la etiqueta de revisión a los espacios de nombres y quita la etiqueta istio-injection (si existe). En el siguiente comando, NAMESPACE es el nombre del espacio de nombres en el que deseas habilitar la inserción automática y REVISION es la etiqueta de revisión que anotaste en el paso anterior.
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
Puedes ignorar el mensaje "istio-injection not found" en el resultado. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection, que debería aparecer en las nuevas instalaciones de Cloud Service Mesh o en implementaciones nuevas. Debido a que el comportamiento de la inserción automática no está definido cuando un espacio de nombres tiene tanto la istio-injection como la etiqueta de revisión, todos los comandos kubectl label de la documentación de Cloud Service Mesh se aseguran de forma explícita de que solo se establezca uno.
Para reiniciar los Pods afectados, sigue los pasos de la siguiente sección.

Malla de servicios administrados

Usa el siguiente comando para ubicar los canales de versiones disponibles:
```
kubectl -n istio-system get controlplanerevision
```
El resultado es similar a este:
```
NAME                AGE
asm-managed         6d7h
```
En el resultado, selecciona el valor en la columna NAME es la etiqueta de REVISION que corresponde al canal de versiones disponible para la versión de Cloud Service Mesh. Aplica esta etiqueta a los espacios de nombres y quita la etiqueta istio-injection (si existe). En el siguiente comando, reemplaza REVISION por la etiqueta de revisión que anotaste antes y reemplaza NAMESPACE por el nombre del espacio de nombres en el que deseas habilitar la inserción automática:
```
kubectl label namespace NAMESPACE  istio-injection- istio.io/rev=REVISION --overwrite
```
Puedes ignorar el mensaje "istio-injection not found" en el resultado. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection, que debería aparecer en las nuevas instalaciones de Cloud Service Mesh o en implementaciones nuevas. Debido a que el comportamiento de la inserción automática no está definido cuando un espacio de nombres tiene tanto la istio-injection como la etiqueta de revisión, todos los comandos kubectl label de la documentación de Cloud Service Mesh se aseguran de forma explícita de que solo se establezca uno.
Para reiniciar los Pods afectados, sigue los pasos de la siguiente sección.
Si también implementaste el plano de datos administrado 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"}'
```

Reinicia los Pods para actualizar los proxies de sidecar

Con la inserción automática de sidecar, puedes actualizar los sidecars para pods existentes con un reinicio de pods:

La forma en la que reinicias los pods dependerá de si se crearon como parte de un objeto Deployment.

Si usaste un Deployment, debes reiniciarlo, de modo que se reinicien todos los pods con sidecars:
```
kubectl rollout restart deployment -n YOUR_NAMESPACE
```
Si no usaste un Deployment, borra los pods, y se volverán a crear de forma automática con sidecars:
```
kubectl delete pod -n YOUR_NAMESPACE --all
```
Verifica que todos los pods en el espacio de nombres tengan sidecars incorporados:
```
kubectl get pod -n YOUR_NAMESPACE
```
En el siguiente resultado de ejemplo del comando anterior, observa que la columna READY indica que hay dos contenedores para cada una de tus cargas de trabajo: el contenedor principal y el contenedor del proxy de sidecar.
```
NAME                    READY   STATUS    RESTARTS   AGE
YOUR_WORKLOAD           2/2     Running   0          20s
...
```

Próximos pasos

Conoce más sobre: