Anthos Service Mesh te brinda la opción de implementar y administrar puertas de enlace como parte de tu malla de servicios. Una puerta de enlace describe un balanceador de cargas que opera en el perímetro de la malla que recibe conexiones HTTP/TCP entrantes o salientes. Las puertas de enlace son proxies de Envoy que te brindan un control detallado sobre el tráfico que entra y sale de la malla. Las puertas de enlace se usan principalmente para administrar el tráfico de entrada, pero también puedes configurar puertas de enlace que administren otros tipos de tráfico. Por ejemplo:
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 qué servicios pueden o deben acceder a las redes externas o habilitar el control seguro del tráfico de salida para agregar seguridad a tu malla, por ejemplo.
Puertas de enlace este-oeste: un proxy para el tráfico este-oeste a fin de permitir que las cargas de trabajo del servicio se comuniquen a través de los límites del clúster en una malla multiprincipal en redes diferentes. 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
.
Algunos aspectos como la división del tráfico, los redireccionamientos y la lógica de reintento son posibles si se aplica una configuración de la puerta de enlace a los proxies de puerta de enlace. Luego, en lugar de agregar 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 administrar el tráfico de puerta de enlace como cualquier otro tráfico del plano de datos en la malla de servicios.
Puedes implementar puertas de enlace de diferentes maneras y puedes usar más de una topología dentro del mismo clúster. Consulta Topologías de implementación de puerta 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
- 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 la misma manera que usas a fin de insertar 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 el Deployment de la puerta de enlace y también simplifica las operaciones. Cuando una actualización nueva está disponible o se modifica una configuración, los administradores actualizan los Pods de la puerta de enlace mediante su reinicio. Esto hace que la experiencia de operar un Deployment de la puerta de enlace sea la misma que operar los proxies de sidecar operativos de tus servicios.
Implementa puertas de enlace
Para admitir usuarios con herramientas de implementación existentes, Anthos Service Mesh admite las mismas formas de implementar una puerta de enlace que Istio: IstioOperator
, Helm y YAML de Kubernetes. Cada método produce el mismo resultado. Aunque puedes elegir el método con el que más estés familiarizado, te recomendamos que uses el método YAML de Kubernetes porque es más fácil de modificar y puedes almacenar manifiestos hidratados en el control de origen.
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
Para habilitar la inserción automática en la puerta de enlace, aplica una etiqueta de revisión en el espacio de nombres de la puerta de enlace. El webhook de inyector de sidecar usa la etiqueta de revisión para asociar los proxies insertados con una revisión de plano de control en particular. La etiqueta de revisión que uses depende de si implementaste el plano de control administrado por Google o el plano de control en el clúster.
A continuación, selecciona la pestaña según tu tipo de instalación (ya sea administrada por Google o en el clúster).
Google-managed
En el plano de control administrado por Google, la etiqueta de revisión corresponde a un canal de versiones:
Etiqueta de revisión Canal istio.io/rev=asm-managed
Normal istio.io/rev=asm-managed-rapid
Rápido istio.io/rev=asm-managed-stable
Estable El espacio de nombres de la puerta de enlace puede estar en el mismo canal de versiones que tus servicios o en un canal de versiones diferente. Te recomendamos usar el mismo canal de versiones en un clúster. Para ver qué canal de versiones usa un espacio de nombres, haz lo siguiente:
kubectl get namespace NAMESPACE -L istio.io/rev
En el clúster
En los planos de control en el clúster, el servicio y Deployment de
istiod
suelen tener una etiqueta de revisión similar aistio.io/rev=asm-1118-4
, en la queasm-1118-4
identifica la versión de Anthos Service Mesh. La revisión pasa a formar parte del nombre del servicioistiod
, por ejemplo:istiod-asm-1118-4.istio-system
.Usa el siguiente comando a fin de encontrar la etiqueta de revisión en
istiod
para el 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 inserción. Reemplaza
REVISION
por el valor de la etiqueta de revisión.kubectl label namespace GATEWAY_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 etiquetaistio-injection
, que debería aparecer en las nuevas instalaciones de Anthos Service Mesh o en implementaciones nuevas. Debido a que la inserción automática falla si un espacio de nombres tiene tanto laistio-injection
como la etiqueta de revisión, todos los comandoskubectl label
de la documentación de Anthos Service Mesh incluyen la acción de quitar la etiquetaistio-injection
.Si instalaste Anthos Service Mesh con
asmcli
, cambia al directorio que especificaste en--output_dir
y, luego,cd
al directoriosamples
.Si no lo instalaste mediante
asmcli
, copia los archivos de configuración de las puertas de enlace del repositorioanthos-service-mesh
.Puedes implementar la configuración de la puerta de enlace de ejemplo ubicada en el directorio
samples/gateways/
tal como está o modificarla según sea necesario.Ingress
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
El resultado es similar a este:
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 puertas de enlace
Debes aplicar una configuración de Puerta de enlace a los proxies istio-ingressgateway
y istio-egressgateway
para administrar el tráfico entrante y saliente de la malla, lo que te permite especificar qué tráfico deseas que ingrese o salga 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, la etiqueta istio=ingressgateway
se configura 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
...
Para ver un ejemplo de una configuración de puerta de enlace y un servicio virtual, consulta frontend.yaml en la aplicación de muestra de Online Boutique.
Actualiza puertas de enlace
Actualizaciones locales
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 deseas cambiar la revisión del plano de control que usa la puerta de enlace, puedes configurar 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 por Google
Debido a que Google administra las actualizaciones del plano de control para el plano de control administrado por Google, puedes reiniciar el objeto Deployment de la puerta de enlace y los pods nuevos se inyectarán de forma automática con la configuración y 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 plano de control en el clúster, deberás cambiar la revisión del plano de control que usa la puerta de enlace.
Configura la etiqueta istio.io/rev
en el Deployment de la puerta de enlace que activará un reinicio progresivo.
- Actualiza la 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 inserción, haz lo siguiente:
- Establece la etiqueta istio.io/rev en el espacio de nombres con el nuevo valor de revisión
kubectl label namespace GATEWAY_NAMESPACE \
istio-injection- istio.io/rev=REVISION \
--overwrite
O
- Si habilitaste la inserción solo para el Pod de la puerta de enlace, haz lo siguiente:
- Establece la etiqueta istio.io/rev en el objeto Deployment con el nuevo valor de revisión
- YAML de Kubernetes
- Establece la etiqueta istio.io/rev en el objeto Deployment con el nuevo valor de revisión
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 (avanzado)
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