Instalar y actualizar pasarelas con las APIs de Istio

Cloud Service Mesh te ofrece la opción de desplegar y gestionar pasarelas 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 se usan principalmente para gestionar el tráfico de entrada, pero también se pueden configurar para gestionar otros tipos de tráfico.

  • 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.

  • Pasarelas de entrada: una pasarela de entrada te permite configurar un nodo de entrada dedicado para recibir conexiones HTTP o TCP entrantes.

  • 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.

Puede implementar las pasarelas 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

  1. Habilita el plano de datos gestionado.
  2. Añade una etiqueta de revisión gestionada a un espacio de nombres.
  3. Implementa y gestiona el plano de control y las pasarelas por separado.
  4. Como práctica recomendada de seguridad, te recomendamos que implementes las pasarelas en un espacio de nombres diferente al del plano de control.
  5. 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

  1. Implementa y gestiona el plano de control y las pasarelas por separado.
  2. Como práctica recomendada de seguridad, te recomendamos que implementes las pasarelas en un espacio de nombres diferente al del plano de control.
  3. 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 una pasarela de ejemplo

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.

En los siguientes pasos se muestra cómo implementar una pasarela de ejemplo.

  1. 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

  2. Habilita el espacio de nombres para la inyección. Los pasos dependen de la implementación del plano de control.

    Gestionado (TD)

    1. Aplica la etiqueta de inyección predeterminada al espacio de nombres:
    kubectl label namespace GATEWAY_NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

    Gestionado (Istiod)

    Recomendación: Ejecuta el siguiente comando para aplicar la etiqueta de inyección predeterminada al espacio de nombres:

      kubectl label namespace GATEWAY_NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

    Si ya eres usuario del plano de control de Istiod gestionado: Te recomendamos que utilices la inyección predeterminada, pero también se admite la inyección basada en revisiones. Sigue estas instrucciones:

    1. Ejecuta 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-rapid   6d7h

      NOTA: Si aparecen dos revisiones del plano de control en la lista anterior, elimina una. No se admite tener varios canales del plano de control en el clúster.

      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.

    2. Aplica la etiqueta de revisión al espacio de nombres:

      kubectl label namespace GATEWAY_NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

    En el clúster

    Recomendación: Ejecuta el siguiente comando para aplicar la etiqueta de inyección predeterminada al espacio de nombres:

      kubectl label namespace GATEWAY_NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

    Te recomendamos que uses la inyección predeterminada, pero también se admite la inyección basada en revisiones: Sigue estas instrucciones:

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

      kubectl get deploy -n istio-system -l app=istiod -o \
   jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

    2. Aplica la etiqueta de revisión al espacio de nombres. En el siguiente comando, REVISION_LABEL es el valor de la etiqueta de revisión istiod que has anotado en el paso anterior.

      kubectl label namespace GATEWAY_NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

  3. Copia los archivos de configuración de las pasarelas de ejemplo del repositorio anthos-service-mesh.

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

  5. Implementa una pasarela de entrada o de salida. Se encuentran en el directorio samples/gateways/ tal cual o se pueden modificar 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

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

    kubectl get pod,service -n GATEWAY_NAMESPACE

    Comprueba 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

Gestiona los recursos de la pasarela como cualquier otra aplicación de Kubernetes. Las muestras del repositorio anthos-service-mesh-packages se han incluido con fines orientativos y para que puedas empezar a usar la API rápidamente. Personalízalas según tus necesidades.

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 ha definido en 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 Cloud 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, la versión mínima predeterminada de TLS para los servidores de puerta de enlace es la 1.2. Puedes configurar la versión mínima de TLS mediante el campo minProtocolVersion. Para obtener más información, consulta ServerTLSSettings.

Funciones no compatibles

Si tienes una TRAFFIC_DIRECTOR implementación del plano de control, no se admiten los siguientes campos o valores en Gateway:

  • ServerTLSSettings.TLSmode con el valor AUTO_PASSTHROUGH
  • ServerTLSSettings.verifyCertificateSpki
  • ServerTLSSettings.verifyCertificateHash

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 la llamada al webhook de mutación falla, se mantiene el marcador de posición auto y no se encuentra el contenedor. Normalmente, esto se debe a una etiqueta de espacio de nombres incorrecta. Asegúrate de haber configurado el espacio de nombres correcto y vuelve a implementar o actualizar la pasarela.