Workshop do Anthos Service Mesh: guia do laboratório

1. TRABALHO DE ALFA

OBSERVAÇÃO IMPORTANTE: ESTE É UM WORKSHOP DE ALFA E ESTÁ ESTRITAMENTE DESENVOLVIMENTO DE SER UM TREINAMENTO EM SALA DE AULA COM INSTRUTOR.

Link para o codelab do workshop bit.ly/asm-workshop

2. Visão geral

Diagrama da arquitetura

Este workshop é uma experiência imersiva e prática que mostra como configurar serviços distribuídos globalmente no GCP em produção. As principais tecnologias usadas são o Google Kubernetes Engine (GKE) para computação e a malha de serviço do Istio para criar conectividade segura, observabilidade e modelagem avançada de tráfego. Todas as práticas e ferramentas usadas neste workshop são as que você usaria na produção.

Tópicos

• Módulo 0: introdução e configuração da plataforma
• Introdução e arquitetura
• Introdução à malha de serviço e ao Istio/ASM
• Laboratório: Configuração da infraestrutura: fluxo de trabalho do usuário
• Intervalo
• QnA
• Módulo 1: instalar, proteger e monitorar aplicativos com o ASM
• Modelo Repo: explicação sobre a infraestrutura e os repositórios do Kubernetes
• Laboratório: Implantar o aplicativo de amostra
• Serviços e observabilidade distribuídos
• Almoço
• Laboratório: Observabilidade com o Stackdriver
• QNA
• Módulo 2: DevOps: lançamentos canário, política/RBAC
• Descoberta e segurança/política de serviços de vários clusters
• Laboratório: TLS mútuo
• Implantações canário
• Laboratório: Implantações canário
• Balanceamento de carga global e seguro com vários clusters
• Intervalo
• Laboratório: Política de autorização
• QNA
• Módulo 3: operações de infraestrutura: upgrades da plataforma
• Elementos básicos do serviço distribuído
• Laboratório: Escalonamento da infraestrutura
• Próximas etapas

Apresentações

Os slides deste workshop podem ser encontrados no seguinte link:

Slides do workshop sobre ASM

Pré-requisitos

Antes de continuar com este workshop, você precisa fazer o seguinte:

1. Um nó de Organização do GCP
2. Um ID de conta de faturamento (o usuário precisa ser um administrador de faturamento da conta)
3. Papel do IAM de administrador da organização no nível da organização para seu usuário

3. Configuração da infraestrutura: fluxo de trabalho do administrador

As etapas desta seção são executadas por um administrador que cria o workshop.

Se você for um usuário que vai fazer o workshop, pule para a próxima seção chamada Infrastructure Setup - User Workflow

Explicação do script do workshop de inicialização

Um script chamado bootstrap_workshop.sh é usado para configurar o ambiente inicial do workshop. Use este script para configurar um único ambiente para você ou vários ambientes para vários usuários, caso este workshop seja oferecido como um treinamento para vários usuários.

O script do workshop de inicialização requer o seguinte como entradas:

• Nome da organização (por exemplo, yourcompany.com): a organização em que você vai criar os ambientes do workshop.
• ID do faturamento (por exemplo, 12345-12345-12345): é usado para cobrar todos os recursos usados durante o workshop.
• Número de workshop (por exemplo, 01): um número de dois dígitos. Use esse recurso se você realizar vários workshops em um dia e quiser acompanhá-los separadamente. Os números de workshop também são usados para derivar os IDs de projeto. Com números de workshop separados, fica mais fácil garantir IDs de projeto exclusivos. Além do número do workshop, a data atual (formatada como YYMMDD) também é usada para os IDs de projeto. A combinação de data e número do workshop fornece IDs de projeto exclusivos.
• Número do usuário inicial (por exemplo, 1): esse número significa o primeiro usuário no workshop. Por exemplo, se você quiser criar um workshop para 10 usuários, defina o número de usuário inicial 1 e o número de usuário final 10.
• Número do usuário final (por exemplo, 10): este número significa o último usuário do workshop. Por exemplo, se você quiser criar um workshop para 10 usuários, defina o número de usuário inicial 1 e o número de usuário final 10. Se estiver configurando um único ambiente (para você, por exemplo), use o mesmo número para o usuário final e o inicial. Isso vai criar um único ambiente.

Além da data e do número do workshop, os números dos usuários inicial e final também estão incorporados nos IDs de projeto. Os IDs de usuário (para usuários que realizam o workshop) são derivados do número do usuário inicial e final. Os IDs de usuário são explicados na seção User schema and permissions performing the workshop.

• Bucket do GCS de administrador (por exemplo, my-gcs-bucket-name): um bucket do GCS é usado para armazenar informações relacionadas ao workshop. Essas informações são usadas pelo script cleanup_workshop.sh para excluir todos os recursos criados durante o script do workshop de inicialização. Os administradores que criam workshops precisam ter permissões de leitura/gravação nesse bucket.

O script da oficina de inicialização usa os valores fornecidos acima e atua como um script de wrapper que chama o script setup-terraform-admin-project.sh. O script setup-terraform-admin-project.sh cria o ambiente da oficina para um único usuário.

Permissões de administrador necessárias para inicializar o workshop

Existem dois tipos de usuários neste workshop. Um ADMIN_USER, que cria e exclui os recursos do workshop. O segundo é MY_USER, que realiza as etapas do workshop. MY_USER só tem acesso aos próprios recursos. ADMIN_USER tem acesso a todas as configurações do usuário. Se você estiver criando essa configuração por conta própria, ADMIN_USER e MY_USER serão os mesmos. Se você é um professor e está criando este workshop para vários estudantes, seu ADMIN_USER e MY_USER serão diferentes.

As seguintes permissões no nível da organização são necessárias para o ADMIN_USER:

• Proprietário: tem permissão de proprietário do projeto para todos os projetos na organização.
• Administrador de pastas: pode criar e excluir pastas na organização. Cada usuário recebe uma única pasta com todos os recursos dentro do projeto.
• Administrador da organização
• Criador de projetos: pode criar projetos na organização.
• Excluidor de projetos: pode excluir projetos na organização.
• Administrador de IAM do projeto: pode criar regras de IAM em todos os projetos da organização.

Além disso, ADMIN_USER também precisa ser o Administrador de faturamento do ID do faturamento usado no workshop.

Esquema do usuário e permissões realizando o workshop

Se você planeja criar este workshop para usuários (além de você) da sua organização, siga um esquema de nomeação de usuário específico para MY_USERs. Durante o script bootstrap_workshop.sh, você fornece um número de início e um de usuário final. Esses números são usados para criar os seguintes nomes de usuário:

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

Por exemplo, se você executar o script de workshop de inicialização com o número de usuário inicial 1 e o número de usuário final 3, na sua organização chamada suaempresa.com, serão criados os ambientes de workshop para os usuários a seguir:

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

Esses nomes de usuário recebem os papéis de Proprietário dos projetos específicos criados durante o script setup_terraform_admin_project.sh. Você precisa aderir a esse esquema de nomenclatura do usuário ao usar o script de inicialização. Consulte como adicionar vários usuários de uma vez no G Suite.

Ferramentas necessárias para o workshop

Este workshop precisa ser inicializado no Cloud Shell. As seguintes ferramentas são necessárias para este workshop.

• gcloud (versão >= 270)
• kubectl
• sed (funciona com sed no Cloud Shell/Linux, e não no Mac OS)
• git (verifique se você está atualizado)
• sudo apt update
• sudo apt install git
• jq
• envsubst (em inglês)
• kustomize (em inglês)

Todas as ferramentas, exceto kustomize, já estão instaladas por padrão no Cloud Shell. Se o kustomize não estiver instalado, instale-o usando o script bash fornecido no link acima, verifique se o binário do Kustomize está no seu PATH e confirme executando o comando kustomize no Cloud Shell.

Configurar o workshop para você (configuração de um único usuário)

1. Abra o Cloud Shell e execute todas as ações abaixo nele. Clique no link abaixo.

CLOUD SHELL

2. Verifique se você fez login na gcloud com o usuário administrador pretendido.

gcloud config list
 

3. Crie um WORKDIR e clone o repositório do workshop.

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

4. Defina o nome da sua organização, o ID do faturamento, o número do workshop e um bucket do GCS de administrador para usar no workshop. Revise as permissões necessárias para configurar o workshop nas seções acima.

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. Execute o script bootstrap_workshop.sh. Est script leva alguns minutos para ser concluído.

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 
 

Não é necessário definir o número do usuário final e inicial, já que você o está configurando.

Depois que o script bootstrap_workshop.sh for concluído, uma pasta do GCP será criada para cada usuário na organização. Dentro dela, será criado um projeto de administrador do Terraform. O projeto "terraform admin" é usado para criar os recursos restantes do GCP necessários para este workshop. Você vai ativar as APIs necessárias no projeto admin do Terraform. Use o Cloud Build para aplicar os planos do Terraform. Atribua os papéis do IAM adequados à conta de serviço do Cloud Build para que ela possa criar recursos no GCP. Por fim, você vai configurar um back-end remoto em um bucket do Google Cloud Storage (GCS) para armazenar os estados do Terraform de todos os recursos do GCP.

Para acessar as tarefas do Cloud Build no projeto de administrador do Terraform, você precisa do ID do projeto de administrador do Terraform. Isso fica armazenado no arquivo vars/vars.sh no diretório asm. Esse diretório só será mantido se você estiver configurando o workshop para si mesmo como administrador.

6. Criar o arquivo de variáveis para definir as variáveis de ambiente

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

Organize um workshop para vários usuários (configuração multiusuário)

7. Abra o Cloud Shell e execute todas as ações abaixo nele. Clique no link abaixo.

CLOUD SHELL

8. Verifique se você fez login na gcloud com o usuário administrador pretendido.

gcloud config list
 

9. Crie um WORKDIR e clone o repositório do workshop.

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

10. Defina o nome da sua organização, o ID do faturamento, o número do workshop, o número do usuário final e inicial e um bucket do GCS de administrador para usar no workshop. Revise as permissões necessárias para configurar o workshop nas seções acima.

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. Execute o script bootstrap_workshop.sh. Est script leva alguns minutos para ser concluído.

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. Acesse o arquivo "workshop.txt" do bucket do GCS de administrador para recuperar os IDs de projetos do Terraform.

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

4. Configuração e preparação do laboratório

Os usuários que realizam o workshop começam aqui. Realize todas as etapas em uma janela do INCOGNITO no Chrome ou no Firefox.

Escolha o programa do laboratório

É possível realizar os laboratórios deste workshop de duas maneiras:

• "scripts interativos fáceis e rápidos" maneira
• O comando "copiar e colar manualmente cada instrução" maneira

O método de scripts de faixa rápida permite que você execute um único script interativo para cada laboratório, que orienta você ao longo do laboratório executando automaticamente os comandos dele. Os comandos são executados em lotes com explicações concisas de cada etapa e o que elas realizam. Após cada lote, você precisa passar para o próximo lote de comandos. Assim, você pode fazer os laboratórios no seu ritmo. Os scripts de acompanhamento rápido são idempotentes, o que significa que é possível executá-los várias vezes e ter o mesmo resultado.

Os scripts de atalho aparecerão na parte superior de cada laboratório em uma caixa verde, como mostrado abaixo.

SCRIPT PARA RASTREAMENTO RÁPIDO

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

O método copiar e colar é a forma tradicional de copiar e colar blocos de comando individuais com explicações dos comandos. Esse método deve ser executado apenas uma vez. Não há garantia de que a nova execução de comandos nesse método retornará os mesmos resultados.

Ao realizar os laboratórios, escolha um dos dois métodos.

Depois de escolher um método e realizar as etapas dele, não execute etapas no outro método.

Configuração rápida do script

Depois de concluir o script de acompanhamento rápido, você concluirá este laboratório. Não siga as etapas das instruções do laboratório para copiar e colar.

Receber informações do usuário

Este workshop é realizado com uma conta de usuário temporária (ou uma conta de laboratório) criada pelo administrador do workshop. A conta de laboratório é proprietária de todos os projetos do workshop. O administrador do workshop fornece as credenciais da conta do laboratório (nome de usuário e senha) ao usuário que realizar o workshop. Todos os projetos dos usuários têm como prefixo o nome de usuário da conta de laboratório (por exemplo, a conta de laboratório [e-mail]), o ID do projeto de administrador do Terraform seria user001-200131-01-tf-abcde e assim por diante nos demais projetos. Cada usuário deve fazer login com a conta de laboratório fornecida pelo administrador do workshop e realizar o workshop usando essa conta.

Verifique seu e-mail corporativo, o mesmo que você usou para se inscrever no workshop. O administrador do workshop deve ter recebido um e-mail com a credencial da sua conta de laboratório (ou seja, nome de usuário e senha). O e-mail é assim.

1. Clique no link abaixo para abrir o Cloud Shell.

CLOUD SHELL

2. Faça login com as credenciais da conta de laboratório, mas não com sua conta corporativa ou pessoal. A conta do laboratório tem esta aparência: userXYZ@<workshop_domain>.com.
3. Como essa é uma nova conta, você precisará aceitar os Termos de Serviço do Google. Clique em "Aceitar".

4. Na próxima tela, marque a caixa de seleção para concordar com os Termos de Serviço do Google e clique em Start Cloud Shell.

Esta etapa provisiona uma pequena VM do Debian do Linux para você usar para acessar os recursos do GCP. Cada conta recebe uma VM do Cloud Shell. O login com a conta de laboratório provisiona e conecta você usando as credenciais dessa conta. Além do Cloud Shell, também há um editor de código que facilita a edição de arquivos de configuração (terraform, YAML etc.). Por padrão, a tela do Cloud Shell é dividida entre o ambiente shell do Cloud Shell (na parte inferior) e o editor de código do Cloud (na parte superior). Os ícones de lápis e do prompt de shell no canto superior direito permitem alternar entre os dois (shell e editor de código). Você também pode arrastar a barra separadora do meio (para cima ou para baixo) e mudar o tamanho de cada janela manualmente. 5. Crie um WORKDIR para este workshop. O "WORKDIR" é uma pasta na qual você realiza todos os laboratórios deste workshop. Execute os comandos a seguir no Cloud Shell para criar o WORKDIR.

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

6. Exporte o usuário da conta de laboratório como uma variável que será usada neste workshop. Essa é a mesma conta que você usou para fazer login no Cloud Shell.

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

Observação: se você for um administrador e configurar o workshop para si mesmo usando o comando "-sufa" ou "–setup-for-admin" flags, defina MY_USER como o e-mail da conta do GCP que você usou para criar os projetos do workshop.

7. Repita as variáveis WORKDIR e MY_USER para garantir que ambas sejam definidas corretamente executando os comandos a seguir.

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

8. Clone o repositório do workshop.

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

5. Configuração da infraestrutura: fluxo de trabalho do usuário

Objetivo: verificar a infraestrutura e a instalação do Istio

• Instalar ferramentas de workshop
• clone o repositório do workshop
• Verificar Infrastructure instalação
• Verificar k8s-repo instalação
• Verificar a instalação do Istio

SCRIPT PARA RASTREAMENTO RÁPIDO

Se você escolher esse método, execute o script a seguir para concluir o laboratório.

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

Após a conclusão do script, crie o bashrc para atualizar as variáveis na sessão do Cloud Shell.

source ${HOME}/.bashrc

Instruções do laboratório do método copiar e colar

IMPORTANTE: se você já tiver concluído o script de controle rápido deste laboratório, não execute o método de copiar e colar abaixo**.**

Receber informações do usuário

O administrador que está configurando o workshop precisa fornecer as informações de nome de usuário e senha ao usuário. Todos os projetos do usuário vão ter o prefixo do nome de usuário. Por exemplo, o nome do usuário [e-mail], o ID do projeto de administrador do Terraform será user001-200131-01-tf-abcde e assim por diante nos outros projetos. Cada usuário tem acesso apenas ao próprio ambiente de workshop.

Ferramentas necessárias para o workshop

Este workshop precisa ser inicializado no Cloud Shell. As seguintes ferramentas são necessárias para este workshop.

Todas as ferramentas, exceto kustomize e pv, já estão instaladas por padrão no Cloud Shell. Abaixo, você encontra instruções para instalar os dois.

• gcloud (versão >= 270)
• kubectl
• sed (funciona com sed no Cloud Shell/Linux, e não no Mac OS)
• git (verifique se você está atualizado)
• sudo apt update
• sudo apt install git
• jq
• envsubst (em inglês)
• kustomize (em inglês)
• pv

Acessar o projeto de administrador do Terraform

Depois que o script bootstrap_workshop.sh for concluído, uma pasta do GCP será criada para cada usuário na organização. Dentro dela, será criado um projeto de administrador do Terraform. O projeto "terraform admin" é usado para criar os recursos restantes do GCP necessários para este workshop. O script setup-terraform-admin-project.sh ativa as APIs necessárias no projeto de administração do Terraform. O Cloud Build é usado para aplicar planos do Terraform. Com o script, você concede à conta de serviço do Cloud Build os papéis do IAM apropriados para que ela possa criar recursos no GCP. Por fim, um back-end remoto é configurado em um bucket do Google Cloud Storage (GCS) para armazenar os estados do Terraform de todos os recursos do GCP.

Para acessar as tarefas do Cloud Build no projeto de administrador do Terraform, você precisa do ID do projeto de administrador do Terraform. Ela é armazenada no bucket do GCS de administrador especificado no script de inicialização. Se você executar o script de inicialização para vários usuários, todos os IDs de projeto de administrador do Terraform estarão no bucket do GCS.

Este workshop deve ser realizado no Cloud Shell e no Console do Cloud. Siga as etapas abaixo em uma janela do INCOGNITO, já que você fará login com um nome de usuário e uma senha separados.

1. Clique no link abaixo para abrir o Cloud Shell, se ele ainda não estiver aberto na seção de configuração e preparação do laboratório.

CLOUD SHELL

2. Instale o kustomize (se ele ainda não tiver sido instalado) na pasta $HOME/bin e adicione a pasta $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. Instale pv e mova-o para $HOME/bin/pv.

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

4. Atualize seu 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. Verifique se você fez login no gcloud com a conta de usuário pretendida.

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

6. Receba o ID do projeto de administrador do Terraform executando o seguinte comando:

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

7. Todos os recursos associados ao workshop são armazenados como variáveis em um arquivo vars.sh armazenado em um bucket GCS no projeto de administração do Terraform. Receba o arquivo vars.sh para seu projeto de administrador do 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. Clique no link exibido para abrir a página do Cloud Build do projeto de administrador do Terraform e verificar se o build foi concluído.

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

Ao acessar o Console do Cloud pela primeira vez, aceite os Termos de Serviço do Google.

9. Agora que você está na página do Cloud Build, clique no link History na navegação à esquerda e clique no build mais recente para conferir os detalhes da aplicação inicial do Terraform. Os recursos a seguir são criados como parte do script do Terraform. Também é possível consultar o diagrama de arquitetura acima.

• 4 projetos do GCP na organização A conta de faturamento fornecida está associada a cada projeto.
• Um projeto é o network host project da VPC compartilhada. Nenhum outro recurso foi criado neste projeto.
• Um projeto é o ops project usado para os clusters do GKE do plano de controle do Istio.
• Dois projetos representam duas equipes de desenvolvimento diferentes que trabalham nos respectivos serviços.
• Dois clusters do GKE são criados em cada um dos três projetos ops, dev1 e dev2.
• É criado um repositório de CSR chamado k8s-repo, que contém seis pastas para arquivos de manifestos do Kubernetes. Uma pasta por cluster do GKE. Ele é usado para implantar manifestos do Kubernetes nos clusters de forma GitOps.
• Um gatilho do Cloud Build é criado para que, sempre que houver um commit na ramificação mestre do k8s-repo, ele implante os manifestos do Kubernetes nos clusters do GKE das respectivas pastas.

O script do Terraform leva de 40 a 50 minutos.

10. Quando o build for concluído no terraform admin project, outro build será iniciado no projeto ops. Clique no link exibido para abrir a página do Cloud Build do ops project e verificar se o Cloud Build k8s-repo foi concluído.

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

Observação: essa compilação precisa ser concluída antes que você possa verificar a instalação do Istio.

Confirme a instalação

11. Criar arquivos kubeconfig para todos os clusters. Execute o script a seguir.

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

Esse script cria um novo arquivo kubeconfig na pasta gke chamada kubemesh.

12. Altere a variável KUBECONFIG para apontar para o novo arquivo kubeconfig.

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

13. Adicione vars.sh e KUBECONFIG var ao .bashrc no Cloud Shell para que ele seja gerado sempre que o Cloud Shell for reiniciado.

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

14. Liste os contextos do cluster. Serão exibidos seis clusters.

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

Verificar a instalação do Istio

15. Verifique se o Istio está instalado nos dois clusters. Para isso, verifique se todos os pods estão em execução e os jobs foram concluídos.

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. Verifique se o Istio está instalado nos dois clusters dev1. Somente o Citadel, o sidecar-injector e o coredns são executados nos clusters dev1. Elas compartilham um plano de controle do Istio em execução no cluster ops-1.

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

17. Verifique se o Istio está instalado nos dois clusters dev2. Somente o Citadel, o sidecar-injector e o coredns são executados nos clusters dev2. Elas compartilham um plano de controle do Istio em execução no cluster 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

Verificar a descoberta de serviços para planos de controle compartilhados

18. Se quiser, verifique se os secrets estão implantados.

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

Neste workshop, você vai usar uma única VPC compartilhada na qual todos os clusters do GKE são criados. Para descobrir serviços nos clusters, use os arquivos kubeconfig (para cada um dos clusters de aplicativo) criados como secrets nos clusters de operações. O Pilot usa esses secrets para descobrir serviços consultando o servidor da API Kube dos clusters de aplicativos (autenticados pelos secrets acima). Você vê que os dois clusters de operações podem se autenticar em todos os clusters de app usando secrets criados pelo kubeconfig. Os clusters de operações podem descobrir serviços automaticamente usando os arquivos kubeconfig como um método secreto. Isso exige que o Pilot nos clusters de operações tenha acesso ao servidor da API Kube de todos os outros clusters. Se o Pilot não conseguir acessar os servidores da API Kube, adicione manualmente os serviços remotos como ServiceEntries. Pense nas entradas de serviço como entradas DNS no seu registro de serviço. O ServiceEntries define um serviço usando um nome DNS totalmente qualificado ( FQDN) e um endereço IP em que ele pode ser acessado. Consulte a documentação do Istio Multicluster para mais informações.

6. Explicação sobre o repo de infraestrutura

Infraestrutura do Cloud Build

Os recursos do GCP para o workshop foram criados usando o Cloud Build e um repositório de CSR (em inglês) do infrastructure. Você acabou de executar um script de inicialização (localizado em scripts/bootstrap_workshop.sh) no terminal local. O script de inicialização cria uma pasta do GCP, um projeto de administrador do Terraform e as permissões apropriadas do IAM para a conta de serviço do Cloud Build. O projeto de administração do Terraform é usado para armazenar estados, registros e scripts diversos do Terraform. Ele contém os repositórios de CSR infrastructure e k8s_repo. Esses repositórios são explicados em detalhes na próxima seção. Nenhum outro recurso de workshop é criado no projeto de administração do Terraform. A conta de serviço do Cloud Build no projeto "terraform admin" é usada para criar recursos para o workshop.

Um arquivo cloudbuild.yaml localizado na pasta infrastructure é usado para criar recursos do GCP para o workshop. Ele cria uma imagem do builder personalizada com todas as ferramentas necessárias para criar recursos do GCP. Essas ferramentas incluem o SDK da gcloud, o Terraform e outros utilitários, como python, git, jq etc. A imagem do builder personalizado executa terraform plan e apply para cada recurso. Os arquivos do Terraform de cada recurso ficam em pastas separadas (detalhes na próxima seção). Os recursos são criados um de cada vez e na ordem de como normalmente seriam criados. Por exemplo, um projeto do GCP é criado antes da criação dos recursos. Consulte o arquivo cloudbuild.yaml para mais detalhes.

O Cloud Build é acionado sempre que há um commit no repositório infrastructure. Qualquer alteração feita na infraestrutura é armazenada como infraestrutura como código (IaC, na sigla em inglês) e comprometida com o repositório. O estado do seu workshop sempre é armazenado nesse repositório.

Estrutura de pastas - equipes, ambientes e recursos

O repositório de infraestrutura configura os recursos de infraestrutura do GCP para o workshop. Ele é estruturado em pastas e subpastas. As pastas base no repositório representam as team que têm recursos específicos do GCP. A próxima camada de pastas representa o environment específico para a equipe (por exemplo, dev, stage, prod). A próxima camada de pastas no ambiente representa o resource específico (por exemplo, host_project, gke_clusters etc). Os scripts e arquivos do Terraform necessários estão dentro das pastas de recursos.

Estes quatro tipos de equipes estão representados neste workshop:

1. Infrastructure: representa a equipe de infraestrutura em nuvem. Ele é responsável por criar os recursos do GCP para todas as outras equipes. Eles usam o projeto de administrador do Terraform para os recursos. O repositório de infraestrutura em si está no projeto de administração do Terraform, bem como os arquivos de estado do Terraform (explicados abaixo). Esses recursos são criados por um script bash durante o processo de bootstrap (consulte o Módulo 0: fluxo de trabalho do administrador para mais detalhes).
2. network: representa a equipe de rede. Eles são responsáveis pelos recursos de rede e da VPC. Ele é proprietário dos recursos do GCP a seguir.
3. host project: representa o projeto host da VPC compartilhada.
4. shared VPC: representa a VPC compartilhada, as sub-redes, os intervalos de IP secundários, as rotas e as regras de firewall.
5. ops: representa a equipe de operações/devops. Ele tem os recursos a seguir.
6. ops project: representa um projeto para todos os recursos operacionais.
7. gke clusters: um cluster de operações do GKE por região. O plano de controle do Istio está instalado em cada um dos clusters operacionais do GKE.
8. k8s-repo: um repositório de CSR que contém manifestos do GKE para todos os clusters do GKE.
9. apps: representa as equipes de aplicativos. Este workshop vai simular duas equipes, app1 e app2. Ele tem os recursos a seguir.
10. app projects: cada equipe de app tem o próprio conjunto de projetos. Isso permite que eles controlem o faturamento e o IAM para o projeto específico.
11. gke clusters: são clusters de aplicativos em que os contêineres/pods do aplicativo são executados.
12. gce instances: opcionalmente, se tiver aplicativos executados em instâncias do GCE. Neste workshop, o app1 tem algumas instâncias do GCE em que parte do aplicativo é executada.

Neste workshop, o mesmo app (Hipster Shop) representa tanto o app1 quanto o app2.

Provedor, estados e saídas – back-ends e estados compartilhados

Os provedores google e google-beta estão localizados em gcp/[environment]/gcp/provider.tf. O arquivo provider.tf tem um link simbólico em todas as pastas de recursos. Isso permite alterar o provedor em um só lugar, em vez de gerenciar os provedores individualmente para cada recurso.

Todo recurso contém um arquivo backend.tf que define o local do arquivo tfstate do recurso. Esse arquivo backend.tf é gerado com base em um modelo (localizado em templates/backend.tf_tmpl) usando um script (localizado em scripts/setup_terraform_admin_project) e colocado na respectiva pasta de recursos. Os buckets do Google Cloud Storage (GCS) são usados como back-ends. O nome da pasta do bucket do GCS corresponde ao nome do recurso. Todos os back-ends de recursos residem no projeto admin do Terraform.

Recursos com valores interdependentes contêm um arquivo output.tf. Os valores de saída necessários são armazenados no arquivo tfstate definido no back-end para esse recurso específico. Por exemplo, para criar um cluster do GKE em um projeto, você precisa saber o ID do projeto. O ID do projeto é enviado por output.tf para o arquivo tfstate que pode ser usado por uma fonte de dados terraform_remote_state no recurso de cluster do GKE.

O arquivo shared_state é uma fonte de dados terraform_remote_state que aponta para o arquivo tfstate de um recurso. Há um arquivo (ou arquivos) shared_state_[resource_name].tf nas pastas de recursos que exigem saídas de outros recursos. Por exemplo, na pasta de recursos ops_gke, há arquivos shared_state dos recursos ops_project e shared_vpc, porque você precisa do ID do projeto e dos detalhes da VPC para criar clusters do GKE no projeto ops. Os arquivos shared_state são gerados a partir de um modelo (localizado em templates/shared_state.tf_tmpl) usando um script (localizado em scripts/setup_terraform_admin_project). Todos os recursos Os arquivos shared_state são colocados na pasta gcp/[environment]/shared_states. Os arquivos shared_state necessários são vinculados simbolicamente nas respectivas pastas de recursos. Colocar todos os arquivos shared_state em uma pasta e vinculá-los ao sym nas pastas de recursos apropriadas facilita o gerenciamento de todos os arquivos de estado em um único local.

Variáveis

Todos os valores de recursos são armazenados como variáveis de ambiente. Essas variáveis são armazenadas (como instruções de exportação) em um arquivo chamado vars.sh, localizado em um bucket do GCS no projeto de administração do Terraform. Ele contém o ID da organização, a conta de faturamento, os IDs do projeto, os detalhes do cluster do GKE etc. É possível fazer o download e usar o vars.sh em qualquer terminal para acessar os valores da sua configuração.

As variáveis do Terraform são armazenadas em vars.sh como TF_VAR_[variable name]. Essas variáveis são usadas para gerar um arquivo variables.tfvars na respectiva pasta de recursos. O arquivo variables.tfvars contém todas as variáveis com os valores delas. O arquivo variables.tfvars é gerado a partir de um arquivo de modelo na mesma pasta usando um script (localizado em scripts/setup_terraform_admin_project).

Explicação sobre o repo do K8s

k8s_repo é um repositório de CSR (separado do repositório de infraestrutura) localizado no projeto de administrador do Terraform. Ele é usado para armazenar e aplicar manifestos do GKE a todos os clusters do GKE. k8s_repo é criado pela infraestrutura do Cloud Build (consulte a seção anterior para mais detalhes). Durante o processo inicial do Cloud Build na infraestrutura, foram criados seis clusters do GKE. Na k8s_repo, seis pastas são criadas. Cada pasta (nome correspondente ao nome do cluster do GKE) corresponde a um cluster do GKE que contém os respectivos arquivos de manifesto de recursos. Semelhante à criação de infraestrutura, o Cloud Build é usado para aplicar os manifestos do Kubernetes a todos os clusters do GKE usando o k8s_repo. O Cloud Build é acionado sempre que há um commit no repositório k8s_repo. Assim como na infraestrutura, todos os manifestos do Kubernetes são armazenados como código no repositório k8s_repo e o estado de cada cluster do GKE é sempre armazenado na respectiva pasta.

Como parte do build da infraestrutura inicial, k8s_repo é criado e o Istio é instalado em todos os clusters.

Projetos, clusters do GKE e namespaces

Os recursos deste workshop estão divididos em diferentes projetos do GCP. Os projetos devem corresponder à estrutura organizacional (ou de equipe) da sua empresa. As equipes (da sua organização) responsáveis por diferentes projetos/produtos/recursos usam diferentes projetos do GCP. Com projetos separados, é possível criar conjuntos distintos de permissões do IAM e gerenciar o faturamento no nível do projeto. Além disso, as cotas também são gerenciadas no nível do projeto.

Cinco equipes estão representadas neste workshop, cada uma com seu próprio projeto.

1. A equipe de infraestrutura que cria recursos do GCP usa o Terraform admin project. Eles gerenciam a infraestrutura como código em um repositório de CSR (chamado infrastructure) e armazenam todas as informações de estado do Terraform referentes aos recursos criados no GCP nos buckets do GCS. Eles controlam o acesso ao repositório do CSR e aos buckets do GCS de estado do Terraform.
2. A equipe de rede que cria a VPC compartilhada usa o host project. Esse projeto contém a VPC, sub-redes, rotas e regras de firewall. Com uma VPC compartilhada, eles podem gerenciar centralmente a rede dos recursos do GCP. Todos os projetos usaram esta única VPC compartilhada para rede.
3. A equipe de operações/plataforma que cria clusters do GKE e planos de controle do ASM/Istio usa o ops project. Eles gerenciam o ciclo de vida dos clusters do GKE e da malha de serviço. Eles são responsáveis por aumentar a proteção dos clusters e gerenciar a resiliência e a escala da plataforma Kubernetes. Neste workshop, você vai usar o método gitops de implantação de recursos no Kubernetes. Há um repositório CSR (chamado k8s_repo) no projeto ops.
4. Por fim, as equipes dev1 e dev2 (representam duas equipes de desenvolvimento) que criam aplicativos usam dev1 e dev2 projects próprios. Esses são os aplicativos e serviços que você oferece aos seus clientes. Eles são criados na plataforma que a equipe de operações gerencia. Os recursos (implantações, serviços etc.) são enviados por push para o k8s_repo e implantados nos clusters apropriados. É importante observar que o foco deste workshop não são as práticas recomendadas e as ferramentas de CI/CD. Você vai usar o Cloud Build para automatizar a implantação de recursos do Kubernetes diretamente nos clusters do GKE. Em cenários de produção reais, você usaria uma solução de CI/CD adequada para implantar aplicativos nos clusters do GKE.

Há dois tipos de clusters do GKE neste workshop.

1. Clusters de operações: usados pela equipe de operações para executar ferramentas de DevOps. Neste workshop, eles executam o plano de controle do ASM/Istio para gerenciar a malha de serviço.
2. Clusters de aplicativos (apps): usados pelas equipes de desenvolvimento para executar aplicativos. Neste workshop, usamos o aplicativo Hipster Shop.

Separar as ferramentas de operações/administrador dos clusters que executam o aplicativo permite que você gerencie o ciclo de vida de cada recurso de maneira independente. Os dois tipos de clusters também existem em projetos diferentes pertencentes à equipe/produto que os utiliza, o que também facilita o gerenciamento das permissões do IAM.

Há um total de seis clusters do GKE. Dois clusters ops regionais são criados no projeto ops. O plano de controle do ASM/Istio está instalado nos dois clusters de operações. Cada cluster de operações está em uma região diferente. Além disso, há quatro clusters de aplicativos zonais. Eles são criados nos próprios projetos. Este workshop simula duas equipes de desenvolvimento com projetos próprios. Cada projeto contém dois clusters de apps. Os clusters de apps são clusters zonais em zonas diferentes. Os quatro clusters de apps estão localizados em duas regiões e quatro zonas. Dessa forma, você obtém redundância regional e zonal.

O aplicativo usado neste workshop, o Hipster Shop, é implantado nos quatro clusters de apps. Cada microsserviço reside no próprio namespace em cada cluster de app. As implantações do aplicativo Hipster Shop (pods) não são incluídas nos clusters de operações. No entanto, os namespaces e os recursos de serviço de todos os microsserviços também são criados nos clusters de operações. O plano de controle do ASM/Istio usa os registros de serviço do Kubernetes para a descoberta de serviços. Na ausência de serviços (nos clusters de operações), você teria que criar ServiceEntries manualmente para cada serviço em execução no cluster de aplicativo.

Você vai implantar um aplicativo de microsserviços de 10 níveis neste workshop. O aplicativo é um aplicativo de comércio eletrônico baseado na Web chamado " Hipster Shop" onde os usuários podem procurar itens, adicioná-los ao carrinho e comprá-los.

Manifestos do Kubernetes e k8s_repo

Use o k8s_repo para adicionar recursos do Kubernetes a todos os clusters do GKE. Para fazer isso, copie os manifestos do Kubernetes e confirme o k8s_repo. Todas as confirmações para k8s_repo acionam um job do Cloud Build que implanta os manifestos do Kubernetes no respectivo cluster. O manifesto de cada cluster fica em uma pasta separada com o mesmo nome do cluster.

Os seis nomes de cluster são:

1. gke-asm-1-r1-prod: cluster de operações regional na região 1
2. gke-asm-2-r2-prod: cluster de operações regional na região 2
3. gke-1-apps-r1a-prod: cluster de apps na região 1, zona a
4. gke-2-apps-r1b-prod: cluster de apps na região 1 zona b
5. gke-3-apps-r2a-prod: cluster de apps na região 2 (zona a)
6. gke-4-apps-r2b-prod: cluster de apps na região 2 zona b

O k8s_repo tem pastas correspondentes a esses clusters. Qualquer manifesto colocado nessas pastas é aplicado ao cluster do GKE correspondente. Manifestos para cada cluster são colocados em subpastas (dentro da pasta principal do cluster) para facilitar o gerenciamento. Neste workshop, você vai usar o Kustomize para acompanhar os recursos que serão implantados. Consulte a documentação oficial do Kustomize para mais detalhes.

7. Implantar o app de exemplo

Objetivo: implantar o app Hipster Shop em clusters de apps

• k8s-repo (clone)
• Copiar os manifestos do Hipster Shop para todos os clusters de apps
• Criar serviços para o app de compras Hipster nos clusters de operações
• Configure loadgenerators nos clusters de operações para testar a conectividade global
• Verificar a conectividade segura com o aplicativo Hipster Shop

SCRIPT PARA RASTREAMENTO RÁPIDO

Se você escolher esse método, execute o script a seguir para concluir o laboratório.

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

Instruções do laboratório do método copiar e colar

Se você já tiver concluído o script de trilha rápida deste laboratório, não execute o método de copiar e colar abaixo**.**

Clonar o repositório de origem do projeto de operações

Como parte do build inicial da infraestrutura do Terraform, o k8s-repo já foi criado no projeto ops.

1. Crie um diretório vazio para o repositório git:

mkdir $WORKDIR/k8s-repo
 

2. Inicie o repositório git, adicione o método remoto e extraia o mestre do repositório 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. Define a configuração local do git local.

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 manifestos, confirmar e enviar

4. Copie os namespaces e serviços do Hipster Shop para o repositório de origem de todos os clusters.

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. Copie a pasta do aplicativo kustomization.yaml para todos os clusters.

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 as implantações, o RBAC e o PodSecurityPolicy do Hipster Shop no repositório de origem dos clusters de apps.

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

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

7. Remova a implantação do cartservice, o rbac e o podsecuritypolicy de todos os clusters de desenvolvimento, exceto um. O Hipstershop não foi criado para implantação de vários clusters. Por isso, para evitar resultados inconsistentes, usamos apenas um 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. Adicione a implantação cartservice, o rbac e o podsecuritypolicy ao kustomization.yaml somente no primeiro cluster de desenvolvimento.

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. Remover podsecuritypolicies, implantações e diretórios Rbac dos clusters de operações 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. Substitua o PROJECT_ID nos manifestos do 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. Copie os manifestos do IngressGateway e do VirtualService para o repositório de origem dos clusters de operações.

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. Copie os recursos do Config Connector para um dos clusters em cada projeto.

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. Substitua o PROJECT_ID nos manifestos do 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. Copiar os manifestos loadgenerator (implantação, PodSecurityPolicy e RBAC) para os clusters de operações. O app Hipster Shop é exposto usando um balanceador de carga global do Google Cloud (GCLB). O GCLB recebe o tráfego do cliente (destinado a frontend) e o envia para a instância mais próxima do serviço. Colocar loadgenerator nos dois clusters de operações vai garantir que o tráfego seja enviado para os dois gateways de entrada do Istio em execução nos clusters de operações. O balanceamento de carga é explicado em detalhes na próxima seção.

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. Substitua o ID do projeto de operações nos manifestos loadgenerator dos dois clusters de operações.

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. Adicione os recursos loadgenerator a kustomization.yaml para os dois clusters de operações.

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. Confirme com 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. Confira o status do Projeto de operações do Cloud Build em uma guia aberta ou clique no link a seguir:

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

Verificar a implantação do aplicativo

19. Verifique se os pods em todos os namespaces do aplicativo, exceto o carrinho, estão no estado "Em execução" em todos os clusters de desenvolvimento.

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. Verifique se os pods no namespace do carrinho estão no estado "Em execução" apenas no primeiro cluster de desenvolvimento.

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

Acessar o aplicativo Hipster Shop

Balanceamento de carga global

Agora o aplicativo Hipster Shop está implantado nos quatro clusters de aplicativos. Esses clusters estão em duas regiões e quatro zonas. Os clientes podem acessar o aplicativo Hipster Shop acessando o serviço frontend. O serviço frontend é executado nos quatro clusters de apps. Um balanceador de carga do Google Cloud ( GCLB) é usado para receber o tráfego do cliente nas quatro instâncias do serviço frontend.

Os gateways de entrada do Istio são executados apenas nos clusters de operações e atuam como um balanceador de carga regional para os dois clusters de aplicativos zonais na região. O GCLB usa os dois gateways de entrada do Istio (em execução nos dois clusters de operações) como back-ends para o serviço de front-end global. Os gateways de entrada do Istio recebem o tráfego do cliente do GCLB e o enviam para os pods de front-end em execução nos clusters do aplicativo.

Outra opção é colocar os gateways de entrada do Istio diretamente nos clusters do aplicativo para que o GCLB os use como back-ends.

Controlador do GKE Autoneg

O serviço do Kubernetes no gateway de entrada do Istio se registra como um back-end para o GCLB usando os grupos de endpoints de rede (NEGs, na sigla em inglês). Os NEGs permitem o balanceamento de carga nativo de contêiner usando GCLBs. Os NEGs são criados por uma anotação especial em um serviço do Kubernetes para que possam se registrar no controlador de NEG. O controlador Autoneg é um controlador especial do GKE que automatiza a criação de NEGs e os atribui como back-ends a um GCLB usando anotações de serviço. Os planos de controle do Istio, incluindo os gateways de entrada do Istio, são implantados durante a infraestrutura inicial do Terraform Cloud Build. A configuração do GCLB e do AutoML é feita como parte da infraestrutura inicial do Terraform no Cloud Build.

Entrada segura usando o Cloud Endpoints e certificados gerenciados

Os certificados gerenciados pelo GCP são usados para proteger o tráfego do cliente para o serviço GCLB do frontend. O GCLB usa certificados gerenciados para o serviço frontend global, e o certificado é encerrado no GCLB. Neste workshop, você vai usar o Cloud Endpoints como o domínio para o certificado gerenciado. Também é possível usar seu domínio e um nome DNS para que frontend crie certificados gerenciados do GCP.

21. Para acessar o site do Hipster, clique na saída do link do comando a seguir.

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

22. Você pode verificar se o certificado é válido clicando no símbolo de cadeado na barra de URL da sua guia do Chrome.

Verificar o balanceamento de carga global

Como parte da implantação do aplicativo, os geradores de carga foram implantados nos dois clusters de operações que geram tráfego de teste para o link do Cloud Endpoints de loja do GCLB Hipster. Verifique se o GCLB está recebendo tráfego e enviando para os dois gateways de entrada do Istio.

23. Acesse o GCLB > Link de monitoramento para o projeto de operações em que o GCLB do Hipster Shop é criado.

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. Mude de Todos os back-ends para istio-ingressgateway no menu suspenso "Back-end", conforme mostrado abaixo.

25. Observe o tráfego indo para istio-ingressgateways.

Há três NEGs criados por istio-ingressgateway. Como os clusters de operações são regionais, um NEG é criado para cada zona na região. No entanto, os pods istio-ingressgateway são executados em uma única zona por região. O tráfego é exibido para os pods istio-ingressgateway.

Geradores de carga estão em execução nos dois clusters de operações, simulando o tráfego de cliente das duas regiões em que estão. A carga gerada na região 1 do cluster de operações está sendo enviada para istio-ingressgateway na região 2. Da mesma forma, a carga gerada na região 2 do cluster de operações está sendo enviada para istio-ingressgateway na região 2.

8. Observabilidade com o Stackdriver

Objetivo: conectar a telemetria do Istio ao Stackdriver e validar.

• Instalar istio-telemetry recursos
• Criar/atualizar painéis de serviços do Istio
• Ver registros do contêiner
• Ver rastreamento distribuído no Stackdriver

SCRIPT PARA RASTREAMENTO RÁPIDO

Se você escolher esse método, execute o script a seguir para concluir o laboratório.

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

Instruções do laboratório do método copiar e colar

Se você já tiver concluído o script de trilha rápida deste laboratório, não execute o método de copiar e colar abaixo**.**

Um dos principais recursos do Istio é a observabilidade integrada ("o11y"). Isso significa que, mesmo com contêineres de caixa preta não instrumentados, os operadores ainda podem observar o tráfego que entra e sai desses contêineres, fornecendo serviços aos clientes. Essa observação assume a forma de alguns métodos diferentes: métricas, registros e traces.

Também utilizaremos o sistema integrado de geração de carga do Hipster Shop. A observabilidade não funciona muito bem em um sistema estático sem tráfego. Portanto, a geração de carga nos ajuda a entender como ela funciona. Essa carga já está em execução e agora só podemos vê-la.

1. Instale o arquivo de configuração do istio no 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. Confirme com k8s-repo.

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

3. Confira o status do Projeto de operações do Cloud Build em uma guia aberta ou clique no link a seguir:

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

4. Verifique a integração do Istio → Stackdriver. Acesse a CRD do Stackdriver Handler.

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

A saída deve mostrar um gerenciador chamado stackdriver:

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

5. Verificar se a exportação de métricas do Istio para o Stackdriver está funcionando. Clique na saída do link deste comando:

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

Você vai precisar criar um novo espaço de trabalho com o nome do projeto de operações. Basta escolher "OK". Se aparecer uma mensagem sobre a nova interface, basta dispensar a caixa de diálogo.

Em "Metrics Explorer", em "Find resource type and metric" tipo "istio" para ver opções como "Contagem de solicitações do servidor" no "Contêiner do Kubernetes", tipo de recurso. Isso nos mostra que as métricas estão fluindo da malha para o Stackdriver.

Você terá que Agrupar por destination_service_name se quiser ver as linhas abaixo.

Como visualizar métricas com painéis:

Agora que nossas métricas estão no sistema Stackdriver APM, queremos uma maneira de visualizá-las. Nesta seção, instalaremos um painel pré-criado que nos mostra os três " Golden Signals" das métricas: Tráfego (solicitações por segundo), Latência (nesse caso, 99o e 50o percentis) e Erros (neste exemplo, estamos excluindo Saturação).

O proxy Envoy do Istio oferece várias métricas, mas estas são um bom conjunto para começar. Confira a lista completa. Observe que cada métrica tem um conjunto de rótulos que podem ser usados para filtragem e agregação, como: destination_service, source_workload_namespace, response_code, istio_tcp_received_bytes_total etc.

6. Agora, vamos adicionar nosso painel de métricas predefinidas. Vamos usar a API Dashboard diretamente. Isso é algo que você normalmente não faria gerando chamadas de API manualmente, faria parte de um sistema de automação ou criaria o painel manualmente na IU da Web. Isso fará com que comecemos rapidamente:

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. Navegue até o link de saída abaixo para visualizar o "Painel de serviços" recém-adicionado.

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

Poderíamos editar o painel no local usando a UX, mas, no nosso caso, vamos adicionar rapidamente um novo gráfico usando a API. Para fazer isso, você deve puxar a versão mais recente do painel, aplicar suas edições e, em seguida, enviá-lo de volta usando o método HTTP PATCH.

8. Para acessar um painel, consulte a API Monitoring. Acesse o painel que acabou de ser adicionado:

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. Adicione um novo gráfico: (50o %ile latência): [ Referência da API] Agora podemos adicionar um novo widget de gráfico ao nosso dashboard no código. Essa mudança pode ser revisada por colegas e verificada no controle de versões. Este é um widget que mostra a latência de 50% (latência mediana).

Tente editar o painel que acabou de criar, adicionando uma nova estrofe:

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. Atualize o painel de serviços atual:

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. Confira o painel atualizado acessando o seguinte link de saída:

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

12. Faça algumas análises de registros simples.

O Istio fornece um conjunto de registros estruturados para todo o tráfego de rede em malha e os envia ao Stackdriver Logging para permitir a análise entre clusters em uma ferramenta poderosa. Os registros são anotados com metadados de nível de serviço, como cluster, container, app, connection_id etc.

Veja um exemplo de entrada de registro (neste caso, o log de acesso do proxy Envoy) (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" 
...  
 }

Veja seus registros aqui:

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

Para ver os registros do plano de controle do Istio, selecione Recurso > Kubernetes e pesquisar no "piloto" -

Aqui podemos ver o plano de controle do Istio enviando a configuração do proxy aos proxies sidecar para cada serviço de app de amostra. "CDS", "LDS" e "RDS" representam diferentes APIs Envoy ( mais informações, link em inglês).

Além dos registros do Istio, também é possível encontrar registros de contêineres e de infraestrutura ou outros registros de serviços do GCP na mesma interface. Confira algumas exemplos de consultas de registros para o GKE. O visualizador de registros também permite criar métricas com base nos registros (por exemplo, "contar cada erro que corresponde a alguma string") que podem ser usadas em um painel ou como parte de um alerta. Os registros também podem ser transmitidos para outras ferramentas de análise, como o BigQuery.

Alguns exemplos de filtros para lojas hipster:

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

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

13. Confira o Rastreamentos distribuídos.

Agora que você está trabalhando com um sistema distribuído, a depuração precisa de uma nova ferramenta: o Rastreamento distribuído. Essa ferramenta permite descobrir estatísticas sobre como seus serviços estão interagindo (como descobrir eventos lentos na figura abaixo), bem como se aprofundar em rastros de amostra brutos para investigar os detalhes do que realmente está acontecendo.

A visualização da linha do tempo mostra todas as solicitações ao longo do tempo, representadas em gráfico pela latência ou o tempo gasto entre a solicitação inicial, pela pilha do Hipster, para finalmente responder ao usuário final. Quanto mais altos os pontos, mais lenta e menos feliz é a experiência do usuário.

Você pode clicar em um ponto para encontrar a visualização em cascata detalhada dessa solicitação específica. Essa capacidade de encontrar os detalhes brutos de uma solicitação específica (não apenas estatísticas agregadas) é vital para entender a interação entre os serviços, especialmente ao procurar interações raras, mas ruins, entre os serviços.

A visualização em cascata é familiar para qualquer pessoa que já tenha usado um depurador. No entanto, nesse caso, em vez de mostrar o tempo gasto em diferentes processos de um único aplicativo, ela está mostrando o tempo gasto na malha, entre serviços, em execução em contêineres separados.

Aqui você encontra seus traces:

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

Exemplo de captura de tela da ferramenta:

9. Autenticação TLS mútua

Objetivo: proteger a conectividade entre microsserviços (AuthN).

• Ativar mTLS em toda a malha
• Verificar o mTLS inspecionando registros

SCRIPT PARA RASTREAMENTO RÁPIDO

Se você escolher esse método, execute o script a seguir para concluir o laboratório.

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

Instruções do laboratório do método copiar e colar

Se você já tiver concluído o script de trilha rápida deste laboratório, não execute o método de copiar e colar abaixo**.**

Agora que nossos apps estão instalados e a observabilidade está configurada, podemos começar a proteger as conexões entre os serviços para garantir que eles continuem funcionando.

Por exemplo, podemos ver no painel do Kiali que nossos serviços não estão usando MTLS (sem ícone de "bloqueio"). Mas o tráfego está fluindo e o sistema está funcionando bem. Nosso painel do Stackdriver Golden Metrics nos traz a tranquilidade de saber que, no geral, tudo está funcionando.

1. Verifique o MeshPolicy em clusters de operações. O mTLS é PERMISSIVE, permitindo tráfego criptografado e não 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"
      }
    }
  ]
}

O Istio é configurado em todos os clusters usando o operador Istio, que usa o recurso personalizado (CR, na sigla em inglês) IstioControlPlane. Para configurar o mTLS em todos os clusters, atualizaremos a resposta automática do IstioControlPlane e o k8s-repo. Configuração global > mTLS > ativado: verdadeiro na resposta automática do IstioControlPlane resulta nas duas alterações a seguir no plano de controle do Istio:

• O MeshPolicy está definido para ativar a malha mTLS em todos os serviços em execução em todos os clusters.
• Uma DestinationRule é criada para permitir o tráfego ISTIO_MUTUAL entre Serviços em execução em todos os clusters.

2. Aplicaremos um patch personalizado à resposta automática do istioControlPlane para ativar o mTLS em todo o cluster. Copie o patch para o diretório relevante de todos os clusters e adicione um patch do 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. Confirme com k8s-repo.

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

4. Confira o status do Projeto de operações do Cloud Build em uma guia aberta ou clique no link a seguir:

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

 

Verificar mTLS

5. Verifique o MeshPolicy mais uma vez nos clusters de operações. O mTLS não é mais PERMISSIVE e só vai permitir tráfego 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
 

Resposta (não copie):

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

6. Descreva a DestinationRule criada pelo controlador do operador do 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'

Resposta (não copie):

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

Também podemos ver a mudança de HTTP para HTTPS nos registros.

Podemos expor esse campo específico dos registros na interface clicando em uma entrada de registro e, em seguida, clicando no valor do campo que você quer exibir. No nosso caso, clique em "http" ao lado de "protocol:

O resultado é uma boa forma de visualizar a mudança:

10. Implantações canário

Objetivo: lançar uma nova versão do serviço de front-end.

• Lançar o serviço frontend-v2 (próxima versão de produção) em uma região
• Use DestinationRules e VirtualServices para direcionar lentamente o tráfego para frontend-v2
• Verificar o pipeline de implantação do GitOps inspecionando a série de commits para o k8s-repo

SCRIPT PARA RASTREAMENTO RÁPIDO

Se você escolher esse método, execute o script a seguir para concluir o laboratório.

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

Instruções do laboratório do método copiar e colar

Se você já tiver concluído o script de trilha rápida deste laboratório, não execute o método de copiar e colar abaixo**.**

Uma implantação canário é o lançamento progressivo de um novo serviço. Em uma implantação canário, você envia uma quantidade crescente de tráfego para a nova versão e, ao mesmo tempo, envia a porcentagem restante para a versão atual. Um padrão comum é realizar uma análise de canários em cada estágio da divisão de tráfego e comparar os "indicadores de ouro" da nova versão (latência, taxa de erro, saturação) em relação a um valor de referência. Isso ajuda a evitar interrupções e garantir a estabilidade da nova versão "v2". o serviço em todos os estágios da divisão de tráfego.

Nesta seção, você vai aprender a usar as políticas de tráfego do Cloud Build e do Istio para criar uma implantação canário básica para uma nova versão do serviço frontend.

Primeiro, vamos executar o pipeline canário na região DEV1 (us-west1) e implantar o front-end v2 nos dois clusters nessa região. Depois, vamos executar o pipeline canário na região DEV2 (us-central) e implantar a v2 nos dois clusters nessa região. Executar o pipeline em regiões em ordem, em vez de em paralelo em todas as regiões, ajuda a evitar interrupções globais causadas por configurações incorretas ou por bugs no próprio aplicativo v2.

Observação: acionaremos manualmente o pipeline canário nas duas regiões. No entanto, na produção, você usaria um gatilho automatizado, por exemplo, com base em uma nova tag de imagem do Docker enviada para um registro.

1. No Cloud Shell, defina algumas variáveis de ambiente para simplificar a execução dos outros comandos.

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

2. Execute o script repo_setup.sh, para copiar os manifestos de valor de referência no k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

Os seguintes manifestos são copiados:

• implantação do frontend-v2
• Patch frontend-v1 (para incluir o rótulo "v1" e uma imagem com um endpoint "/version")
• respy, um pequeno pod que vai imprimir a distribuição de resposta HTTP e nos ajudar a visualizar a implantação canário em tempo real.
• DestinationRule do front-end do Istio: divide o serviço do Kubernetes de front-end em dois subconjuntos, v1 e v2, com base na "versão". rótulo de implantação
• frontend do Istio VirtualService: encaminha 100% do tráfego para o front-end v1. Isso substitui o comportamento round-robin padrão do serviço do Kubernetes, que enviaria imediatamente 50% de todo o tráfego regional do Dev1 para o front-end v2.

3. Confirmar alterações em k8s_repo:

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

4. Confira o status do Projeto de operações do Cloud Build em uma guia aberta ou clique no link a seguir:

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

5. Navegue até o Cloud Build no console do projeto OPS1. Aguarde a conclusão do pipeline do Cloud Build e receba os pods no namespace de front-end nos dois clusters DEV1. Você verá o seguinte:

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

Observação: pressione Ctrl+C para sair dos comandos do watch.

Vamos usar o tmux para dividir a janela do cloudshell em dois painéis:

• O painel inferior executará o comando watch para observar a distribuição de resposta HTTP para o serviço front-end.
• O painel superior executa o script de pipeline canário real.

6. Use o comando para dividir a janela do Cloud Shell e executar o comando watch no painel de baixo.

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"
 

Resposta (não copie)

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

Podemos ver que todo o tráfego está indo para a implantação do frontend v1, definida no novo VirtualService.

7. Execute o pipeline canário na região Dev1. Fornecemos um script que atualiza as porcentagens de tráfego do frontend-v2 no VirtualService (atualizando os pesos para 20%, 50%, 80% e depois 100%). Entre as atualizações, o script aguarda a conclusão do pipeline do Cloud Build. Execute o script de implantação canário para a região Dev1. Observação: este script leva cerca de 10 minutos para ser concluído.

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

É possível conferir a divisão do tráfego em tempo real na janela inferior em que o comando "respy" é executado. Por exemplo, na marca de 20%:

Resposta (não copie)

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

8. Quando o lançamento do Dev2 for concluído para o frontend-v2, você verá uma mensagem de êxito no final do script:

    Output (do not copy) 
   

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

9. E todo o tráfego de front-end de um pod Dev2 vai para frontend-v2:

    Output (do not copy) 
   

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

10. Feche o painel de divisão.

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

11. Navegue até o Cloud Source Repos no link gerado.

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

Você verá uma confirmação separada para cada porcentagem de tráfego, com a confirmação mais recente no topo da lista:

Repita o mesmo processo para a região Dev2. Observe que a região Dev2 ainda está "bloqueada" na v1. Isso ocorre porque, no script repo_setup de referência, enviamos um VirtualService para enviar explicitamente todo o tráfego para a v1. Assim, conseguimos criar um canário regional com segurança no Dev1 e garantir que ele fosse executado corretamente antes de lançar a nova versão globalmente.

12. Use o comando para dividir a janela do Cloud Shell e executar o comando watch no painel de baixo.

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"
 

Resposta (não copie)

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

Podemos ver que todo o tráfego está indo para a implantação do frontend v1, definida no novo VirtualService.

13. Execute o pipeline canário na região Dev2. Fornecemos um script que atualiza as porcentagens de tráfego do frontend-v2 no VirtualService (atualizando os pesos para 20%, 50%, 80% e depois 100%). Entre as atualizações, o script aguarda a conclusão do pipeline do Cloud Build. Execute o script de implantação canário para a região Dev1. Observação: este script leva cerca de 10 minutos para ser concluído.

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

Resposta (não copie)

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

14. Do pod Respy no Dev2, observe o tráfego dos pods Dev2 migrar progressivamente do front-end v1 para v2. Depois que o script for concluído, você verá:

Resposta (não copie)

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

15. Feche o painel de divisão.

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

Nesta seção, mostramos como usar o Istio para implantações canário regionais. Na produção, em vez de um script manual, é possível acionar automaticamente esse script canário como um pipeline do Cloud Build, usando um gatilho, como uma nova imagem com tags enviada para um Container Registry. Também seria útil adicionar uma análise de canários entre cada etapa, analisando a latência e a taxa de erros da v2 em relação a um limite de segurança predefinido, antes de enviar mais tráfego.

11. Políticas de autorização

Objetivo: configurar o RBAC entre microsserviços (AuthZ).

• Criar AuthorizationPolicy para NEGAR o acesso a um microsserviço
• Criar AuthorizationPolicy para PERMITIR acesso específico a um microsserviço

SCRIPT PARA RASTREAMENTO RÁPIDO

Se você escolher esse método, execute o script a seguir para concluir o laboratório.

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

Instruções do laboratório do método copiar e colar

Se você já tiver concluído o script de trilha rápida deste laboratório, não execute o método de copiar e colar abaixo**.**

Ao contrário de um aplicativo monolítico que pode ser executado em um só lugar, os apps de microsserviços distribuídos globalmente fazem chamadas entre limites de rede. Isso significa mais pontos de entrada nos aplicativos e mais oportunidades para ataques maliciosos. Como os pods do Kubernetes têm IPs temporários, as regras tradicionais de firewall baseadas em IP não são mais adequadas para proteger o acesso entre cargas de trabalho. Em uma arquitetura de microsserviços, é necessária uma nova abordagem à segurança. Com base nos elementos de segurança do Kubernetes, como as contas de serviço, o Istio oferece um conjunto flexível de políticas de segurança para aplicativos.

As políticas do Istio abrangem a autenticação e a autorização. A autenticação verifica a identidade (este servidor é quem eles dizem ser) e a autorização verifica as permissões (o cliente tem permissão para fazer isso?). Abordamos a autenticação do Istio na seção TLS mútua do Módulo 1 (MeshPolicy). Nesta seção, vamos aprender a usar as políticas de autorização do Istio para controlar o acesso a uma das nossas cargas de trabalho de aplicativos, currencyservice.

Primeiro, implantaremos uma AuthorizationPolicy nos quatro clusters de desenvolvimento, encerrando todo o acesso a currencyservice e acionando um erro no front-end. Depois, vamos permitir que apenas o serviço front-end acesse o atributo "currencyservice".

1. Inspecione o conteúdo de currency-deny-all.yaml. Esta política usa seletores de rótulo de implantação para restringir o acesso ao currencyservice. Não há um campo spec: isso significa que esta política vai negar todo o acesso ao serviço selecionado.

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

Resposta (não copie)

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

2. Copiar a política de moeda em k8s-repo, para os clusters de operações em ambas as regiões.

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. Envie as alterações.

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

4. Verifique o status do projeto de operações do Cloud Build em uma guia aberta anteriormente ou clique no link a seguir:

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

5. Quando o build for concluído, tente acessar o front-end do hipstershop em um navegador no seguinte link:

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

Você verá um erro de autorização de "currencyservice":

6. Vamos investigar como o serviço de moeda está aplicando este AuthorizationPolicy. Primeiro, ative os registros no nível do rastreamento no proxy Envoy para um dos pods de moeda, já que as chamadas de autorização bloqueadas não são registradas por padrão.

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. Acesse os registros de RBAC (autorização) do proxy sidecar do serviço de moeda. A mensagem "aplicada negada" , indicando que o currencyservice está definido para bloquear todas as solicitações de entrada.

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

Resposta (não 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. Agora vamos permitir que o front-end, mas não os outros serviços de back-end, acessem o "currencyservice". Abra currency-allow-frontend.yaml e inspecione o conteúdo dele. Adicionamos a seguinte regra:

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

Resposta (não copie)

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

Neste caso, colocamos na lista de permissões um source.principal (cliente) específico para acessar o serviço de moeda. Esse source.principal é definido pela conta de serviço do Kubernetes. Neste caso, a conta de serviço que estamos na lista de permissões é a conta de serviço de front-end no namespace frontend.

Observação: ao usar contas de serviço do Kubernetes no Istio AuthorizationPolicies, você precisa primeiro ativar o TLS mútuo em todo o cluster, como fizemos no Módulo 1. Isso garante que as credenciais da conta de serviço sejam montadas nas solicitações.

9. Copiar a política de moeda atualizada

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. Envie as alterações.

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

11. Confira o status do Projeto de operações do Cloud Build em uma guia aberta ou clique no link a seguir:

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

12. Quando o build for concluído, abra o front-end do Hipstershop novamente. Desta vez, não haverá erros na página inicial. Isso ocorre porque o front-end tem permissão explícita para acessar o serviço atual.
13. Agora, tente finalizar a compra, adicionando itens ao carrinho e clicando em "fazer pedido". Desta vez, você verá um erro de conversão de preços do serviço de moeda. Isso ocorre porque colocamos apenas o front-end na lista de permissões. Assim, o checkoutservice ainda não consegue acessar o currencyservice.

14. Por fim, vamos permitir que o serviço de checkout acesse a moeda. Para isso,vamos adicionar outra regra à "Currencyservice" AuthorizationPolicy. Observe que estamos liberando o acesso à moeda apenas para os dois serviços que precisam de acesso a ela: front-end e checkout. Os outros back-ends ainda serão bloqueados.
15. Abra currency-allow-frontend-checkout.yaml e inspecione o conteúdo dele. A lista de regras funciona como uma moeda "OR" lógica apenas para solicitações de cargas de trabalho com uma dessas duas contas de serviço.

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

Resposta (não 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. Copie a política de autorização final para 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 alterações

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

18. Confira o status do Projeto de operações do Cloud Build em uma guia aberta ou clique no link a seguir:

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

19. Depois que o build for concluído, tente executar uma finalização de compra. Ele vai funcionar.

Nesta seção, mostramos como usar as políticas de autorização do Istio para aplicar o controle de acesso granular por serviço. Na produção, você pode criar um AuthorizationPolicy por serviço e, por exemplo, usar uma política "allow-all" para permitir que todas as cargas de trabalho no mesmo namespace acessem umas às outras.

12. Escalonamento de infraestrutura

Objetivo: escalonar a infraestrutura adicionando nova região, projeto e clusters.

• Clone o repositório infrastructure
• Atualizar os arquivos do Terraform para criar novos recursos
• Duas sub-redes na nova região (uma para o projeto ops e outra para o novo projeto)
• Novo cluster de operações na nova região (na nova sub-rede)
• Novo plano de controle do Istio para a nova região
• Dois clusters de apps no novo projeto na nova região
• Confirmar para o repositório infrastructure
• Confirme a instalação

SCRIPT PARA RASTREAMENTO RÁPIDO

Se você escolher esse método, execute o script a seguir para concluir o laboratório.

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

Instruções do laboratório do método copiar e colar

Se você já tiver concluído o script de trilha rápida deste laboratório, não execute o método de copiar e colar abaixo**.**

Há várias maneiras de escalonar uma plataforma. É possível acrescentar mais computação adicionando nós aos clusters atuais. É possível adicionar mais clusters em uma região. Ou então, você pode adicionar mais regiões à plataforma. A decisão sobre qual aspecto da plataforma escalonar depende dos requisitos. Por exemplo, se você tiver clusters nas três zonas de uma região, talvez adicionar mais nós (ou pools de nós) ao cluster atual seja suficiente. No entanto, se você tiver clusters em duas das três zonas em uma única região, adicionar um novo cluster na terceira zona oferece escalonamento e um domínio de falha adicional (ou seja, uma nova zona). Outro motivo para adicionar um novo cluster em uma região pode ser a necessidade de criar um cluster de locatário único, por motivos regulatórios ou de compliance, por exemplo, PCI ou um cluster de banco de dados que abriga informações de PII. À medida que seus negócios e serviços se expandem, adicionar novas regiões torna-se inevitável para fornecer serviços mais próximos dos clientes.

A plataforma atual consiste em duas regiões e clusters em duas zonas por região. Pense em escalonar a plataforma de duas maneiras:

• Verticalmente: em cada região, adicionando mais computação. Isso é feito adicionando mais nós (ou pools de nós) aos clusters atuais ou adicionando novos clusters na região. Isso é feito pelo repositório infrastructure. O caminho mais simples é adicionar nós a clusters atuais. Não é preciso fazer nenhuma configuração adicional. A adição de novos clusters pode exigir outras sub-redes (e intervalos secundários), adicionar regras de firewall apropriadas, adicionar novos clusters ao plano de controle da malha de serviço do ASM/Istio regional e implantar recursos do aplicativo nos novos clusters.
• Horizontalmente: adicionando mais regiões A plataforma atual oferece um modelo regional. Ele consiste em um cluster de operações regional onde o controle do ASM/Istio está e em dois (ou mais) clusters de aplicativos zonais em que os recursos de aplicativo são implantados.

Neste workshop, você vai escalonar a plataforma "horizontalmente" e também abrange as etapas dos casos de uso verticais. Para escalonar a plataforma horizontalmente adicionando uma nova região (r3) a ela, os seguintes recursos precisam ser adicionados:

1. Sub-redes na VPC compartilhada do projeto host na região r3 para os novos clusters de operações e aplicativos.
2. Um cluster de operações regional na região r3 onde reside o plano de controle do ASM/Istio.
3. Dois clusters de aplicativos zonais em duas zonas na região r3.
4. Atualize para o k8s-repo:
5. Implante os recursos do plano de controle do ASM/Istio no cluster de operações na região r3.
6. Implante os recursos do plano de controle compartilhado do ASM/Istio nos clusters de apps na região r3.
7. Embora você não precise criar um novo projeto, as etapas do workshop demonstram como adicionar um novo projeto dev3 para abordar o caso de uso de adicionar uma nova equipe à plataforma.

O repositório de infraestrutura é usado para adicionar os novos recursos mencionados acima.

1. No Cloud Shell, navegue até WORKDIR e clone o repositório 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. Clone a ramificação add-proj do repositório de origem do workshop no diretório add-proj-repo.

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

 

3. Copie os arquivos da ramificação add-proj no repositório do workshop de origem. A ramificação add-proj contém as alterações desta seção.

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

4. Substitua o diretório infrastructure no diretório repo add-proj por um link simbólico para o diretório infra-repo para permitir que os scripts na ramificação sejam executados.

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

5. Execute o script add-project.sh para copiar os estados e vars compartilhados para a nova estrutura de diretórios do projeto.

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

6. Confirme e envie alterações para criar um novo projeto

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

7. A confirmação aciona o repositório infrastructure para implantar a infraestrutura com os novos recursos. Veja o progresso do Cloud Build clicando na saída do link a seguir e navegando até o build mais recente na parte superior.

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

Esta etapa leva de 25 a 30 minutos para ser concluída. É uma boa hora para fazer uma pausa para o café.

A última etapa do Cloud Build infrastructure cria novos recursos do Kubernetes no k8s-repo. Isso aciona o Cloud Build no k8s-repo (no projeto ops). Os novos recursos do Kubernetes são para os três novos clusters adicionados na etapa anterior. O plano de controle do ASM/Istio e os recursos do plano de controle compartilhado são adicionados aos novos clusters com o Cloud Build k8s-repo.

8. Depois que o Cloud Build da infraestrutura concluir, navegue até a k8s-repo execução mais recente do Cloud Build clicando no link de saída a seguir.

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

9. Execute o script a seguir para adicionar os novos clusters a vars e ao arquivo kubeconfig.

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

10. Altere a variável KUBECONFIG para apontar para o novo arquivo kubeconfig.

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

11. Liste os contextos do cluster. Serão exibidos oito clusters.

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

Verificar a instalação do Istio

12. Verifique se o Istio está instalado no novo cluster de operações verificando se todos os pods estão em execução e se os jobs foram concluídos.

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. Verifique se o Istio está instalado nos dois clusters dev3. Somente o Citadel, o sidecar-injector e o coredns são executados nos clusters dev3. Eles compartilham um plano de controle do Istio em execução no cluster 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

Verificar a descoberta de serviços para planos de controle compartilhados

14. Verifique se os secrets estão implantados em todos os clusters de operações nos seis clusters de aplicativos.

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. Quebra de circuito

Objetivo: implementar um disjuntor para o serviço de frete.

• Crie um DestinationRule para o serviço shipping implementar um disjuntor.
• Use o fortio (um utilitário de geração de carga) para validar o disjuntor para o serviço shipping forçando o desvio do circuito.

Instruções do laboratório de roteiro rápido

O Fast Track Script Lab estará disponível em breve!

Instruções do laboratório do método copiar e colar

Agora que aprendemos algumas estratégias básicas de monitoramento e solução de problemas para serviços com o Istio ativado, vamos ver como ele ajuda a melhorar a resiliência dos serviços, reduzindo a quantidade de solução de problemas que você terá que realizar.

Uma arquitetura de microsserviços apresenta o risco de falhas em cascata, em que a falha de um serviço pode se propagar para as dependências, e as dependências dessas dependências, causando um "efeito de ondulação". uma interrupção temporária que pode afetar os usuários finais. O Istio oferece uma política de tráfego do tipo Circuit Breaker para ajudar a isolar os serviços, protegendo os serviços downstream (do lado do cliente) contra a falha de serviços e protegendo os serviços upstream (do lado do servidor) contra uma enxurrada repentina de tráfego downstream quando eles voltam a ficar on-line. Em geral, o uso de disjuntores pode ajudar a evitar que todos os serviços apresentem falhas nos SLOs devido a um serviço de back-end que está travando.

O padrão de disjuntor se refere a um interruptor elétrico que pode "virar" quando há muita eletricidade passando, protegendo os dispositivos de sobrecarga. Em uma configuração do Istio, isso significa que o Envoy é o disjuntor, acompanhando o número de solicitações pendentes para um serviço. Nesse estado fechado padrão, as solicitações fluem pelo Envoy sem interrupções.

Porém, quando o número de solicitações pendentes excede o limite definido, o disjuntor é acionado (abre) e o Envoy retorna imediatamente um erro. Isso permite que o servidor falhe rapidamente para o cliente e evita que o código do aplicativo do servidor receba a solicitação do cliente quando estiver sobrecarregado.

Depois do tempo limite definido, o Envoy passa para um estado meio aberto, em que o servidor pode voltar a receber solicitações de maneira probatória e, se conseguir responder às solicitações, o disjuntor fecha de novo e as solicitações ao servidor começam a fluir de novo.

Este diagrama resume o padrão do disjuntor do Istio. Os retângulos azuis representam o Envoy, os círculos azuis representam o cliente e os círculos brancos representam o contêiner do servidor:

É possível definir políticas de disjuntor usando DestinationRules do Istio. Nesta seção, vamos aplicar a política a seguir para aplicar um disjuntor ao serviço de frete:

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

Há dois campos DestinationRule a serem observados aqui. connectionPool define o número de conexões que este serviço permitirá. O campo outlierDetection é onde configuramos como o Envoy determina o limite para abrir o disjuntor. Aqui, a cada segundo (intervalo), o Envoy contará o número de erros recebidos do contêiner do servidor. Se ele exceder o limite de consecutiveErrors, o disjuntor do Envoy será aberto e 100% dos pods do productcatalog serão protegidos contra novas solicitações do cliente por 10 segundos. Depois que o disjuntor do Envoy estiver aberto, ou seja, ativo, os clientes vão receber erros 503 (serviço indisponível). Vamos ver tudo funcionando.

1. Defina variáveis de ambiente para k8s-repo e asm dir para simplificar os comandos.

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

2. Atualizar o k8s-repo

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

3. Atualize a DestinationRule do serviço de frete nos dois clusters de operações.

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. Copie um pod do gerador de carga do Fortio para o cluster GKE_1 na região Dev1. Este é o pod de cliente que vamos usar para "trip" o disjuntor do serviço de envio.

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. Confirme as alterações.

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

6. Aguarde a conclusão do Cloud Build.
7. De volta ao Cloud Shell, use o pod do Fortio para enviar tráfego gRPC parashippingservice com uma conexão simultânea, com 1.000 solicitações no total. Isso não vai acionar o disjuntor, porque ainda não excedemos as configurações 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 
 

Resposta (não copie)

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

8. Agora, execute o Fortio novamente, aumentando o número de conexões simultâneas para 2, mas mantendo o número total de solicitações constante. Veremos que até dois terços das solicitações retornarão um "overflow" porque o disjuntor foi acionado: na política que definimos, apenas uma conexão simultânea é permitida em um intervalo de um 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 
 

Resposta (não 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. O Envoy acompanha o número de conexões descartadas quando o disjuntor está ativo, com a métrica upstream_rq_pending_overflow. Vamos encontrar isso no pod do 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
 

Resposta (não 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. Faça a limpeza removendo a política do disjuntor de ambas as regiões.

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
 

Esta seção demonstrou como configurar uma única política de disjuntor para um serviço. Uma prática recomendada é configurar um disjuntor para qualquer serviço upstream (back-end) que possa travar. Ao aplicar as políticas de disjuntor do Istio, você isola os microsserviços, cria tolerância a falhas na arquitetura e reduz o risco de falhas em cascata sob alta carga.

14. Injeção de falha

Objetivo: testar a resiliência do serviço de recomendação introduzindo atrasos (antes de ser enviado para produção).

• Crie um VirtualService para o serviço recommendation introduzir um atraso de 5 segundos.
• Testar o atraso usando o gerador de carga fortio
• Remova o atraso no VirtualService e faça a validação

Instruções do laboratório de roteiro rápido

O Fast Track Script Lab estará disponível em breve!

Instruções do laboratório do método copiar e colar

Adicionar políticas de disjuntor aos seus serviços é uma forma de criar resiliência contra os serviços na produção. Mas o disjuntor resulta em falhas, possivelmente erros próprios do usuário, o que não é o ideal. Para se antecipar a esses casos de erro e prever melhor como os serviços downstream podem responder quando os back-ends retornam erros, é possível adotar o teste de caos em um ambiente de teste. O teste de caos é a prática de interromper deliberadamente seus serviços para analisar os pontos fracos do sistema e melhorar a tolerância a falhas. Também é possível usar o teste de caos para identificar maneiras de reduzir os erros do usuário quando os back-ends falham, por exemplo, exibindo um resultado armazenado em cache em um front-end.

Usar o Istio para injeção de falhas é útil porque você pode usar suas imagens de versão de produção e adicionar a falha na camada de rede, em vez de modificar o código-fonte. Na produção, é possível usar uma ferramenta de teste de caos completa para testar a resiliência na camada do Kubernetes/de computação, além da camada de rede.

Você pode usar o Istio para testes de caos aplicando um VirtualService com o atributo "falha" . O Istio oferece suporte a dois tipos de falhas: falhas de atraso (injetar um tempo limite) e falhas de cancelamento (injeção de erros HTTP). Neste exemplo, injetaremos uma falha de atraso de cinco segundos no serviço de recomendações. Mas, desta vez, em vez de usar um disjuntor para "falhar rápido", contra esse serviço suspenso, forçaremos os serviços downstream a suportar todo o tempo limite.

11. Acesse o diretório de injeção de falhas.

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

12. Abra k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml para inspecionar o conteúdo. O Istio tem a opção de injetar a falha em uma porcentagem das solicitações. Aqui, vamos introduzir um tempo limite em todas as solicitações de recommendationservice.

Resposta (não 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. Copie o VirtualService para k8s_repo. A falha será injetada globalmente, nas duas regiões.

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 alterações

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

15. Aguarde a conclusão do Cloud Build.
16. Execer no pod do Fortio implantado na seção do disjuntor e enviar tráfego para o 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:

Resposta (não 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. Outra forma de ver a falha injetada em ação é abrir o front-end em um navegador da Web e clicar em qualquer produto. Uma página de produto deve levar 5 segundos a mais para carregar, pois ela busca as recomendações exibidas na parte de baixo da página.
18. Para fazer a limpeza, remova o serviço de injeção de falhas dos dois clusters de operações.

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. Enviar alterações:

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

15. Como monitorar o plano de controle do Istio

O ASM instala quatro componentes importantes do plano de controle: Pilot, Mixer, Galley e Citadel. Cada um envia as métricas de monitoramento relevantes para o Prometheus, e o ASM envia os painéis do Grafana para que os operadores visualizem esses dados de monitoramento e avaliem a integridade e o desempenho do plano de controle.

Como visualizar os painéis

20. Faça o encaminhamento por portas do serviço Grafana instalado com o Istio

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

21. Abrir o Grafana no navegador
22. Clique em "Visualização na Web" no canto superior direito da janela do Cloud Shell
23. Clique em Visualizar na porta 3000 (Observação: se a porta não for 3000, clique em "Alterar porta" e selecione a porta 3000)
24. Isso abrirá uma guia em seu navegador com um URL semelhante a " BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. Ver painéis disponíveis
26. Modifique o URL para " BASE_URL/dashboard"
27. Clique em "istio". para visualizar os painéis disponíveis
28. Clique em qualquer um dos painéis para conferir o desempenho do componente em questão. Vamos analisar as métricas importantes de cada componente nas próximas seções.

Piloto de monitoramento

O Pilot é o componente do plano de controle que distribui a configuração de política e rede para o plano de dados (os proxies Envoy). O piloto tende a escalonar de acordo com o número de cargas de trabalho e implantações, mas não necessariamente com a quantidade de tráfego para essas cargas de trabalho. Um Piloto com problemas de integridade pode:

• consumir mais recursos do que o necessário (CPU e/ou RAM)
• resultarão em atrasos no envio das informações de configuração atualizadas para o Envoys

Observação: se o Piloto estiver inativo ou houver atrasos, suas cargas de trabalho ainda exibirão tráfego.

23. Navegar até " BASE_URL/dashboard/db/istio-pilot-dashboard" no seu navegador para visualizar as métricas do piloto.

Métricas monitoradas importantes

Uso de recursos

Use a página "Desempenho e escalonabilidade do Istio" como guia para ver os números de uso aceitáveis. Entre em contato com o suporte do GCP se você observar um uso muito maior de recursos sustentado do que isso.

Informações de push do piloto

Esta seção monitora os push de configuração do Pilot para proxies Envoy.

• Envios do piloto mostra o tipo de configuração enviada a qualquer momento.
• O Monitoramento de anúncios mostra o número de serviços virtuais, serviços e endpoints conectados no sistema.
• Clusters sem endpoints conhecidos mostra os endpoints que foram configurados, mas não têm instâncias em execução. Isso pode indicar serviços externos, como *.googleapis.com.
• Erros do piloto mostram o número de erros encontrados ao longo do tempo.
• Conflitos mostram o número de conflitos que são uma configuração ambígua nos listeners.

Se houver erros ou conflitos, significa que você tem uma configuração inválida ou inconsistente para um ou mais de seus serviços. Para mais informações, consulte Como solucionar problemas no plano de dados.

Informações do Envoy

Esta seção contém informações sobre os proxies Envoy que entram em contato com o plano de controle. Entre em contato com o suporte do GCP se você vir falhas de conexão XDS repetidas.

Mixer de monitoramento

O Mixer é o componente que afunila a telemetria dos proxies Envoy para back-ends de telemetria (geralmente o Prometheus, o Stackdriver etc.). Nessa capacidade, ele não está no plano de dados. Ele é implantado como dois jobs do Kubernetes (chamados Mixer) com dois nomes de serviço diferentes (istio-telemetry e istio-policy).

O Mixer também pode ser usado na integração com sistemas de políticas. Com relação a isso, o Mixer afeta o plano de dados, já que as verificações de política nele que falham bloqueiam o acesso aos serviços.

O Mixer costuma ser escalonado de acordo com o volume de tráfego.

24. Navegar até " BASE_URL/dashboard/db/istio-mixer-dashboard" no navegador para acessar as métricas do Mixer.

Métricas monitoradas importantes

Uso de recursos

Use a página "Desempenho e escalonabilidade do Istio" como guia para ver os números de uso aceitáveis. Entre em contato com o suporte do GCP se você observar um uso muito maior de recursos sustentado do que isso.

Visão geral do Mixer

• Duração da resposta é uma métrica importante. Embora os relatórios para a telemetria do Mixer não estejam no caminho de dados, se essas latências forem altas, o desempenho do proxy sidecar será reduzido. O 90o percentil está na ordem de milissegundos de um dígito e o 99o percentil fica abaixo de 100 ms.

• Duração do envio do adaptador indica a latência que o Mixer está enfrentando ao chamar adaptadores (por meio dos quais envia informações para sistemas de telemetria e de registros). Aqui, latências altas afetam o desempenho na malha. Novamente, as latências p90 precisam ser inferiores a 10 ms.

Galeria de monitoramento

Galeria é o componente de validação de configuração, ingestão, processamento e distribuição do Istio. Ele transmite a configuração do servidor da API Kubernetes para o Pilot. Assim como o Pilot, ele tende a ser escalonado de acordo com o número de serviços e endpoints no sistema.

25. Navegar até " BASE_URL/dashboard/db/istio-galley-dashboard" no navegador para conferir as métricas do Galley.

Métricas monitoradas importantes

Validação de recursos

A métrica mais importante a seguir, que indica o número de recursos de vários tipos, como regras de destino, gateways e entradas de serviço que estão sendo aprovados ou reprovados na validação.

Clientes conectados

Indica quantos clientes estão conectados ao Galley. Em geral, serão três (pilot, istio-telemetry, istio-policy) e serão escalonados à medida que esses componentes forem escalonados.

16. Solução de problemas do Istio

Como solucionar problemas no plano de dados

Se o painel do Piloto indicar que há problemas de configuração, examine os registros do PIlot ou use o istioctl para localizar problemas de configuração.

Para examinar os registros do Pilot, execute a descoberta istio-pilot-69db46c598-45m44 dos logs do Pilot, substituindo istio-pilot-... pelo identificador do pod da instância do Pilot que você quer solucionar.

No registro resultante, procure uma mensagem de Status do push. Exemplo:

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="
}

O status do push indica os problemas que ocorreram ao tentar enviar a configuração para proxies Envoy. Nesse caso, há várias mensagens "Duplicate cluster" que indicam destinos upstream duplicados.

Para receber ajuda com o diagnóstico de problemas, entre em contato com o suporte do Google Cloud.

Como encontrar erros de configuração

Se quiser usar istioctl para analisar sua configuração, execute istioctl experimental analyze -k --context $OPS_GKE_1. Isso vai realizar uma análise da configuração do sistema, indicar se há problemas e as mudanças sugeridas. Consulte a documentação para ver uma lista completa dos erros de configuração que esse comando pode detectar.

17. Limpeza

As etapas a seguir são executadas por um administrador após a conclusão do workshop.

Um administrador executa o script cleanup_workshop.sh para excluir recursos criados pelo script bootstrap_workshop.sh. Você precisa das seguintes informações para que o script de limpeza seja executado.

• Nome da organização, por exemplo, yourcompany.com
• ID do workshop: no formato YYMMDD-NN. Por exemplo: 200131-01
• Bucket do GCS de administrador: definido no script de inicialização.

13. Abra o Cloud Shell e execute todas as ações abaixo nele. Clique no link abaixo.

CLOUD SHELL

14. Verifique se você fez login na gcloud com o usuário administrador pretendido.

gcloud config list
 

15. Navegue até a pasta "asm".

cd ${WORKDIR}/asm
 

16. Defina o nome da sua organização e o ID do workshop a serem excluídos.

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

17. Execute o script de limpeza conforme mostrado a seguir.

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