Instalación y migración en GKE

En esta guía, se explica cómo instalar o migrar a la versión 1.6.14 de Anthos Service Mesh para una malla que contiene uno o más clústeres de GKE que se encuentran en el mismo proyecto. Debes usar una secuencia de comandos proporcionada por Google, que configura tu proyecto y tu clúster, y, luego, instala Anthos Service Mesh.

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

  • Instalaciones nuevas de Anthos Service Mesh. Si tienes instalada una versión anterior de Anthos Service Mesh, consulta Actualiza Anthos Service Mesh en GKE. La secuencia de comandos 1.6 no controla las actualizaciones.

  • Migraciones de Istio |.6 de código abierto a Anthos Service Mesh. No se admite la migración desde una versión anterior de Istio. La versión 1.7 de la secuencia de comandos admite la migración de Istio 1.6 o 1.7 a Anthos Service Mesh 1.7. Como vas a realizar una migración, es posible que prefieras hacerlo a Anthos Service Mesh 1.7.

  • Migraciones desde la versión 1.6 del complemento Istio on GKE en Anthos Service Mesh. Antes de que puedas migrar a Anthos Service Mesh, debes actualizar a Istio 1.6 con Operator. Para ver los pasos de migración completos del complemento, consulta Migra a Anthos Service Mesh en la documentación de Istio on GKE.

Debes usar la guía Instalación y migración avanzadas en GKE para los siguientes casos de uso:

  • Cuando necesites personalizar la instalación para anular la configuración del perfil asm-gcp y tengas más de un archivo YAML IstioOperator superpuesto. La secuencia de comandos te permite especificar solo un archivo YAMl.

  • En una malla de varios clústeres en la que los clústeres se encuentren en diferentes proyectos.

Antes de comenzar

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

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

Diferencias entre Anthos Service Mesh y Anthos

  • Los suscriptores de GKE Enterprise deben asegurarse de habilitar la API de GKE Enterprise.

    Habilitar la API

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

Requisitos

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

    • La secuencia de comandos habilita Workload Identity en tu clúster. 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.

    • Aunque es una acción opcional, se recomienda inscribir el clúster en un canal de versiones. Te recomendamos que te inscribas en el canal de versiones regular, ya que otros se podrían basar en una versión de GKE que no es compatible con Anthos Service Mesh 1.6.14. 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.

  • Para las migraciones, istiod debe instalarse en el espacio de nombres istio-system.

Restricciones

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.
En las instalaciones nuevas de Anthos Service Mesh, la secuencia de comandos habilita la CA de Mesh de forma predeterminada.

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 migras desde Istio o el complemento Istio on GKE.

    Si eliges Citadel, no hay tiempo de inactividad porque el tráfico de mTLS no se interrumpe durante la migración. Si eliges la CA de Mesh, debes programar el tiempo de inactividad para la migración, ya que el tráfico de mTLS fallará hasta que reinicies todos los Pods en todos los espacios de nombres.

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

Instala las herramientas necesarias

Puedes ejecutar la secuencia de comandos en Cloud Shell o en tu máquina local que ejecuta Linux o macOS. Cloud Shell instala previamente todas las herramientas necesarias.

Para ejecutar la secuencia de comandos de forma local, haz lo siguiente:

  1. Asegúrate de tener instaladas las siguientes herramientas:

  2. Autentica con la CLI de gcloud:

    gcloud auth login

  3. Actualiza los componentes:

    gcloud components update

  4. Asegúrate de que git esté en tu ruta para que kpt pueda encontrarlo.

Ejecuta la secuencia de comandos

En esta sección, se describe cómo descargar la secuencia de comandos, configurar los parámetros necesarios y opcionales y ejecutar la secuencia de comandos. Para obtener una explicación detallada de lo que hace la secuencia de comandos, consulta Información sobre la secuencia de comandos.

  1. Descarga la secuencia de comandos en el directorio de trabajo actual:

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

  2. Descarga el SHA-256 del archivo en el directorio de trabajo actual:

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

  3. Con ambos archivos en el mismo directorio, verifica la descarga:

    sha256sum -c --ignore-missing install_asm.sha256

    Si la verificación se realiza de forma correcta, el comando genera este resultado: install_asm: OK.

    Para mayor compatibilidad, el archivo install_asm.sha256 incluye la suma de verificación dos veces a fin de permitir que cualquier versión de la secuencia de comandos cambie su nombre a install_asm. Si recibes un error que indica que --ignore-missing no existe, vuelve a ejecutar el comando anterior sin la marca --ignore-missing.

  4. Haz que la secuencia de comandos sea ejecutable:

    chmod +x install_asm

  5. Configura las opciones y especifica las marcas para ejecutar la secuencia de comandos. Siempre debes incluir las siguientes opciones: project_id, cluster_name, cluster_location y mode. Según el mode, es posible que debas incluir la opción ca.

    • Las opciones project_id, cluster_name y cluster_location identifican el clúster en el que se instalará Anthos Service Mesh.
    • El mode es install o migrate.
    • La ca especifica la autoridad certificada como mesh_ca o citadel.

    En la siguiente sección, se proporcionan ejemplos típicos de la ejecución de la secuencia de comandos. Para obtener una descripción completa de los argumentos de la secuencia de comandos, consulta Opción y marcas.

  6. Para completar la configuración de Anthos Service Mesh, debes habilitar la inyección automática del archivo adicional y, luego, implementar o volver a implementar las cargas de trabajo.

Ejemplos

En esta sección, se muestran ejemplos de ejecución de la secuencia de comandos en cada mode y algunos argumentos adicionales que pueden resultarte útiles. Consulta la barra de navegación de la derecha para ver una lista de los ejemplos.

Solo validación

En el siguiente ejemplo, se muestra la ejecución de la secuencia de comandos con la opción --only_validate. Con esta opción, la secuencia de comandos no realiza ningún cambio en tu clúster y no instala Anthos Service Mesh. La secuencia de comandos valida lo siguiente:

  • Tu entorno tiene las herramientas necesarias.
  • Tienes el permiso requerido en el proyecto especificado.
  • El clúster cumple con los requisitos mínimos.
  • El proyecto tiene habilitadas todas las API de Google requeridas.

De forma predeterminada, la secuencia de comandos descarga y extrae el archivo de instalación, y descarga el paquete de configuración asm de GitHub a un directorio temporal. Antes de salir, la secuencia de comandos genera un mensaje que proporciona el nombre del directorio temporal. Puedes especificar un directorio existente para las descargas con la opción --output_dir DIR_PATH. La opción --output_dir te permite usar la herramienta de línea de comandos de istioctl si la necesitas.

  1. Crea un directorio llamado asm-packages:

    mkdir asm-packages

  2. Ejecuta el siguiente comando para validar tu configuración y descargar el archivo de instalación y el paquete asm en el directorio asm-packages:

    ./install_asm \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION \
--mode install \
--output_dir ./asm-packages \
--only_validate

Si la operación es exitosa, la secuencia de comandos mostrará lo siguiente:

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Si una de las pruebas no pasa la validación, la secuencia de comandos mostrará un mensaje de error. Por ejemplo, si tu proyecto no tiene habilitadas todas las API de Google necesarias, verás el siguiente error:

ERROR: One or more APIs are not enabled. Please enable them and retry, or
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

Nueva instalación

El siguiente comando ejecuta la secuencia de comandos para una instalación nueva, habilita la CA de Mesh (la CA predeterminada para las instalaciones nuevas, por lo que no necesitas la opción ca en este caso) y permite que la secuencia de comandos habilite las API de Google requeridas.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis

Nueva instalación con un archivo de superposición

En el siguiente ejemplo, se realiza una instalación nueva y se incluye un archivo YAML que habilita una función opcional.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis \
  --operator_overlay egressgateways.yaml

Migración desde Istio

Si realizas una migración desde Istio de código abierto, estárás usando Citadel como la CA. Con el siguiente comando, se ejecuta la secuencia de comandos para una migración a Anthos Service Mesh y habilitar Citadel como la CA. Esta migración solo implementa el plano de control. No cambia la CA raíz y no es una interrupción en las cargas de trabajo existentes.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

Opciones y marcas

Opciones

-p|--project_id CLUSTER_PROJECT_ID
El ID del proyecto en el que se creó el clúster.
-n|--cluster_name CLUSTER_NAME
Es el nombre del clúster.
-l|--cluster_location CLUSTER_LOCATION
Es la zona (para clústeres de una sola zona) o la región (para clústeres regionales) en la que se creó el clúster.
-m|--mode {install|migrate}
Ingresa install si haces una instalación nueva de Anthos Service Mesh. Ingresa migrate si migras desde Istio o el complemento Istio on GKE a Anthos Service Mesh.
-c|--ca {mesh_ca|citadel}
Si realizas una instalación nueva, este parámetro se establece de forma predeterminada como la CA de Mesh, y no tienes que incluirlo. Si realizas la migración desde Istio, debes especificar citadel o mesh_ca. Si puedes programar el tiempo de inactividad para la migración, te recomendamos que uses mesh_ca. Si no puedes programarlo, usa citadel.
-o|--operator_overlay YAML_FILE
Es el nombre del archivo YAML para habilitar una función que no está habilitada en el perfil asm-gcp. La secuencia de comandos debe poder ubicar el archivo YAML. Por lo tanto, el archivo debe estar en el mismo directorio que la secuencia de comandos o puedes especificar una ruta relativa, como: ../manifests/asm-features.yaml.
-s|--service_account ACCOUNT
El nombre de una cuenta de servicio que se usa para instalar Anthos Service Mesh. Si no se especifica, se usa la cuenta de usuario activa en la configuración de gcloud actual. Si necesitas cambiar la cuenta de usuario activa, ejecuta gcloud auth login.
-k|--key_file FILE PATH
Es el archivo de claves de una cuenta de servicio. Omite esta opción si no usas una cuenta de servicio.
-D|--output_dir DIR_PATH
Si no se especifica, la secuencia de comandos crea un directorio temporal en el que descarga archivos y configuraciones necesarios para instalar Anthos Service Mesh. Especifica la marca --output-dir para designar un directorio existente que se usará en su lugar. Una vez completado, el directorio especificado contiene los subdirectorios asm y istio-1.6.14-asm.2. El directorio asm contiene la configuración de la instalación. El directorio istio-1.6.14-asm.2 tiene el contenido extraído del archivo de instalación, que contiene istioctl, muestras y manifiestos.

Marcas

-e|--enable_apis
Permite que la secuencia de comandos habilite las API de Google que requiere Anthos Service Mesh. Sin esta marca, la secuencia de comandos se cierra si las API necesarias no están habilitadas. Para obtener una lista de las API que habilita la secuencia de comandos, consulta set_up_project.
-v|--verbose
Imprime comandos antes y después de la ejecución.
--dry_run
Imprime comandos, pero no los ejecutes.
--only_validate
Ejecuta la validación, pero no instales Anthos Service Mesh.
--disable_canonical_service
De forma predeterminada, la secuencia de comandos implementa el controlador del servicio canónico en tu clúster. Si no deseas que la secuencia de comandos implemente el controlador, especifica --disable_canonical_service. Para obtener más información, consulta Habilita o inhabilita el controlador del servicio canónico.
-h|--help
Muestra un mensaje de ayuda que describe las opciones y las marcas, y se cierra.

Implementa y vuelve a implementar las cargas de trabajo

La instalación no estará completa hasta que habilites la inserción automática de proxy de sidecar (inserción automática).

  • En las instalaciones nuevas, debes habilitar la inserción automática y reiniciar los pods de las cargas de trabajo que se estaban ejecutando en tu clúster antes de instalar Anthos Service Mesh.

  • Las migraciones de Istio siguen el proceso de actualización de plano de control dual (denominado “actualizaciones canary” en la documentación de Istio). Con una actualización del plano de control dual, la secuencia de comandos instala una versión nueva de istiod junto con el istiod existente. Luego, transfiere algunas de las cargas de trabajo a la versión nueva. Este proceso te permite supervisar el efecto de la versión nueva con un pequeño porcentaje de las cargas de trabajo antes de migrar todo el tráfico a la versión nueva.

  • Antes de implementar las cargas de trabajo nuevas, asegúrate de habilitar la incorporación del proxy de sidecar para que Anthos Service Mesh pueda supervisar y asegurar el tráfico.

Para habilitar la inserción automática, debes obtener la etiqueta de revisión que la secuencia de comandos aplicó a istiod y etiquetar los espacios de nombres con la etiqueta de revisión. Se proporcionan detalles en las siguientes secciones.

Obtén la etiqueta de revisión

La secuencia de comandos agrega una etiqueta de revisión en el formato istio.io/rev=asm-1614-2 a istiod. Para habilitar la inserción automática, agrega una etiqueta de revisión coincidente a tus espacios de nombres. El webhook de inyector de sidecar usa la etiqueta de revisión para asociar los sidecars insertados con una revisión istiod particular. Después de agregar la etiqueta, los pods existentes en el espacio de nombres deben reiniciarse para que se incorporen los archivos adicionales.

  1. Establece el contexto actual para kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID

  2. Muestra las etiquetas en istiod para obtener la etiqueta de revisión establecida por la secuencia de comandos:

    kubectl -n istio-system get pods -l app=istiod --show-labels

    El resultado del comando es similar al siguiente:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-1614-2-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-1614-2-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1614-2,istio=istiod,pod-template-hash=85d86774f7

    En el resultado, en la columna LABELS, observa el valor de la etiqueta de revisión istiod, que está después del prefijo istio.io/rev=. En este ejemplo, el valor es asm-1614-2, pero puedes tener un valor diferente.

    Para las migraciones, también observa el valor de la etiqueta de revisión de la versión de istiod anterior. Necesitas esto para borrar la versión anterior de istiod cuando termines la migración. En el resultado de ejemplo, el valor en la etiqueta de revisión de la versión anterior de istiod es default, pero puedes tener un valor diferente.

Habilita la inserción automática

Sigue estos pasos para las instalaciones y migraciones nuevas a fin de habilitar la inserción automática.

  1. Obtén el valor en la etiqueta de revisión para istiod.

  2. Agrega la etiqueta de revisión a un espacio de nombres y quita la etiqueta istio-injection. En el siguiente comando, cambia REVISION por el valor que coincide con la revisión en istiod.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite

  3. Reinicia los Pods para activar la reinserción:

    kubectl rollout restart deployment -n NAMESPACE

  4. Verifica que tus pods estén configurados para apuntar a la nueva versión de istiod.

    kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION

  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 para etiquetar el espacio de nombres y reiniciar los pods.

Para la migración, haz lo siguiente:

Completa la transición

Para las migraciones, debes quitar la versión anterior de istiod. Si estás seguro de que tu aplicación funciona como se esperaba, quita el plano de control anterior para completar la transición a la nueva versión.

  1. Obtén el valor en la etiqueta de revisión para la versión anterior de istiod.

  2. Borra la versión anterior de istiod. En el siguiente comando, reemplaza OLD_REVISION por la revisión del paso anterior.

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

Realiza una reversión a la versión anterior

Para las migraciones, si encontraste un problema cuando probaste tu aplicación con la versión nueva de istiod, sigue estos pasos para realizar una reversión a la versión anterior:

  1. Actualiza las cargas de trabajo que se insertarán con la versión anterior de istiod:

    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

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

    kubectl rollout restart deployment -n NAMESPACE

  3. Vuelve a implementar la versión anterior de istio-ingressgateway:

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

  4. Quita el nuevo istiod:

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

  5. Si no incluiste la marca --disable_canonical_service, la secuencia de comandos habilitó el controlador del servicio canónico. Sigue los pasos en Habilita o inhabilita el controlador del servicio canónico para inhabilitarla.

Visualiza los paneles de Anthos Service Mesh

Esta sección es aplicable solo si instalaste Anthos Service Mesh con el perfil de configuración asm-gcp. Si usaste el perfil asm-gcp-multiproject para instalar Anthos Service Mesh, los datos de telemetría no estarán disponibles en los paneles de Anthos Service Mesh en la consola de Google Cloud.

Después de implementar las cargas de trabajo en el clúster con los proxies de sidecar incorporados, puedes explorar las páginas de Anthos Service Mesh en la consola de Google Cloud para ver todas las funciones de observabilidad que ofrece Anthos Service Mesh. Ten en cuenta que los datos de telemetría toman uno o dos minutos en aparecer en la consola de Google Cloud después de implementar las cargas de trabajo.

El acceso a Anthos Service Mesh en la consola de Google Cloud se controla mediante la Administración de identidades y accesos (IAM). Para acceder a las páginas de Anthos Service Mesh, el propietario del proyecto debe otorgar a los usuarios la función de editor o visualizador del proyecto, o los roles más restrictivas que se describen en Controla el acceso a Anthos Service Mesh en la consola de Google Cloud.

  1. En la consola de Google Cloud, ve a Anthos Service Mesh.

    Ir a Anthos Service Mesh

  2. Selecciona el proyecto de Google Cloud en la lista desplegable de la barra de menú.

  3. Si tienes más de una malla de servicios, selecciona la malla en la lista desplegable Malla de servicios.

Para obtener más información, consulta Explora Anthos Service Mesh en la consola de Google Cloud.

Además de las páginas de Anthos Service Mesh, las métricas relacionadas con tus servicios (como la cantidad de solicitudes que recibe un servicio específico) se envían a Cloud Monitoring, donde aparecen en el Explorador de métricas.

Para ver las métricas, sigue estos pasos:

  1. En la consola de Google Cloud, ve a la página Monitoring.

    Ir a Monitoring

  2. Selecciona Recursos > Explorador de métricas.

Para obtener una lista completa de las métricas, consulta Métricas de Istio en la documentación de Cloud Monitoring.

Registra tu clúster

Debes registrar tu clúster en la flota del proyecto para obtener acceso a la interfaz de usuario unificada en la consola de Google Cloud. Una flota proporciona una forma unificada de ver y administrar los clústeres y sus cargas de trabajo, incluidos los clústeres fuera de Google Cloud.

A fin de obtener información para registrar tu clúster, consulta Registra clústeres en la flota.

Información sobre la secuencia de comandos

Aunque descargues la secuencia de comandos desde una ubicación segura de Cloud Source Repositories, la secuencia de comandos también está disponible en GitHub para que puedas ver lo que hace antes de descargarla. La secuencia de comandos valida que tu clúster cumpla con los requisitos y automatiza todos los pasos que harías de manera manual en Instala Anthos Service Mesh en GKE.

validate_args y validate_dependencies

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF
 
validate_dependencies() {
  validate_cli_dependencies

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_expected_control_plane
  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  fi
  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

Las funciones validate_args y validate_dependencies realizan las siguientes funciones:

  • Verifican que estén instaladas todas las herramientas necesarias.
  • Verifican que el ID del proyecto, el nombre del clúster y la ubicación del clúster que ingresaste como valores de parámetros sean válidos.
  • Garantizan que el clúster cumpla con el tipo de máquina mínimo requerido y la cantidad de nodos.

set_up_project

Si incluiste la marca --enable_apis, la función set_up_project habilita las API necesarias:

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  add_cluster_labels
  enable_workload_identity

  # this is project scope but requires workload identity
  if [[ "${CA}" = "mesh_ca" ]]; then
    init_meshca
  fi

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

La función set_up_cluster realiza las siguientes actualizaciones en el clúster:

  • Habilita Workload Identity, que es la forma recomendada para acceder de forma segura a los servicios de Google Cloud desde las aplicaciones de GKE.

  • Habilita Cloud Monitoring y Cloud Logging en GKE.

  • Configura la etiqueta mesh_id en el clúster, que se requiere para que las métricas se muestren en las páginas de Anthos Service Mesh en la consola de Google Cloud.

  • Establece una etiqueta como asmv=asm-1614-2 para que puedas saber si la secuencia de comandos modificó el clúster.

  • Vincula la cuenta de servicio o el usuario de GCP que ejecuta la secuencia de comandos a la función de administrador del clúster en tu clúster.

install_asm

install_asm(){

  local CA_OPT
  CA_OPT=""
  if [[ "${CA}" = "citadel" ]]; then
    CA_OPT="-citadel"
  fi

  info "Configuring kpt package..."
  run kpt cfg set asm gcloud.container.cluster "${CLUSTER_NAME}"
  run kpt cfg set asm gcloud.core.project "${PROJECT_ID}"
  run kpt cfg set asm gcloud.project.environProjectNumber "${PROJECT_NUMBER}"
  run kpt cfg set asm gcloud.compute.location "${CLUSTER_LOCATION}"
  run kpt cfg set asm anthos.servicemesh.rev "${REVISION_LABEL}"
  if [[ -n "${_CI_ASM_IMAGE_LOCATION}" ]]; then
    run kpt cfg set asm anthos.servicemesh.hub "${_CI_ASM_IMAGE_LOCATION}"
    run kpt cfg set asm anthos.servicemesh.tag "${RELEASE}"
  fi

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST}"
  if [[  -f "$CUSTOM_OVERLAY" ]]; then
    PARAMS="${PARAMS} -f ${CUSTOM_OVERLAY}"
  fi
  PARAMS="${PARAMS} --set revision=${REVISION_LABEL}"
  PARAMS="${PARAMS} -c ${KUBECONFIG}"

  info "Installing ASM control plane..."
  # shellcheck disable=SC2086
  retry 5 run ./"${ISTIOCTL_REL_PATH}" install $PARAMS

  # Prevent the stderr buffer from ^ messing up the terminal output below
  sleep 1
  info "...done!"

  if ! does_istiod_exist; then
    info "Installing validation webhook fix..."
    retry 3 run kubectl apply -f "${VALIDATION_FIX_SERVICE}"
  fi

  if [[ "$DISABLE_CANONICAL_SERVICE" -ne 1 ]]; then
    info "Installing ASM CanonicalService controller in asm-system namespace..."
    retry 3 run kubectl apply -f asm/canonical-service/controller.yaml
    info "Waiting for deployment..."
    retry 3 run kubectl wait --for=condition=available --timeout=600s \
        deployment/canonical-service-controller-manager -n asm-system
    info "...done!"
  fi

  outro
}

La función install_asm realiza lo siguiente:

  • Descarga el paquete kpt en un directorio temporal.
  • Ejecuta los métodos set de kpt para configurar el archivo istio-operator.yaml.
  • Instala Anthos Service Mesh.

Diferencias con la secuencia de comandos 1.7

Secuencia de comandos 1.7: Secuencia de comandos 1.6:
Admite actualizaciones. No realiza actualizaciones.
Admite migraciones desde Istio 1.6 y Istio 1.7. Admite la migración desde Istio 1.6.
--print_config
Proporciona la configuración que usaste cuando realizaste la instalación mediante la secuencia de comandos install_asm. Esta marca te facilita volver a instalar la misma versión de Anthos Service Mesh (que la secuencia de comandos no permite) con la misma configuración que usaste cuando realizaste la instalación antes.		 No disponible
--custom_overlay
Permite varios archivos de superposición.		 --custom_overlay
Solo permite un archivo de superposición.
--option
Extrae archivos de superposición del paquete asm de GitHub. 		No disponible
Admite una CA personalizada con las siguientes opciones:

--ca_cert
--ca_key
--root_cert
--cert_chain

No disponible