Cloud Service Mesh es una malla de servicios administrada por Google que se puede habilitar con facilidad. Google administra la confiabilidad, las actualizaciones, el escalamiento y la seguridad por ti.
En esta página, se muestra cómo usar la API de fleet para configurar Cloud Service Mesh administrado con las APIs de Istio.
Requisitos previos
Como punto de partida, en esta página se supone que realizaste las siguientes acciones:
- Un proyecto de Cloud
- Una cuenta de facturación de Cloud
- Obtener los permisos necesarios para aprovisionar Cloud Service Mesh
- Habilitaste Workload Identity en tus clústeres.
Requisitos
- Uno o más clústeres con una versión de GKE compatible en una de las regiones admitidas.
- Asegúrate de que tu clúster tenga suficiente capacidad para los componentes necesarios que
administraste Cloud Service Mesh para que instale en el clúster.
- La implementación
mdp-controller
en el espacio de nombreskube-system
solicita CPU: 50 m, memoria: 128 Mi. - El daemonset
istio-cni-node
en el espacio de nombreskube-system
solicita CPU: 100 m, memoria: 100 Mi en cada nodo.
- La implementación
- Asegúrate de que la máquina cliente desde la que aprovisionas Cloud Service Mesh administrado tenga conectividad de red al servidor de la API.
- Tus clústeres deben estar registrados en una flota. Esto se incluye en las instrucciones, o bien se puede hacer por separado antes del aprovisionamiento.
- Tu proyecto debe tener habilitada la función de flota de Service Mesh. Esto está incluido en las instrucciones o se puede hacer por separado.
GKE Autopilot solo es compatible con la versión 1.21.3 o posterior de GKE.
Cloud Service Mesh puede usar varios clústeres de GKE en un entorno de red única de proyecto o de un solo proyecto.
- 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.
- Para un entorno de varios clústeres en un proyecto único, el proyecto de la flota puede ser el mismo que el proyecto del clúster. Para obtener más información sobre las flotas, consulta Descripción general de las flotas.
- Para un entorno de varios proyectos, te recomendamos que alojes la flota en un proyecto separado de los proyectos del clúster. Si las políticas de la organización y la configuración existente lo permiten, te recomendamos que uses el proyecto de VPC compartida como el proyecto host de la flota. Para obtener más información, consulta Configura clústeres con VPC compartida.
Funciones necesarias para instalar Cloud Service Mesh
En la siguiente tabla, se describen las funciones necesarias para instalar Cloud Service Mesh administrado.
Nombre de la función | ID de la función | Otorga la ubicación | Descripción |
---|---|---|---|
Administrador de GKE Hub | roles/gkehub.admin | Proyecto de flota | Acceso completo a GKE Hubs y recursos relacionados. |
Administrador de Service Usage | roles/serviceusage.serviceUsageAdmin | Proyecto de flota | Puede inspeccionar, habilitar y también inhabilitar estados de servicio, inspeccionar operaciones junto con cuotas de consumo y facturación para un proyecto de consumidor. (Nota 1) |
Administrador del servicio de CA beta | roles/privateca.admin | Proyecto de flota | Tiene acceso completo a todos los recursos del Servicio de CA. (Nota 2) |
Limitaciones
Te recomendamos que revises la lista de funciones y limitaciones compatibles con Cloud Service Mesh. 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.El uso de Certificate Authority Service (CA Service) requiere configurar Cloud Service Mesh por clúster y no es compatible cuando se usa la configuración predeterminada de la flota en GKE Enterprise.
Para los clústeres de GKE Autopilot, la configuración entre proyectos solo es compatible con GKE 1.23 o una versión posterior.
En el caso de los clústeres de GKE Autopilot, para adaptarse al límite de recursos de GKE Autopilot, las solicitudes y los límites predeterminados de los recursos del proxy se establecen en 500m de CPU y 512 Mb de memoria. Puedes anular los valores predeterminados con la inyección personalizada.
Durante el proceso de aprovisionamiento para un plano de control administrado, las CRD de Istio se aprovisionan en el clúster especificado. Si hay CRD de Istio existentes en el clúster, se reemplazarán.
La CNI de Istio y Cloud Service Mesh no son compatibles con GKE Sandbox. Por lo tanto, Cloud Service Mesh administrado con la implementación
TRAFFIC_DIRECTOR
no admite clústeres con GKE Sandbox habilitado.
Antes de comenzar
- Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
- Configura
gcloud
(incluso si usas Cloud Shell). -
Autentica con Google Cloud CLI, en el que FLEET_PROJECT_ID
es el ID de tu proyecto host de flota. Por lo general, FLEET_PROJECT_ID se crea de forma predeterminada y tiene el mismo nombre que el proyecto.
gcloud auth login --project FLEET_PROJECT_ID
- Actualiza los componentes:
gcloud components update
-
Habilita las APIs necesarias en el proyecto host de la flota.
gcloud services enable mesh.googleapis.com \ --project=FLEET_PROJECT_ID
En la consola de Google Cloud, ve a la página Administrador de funciones.
En el panel Malla de servicios, haz clic en Configurar.
Revisa la configuración que heredan todos los clústeres nuevos que crees en la consola de Google Cloud y regístrate en la flota.
Para aplicar estos parámetros de configuración, haz clic en Configurar.
En el cuadro de diálogo Confirmación, haz clic en Confirmar.
Opcional: Sincroniza los clústeres existentes con la configuración predeterminada:
- En la lista Clústeres de la flota, selecciona los clústeres que deseas sincronizar. Solo puedes seleccionar clústeres que tengan instalado Cloud Service Mesh.
- Haz clic en Sincronizar con la configuración de la flota y, luego, en Confirmar en el diálogo de confirmación que aparece. Esta operación puede tardar unos minutos en completarse.
Configuración a nivel de la flota
Crea un archivo
mesh.yaml
que solo contenga la única líneamanagement: automatic
:echo "management: automatic" > mesh.yaml
Habilita Cloud Service Mesh para tu flota:
gcloud container fleet mesh enable --project FLEET_PROJECT_ID \ --fleet-default-member-config mesh.yaml
Si ves el siguiente error, debes habilitar GKE Enterprise.
ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The [anthos.googleapis.com] service is required for this operation and is not enabled for the project [PROJECT_NUMBER]. Please use the Google Developers Console to enable it.: failed precondition
Configuración a nivel de la red
Si el proyecto de tu red difiere del proyecto host de la flota (por ejemplo, usas una VPC compartida), debes permitir que las cuentas de servicio de Cloud Service Mesh en el proyecto de la flota accedan al proyecto de red. Solo necesitas hacerlo una vez para el proyecto de red.
Otorga permiso a las cuentas de servicio en el proyecto de la flota para acceder al proyecto de red:
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Configuración a nivel del clúster
Cuando estés listo para crear clústeres que se usarán con Cloud Service Mesh, créalos y regístralos en un solo paso con Google Cloud CLI a fin de usar la configuración predeterminada. Por ejemplo:
gcloud container clusters create-auto CLUSTER_NAME \ --fleet-project FLEET_PROJECT_ID \ --location=LOCATION
Para obtener el número de proyecto de tu flota, ejecuta el siguiente comando:
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
La marca
--location
es la zona o región de procesamiento (comous-central1-a
ous-central1
) del clúster.Si el proyecto de tu clúster difiere del proyecto host de la flota, debes permitir que las cuentas de servicio de Cloud Service Mesh en el proyecto de la flota accedan al proyecto del clúster y habilitar las APIs necesarias en el proyecto del clúster. Solo necesitas hacerlo una vez para cada proyecto de clúster.
Otorga a las cuentas de servicio del proyecto de la flota permiso para acceder al proyecto de clúster:
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Habilita la API de Mesh en el proyecto del clúster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
Reemplaza CLUSTER_PROJECT_ID por el identificador único de tu proyecto de clúster. Si creaste tu clúster en el mismo proyecto que tu flota, el CLUSTER_PROJECT_ID es el mismo que el FLEET_PROJECT_ID.
Registra un clúster de GKE con la identidad de carga de trabajo de la flota. La marca
--location
es la zona de procesamiento o la región (comous-central1-a
ous-central1
) del clúster.gcloud container clusters update CLUSTER_NAME \ --location CLUSTER_LOCATION \ --fleet-project FLEET_PROJECT_ID
Verifica que tu clúster esté registrado:
gcloud container fleet memberships list --project FLEET_PROJECT_ID
Resultado de ejemplo:
NAME EXTERNAL_ID LOCATION cluster-1 1d8e255d-2b55-4df9-8793-0435461a2cbc us-central1
Toma nota del MEMBERSHIP_NAME, ya que lo necesitarás cuando habilites la administración automática.
Si el proyecto de red del clúster difiere del proyecto host de la flota (por ejemplo, usas una VPC compartida), debes permitir que las cuentas de servicio de Cloud Service Mesh en el proyecto de la flota accedan al proyecto de red. Solo necesitas hacerlo una vez para el proyecto de red.
Otorga permiso a las cuentas de servicio en el proyecto de la flota para acceder al proyecto de red:
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Si el proyecto de tu clúster difiere del proyecto host de la flota, debes permitir que las cuentas de servicio de Cloud Service Mesh en el proyecto de la flota accedan al proyecto del clúster y habilitar las APIs necesarias en el proyecto del clúster.
Solo necesitas hacerlo una vez para cada proyecto de clúster. Si ya configuraste Cloud Service Mesh administrado para esta combinación de proyectos de clúster y flota, estos cambios ya se aplicaron y no tienes que ejecutar los siguientes comandos.
Otorga a las cuentas de servicio en el proyecto de la flota permiso para acceder al proyecto del clúster:
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \ --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \ --role roles/anthosservicemesh.serviceAgent
Habilita la API de Mesh en el proyecto del clúster:
gcloud services enable mesh.googleapis.com \ --project=CLUSTER_PROJECT_ID
- MEMBERSHIP_NAME es el nombre de la membresía que se mostró cuando verificaste que tu clúster se registró en la flota.
MEMBERSHIP_LOCATION es la ubicación de tu membresía (ya sea una región o
global
).Si creaste la membresía hace poco con el comando en esta guía, esta debería ser la región de tu clúster. Si tienes un clúster zonal, usa la región correspondiente a la zona del clúster. Por ejemplo, si tienes un clúster zonal en
us-central1-c
, usa el valorus-central1
.Este valor puede ser
global
si te registraste antes de mayo de 2023 o si especificaste la ubicación deglobal
cuando registraste la membresía. Puedes verificar la ubicación de tu membresía congcloud container fleet memberships list --project FLEET_PROJECT_ID
.- Pods que no se insertaron
- Pods insertados de forma manual
- Jobs
- StatefulSets
- DaemonSets
Ve a la página Comunicación.
En la fila Actualización de Cloud Service Mesh, en la columna Correo electrónico, selecciona el botón de selección para ACTIVAR las notificaciones de mantenimiento.
- Kubernetes requiere que se configure el campo
image
antes de que se ejecute la inserción. Si bien puedes configurar una imagen específica para anular la predeterminada, te recomendamos establecerimage
enauto
, lo que hará que el inyector de sidecar seleccione automáticamente la imagen que se usará. - Algunos campos de
containers
dependen de la configuración relacionada. Por ejemplo, debe ser menor o igual que el límite de CPU. Si ambos campos no están configurados de forma correcta, es posible que el Pod no se inicie. - Kubernetes te permite configurar
requests
ylimits
para los recursos del Podspec
. GKE Autopilot solo considerarequests
. Para obtener más información, consulta Establece límites de recursos en Autopilot. - Para GKE Standard, si se configura
sidecar.istio.io/proxyCPU
, asegúrate de configurarsidecar.istio.io/proxyCPULimit
de forma explícita. De lo contrario, el límite de CPU del archivo adicional se establecerá como ilimitado. - Para GKE Standard, si
sidecar.istio.io/proxyMemory
está configurado, asegúrate de configurarsidecar.istio.io/proxyMemoryLimit
de forma explícita. De lo contrario, el límite de memoria del archivo adicional se establecerá como ilimitado. - Para GKE Autopilot, la configuración de los recursos
requests
ylimits
con anotaciones podría aprovisionar en exceso los recursos. Evita usar el enfoque de plantillas de imágenes. Consulta Ejemplos de modificación de recursos en Autopilot. Reemplaza la etiqueta del espacio de nombres actual. Los pasos necesarios dependen de si deseas usar etiquetas de inserción predeterminadas (por ejemplo,
istio-injection enabled
) o la etiqueta de revisión.Etiqueta de inyección predeterminada
Ejecuta el siguiente comando para mover la etiqueta predeterminada a la revisión administrada:
istioctl tag set default --revision REVISION_LABEL
Ejecuta el siguiente comando para etiquetar el espacio de nombres con
istio-injection=enabled
, si aún no lo era:kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- \ --overwrite
Etiqueta de revisión
Si usaste la etiqueta
istio.io/rev=REVISION_LABEL
, ejecuta el siguiente comando:kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL \ --overwrite
Realiza una actualización progresiva de las implementaciones en el espacio de nombres:
kubectl rollout restart deployment -n NAMESPACE
Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.
Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos anteriores para cada espacio de nombres.
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.
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
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
Habilitar mesh.googleapis.com habilita las siguientes APIs:
API | Objetivo | Se puede inhabilitar |
---|---|---|
meshconfig.googleapis.com |
Cloud Service Mesh usa la API de configuración de malla para retransmitir los datos de configuración de la malla a Google Cloud. Además, habilitar la API de configuración de malla te permite acceder a las páginas de Cloud Service Mesh en la consola de Google Cloud y usar la autoridad certificadora de Cloud Service Mesh. | No |
meshca.googleapis.com |
Se relaciona con la autoridad certificadora de Cloud Service Mesh que usa Cloud Service Mesh administrado. | No |
container.googleapis.com |
Obligatorio para crear clústeres de Google Kubernetes Engine (GKE). | No |
gkehub.googleapis.com |
Es obligatorio para administrar la malla como una flota. | No |
monitoring.googleapis.com |
Se requiere para capturar la telemetría de las cargas de trabajo en malla. | No |
stackdriver.googleapis.com |
Obligatorio para usar la IU de servicios. | No. |
opsconfigmonitoring.googleapis.com |
Es necesario usar la IU de servicios para clústeres fuera de Google Cloud. | No |
connectgateway.googleapis.com |
Es obligatorio para que el plano de control de Cloud Service Mesh administrado pueda acceder a las cargas de trabajo de la malla. | Sí* |
trafficdirector.googleapis.com |
Habilita un plano de control administrado escalable y con alta disponibilidad. | Sí* |
networkservices.googleapis.com |
Habilita un plano de control administrado escalable y con alta disponibilidad. | Sí* |
networksecurity.googleapis.com |
Habilita un plano de control administrado escalable y con alta disponibilidad. | Sí* |
Configura la malla de servicios de Cloud administrada
Los pasos necesarios para aprovisionar Cloud Service Mesh administrado mediante la API de la flota dependen de si prefieres habilitarlo de forma predeterminada para los clústeres de flota nuevos o por clúster.
Configurar para tu flota
Si habilitaste la edición Google Kubernetes Engine (GKE) Enterprise, puedes habilitar Cloud Service Mesh administrado como una configuración predeterminada para tu flota. Esto significa que cada clúster de GKE nuevo en Google Cloud que se registre durante la creación del clúster tendrá habilitado Cloud Service Mesh administrado en el clúster. Puedes obtener más información sobre la configuración predeterminada de la flota en Administra las funciones a nivel de la flota.
Habilitar la malla de servicios de Cloud administrada como una configuración predeterminada para tu flota y registrar clústeres en ella durante la creación del clúster solo admite la CA de Mesh. Si deseas usar Certificate Authority Service, te recomendamos que lo habilites por clúster.
Si deseas habilitar los valores predeterminados a nivel de la flota para Cloud Service Mesh administrado, completa los siguientes pasos:
Console
gcloud
Para establecer los valores predeterminados a nivel de la flota con Google Cloud CLI, debes establecer la siguiente configuración:
Continúa con la verificación de que se aprovisionó el plano de control.
Configurar por clúster
Usa los siguientes pasos para configurar Cloud Service Mesh administrado en cada clúster de la malla de forma individual.
Habilitar la función de flota de Cloud Service Mesh
Habilitar Cloud Service Mesh en el proyecto de la flota Ten en cuenta que, si planeas registrar varios clústeres, la habilitación de Cloud Service Mesh se realiza a nivel de la flota, por lo que solo tienes que ejecutar este comando una vez.
gcloud container fleet mesh enable --project FLEET_PROJECT_ID
Registra clústeres en una flota
Configura Certificate Authority Service (opcional)
Si la implementación de la malla de servicios requiere Certificate Authority Service (CA Service), sigue los pasos en Configura Certificate Authority Service para un servicio administrado de Cloud Service Mesh a fin de habilitarlo en tu flota. Asegúrate de completar todos los pasos antes de continuar a la siguiente sección.
Habilitar la administración automática
Ejecuta el siguiente comando para habilitar la administración automática:
gcloud container fleet mesh update \
--management automatic \
--memberships MEMBERSHIP_NAME \
--project FLEET_PROJECT_ID \
--location MEMBERSHIP_LOCATION
Donde:
Verifica si se aprovisionó el plano de control
Después de unos minutos, verifica que el estado del plano de control sea ACTIVE
:
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
El resultado es similar al siguiente:
...
membershipSpecs:
projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
mesh:
management: MANAGEMENT_AUTOMATIC
membershipStates:
projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
servicemesh:
controlPlaneManagement:
details:
- code: REVISION_READY
details: 'Ready: asm-managed'
state: ACTIVE
implementation: ISTIOD | TRAFFIC_DIRECTOR
dataPlaneManagement:
details:
- code: OK
details: Service is running.
state: ACTIVE
state:
code: OK
description: 'Revision(s) ready for use: asm-managed.'
...
Toma nota del plano de control que se muestra en el campo implementation
, ya sea ISTIOD
o TRAFFIC_DIRECTOR
. Consulta Funciones compatibles de Cloud Service Mesh para conocer las diferencias del plano de control y los parámetros de configuración compatibles, y conocer cómo se selecciona la implementación del plano de control.
Configura kubectl
para que apunte al clúster
Las siguientes secciones implican la ejecución de comandos kubectl
en cada uno de tus clústeres. Antes de continuar con las secciones a continuación, ejecuta el comando siguiente para cada uno de tus clústeres y configura kubectl
de modo que apunte al clúster.
gcloud container clusters get-credentials CLUSTER_NAME \
--location CLUSTER_LOCATION \
--project CLUSTER_PROJECT_ID
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 o una de salida, consulta Implementa puertas de enlace. Para habilitar otras funciones opcionales, consulta Habilita funciones opcionales en Cloud Service Mesh.
Plano de datos administrado
Si usas Cloud Service Mesh administrado, Google administra por completo las actualizaciones de tus proxies, a menos que lo inhabilites a nivel del espacio de nombres, la carga de trabajo o la revisión.
Con el plano de datos administrado, los proxies de sidecar y las puertas de enlace insertadas se actualizan de forma automática junto con el plano de control administrado mediante el reinicio de las cargas de trabajo para volver a insertar versiones nuevas del proxy. Por lo general, esto se completa entre 1 y 2 semanas después de que se actualiza el plano de control administrado.
Si se inhabilita, el ciclo de vida natural de los Pods del clúster impulsa la administración de proxies y el usuario la debe activar manualmente para controlar la frecuencia de actualizació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 gradual, respetando el presupuesto de interrupción del Pod y controlando la tasa de cambio.
El plano de datos administrado no administra lo siguiente:
Inhabilita el plano de datos administrado (opcional)
Si aprovisionas Cloud Service Mesh administrado en un clúster nuevo, puedes inhabilitar el plano de datos administrado por completo o para Pods o espacios de nombres individuales. El plano de datos administrado seguirá inhabilitado para los clústeres existentes en los que se inhabilitó de forma predeterminada o manual.
Para inhabilitar el plano de datos administrado a nivel del clúster y volver a administrar los proxies de sidecar, cambia la anotación:
kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Si deseas inhabilitar el plano de datos administrado para un espacio de nombres, haz lo siguiente:
kubectl annotate --overwrite namespace NAMESPACE \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Para inhabilitar el plano de datos administrado de un Pod, sigue estos pasos:
kubectl annotate --overwrite pod POD_NAME \
mesh.cloud.google.com/proxy='{"managed":"false"}'
Habilita las notificaciones de mantenimiento
Puedes solicitar que se te notifique sobre el próximo mantenimiento del plano de datos administrado hasta una semana antes de la programación de mantenimiento. Las notificaciones de mantenimiento no se envían de forma predeterminada. También debes configurar un período de mantenimiento de GKE para poder recibir notificaciones. Cuando se habilita, las notificaciones se envían al menos dos días antes de la operación de actualización.
Para habilitar las notificaciones de mantenimiento del plano de datos administrado, haz lo siguiente:
Cada usuario que desee recibir notificaciones debe habilitarlas por separado. Si deseas establecer un filtro de correo electrónico para estas notificaciones, el asunto es el siguiente:
Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"
.
En el siguiente ejemplo, se muestra una notificación típica de mantenimiento del plano de datos administrado:
Asunto: Próxima actualización del clúster de Cloud Service Mesh “
<location/cluster-name>
”Estimado usuario de Cloud Service Mesh:
Los componentes de Cloud Service Mesh en tu clúster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) están programados para actualizarse el ${scheduled_date_human_Read} a las ${scheduled_time_human_ read}.
Para obtener información sobre la nueva actualización, consulta las notas de la versión (https://cloud.google.com/service-mesh/docs/release-notes).
Si se cancela este mantenimiento, te enviaremos otro correo electrónico.
Saludos,
El equipo de Cloud Service Mesh
(c) 2023 Google LLC, 1600 Amphitheater Parkway, Mountain View, CA 94043 Te enviamos este anuncio para informarte sobre cambios importantes relacionados con tu cuenta o Google Cloud Platform. Para inhabilitar las notificaciones sobre el período de mantenimiento, edita tus preferencias de usuario: https://console.cloud.google.com/user-preferences/Communication?project=${project_id}
Configura la detección de extremos (solo para instalaciones de varios clústeres)
Si tu malla tiene un solo clúster, omite estos pasos de varios clústeres y continúa con Implementa aplicaciones o Migra aplicaciones.
Antes de continuar, asegúrate de que Cloud Service Mesh esté configurado en cada clúster.
Si habilitas Cloud Service Mesh con la API de la flota, se habilitará el descubrimiento de extremos para este clúster. Sin embargo, debes abrir los puertos de firewall. Si quieres inhabilitar la detección de extremos en uno o más clústeres, consulta las instrucciones para inhabilitarlo en Descubrimiento de extremos entre clústeres con una API declarativa.
Para ver una aplicación de ejemplo con dos clústeres, consulta Ejemplo de servicio de Hello World.
Implementar aplicaciones
Si tienes más de un clúster en la flota que usa Cloud Service Mesh administrado, asegúrate de que el descubrimiento del extremo o los puertos de firewall estén configurados según lo previsto antes de continuar y de implementar las aplicaciones.Para implementar aplicaciones, usa la etiqueta istio-injection=enabled
Etiqueta de inyección predeterminada
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite
Etiqueta de revisión
Antes de implementar aplicaciones, quita las etiquetas istio-injection
anteriores de sus espacios de nombres y configura la etiqueta istio.io/rev=REVISION_LABEL
en su lugar.
Esta es la etiqueta de revisión que identificaste cuando verificaste el plano de control.
Para cambiarla a una etiqueta de revisión específica, haz clic en REVISION_LABEL
y reemplázala por la etiqueta aplicable: asm-managed-rapid
para Rápido, 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 |
---|---|
asm-managed |
Normal |
asm-managed-rapid |
Rápido |
asm-managed-stable |
Estable |
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite
En este punto, configuraste con éxito Cloud Service Mesh. Si tienes cargas de trabajo existentes en espacios de nombres etiquetados, reinícialas para que se inserten proxies.
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.
Personaliza la inserción (opcional)
Puedes anular los valores predeterminados y personalizar la configuración de inserción, pero esto puede generar errores de configuración imprevistos y problemas resultantes con los contenedores de archivos adicionales. Antes de personalizar la inserción, lee la información después de la muestra para obtener notas sobre parámetros de configuración y recomendaciones específicos.
La configuración por Pod está disponible para anular estas opciones en Pods individuales.
Para ello, se debe agregar un contenedor istio-proxy
al Pod. La inserción de sidecar tratará cualquier configuración definida aquí como una anulación a la plantilla de inyección predeterminada.
Por ejemplo, en la siguiente configuración, se personalizan diferentes opciones de configuración, como reducir las solicitudes de CPU, agregar una activación de volumen y un hook preStop
:
apiVersion: v1
kind: Pod
metadata:
name: example
spec:
containers:
- name: hello
image: alpine
- name: istio-proxy
image: auto
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "200m"
memory: "256Mi"
volumeMounts:
- mountPath: /etc/certs
name: certs
lifecycle:
preStop:
exec:
command: ["sleep", "10"]
volumes:
- name: certs
secret:
secretName: istio-certs
En general, se puede configurar cualquier campo en un Pod. Sin embargo, se deben tener cuidado con los siguientes campos:
Además, ciertos campos se pueden configurar mediante anotaciones en el Pod, aunque se recomienda usar el enfoque anterior para personalizar la configuración. Presta especial atención a las siguientes anotaciones:
Por ejemplo, consulta la siguiente anotación de recursos:
spec:
template:
metadata:
annotations:
sidecar.istio.io/proxyCPU: "200m"
sidecar.istio.io/proxyCPULimit: "200m"
sidecar.istio.io/proxyMemory: "256Mi"
sidecar.istio.io/proxyMemoryLimit: "256Mi"
Migra aplicaciones a Cloud Service Mesh administrado
Para migrar aplicaciones de Cloud Service Mesh en el clúster a Cloud Service Mesh administrado, sigue estos pasos:
Si estás seguro de que tu aplicación funciona como se espera, puedes quitar el istiod
en el clúster después de cambiar todos los espacios de nombres al plano de control administrado o mantenerlos como una copia de seguridad. istiod
reducirá la escala automáticamente 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:
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 revertirla, vuelve a ejecutar el comando de instalación de Cloud 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
Desinstala Cloud Service Mesh
El plano de control administrado realiza un ajuste de escala automático a cero cuando no hay espacios de nombres que lo usen. Para obtener pasos detallados, consulta Desinstala Cloud Service Mesh.