Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la Descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Instala y actualiza puertas de enlace con las APIs de Istio

Cloud Service Mesh te da la opción de implementar y administrar puertas de enlace como parte del tu malla de servicios. Una puerta de enlace describe un balanceador de cargas que opera en el perímetro de la malla y recibe conexiones HTTP/TCP entrantes o salientes. Las puertas de enlace son usarse principalmente para administrar el tráfico de entrada, pero también puede configurar puertas de enlace para administran otros tipos de tráfico.

Puertas de enlace de salida: Una puerta de enlace de salida te permite configurar un nodo de salida dedicado. para el tráfico que sale de la malla, lo que te permite limitar los servicios acceder a redes externas o habilitar el control seguro del tráfico de salida para agregar seguridad a la malla, por ejemplo.
Puertas de enlace de entrada: Una puerta de enlace de entrada te permite configurar una entrada dedicada. para recibir conexiones HTTP/TCP entrantes.
Puertas de enlace este-oeste: un proxy para este-oeste para permitir que las cargas de trabajo del servicio se comuniquen a través de los límites del clúster en una malla de múltiples instancias principales en diferentes redes. De forma predeterminada, esta puerta de enlace será pública en Internet.

En esta página, se describen las prácticas recomendadas para implementar y actualizar los proxies de puerta de enlace, así como los ejemplos de configuración de tus propios proxies de puerta de enlace istio-ingressgateway y istio-egressgateway.

Puedes implementar puertas de enlace de diferentes maneras y usar más de una topología dentro del mismo clúster. Consulta Topologías de implementación de puertas de enlace en la documentación de Istio para obtener más información sobre estas topologías.

Prácticas recomendadas para implementar puertas de enlace

Las prácticas recomendadas para implementar puertas de enlace dependen de si usas el plano de datos administrado o el plano de datos no administrado.

Prácticas recomendadas para el plano de datos administrado

Habilita el plano de datos administrado.
Agrega una etiqueta de revisión administrada a un espacio de nombres.
Implementa y administra el plano de control y las puertas de enlace por separado.
Como práctica recomendada de seguridad, te recomendamos que implementes puertas de enlace en un espacio de nombres diferente del plano de control.
Usa la inserción automática del sidecar (inserción automática) para incorporar la configuración del proxy en las puertas de enlace de manera similar a como insertarías los proxies de sidecar para tus servicios.

Estas prácticas recomendadas son las siguientes:

Asegúrate de que las puertas de enlace administradas se mantengan actualizadas de forma automática con las mejoras y las actualizaciones de seguridad más recientes.
Transfiere la administración y el mantenimiento de las instancias de puerta de enlace a Cloud Service Mesh en el plano de datos administrado.

Prácticas recomendadas para el plano de datos no administrado

Implementa y administra el plano de control y las puertas de enlace por separado.
Como práctica recomendada de seguridad, te recomendamos que implementes puertas de enlace en un espacio de nombres diferente del plano de control.
Usa la inserción automática del sidecar (inserción automática) para incorporar la configuración del proxy en las puertas de enlace de manera similar a como insertarías los proxies de sidecar para tus servicios.

Estas prácticas recomendadas son las siguientes:

Permite que los administradores de espacios de nombres administren las puertas de enlace sin necesidad de privilegios elevados para todo el clúster.
Permite que los administradores usen las mismas herramientas o los mismos mecanismos de implementación que usan para administrar las aplicaciones de Kubernetes a fin de implementar y administrar puertas de enlace.
Brinda a los administradores control total sobre la implementación de la puerta de enlace y también simplifica las operaciones. Cuando hay una nueva actualización disponible o una configuración los administradores actualizan los Pods de la puerta de enlace reiniciándolos. Esta hace que la experiencia de operar un objeto Deployment de puerta de enlace sea la misma que que operan proxies de sidecar para tus servicios.

Implementa una puerta de enlace de muestra

Para brindar asistencia a los usuarios con las herramientas de implementación existentes, Cloud Service Mesh admite de las mismas maneras de implementar una puerta de enlace, Istio: IstioOperator, Helm y YAML de Kubernetes. Cada método produce el mismo resultado. Si bien puedes elegir el método con el que estés más familiarizado, recomendamos que uses 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 puerta de enlace de muestra.

Crea un espacio de nombres para la puerta de enlace si aún no tienes uno. Reemplaza GATEWAY_NAMESPACE por el nombre de tu espacio de nombres.
```
kubectl create namespace GATEWAY_NAMESPACE
```
Habilita el espacio de nombres para la inserción. Los pasos dependen de la implementación del plano de control.
Administrado (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
```
Administrado (Istiod)
Recomendado: 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 eres un usuario existente con el plano de control administrado de Istiod, haz lo siguiente: Recomendamos que uses la inyección predeterminada, pero la inyección basada en revisiones no es compatible. Sigue estas instrucciones:
1. Ejecuta 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-rapid   6d7h
```
  NOTA: Si dos revisiones del plano de control aparecen en la lista anterior, quita 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 versiones 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
Recomendado: 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 se admite la inyección basada en revisiones: Sigue estas instrucciones:
1. Usa el siguiente comando para encontrar 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 a los espacios de nombres. En el siguiente comando, REVISION_LABEL es el valor de la etiqueta de revisión istiod que anotaste en el paso anterior.
```
kubectl label namespace GATEWAY_NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite
```
Copia los archivos de configuración para las puertas de enlace de ejemplo desde la Repositorio anthos-service-mesh.
Cambia tu directorio al directorio samples. Para asegurarte de estar en el directorio correcto, ejecuta el comando ls para mostrar el contenido del directorio y luego confirma que haya un directorio gateways (al que accederás en la siguiente) y un directorio online-boutique.

Implementa una puerta de enlace de entrada o salida. Se encuentran en samples/gateways/ tal como está o modifícalo 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

Después de crear la implementación, verifica que los servicios nuevos funcionen de forma correcta:

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

Administra recursos de puerta de enlace como cualquier otra aplicación de Kubernetes. Las muestras de del repositorio anthos-service-mesh-packages se usan como guía y guía de inicio rápido. Personalízalos según tus necesidades.

Selectores de puertas de enlace

Aplicas un Puerta de enlace configuración de los proxies istio-ingressgateway y istio-egressgateway para administrar el tráfico de entrada y salida de tu malla, lo que te permite especificar el tráfico al que quieres ingresar o salir de la malla. Los recursos de configuración de puerta de enlace usan las etiquetas en los Pods de la implementación de una puerta de enlace, por lo que es importante que tu selector de puerta de enlace coincida con estas etiquetas.

Por ejemplo, en las implementaciones anteriores, se estableció la etiqueta istio=ingressgateway en los Pods de la puerta de enlace. Para aplicar una configuración de puerta de enlace a estas implementaciones, debes seleccionar la misma etiqueta:

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

En este ejemplo de configuración de puerta de enlace y servicio virtual, consulta frontend.yaml. en la aplicación de muestra Online Boutique.

Actualiza puertas de enlace

Actualizaciones in situ

Para la mayoría de los casos de uso, debes actualizar las puertas de enlace según el patrón de actualización in situ. Debido a que las puertas de enlace usan la inserción de Pods, los Pods nuevos de puerta de enlace que se crean se inyectarán de forma automática con la última configuración, que incluye la versión.

Si quieres cambiar la revisión del plano de control que usa la puerta de enlace, puedes establecer la etiqueta istio.io/rev en el objeto Deployment de la puerta de enlace, que también activar un reinicio progresivo.

Plano de control administrado

Google administra las actualizaciones del plano de control administrado puedes reiniciar el objeto Deployment de la puerta de enlace, y los nuevos Pods insertar automáticamente la configuración y la versión más recientes.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Plano de control en el clúster

Para aplicar el mismo patrón a las puertas de enlace cuando tienes el control en el clúster deberá cambiar la revisión del plano de control que usa la puerta de enlace. Establece la etiqueta istio.io/rev en el Deployment de la puerta de enlace que activará una un reinicio progresivo. Los pasos necesarios dependen de si necesitas actualizar etiqueta de revisión en el espacio de nombres o en el Pod de la puerta de enlace.

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

Si habilitaste la inyección solo para el pod de puerta de enlace, configura istio.io/rev etiqueta del objeto Deployment al valor de revisión nuevo, como se muestra a continuación 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 versiones canary (avanzadas)

Si usas el plano de control en el clúster y deseas controlar con mayor lentitud el lanzamiento de una revisión nueva del plano de control, puedes seguir el patrón de actualización canary. Puedes ejecutar varias versiones de un Deployment de la puerta de enlace y asegurarte de que todo funcione como se espera con un subconjunto de tu tráfico. Por ejemplo, si deseas lanzar una revisión nueva, realiza una actualización canary, crea una copia del Deployment de la puerta de enlace con la etiqueta istio.io/rev=REVISION configurada en la revisión nueva y un nombre nuevo, por ejemplo, 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 este objeto Deployment, 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 como esperabas, ejecuta este comando para realizar la transición a la nueva versión mediante la eliminación del Deployment con el conjunto de etiquetas istio.io/rev anterior:

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Si encontraste un problema cuando probaste tu aplicación con la versión nueva de la puerta de enlace, ejecuta este comando para volver a la versión anterior; para ello, borra el Deployment con el nuevo conjunto de etiquetas istio.io/rev:

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

Configuración avanzada

Configurar la versión mínima de TLS de la puerta de enlace

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

Características no compatibles

Si tienes TRAFFIC_DIRECTOR implementación del plano de control, No se admiten los siguientes campos o valores en la puerta de enlace:

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

Soluciona problemas de las puertas de enlace

No se pudo actualizar la imagen de la puerta de enlace desde `auto`

Cuando implementas o actualizas una puerta de enlace, Cloud Service Mesh inserta auto como un en el campo image. Después de la llamada al webhook de mutación, Cloud Service Mesh reemplaza automáticamente este marcador de posición con el Imagen del proxy de Cloud Service Mesh. Si la llamada al webhook de mutación falla, el auto el marcador de posición permanece y no se encuentra el contenedor. Normalmente, esto es causado por una etiqueta de espacio de nombres incorrecta. Asegúrate de haber configurado el sistema y, luego, implementa o actualiza la puerta de enlace nuevamente.