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

Esta página se ha traducido con Cloud Translation API.

Requisitos previos de Cloud Service Mesh en clústeres

En esta página se describen los requisitos previos y los requisitos para instalar Cloud Service Mesh en el clúster para cargas de trabajo de Kubernetes fuera de Google Cloud, como los requisitos de clúster, de flota y generales.

Proyecto en la nube

Antes de empezar:

Seleccione o cree un Google Cloud proyecto.
Comprueba que la facturación esté habilitada en tu proyecto.

Requisitos generales

Para que se incluyan en la malla de servicios, los puertos de servicio deben tener un nombre, y este debe incluir el protocolo del puerto con la siguiente sintaxis: name: protocol[-suffix] donde los corchetes indican un sufijo opcional que debe empezar por un guion. Para obtener más información, consulta Asignar nombres a puertos de servicio.
Si has creado un perímetro de servicio en tu organización, puede que tengas que añadir el servicio de autoridad de certificación de Cloud Service Mesh al perímetro. Consulta más información sobre cómo añadir una autoridad de certificación de Cloud Service Mesh a un perímetro de servicio.
Si quieres cambiar los límites de recursos predeterminados del contenedor sidecar istio-proxy, los nuevos valores deben ser superiores a los predeterminados para evitar eventos de falta de memoria (OOM).
Un proyecto Google Cloud solo puede tener una malla asociada.

Requisitos de clústeres

Asegúrate de que el clúster de usuarios en el que instales Cloud Service Mesh tenga al menos 4 vCPUs, 15 GB de memoria y 4 nodos.
Comprueba que la versión de tu clúster aparezca en la lista de plataformas compatibles.
Asegúrate de que el equipo cliente desde el que instalas Cloud Service Mesh tenga conectividad de red con el servidor de la API.
Si vas a implementar sidecars en pods de aplicaciones en los que no haya conectividad directa a los servicios de CA (como meshca.googleapis.com y privateca.googleapis.com), debes configurar un proxy HTTPS explícito basado en CONNECT.
En el caso de los clústeres públicos con reglas de cortafuegos de salida definidas que bloquean las reglas implícitas, asegúrate de haber configurado reglas HTTP/HTTPS y DNS para acceder a las APIs públicas de Google.

Requisitos de la flota

Todos los clústeres deben registrarse en una flota y se debe habilitar la identidad de carga de trabajo de la flota. Puedes configurar los clústeres tú mismo o dejar que asmcli los registre siempre que cumplan los siguientes requisitos:

Clústeres de GKE fuera de Google Cloud: (se aplica a Cloud Service Mesh en el clúster) Google Distributed Cloud (solo software) para VMware, Google Distributed Cloud (solo software) para bare metal, GKE en AWS (obsoleto) y GKE en Azure (obsoleto) se registran automáticamente en tu flota de proyectos cuando se crean los clústeres. Desde GKE Enterprise 1.8, todos estos tipos de clúster habilitan automáticamente la identidad de carga de trabajo de flota cuando se registran. Los clústeres registrados se actualizan para usar la identidad de cargas de trabajo de la flota cuando se actualizan a GKE Enterprise 1.8.
Clústeres de Amazon EKS (obsoleto): (se aplica a Cloud Service Mesh en el clúster) el clúster debe tener un proveedor de identidades OIDC de IAM público. Sigue las instrucciones de Crear un proveedor de OIDC de IAM para tu clúster para comprobar si existe un proveedor y, si es necesario, crear uno.

Cuando ejecutas asmcli install, especificas el ID del proyecto del proyecto host de la flota. asmcli registra el clúster si aún no lo está.