Taller de Anthos Service Mesh: guía del lab

1. TALLER DE ALFA

NOTA IMPORTANTE: ESTE ES UN TALLER DE ALFA Y ESTÁ ESTRICTAMENTE INTELIGENTE PARA SER UNA CAPACITACIÓN EN EL AULA POR 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 inmersiva en la que se explica cómo configurar servicios distribuidos a nivel global en GCP para producción. Las tecnologías principales 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 la 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: Configuración de la infraestructura: Flujo de trabajo del usuario
• Receso
• QnA
• Módulo 1: Instala, protege y supervisa aplicaciones con ASM
• Modelo de repositorio: Explicación de los repositorios de Kubernetes y la infraestructura
• Lab: Implementa la aplicación de muestra
• Servicios distribuidos y observabilidad
• Almuerzo
• Lab: Observabilidad con Stackdriver
• QNA
• Módulo 2: DevOps: lanzamientos de versiones canary, políticas/RBAC
• Descubrimiento de servicios de varios clústeres y seguridad/política
• Lab: TLS mutua
• Implementaciones de versiones canary
• Lab: Implementaciones de versiones canary
• Balanceo de cargas global seguro de varios clústeres
• Receso
• Lab: Política de autorización
• QNA
• Módulo 3: Operaciones de infraestructura, Actualizaciones de la plataforma
• Componentes básicos del servicio distribuido
• Lab: Escalamiento 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

Para continuar con este taller, se requiere lo siguiente:

1. Un nodo de la 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 el usuario

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

Los pasos de esta sección están a cargo de un administrador que crea el taller.

Si eres un usuario que está realizando el taller, pasa a la siguiente sección etiquetada como Infrastructure Setup - User Workflow.

Explicación del guion del taller de arranque

Se usa una secuencia de comandos llamada bootstrap_workshop.sh para configurar el entorno inicial del taller. Puedes usar esta secuencia de comandos a fin de configurar un solo entorno para ti o varios entornos para varios usuarios, en caso de que estés dando este taller como capacitación a varios usuarios.

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

• Nombre de la organización (por ejemplo, yourcompany.com): Es la organización en la que creas los 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 utiliza en caso de que estés realizando varios talleres en un día y desees realizar un seguimiento de ellos por separado. Los números de los talleres también se usan para derivar los IDs de los proyectos. Tener números de taller separados facilita la tarea de obtener IDs de proyecto únicos cada vez. Además del número de taller, también se usa la fecha actual (con el formato YYMMDD) para los IDs de los proyectos. La combinación de fecha y número de taller proporciona IDs de proyecto únicos.
• Número de usuario inicial (por ejemplo, 1): Este número representa el primer usuario del taller. Por ejemplo, si quieres crear un taller para 10 usuarios, puedes tener un número de usuario inicial de 1 y un número de usuario final de 10.
• Número de usuario final (por ejemplo, 10): Este número indica el último usuario que participó en el taller. Por ejemplo, si quieres crear un taller para 10 usuarios, puedes tener un número de usuario inicial de 1 y un número de usuario final de 10. Si configuras un solo entorno (por ejemplo, para ti), asegúrate de que el número de usuario inicial y final sea el mismo. Esto creará un entorno único.

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 User schema and permissions performing the workshop.

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

La secuencia de comandos del taller de arranque usa los valores proporcionados anteriormente y actúa como una secuencia de comandos 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.

Permisos de administrador necesarios para iniciar el taller

Hay dos tipos de usuarios en este taller. Un ADMIN_USER, que crea y borra recursos para este taller. El segundo es MY_USER, que realiza los pasos del taller. MY_USER solo tiene acceso a sus propios recursos. ADMIN_USER tiene acceso a todas las configuraciones del usuario. Si estás creando esta configuración por tu cuenta, 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: Otorga la capacidad de 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: Posibilidad de crear proyectos en la organización.
• Eliminador de proyectos: Capacidad de borrar proyectos en la organización.
• Administrador de IAM de proyecto: Capacidad de crear reglas de IAM en todos los proyectos de la organización.

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

Esquema y permisos de usuarios para realizar el taller

Si tienes pensado crear este taller para usuarios (que no sean tú) en tu organización, debes seguir un esquema de nombres de usuarios específico para MY_USERs. Durante la secuencia de comandos bootstrap_workshop.sh, proporcionas un número de inicio y un número de usuario final. Estos números se utilizan 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 arranque con el número de usuario inicial de 1 y el número de usuario final de 3, en tu organización llamada tuempresa.com, se crean 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 los proyectos específicos que se crearon durante la secuencia de comandos setup_terraform_admin_project.sh. Debes cumplir con este esquema de nombres de usuarios 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 (ver >= 270)
• kubectl
• sed (funciona con sed en Cloud Shell/Linux y no con Mac OS)
• git (asegúrate de estar actualizado)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• acumular

Todas las herramientas, excepto kustomize, ya están instaladas de forma predeterminada en Cloud Shell. Si kustomize no está instalado, instálalo con la secuencia de comandos bash proporcionada en el vínculo anterior y asegúrate de que el objeto binario de Kustomize esté en tu ruta de acceso. Para confirmar, ejecuta el comando kustomize en Cloud Shell.

Crea un taller para ti (configuración para 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 organizar 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 necesitas definir el número de usuario inicial y final, ya que lo harás tú mismo.

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 terraform admin project. El proyecto de administrador de Terraform se usa para crear el resto de los recursos de GCP necesarios para este taller. Habilita las APIs necesarias en el proyecto de administración de Terraform. Usas Cloud Build para aplicar planes de Terraform. Otorga los roles de IAM adecuados a la cuenta de servicio de Cloud Build 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 en todos los recursos de GCP.

Para ver las tareas de Cloud Build en el proyecto terraform admin, necesitas el ID del proyecto terraform admin. Esto se almacena en el archivo vars/vars.sh, en el directorio asm. Este directorio solo se conserva si estás configurando el taller para ti mismo como administrador.

6. Obtén el archivo de variables para establecer variables de entorno

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

Organización de un taller para múltiples 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 usuario inicial y final, y un bucket de GCS de administrador para usar en el taller. Revisa los permisos necesarios para organizar 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 taller.txt del bucket de administrador de GCS para recuperar los IDs de los proyectos de Terraform.

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

4. Configuración y preparación para el lab

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

Elige la ruta del lab

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

• Los "scripts interactivos fáciles y rápidos" manera
• La opción "copiar y pegar manualmente cada instrucción" manera

El método de secuencias de comandos de seguimiento rápido te permite ejecutar una sola secuencia de comandos interactiva para cada lab que te guía en el lab mediante la ejecución automática de los comandos para ese lab. Los comandos se ejecutan por lotes con explicaciones concisas de cada paso y lo que logran. Después de cada lote, se te solicitará que continúes con el siguiente lote de comandos. De este modo, podrás realizar los labs a tu ritmo. Las secuencias de comandos de seguimiento rápido son idempotentes, lo que significa que puedes ejecutarlas varias veces, lo que genera el mismo resultado.

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

GUION DE LA 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 está diseñado para ejecutarse una vez. No se garantiza 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 seleccionar un método y realizar los pasos en ese método, no realices pasos en el otro.

Configuración rápida de la secuencia de comandos

Una vez que completes la secuencia de comandos de pista rápida, habrás terminado con ese lab. No sigas los pasos que se indican en las instrucciones del lab de copiar y pegar.

Obtén información de los usuarios

Este taller se realiza con una cuenta de usuario temporal (o una cuenta de lab) creada por el administrador del taller. Todos los proyectos del taller son propiedad de la cuenta del lab. 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 del 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 del lab que proporcionó 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 la credencial de tu cuenta del 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 con tu cuenta personal o corporativa). La cuenta del lab es similar a userXYZ@<workshop_domain>.com.
3. Como esta es 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 Debian de Linux para que la uses cuando accedas a los recursos de GCP. Cada cuenta obtiene una VM de Cloud Shell. Si accedes con la cuenta del lab, se aprovisionará y 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étera). De forma predeterminada, la pantalla de Cloud Shell se divide en el entorno de shell de Cloud Shell (en la parte inferior) y en el editor de Cloud Code (en la parte superior). El lápiz y los íconos de shell en la esquina superior derecha te permiten alternar entre los dos (shell y editor de código). También puedes arrastrar la barra separadora del medio (hacia arriba o abajo) y cambiar el tamaño de cada ventana manualmente. 5. Crea un WORKDIR para este taller. El WORKDIR es una carpeta desde la que se realizan todos los labs de este taller. Ejecuta los siguientes comandos en Cloud Shell para crear el WORKDIR.

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

6. Exporta el usuario de la cuenta del lab como una variable que se usará 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 preparas el taller por tu cuenta con el comando "-sufa", o “–setup-for-admin” marcas y, luego, establecen MY_USER en el correo electrónico de la cuenta de GCP que usaste para crear los proyectos del taller.

7. Copia las variables WORKDIR y MY_USER para asegurarte de que ambas estén configuradas correctamente mediante la ejecución de los siguientes comandos.

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 las herramientas del taller
• Repositorio del taller de clones
• Verifica la instalación de Infrastructure
• Verifica la instalación de k8s-repo
• Verifica la instalación de Istio

GUION DE LA 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

Cuando 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 rápida de este lab, no uses el método de copiar y pegar que aparece a continuación**.**

Obtén información de los usuarios

El administrador que organiza el taller debe proporcionarle al usuario la información de nombre de usuario y contraseña. Todos los proyectos del usuario tendrán el prefijo del nombre de usuario. Por ejemplo, para el usuario [e-mail], el ID de proyecto del 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 instrucciones para instalarlos.

• gcloud (ver >= 270)
• kubectl
• sed (funciona con sed en Cloud Shell/Linux y no con Mac OS)
• git (asegúrate de estar actualizado)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• acumular
• pv

Acceder 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 terraform admin project. 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 terraform admin. Cloud Build se usa para aplicar planes de Terraform. Con la secuencia de comandos, le asignas los roles de IAM adecuados a la cuenta de servicio de Cloud Build para que pueda crear recursos en GCP. Por último, se configura un backend remoto en un bucket de Google Cloud Storage (GCS) para almacenar estados de Terraform para todos los recursos de GCP.

Para ver las tareas de Cloud Build en el proyecto terraform admin, necesitas el ID del proyecto terraform admin. Esto se almacena en el bucket de administrador de GCS que se especificó en la secuencia de comandos de arranque. Si ejecutas la secuencia de comandos de arranque para varios usuarios, todos los IDs de proyectos del administrador de Terraform se encuentran 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 diferentes.

1. Abre Cloud Shell (si no está abierto desde la sección Configuración y preparación del lab) haciendo clic en el siguiente vínculo.

CLOUD SHELL

2. Instala kustomize (si aún no está instalado) 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 tu prompt 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. Ejecuta el siguiente comando para obtener el ID del proyecto de administrador de Terraform:

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 almacenado en un bucket de GCS en el proyecto de Terraform Admin. 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 administrador de Terraform y verificar 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 accedes a la consola de Cloud por primera vez, acepta las Condiciones del Servicio de Google.

9. Ahora que estás viendo la página Cloud Build, haz clic en el vínculo History en el panel de navegación izquierdo 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 el network host project para la VPC compartida. No se crean otros recursos en este proyecto.
• Un proyecto es el ops project que se usa para los clústeres de GKE del plano de control de Istio.
• Dos proyectos representan 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 repositorio 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 mediante GitOps.
• Se crea un activador de Cloud Build para que, cada vez que haya una confirmación con la rama principal de k8s-repo, implemente 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 verificar que k8s-repo Cloud Build se haya completado correctamente.

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

Nota: Se debe completar esta compilación para poder 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
 

Esta secuencia de comandos crea un nuevo archivo kubeconfig en la carpeta gke llamado kubemesh.

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

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

13. Agrega las variables vars.sh y KUBECONFIG al archivo .bashrc en Cloud Shell para obtener la fuente 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. Obtén una lista de los contextos del 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. Asegúrate de que Istio esté instalado en ambos clústeres. Para ello, verifica 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 dev1. Solo Citadel, el inyector de sidecar y el 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 dev2. Solo Citadel, el inyector de sidecar y el 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 la detección de servicios para los planos de control compartidos

18. De manera opcional, verifica que los Secrets estén implementados.

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 única VPC compartida en la que se crearán todos los clústeres de GKE. Para descubrir servicios en los clústeres, usa los archivos kubeconfig (para cada uno de los clústeres de la aplicación) creados como secretos en los clústeres de operaciones. Pilot usa estos Secrets para descubrir Services consultando al servidor de la API de Kube de los clústeres de aplicaciones (autenticados mediante los Secrets anteriores). Verás que ambos clústeres de operaciones pueden autenticarse en todos los clústeres de la app 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 piloto de 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 conectarse con los servidores de la API de Kube, debes agregar manualmente servicios remotos como ServiceEntries. Puedes pensar en ServiceEntries como entradas DNS en tu registro de servicio. ServiceEntries define un servicio con un nombre de DNS completamente calificado ( FQDN) y una dirección IP a la que se puede acceder. Consulta la documentación de varios clústeres de Istio para obtener más información.

6. Explicación del repositorio de infraestructura

Infraestructura de Cloud Build

Los recursos de GCP para el taller se crean con Cloud Build y un repositorio de CSR de infrastructure. Acabas de ejecutar una secuencia de comandos de arranque (ubicada en scripts/bootstrap_workshop.sh) desde tu terminal local. La secuencia de comandos de arranque 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 administración de Terraform se usa para almacenar estados, registros y secuencias de comandos varias de Terraform. Contiene los repositorios de CSR infrastructure y k8s_repo. Estos repositorios se explican en detalle en la siguiente sección. No se compilan otros recursos de taller en el proyecto de administración de Terraform. La cuenta de servicio de Cloud Build en el proyecto de Terraform Admin se usa para crear recursos para el taller.

Se usa un archivo cloudbuild.yaml ubicado en la carpeta infrastructure para compilar los 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. La imagen del compilador personalizado ejecuta terraform plan y apply para cada recurso. Los archivos de Terraform de cada recurso se ubican en carpetas separadas (los detalles se encuentran en la siguiente sección). Los recursos se compilan uno a la vez y en el orden en que se crearí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 hay una confirmación con el repositorio infrastructure. Cualquier cambio que se realice en la infraestructura se almacena como Infraestructura como código (IaC) y se confirma en el repositorio. El estado de tu taller siempre se almacena en este repositorio.

Estructura de carpetas: equipos, entornos y recursos

El repositorio de infraestructura configura los recursos de infraestructura de GCP para el taller. Se estructura en carpetas y subcarpetas. Las carpetas base dentro del repositorio representan los team que poseen recursos específicos de GCP. La siguiente capa de carpetas representa el environment específico del equipo (por ejemplo, desarrollo, etapa de pruebas o producción). La siguiente capa de carpetas dentro del entorno representa el resource específico (por ejemplo, host_project, gke_clusters, etcétera). Las secuencias de comandos y los archivos de Terraform necesarios existen dentro de las carpetas de recursos.

En este taller, están representados los siguientes cuatro tipos de equipos:

1. infraestructura: Representa al equipo de infraestructura de nube. Son responsables de crear los recursos de GCP para todos los demás equipos. Para sus recursos, usa el proyecto de administrador de Terraform. El repositorio de infraestructura se encuentra en el proyecto de administración de Terraform y en los archivos de estado de Terraform (que se explican a continuación). Estos recursos se crean mediante una secuencia de comandos de Bash durante el proceso de arranque (para obtener más información, consulta el Módulo 0: Flujo de trabajo del administrador).
2. network: Representa al equipo de herramientas de redes. Son responsables de la VPC y los recursos de red. Son propietarios de los siguientes recursos de GCP.
3. host project: Representa el proyecto host de 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/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 operaciones de GKE 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 repositorio 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 apps obtiene su propio conjunto de proyectos. Esto les permite controlar la facturación y la IAM de su proyecto específico.
11. gke clusters: Estos son clústeres de aplicación 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, la app1 tiene algunas instancias de GCE en las que se ejecuta parte de la aplicación.

En este taller, la misma app (hipster Shop) representa a las apps 1 y 2.

Proveedor, estados y resultados: Backends y estados compartidos

Los proveedores google y google-beta se encuentran en gcp/[environment]/gcp/provider.tf. El archivo provider.tf tiene un symlink en cada carpeta de recursos. Esto te permite cambiar el proveedor en un solo lugar, en lugar de administrar individualmente los proveedores para cada recurso.

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 respectiva. 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 del administrador de Terraform.

Los recursos con valores interdependientes contienen un archivo output.tf. Los valores de salida necesarios 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 envía a través de output.tf al 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 (o archivos) shared_state_[resource_name].tf 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 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 recursos Los archivos shared_state se colocan en la carpeta gcp/[environment]/shared_states. Los archivos shared_state necesarios tienen symlink en las carpetas de recursos respectivas. Si colocas todos los archivos shared_state en una carpeta y los vinculas con symlinks a las carpetas de recursos correspondientes, será más fácil administrar todos los archivos de estado en un solo lugar.

Variables

Todos los valores de recursos se almacenan como variables de entorno. Estas variables se almacenan (como sentencias de exportación) en un archivo llamado vars.sh ubicado 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 del proyecto, los detalles del clúster de GKE, etc. 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 K8s

k8s_repo es un repositorio de CSR (independiente del repositorio de infraestructura) ubicado en el proyecto de administración 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 infraestructura de Cloud Build, se crea un total de seis clústeres de GKE. En k8s_repo, se crean seis carpetas. Cada carpeta (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 compilación de infraestructura, 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 hay una confirmación en el repositorio k8s_repo. Al igual que en 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 equipo) de tu empresa. Los equipos (de tu organización) responsables de diferentes proyectos, productos o recursos usan diferentes proyectos de GCP. Tener proyectos independientes te permite crear conjuntos distintos de permisos de IAM y administrar la facturación a nivel de proyecto. Además, las cuotas también se administran a nivel de proyecto.

En este taller, están representados cinco equipos, cada uno con su propio proyecto.

1. El equipo de infraestructura que crea recursos de GCP usa Terraform admin project. Administran la infraestructura como código en un repositorio de CSR (llamado infrastructure) y almacenan toda la información del estado de Terraform correspondiente a los recursos compilados en GCP en buckets de GCS. Controlan el acceso al repositorio de CSR y a los buckets de GCS del estado de Terraform.
2. El equipo de red que compila la VPC compartida usa 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 de los recursos de GCP. Todos los proyectos usaron esta VPC compartida única para las herramientas de 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 endurecer los clústeres y de administrar la resiliencia y el escalamiento de la plataforma de Kubernetes. En este taller, usarás el método de gitops para implementar recursos en Kubernetes. Existe un repositorio de CSR (llamado k8s_repo) en el proyecto de operaciones.
4. Por último, los equipos dev1 y dev2 (representan dos equipos de desarrollo) que compilan aplicaciones usan sus propios dev1 y dev2 projects. Son las aplicaciones y los servicios que les proporcionas a tus clientes. Estos se basan en la plataforma que administra el equipo de operaciones. Los recursos (implementaciones, servicios, etc.) se envían a k8s_repo y se implementan en los clústeres adecuados. Es importante tener en cuenta que este taller no se enfoca en las prácticas recomendadas y las herramientas de CI/CD. Cloud Build se usa para automatizar la implementación de recursos de Kubernetes directamente en los clústeres de GKE. En situaciones de producción reales, se usa una solución de CI/CD adecuada para implementar aplicaciones en clústeres de GKE.

Hay dos tipos de clústeres de GKE en este taller.

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

Separar las herramientas de operaciones/administración 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 pertenecientes al equipo o producto que los usa, lo que hace que los permisos de IAM también sean más fáciles de administrar.

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 se instala en ambos clústeres de operaciones. Cada clúster de operaciones está en una región diferente. Además, hay cuatro clústeres de aplicaciones zonales. Estos elementos se crean en sus propios proyectos. Este taller simula dos equipos de desarrollo, cada uno con sus propios proyectos. Cada proyecto contiene dos clústeres de apps. Los clústeres de apps son zonales en zonas diferentes. Los cuatro clústeres de apps se encuentran en dos regiones y cuatro zonas. De esta manera, obtienes redundancia regional y zonal.

La aplicación que se usó en este taller, la app Hipster Shop, se implementa en los cuatro clústeres de apps. Cada microservicio vive en su propio espacio de nombres en cada clúster de 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 servicio de Kubernetes para el descubrimiento de servicios. Si no hay objetos Services (en los clústeres de operaciones), tendrías que crear ServiceEntries de forma manual para cada servicio que se ejecuta en el clúster de la app.

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

Manifiestos de Kubernetes y k8s_repo

Usa k8s_repo para agregar recursos de Kubernetes a todos los clústeres de GKE. Para ello, copia los manifiestos de Kubernetes y confirma el k8s_repo. Todas las confirmaciones de k8s_repo activan un trabajo de Cloud Build que implementa los manifiestos de Kubernetes en el clúster correspondiente. El manifiesto de cada clúster se ubica en una carpeta separada cuyo nombre es el mismo.

Los seis nombres de los clústeres son los siguientes:

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

k8s_repo tiene carpetas que corresponden a estos clústeres. Cualquier manifiesto ubicado en estas carpetas se aplica 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 LA 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 la secuencia de comandos rápida de este lab, no uses el método de copiar y pegar que aparece a continuación**.**

Clona el repositorio de origen del proyecto de operaciones

Como parte de la compilación inicial de la infraestructura de Terraform, el 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. En el repositorio de Git, agrega el repositorio remoto y extrae la instancia 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

Copiar manifiestos, confirmar y enviar

4. Copia los espacios de nombres y servicios de Hipster Shop en el repositorio de origen de 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 la carpeta de la aplicación kustomization.yaml 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. Copie las implementaciones de Hipster Shop, RBAC y PodSecurityPolicy en el repositorio de origen de los clústeres de las aplicaciones.

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 cartservice, rbac y podsecuritypolicy de todos los clústeres de desarrollo, excepto uno. Hipstershop no se creó para la implementación de varios clústeres, por lo que, para evitar resultados incoherentes, solo usamos 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 cartservice deployment, 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 podsecuritypolicies, deployments y los directorios rbac de los clústeres de operaciones 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 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 a 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 de loadgenerator (Deployment, PodSecurityPolicy y RBAC) en los clústeres de operaciones. La app de Hipster Shop se expone mediante un balanceador de cargas de Google Cloud (GCLB) global. GCLB recibe tráfico de cliente (destinado a frontend) y lo envía a la instancia más cercana del Service. 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.

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 con 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 del proyecto de operaciones de Cloud Build en una pestaña abierta con anterioridad o haz 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 en el carrito, tengan el 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 tengan el estado Running 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 si acceden al servicio frontend. El servicio frontend se ejecuta en los cuatro clústeres de apps. Se usa un balanceador de cargas de Google Cloud ( GCLB) para obtener tráfico de clientes a las cuatro instancias del servicio frontend.

Las puertas de enlace de Ingress 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 desde el GCLB y, luego, lo envían a los Pods de frontend que se ejecutan en los clústeres de aplicaciones.

Como alternativa, puedes colocar directamente las puertas de enlace de entrada de Istio en los clústeres de la aplicación, y GCLB puede usarlas como backends.

Controlador de GKE Autoneg

El Service de Kubernetes de la puerta de enlace de entrada de Istio se registra como backend en GCLB mediante grupos de extremos de red (NEG). Los NEG permiten el balanceo de cargas nativo del contenedor mediante GCLB. Los NEG se crean a través de una anotación especial en un Service de Kubernetes para que pueda registrarse en el controlador de NEG. El controlador Autoneg es un controlador especial de GKE que automatiza la creación de NEG y los asigna como backends a un GCLB mediante anotaciones de Service. Los planos de control de Istio, incluidas las puertas de enlace de entrada de Istio, se implementan durante la infraestructura inicial de Terraform Cloud Build. La configuración de GCLB y autoneg se realiza como parte de Cloud Build inicial para 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 GCLB frontend. GCLB usa certificados administrados para el servicio frontend global, y el certificado finaliza en GCLB. En este taller, usarás Cloud Endpoints como el dominio para el certificado administrado. Como alternativa, puedes usar tu dominio y un nombre de DNS para el frontend a fin de crear certificados administrados por GCP.

21. Para acceder a la tienda Hipster, haz clic en el resultado del vínculo del siguiente comando.

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

22. Para comprobar que el certificado es válido, haz clic en el símbolo de bloqueo 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, los generadores de cargas se implementaron en ambos clústeres de operaciones que generan tráfico de prueba al vínculo de Cloud Endpoints de la tienda GCLB Hipster. Verifica que el GCLB reciba tráfico y se envíe a ambas puertas de enlace de entrada de Istio.

23. Obtén el GCLB > Vínculo de Monitoring para el proyecto de operaciones en el que se crea el GCLB de la tienda de Hipster.

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 Todos los backends a istio-ingressgateway en el menú desplegable Backend como se muestra a continuación.

25. Ten en cuenta el tráfico que se dirige a ambos istio-ingressgateways.

Hay tres NEG creados por istio-ingressgateway. Dado que los clústeres de operaciones son regionales, se crea un NEG para cada zona en 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 de istio-ingressgateway.

Los generadores de cargas se ejecutan en ambos clústeres de operaciones, simulando el tráfico de clientes desde 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.

• Instalar istio-telemetry recurso
• Crear o actualizar paneles de servicios de Istio
• Ver registros de contenedores
• Ver el seguimiento distribuido en Stackdriver

GUION DE LA 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 la secuencia de comandos rápida de este lab, no uses el método de copiar y pegar que aparece a continuación**.**

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

También usaremos el sistema de generación de carga integrado 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. Instalar el archivo de configuración 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. Confirmar en k8s-repo.

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

3. Consulta el estado del proyecto de operaciones de Cloud Build en una pestaña abierta con anterioridad o haz 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 → Stackdriver Obtén la 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 esté funcionando. Haz clic en el resultado del vínculo de 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 elige Aceptar. Si aparece un mensaje sobre la nueva IU, simplemente 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 “Server Request Count” en el campo “Contenedor de Kubernetes” el tipo de recurso. Esto nos muestra que las métricas fluyen de la malla a Stackdriver.

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

Visualiza métricas con paneles:

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

El proxy Envoy de Istio nos proporciona varias métricas, pero estas son un buen conjunto para comenzar. (consulta una lista exhaustiva 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 preestablecidas. Vamos a usar directamente la API del panel. Esto es algo que normalmente no harías con la generación manual de llamadas a la API, sería parte de un sistema de automatización o podrías compilar el panel de forma manual en la IU web. Esto nos ayudará a 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 aparece 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 in situ con la UX, pero en este caso vamos a agregar rápidamente un nuevo gráfico con la API. Para hacerlo, debes desplegar la última versión del panel, aplicar tus ediciones y, luego, volver a enviarla con el método HTTP PATCH.

8. Puedes obtener un panel existente si consultas 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 %50): [ referencia de la API] Ahora podemos agregar un widget de gráfico nuevo a nuestro panel en el código. Las apps similares pueden revisar este cambio y ponerlo en el control de versiones. Este es un widget para agregar que muestra la latencia del 50% (latencia mediana).

Intenta editar el panel que acabas de tener, agregando 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. Haz un análisis de registros sencillo.

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

Un ejemplo de entrada de registro (en este caso, el registro de acceso del proxy de Envoy) podría verse de la siguiente manera (recortada):

*** 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 búsqueda en “piloto” -

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

Además de los registros de Istio, también puedes encontrar registros de contenedores y de la infraestructura o de otros servicios de GCP, todo en la misma interfaz. Estas son algunas consultas de registros de muestra para GKE. El visor de registros también te permite crear métricas a partir de los registros (p. ej., “contar todos los errores que coincidan con alguna cadena”) que se pueden usar en un panel o como parte de una alerta. Los registros también pueden transmitirse a otras herramientas de análisis, como BigQuery.

Estos son algunos filtros de muestra para una tienda hípster:

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

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

13. Consulta los seguimientos distribuidos.

Ahora que trabajas con un sistema distribuido, la depuración necesita una nueva herramienta: Seguimiento distribuido. Esta herramienta te permite descubrir estadísticas sobre cómo interactúan tus servicios (como encontrar eventos lentos marginales en la imagen a continuación), así como explorar muestras sin procesar de seguimientos para investigar los detalles de lo que realmente está sucediendo.

En la vista de cronograma, se muestran todas las solicitudes a lo largo del tiempo, graficadas por su latencia o el tiempo transcurrido entre la solicitud inicial, a través de la pila de Hipster, para responder finalmente al usuario final. Cuanto más altos 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 estadísticas agregadas) es vital para comprender la interacción entre los servicios, especialmente cuando se buscan interacciones raras, pero malas, entre servicios.

Cualquier persona que haya usado un depurador debería estar familiarizado con la vista Waterfall. Sin embargo, en este caso, en lugar de mostrar el tiempo empleado en diferentes procesos de una sola aplicación, se muestra el tiempo empleado en recorrer nuestra malla, entre servicios y ejecutándose en contenedores separados.

Aquí puedes encontrar tus seguimientos:

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

Una captura de pantalla de ejemplo de la herramienta:

9. Autenticación mutua de TLS

Objetivo: Conectividad segura entre microservicios (AuthN).

• Habilitar mTLS de toda la malla
• Inspecciona los registros para verificar mTLS

GUION DE LA 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 la secuencia de comandos rápida de este lab, no uses el método de copiar y pegar que aparece 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 siga funcionando.

Por ejemplo, en el panel de Kiali, podemos ver que nuestros servicios no usan MTLS (sin ícono de bloqueo). Pero el tráfico está fluyendo y el sistema funciona bien. Nuestro panel Golden Metrics de Stackdriver nos da la tranquilidad de saber que, en general, todo está funcionando.

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 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 mediante el operador de Istio, que usa el recurso personalizado (CR) de IstioControlPlane. Configuraremos mTLS en todos los clústeres actualizando la CR de IstioControlPlane y el repositorio k8s-repo. Configuración global > mTLS > enabled: true en la CR de IstioControlPlane genera los dos cambios siguientes en el plano de control de Istio:

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

2. Aplicaremos un parche de kustomize a la CR istioControlPlane para habilitar todo el clúster de mTLS. Copia el parche al directorio relevante 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. Confirmar en k8s-repo.

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

4. Consulta el estado del proyecto de operaciones de Cloud Build en una pestaña abierta con anterioridad o haz clic en el siguiente vínculo:

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

 

Verifica mTLS

5. Revisa MeshPolicy una vez más 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 la DestinationRule creada 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 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 "protocol:

Esto da como resultado una buena manera de visualizar el cambio:

10. Implementaciones de versiones canary

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

• Lanzar el servicio frontend-v2 (próxima versión de producción) 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 mediante la inspección de series de confirmaciones en k8s-repo

GUION DE LA 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 la secuencia de comandos rápida de este lab, no uses el método de copiar y pegar que aparece a continuación**.**

Una implementación de versiones canary es un lanzamiento progresivo de un servicio nuevo. En una implementación de versiones canary, envías una cantidad creciente de tráfico a la versión nueva y, al mismo tiempo, envías 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 error, saturación) en comparación con un modelo de referencia. Esto ayuda a evitar interrupciones y garantizar la estabilidad de la nueva "v2" en cada etapa de la división del tráfico.

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

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

Nota: Activaremos manualmente la canalización de versiones canary en ambas regiones, pero, en producción, usarías un activador automatizado, 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 versiones canary en tiempo real.
• DestinationRule de frontend de Istio divide el Service de Kubernetes de frontend en dos subconjuntos, v1 y v2, según la “versión”. etiqueta de implementación
• Frontend VirtualService de Istio: enruta el 100% del tráfico a frontend v1. Esto anula el comportamiento round robin predeterminado del servicio de Kubernetes, que enviaría de inmediato el 50% de todo el tráfico regional de Dev1 a la versión 2 del frontend.

3. Confirma los cambios en k8s_repo:

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

4. Consulta el estado del proyecto de operaciones de Cloud Build en una pestaña abierta con anterioridad o haz 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 para el proyecto OPS1. Espera a que se complete la canalización de Cloud Build. Luego, obtén los Pods en el espacio de nombres de 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 del reloj

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

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

6. Ejecuta el comando para dividir la ventana de Cloud Shell y ejecuta 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, que se define en el nuevo VirtualService.

7. Ejecutar la canalización de versiones canary en la región Dev1 Proporcionamos una secuencia de comandos que actualiza los porcentajes de tráfico frontend-v2 en VirtualService (actualizando los pesos al 20%, 50%, 80% y luego al 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 Dev1. Nota: Esta secuencia de comandos tarda unos 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, donde ejecutas el comando respy. Por ejemplo, cuando se alcanza el 20%, ocurre lo siguiente :

Resultado (no lo copie)

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

8. Cuando se complete el lanzamiento 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. Y todo el tráfico de frontend de un Pod de Dev2 debería 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 Dev2. Ten en cuenta que la región Dev2 sigue estando “bloqueada” en la versión 1. Esto se debe a que, en la secuencia de comandos repo_setup del modelo de referencia, enviamos un VirtualService para enviar explícitamente todo el tráfico a v1. De esta manera, pudimos realizar una prueba canary regional de forma segura en Dev1 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 ejecuta 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, que se define en el nuevo VirtualService.

13. Ejecutar la canalización de versiones canary en la región Dev2 Proporcionamos una secuencia de comandos que actualiza los porcentajes de tráfico frontend-v2 en VirtualService (actualizando los pesos al 20%, 50%, 80% y luego al 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 Dev1. Nota: Esta secuencia de comandos tarda unos 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 de la versión 1 de frontend a la 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 presentó cómo usar Istio para implementaciones regionales de versiones canary. En producción, en lugar de una secuencia de comandos manual, puedes activar automáticamente esta secuencia de comandos de versiones canary como una canalización de Cloud Build, a través de un activador, como una nueva imagen etiquetada enviada a un registro de contenedores. También querrás agregar un análisis de versiones canary entre cada paso, analizando la latencia y la tasa de errores de v2 en comparación con un umbral de seguridad predefinido, antes de enviar más tráfico.

11. Políticas de autorización

Objetivo: Configurar RBAC entre microservicios (AuthZ).

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

GUION DE LA 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 la secuencia de comandos rápida de este lab, no uses el método de copiar y pegar que aparece a continuación**.**

A diferencia de una aplicación monolítica que podría ejecutarse en un solo lugar, las apps de microservicios distribuidas globalmente hacen llamadas a través de los límites de la red. Esto significa 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 IP transitorias, las reglas de firewall tradicionales basadas en IP ya no son adecuadas para proteger el acceso entre cargas de trabajo. En una arquitectura de microservicios, se necesita un enfoque nuevo de seguridad. Istio, que se basa en 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 (¿es este servidor quien dice ser?) y la autorización verifica los permisos (¿este cliente puede hacer eso?). Abordamos la autenticación de Istio en la sección de TLS mutua en el módulo 1 (MeshPolicy). En esta sección, aprenderemos a usar las políticas de autorización de Istio para controlar el acceso a currencyservice, una de las cargas de trabajo de nuestra aplicación.

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 al currencyservice. Observa que no hay ningún campo spec. Esto significa que esta política rechazará 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 del proyecto de operaciones de Cloud Build 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. Después de que la compilación finalice con éxito, intenta llegar al frontend de hipstershop en un navegador a través del siguiente vínculo:

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

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

6. Investiguemos cómo el servicio de moneda aplica esta AuthorizationPolicy. Primero, habilita los registros a nivel de seguimiento en el proxy de Envoy para uno de los Pods de 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 “enforced denied” que indica que currencyservice 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, permitamos que el frontend, pero no los otros servicios de backend, acceda a currencyservice. Abre currency-allow-frontend.yaml e inspecciona el 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 monedas. La cuenta de servicio de Kubernetes define este source.principal. En este caso, la cuenta de servicio que agregamos a la lista blanca es la de frontend del espacio de nombres de frontend.

Nota: Cuando uses las cuentas de servicio de Kubernetes en las AuthorizationPolicies de Istio, primero deberás habilitar la TLS mutua en todo el clúster, como lo hicimos en el módulo 1. Esto permite garantizar que las credenciales de la cuenta de servicio se activen en las solicitudes.

9. Copia la política de moneda 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 del proyecto de operaciones de Cloud Build en una pestaña abierta con anterioridad o haz 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. Esto se debe a que el frontend tiene permiso explícito para acceder al servicio actual.
13. Ahora intenta realizar la confirmación de la compra agregando artículos al carrito y haciendo clic en “Realizar pedido”. Esta vez, deberías ver un error de conversión de precios del servicio de moneda. Esto se debe a que solo incluimos el frontend en la lista blanca, por lo que el servicio de confirmación de la compra todavía no puede acceder a currencyservice.

14. Por último, permitiremos que el servicio de confirmación de la compra acceda a la moneda. Para ello,agreguemos otra regla a nuestra AuthorizationPolicy de currencyservice. Ten en cuenta que solo permitiremos el acceso de moneda a los dos servicios que necesitan acceder: frontend y confirmación de la compra. Los otros backends seguirán bloqueados.
15. Abre currency-allow-frontend-checkout.yaml e inspecciona el contenido. Ten en cuenta que la lista de reglas funciona como una moneda OR lógica 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. Enviar cambios

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

18. Consulta el estado del proyecto de operaciones de Cloud Build en una pestaña abierta con anterioridad o haz 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 de la compra, ya que 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 producción, puedes crear una AuthorizationPolicy por servicio y, por ejemplo, usar una política allow-all para permitir que todas las cargas de trabajo en el mismo espacio de nombres accedan unas a otras.

12. Escalamiento de la infraestructura

Objetivo: Escalar la infraestructura agregando región, proyecto y clústeres nuevos.

• Clona el repositorio infrastructure
• Actualizar 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)
• Clúster de operaciones nuevo en una región nueva (en la subred nueva)
• Nuevo plano de control de Istio para la nueva región
• 2 clústeres de apps en el proyecto nuevo en la región nueva
• Confirmar en el repositorio infrastructure
• Verifica la instalación

GUION DE LA 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 la secuencia de comandos rápida de este lab, no uses el método de copiar y pegar que aparece a continuación**.**

Existen varias formas de escalar una plataforma. Puedes aumentar el procesamiento si agregas 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, quizás sea suficiente agregar más nodos (o grupos de nodos) al clúster existente. Sin embargo, si tienes clústeres en dos de tres zonas de una sola región, agregar un clúster nuevo en la tercera zona te proporciona escalamiento y un dominio con fallas adicional (es decir, una zona nueva). Otra razón para agregar un clúster nuevo en una región podría ser la necesidad de crear un clúster de un solo usuario, por motivos normativos o de cumplimiento (por ejemplo, PCI o un clúster de base de datos que aloja información de PII). A medida que su empresa y sus servicios se expanden, agregar nuevas regiones se vuelve inevitable para ofrecer 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 escalar la plataforma de dos maneras:

• Verticalmente: dentro de cada región agregando más procesamiento. Esto se hace agregando más nodos (o grupos de nodos) a los clústeres existentes o con clústeres nuevos dentro de la región. Esto se hace a través del repositorio infrastructure. La ruta más simple es agregar nodos a los clústeres existentes. No es necesario realizar ninguna configuración adicional. Es posible que para agregar clústeres nuevos se requieran subredes adicionales (y rangos secundarios), se deben agregar reglas de firewall adecuadas, agregar los clústeres nuevos al plano de control de la malla de servicios regional de ASM/Istio y, luego, implementar recursos de aplicaciones en los clústeres nuevos.
• Horizontalmente: Agrega más regiones. La plataforma actual te proporciona una plantilla regional. Consiste en un clúster de operaciones regional en el que reside el 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 incluye los pasos verticales del caso de uso. Para escalar horizontalmente la plataforma agregando una región nueva (r3) a ella, se deben agregar los siguientes recursos:

1. Las subredes del proyecto host comparten la VPC en la región r3 para los clústeres de aplicaciones y operaciones nuevos.
2. 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 en la región r3.
4. Actualiza al repositorio k8s-repo:
5. Implementa los recursos del plano de control de ASM/Istio en el clúster de operaciones en la región r3.
6. Implementa los 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 necesitas crear un proyecto nuevo, los pasos del taller demuestran la adición de un nuevo proyecto dev3 para cubrir el caso de uso de agregar un nuevo equipo a la plataforma.

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

1. En Cloud Shell, navega a WORKDIR y clona el repositorio 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 repositorio 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 repositorio del taller de código fuente. 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 repositorio add-proj por un symlink al directorio infra-repo para permitir que se ejecuten las secuencias de comandos de 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 compartidos y las variables en la nueva estructura del directorio del proyecto.

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

6. Confirma y envía 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 en el café.

El último paso de infrastructure Cloud Build crea nuevos recursos de Kubernetes en k8s-repo. Esto activa Cloud Build en k8s-repo (en el proyecto de operaciones). Los recursos nuevos 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 los recursos del plano de control compartido se agregan a los clústeres nuevos con Cloud Build k8s-repo.

8. Una vez que la infraestructura de Cloud Build finalice con éxito, navega a la ejecución k8s-repo más reciente de 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 al archivo 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 archivo kubeconfig nuevo.

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

11. Obtén una lista de los contextos del 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. Asegúrate de que Istio esté instalado en el clúster de operaciones nuevo. Para ello, verifica que todos los Pods estén en ejecución y que los trabajos se hayan completado.

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 dev3. Solo Citadel, el inyector de sidecar y el 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 la detección de servicios para los planos de control compartidos

14. Verifica que los Secrets se hayan implementado en todos los clústeres de operaciones para los seis clústeres de la aplicación.

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 que el servicio shipping implemente un disyuntor
• Usa fortio (una utilidad de generación de carga) a fin de validar el disyuntor para el servicio de shipping forzando la expulsión del circuito.

Instrucciones del lab de procedimiento rápido de Script

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 de los servicios habilitados para Istio, veamos cómo Istio te ayuda a mejorar la resistencia de los servicios, lo que reduce la cantidad de solución de problemas que tendrás que realizar desde el principio.

Una arquitectura de microservicios presenta el riesgo de fallas en cascada, en las que la falla de un servicio puede propagarse a sus dependencias, y las dependencias de esas dependencias, lo que provoca un “efecto dominó” una interrupción que podría afectar a los usuarios finales. Istio proporciona una política de tráfico de disyuntor para ayudarte a aislar servicios. Esto protege los servicios downstream (del cliente) para que no esperen en servicios con errores y protege los servicios ascendentes (del servidor) de una avalancha repentina de tráfico descendente cuando vuelven a estar en línea. En general, el uso de disyuntores puede ayudarte a evitar que todos tus servicios fallen en sus SLO debido a que hay un servicio de backend que se bloquea.

El patrón del disyuntor lleva el nombre de un interruptor eléctrico que puede “dispararse”. 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 y hace un seguimiento de la cantidad de solicitudes pendientes de 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 abre) y Envoy devuelve un error de inmediato. Esto permite que el servidor falle rápido para el cliente y evita que el código de la aplicación del servidor reciba la solicitud del cliente cuando se sobrecarga.

Después del tiempo de espera definido, Envoy pasa al estado semiabierto, en el que el servidor puede comenzar a recibir solicitudes nuevamente en forma de prueba y, si puede responder con éxito a las solicitudes, el disyuntor se cierra de nuevo y las solicitudes al servidor comienzan a fluir nuevamente.

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

Puedes definir políticas del disyuntor mediante DestinationRules de Istio. En esta sección, aplicaremos la siguiente política para aplicar un disyuntor en el 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 para tener en cuenta. connectionPool define la cantidad de conexiones que permitirá este servicio. En el campo outlierDetection, configuramos cómo Envoy determinará el umbral para el cual 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 estarán protegidos frente a nuevas solicitudes de clientes 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. Establecer variables de entorno para k8s-repo y asm dir para simplificar los comandos

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

2. Actualiza el repositorio k8s-repo

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

3. Actualiza el objeto 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 cargas Fortio en el clúster GKE_1 en la región Dev1. Este es el grupo de clientes que usaremos para “viajar” el disyuntor para el servicio de envío.

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. En Cloud Shell, usa el Pod de fortio para enviar tráfico de gRPC a shippingservice con 1 conexión simultánea, 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, aumentando el número de conexiones simultáneas a 2, pero manteniendo el número total de solicitudes constante. Deberíamos ver que hasta dos tercios de las solicitudes devuelven un "overflow" debido a que se disparó 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 perdió 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. Para realizar una limpieza, quita la política de disyuntor de ambas regiones.

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 demostró cómo configurar una sola política de disyuntor para un servicio. Una práctica recomendada es configurar un disyuntor para cualquier servicio ascendente (backend) que tenga el potencial de bloquearse. Cuando aplicas políticas de disyuntor de Istio, ayudas a aislar tus microservicios, desarrollar tolerancia a errores en tu arquitectura y reducir el riesgo de fallas en cascada bajo cargas altas.

14. Inyección de errores

Objetivo: Probar la resiliencia del servicio de recomendación mediante la introducción de demoras (antes de que se envíe a la producción).

• Crea un VirtualService para que el servicio recommendation introduzca un retraso de 5 s
• Prueba la demora con el generador de cargas fortio
• Quita el retraso en VirtualService y valida

Instrucciones del lab de procedimiento rápido de Script

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 frente a los servicios en producción. Sin embargo, la interrupción de circuitos genera fallas (posibles errores que afectan al usuario), lo cual no es ideal. Para adelantarte a estos casos de error y predecir mejor cómo podrían responder tus servicios downstream cuando los backends muestren 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 los 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 del usuario cuando fallan los backends, por ejemplo, mostrando un resultado almacenado en caché en un frontend.

El uso de Istio para la inserción de errores es útil porque puedes usar tus imágenes de lanzamiento 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 procesamiento y Kubernetes, además de la capa de red.

Puedes usar Istio para realizar pruebas de caos si aplicas un VirtualService con el error "fault" . Istio admite dos tipos de fallas: las fallas de retraso (inyectar un tiempo de espera) y anular las fallas (inyectar errores de HTTP). En este ejemplo, insertaremos una falla de 5 segundos de retraso en el servicio de recomendaciones. Pero esta vez, en lugar de usar un disyuntor para “fallar rápido” con este servicio pendiente, obligaremos a los servicios downstream a soportar el tiempo de espera completo.

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

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 el contenido. Ten en cuenta que Istio tiene la opción de insertar la falla en un porcentaje de las solicitudes. Aquí, ingresaremos 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 globalmente, 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. Enviar 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. Ejecútalo en el Pod de fortio implementado en la sección de 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. La página de un producto debería tardar 5 segundos más en cargarse, ya que recupera las recomendaciones que se muestran en la parte inferior de la página.
18. Para realizar una limpieza, quita el servicio de inserción de errores de ambos clústeres de operaciones.

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ío de 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 relevantes a Prometheus, y ASM se incluye en los 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.

Visualiza 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 "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. Ver paneles disponibles
26. Modifica la URL a " BASE_URL/dashboard"
27. Haz clic en “istio”. carpeta para ver los paneles disponibles
28. Haz clic en cualquiera de esos paneles para ver el rendimiento de ese componente. Veremos las métricas importantes para cada componente en las siguientes secciones.

Prueba piloto de supervisión

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

• consumen más recursos de los necesarios (CPU o RAM)
• retrasan el envío de la información de configuración actualizada a Envoys.

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

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

Métricas supervisadas importantes

Uso de recursos

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

Información push de la prueba piloto

En esta sección, se supervisan los envíos de configuración de Pilots a tus proxies de Envoy.

• Pilot Pushes muestra el tipo de configuración que se envía en cualquier momento.
• Supervisión de anuncios muestra la cantidad de servicios virtuales, servicios y extremos conectados en el sistema.
• Clústeres sin extremos conocidos muestra los extremos que se configuraron, pero no tienen ninguna instancia en ejecución (lo que puede indicar servicios externos, como *.googleapis.com).
• Los errores de la prueba piloto muestran la cantidad de errores que se encontraron con el tiempo.
• Los conflictos muestran la cantidad de conflictos de configuración ambigua en los objetos de escucha.

Si tienes errores o conflictos, la configuración de uno o más de tus servicios es incorrecta o inconsistente. Consulta Soluciona problemas del plano de datos para obtener más información.

Información de Envoy

Esta sección contiene 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 observas fallas de conexión de XDS repetidas.

Mezclador de supervisión

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 está en el plano de datos. Se implementa como dos objetos Job de Kubernetes (llamados Mixer) implementados con dos nombres de servicio diferentes (istio-telemetry e istio-policy).

Mixer también se puede utilizar para integrar a los sistemas de políticas. En esta capacidad, Mixer sí afecta el plano de datos, ya que las políticas de Mixer que fallan bloquean el acceso a tus servicios.

Mixer 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 supervisadas importantes

Uso de recursos

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

Descripción general de la batidora

• 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, sin duda se ralentizará el rendimiento del proxy de sidecar. El percentil 90 debe estar en milisegundos de un solo dígito y el percentil 99 debe estar por debajo de 100 ms.

• Adapter Dispatch Duration indica la latencia que experimenta el Mixer en las llamadas a los adaptadores (a través de los cuales envía información a los sistemas de telemetría y registro). Las latencias altas afectarán, sin dudas, el rendimiento en la malla. Una vez más, las latencias de p90 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 endpoints del sistema.

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

Métricas supervisadas importantes

Validación de recursos

La métrica más importante que se debe seguir, que indica la cantidad de recursos de varios tipos, como las reglas de destino, las puertas de enlace y las entradas de servicio que están aprobadas o fallan en la validación.

Clientes conectados

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

16. Soluciona problemas de Istio

Soluciona problemas del plano de datos

Si el panel de la prueba 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 de pod para la instancia de Pilot que quieres solucionar.

En el registro resultante, busca el mensaje Estado del envío. 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 del envío indicará cualquier problema que haya ocurrido cuando se intentó enviar la configuración a los proxies de Envoy. En este caso, vemos varios “Clústeres duplicados”. mensajes, que indican destinos ascendentes duplicados.

Si necesitas ayuda para diagnosticar problemas, comunícate con la asistencia de Google Cloud.

Cómo buscar errores de configuración

Si quieres usar istioctl para analizar tu configuración, ejecuta istioctl experimental analyze -k --context $OPS_GKE_1. Esto realizará un análisis de la configuración en tu sistema e indicará cualquier problema junto con cualquier cambio sugerido. Consulta la documentación para obtener una lista completa de los errores de configuración que este comando puede detectar.

17. Limpieza

Un administrador realiza los siguientes pasos una vez finalizado 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 los siguientes datos para que se ejecute la secuencia de comandos de limpieza.

• Nombre de la organización (por ejemplo, yourcompany.com)
• ID del taller con el formato YYMMDD-NN, por ejemplo 200131-01
• Bucket de GCS de administrador: definido 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 la organización y el ID del taller que quieres 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 como se indica a continuación.

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