Taller de Anthos Service Mesh: guía del lab

1. TALLER DE ALPHA

NOTA IMPORTANTE: ESTE ES UN TALLER EN VERSIÓN ALPHA Y ESTÁ DESTINADO ESTRICTAMENTE A SER UNA CAPACITACIÓN EN EL AULA DIRIGIDA POR UN INSTRUCTOR.

Vínculo al codelab del taller: bit.ly/asm-workshop

2. Descripción general

Diagrama de arquitectura

Este taller es una experiencia práctica y envolvente que explica cómo configurar servicios distribuidos a nivel global en GCP en producción. Las principales tecnologías que se usan son Google Kubernetes Engine (GKE) para el procesamiento y la malla de servicios de Istio para crear conectividad segura, observabilidad y modelado avanzado del tráfico. Todas las prácticas y herramientas que se usan en este taller son las que usarías en producción.

Temario

• Módulo 0: Introducción y configuración de la plataforma
• Introducción y arquitectura
• Introducción a Service Mesh y a Istio/ASM
• Lab: Infrastructure Setup: User workflow (Lab: Configuración de la infraestructura: flujo de trabajo del usuario)
• Break
• QnA
• Módulo 1: Instala, protege y supervisa aplicaciones con ASM
• Modelo de repo: Explicación de los repositorios de infraestructura y Kubernetes
• Lab: Implementa una aplicación de muestra
• Servicios distribuidos y observabilidad
• Almuerzo
• Lab: Observabilidad con Stackdriver
• QNA
• Módulo 2: DevOps: Lanzamientos de versiones canary, políticas y RBAC
• Descubrimiento de servicios y seguridad o políticas de varios clústeres
• Lab: Mutual TLS
• Implementaciones de versiones canary
• Lab: Implementaciones de versiones canary
• Balanceo de cargas global seguro entre varios clústeres
• Break
• Lab: Authorization Policy (Lab: Política de autorización)
• QNA
• Módulo 3: Operaciones de infraestructura: Actualizaciones de la plataforma
• Componentes básicos de servicios distribuidos
• Lab: Infrastructure Scaling (Lab: Escalabilidad de la infraestructura)
• Próximos pasos

Presentaciones

Puedes encontrar las diapositivas de este taller en el siguiente vínculo:

Diapositivas del taller de ASM

Requisitos previos

Antes de continuar con este taller, debes cumplir con los siguientes requisitos:

1. Un nodo de organización de GCP
2. Un ID de cuenta de facturación (tu usuario debe ser administrador de facturación en esta cuenta de facturación)
3. Rol de IAM de administrador de la organización a nivel de la organización para tu usuario

3. Configuración de la infraestructura: Flujo de trabajo del administrador

Un administrador que crea el taller realiza los pasos de esta sección.

Si eres un usuario que realiza el taller, ve a la siguiente sección etiquetada como Infrastructure Setup - User Workflow.

Explicación del script del taller de arranque

Se usa una secuencia de comandos llamada bootstrap_workshop.sh para configurar el entorno inicial del taller. Puedes usar este script para configurar un solo entorno para ti o varios entornos para varios usuarios en caso de que impartas este taller como capacitación para varios usuarios.

La secuencia de comandos del taller de arranque requiere las siguientes entradas:

• Nombre de la organización (por ejemplo, yourcompany.com): Es la organización en la que crearás entornos para el taller.
• ID de facturación (por ejemplo, 12345-12345-12345): Este ID de facturación se usa para facturar todos los recursos que se usaron durante el taller.
• Número de taller (por ejemplo, 01): Es un número de dos dígitos. Se usa en caso de que realices varios talleres en un día y quieras hacer un seguimiento de cada uno por separado. Los números de taller también se usan para derivar los IDs de los proyectos. Tener números de taller separados facilita garantizar que obtengas IDs de proyecto únicos cada vez. Además del número de taller, la fecha actual (con el formato YYMMDD) también se usa para los IDs de proyecto. La combinación de la fecha y el número de taller proporciona IDs de proyecto únicos.
• Número de usuario inicial (por ejemplo, 1): Este número indica el primer usuario del taller. Por ejemplo, si quieres crear un taller para 10 usuarios, puedes establecer el número de usuario inicial en 1 y el número de usuario final en 10.
• Número de usuario final (por ejemplo, 10): Este número indica el último usuario del taller. Por ejemplo, si quieres crear un taller para 10 usuarios, puedes establecer el número de usuario inicial en 1 y el número de usuario final en 10. Si configuras un solo entorno (para ti, por ejemplo), haz que el número de usuario inicial y final sea el mismo. Esto creará un solo entorno.

Además de la fecha y el número de taller, los números de usuario inicial y final también se incorporan en los IDs de proyecto. Los IDs de usuario (para los usuarios que realizan el taller) se derivan del número de usuario inicial y final. Los IDs de usuario se explican en la sección llamada User schema and permissions performing the workshop.

• Bucket de GCS del administrador (por ejemplo, my-gcs-bucket-name): Se usa un bucket de GCS para almacenar información relacionada con el taller. El script cleanup_workshop.sh usa esta información para borrar correctamente todos los recursos creados durante el script del taller de arranque. Los administradores que creen talleres deben tener permisos de lectura y escritura para este bucket.

La secuencia de comandos del taller de inicio usa los valores proporcionados anteriormente y actúa como una secuencia de comandos de wrapper que llama a la secuencia de comandos setup-terraform-admin-project.sh. La secuencia de comandos setup-terraform-admin-project.sh crea el entorno del taller para un solo usuario.

Se requieren permisos de administrador para iniciar el taller

En este taller, hay dos tipos de usuarios. Un ADMIN_USER, que crea y borra recursos para este taller. El segundo es MY_USER, quien realiza los pasos en el taller. MY_USER solo tiene acceso a sus propios recursos. ADMIN_USER tiene acceso a todos los parámetros de configuración del usuario. Si creas esta configuración para ti, ADMIN_USER y MY_USER son iguales. Si eres instructor y creas este taller para varios estudiantes, tus ADMIN_USER y MY_USER serán diferentes.

Se requieren los siguientes permisos a nivel de la organización para ADMIN_USER:

• Propietario: Permiso de propietario del proyecto para todos los proyectos de la organización.
• Administrador de carpetas: Puede crear y borrar carpetas en la organización. Cada usuario obtiene una sola carpeta con todos sus recursos dentro del proyecto.
• Administrador de la organización
• Creador de proyectos: Capacidad para crear proyectos en la organización
• Eliminador de proyectos: Capacidad para borrar proyectos en la organización.
• Administrador de IAM de proyecto: Capacidad para crear reglas de IAM en todos los proyectos de la organización

Además de estos, ADMIN_USER también debe ser el administrador de facturación del ID de facturación que se usa para el taller.

Esquema de usuario y permisos para realizar el taller

Si planeas crear este taller para usuarios (que no sean tú) de tu organización, debes seguir un esquema de nombres de usuario específico para MY_USERs. Durante la ejecución del script bootstrap_workshop.sh, debes proporcionar un número de usuario inicial y uno final. Estos números se usan para crear los siguientes nombres de usuario:

• user<3 digit user number>@<organization_name>

Por ejemplo, si ejecutas la secuencia de comandos del taller de inicio con el número de usuario inicial 1 y el número de usuario final 3, en tu organización llamada tuempresa.com, se crearán los entornos del taller para los siguientes usuarios:

• [e-mail]
• [e-mail]
• [e-mail]

A estos nombres de usuario se les asignan roles de propietario del proyecto para sus proyectos específicos creados durante el script setup_terraform_admin_project.sh. Debes cumplir con este esquema de nombres de usuario cuando uses la secuencia de comandos de arranque. Consulta cómo agregar varios usuarios a la vez en G Suite.

Herramientas necesarias para el taller

Este taller está diseñado para iniciarse desde Cloud Shell. Para este taller, se requieren las siguientes herramientas.

• gcloud (versión >= 270)
• kubectl
• sed (funciona con sed en Cloud Shell/Linux y no en macOS)
• git (asegúrate de que esté actualizado)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

Todas las herramientas, excepto kustomize, ya están instaladas de forma predeterminada en Cloud Shell. Si kustomize no está instalado, instálalo con el script de bash que se proporciona en el vínculo anterior y asegúrate de que el archivo binario de kustomize esté en tu PATH. Para confirmarlo, ejecuta el comando kustomize en Cloud Shell.

Configura el taller para ti (configuración de un solo usuario)

1. Abre Cloud Shell y realiza todas las acciones que se indican a continuación en Cloud Shell. Haz clic en el siguiente vínculo.

CLOUD SHELL

2. Verifica que accediste a gcloud con el usuario administrador previsto.

gcloud config list
 

3. Crea un WORKDIR y clona el repo del taller.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

4. Define el nombre de tu organización, el ID de facturación, el número de taller y un bucket de GCS de administrador para usar en el taller. Revisa los permisos necesarios para configurar el taller en las secciones anteriores.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<ADMIN_BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

5. Ejecuta la secuencia de comandos bootstrap_workshop.sh. Esta secuencia de comandos puede tardar unos minutos en completarse:

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --set-up-for-admin 
 

Ten en cuenta que no es necesario que definas la cantidad de usuarios inicial y final, ya que estás configurando esto para ti.

Una vez que se completa la secuencia de comandos bootstrap_workshop.sh, se crea una carpeta de GCP para cada usuario de la organización. Dentro de la carpeta, se crea un proyecto de administrador de Terraform. El proyecto de administrador de Terraform se usa para crear el resto de los recursos de GCP necesarios para este taller. Habilitarás las APIs obligatorias en el proyecto de administrador de Terraform. Usas Cloud Build para aplicar planes de Terraform. Le otorgas a la cuenta de servicio de Cloud Build los roles de IAM adecuados para que pueda crear recursos en GCP. Por último, configurarás un backend remoto en un bucket de Google Cloud Storage (GCS) para almacenar los estados de Terraform de todos los recursos de GCP.

Para ver las tareas de Cloud Build en el proyecto de administrador de Terraform, necesitas el ID del proyecto de administrador de Terraform. Esta información se almacena en el archivo vars/vars.sh de tu directorio asm. Este directorio solo se conserva si configuras el taller para ti como administrador.

6. Ejecuta el archivo de variables para establecer las variables de entorno

echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
source $WORKDIR/asm/vars/vars.sh 
 

Configura el taller para varios usuarios (configuración multiusuario)

7. Abre Cloud Shell y realiza todas las acciones que se indican a continuación en Cloud Shell. Haz clic en el siguiente vínculo.

CLOUD SHELL

8. Verifica que accediste a gcloud con el usuario administrador previsto.

gcloud config list
 

9. Crea un WORKDIR y clona el repo del taller.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

10. Define el nombre de tu organización, el ID de facturación, el número de taller, el número de usuarios inicial y final, y un bucket de GCS de administrador para usar en el taller. Revisa los permisos necesarios para configurar el taller en las secciones anteriores.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

11. Ejecuta la secuencia de comandos bootstrap_workshop.sh. Esta secuencia de comandos puede tardar unos minutos en completarse:

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --start-user-num ${START_USER_NUMBER} --end-user-num ${END_USER_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET}
 

12. Obtén el archivo workshop.txt del bucket de GCS del administrador para recuperar los IDs del proyecto de Terraform.

export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .
 

4. Preparación y configuración del lab

Los usuarios que realizan el taller deben comenzar aquí. Realiza todos los pasos desde una ventana de INCOGNITO en Chrome o Firefox.

Elige tu ruta de lab

Los labs de este taller se pueden realizar de dos maneras:

• La forma de "guiones interactivos de vía rápida y sencilla"
• La forma de "copiar y pegar manualmente cada instrucción"

El método de secuencias de comandos de pista rápida te permite ejecutar una sola secuencia de comandos interactiva para cada lab que te guía por el lab ejecutando automáticamente los comandos correspondientes. Los comandos se ejecutan en lotes con explicaciones concisas de cada paso y lo que logran. Después de cada lote, se te pedirá que pases al siguiente lote de comandos. De esta manera, puedes realizar los labs a tu propio ritmo. Las secuencias de comandos de la pista rápida son idempotentes, lo que significa que puedes ejecutarlas varias veces y obtener el mismo resultado.

Las secuencias de comandos de la pista rápida aparecerán en la parte superior de cada lab en un cuadro verde, como se muestra a continuación.

GUION DE PISTA RÁPIDA

${WORKDIR}/asm/fasttrack_scripts/<name_of_script>.sh

El método de copiar y pegar es la forma tradicional de copiar y pegar bloques de comandos individuales con explicaciones de los comandos. Este método solo se debe ejecutar una vez. No hay garantía de que volver a ejecutar comandos en este método te proporcione los mismos resultados.

Cuando realices los labs, elige uno de los dos métodos.

Después de elegir un método y realizar los pasos correspondientes, no realices los pasos del otro método.

Configuración de Fast Track Script

Después de completar la secuencia de comandos de la pista rápida, habrás terminado ese lab. No realices los pasos que se indican en las instrucciones del lab de copiar y pegar.

Obtén información del usuario

Este taller se realiza con una cuenta de usuario temporal (o una cuenta de laboratorio) creada por el administrador del taller. La cuenta de lab es propietaria de todos los proyectos del taller. El administrador del taller proporciona las credenciales de la cuenta del lab (nombre de usuario y contraseña) al usuario que realiza el taller. Todos los proyectos del usuario tienen como prefijo el nombre de usuario de la cuenta del lab. Por ejemplo, para la cuenta del lab [e-mail], el ID del proyecto de administrador de Terraform sería user001-200131-01-tf-abcde, y así sucesivamente para el resto de los proyectos. Cada usuario debe acceder con la cuenta de lab que proporciona el administrador del taller y realizar el taller con esa cuenta.

Revisa tu correo electrónico corporativo (el mismo que usaste para registrarte en el taller). Deberías haber recibido un correo electrónico del administrador del taller con las credenciales de tu cuenta de lab (es decir, nombre de usuario y contraseña). El correo electrónico se ve así.

1. Haz clic en el siguiente vínculo para abrir Cloud Shell.

CLOUD SHELL

2. Accede con las credenciales de la cuenta del lab (no accedas con tu cuenta corporativa ni personal). La cuenta de lab se ve como userXYZ@<workshop_domain>.com.
3. Como se trata de una cuenta nueva, se te solicitará que aceptes las Condiciones del Servicio de Google. Haz clic en Aceptar.

4. En la siguiente pantalla, selecciona la casilla de verificación para aceptar las Condiciones del Servicio de Google y haz clic en Start Cloud Shell.

En este paso, se aprovisiona una pequeña VM de Linux Debian para que la uses y accedas a los recursos de GCP. Cada cuenta obtiene una VM de Cloud Shell. Acceder con la cuenta del lab te aprovisiona y te permite acceder con las credenciales de la cuenta del lab. Además de Cloud Shell, también se aprovisiona un editor de código que facilita la edición de archivos de configuración (Terraform, YAML, etc.). De forma predeterminada, la pantalla de Cloud Shell se divide en el entorno de shell de Cloud Shell (en la parte inferior) y el editor de Cloud Code (en la parte superior). Los íconos de lápiz y de símbolo del sistema en la esquina superior derecha te permiten alternar entre los dos (símbolo del sistema y editor de código). También puedes arrastrar la barra separadora central (hacia arriba o hacia abajo) y cambiar el tamaño de cada ventana de forma manual. 5. Crea un WORKDIR para este taller. El WORKDIR es una carpeta desde la que realizarás todos los labs de este taller. Ejecuta los siguientes comandos en Cloud Shell para crear el directorio de trabajo.

mkdir -p ${HOME}/asm-workshop
cd ${HOME}/asm-workshop
export WORKDIR=`pwd` 
 

6. Exporta el usuario de la cuenta del lab como una variable para usarla en este taller. Esta es la misma cuenta con la que accediste a Cloud Shell.

export MY_USER=<LAB ACCOUNT EMAIL PROVIDED BY THE WORKSHOP ADMIN>
# For example export MY_USER=[e-mail] 
 

Nota: Si eres administrador y configuraste el taller para ti con las marcas "-sufa" o "–setup-for-admin", establece MY_USER en el correo electrónico de la cuenta de GCP que usaste para crear los proyectos del taller.

7. Ejecuta los siguientes comandos para hacer eco de las variables WORKDIR y MY_USER y asegurarte de que ambas estén configuradas correctamente.

echo "WORKDIR set to ${WORKDIR}" && echo "MY_USER set to ${MY_USER}"
 

8. Clona el repo del taller.

git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git ${WORKDIR}/asm
 

5. Configuración de la infraestructura: Flujo de trabajo del usuario

Objetivo: Verificar la infraestructura y la instalación de Istio

• Instala herramientas de taller
• Clona el repo del taller
• Verifica la instalación de Infrastructure
• Verifica la instalación de k8s-repo
• Verifica la instalación de Istio

GUION DE PISTA RÁPIDA

Si eliges este método, ejecuta la siguiente secuencia de comandos para completar este lab.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-setup-user-workflow.sh

Una vez que se complete la secuencia de comandos, obtén tu bashrc para actualizar las variables en tu sesión de Cloud Shell.

source ${HOME}/.bashrc

Instrucciones del lab sobre el método de copiar y pegar

IMPORTANTE: Si ya completaste la secuencia de comandos de la pista rápida para este lab, no realices el método de copiar y pegar que se indica a continuación**.**

Obtén información del usuario

El administrador que configura el taller debe proporcionar la información de nombre de usuario y contraseña al usuario. Todos los proyectos del usuario tendrán como prefijo el nombre de usuario. Por ejemplo, para el usuario [e-mail], el ID del proyecto de administrador de Terraform sería user001-200131-01-tf-abcde, y así sucesivamente para el resto de los proyectos. Cada usuario solo tiene acceso a su propio entorno de taller.

Herramientas necesarias para el taller

Este taller está diseñado para iniciarse desde Cloud Shell. Para este taller, se requieren las siguientes herramientas.

Todas las herramientas, excepto kustomize y pv, ya están instaladas de forma predeterminada en Cloud Shell. A continuación, encontrarás las instrucciones para instalar ambos.

• gcloud (versión >= 270)
• kubectl
• sed (funciona con sed en Cloud Shell/Linux y no en macOS)
• git (asegúrate de que esté actualizado)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

Accede al proyecto de administrador de Terraform

Una vez que se completa la secuencia de comandos bootstrap_workshop.sh, se crea una carpeta de GCP para cada usuario de la organización. Dentro de la carpeta, se crea un proyecto de administrador de Terraform. El proyecto de administrador de Terraform se usa para crear el resto de los recursos de GCP necesarios para este taller. La secuencia de comandos setup-terraform-admin-project.sh habilita las APIs necesarias en el proyecto de administrador de Terraform. Cloud Build se usa para aplicar planes de Terraform. A través de la secuencia de comandos, le otorgas a la cuenta de servicio de Cloud Build los roles de IAM adecuados para que pueda crear recursos en GCP. Por último, se configura un backend remoto en un bucket de Google Cloud Storage (GCS) para almacenar los estados de Terraform de todos los recursos de GCP.

Para ver las tareas de Cloud Build en el proyecto de administrador de Terraform, necesitas el ID del proyecto de administrador de Terraform. Este se almacena en el bucket de GCS del administrador que se especificó en el script de arranque. Si ejecutas la secuencia de comandos de arranque para varios usuarios, todos los IDs de proyectos de administrador de Terraform estarán en el bucket de GCS.

Este taller está diseñado para realizarse en Cloud Shell y la consola de Cloud. Realiza los siguientes pasos en una ventana de INCOGNITO, ya que accederás con un nombre de usuario y una contraseña independientes.

1. Haz clic en el siguiente vínculo para abrir Cloud Shell (si aún no lo abriste en la sección Preparación y configuración del lab).

CLOUD SHELL

2. Instala kustomize (si aún no lo hiciste) en la carpeta $HOME/bin y agrega la carpeta $HOME/bin a $PATH.

mkdir -p $HOME/bin
cd $HOME/bin
curl -s "https://raw.githubusercontent.com/\
kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
cd $HOME
export PATH=$PATH:${HOME}/bin
echo "export PATH=$PATH:$HOME/bin" >> $HOME/.bashrc
 

3. Instala pv y muévelo a $HOME/bin/pv.

sudo apt-get update && sudo apt-get -y install pv
sudo mv /usr/bin/pv ${HOME}/bin/pv
 

4. Actualiza el símbolo del sistema de Bash.

cp $WORKDIR/asm/scripts/krompt.bash $HOME/.krompt.bash
echo "export PATH=\$PATH:\$HOME/bin" >> $HOME/.asm-workshop.bash
echo "source $HOME/.krompt.bash" >> $HOME/.asm-workshop.bash

alias asm-init='source $HOME/.asm-workshop.bash' >> $HOME/.bashrc
echo "source $HOME/.asm-workshop.bash" >> $HOME/.bashrc
source $HOME/.bashrc
 

5. Verifica que accediste a gcloud con la cuenta de usuario deseada.

echo "Check logged in user output from the next command is $MY_USER"
gcloud config list account --format=json | jq -r .core.account
 

6. Para obtener el ID de tu proyecto de administrador de Terraform, ejecuta el siguiente comando:

export TF_ADMIN=$(gcloud projects list | grep tf- | awk '{ print $1 }')
echo $TF_ADMIN
 

7. Todos los recursos asociados con el taller se almacenan como variables en un archivo vars.sh que se encuentra en un bucket de GCS en el proyecto de administrador de Terraform. Obtén el archivo vars.sh para tu proyecto de administrador de Terraform.

mkdir $WORKDIR/asm/vars
gsutil cp gs://$TF_ADMIN/vars/vars.sh $WORKDIR/asm/vars/vars.sh
echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
 

8. Haz clic en el vínculo que se muestra para abrir la página de Cloud Build del proyecto de administrador de Terraform y verifica que la compilación se haya completado correctamente.

source $WORKDIR/asm/vars/vars.sh
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

Si es la primera vez que accedes a la consola de Cloud, acepta las Condiciones del Servicio de Google.

9. Ahora que estás en la página Cloud Build, haz clic en el vínculo History en la navegación de la izquierda y, luego, en la compilación más reciente para ver los detalles de la aplicación inicial de Terraform. Los siguientes recursos se crean como parte de la secuencia de comandos de Terraform. También puedes consultar el diagrama de arquitectura anterior.

• 4 proyectos de GCP en la organización La cuenta de facturación proporcionada está asociada a cada proyecto.
• Un proyecto es network host project para la VPC compartida. No se crean otros recursos en este proyecto.
• Un proyecto es ops project, que se usa para los clústeres de GKE del plano de control de Istio.
• Los dos proyectos representan a dos equipos de desarrollo diferentes que trabajan en sus respectivos servicios.
• Se crean dos clústeres de GKE en cada uno de los tres proyectos ops, dev1 y dev2.
• Se crea un repo de CSR llamado k8s-repo que contiene seis carpetas para los archivos de manifiestos de Kubernetes. Una carpeta por clúster de GKE Este repo se usa para implementar manifiestos de Kubernetes en los clústeres de forma GitOps.
• Se crea un activador de Cloud Build para que, cada vez que haya una confirmación en la rama principal de k8s-repo, se implementen los manifiestos de Kubernetes en los clústeres de GKE desde sus respectivas carpetas.

La secuencia de comandos de Terraform tarda entre 40 y 50 minutos.

10. Una vez que se complete la compilación en terraform admin project, se iniciará otra compilación en el proyecto de operaciones. Haz clic en el vínculo que se muestra para abrir la página de Cloud Build de ops project y verifica que Cloud Build de k8s-repo se haya completado correctamente.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

Nota: Esta compilación debe completarse antes de que puedas verificar la instalación de Istio.

Verifica la instalación

11. Crea archivos kubeconfig para todos los clústeres. Ejecuta la siguiente secuencia de comandos.

$WORKDIR/asm/scripts/setup-gke-vars-kubeconfig.sh
 

Este script crea un archivo kubeconfig nuevo en la carpeta gke llamado kubemesh.

12. Cambia la variable KUBECONFIG para que apunte al nuevo archivo kubeconfig.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

13. Agrega las variables vars.sh y KUBECONFIG a .bashrc en Cloud Shell para que se obtengan cada vez que se reinicie Cloud Shell.

echo "source ${WORKDIR}/asm/vars/vars.sh" >> $HOME/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> $HOME/.bashrc
 

14. Enumera los contextos de tu clúster. Deberías ver seis clústeres.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_tf05-01-ops_us-central1_gke-asm-2-r2-prod
gke_tf05-01-ops_us-west1_gke-asm-1-r1-prod
gke_tf05-02-dev1_us-west1-a_gke-1-apps-r1a-prod
gke_tf05-02-dev1_us-west1-b_gke-2-apps-r1b-prod
gke_tf05-03-dev2_us-central1-a_gke-3-apps-r2a-prod
gke_tf05-03-dev2_us-central1-b_gke-4-apps-r2b-prod

Verifica la instalación de Istio

15. Verifica que Istio esté instalado en ambos clústeres. Para ello, comprueba que todos los Pods estén en ejecución y que los trabajos se hayan completado.

kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-z9f98                  1/1     Running   0          6m21s
istio-citadel-568747d88-qdw64             1/1     Running   0          6m26s
istio-egressgateway-8f454cf58-ckw7n       1/1     Running   0          6m25s
istio-galley-6b9495645d-m996v             2/2     Running   0          6m25s
istio-ingressgateway-5df799fdbd-8nqhj     1/1     Running   0          2m57s
istio-pilot-67fd786f65-nwmcb              2/2     Running   0          6m24s
istio-policy-74cf89cb66-4wrpl             2/2     Running   1          6m25s
istio-sidecar-injector-759bf6b4bc-mw4vf   1/1     Running   0          6m25s
istio-telemetry-77b6dfb4ff-zqxzz          2/2     Running   1          6m24s
istio-tracing-cd67ddf8-n4d7k              1/1     Running   0          6m25s
istiocoredns-5f7546c6f4-g7b5c             2/2     Running   0          6m39s
kiali-7964898d8c-5twln                    1/1     Running   0          6m23s
prometheus-586d4445c7-xhn8d               1/1     Running   0          6m25s

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-2s8k4                  1/1     Running   0          59m
istio-citadel-568747d88-87kdj             1/1     Running   0          59m
istio-egressgateway-8f454cf58-zj9fs       1/1     Running   0          60m
istio-galley-6b9495645d-qfdr6             2/2     Running   0          59m
istio-ingressgateway-5df799fdbd-2c9rc     1/1     Running   0          60m
istio-pilot-67fd786f65-nzhx4              2/2     Running   0          59m
istio-policy-74cf89cb66-4bc7f             2/2     Running   3          59m
istio-sidecar-injector-759bf6b4bc-grk24   1/1     Running   0          59m
istio-telemetry-77b6dfb4ff-6zr94          2/2     Running   4          60m
istio-tracing-cd67ddf8-grs9g              1/1     Running   0          60m
istiocoredns-5f7546c6f4-gxd66             2/2     Running   0          60m
kiali-7964898d8c-nhn52                    1/1     Running   0          59m
prometheus-586d4445c7-xr44v               1/1     Running   0          59m

16. Asegúrate de que Istio esté instalado en ambos clústeres de dev1. Solo Citadel, sidecar-injector y coredns se ejecutan en los clústeres dev1. Comparten un plano de control de Istio que se ejecuta en el clúster ops-1.

kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
 

17. Asegúrate de que Istio esté instalado en ambos clústeres de dev2. Solo Citadel, sidecar-injector y coredns se ejecutan en los clústeres dev2. Comparten un plano de control de Istio que se ejecuta en el clúster ops-2.

kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

Verifica el descubrimiento de servicios para los planos de control compartidos

18. De manera opcional, verifica que los secretos se hayan implementado.

kubectl --context ${OPS_GKE_1} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_2} get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

For OPS_GKE_1:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      8m7s
gke-2-apps-r1b-prod   Opaque   1      8m7s
gke-3-apps-r2a-prod   Opaque   1      44s
gke-4-apps-r2b-prod   Opaque   1      43s

For OPS_GKE_2:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      40s
gke-2-apps-r1b-prod   Opaque   1      40s
gke-3-apps-r2a-prod   Opaque   1      8m4s
gke-4-apps-r2b-prod   Opaque   1      8m4s

En este taller, usarás una sola VPC compartida en la que se crearán todos los clústeres de GKE. Para descubrir servicios en todos los clústeres, usa los archivos kubeconfig (para cada uno de los clústeres de aplicaciones) creados como secretos en los clústeres de operaciones. Pilot usa estos secretos para descubrir servicios consultando el servidor de la API de Kube de los clústeres de aplicaciones (autenticado a través de los secretos anteriores). Verás que ambos clústeres de operaciones pueden autenticarse en todos los clústeres de aplicaciones con los secretos creados por kubeconfig. Los clústeres de operaciones pueden descubrir servicios automáticamente con los archivos kubeconfig como método secreto. Esto requiere que el Pilot en los clústeres de operaciones tenga acceso al servidor de la API de Kube de todos los demás clústeres. Si Pilot no puede acceder a los servidores de la API de Kube, deberás agregar manualmente los servicios remotos como ServiceEntries. Puedes considerar los ServiceEntries como entradas DNS en tu registro de servicio. Los ServiceEntry definen un servicio con un nombre de DNS completamente calificado ( FQDN) y una dirección IP en la que se puede acceder a él. Consulta los documentos sobre Istio Multicluster para obtener más información.

6. Explicación del repositorio de infraestructura

Compilación de infraestructura de Cloud Build

Los recursos de GCP para el taller se compilan con Cloud Build y un infrastructure repo de CSR. Acabas de ejecutar una secuencia de comandos de arranque (ubicada en scripts/bootstrap_workshop.sh) desde tu terminal local. La secuencia de comandos de inicio crea una carpeta de GCP, un proyecto de administrador de Terraform y los permisos de IAM adecuados para la cuenta de servicio de Cloud Build. El proyecto de administrador de Terraform se usa para almacenar estados, registros y secuencias de comandos varios de Terraform. Contiene los repositorios de infrastructure y k8s_repo de la RSE. Estos repositorios se explican en detalle en la siguiente sección. No se compilan otros recursos del taller en el proyecto de administrador de Terraform. La cuenta de servicio de Cloud Build en el proyecto de administrador de Terraform se usa para compilar recursos para el taller.

Se usa un archivo cloudbuild.yaml ubicado en la carpeta infrastructure para compilar recursos de GCP para el taller. Crea una imagen de compilador personalizada con todas las herramientas necesarias para crear recursos de GCP. Estas herramientas incluyen el SDK de gcloud, Terraform y otras utilidades como Python, Git, jq, etcétera. La imagen del compilador personalizado ejecuta terraform plan y apply para cada recurso. Los archivos de Terraform de cada recurso se encuentran en carpetas separadas (se brindan detalles en la siguiente sección). Los recursos se compilan de a uno y en el orden en que se compilarían normalmente (por ejemplo, un proyecto de GCP se compila antes de que se creen los recursos en el proyecto). Revisa el archivo cloudbuild.yaml para obtener más detalles.

Cloud Build se activa cada vez que se confirma un cambio en el repositorio infrastructure. Cualquier cambio que se realice en la infraestructura se almacena como infraestructura como código (IaC) y se confirma en el repo. El estado de tu taller siempre se almacena en este repo.

Estructura de carpetas: equipos, entornos y recursos

El repo de infraestructura configura los recursos de infraestructura de GCP para el taller. Está estructurada en carpetas y subcarpetas. Las carpetas base dentro del repo representan los team que poseen recursos específicos de GCP. La siguiente capa de carpetas representa el environment específico del equipo (por ejemplo, dev, stage, prod). La siguiente capa de carpetas dentro del entorno representa el resource específico (por ejemplo, host_project, gke_clusters, etc.). Las secuencias de comandos y los archivos de Terraform necesarios se encuentran en las carpetas de recursos.

En este taller, se representan los siguientes cuatro tipos de equipos:

1. infrastructure: Representa al equipo de infraestructura de nube. Son responsables de crear los recursos de GCP para todos los demás equipos. Usan el proyecto de administrador de Terraform para sus recursos. El repositorio de infraestructura se encuentra en el proyecto de administrador de Terraform, al igual que los archivos de estado de Terraform (que se explican a continuación). Estos recursos se crean con una secuencia de comandos de Bash durante el proceso de arranque (consulta el Módulo 0: Flujo de trabajo del administrador para obtener más detalles).
2. network: Representa al equipo de redes. Son responsables de los recursos de VPC y de redes. Son propietarios de los siguientes recursos de GCP.
3. host project: Representa el proyecto host de la VPC compartida.
4. shared VPC: Representa la VPC compartida, las subredes, los rangos de IP secundarios, las rutas y las reglas de firewall.
5. ops: Representa al equipo de operaciones o DevOps. Son propietarios de los siguientes recursos.
6. ops project: Representa un proyecto para todos los recursos de operaciones.
7. gke clusters: Es un clúster de GKE de operaciones por región. El plano de control de Istio se instala en cada uno de los clústeres de GKE de operaciones.
8. k8s-repo: Es un repo de CSR que contiene manifiestos de GKE para todos los clústeres de GKE.
9. apps: Representa a los equipos de aplicaciones. En este taller, se simulan dos equipos: app1 y app2. Son propietarios de los siguientes recursos.
10. app projects: Cada equipo de la app obtiene su propio conjunto de proyectos. Esto les permite controlar la facturación y la IAM de su proyecto específico.
11. gke clusters: Son clústeres de aplicaciones en los que se ejecutan los contenedores o Pods de la aplicación.
12. gce instances: De manera opcional, si tienen aplicaciones que se ejecutan en instancias de GCE En este taller, app1 tiene un par de instancias de GCE en las que se ejecuta parte de la aplicación.

En este taller, la misma app (la app de Hipster Shop) representa tanto a app1 como a app2.

Proveedor, estados y resultados: back-ends y estados compartidos

Los proveedores google y google-beta se encuentran en gcp/[environment]/gcp/provider.tf. El archivo provider.tf está symlinked en cada carpeta de recursos. Esto te permite cambiar el proveedor en un solo lugar en lugar de administrar los proveedores de cada recurso de forma individual.

Cada recurso contiene un archivo backend.tf que define la ubicación del archivo tfstate del recurso. Este archivo backend.tf se genera a partir de una plantilla (ubicada en templates/backend.tf_tmpl) con una secuencia de comandos (ubicada en scripts/setup_terraform_admin_project) y, luego, se coloca en la carpeta de recursos correspondiente. Los buckets de Google Cloud Storage (GCS) se usan para los backends. El nombre de la carpeta del bucket de GCS coincide con el nombre del recurso. Todos los backends de recursos residen en el proyecto de administrador de Terraform.

Los recursos con valores interdependientes contienen un archivo output.tf. Los valores de salida requeridos se almacenan en el archivo tfstate definido en el backend para ese recurso en particular. Por ejemplo, para crear un clúster de GKE en un proyecto, debes conocer el ID del proyecto. El ID del proyecto se genera a través de output.tf en el archivo tfstate que se puede usar a través de una fuente de datos terraform_remote_state en el recurso del clúster de GKE.

El archivo shared_state es una fuente de datos terraform_remote_state que apunta al archivo tfstate de un recurso. Existe un archivo shared_state_[resource_name].tf (o archivos) en las carpetas de recursos que requieren resultados de otros recursos. Por ejemplo, en la carpeta de recursos ops_gke, hay archivos shared_state de los recursos ops_project y shared_vpc, ya que necesitas el ID del proyecto y los detalles de la VPC para crear clústeres de GKE en el proyecto de operaciones. Los archivos shared_state se generan a partir de una plantilla (ubicada en templates/shared_state.tf_tmpl) con una secuencia de comandos (ubicada en scripts/setup_terraform_admin_project). Todos los archivos shared_state de los recursos se colocan en la carpeta gcp/[environment]/shared_states. Los archivos shared_state necesarios se vinculan simbólicamente en las carpetas de recursos respectivas. Colocar todos los archivos shared_state en una carpeta y crear vínculos simbólicos a las carpetas de recursos correspondientes facilita la administración de todos los archivos de estado en un solo lugar.

Variables

Todos los valores de los recursos se almacenan como variables de entorno. Estas variables se almacenan (como instrucciones de exportación) en un archivo llamado vars.sh que se encuentra en un bucket de GCS en el proyecto de administrador de Terraform. Contiene el ID de la organización, la cuenta de facturación, los IDs de los proyectos, los detalles del clúster de GKE, etcétera. Puedes descargar y obtener el vars.sh desde cualquier terminal para obtener los valores de tu configuración.

Las variables de Terraform se almacenan en vars.sh como TF_VAR_[variable name]. Estas variables se usan para generar un archivo variables.tfvars en la carpeta de recursos correspondiente. El archivo variables.tfvars contiene todas las variables con sus valores. El archivo variables.tfvars se genera a partir de un archivo de plantilla en la misma carpeta con una secuencia de comandos (ubicada en scripts/setup_terraform_admin_project).

Explicación del repositorio de K8s

k8s_repo es un repo de CSR (independiente del repo de infraestructura) ubicado en el proyecto de administrador de Terraform. Se usa para almacenar y aplicar manifiestos de GKE a todos los clústeres de GKE. k8s_repo se crea con la infraestructura de Cloud Build (consulta la sección anterior para obtener más detalles). Durante el proceso inicial de Cloud Build de la infraestructura, se crean un total de seis clústeres de GKE. En k8s_repo, se crean seis carpetas. Cada carpeta (con un nombre que coincide con el nombre del clúster de GKE) corresponde a un clúster de GKE que contiene sus respectivos archivos de manifiesto de recursos. De manera similar a la infraestructura de compilación, Cloud Build se usa para aplicar los manifiestos de Kubernetes a todos los clústeres de GKE con k8s_repo. Cloud Build se activa cada vez que se confirma un cambio en el repositorio k8s_repo. Al igual que la infraestructura, todos los manifiestos de Kubernetes se almacenan como código en el repositorio k8s_repo, y el estado de cada clúster de GKE siempre se almacena en su carpeta respectiva.

Como parte de la compilación inicial de la infraestructura, se crea k8s_repo y se instala Istio en todos los clústeres.

Proyectos, clústeres de GKE y espacios de nombres

Los recursos de este taller se dividen en diferentes proyectos de GCP. Los proyectos deben coincidir con la estructura organizativa (o de equipo) de tu empresa. Los equipos (de tu organización) responsables de diferentes proyectos, productos o recursos usan diferentes proyectos de GCP. Tener proyectos separados te permite crear conjuntos independientes de permisos de IAM y administrar la facturación a nivel del proyecto. Además, las cuotas también se administran a nivel del proyecto.

En este taller, se representan cinco equipos, cada uno con su propio proyecto.

1. El equipo de infraestructura que compila los recursos de GCP usa Terraform admin project. Administran la infraestructura como código en un repo de CSR (llamado infrastructure) y almacenan toda la información de estado de Terraform relacionada con los recursos creados en GCP en buckets de GCS. Controlan el acceso al repo de CSR y a los buckets de GCS del estado de Terraform.
2. El equipo de redes que compila la VPC compartida usa el host project. Este proyecto contiene la VPC, las subredes, las rutas y las reglas de firewall. Tener una VPC compartida les permite administrar de forma centralizada las redes para los recursos de GCP. Todos los proyectos usaban esta única VPC compartida para las redes.
3. El equipo de operaciones/plataforma que compila clústeres de GKE y planos de control de ASM/Istio usa ops project. Administran el ciclo de vida de los clústeres de GKE y la malla de servicios. Son responsables de proteger los clústeres y de administrar la resiliencia y la escala de la plataforma de Kubernetes. En este taller, usarás el método de GitOps para implementar recursos en Kubernetes. En el proyecto de operaciones, existe un repo de CSR (llamado k8s_repo).
4. Por último, los equipos dev1 y dev2 (que representan dos equipos de desarrollo) que compilan aplicaciones usan sus propios dev1 y dev2 projects. Son las aplicaciones y los servicios que proporcionas a tus clientes. Se compilan en la plataforma que administra el equipo de Operaciones. Los recursos (implementaciones, servicios, etcétera) se envían a k8s_repo y se implementan en los clústeres correspondientes. Es importante tener en cuenta que este taller no se centra en las prácticas recomendadas ni en las herramientas de CI/CD. Usas Cloud Build para automatizar la implementación de recursos de Kubernetes directamente en los clústeres de GKE. En situaciones de producción del mundo real, usarías una solución de CI/CD adecuada para implementar aplicaciones en clústeres de GKE.

En este taller, hay dos tipos de clústeres de GKE.

1. Clústeres de operaciones: Los usa el equipo de operaciones para ejecutar herramientas de DevOps. En este taller, ejecutan el plano de control de ASM/Istio para administrar la malla de servicios.
2. Clústeres de aplicaciones: Los usan los equipos de desarrollo para ejecutar aplicaciones. En este taller, se usa la app de Hipster Shop.

Separar las herramientas de administración y operaciones de los clústeres que ejecutan la aplicación te permite administrar el ciclo de vida de cada recurso de forma independiente. Los dos tipos de clústeres también existen en diferentes proyectos relacionados con el equipo o el producto que los usa, lo que también facilita la administración de los permisos de IAM.

Hay un total de seis clústeres de GKE. Se crean dos clústeres de operaciones regionales en el proyecto de operaciones. El plano de control de ASM/Istio está instalado en ambos clústeres de operaciones. Cada clúster de operaciones se encuentra en una región diferente. Además, hay cuatro clústeres de aplicaciones zonales. Estos se crean en sus propios proyectos. En este taller, se simulan dos equipos de desarrollo, cada uno con sus propios proyectos. Cada proyecto contiene dos clústeres de aplicaciones. Los clústeres de aplicaciones son clústeres zonales en diferentes zonas. Los cuatro clústeres de la app se encuentran en dos regiones y cuatro zonas. De esta manera, obtienes redundancia regional y zonal.

La aplicación que se usa en este taller, la app de Hipster Shop, se implementa en los cuatro clústeres de aplicaciones. Cada microservicio reside en su propio espacio de nombres en cada clúster de la app. Las implementaciones (Pods) de la app de Hipster Shop no se implementan en los clústeres de operaciones. Sin embargo, los espacios de nombres y los recursos de Service para todos los microservicios también se crean en los clústeres de operaciones. El plano de control de ASM/Istio usa los registros de servicios de Kubernetes para el descubrimiento de servicios. En ausencia de Services (en los clústeres de operaciones), deberías crear manualmente ServiceEntries para cada servicio que se ejecute en el clúster de la app.

En este taller, implementarás una aplicación de microservicios de 10 niveles. La aplicación es una app de comercio electrónico basada en la Web llamada " Hipster Shop" en la que los usuarios pueden explorar artículos, agregarlos al carrito y comprarlos.

Manifiestos de Kubernetes y k8s_repo

Usas k8s_repo para agregar recursos de Kubernetes a todos los clústeres de GKE. Para ello, copia los manifiestos de Kubernetes y confirma los cambios en k8s_repo. Todas las confirmaciones en k8s_repo activan un trabajo de Cloud Build que implementa los manifiestos de Kubernetes en el clúster respectivo. El manifiesto de cada clúster se encuentra en una carpeta independiente con el mismo nombre que el clúster.

Los seis nombres de clústeres son los siguientes:

1. gke-asm-1-r1-prod: Es el clúster de operaciones regional en la región 1.
2. gke-asm-2-r2-prod: Es el clúster de operaciones regional en la región 2.
3. gke-1-apps-r1a-prod: Es el clúster de la app en la zona a de la región 1.
4. gke-2-apps-r1b-prod: Es el clúster de la app en la zona b de la región 1.
5. gke-3-apps-r2a-prod: Es el clúster de la app en la zona a de la región 2.
6. gke-4-apps-r2b-prod: Es el clúster de la app en la zona b de la región 2.

El k8s_repo tiene carpetas correspondientes a estos clústeres. Cualquier manifiesto que se coloque en estas carpetas se aplicará al clúster de GKE correspondiente. Los manifiestos de cada clúster se colocan en subcarpetas (dentro de la carpeta principal del clúster) para facilitar la administración. En este taller, usarás Kustomize para hacer un seguimiento de los recursos que se implementan. Consulta la documentación oficial de Kustomize para obtener más detalles.

7. Implementa la app de ejemplo

Objetivo: Implementar la app de Hipster Shop en clústeres de apps

• Clon de k8s-repo
• Copia los manifiestos de Hipster Shop en todos los clústeres de apps
• Crea servicios para la app de Hipster Shop en los clústeres de operaciones
• Configura loadgenerators en los clústeres de operaciones para probar la conectividad global
• Verifica la conectividad segura a la app de Hipster Shop

GUION DE PISTA RÁPIDA

Si eliges este método, ejecuta la siguiente secuencia de comandos para completar este lab.

${WORKDIR}/asm/fasttrack_scripts/deploy-sample-app.sh

Instrucciones del lab sobre el método de copiar y pegar

Si ya completaste el script de la pista rápida para este lab, **no realices el método de copiar y pegar que se indica a continuación**.

Clona el repo de código fuente del proyecto de operaciones

Como parte de la compilación inicial de la infraestructura de Terraform, el objeto k8s-repo ya se creó en el proyecto de operaciones.

1. Crea un directorio vacío para el repositorio de Git:

mkdir $WORKDIR/k8s-repo
 

2. Inicializa el repositorio de Git, agrega el repositorio remoto y extrae la rama principal del repositorio remoto:

cd $WORKDIR/k8s-repo
git init && git remote add origin \
https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo
 

3. Establece la configuración local de Git.

git config --local user.email $MY_USER
git config --local user.name "K8s repo user"
git config --local \
credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

Copia los manifiestos, confirma y envía los cambios

4. Copia los espacios de nombres y los servicios de Hipster Shop en el repo de origen para todos los clústeres.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.
 

5. Copia el archivo kustomization.yaml de la carpeta de la app en todos los clústeres.

cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/
 

6. Copia las implementaciones, el RBAC y la PodSecurityPolicy de Hipster Shop en el repo de origen de los clústeres de apps.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

7. Quita la implementación de cartservice, rbac y podsecuritypolicy de todos los clústeres de desarrollo, excepto de uno. Hipstershop no se creó para la implementación en varios clústeres, por lo que, para evitar resultados incoherentes, usamos solo un cartservice.

rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml
 

8. Agrega la implementación de cartservice, rbac y podsecuritypolicy a kustomization.yaml solo en el primer clúster de desarrollo.

cd ${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app
cd deployments && kustomize edit add resource app-cart-service.yaml
cd ../podsecuritypolicies && kustomize edit add resource cart-psp.yaml
cd ../rbac && kustomize edit add resource cart-rbac.yaml
cd ${WORKDIR}/asm
 

9. Quita los directorios podsecuritypolicies, deployments y rbac de ops clusters kustomization.yaml

sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/kustomization.yaml

10. Reemplaza PROJECT_ID en los manifiestos de RBAC.

sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*
  

11. Copia los manifiestos de IngressGateway y VirtualService en el repositorio de origen de los clústeres de operaciones.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-ingress/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-ingress/
 

12. Copia los recursos de Config Connector en uno de los clústeres de cada proyecto.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/
 

13. Reemplaza PROJECT_ID en los manifiestos de Config Connector.

sed -i 's/${PROJECT_ID}/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev1_project_name'/g' \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev2_project_name'/g' \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/*
 

14. Copia los manifiestos loadgenerator (Deployment, PodSecurityPolicy y RBAC) en los clústeres de operaciones. La app de Hipster Shop se expone con un balanceador de cargas de Google Cloud (GCLB) global. El GCLB recibe el tráfico del cliente (destinado a frontend) y lo envía a la instancia más cercana del servicio. Colocar loadgenerator en ambos clústeres de operaciones garantizará que el tráfico se envíe a ambas puertas de enlace de entrada de Istio que se ejecutan en los clústeres de operaciones. El balanceo de cargas se explica en detalle en la siguiente sección.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/. 
 

15. Reemplaza el ID del proyecto de operaciones en los manifiestos de loadgenerator para ambos clústeres de operaciones.

sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g'  \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
 

16. Agrega los recursos loadgenerator a kustomization.yaml para ambos clústeres de operaciones.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml
 

17. Confirma el cambio en k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master 
 

18. Consulta el estado de la compilación de Cloud Build del proyecto de Ops en una pestaña abierta anteriormente o haciendo clic en el siguiente vínculo:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  

Verifica la implementación de la aplicación

19. Verifica que los Pods en todos los espacios de nombres de la aplicación, excepto el carrito, estén en estado Running en todos los clústeres de desarrollo.

for ns in ad checkout currency email frontend payment product-catalog recommendation shipping; do
  kubectl --context $DEV1_GKE_1 get pods -n $ns;
  kubectl --context $DEV1_GKE_2 get pods -n $ns;
  kubectl --context $DEV2_GKE_1 get pods -n $ns;
  kubectl --context $DEV2_GKE_2 get pods -n $ns;
done;
 

Output (do not copy)

NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-pvc6s   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-xlkl9   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-zdjkg   2/2     Running   0          115s
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-l748q   2/2     Running   0          82s

NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-gk92n   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-rvzk9   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-mt925   2/2     Running   0          117s
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-klqn7   2/2     Running   0          84s

NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-kkq7d   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-lwskf   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-zz7xs   2/2     Running   0          118s
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-2vtw5   2/2     Running   0          85s

NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-df8ml   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-bdcvg   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-jqf28   2/2     Running   0          117s
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-95x2m   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-q5g9p   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-n6lp8   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-gf9xl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-v7cbr   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-2ltrk   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-dqd55   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-jghcl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-kkspz   2/2     Running   0          87s

NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-qqd9n   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-xczg5   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-wfgfr   2/2     Running   0          2m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-r6t8v   2/2     Running   0          88s

20. Verifica que los Pods en el espacio de nombres del carrito estén en el estado En ejecución solo en el primer clúster de desarrollo.

kubectl --context $DEV1_GKE_1 get pods -n cart;
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
cartservice-659c9749b4-vqnrd   2/2     Running   0          17m

Accede a la app de Hipster Shop

Balanceo de cargas global

Ahora tienes la app de Hipster Shop implementada en los cuatro clústeres de apps. Estos clústeres se encuentran en dos regiones y cuatro zonas. Los clientes pueden acceder a la app de Hipster Shop a través del servicio frontend. El servicio frontend se ejecuta en los cuatro clústeres de la app. Se usa un balanceador de cargas de Google Cloud ( GCLB) para dirigir el tráfico de clientes a las cuatro instancias del servicio frontend.

Las puertas de enlace de entrada de Istio solo se ejecutan en los clústeres de operaciones y actúan como un balanceador de cargas regional para los dos clústeres de aplicaciones zonales dentro de la región. GCLB usa las dos puertas de enlace de entrada de Istio (que se ejecutan en los dos clústeres de operaciones) como backends para el servicio de frontend global. Las puertas de enlace de entrada de Istio reciben el tráfico del cliente del GCLB y, luego, lo envían a los Pods de frontend que se ejecutan en los clústeres de aplicaciones.

Como alternativa, puedes colocar puertas de enlace de entrada de Istio directamente en los clústeres de aplicaciones, y el GCLB puede usarlas como backends.

Controlador de Autoneg de GKE

El servicio de Kubernetes de la puerta de enlace de entrada de Istio se registra como backend en el GCLB con grupos de extremos de red (NEG). Los NEG permiten el balanceo de cargas nativo del contenedor con GCLB. Los NEG se crean a través de una anotación especial en un servicio de Kubernetes, de modo que pueda registrarse en el controlador del NEG. El controlador Autoneg es un controlador especial de GKE que automatiza la creación de NEG, así como su asignación como backends a un GCLB con anotaciones de Service. Los planos de control de Istio, incluidas las puertas de enlace de entrada de Istio, se implementan durante la compilación inicial de la infraestructura de Terraform Cloud Build. La configuración del GCLB y de autoneg se realiza como parte de la compilación inicial de Cloud Build de la infraestructura de Terraform.

Protege Ingress con Cloud Endpoints y certificados administrados

Los certificados administrados por GCP se usan para proteger el tráfico del cliente al servicio de frontend del GCLB. El GCLB usa certificados administrados para el servicio frontend global, y el certificado se finaliza en el GCLB. En este taller, usarás Cloud Endpoints como el dominio del certificado administrado. Como alternativa, puedes usar tu dominio y un nombre de DNS para el frontend y crear certificados administrados por GCP.

21. Para acceder a la tienda de Hipster, haz clic en el vínculo que se genera con el siguiente comando.

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

22. Para verificar que el certificado sea válido, haz clic en el símbolo de candado que se encuentra en la barra de URL de la pestaña de Chrome.

Verifica el balanceo de cargas global

Como parte de la implementación de la aplicación, se implementaron generadores de carga en ambos clústeres de operaciones que generan tráfico de prueba al vínculo de Cloud Endpoints de la tienda Hipster del GCLB. Verifica que el GCLB reciba tráfico y lo envíe a ambas puertas de enlace de entrada de Istio.

23. Obtén el vínculo GCLB > Monitoring para el proyecto de operaciones en el que se creó el GCLB de Hipster Shop.

echo "https://console.cloud.google.com/net-services/loadbalancing/details/http/istio-ingressgateway?project=$TF_VAR_ops_project_name&cloudshell=false&tab=monitoring&duration=PT1H" 
 

24. Cambia de All backends a istio-ingressgateway en el menú desplegable Backend, como se muestra a continuación.

25. Observa el tráfico que se dirige a ambos istio-ingressgateways.

Se crean tres NEG por cada istio-ingressgateway. Dado que los clústeres de operaciones son clústeres regionales, se crea un NEG para cada zona de la región. Sin embargo, los Pods istio-ingressgateway se ejecutan en una sola zona por región. Se muestra el tráfico que se dirige a los Pods istio-ingressgateway.

Los generadores de cargas se ejecutan en ambos clústeres de operaciones y simulan el tráfico de clientes de las dos regiones en las que se encuentran. La carga generada en la región 1 del clúster de operaciones se envía a istio-ingressgateway en la región 2. Del mismo modo, la carga generada en la región 2 del clúster de operaciones se envía a istio-ingressgateway en la región 2.

8. Observabilidad con Stackdriver

Objetivo: Conectar la telemetría de Istio a Stackdriver y validarla

• Instala recursos de istio-telemetry
• Crea o actualiza paneles de Istio Services
• Consulta registros del contenedor
• Visualiza el seguimiento distribuido en Stackdriver

GUION DE PISTA RÁPIDA

Si eliges este método, ejecuta la siguiente secuencia de comandos para completar este lab.

${WORKDIR}/asm/fasttrack_scripts/observability-with-stackdriver.sh

Instrucciones del lab sobre el método de copiar y pegar

Si ya completaste el script de la pista rápida para este lab, **no realices el método de copiar y pegar que se indica a continuación**.

Una de las principales características de Istio es la observabilidad integrada ("o11y"). Esto significa que, incluso con contenedores de caja negra sin instrumentar, los operadores pueden observar el tráfico que entra y sale de estos contenedores, lo que permite brindar servicios a los clientes. Esta observación adopta la forma de varios métodos diferentes: métricas, registros y seguimientos.

También utilizaremos el sistema integrado de generación de carga en Hipster Shop. La observabilidad no funciona muy bien en un sistema estático sin tráfico, por lo que la generación de carga nos ayuda a ver cómo funciona. Esta carga ya se está ejecutando, ahora solo podremos verla.

1. Instala el archivo de configuración de Istio en Stackdriver.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml
 

2. Confirma en k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "Install istio to stackdriver configuration"
git push 
 

3. Consulta el estado de la compilación de Cloud Build del proyecto de Ops en una pestaña abierta anteriormente o haciendo clic en el siguiente vínculo:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

4. Verifica la integración de Istio en Stackdriver. Obtén el CRD del controlador de Stackdriver.

kubectl --context $OPS_GKE_1 get handler -n istio-system
 

El resultado debería mostrar un controlador llamado stackdriver:

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s      # <== NEW!

5. Verifica que la exportación de métricas de Istio a Stackdriver funcione. Haz clic en el vínculo que se generó con este comando:

echo "https://console.cloud.google.com/monitoring/metrics-explorer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Se te pedirá que crees un nuevo lugar de trabajo con el nombre del proyecto de operaciones. Solo debes hacer clic en Aceptar. Si aparece un mensaje sobre la nueva IU, descarta el diálogo.

En el Explorador de métricas, en "Buscar tipo de recurso y métrica", escribe "istio" para ver que hay opciones como "Recuento de solicitudes del servidor" en el tipo de recurso "Contenedor de Kubernetes". Esto nos muestra que las métricas fluyen de la malla a Stackdriver.

(Deberás agrupar por la etiqueta destination_service_name si quieres ver las líneas a continuación).

Visualiza métricas con paneles:

Ahora que nuestras métricas están en el sistema de APM de Stackdriver, queremos una forma de visualizarlas. En esta sección, instalaremos un panel prediseñado que nos muestra tres de los cuatro "indicadores dorados" de las métricas: Tráfico (solicitudes por segundo), Latencia (en este caso, percentil 99 y 50) y Errores (excluimos la Saturación en este ejemplo).

El proxy de Envoy de Istio nos proporciona varias métricas, pero este es un buen conjunto para comenzar. (La lista exhaustiva se encuentra aquí). Ten en cuenta que cada métrica tiene un conjunto de etiquetas que se pueden usar para filtrar y agregar, como destination_service, source_workload_namespace, response_code, istio_tcp_received_bytes_total, etcétera.

6. Ahora, agreguemos nuestro panel de métricas prediseñadas. Usaremos la API de Dashboard directamente. Normalmente, no harías esto generando llamadas a la API de forma manual, sino que sería parte de un sistema de automatización o crearías el panel de forma manual en la IU web. Esto nos permitirá comenzar rápidamente:

sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g' \
$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
OAUTH_TOKEN=$(gcloud auth application-default print-access-token)
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards \
 -d @$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
 

7. Navega al vínculo de salida que se encuentra a continuación para ver el "Panel de servicios" recién agregado.

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 
 

Podríamos editar el panel de forma local con la UX, pero, en nuestro caso, agregaremos rápidamente un gráfico nuevo con la API. Para ello, debes extraer la versión más reciente del panel, aplicar tus ediciones y, luego, volver a subirla con el método HTTP PATCH.

8. Puedes obtener un panel existente consultando la API de Monitoring. Obtén el panel existente que se acaba de agregar:

curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash > /tmp/services-dashboard.json
 

9. Agrega un nuevo gráfico: (latencia del percentil 50): [Referencia de la API]. Ahora podemos agregar un nuevo widget de gráfico a nuestro panel en el código. Los compañeros pueden revisar este cambio y se puede registrar en el control de versiones. Este es un widget que puedes agregar y que muestra la latencia del percentil 50 (latencia mediana).

Intenta editar el panel que acabas de obtener y agrega una nueva estrofa:

NEW_CHART=${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/new-chart.json
jq --argjson newChart "$(<$NEW_CHART)" '.gridLayout.widgets += [$newChart]' /tmp/services-dashboard.json > /tmp/patched-services-dashboard.json
 

10. Actualiza el panel de servicios existente:

curl -X PATCH -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash \
 -d @/tmp/patched-services-dashboard.json
 

11. Para ver el panel actualizado, navega al siguiente vínculo de salida:

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 

12. Realiza un análisis de registros simple.

Istio proporciona un conjunto de registros estructurados para todo el tráfico de red dentro de la malla y los sube a Stackdriver Logging para permitir el análisis entre clústeres en una herramienta potente. Los registros se anotan con metadatos a nivel del servicio, como el clúster, el contenedor, la app, el connection_id, etcétera.

Un ejemplo de entrada de registro (en este caso, el registro de acceso del proxy de Envoy) podría verse así (recortado):

*** DO NOT PASTE *** 
 logName: "projects/PROJECTNAME-11932-01-ops/logs/server-tcp-accesslog-stackdriver.instance.istio-system" 
labels: {
  connection_id: "fbb46826-96fd-476c-ac98-68a9bd6e585d-1517191"   
  destination_app: "redis-cart"   
  destination_ip: "10.16.1.7"   
  destination_name: "redis-cart-6448dcbdcc-cj52v"   
  destination_namespace: "cart"   
  destination_owner: "kubernetes://apis/apps/v1/namespaces/cart/deployments/redis-cart"   
  destination_workload: "redis-cart"   
  source_ip: "10.16.2.8"   
  total_received_bytes: "539"   
  total_sent_bytes: "569" 
...  
 }

Consulta tus registros aquí:

echo "https://console.cloud.google.com/logs/viewer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Para ver los registros del plano de control de Istio, selecciona Recurso > Contenedor de Kubernetes y busca "pilot":

Aquí, podemos ver el plano de control de Istio que envía la configuración del proxy a los proxies de sidecar de cada servicio de la app de ejemplo. "CDS", "LDS" y "RDS" representan diferentes APIs de Envoy ( más información).

Además de los registros de Istio, también puedes encontrar registros de contenedores, así como registros de infraestructura o de otros servicios de GCP, todo en la misma interfaz. Aquí tienes algunas consultas de registros de ejemplo para GKE. El visualizador de registros también te permite crear métricas a partir de los registros (p. ej., "cuenta cada error que coincida con alguna cadena"), que se pueden usar en un panel o como parte de una alerta. Los registros también se pueden transmitir a otras herramientas de análisis, como BigQuery.

Estos son algunos filtros de ejemplo para una tienda hipster:

resource.type="k8s_container" labels.destination_app="productcatalogservice"

resource.type="k8s_container" resource.labels.namespace_name="cart"

13. Consulta Seguimientos distribuidos.

Ahora que trabajas con un sistema distribuido, la depuración necesita una nueva herramienta: el seguimiento distribuido. Esta herramienta te permite descubrir estadísticas sobre cómo interactúan tus servicios (por ejemplo, encontrar eventos lentos atípicos en la siguiente imagen), así como explorar seguimientos de muestras sin procesar para investigar los detalles de lo que realmente sucede.

La vista de cronograma muestra todas las solicitudes a lo largo del tiempo, graficadas según su latencia o el tiempo transcurrido entre la solicitud inicial, a través de la pila de Hipster, hasta responder finalmente al usuario final. Cuanto más arriba estén los puntos, más lenta (y menos feliz) será la experiencia del usuario.

Puedes hacer clic en un punto para encontrar la vista de cascada detallada de esa solicitud en particular. Esta capacidad de encontrar los detalles sin procesar de una solicitud en particular (no solo las estadísticas agregadas) es fundamental para comprender la interacción entre los servicios, en especial cuando se buscan interacciones raras, pero malas, entre los servicios.

La vista de cascada debería ser familiar para cualquier persona que haya usado un depurador, pero, en este caso, en lugar de mostrar el tiempo dedicado a diferentes procesos de una sola aplicación, muestra el tiempo dedicado a recorrer nuestra malla, entre servicios, que se ejecutan en contenedores separados.

Aquí puedes encontrar tus Rutas:

echo "https://console.cloud.google.com/traces/overview?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Ejemplo de captura de pantalla de la herramienta:

9. Autenticación mutua de TLS

Objetivo: Conectividad segura entre microservicios (AuthN)

• Habilita la mTLS en toda la malla
• Verifica la mTLS inspeccionando los registros

GUION DE PISTA RÁPIDA

Si eliges este método, ejecuta la siguiente secuencia de comandos para completar este lab.

${WORKDIR}/asm/fasttrack_scripts/mutual-tls.sh

Instrucciones del lab sobre el método de copiar y pegar

Si ya completaste el script de la pista rápida para este lab, **no realices el método de copiar y pegar que se indica a continuación**.

Ahora que nuestras apps están instaladas y la Observabilidad está configurada, podemos comenzar a proteger las conexiones entre los servicios y asegurarnos de que sigan funcionando.

Por ejemplo, en el panel de Kiali, podemos ver que nuestros servicios no usan mTLS (no hay ningún ícono de "candado"). Pero el tráfico fluye y el sistema funciona bien. Nuestro panel de métricas de oro de Stackdriver nos da cierta tranquilidad de que todo funciona en general.

1. Verifica MeshPolicy en los clústeres de operaciones. Ten en cuenta que mTLS es PERMISSIVE, lo que permite el tráfico encriptado y el tráfico que no es de mTLS.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq '.items[].spec'
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq '.items[].spec'
 

    `Output (do not copy)`

{
  "peers": [
    {
      "mtls": {
        "mode": "PERMISSIVE"
      }
    }
  ]
}

Istio se configura en todos los clústeres con el operador de Istio, que usa el recurso personalizado (CR) IstioControlPlane. Configuraremos mTLS en todos los clústeres actualizando el CR de IstioControlPlane y k8s-repo. Si se configura global > mTLS > enabled: true en el CR de IstioControlPlane, se producen los siguientes dos cambios en el plano de control de Istio:

• MeshPolicy está configurado para activar la mTLS en toda la malla para todos los servicios que se ejecutan en todos los clústeres.
• Se crea un DestinationRule para permitir el tráfico ISTIO_MUTUAL entre los servicios que se ejecutan en todos los clústeres.

2. Aplicaremos un parche de kustomize al CR de istioControlPlane para habilitar mTLS en todo el clúster. Copia el parche en el directorio pertinente para todos los clústeres y agrega un parche de kustomize.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml
 

3. Confirma en k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "turn mTLS on"
git push
 

4. Consulta el estado de la compilación de Cloud Build del proyecto de Ops en una pestaña abierta anteriormente o haciendo clic en el siguiente vínculo:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

 

Verifica la mTLS

5. Vuelve a verificar MeshPolicy en los clústeres de operaciones. Ten en cuenta que mTLS ya no es PERMISSIVE y solo permitirá el tráfico de mTLS.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq .items[].spec
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq .items[].spec
 

Resultado (no lo copie):

{
  "peers": [
    {
      "mtls": {}
    }
  ]
}

6. Describe el objeto DestinationRule creado por el controlador del operador de Istio.

kubectl --context $OPS_GKE_1 get DestinationRule default -n istio-system -o json | jq '.spec'
kubectl --context $OPS_GKE_2 get DestinationRule default -n istio-system -o json | jq '.spec'

Resultado (no lo copie):

{
    host: '*.local',
    trafficPolicy: {
      tls: {
        mode: ISTIO_MUTUAL
      }
   }
}

También podemos ver el cambio de HTTP a HTTPS en los registros.

Podemos exponer este campo en particular de los registros en la IU haciendo clic en una entrada de registro y, luego, en el valor del campo que deseas mostrar. En nuestro caso, haz clic en "http" junto a "protocolo":

Esto genera una buena forma de visualizar el cambio:

10. Implementaciones de versiones canary

Objetivo: Lanzar una nueva versión del servicio de frontend.

• Lanzamiento de la versión frontend-v2 (próxima versión de producción) del servicio en una región
• Usa DestinationRules y VirtualServices para dirigir el tráfico lentamente hacia frontend-v2
• Verifica la canalización de implementación de GitOps inspeccionando una serie de confirmaciones en k8s-repo.

GUION DE PISTA RÁPIDA

Si eliges este método, ejecuta la siguiente secuencia de comandos para completar este lab.

${WORKDIR}/asm/fasttrack_scripts/canary-deployments.sh

Instrucciones del lab sobre el método de copiar y pegar

Si ya completaste el script de la pista rápida para este lab, **no realices el método de copiar y pegar que se indica a continuación**.

Una implementación canary es un lanzamiento progresivo de un servicio nuevo. En una implementación Canary, envías una cantidad cada vez mayor de tráfico a la versión nueva, mientras sigues enviando el porcentaje restante a la versión actual. Un patrón común es realizar un análisis de versiones canary en cada etapa de la división del tráfico y comparar los "indicadores clave" de la versión nueva (latencia, tasa de errores, saturación) con un valor de referencia. Esto ayuda a evitar interrupciones y garantiza la estabilidad del nuevo servicio "v2" en cada etapa de la división del tráfico.

En esta sección, aprenderás a usar Cloud Build y las políticas de tráfico de Istio para crear una implementación canary básica para una nueva versión del servicio frontend.

Primero, ejecutaremos la canalización de Canary en la región DEV1 (us-west1) y lanzaremos la versión 2 del frontend en ambos clústeres de esa región. En segundo lugar, ejecutaremos la canalización de Canary en la región DEV2 (us-central) y, luego, implementaremos la versión 2 en ambos clústeres de esa región. Ejecutar la canalización en las regiones en orden, en lugar de hacerlo en paralelo en todas las regiones, ayuda a evitar interrupciones globales causadas por una configuración incorrecta o por errores en la app de la versión 2.

Nota: Activaremos manualmente la canalización de Canary en ambas regiones, pero, en producción, usarías un activador automático, por ejemplo, basado en una nueva etiqueta de imagen de Docker enviada a un registro.

1. En Cloud Shell, define algunas variables de entorno para simplificar la ejecución del resto de los comandos.

CANARY_DIR="$WORKDIR/asm/k8s_manifests/prod/app-canary/"
K8S_REPO="$WORKDIR/k8s-repo"
 

2. Ejecuta la secuencia de comandos repo_setup.sh para copiar los manifiestos de referencia en k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

Se copian los siguientes manifiestos:

• Implementación de frontend-v2
• Parche frontend-v1 (para incluir la etiqueta "v1" y una imagen con un extremo "/version")
• respy, un pod pequeño que imprimirá la distribución de respuestas HTTP y nos ayudará a visualizar la implementación de Canary en tiempo real.
• DestinationRule de Istio para el frontend: Divide el servicio de Kubernetes del frontend en dos subconjuntos, v1 y v2, según la etiqueta de implementación "version".
• VirtualService de Istio para el frontend: Enruta el 100% del tráfico a la versión 1 del frontend. Esto anula el comportamiento predeterminado de Kubernetes Service de round-robin, que enviaría de inmediato el 50% de todo el tráfico regional de Dev1 al frontend v2.

3. Confirma los cambios en k8s_repo:

cd $K8S_REPO 
git add . && git commit -am "frontend canary setup"
git push
 

4. Consulta el estado de la compilación de Cloud Build del proyecto de Ops en una pestaña abierta anteriormente o haciendo clic en el siguiente vínculo:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}" 
 

5. Navega a Cloud Build en la consola del proyecto OPS1. Espera a que se complete la canalización de Cloud Build y, luego, obtén los Pods en el espacio de nombres del frontend en ambos clústeres de DEV1. Deberías ver lo siguiente:

watch -n 1 kubectl --context $DEV1_GKE_1 get pods -n frontend 
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
frontend-578b5c5db6-h9567      2/2     Running   0          59m
frontend-v2-54b74fc75b-fbxhc   2/2     Running   0          2m26s
respy-5f4664b5f6-ff22r         2/2     Running   0          2m26s

Nota: Presiona Ctrl + C para salir de los comandos watch.

Usaremos tmux para dividir nuestra ventana de Cloud Shell en 2 paneles:

• En el panel inferior, se ejecutará el comando watch para observar la distribución de respuestas HTTP del servicio de frontend.
• El panel superior ejecutará la secuencia de comandos de la canalización de la versión canary real.

6. Ejecuta el comando para dividir la ventana de Cloud Shell y ejecutar el comando watch en el panel inferior.

RESPY_POD=$(kubectl --context $DEV1_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV1_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

Resultado (no lo copie)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

Podemos ver que todo el tráfico se dirige a la implementación de frontend v1, definida en el nuevo VirtualService.

7. Ejecuta la canalización de versiones canary en la región de Dev1. Proporcionamos una secuencia de comandos que actualiza los porcentajes de tráfico de frontend-v2 en VirtualService (actualiza los pesos a 20%, 50%, 80% y, luego, 100%). Entre las actualizaciones, la secuencia de comandos espera a que se complete la canalización de Cloud Build. Ejecuta la secuencia de comandos de implementación de versiones canary para la región de Dev1. Nota: Esta secuencia de comandos tarda aproximadamente 10 minutos en completarse.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_1_CLUSTER OPS_CONTEXT=$OPS_GKE_1 \
${CANARY_DIR}/auto-canary.sh
 

Puedes ver la división del tráfico en tiempo real en la ventana inferior en la que ejecutas el comando respy. Por ejemplo, en la marca del 20%:

Resultado (no lo copie)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 79.4%             |
|          |                   |
| v2       | 20.6%             |
|          |                   |
+----------+-------------------+

8. Una vez que se complete la actualización progresiva de Dev2 para frontend-v2, deberías ver un mensaje de éxito al final de la secuencia de comandos:

    Output (do not copy) 
   

✅ 100% successfully deployed
🌈 frontend-v2 Canary Complete for gke-asm-1-r1-prod

9. Además, todo el tráfico de frontend de un pod de Dev2 debe dirigirse a frontend-v2:

    Output (do not copy) 
   

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

10. Cierra el panel dividido.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'
 

11. Navega a Cloud Source Repos en el vínculo generado.

echo https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo

Deberías ver una confirmación separada para cada porcentaje de tráfico, con la confirmación más reciente en la parte superior de la lista:

Ahora, repetirás el mismo proceso para la región de Dev2. Ten en cuenta que la región Dev2 aún está "bloqueada" en la versión 1. Esto se debe a que, en el script baseline repo_setup, enviamos un VirtualService para enviar explícitamente todo el tráfico a v1. De esta manera, pudimos realizar una versión canary regional en Dev1 de forma segura y asegurarnos de que se ejecutara correctamente antes de lanzar la nueva versión a nivel global.

12. Ejecuta el comando para dividir la ventana de Cloud Shell y ejecutar el comando watch en el panel inferior.

RESPY_POD=$(kubectl --context $DEV2_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV2_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

Resultado (no lo copie)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

Podemos ver que todo el tráfico se dirige a la implementación de frontend v1, definida en el nuevo VirtualService.

13. Ejecuta la canalización canary en la región de Dev2. Proporcionamos una secuencia de comandos que actualiza los porcentajes de tráfico de frontend-v2 en VirtualService (actualiza los pesos a 20%, 50%, 80% y, luego, 100%). Entre las actualizaciones, la secuencia de comandos espera a que se complete la canalización de Cloud Build. Ejecuta la secuencia de comandos de implementación de versiones canary para la región de Dev1. Nota: Esta secuencia de comandos tarda aproximadamente 10 minutos en completarse.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_2_CLUSTER OPS_CONTEXT=$OPS_GKE_2 \
${CANARY_DIR}/auto-canary.sh
 

Resultado (no lo copie)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

14. Desde el pod de Respy en Dev2, observa cómo el tráfico de los pods de Dev2 se mueve progresivamente del frontend v1 a v2. Una vez que se complete la secuencia de comandos, deberías ver lo siguiente:

Resultado (no lo copie)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

15. Cierra el panel dividido.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'

En esta sección, se explicó cómo usar Istio para las implementaciones Canary regionales. En la producción, en lugar de una secuencia de comandos manual, puedes activar automáticamente esta secuencia de comandos de versión canary como una canalización de Cloud Build, con un activador, como una nueva imagen etiquetada enviada a un registro de contenedores. También te convendría agregar un análisis de versiones canary entre cada paso, analizando la latencia y la tasa de errores de la versión 2 en comparación con un umbral de seguridad predefinido, antes de enviar más tráfico.

11. Políticas de autorización

Objetivo: Configurar el RBAC entre microservicios (AuthZ).

• Crea AuthorizationPolicy para DENY el acceso a un microservicio
• Crea AuthorizationPolicy para PERMITIR el acceso específico a un microservicio

GUION DE PISTA RÁPIDA

Si eliges este método, ejecuta la siguiente secuencia de comandos para completar este lab.

${WORKDIR}/asm/fasttrack_scripts/authorization-policy.sh

Instrucciones del lab sobre el método de copiar y pegar

Si ya completaste el script de la pista rápida para este lab, **no realices el método de copiar y pegar que se indica a continuación**.

A diferencia de una aplicación monolítica que podría ejecutarse en un solo lugar, las apps de microservicios distribuidas en todo el mundo realizan llamadas a través de los límites de red. Esto significa que habrá más puntos de entrada a tus aplicaciones y más oportunidades de ataques maliciosos. Además, debido a que los Pods de Kubernetes tienen IPs transitorias, las reglas de firewall tradicionales basadas en IP ya no son adecuadas para proteger el acceso entre las cargas de trabajo. En una arquitectura de microservicios, se necesita un nuevo enfoque para la seguridad. Istio, que se basa en los componentes básicos de seguridad de Kubernetes, como las cuentas de servicio, proporciona un conjunto flexible de políticas de seguridad para tus aplicaciones.

Las políticas de Istio abarcan la autenticación y la autorización. La autenticación verifica la identidad (¿este servidor es quien dice ser?) y la autorización verifica los permisos (¿este cliente tiene permiso para hacer eso?). Tratamos la autenticación de Istio en la sección de TLS mutua del módulo 1 (MeshPolicy). En esta sección, aprenderemos a usar las políticas de autorización de Istio para controlar el acceso a una de las cargas de trabajo de nuestra aplicación, currencyservice.

Primero, implementaremos una AuthorizationPolicy en los 4 clústeres de desarrollo, lo que cerrará todo el acceso a currencyservice y activará un error en el frontend. Luego, permitiremos que solo el servicio de frontend acceda a currencyservice.

1. Inspecciona el contenido de currency-deny-all.yaml. Esta política usa selectores de etiquetas de implementación para restringir el acceso a currencyservice. Observa que no hay ningún campo spec, lo que significa que esta política denegará todo el acceso al servicio seleccionado.

cat $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml
 

Resultado (no lo copie)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice

2. Copia la política de moneda en k8s-repo para los clústeres de operaciones en ambas regiones.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml

3. Envía los cambios.

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push 

4. Verifica el estado de Cloud Build del proyecto de operaciones en una pestaña que hayas abierto anteriormente o haciendo clic en el siguiente vínculo:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name 
 

5. Una vez que la compilación finalice correctamente, intenta acceder a la interfaz de Hipstershop en un navegador a través del siguiente vínculo:

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

Deberías ver un error de autorización de currencyservice:

6. Investiguemos cómo el servicio de Currency aplica esta AuthorizationPolicy. Primero, habilita los registros a nivel de seguimiento en el proxy de Envoy para uno de los Pods de la moneda, ya que las llamadas de autorización bloqueadas no se registran de forma predeterminada.

CURRENCY_POD=$(kubectl --context $DEV1_GKE_2 get pod -n currency | grep currency| awk '{ print $1 }')
kubectl --context $DEV1_GKE_2 exec -it $CURRENCY_POD -n \
currency -c istio-proxy -- curl -X POST \
"http://localhost:15000/logging?level=trace"
 

7. Obtén los registros de RBAC (autorización) del proxy de sidecar del servicio de moneda. Deberías ver un mensaje de "rechazo aplicado", que indica que el servicio de monedas está configurado para bloquear todas las solicitudes entrantes.

kubectl --context $DEV1_GKE_2 logs -n currency $CURRENCY_POD \
-c istio-proxy | grep -m 3 rbac
 

Resultado (no lo copie)

[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:67] checking request: remoteAddress: 10.16.5.15:37310, localAddress: 10.16.3.8:7000, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/frontend/sa/frontend, subjectPeerCertificate: , headers: ':method', 'POST'
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:118] enforced denied
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1354] [C115][S17310331589050212978] Sending local reply with details rbac_access_denied

8. Ahora, permite que el frontend (pero no los otros servicios de backend) acceda a currencyservice. Abre currency-allow-frontend.yaml y examina su contenido. Ten en cuenta que agregamos la siguiente regla:

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml

Resultado (no lo copie)

rules:
 - from:
   - source:
       principals: ["cluster.local/ns/frontend/sa/frontend"]

Aquí, incluimos en la lista blanca un source.principal (cliente) específico para acceder al servicio de divisas. Este source.principal se define como cuenta de servicio de Kubernetes. En este caso, la cuenta de servicio que agregamos a la lista de entidades permitidas es la cuenta de servicio de frontend en el espacio de nombres de frontend.

Nota: Cuando uses cuentas de servicio de Kubernetes en las políticas de autorización de Istio, primero debes habilitar el protocolo TLS mutuo en todo el clúster, como lo hicimos en el módulo 1. Esto garantiza que las credenciales de la cuenta de servicio se activen en las solicitudes.

9. Copia la política de monedas actualizada

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

10. Envía los cambios.

cd $WORKDIR/k8s-repo
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
 

11. Consulta el estado de la compilación de Cloud Build del proyecto de Ops en una pestaña abierta anteriormente o haciendo clic en el siguiente vínculo:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name

12. Una vez que la compilación finalice correctamente, vuelve a abrir el frontend de Hipstershop. Esta vez, no deberías ver ningún error en la página principal, ya que el frontend tiene permiso explícito para acceder al servicio actual.
13. Ahora, intenta ejecutar una confirmación de compra. Para ello, agrega artículos al carrito y haz clic en "Realizar pedido". Esta vez, deberías ver un error de conversión de precios del servicio de divisas, ya que solo incluimos en la lista de entidades permitidas el frontend, por lo que el servicio de pago sigue sin poder acceder al servicio de divisas.

14. Por último, permitamos que el servicio de confirmación de compra acceda a la moneda agregando otra regla a nuestra AuthorizationPolicy de currencyservice. Ten en cuenta que solo abriremos el acceso a la moneda a los dos servicios que necesitan acceder a ella: el frontend y la confirmación de compra. Los demás back-ends seguirán bloqueados.
15. Abre currency-allow-frontend-checkout.yaml y examina su contenido. Ten en cuenta que la lista de reglas funciona como un OR lógico: la moneda solo aceptará solicitudes de cargas de trabajo con cualquiera de estas dos cuentas de servicio.

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml
 

Resultado (no lo copie)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/checkout/sa/checkout"]

16. Copia la política de autorización final en k8s-repo.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

17. Envía los cambios

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push
 

18. Consulta el estado de la compilación de Cloud Build del proyecto de Ops en una pestaña abierta anteriormente o haciendo clic en el siguiente vínculo:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name
 

19. Una vez que la compilación finalice correctamente, intenta ejecutar una confirmación. Debería funcionar correctamente.

En esta sección, se explicó cómo usar las políticas de autorización de Istio para aplicar un control de acceso detallado a nivel de cada servicio. En la producción, puedes crear una AuthorizationPolicy por servicio y, por ejemplo, usar una política de permitir todo para permitir que todas las cargas de trabajo en el mismo espacio de nombres se accedan entre sí.

12. Escalamiento de la infraestructura

Objetivo: Ampliar la infraestructura agregando regiones, proyectos y clústeres nuevos

• Clona el repositorio infrastructure
• Actualiza los archivos de Terraform para crear recursos nuevos
• 2 subredes en la región nueva (una para el proyecto de operaciones y otra para el proyecto nuevo)
• Nuevo clúster de operaciones en una región nueva (en la subred nueva)
• Nuevo plano de control de Istio para la región nueva
• 2 clústeres de apps en el proyecto nuevo y la región nueva
• Confirma en el repo de infrastructure
• Verifica la instalación

GUION DE PISTA RÁPIDA

Si eliges este método, ejecuta la siguiente secuencia de comandos para completar este lab.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-scaling.sh

Instrucciones del lab sobre el método de copiar y pegar

Si ya completaste el script de la pista rápida para este lab, **no realices el método de copiar y pegar que se indica a continuación**.

Existen varias formas de escalar una plataforma. Puedes agregar más capacidad de procesamiento agregando nodos a los clústeres existentes. Puedes agregar más clústeres en una región. También puedes agregar más regiones a la plataforma. La decisión sobre qué aspecto de la plataforma escalar depende de los requisitos. Por ejemplo, si tienes clústeres en las tres zonas de una región, tal vez sea suficiente con agregar más nodos (o grupos de nodos) al clúster existente. Sin embargo, si tienes clústeres en dos de las tres zonas de una sola región, agregar un clúster nuevo en la tercera zona te brinda escalamiento y un dominio de fallas adicional (es decir, una zona nueva). Otro motivo para agregar un clúster nuevo en una región podría ser la necesidad de crear un clúster de un solo arrendatario por motivos reglamentarios o de cumplimiento (por ejemplo, PCI o un clúster de base de datos que aloje información de PII). A medida que se expanden tu empresa y tus servicios, es inevitable agregar regiones nuevas para brindar servicios más cerca de los clientes.

La plataforma actual consta de dos regiones y clústeres en dos zonas por región. Puedes pensar en el escalamiento de la plataforma de dos maneras:

• Verticalmente: Dentro de cada región, se agrega más capacidad de procesamiento. Esto se hace agregando más nodos (o grupos de nodos) a los clústeres existentes o agregando clústeres nuevos dentro de la región. Esto se hace a través del repo infrastructure. La ruta más simple es agregar nodos a los clústeres existentes. No es necesario realizar ninguna configuración adicional. Agregar clústeres nuevos puede requerir subredes adicionales (y rangos secundarios), agregar reglas de firewall adecuadas, agregar los clústeres nuevos al plano de control regional de la malla de servicios de ASM/Istio y, luego, implementar recursos de la aplicación en los clústeres nuevos.
• Horizontalmente: Agregando más regiones La plataforma actual te proporciona una plantilla regional. Consiste en un clúster de operaciones regional en el que reside el plano de control de ASM/Istio y dos (o más) clústeres de aplicaciones zonales en los que se implementan los recursos de la aplicación.

En este taller, escalarás la plataforma "horizontalmente", ya que también abarca los pasos del caso de uso vertical. Para escalar la plataforma de forma horizontal agregando una región nueva (r3), se deben agregar los siguientes recursos:

1. Subredes en la VPC compartida del proyecto host en la región r3 para los nuevos clústeres de operaciones y aplicaciones.
2. Es un clúster de operaciones regional en la región r3 donde reside el plano de control de ASM/Istio.
3. Dos clústeres de aplicaciones zonales en dos zonas de la región r3.
4. Actualiza el k8s-repo:
5. Implementa los recursos del plano de control de ASM/Istio en el clúster de operaciones de la región r3.
6. Implementa recursos del plano de control compartido de ASM/Istio en los clústeres de la app en la región r3.
7. Si bien no es necesario que crees un proyecto nuevo, los pasos del taller demuestran cómo agregar un proyecto nuevo dev3 para abarcar el caso de uso de agregar un equipo nuevo a la plataforma.

El repo de infraestructura se usa para agregar los recursos nuevos mencionados anteriormente.

1. En Cloud Shell, navega a WORKDIR y clona el repo infrastructure.

mkdir -p $WORKDIR/infra-repo
cd $WORKDIR/infra-repo
git init && git remote add origin https://source.developers.google.com/p/${TF_ADMIN}/r/infrastructure
git config --local user.email ${MY_USER}
git config --local user.name "infra repo user"
git config --local credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

2. Clona la rama add-proj del repo de código fuente del taller en el directorio add-proj-repo.

cd $WORKDIR
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git add-proj-repo -b add-proj

 

3. Copia los archivos de la rama add-proj en el repo del taller de origen. La rama add-proj contiene los cambios de esta sección.

cp -r $WORKDIR/add-proj-repo/infrastructure/* $WORKDIR/infra-repo/
 

4. Reemplaza el directorio infrastructure en el directorio del repo add-proj por un symlink al directorio infra-repo para permitir que se ejecuten las secuencias de comandos en la rama.

rm -rf $WORKDIR/add-proj-repo/infrastructure
ln -s $WORKDIR/infra-repo $WORKDIR/add-proj-repo/infrastructure
 

5. Ejecuta la secuencia de comandos add-project.sh para copiar los estados y las variables compartidos en la nueva estructura de directorio del proyecto.

$WORKDIR/add-proj-repo/scripts/add-project.sh app3 $WORKDIR/asm $WORKDIR/infra-repo

6. Confirma y envía los cambios para crear un proyecto nuevo

cd $WORKDIR/infra-repo
git add .
git status
git commit -m "add new project" && git push origin master
 

7. La confirmación activa el repositorio infrastructure para implementar la infraestructura con los recursos nuevos. Para ver el progreso de Cloud Build, haz clic en el resultado del siguiente vínculo y navega a la compilación más reciente en la parte superior.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

Este paso tarda entre 25 y 30 minutos en completarse. Es un buen momento para un descanso.

El último paso de infrastructure Cloud Build crea recursos de Kubernetes nuevos en k8s-repo. Esto activa Cloud Build en k8s-repo (en el proyecto de operaciones). Los nuevos recursos de Kubernetes son para los tres clústeres nuevos que se agregaron en el paso anterior. Los recursos del plano de control de ASM/Istio y del plano de control compartido se agregan a los clústeres nuevos con la compilación de k8s-repo Cloud Build.

8. Una vez que finalice correctamente la compilación de infraestructura de Cloud Build, navega a la ejecución más reciente de k8s-repo Cloud Build haciendo clic en el siguiente vínculo de salida.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

9. Ejecuta la siguiente secuencia de comandos para agregar los clústeres nuevos a los archivos vars y kubeconfig.

$WORKDIR/add-proj-repo/scripts/setup-gke-vars-kubeconfig-add-proj.sh $WORKDIR/asm
 

10. Cambia la variable KUBECONFIG para que apunte al nuevo archivo kubeconfig.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

11. Enumera los contextos de tu clúster. Deberías ver ocho clústeres.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_user001-200204-05-dev1-49tqc4_us-west1-a_gke-1-apps-r1a-prod
gke_user001-200204-05-dev1-49tqc4_us-west1-b_gke-2-apps-r1b-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-a_gke-3-apps-r2a-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-b_gke-4-apps-r2b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-b_gke-5-apps-r3b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-c_gke-6-apps-r3c-prod
gke_user001-200204-05-ops-49tqc4_us-central1_gke-asm-2-r2-prod
gke_user001-200204-05-ops-49tqc4_us-east1_gke-asm-3-r3-prod
gke_user001-200204-05-ops-49tqc4_us-west1_gke-asm-1-r1-prod

Verifica la instalación de Istio

12. Verifica que Istio esté instalado en el nuevo clúster de operaciones. Para ello, comprueba que todos los Pods estén en ejecución y que se hayan completado los trabajos.

kubectl --context $OPS_GKE_3 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-72g6w                  1/1     Running   0          5h12m
istio-citadel-7d8595845-hmmvj             1/1     Running   0          5h12m
istio-egressgateway-779b87c464-rw8bg      1/1     Running   0          5h12m
istio-galley-844ddfc788-zzpkl             2/2     Running   0          5h12m
istio-ingressgateway-59ccd6574b-xfj98     1/1     Running   0          5h12m
istio-pilot-7c8989f5cf-5plsg              2/2     Running   0          5h12m
istio-policy-6674bc7678-2shrk             2/2     Running   3          5h12m
istio-sidecar-injector-7795bb5888-kbl5p   1/1     Running   0          5h12m
istio-telemetry-5fd7cbbb47-c4q7b          2/2     Running   2          5h12m
istio-tracing-cd67ddf8-2qwkd              1/1     Running   0          5h12m
istiocoredns-5f7546c6f4-qhj9k             2/2     Running   0          5h12m
kiali-7964898d8c-l74ww                    1/1     Running   0          5h12m
prometheus-586d4445c7-x9ln6               1/1     Running   0          5h12m

13. Asegúrate de que Istio esté instalado en ambos clústeres de dev3. Solo Citadel, sidecar-injector y coredns se ejecutan en los clústeres dev3. Comparten un plano de control de Istio que se ejecuta en el clúster ops-3.

kubectl --context $DEV3_GKE_1 get pods -n istio-system
kubectl --context $DEV3_GKE_2 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

Verifica el descubrimiento de servicios para los planos de control compartidos

14. Verifica que los secretos se implementen en todos los clústeres de operaciones para los seis clústeres de aplicaciones.

kubectl --context $OPS_GKE_1 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_2 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_3 get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      14h
gke-2-apps-r1b-prod   Opaque   1      14h
gke-3-apps-r2a-prod   Opaque   1      14h
gke-4-apps-r2b-prod   Opaque   1      14h
gke-5-apps-r3b-prod   Opaque   1      5h12m
gke-6-apps-r3c-prod   Opaque   1      5h12m

13. Interrupción de circuitos

Objetivo: Implementar un disyuntor para el servicio de envío.

• Crea un DestinationRule para el servicio shipping para implementar un disyuntor
• Usa fortio (una utilidad de generación de carga) para validar el disyuntor del servicio shipping forzando el disparo del circuito.

Instrucciones del lab de Fast Track Script

El Fast Track Script Lab estará disponible próximamente.

Instrucciones del lab sobre el método de copiar y pegar

Ahora que aprendimos algunas estrategias básicas de supervisión y solución de problemas para los servicios habilitados para Istio, veamos cómo Istio te ayuda a mejorar la resistencia de tus servicios, lo que reduce la cantidad de problemas que deberás solucionar en primer lugar.

Una arquitectura de microservicios introduce el riesgo de fallas en cascada, en las que la falla de un servicio puede propagarse a sus dependencias y a las dependencias de esas dependencias, lo que provoca una interrupción con un "efecto dominó" que puede afectar a los usuarios finales. Istio proporciona una política de tráfico de Circuit Breaker para ayudarte a aislar los servicios, proteger los servicios posteriores (del cliente) de la espera en servicios con errores y proteger los servicios anteriores (del servidor) de una repentina avalancha de tráfico posterior cuando vuelvan a estar en línea. En general, el uso de Circuit Breakers puede ayudarte a evitar que todos tus servicios no cumplan con sus SLOs debido a un servicio de backend que se bloquea.

El patrón de disyuntor recibe su nombre de un interruptor eléctrico que puede "activarse" cuando fluye demasiada electricidad, lo que protege los dispositivos de la sobrecarga. En una configuración de Istio, esto significa que Envoy es el disyuntor, que realiza un seguimiento de la cantidad de solicitudes pendientes para un servicio. En este estado cerrado predeterminado, las solicitudes fluyen a través de Envoy sin interrupciones.

Sin embargo, cuando la cantidad de solicitudes pendientes supera el umbral definido, el disyuntor se activa (se abre) y Envoy muestra un error de inmediato. Esto permite que el servidor falle rápidamente para el cliente y evita que el código de la aplicación del servidor reciba la solicitud del cliente cuando está sobrecargado.

Luego, después del tiempo de espera definido, Envoy pasa a un estado semiabierto, en el que el servidor puede comenzar a recibir solicitudes nuevamente de forma provisional. Si puede responder a las solicitudes correctamente, el disyuntor se cierra nuevamente y las solicitudes al servidor comienzan a fluir de nuevo.

En este diagrama, se resume el patrón de disyuntor de Istio. Los rectángulos azules representan Envoy, el círculo relleno de azul representa el cliente y los círculos rellenos de blanco representan el contenedor del servidor:

Puedes definir políticas de disyuntor con Istio DestinationRules. En esta sección, aplicaremos la siguiente política para aplicar un disyuntor al servicio de envío:

Output (do not copy)

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "shippingservice-shipping-destrule"
  namespace: "shipping"
spec:
  host: "shippingservice.shipping.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 10s
      maxEjectionPercent: 100

Aquí hay dos campos DestinationRule que debes tener en cuenta. connectionPool define la cantidad de conexiones que permitirá este servicio. El campo outlierDetection es donde configuramos cómo Envoy determinará el umbral en el que se abrirá el disyuntor. Aquí, cada segundo (intervalo), Envoy contará la cantidad de errores que recibió del contenedor del servidor. Si supera el umbral de consecutiveErrors, se abrirá el disyuntor de Envoy y el 100% de los pods de productcatalog se protegerán de las solicitudes de clientes nuevos durante 10 segundos. Una vez que el disyuntor de Envoy esté abierto (es decir, activo), los clientes recibirán errores 503 (Servicio no disponible). Veamos esto en acción.

1. Configura variables de entorno para los directorios k8s-repo y asm para simplificar los comandos.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm" 
 

2. Actualiza k8s-repo

cd $WORKDIR/k8s-repo
git pull
cd $WORKDIR

3. Actualiza el DestinationRule del servicio de envío en ambos clústeres de Ops.

cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
 

4. Copia un pod generador de carga de Fortio en el clúster GKE_1 de la región Dev1. Este es el pod del cliente que usaremos para "activar" el disyuntor de shippingservice.

cp $ASM/k8s_manifests/prod/app/deployments/app-fortio.yaml ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments/
cd ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments; kustomize edit add resource app-fortio.yaml
 

5. Confirma los cambios.

cd $K8S_REPO 
git add . && git commit -am "Circuit Breaker: shippingservice"
git push
cd $ASM
 

6. Espera a que se complete Cloud Build.
7. De vuelta en Cloud Shell, usa el pod de Fortio para enviar tráfico de gRPC a shippingservice con 1 conexión simultánea y 1, 000 solicitudes en total. Esto no activará el disyuntor, ya que aún no superamos la configuración de connectionPool.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 1 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Resultado (no lo copie)

Health SERVING : 1000
All done 1000 calls (plus 0 warmup) 4.968 ms avg, 201.2 qps

8. Ahora, vuelve a ejecutar fortio, pero aumenta la cantidad de conexiones simultáneas a 2 y mantén constante la cantidad total de solicitudes. Deberíamos ver que hasta dos tercios de las solicitudes devuelven un error de "desbordamiento", porque se activó el disyuntor: En la política que definimos, solo se permite 1 conexión simultánea en un intervalo de 1 segundo.

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 2 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Resultado (no lo copie)

18:46:16 W grpcrunner.go:107> Error making grpc call: rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: overflow
...

Health ERROR : 625
Health SERVING : 375
All done 1000 calls (plus 0 warmup) 12.118 ms avg, 96.1 qps

9. Envoy realiza un seguimiento de la cantidad de conexiones que se descartaron cuando el disyuntor está activo con la métrica upstream_rq_pending_overflow. Busquemos esto en el pod de fortio:

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep shipping | grep pending
 

Resultado (no lo copie)

cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_failure_eject: 9
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_overflow: 565
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_total: 1433

10. Borra la política de disyuntor de ambas regiones para realizar una limpieza.

kubectl --context ${OPS_GKE_1} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
 

kubectl --context ${OPS_GKE_2} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
cd $K8S_REPO; git add .; git commit -m "Circuit Breaker: cleanup"; git push origin master
 

En esta sección, se mostró cómo configurar una sola política de disyuntores para un servicio. Una práctica recomendada es configurar un disyuntor para cualquier servicio upstream (de backend) que pueda colgarse. Si aplicas políticas de disyuntores de Istio, podrás aislar tus microservicios, incorporar tolerancia a fallas en tu arquitectura y reducir el riesgo de fallas en cascada con una carga alta.

14. Inserción de fallas

Objetivo: Probar la resiliencia del servicio de recomendaciones introduciendo retrasos (antes de que se envíe a producción).

• Crea un VirtualService para el servicio recommendation para introducir una demora de 5 s.
• Prueba la demora con el generador de cargas fortio
• Quita la demora en VirtualService y valida

Instrucciones del lab de Fast Track Script

El Fast Track Script Lab estará disponible próximamente.

Instrucciones del lab sobre el método de copiar y pegar

Agregar políticas de disyuntores a tus servicios es una forma de generar resiliencia contra los servicios en producción. Sin embargo, la interrupción del circuito genera fallas (posiblemente errores visibles para el usuario), lo que no es ideal. Para adelantarte a estos casos de error y predecir mejor cómo podrían responder tus servicios descendentes cuando los backends devuelvan errores, puedes adoptar las pruebas de caos en un entorno de etapa de pruebas. Las pruebas de caos son la práctica de interrumpir deliberadamente tus servicios para analizar los puntos débiles del sistema y mejorar la tolerancia a errores. También puedes usar las pruebas de caos para identificar formas de mitigar los errores que ven los usuarios cuando fallan los back-ends, por ejemplo, mostrando un resultado almacenado en caché en un front-end.

Usar Istio para la inserción de fallas es útil porque puedes usar tus imágenes de versiones de producción y agregar la falla en la capa de red, en lugar de modificar el código fuente. En producción, puedes usar una herramienta de prueba de caos completa para probar la resiliencia en la capa de Kubernetes o de procesamiento, además de la capa de red.

Puedes usar Istio para realizar pruebas de caos aplicando un VirtualService con el campo "fault". Istio admite dos tipos de fallas: fallas de retraso (inyectan un tiempo de espera) y fallas de anulación (inyectan errores HTTP). En este ejemplo, insertaremos una falla de retraso de 5 segundos en el servicio de recomendaciones. Sin embargo, esta vez, en lugar de usar un disyuntor para "fallar rápido" contra este servicio que se cuelga, forzaremos a los servicios descendentes a soportar el tiempo de espera completo.

11. Navega al directorio de inserción de fallas.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm/" 
cd $ASM
 

12. Abre k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml para inspeccionar su contenido. Ten en cuenta que Istio tiene una opción para insertar la falla en un porcentaje de las solicitudes. Aquí, introduciremos un tiempo de espera en todas las solicitudes de recommendationservice.

Resultado (no lo copie)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation-delay-fault
spec:
  hosts:
  - recommendationservice.recommendation.svc.cluster.local
  http:
  - route:
    - destination:
        host: recommendationservice.recommendation.svc.cluster.local
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 5s

13. Copia el VirtualService en k8s_repo. Insertaremos la falla de forma global en ambas regiones.

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml
 

14. Envía los cambios

cd $K8S_REPO 
git add . && git commit -am "Fault Injection: recommendationservice"
git push
cd $ASM
 

15. Espera a que se complete Cloud Build.
16. Ejecuta el pod de fortio implementado en la sección del disyuntor y envía algo de tráfico a recommendationservice.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 100 -n 100 -qps 0 recommendationservice.recommendation.svc.cluster.local:8080
 

    Once the fortio command is complete, you should see responses averaging 5s:

Resultado (no lo copie)

Ended after 5.181367359s : 100 calls. qps=19.3
Aggregated Function Time : count 100 avg 5.0996506 +/- 0.03831 min 5.040237641 max 5.177559818 sum 509.965055

17. Otra forma de ver la falla que insertamos en acción es abrir el frontend en un navegador web y hacer clic en cualquier producto. Una página de producto debería tardar 5 segundos adicionales en cargarse, ya que recupera las recomendaciones que se muestran en la parte inferior de la página.
18. Quita el servicio de inserción de fallas de ambos clústeres de Ops para realizar una limpieza.

kubectl --context ${OPS_GKE_1} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml

kubectl --context ${OPS_GKE_2} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml
 

19. Envía los cambios:

cd $K8S_REPO 
git add . && git commit -am "Fault Injection cleanup / restore"
git push
cd $ASM
 

15. Supervisa el plano de control de Istio

ASM instala cuatro componentes importantes del plano de control: Pilot, Mixer, Galley y Citadel. Cada uno envía sus métricas de supervisión pertinentes a Prometheus, y ASM se entrega con paneles de Grafana que permiten a los operadores visualizar estos datos de supervisión y evaluar el estado y el rendimiento del plano de control.

Cómo visualizar los paneles

20. Redirecciona el puerto de tu servicio de Grafana instalado con Istio

kubectl --context ${OPS_GKE_1} -n istio-system port-forward svc/grafana 3000:3000 >> /dev/null
 

21. Abre Grafana en tu navegador
22. Haz clic en el ícono de "Vista previa en la Web" en la esquina superior derecha de la ventana de Cloud Shell.
23. Haz clic en Vista previa en el puerto 3000 (nota: Si el puerto no es 3000, haz clic en Cambiar puerto y selecciona el puerto 3000).
24. Se abrirá una pestaña en tu navegador con una URL similar a "BASE_URL/?orgId=1&authuser=0&environment_id=default".
25. Cómo ver los paneles disponibles
26. Modifica la URL a "BASE_URL/dashboard".
27. Haz clic en la carpeta "istio" para ver los paneles disponibles.
28. Haz clic en cualquiera de esos paneles para ver el rendimiento de ese componente. En las siguientes secciones, analizaremos las métricas importantes para cada componente.

Prueba piloto de supervisión

Pilot es el componente del plano de control que distribuye la configuración de redes y políticas al plano de datos (los proxies de Envoy). Pilot tiende a escalar con la cantidad de cargas de trabajo y de implementaciones, aunque no necesariamente con la cantidad de tráfico hacia esas cargas de trabajo. Un piloto en mal estado puede hacer lo siguiente:

• consumir más recursos de los necesarios (CPU o RAM)
• provocan retrasos en la transmisión de la información de configuración actualizada a los proxies de Envoy

Nota: Si Pilot está inactivo o hay demoras, tus cargas de trabajo seguirán publicando tráfico.

23. Navega a "BASE_URL/dashboard/db/istio-pilot-dashboard" en tu navegador para ver las métricas de Pilot.

Métricas supervisadas importantes

Uso de recursos

Usa la página de rendimiento y escalabilidad de Istio como guía para conocer las cifras de uso aceptables. Comunícate con el equipo de asistencia de GCP si observas un uso de recursos sostenido significativamente mayor que este.

Información de la prueba piloto de notificaciones push

En esta sección, se supervisan las transmisiones de versiones piloto de la configuración a tus proxies de Envoy.

• En Pilot Pushes, se muestra el tipo de configuración que se envió en un momento determinado.
• Supervisión de ADS muestra la cantidad de servicios virtuales, servicios y extremos conectados en el sistema.
• Clusters with no known endpoints muestra los extremos que se configuraron, pero no tienen instancias en ejecución (lo que puede indicar servicios externos, como *.googleapis.com).
• En Pilot Errors, se muestra la cantidad de errores que se encontraron con el tiempo.
• Conflicts muestra la cantidad de conflictos que son parámetros de configuración ambiguos en los objetos de escucha.

Si tienes errores o conflictos, significa que tienes una configuración incorrecta o incoherente para uno o más de tus servicios. Consulta Solución de problemas del plano de datos para obtener más información.

Envoy Information

En esta sección, se incluye información sobre los proxies de Envoy que se comunican con el plano de control. Comunícate con el equipo de asistencia de GCP si ves errores de conexión de XDS repetidos.

Mezclador de Monitoring

Mixer es el componente que canaliza la telemetría de los proxies de Envoy a los backends de telemetría (por lo general, Prometheus, Stackdriver, etcétera). En esta capacidad, no se encuentra en el plano de datos. Se implementa como dos trabajos de Kubernetes (llamados Mixer) con dos nombres de servicio diferentes (istio-telemetry y istio-policy).

Mixer también se puede usar para integrarse con sistemas de políticas. En esta capacidad, Mixer sí afecta el plano de datos, ya que las verificaciones de políticas que fallan en Mixer bloquean el acceso a tus servicios.

El mezclador tiende a escalar con el volumen de tráfico.

24. Navega a "BASE_URL/dashboard/db/istio-mixer-dashboard" en tu navegador para ver las métricas de Mixer.

Métricas importantes supervisadas

Uso de recursos

Usa la página de rendimiento y escalabilidad de Istio como guía para conocer las cifras de uso aceptables. Comunícate con el equipo de asistencia de GCP si observas un uso de recursos sostenido significativamente mayor que este.

Descripción general del mezclador

• La duración de la respuesta es una métrica importante. Si bien los informes a la telemetría de Mixer no se encuentran en la ruta de datos, si estas latencias son altas, definitivamente se ralentizará el rendimiento del proxy de sidecar. Se espera que el percentil 90 esté en milisegundos de un solo dígito y que el percentil 99 sea inferior a 100 ms.

• La métrica Adapter Dispatch Duration indica la latencia que experimenta Mixer al llamar a los adaptadores (a través de los cuales envía información a los sistemas de registro y telemetría). Las latencias altas aquí afectarán absolutamente el rendimiento en la malla. Nuevamente, las latencias del percentil 90 deben ser inferiores a 10 ms.

Galería de supervisión

Galley es el componente de validación, transferencia, procesamiento y distribución de la configuración de Istio. Transmite la configuración del servidor de la API de Kubernetes a Pilot. Al igual que Pilot, tiende a escalar con la cantidad de servicios y extremos del sistema.

25. Navega a "BASE_URL/dashboard/db/istio-galley-dashboard" en tu navegador para ver las métricas de Galley.

Métricas importantes supervisadas

Validación de recursos

Es la métrica más importante que se debe seguir, ya que indica la cantidad de recursos de varios tipos, como reglas de destino, puertas de enlace y entradas de servicio, que superan o no la validación.

Clientes conectados

Indica cuántos clientes están conectados a Galley. Por lo general, serán 3 (pilot, istio-telemetry, istio-policy) y se ajustarán a medida que se ajusten esos componentes.

16. Solución de problemas de Istio

Solución de problemas del plano de datos

Si tu panel de Piloto indica que tienes problemas de configuración, debes examinar los registros de Piloto o usar istioctl para encontrar problemas de configuración.

Para examinar los registros de Pilot, ejecuta kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery y reemplaza istio-pilot… con el identificador del pod de la instancia de Pilot para la que deseas solucionar problemas.

En el registro resultante, busca un mensaje de Push Status. Por ejemplo:

2019-11-07T01:16:20.451967Z        info        ads        Push Status: {
    "ProxyStatus": {
        "pilot_conflict_outbound_listener_tcp_over_current_tcp": {
            "0.0.0.0:443": {
                "proxy": "cartservice-7555f749f-k44dg.hipster",
                "message": "Listener=0.0.0.0:443 AcceptedTCP=accounts.google.com,*.googleapis.com RejectedTCP=edition.cnn.com TCPServices=2"
            }
        },
        "pilot_duplicate_envoy_clusters": {
            "outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            }
        },
        "pilot_eds_no_instances": {
            "outbound_.80_._.frontend-external.hipster.svc.cluster.local": {},
            "outbound|443||*.googleapis.com": {},
            "outbound|443||accounts.google.com": {},
            "outbound|443||metadata.google.internal": {},
            "outbound|80||*.googleapis.com": {},
            "outbound|80||accounts.google.com": {},
            "outbound|80||frontend-external.hipster.svc.cluster.local": {},
            "outbound|80||metadata.google.internal": {}
        },
        "pilot_no_ip": {
            "loadgenerator-778c8489d6-bc65d.hipster": {
                "proxy": "loadgenerator-778c8489d6-bc65d.hipster"
            }
        }
    },
    "Version": "o1HFhx32U4s="
}

El estado de envío indicará cualquier problema que haya ocurrido al intentar enviar la configuración a los proxies de Envoy. En este caso, vemos varios mensajes de "Clúster duplicado", que indican destinos upstream duplicados.

Para obtener ayuda con el diagnóstico de problemas, comunícate con el equipo de asistencia de Google Cloud.

Cómo encontrar errores de configuración

Para usar istioctl y analizar tu configuración, ejecuta istioctl experimental analyze -k --context $OPS_GKE_1. Esto realizará un análisis de la configuración de tu sistema, indicará cualquier problema y sugerirá los cambios correspondientes. Consulta la documentación para obtener una lista completa de los errores de configuración que puede detectar este comando.

17. Limpieza

Un administrador realiza los siguientes pasos después de que finaliza el taller.

Un administrador ejecuta la secuencia de comandos cleanup_workshop.sh para borrar los recursos creados por la secuencia de comandos bootstrap_workshop.sh. Necesitas la siguiente información para ejecutar la secuencia de comandos de limpieza.

• Nombre de la organización, por ejemplo, yourcompany.com
• ID del taller: Por ejemplo, YYMMDD-NN en el formato 200131-01
• Bucket de GCS del administrador: Se define en la secuencia de comandos de arranque.

13. Abre Cloud Shell y realiza todas las acciones que se indican a continuación en Cloud Shell. Haz clic en el siguiente vínculo.

CLOUD SHELL

14. Verifica que accediste a gcloud con el usuario administrador previsto.

gcloud config list
 

15. Navega a la carpeta asm.

cd ${WORKDIR}/asm
 

16. Define el nombre de tu organización y el ID del taller que se borrará.

export ORGANIZATION_NAME=<ORGANIZATION NAME>
export ASM_WORKSHOP_ID=<WORKSHOP ID>
export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

17. Ejecuta la secuencia de comandos de limpieza de la siguiente manera.

./scripts/cleanup_workshop.sh --workshop-id ${ASM_WORKSHOP_ID} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --org-name ${ORGANIZATION_NAME}