Configurar 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 con asmcli.

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

  • Uno o más clústeres con una versión de GKE compatible en una de las regiones admitidas.
  • Tus clústeres deben estar registrados en una flota. Este paso se puede hacer por separado antes de la instalación o como parte de ella si pasas las marcas --enable-registration y --fleet-id.

  • Tu proyecto debe tener habilitada la función de Malla de servicios. Puedes habilitarlo como parte de la instalación si pasas --enable-gcp-components o si ejecutas el siguiente comando:

    gcloud container hub mesh enable --project=FLEET_PROJECT_ID

    en el que FLEET_PROJECT_ID es el ID del proyecto host de la flota.

  • Anthos Service Mesh administrado puede usar varios clústeres de GKE en un entorno de una sola red de un solo proyecto o en un entorno de una sola red de varios proyectos. Si unes clústeres que no están en el mismo proyecto, deben estar registrados en el mismo proyecto host de la flota y los clústeres deben estar en la configuración de una VPC compartida en la misma red. Además, te recomendamos que tengas un proyecto para alojar la VPC compartida y proyectos de servicio independientes a fin de crear clústeres. Para obtener más información, consulta Configura clústeres con VPC compartida.

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:

  • La API de IstioOperator no es compatible, ya que su propósito principal es controlar los componentes del clúster.

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

  • Las funciones reales disponibles para Anthos Service Mesh administrado dependen del canal de versiones. Para obtener más información, revisa la lista completa de funciones y limitaciones admitidas de Anthos Service Mesh.

Configura gcloud

Sigue estos pasos incluso si usas Cloud Shell.

  1. Autentica con Google Cloud CLI

    gcloud auth login --project PROJECT_ID

  2. Actualiza los componentes:

    gcloud components update

  3. Si instalas Anthos Service Mesh en un clúster de GKE, configura kubectl para que apunte al clúster.

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

Descarga la herramienta de instalación

  1. Descarga la versión más reciente de la herramienta en el directorio de trabajo actual:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli

  2. Haz que la herramienta sea ejecutable:

    chmod +x asmcli

Configura cada clúster

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

Aplica el plano de control administrado por Google

Ejecuta la herramienta de instalación para cada clúster que usará Anthos Service Mesh administrado. Te recomendamos que incluyas las dos opciones siguientes:

  • --enable-registration --fleet_id FLEET_PROJECT_ID Estas dos marcas registran el clúster en una flota, en el que FLEET_ID es el ID del proyecto host de la flota. Si se usa un solo proyecto, el FLEET_PROJECT_ID es el mismo que PROJECT_ID, el proyecto host de la flota y el proyecto del clúster son los mismos. En configuraciones más complejas, como las de varios proyectos, te recomendamos usar un proyecto host de flota independiente.

  • --enable-all. Esta marca habilita los componentes y el registro necesarios.

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.

Antes de aplicar el plano de control administrado por Google, debes seleccionar un canal de versiones.

La herramienta asmcli configura el plano de control administrado directamente con las herramientas y la lógica dentro de la herramienta de la CLI. Usa el conjunto de instrucciones que se muestra a continuación según tu CA preferida.

Si tu organización aplica el Control del servicio de VPC para tu proyecto, debes configurar una marca adicional: --use-vpcsc. De lo contrario, la instalación no pasará los controles de seguridad. La asistencia para la función de VPC-SC está disponible en los canales regulares y rápidos. Si usas la versión 1.11, debes usar el comando experimental.

Si tu clúster es un clúster de Autopilot de GKE, consulta el final de esta sección a fin de obtener requisitos y marcas adicionales para usar con el comando “asmcli”.

Ten en cuenta que el complemento de la interfaz de red de los contenedores (CNI) de Istio está habilitado de forma predeterminada cuando implementas el plano de control administrado por Google.

Autoridades certificadoras

Selecciona una autoridad certificadora para usarla en tu malla.

CA de Mesh

Ejecuta el siguiente comando para instalar el plano de control con las funciones predeterminadas y con la CA de Mesh. Ingresa los valores en los marcadores de posición proporcionados. Reemplaza RELEASE_CHANNEL por el canal adecuado: regular, stable o rapid.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL

Servicio de CA

  1. Sigue los pasos de la página Configura Certificate Authority Service.
  2. Ejecuta el siguiente comando para instalar el plano de control con las funciones predeterminadas y Certificate Authority Service. Ingresa los valores en los marcadores de posición proporcionados. Reemplaza RELEASE_CHANNEL por el canal adecuado: regular, stable o rapid.
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL \
      --ca gcp_cas \
      --ca_pool pool_name

La herramienta descargará todos los archivos para configurar el plano de control administrado en el --output_dir especificado, e instalará la herramienta istioctl y las aplicaciones de muestra. En los pasos de esta guía, se supone que ejecutas istioctl desde la ubicación --output_dir que especificaste cuando ejecutaste asmcli install, con istioctl presente en su subdirectorio <Istio release dir>/bin.

Si vuelves a ejecutar asmcli 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.

GKE Autopilot

Autopilot de GKE solo es compatible con Anthos Service Mesh en los canales regulares y rápidos. El clúster debe estar en el canal rápido de GKE con la versión 1.21.3 o una posterior. Para adaptarse al límite de recursos de Autopilot de GKE, los requisitos y límites de recursos del proxy predeterminados se establecen en 500 m de CPU y 512 MB de memoria. Los clústeres de Autopilot requieren la CNI administrada, por lo que debes incluir la marca --use_managed_cni. Reemplaza RELEASE_CHANNEL por el canal adecuado: regular, stable o rapid.

./asmcli install \
    -p PROJECT_ID \
    -l LOCATION \
    -n CLUSTER_NAME \
    --managed \
    --verbose \
    --output_dir CLUSTER_NAME \
    --use_managed_cni \
    --channel RELEASE_CHANNEL \
    --enable-all \

Verifica si se aprovisionó el plano de control

La herramienta de asmcli crea un recurso personalizado ControlPlaneRevision en el clúster. El estado de este recurso se actualiza cuando el plano de control administrado se aprovisiona o falla en el aprovisionamiento.

Inspecciona el estado del recurso. Reemplaza NAME por el valor correspondiente a cada canal: asm-managed, asm-managed-stable o asm-managed-rapid.

kubectl describe controlplanerevision NAME -n istio-system

El resultado es similar al siguiente:

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

La condición de conciliación determina si el plano de control administrado se ejecuta de forma correcta. Si es true, el plano de control se ejecuta de forma correcta. Stalled determina si el proceso de aprovisionamiento del plano de control administrado encontró un error. Si es Stalled, el campo Message contiene más información sobre el error específico. Consulta Códigos detenidos para obtener más información sobre posibles errores.

Actualizaciones automáticas

Una vez que se instala el plano de control administrado por Google, Google lo actualizará de forma automática cuando haya actualizaciones o parches nuevos disponibles.

No es obligatorio actualizar el plano de datos cada vez que se realiza una actualización del plano de control. El plano de control continúa funcionando con todos los proxies de la ventana de asistencia, pero se recomienda hacerlo para obtener acceso a las funciones más recientes del plano de datos, correcciones y mejoras de rendimiento. Para actualizar a la última imagen de proxy publicada en tu canal, puedes realizar un reinicio progresivo, cuando sea conveniente, o aplicar el plano de datos administrado por Google que lo hará de forma automática por ti.

Aplica el plano de datos administrado por Google (opcional)

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.

Ten en cuenta que el plano de datos administrado por Google requiere el complemento de la Interfaz de la Red del Contenedor (CNI) de Istio, que ahora está habilitado de forma predeterminada cuando implementas el plano de control administrado por Google.

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

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.

    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 aparece como listo 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"}'

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

Antes de continuar, ya debes haber configurado Anthos Service Mesh administrado 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. Debes terminar las secciones Configura las variables de proyecto y clúster y Crear regla de firewall antes de configurar el descubrimiento de extremos.

Clústeres públicos

Configura el descubrimiento de extremos entre clústeres públicos

Si operas en clústeres públicos (clústeres no privados), consulta Configura el descubrimiento de extremos entre clústeres públicos.

Clústeres privados

Configura el descubrimiento de extremos entre clústeres privados

Cuando usas clústeres privados de GKE, debes configurar el extremo del plano de control del clúster para que sea el extremo público en lugar del extremo privado. Consulta Configura el descubrimiento de extremos entre clústeres privados.

Para ver una aplicación de ejemplo con dos clústeres, consulta Ejemplo de servicio de Hello World.

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. Si usas una etiqueta de revisión diferente, haz clic en asm-managed-rapid y reemplázala por la etiqueta aplicable: asm-managed para regular o asm-managed-stable para estable.

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 
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. Si también aplicaste el plano de datos administrado, reinicia las cargas de trabajo. De lo contrario, realiza una actualización progresiva. 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 o Certificate Authority Service con la CA de Mesh en otros espacios de nombres, verifica que la aplicación pueda comunicarse con las otras aplicaciones controladas por 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 Cloud Console, observa 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

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

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

  2. Si deseas usar el plano de datos administrado por Google, habilita la administración del plano de datos (opcional):

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

  3. Si deseas usar el plano de datos administrado por Google, habilita Anthos Service Mesh en la flota (opcional):

    gcloud alpha container hub mesh enable --project=PROJECT_ID

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

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

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

Desinstalar

El plano de control administrado por Google se escala de forma automática a cero cuando no hay espacios de nombres que lo usen. Para ver los pasos detallados, consulta Desinstala Anthos Service Mesh.

Soluciona problemas

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

Códigos detenidos de ControlPlaneRevision

Hay varias razones por las que la condición Stalled podría convertirse en verdadera en el estado ControlPlaneRevisions.

Motivo Mensaje Descripción
PreconditionFailed Solo se admiten las membresías de GKE, pero ${CLUSTER_NAME} no es un clúster de GKE. Parece que el clúster actual no es un clúster de GKE. El plano de control administrado solo funciona en los clústeres de GKE.
Nombre de ControlPlaneRevision no admitido: ${NAME} El nombre de ControlPlaneRevision debe ser uno de los siguientes:
  • asm-managed
  • asm-managed-rapid
  • asm-managed-stable
Unsupported ControlPlaneRevision namespace: ${NAMESPACE} El espacio de nombres de ControlPlaneRevision debe ser istio-system.
El canal ${Channel} no se admite para ControlPlaneRevision con el nombre${NAME}. Se esperaba ${OTHER_Channel} El nombre de ControlControleRevision debe coincidir con el canal de ControlPlaneRevision en función de la siguiente información:
  • asm-managed -> regular
  • asm-managed-rapid -> rapid
  • asm-managed-stable -> stable
No se debe omitir el canal ni dejarlo en blanco Channel es un campo obligatorio en ControlPlaneRevision. Falta en el recurso personalizado o está vacío.
Tipo de revisión del plano de control no compatible: ${TYPE} managed_service es el único campo de permiso para el campo ControlPlaneRevisionType.
Versión de Kubernetes no compatible: ${VERSION} Las versiones de Kubernetes 1.15 y posteriores son compatibles.
La identidad de carga de trabajo no está habilitada. Habilita la identidad de carga de trabajo en el clúster.
Grupo de cargas de trabajo no compatible: ${POOL} El grupo de cargas de trabajo debe tener el formato ${PROJECT_ID}.svc.id.goog.
El proyecto de clúster y el de Environ no coinciden Los clústeres deben pertenecer al mismo proyecto en el que están registrados en la flota.
ProvisioningFailed Se produjo un error mientras se actualizaban los recursos del clúster Google no pudo actualizar los recursos en el clúster, como los CRD y los webhooks.
MutatingWebhookConfiguration "istiod-asm-managed" contiene un webhook con la URL ${EXISTING_URL}, pero se espera ${EXPECTED_URL} Google no reemplazará los webhooks existentes para evitar que se rompa la instalación. Actualiza esto de forma manual si deseas tener un comportamiento deseado.
ValidingWebhookConfiguration ${NAME} contiene un webhook con la URL ${EXISTING_URL}, pero se espera ${EXPECTED_URL} Google no reemplazará los webhooks existentes para evitar que se rompa la instalación. Actualiza esto de forma manual si deseas tener un comportamiento deseado.

Próximos pasos