Estás viendo la documentación de Anthos Service Mesh 1.8. Consulta la documentación más reciente o selecciona otra versión disponible:

Instalación y migración de varios proyectos en GKE

En esta guía, se explica cómo instalar o migrar a Anthos Service Mesh desde Istio de código abierto para una malla que contiene varios clústeres de GKE que se encuentran en diferentes proyectos de Google Cloud.

Puedes usar esta guía para los siguientes casos de uso de integración:

  • Instalaciones nuevas de Anthos Service Mesh 1.8.5.

  • Migraciones de Istio de código abierto 1.7 or 1.8 a Anthos Service Mesh 1.8.5. Si tienes una versión anterior de Istio, debes realizar una actualización antes de migrar a Anthos Service Mesh.

No todas las funciones están disponibles para una malla de servicios con clústeres en proyectos diferentes. En particular, los paneles de Anthos Service Mesh en Cloud Console no están disponibles en este momento. Sin embargo, aún puedes ver registros en Cloud Logging y métricas en Cloud Monitoring para cada proyecto.

Antes de comenzar

En esta guía, suponemos que ya tienes lo siguiente:

Si realizas la migración desde Istio, asegúrate de revisar Prepárate para la migración desde Istio.

Diferencias entre Anthos Service Mesh y Anthos

  • Para los suscriptores de Anthos, asegúrate de habilitar la API de Anthos.

    Habilitar la API

  • Si no estás suscrito a Anthos, puedes instalar Anthos Service Mesh, pero ciertos elementos y funciones de la IU en Google Cloud Console solo están disponibles para los suscriptores de Anthos. Si quieres obtener información sobre lo que está disponible para suscriptores y no suscriptores, consulta las diferencias en la IU de Anthos Service Mesh y Anthos. Si quieres obtener información sobre los precios de Anthos Service Mesh para usuarios no suscritos, consulta Precios.

Requisitos

  • Debido a que tus clústeres están en proyectos diferentes, deben estar en una Nube privada virtual compartida (VPC). Para obtener información sobre la configuración de los clústeres, consulta Configura clústeres con VPC compartida.

  • El clúster de GKE debe cumplir con los siguientes requisitos:

    • Su tipo de máquina debe tener, al menos, cuatro CPU virtuales, como e2-standard-4. Si el tipo de máquina del clúster no tiene al menos cuatro CPU virtuales, cámbialo como se describe en Migra cargas de trabajo a diferentes tipos de máquina.

    • La cantidad mínima de nodos depende del tipo de máquina. Anthos Service Mesh requiere al menos ocho CPU virtuales. Si el tipo de máquina tiene cuatro CPU virtuales, el clúster debe tener al menos dos nodos. Si el tipo de máquina tiene ocho CPU virtuales, el clúster solo necesita un nodo. Si necesitas agregar nodos, consulta Cambia el tamaño de un clúster.

    • Para preparar tu clúster antes de instalar Anthos Service Mesh, habilita Workload Identity. Workload Identity es el método recomendado para llamar a las API de Google. Habilitar Workload Identity cambia la forma en que se protegen las llamadas de tus cargas de trabajo a las API de Google, como se describe en Limitaciones de Workload Identity.

    • De manera opcional, puedes inscribir el clúster en un canal de versiones. Te recomendamos que te inscribas en el canal de versiones regular, ya que otros podrían basarse en una versión de GKE que no es compatible con Anthos Service Mesh 1.8.5. Para obtener más información, consulta Entornos compatibles. Sigue las instrucciones en Inscribe un clúster existente en un canal de versiones si tienes una versión estática de GKE.

  • Para que se los incluya en la malla de servicios, los puertos de servicio deben tener un nombre, y ese nombre debe incluir el protocolo del puerto en la siguiente sintaxis: name: protocol[-suffix], en la que los corchetes indican un sufijo opcional que debe comenzar con un guion. Para obtener más información, consulta Asigna nombres a puertos de servicio.

  • Si instalas Anthos Service Mesh en un clúster privado, debes abrir el puerto 15017 en el firewall para que el webhook se use con la incorporación automática de sidecar y funcione de manera correcta. Para obtener más información, consulta Abre un puerto en un clúster privado.

  • Si creaste un perímetro de servicio en tu organización, es posible que debas agregar el servicio de CA de Mesh al perímetro. Para obtener más información, consulta Agrega la CA de Mesh a un perímetro de servicio.

  • Un proyecto de Google Cloud solo puede tener una malla asociada.

Elige una autoridad certificada

Para las instalaciones y migraciones nuevas, puedes usar la autoridad certificada de Anthos Service Mesh (CA de Mesh) o Citadel (ahora incorporada en istiod) como autoridad certificada (CA) para emitir certificados de mutual TLS (mTLS).

Por lo general, recomendamos que uses CA de Mesh por los siguientes motivos:

  • La CA de Mesh es un servicio altamente confiable y escalable que está optimizado para cargas de trabajo escaladas de forma dinámica en Google Cloud.
  • Con la CA de Mesh, Google administra la seguridad y la disponibilidad del backend de CA.
  • La CA de Mesh te permite tener una sola raíz de confianza entre clústeres.

Sin embargo, hay casos en los que podrías considerar usar Citadel, como los que se mencionan a continuación:

  • Si tienes una CA personalizada.
  • Si realizas la migración desde Istio.

    Si eliges Citadel, hay poco tiempo de inactividad porque el tráfico de mTLS no se interrumpe durante la migración. Si eliges CA de Mesh, debes programar el tiempo de inactividad para la migración, ya que la raíz de confianza cambia de Citadel a la CA de Mesh. Para completar la migración a la raíz de confianza de la CA de Mesh, debes reiniciar todos los Pods en todos los espacios de nombres. Durante este proceso, los Pods antiguos no pueden establecer conexiones mTLS con los Pods nuevos.

En los certificados de CA de Mesh, se incluyen los siguientes datos sobre los servicios de tu aplicación:

  • El ID del proyecto de Google Cloud
  • El espacio de nombres de GKE
  • El nombre de la cuenta de servicio de GKE

Registra tu clúster

Aunque no es obligatorio actualmente, te recomendamos que registres el clúster en el Environ de tu proyecto (también conocido como Hub). Un Environ te permite organizar clústeres para facilitar la administración de varios clústeres. Mediante el registro de los clústeres en un Environ, puedes agrupar servicios y otra infraestructura según sea necesario para aplicar políticas coherentes. Si tienes clústeres en diferentes proyectos, debes registrarlos con el proyecto host de Environ en lugar del proyecto en el que se creó el clúster. Si deseas obtener más información para registrar tu clúster, consulta Registra clústeres en Environ.

El concepto de un proyecto host de Environ es importante cuando configuras tu clúster para habilitar las opciones que requiere Anthos Service Mesh. La malla de servicios del clúster se identifica con un valor basado en un número de proyecto. Cuando configuras clústeres de diferentes proyectos, tienes que usar el número del proyecto host de Environ.