Configura Anthos Service Mesh administrado

Descripción general

Anthos Service Mesh administrado es un plano de control administrado por Google y un plano de datos opcional que simplemente configuras. Google maneja la confiabilidad, las actualizaciones, el escalamiento y la seguridad de manera retrocompatible. En esta guía, se explica cómo configurar o migrar aplicaciones a Anthos Service Mesh administrado en una configuración de uno o varios clústeres.

Para obtener información sobre las funciones admitidas y las limitaciones de Anthos Service Mesh administrado, consulta las funciones admitidas de Anthos Service Mesh administrado.

Requisitos previos

Como punto de partida, en esta página se supone que realizaste las siguientes acciones:

Requisitos

Migraciones

  • Las migraciones directas/actualizaciones del plano de control en el clúster al plano de control administrado por Google solo son compatibles con las versiones 1.9+ (instaladas con la CA de Mesh).
  • Las instalaciones con la CA de Istio primero se deben migrar a la CA de Mesh 1.9 y versiones posteriores.
  • Nota: Se admiten migraciones o actualizaciones indirectas, lo que significa que puedes seguir las rutas de actualización estándar de Anthos Service Mesh. a través de cada versión hasta que llegues a Anthos Service Mesh 1.11 con un plano de control dentro del clúster; luego puedes migrar al plano de control administrado por Google.

Limitaciones

Te recomendamos que revises la lista de funciones admitidas y limitaciones de Anthos Service Mesh administrado. En particular, ten en cuenta esta información:

  • Anthos Service Mesh administrado puede usar varios clústeres de GKE solo en un proyecto de Google Cloud.

  • La API de IstioOperator no es compatible.

  • Limitaciones del plano de datos administrado:

    • Esta versión preliminar del plano de datos administrado solo está disponible para las implementaciones nuevas del plano de control administrado. Si implementaste el plano de control administrado antes y deseas implementar el plano de datos administrado, debes volver a ejecutar la secuencia de comandos de instalación como se describe enAplica el plano de control administrado por Google.

    • El plano de datos administrado está disponible en los canales de versiones regulares y rápidos.

Habilitar Workload Identity

Si Workload Identity no está habilitado, consulta Habilita Workload Identity en un clúster para obtener los permisos de IAM necesarios y usa la CLI de gcloud a fin de habilitarlo.

Descarga la secuencia de comandos de instalación

  1. Descarga la versión más reciente de la secuencia de comandos que instala Anthos Service Mesh 1.11.8 en el directorio de trabajo actual:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.11 > install_asm

  2. Haz que la secuencia de comandos sea ejecutable:

    chmod +x install_asm

Configura cada clúster

Sigue estos pasos a fin de configurar Anthos Service Mesh administrado para cada clúster de tu malla.

Obtén credenciales de clúster

Recupera las credenciales adecuadas. El siguiente comando también apunta el contexto kubectl al clúster de destino.

gcloud container clusters get-credentials  CLUSTER_NAME \
    --zone LOCATION \
    --project PROJECT_ID

Aplica el plano de control administrado por Google

Ejecuta la secuencia de comandos de instalación install_asm para cada clúster que usará Anthos Service Mesh administrado. Te recomendamos incluir las dos opciones siguientes cuando ejecutes install_asm:

  • --option cni-managed: Esta opción habilita el complemento de interfaz de red de contenedor (CNI) de Istio. El complemento de CNI configura el redireccionamiento del tráfico de red desde y hacia los proxies de sidecar mediante la interfaz CNI de CNCF, en lugar de usar un contenedor init con alto privilegio.

  • --enable-registration: Esta marca registra el clúster en flota.

Estas opciones son necesarias si también deseas implementar el plano de datos administrado por Google. Para obtener una lista completa de las opciones, consulta la página de referencia de asmcli.

  ./install_asm --mode install --managed \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --enable-registration \
      --option cni-managed

La secuencia de comandos se descargará en el --output_dir especificado para todos los archivos a fin de configurar el plano de control administrado e instalar una puerta de enlace de Istio, junto con la herramienta istioctl y las aplicaciones de muestra. En los pasos de esta guía se asume que ejecutas istioctl de la raíz del directorio de instalación, con istioctl en el subdirectorio /bin.

Si vuelves a ejecutar install_asm en el mismo clúster, se reemplaza la configuración del plano de control existente. Asegúrate de especificar las mismas opciones y marcas si quieres establecer la misma configuración.

Ten en cuenta que una puerta de enlace de entrada no se implementa de forma automática con el plano de control. Separar la implementación de la puerta de enlace de entrada y el plano de control te permite administrar con mayor facilidad las puertas de enlace en un entorno de producción. Si el clúster necesita una puerta de enlace de entrada, consulta Instala puertas de enlace de Istio.

Aplica el plano de datos administrado por Google

Si deseas que Google administre las actualizaciones de los proxies, habilita el plano de datos administrado por Google. Si se habilita, los proxies de sidecar y las puertas de enlace insertadas se actualizan de forma automática junto con el plano de control administrado.

En la versión preliminar de la función, el plano de datos administrado actualiza los proxies mediante la expulsión de Pods que ejecutan versiones anteriores del proxy. Las expulsiones se realizan de forma ordenada para respetar el presupuesto de interrupción del Pod y controlar la velocidad de cambio.

En esta versión preliminar del plano de datos administrado, no se administra lo siguiente:

  • Pods que no se insertaron.
  • Pods insertados de forma manual mediante istioctl kube-inject
  • Trabajos
  • Conjuntos con estado
  • DaemonSet

Si no deseas usar el plano de datos administrado o no quieres habilitarlo para todos los espacios de nombres, debes activar un reinicio de los proxies para beneficiarte con la imagen de proxy más reciente. El plano de control continúa funcionando con los proxies existentes.

El plano de datos administrado está disponible en los canales de versiones rápidos y regulares.

Para habilitar el plano de datos administrado por Google, sigue estos pasos:

  1. Habilita la administración del plano de datos:

    kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

    De manera alternativa, puedes habilitar el plano de datos administrado por Google para un Pod específico anotándolo con la misma anotación. Cuando anotas un Pod específico, ese Pod usa el proxy de sidecar administrado por Google, y el resto de las cargas de trabajo usan los proxies de sidecar no administrados.

  2. Repite el paso anterior para cada espacio de nombres en el que quieras un plano de datos administrado.

  3. Habilita Anthos Service Mesh en la flota:

    gcloud alpha container hub mesh enable --project=PROJECT_ID

El controlador del plano de datos puede tardar hasta diez minutos en estar listo para administrar los proxies del clúster. Ejecuta el siguiente comando para verificar el estado:

if kubectl get dataplanecontrols -o custom-columns=REV:.spec.revision,STATUS:.status.state | grep rapid | grep -v none > /dev/null; then echo "Managed Data Plane is ready."; else echo "Managed Data Plane is NOT ready."; fi

Cuando el controlador del plano de datos esté listo, el comando generará el siguiente resultado: Managed Data Plane is ready.

Si el estado del controlador del plano de datos no muestra después de esperar más de diez minutos, consulta Estado del plano de datos administrado para obtener sugerencias de solución de problemas.

Si deseas inhabilitar el plano de datos administrado por Google y volver a administrar los proxies de sidecar, cambia la anotación:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Instala puertas de enlace de Istio (opcional)

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.

Como práctica recomendada, crea un espacio de nombres independiente para las puertas de enlace. No implementes las puertas de enlace en el espacio de nombres istio-system.

Puedes instalar una o más puertas de enlace de Istio en tu clúster para manejar el tráfico de entrada típico mediante los siguientes pasos:

  1. Elige una de estas dos opciones a fin de configurar el espacio de nombres en el que implementarás la puerta de enlace en pasos posteriores.

    • Habilita el espacio de nombres para la inserción: 
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

    O

    • Habilita la inserción solo para el Pod de puerta de enlace, pero no para todos los Pods del espacio de nombres. Este comando quita todas las etiquetas de inyección y, luego, habilitarás la inserción en el pod: 
      kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev-

  2. Crea un objeto Deployment y Service para la puerta de enlace mediante el siguiente ejemplo mínimo:

    kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
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: asm-managed-rapid # This is required only if the namespace is not labeled.
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: istio-ingressgateway-sds
  namespace: GATEWAY_NAMESPACE
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default
EOF

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

    kubectl get pod,service -n GATEWAY_NAMESPACE

    Verifica un resultado 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

Puedes permitir que el controlador del plano de datos administrado administre los proxies para las puertas de enlace del mismo modo que lo hace con tus servicios. Si implementaste el plano de datos administrado y deseas que los proxies de tu puerta de enlace estén administrados, etiqueta y anota el espacio de nombres de la puerta de enlace como se describe en Aplica el plano de datos administrado por Google.

Si eliges administrar las puertas de enlace tú mismo, debes reiniciar los pods en GATEWAY_NAMESPACE cuando se lance una nueva versión de Anthos Service Mesh para que puedan recoger el plano de control nuevo. Antes de reiniciar los Pods, debes confirmar que el nuevo plano de control se haya lanzado a tu clúster. Para ello, verifica la versión del plano de control con la consulta personalizada del Explorador de métricas proporcionada en Verifica las métricas del plano de control.

Configura la detección de extremos (solo para instalaciones de varios clústeres)

El plano de control administrado de Anthos Service Mesh admite una configuración de principales múltiples, de proyecto único y de red única, con la diferencia de que el plano de control no está instalado en el clúster.

Antes de continuar, ya deberías haber ejecutado la secuencia de comandos de instalación en cada clúster como se describe en los pasos anteriores. No es necesario indicar que un clúster es uno principal, este es el comportamiento predeterminado.

Para cada clúster, habilita el descubrimiento de extremos ejecutando los siguientes comandos una vez para cada clúster i=1..N en la malla:

  1. Para cada clúster, asegúrate de que el contexto de configuración de kubectl apunte al clúster actual:

    export CTX=gke_PROJECT_ID_LOCATION_CLUSTER_NAME

  2. Habilita el descubrimiento de extremos mediante la ejecución de los siguientes comandos una vez para cada clúster i=1..N en la malla:

    export CTX_i=gke_PROJECT_ID_LOCATION_i_CLUSTER_NAME_i

    ./bin/istioctl x create-remote-secret --context=${CTX_i} --name=CLUSTER_NAME_i | \
  kubectl apply -f - --context=${CTX}

  3. Ejecuta el siguiente comando para verificar que se haya creado el secreto:

    kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system

    Verifica el resultado esperado:

    NAME                                   TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME_i   Opaque   1      44s

  4. Si el clúster actual se agrega a una malla de varios clústeres existente, permite que todos los demás clústeres descubran sus extremos mediante la creación de un secreto correspondiente al clúster actual en todos los demás clústeres:

    ./bin/istioctl x create-remote-secret --context=${CTX} --name=CLUSTER_NAME | \
  kubectl apply -f - --context=${CTX_i}

  5. Además, puedes verificar el secreto del otro clúster:

    kubectl get secret istio-remote-secret-CLUSTER_NAME -n istio-system --context ${CTX_i}

    Verifica el resultado esperado:

    NAME                            TYPE     DATA   AGE
istio-remote-secret-CLUSTER_NAME   Opaque   1      44s

Para obtener más detalles y un ejemplo con dos clústeres, consulta Habilita el descubrimiento de extremos.

Implementar aplicaciones

Antes de implementar aplicaciones, quita las etiquetas istio-injection anteriores de sus espacios de nombres y configura la etiqueta istio.io/rev:asm-managed-rapid en su lugar:

kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid --overwrite

En este punto, configuraste correctamente el plano de control administrado de Anthos Service Mesh. Ahora estás listo para implementar las aplicaciones o puedes implementar la aplicación de muestra de Bookinfo.

Si implementas una aplicación en una configuración de varios clústeres, replica la configuración del plano de control y Kubernetes en todos los clústeres, a menos que planees limitar esa configuración en particular a un subconjunto de clústeres. La configuración que se aplica a un clúster en particular es la fuente de información de ese clúster. Además, si el clúster también ejecuta Anthos Service Mesh 1.7, 1.8 o una versión posterior con la CA de Mesh en otros espacios de nombres, verifica que la aplicación pueda comunicarse con las otras aplicaciones que controla el plano de control en el clúster.

Verifica las métricas del plano de control

Puedes ver la versión del plano de control y el plano de datos en el Explorador de métricas.

Para verificar que tu configuración funcione de forma correcta, sigue estos pasos:

  1. En la consola de Google Cloud, visualiza las métricas del plano de control:

    Ir al Explorador de métricas

  2. Elige tu lugar de trabajo y agrega una consulta personalizada con los siguientes parámetros:

    • Tipo de recurso: Contenedor de Kubernetes
    • Métrica: Clientes del proxy
    • Filtro: container_name="cr-asm-managed-rapid"
    • Agrupar por: Etiqueta de revisión y etiqueta proxy_version
    • Suma de agregador
    • Período: 1 minuto

    Cuando ejecutas Anthos Service Mesh con un plano de control administrado por Google y en el clúster, puedes distinguir las métricas por su nombre de contenedor. Por ejemplo, las métricas administradas tienen container_name="cr-asm-managed", mientras que las métricas no administradas tienen container_name="discovery". Para mostrar las métricas de ambos, quita el filtro en container_name="cr-asm-managed".

  3. Para verificar la versión del plano de control y del proxy, inspecciona los siguientes campos en el Explorador de métricas:

    • En el campo revisión, se indica la versión del plano de control.
    • El campo proxy_version indica el proxy_version.
    • El campo value indica el número de proxies conectados.

    A fin de conocer el canal actual para la asignación de versiones de Anthos Service Mesh, consulta Versiones de Anthos Service Mesh por canal.

Migra aplicaciones a Anthos Service Mesh administrado

Anthos Service Mesh administrado solo es compatible con la migración desde Anthos Service Mesh 1.9 que usa la CA de Mesh.

Para migrar a Anthos Service Mesh administrado, sigue estos pasos:

  1. Ejecuta la secuencia de comandos como se indica en la sección Aplica el plano de control administrado por Google.

  2. Si implementaste el plano de control y el plano de datos administrados por Google, haz lo siguiente:

    1. Habilita la administración del plano de datos:

      kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"true"}'

    2. Habilita Anthos Service Mesh en la flota:

      gcloud alpha container hub mesh enable --project=PROJECT_ID

  3. Reemplaza la etiqueta del espacio de nombres actual por la etiqueta istio.io/rev:asm-managed-rapid:

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-managed-rapid \
    --overwrite

  4. Realiza una actualización progresiva de las implementaciones en el espacio de nombres:

    kubectl rollout restart deployment -n NAMESPACE

  5. Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.

  6. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos anteriores para cada espacio de nombres.

  7. Si implementaste la aplicación en una configuración de varios clústeres, replica la configuración de Istio y Kubernetes en todos los clústeres, a menos que exista el deseo de limitar esa configuración a un subconjunto de clústeres solamente. La configuración que se aplica a un clúster en particular es la fuente de información de ese clúster.

  8. Para verificar que las métricas aparezcan como se espera, sigue los pasos en Verifica las métricas del plano de control.

Un clúster puede tener una combinación de revisiones, por ejemplo, Anthos Service Mesh 1.7 y 1.8, y un plano de control dentro del clúster. Puedes combinar espacios de nombres con diferentes revisiones del plano de control de Anthos Service Mesh de manera indefinida.

Si estás seguro de que tu aplicación funciona como se esperaba, puedes quitar el clúster integrado istiod después de cambiar todos los espacios de nombres al plano de control en el cluster o mantenerlos como una copia de seguridad; istiod reducirá la escala verticalmente de forma automática para usar menos recursos. Para quitarlo, ve a Borra el plano de control anterior.

Si encuentras problemas, puedes identificarlos y resolverlos mediante la información que aparece en Resuelve problemas del plano de control administrado y, si es necesario, revertir a la versión anterior.

Borrar el plano de control anterior

Después de instalar y confirmar que todos los espacios de nombres usan el plano de control administrado por Google, puedes borrar el plano de control anterior.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Si usaste istioctl kube-inject en lugar de la inserción automática, o si instalaste puertas de enlace adicionales, verifica las métricas del plano de control y verifica que la cantidad de extremos conectados sea cero.

Revertir

Realiza los siguientes pasos si necesitas revertir a la versión anterior del plano de control:

  1. Actualiza las cargas de trabajo que se insertarán con la versión anterior del plano de control: En el siguiente comando, el valor de revisión asm-191-1 solo se usa como ejemplo. Reemplaza el valor de ejemplo por la etiqueta de revisión de tu plano de control anterior.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite

  2. Reinicia los Pods para activar la reinserción a fin de que los proxies tengan la versión de Istio:

    kubectl rollout restart deployment -n NAMESPACE

El plano de control administrado escalará de forma automática a cero y no usará ningún recurso cuando no esté en uso. Los webhooks y el aprovisionamiento mutados permanecerán y no afectarán el comportamiento del clúster.

La puerta de enlace ahora está configurada en la revisión asm-managed. Para revertirlo, vuelve a ejecutar el comando de instalación de Anthos Service Mesh, que volverá a implementar la puerta de enlace que apunta al plano de control en el clúster:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Espera el siguiente resultado con éxito:

deployment.apps/istio-ingressgateway rolled back

Migra una puerta de enlace al plano de control administrado por Google

  1. Crea una implementación de Kubernetes para la versión nueva de la puerta de enlace mediante la documentación. Debes configurar el servicio de Kubernetes Gateway existente para seleccionar la versión anterior y la nueva, mediante el campo selector en la configuración del servicio.

  2. Mediante el uso del comando kubectl scale, escala verticalmente y de forma gradual la implementación nueva, mientras reduces verticalmente la escala de la implementación anterior y verificas si hay indicadores de cualquier interrupción o tiempo de inactividad del servicio. Si la migración se realiza correctamente, no deberías alcanzar instancias anteriores ni experimentar interrupciones del servicio.

Desinstalar

El plano de control administrado por Google se escala automáticamente a cero cuando ningún espacio de nombres lo está utilizando; por lo tanto, no se requiere desinstalación.

Soluciona problemas

Para identificar y resolver problemas cuando usas el plano de control administrado, consulta Resuelve problemas del plano de control administrado.

Próximos pasos