Estás consultando la documentación de la versión antigua 1.19 de Service Mesh.

Versiones disponibles

Cloud Service Mesh
archivo 1.24
archivo 1.23
archivo 1.22
archivo 1.21
archivo 1.20
archivo 1.19
archivo 1.18

Esta página se ha traducido con Cloud Translation API.

Instalar y actualizar pasarelas

Cloud Service Mesh te ofrece la opción de desplegar y gestionar gateways como parte de tu malla de servicios. Una pasarela describe un balanceador de carga que opera en el perímetro de la malla y recibe conexiones HTTP o TCP entrantes o salientes. Las pasarelas son proxies de Envoy que te ofrecen un control pormenorizado del tráfico que entra y sale de la malla. Las pasarelas se usan principalmente para gestionar el tráfico de entrada, pero también puedes configurarlas para gestionar otros tipos de tráfico. Por ejemplo:

Pasarelas de salida: una pasarela de salida te permite configurar un nodo de salida dedicado para el tráfico que sale de la malla, lo que te permite limitar qué servicios pueden o deben acceder a redes externas, o habilitar el control seguro del tráfico de salida para añadir seguridad a tu malla, por ejemplo.
Puertas de enlace este-oeste: un proxy para el tráfico este-oeste que permite que las cargas de trabajo de los servicios se comuniquen entre los límites de los clústeres en una malla multiprimaria de diferentes redes. De forma predeterminada, esta pasarela será pública en Internet.

En esta página se describen las prácticas recomendadas para desplegar y actualizar los proxies de la pasarela, así como ejemplos de configuración de tus propios proxies de la pasarela istio-ingressgateway y istio-egressgateway. Se pueden hacer cosas como dividir el tráfico, redirecciones y lógica de reintentos aplicando una configuración de Gateway a los proxies de la pasarela. En lugar de añadir el enrutamiento de tráfico de la capa de aplicación (L7) al mismo recurso de API, vincula un servicio virtual a la puerta de enlace. Esto te permite gestionar el tráfico de la pasarela como cualquier otro tráfico del plano de datos de la malla de servicios.

Puedes implementar gateways de diferentes formas y usar más de una topología en el mismo clúster. Consulta las topologías de implementación de Gateway en la documentación de Istio para obtener más información sobre estas topologías.

Prácticas recomendadas para implementar pasarelas

Las prácticas recomendadas para implementar pasarelas dependen de si usas el plano de datos gestionado o el plano de datos no gestionado.

Prácticas recomendadas para el plano de datos gestionado

Habilita el plano de datos gestionado.
Añade una etiqueta de revisión gestionada a un espacio de nombres.
Implementa y gestiona el plano de control y las pasarelas por separado.
Como práctica recomendada de seguridad, te recomendamos que implementes las pasarelas en un espacio de nombres diferente al del plano de control.
Usa la inyección automática de sidecar para inyectar la configuración del proxy de las pasarelas de forma similar a como inyectarías los proxies de sidecar de tus servicios.

Estas prácticas recomendadas:

Asegúrate de que tus pasarelas gestionadas se mantengan actualizadas automáticamente con las últimas mejoras y actualizaciones de seguridad.
Delega la gestión y el mantenimiento de las instancias de la pasarela en el plano de datos gestionado de Cloud Service Mesh.

Prácticas recomendadas para el plano de datos no gestionado

Implementa y gestiona el plano de control y las pasarelas por separado.
Como práctica recomendada de seguridad, te recomendamos que implementes las pasarelas en un espacio de nombres diferente al del plano de control.
Usa la inyección automática de sidecar para inyectar la configuración del proxy de las pasarelas de forma similar a como inyectarías los proxies de sidecar de tus servicios.

Estas prácticas recomendadas:

Permite que los administradores de tu espacio de nombres gestionen las pasarelas sin necesidad de tener privilegios elevados en todo el clúster.
Permite que tus administradores usen las mismas herramientas o mecanismos de implementación que utilizan para gestionar las aplicaciones de Kubernetes con el fin de implementar y gestionar las pasarelas.
Ofrecer a los administradores control total sobre la implementación de la pasarela y simplificar las operaciones. Cuando hay una nueva actualización disponible o se ha cambiado una configuración, los administradores actualizan los pods de la pasarela reiniciándolos. De esta forma, la experiencia de operar una implementación de gateway es la misma que la de operar proxies sidecar para tus servicios.

Desplegar pasarelas

Para ayudar a los usuarios que ya tienen herramientas de implementación, Cloud Service Mesh admite las mismas formas de implementar una pasarela que Istio: IstioOperator, Helm y YAML de Kubernetes. Ambos métodos producen el mismo resultado. Aunque puedes elegir el método con el que estés más familiarizado, te recomendamos que utilices el método YAML de Kubernetes, ya que es más fácil de modificar y puedes almacenar manifiestos hidratados en el control de código fuente.

Crea un espacio de nombres para la pasarela si aún no tienes uno. Sustituye GATEWAY_NAMESPACE por el nombre de tu espacio de nombres.
```
kubectl create namespace GATEWAY_NAMESPACE
```
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 o 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 de plano de control concreta.

Selecciona la pestaña que corresponda a tu tipo de instalación (gestionada o en el clúster).
gestionados
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
asm-managed-rapid   6d7h
```
En el resultado, el valor de la columna NAME es la etiqueta de revisión que corresponde al canal de lanzamiento disponible para la versión de Cloud Service Mesh.
En el clúster
En el caso de los planos de control en el clúster, el istiod servicio y el despliegue suelen tener una etiqueta de revisión similar a istio.io/rev=asm-11910-9, donde asm-11910-9 identifica la versión de Cloud Service Mesh. La revisión pasa a formar parte del istiodnombre del servicioistiod-asm-11910-9.istio-system, por ejemplo: istiod-asm-11910-9.istio-system

Usa el siguiente comando para localizar la etiqueta de revisión en istiod del plano de control en el clúster:
```
kubectl get deploy -n istio-system -l app=istiod \
  -o=jsonpath='{.items[*].metadata.labels.istio\.io\/rev}''{"\n"}'
```
Habilita el espacio de nombres para la inyección. Sustituye and REVISION por el valor de la etiqueta de revisión.

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.
```
kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
```
Si has instalado Cloud Service Mesh con asmcli, cambia al directorio que hayas especificado en --output_dir y, a continuación, cd al directorio samples.

Importante: Para asegurarte de que estás en el directorio samples correcto, ejecuta el comando ls para mostrar el contenido del directorio y confirma que hay un directorio gateways (al que accederás en el siguiente paso) y un directorio online-boutique.

Si no has realizado la instalación con asmcli, copia los archivos de configuración de las pasarelas desde el repositorio anthos-service-mesh.
Puedes implementar la configuración de pasarela de ejemplo que se encuentra en el directorio samples/gateways/ tal cual o modificarla según sea necesario.
Entrada
```
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
```
Salida
```
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
```

Una vez que hayas creado la implementación, comprueba que los nuevos servicios funcionan correctamente:

kubectl get pod,service -n GATEWAY_NAMESPACE

Verifica que el resultado sea similar al siguiente:

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Selectores de pasarela

Puedes aplicar una configuración de pasarela a los proxies istio-ingressgateway y istio-egressgateway para gestionar el tráfico entrante y saliente de tu malla, lo que te permite especificar qué tráfico quieres que entre o salga de la malla. Los recursos de configuración de Gateway usan las etiquetas de los pods de una implementación de Gateway, por lo que es importante que el selector de Gateway coincida con estas etiquetas.

Por ejemplo, en las implementaciones anteriores, la etiqueta istio=ingressgateway se asigna a los pods de la pasarela. Para aplicar una configuración de pasarela a estas implementaciones, debe seleccionar la misma etiqueta:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

Para ver un ejemplo de configuración de Gateway y de Virtual Service, consulta frontend.yaml en la aplicación de ejemplo Online Boutique.

Actualizar pasarelas

Actualizaciones in situ

En la mayoría de los casos, debe actualizar sus pasarelas siguiendo el patrón de actualización in situ. Como las pasarelas utilizan la inyección de pods, los nuevos pods de pasarela que se creen se inyectarán automáticamente con la configuración más reciente, que incluye la versión.

Si quieres cambiar la revisión del plano de control que usa la pasarela, puedes definir la etiqueta istio.io/rev en la implementación de la pasarela, lo que también activará un reinicio gradual.

Plano de control gestionado

Como Google gestiona las actualizaciones del plano de control gestionado, solo tienes que reiniciar el Deployment de la pasarela y los nuevos pods se insertarán automáticamente con la configuración y la versión más recientes.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Plano de control en clústeres

Para aplicar el mismo patrón a tus pasarelas cuando tengas el plano de control en el clúster, tendrás que cambiar la revisión del plano de control que usa la pasarela. Define la etiqueta istio.io/rev en la implementación de la pasarela, lo que activará un reinicio gradual. Los pasos necesarios dependen de si tienes que actualizar la etiqueta de revisión en el espacio de nombres o en el pod de la pasarela.

Si has etiquetado el espacio de nombres para la inyección, asigna la etiqueta istio.io/rev al espacio de nombres con el nuevo valor de revisión:
```
  kubectl label namespace GATEWAY_NAMESPACE \
    istio-injection- istio.io/rev=REVISION \
    --overwrite
```

Si has habilitado la inyección solo para el pod de la pasarela, asigna la etiqueta istio.io/rev al Deployment con el nuevo valor de revisión, como en el siguiente archivo YAML de Kubernetes:

cat <<EOF > gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
EOF

kubectl apply -f gateway-deployment.yaml

Actualizaciones de Canary (avanzadas)

Si usas el plano de control en clústeres y quieres controlar la implementación de una nueva revisión del plano de control de forma más lenta, puedes seguir el patrón de actualización canary. Puedes ejecutar varias versiones de una implementación de la pasarela y asegurarte de que todo funciona correctamente con un subconjunto de tu tráfico. Por ejemplo, si quieres lanzar una nueva revisión o una versión canary, crea una copia de tu gateway Deployment con la etiqueta istio.io/rev=REVISION definida en la nueva revisión y un nuevo nombre, como istio-ingressgateway-canary:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

Cuando se cree esta implementación, tendrás dos versiones de la puerta de enlace, ambas seleccionadas por el mismo servicio:

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

Si estás seguro de que tus aplicaciones funcionan correctamente, ejecuta este comando para cambiar a la nueva versión eliminando el Deployment con la etiqueta istio.io/rev antigua:

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Si has tenido algún problema al probar tu aplicación con la nueva versión de la pasarela, ejecuta este comando para volver a la versión anterior eliminando el Deployment con la nueva etiqueta istio.io/rev definida:

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

Configuración avanzada

Configurar la versión mínima de TLS de la pasarela

En Cloud Service Mesh 1.14 y versiones posteriores, la versión mínima predeterminada de TLS para los servidores de puerta de enlace es 1.2. Puedes configurar la versión mínima de TLS mediante el campo minProtocolVersion. Para obtener más información, consulta ServerTLSSettings.

Solucionar problemas de pasarelas

No se ha podido actualizar la imagen de la pasarela desde `auto`

Cuando despliegas o actualizas una pasarela, Cloud Service Mesh inserta auto como marcador de posición en el campo image. Después de la llamada al webhook de mutación, Cloud Service Mesh sustituye automáticamente este marcador de posición por la imagen de proxy de Cloud Service Mesh real. Si falla la llamada al webhook de mutación, se mantendrá el marcador de posición auto y no se encontrará el contenedor. Normalmente, esto se debe a una etiqueta de espacio de nombres incorrecta. Asegúrate de que has configurado el espacio de nombres correcto y, a continuación, vuelve a implementar o actualizar la pasarela.