Como instalar o Anthos Service Mesh

Aviso: os comandos install_asm e istioctl install estão obsoletos com o lançamento do Anthos Service Mesh 1.11 e não terão suporte na versão 1.12. Atualize seus scripts e ferramentas para usar asmcli. Para mais informações, consulte Transição para asmcli.

Nesta página, explicamos como executar o script para instalar a versão 1.11.8 do Anthos Service Mesh em um cluster do GKE para uma malha que contém um ou mais clusters que estão no mesmo projeto do Google Cloud.

Para instalações em que os clusters estão em projetos diferentes, consulte o guia sobre como usar vários projetos do GKE.

Este guia é para instalar o Anthos Service Mesh ou reinstalar a mesma versão com uma configuração diferente. Saiba que a reinstalação com diferentes configurações, upgrades e migração do Istio exige planejamento adicional. Veja mais informações em:

• Como fazer upgrade do Anthos Service Mesh
• Como migrar do Istio
• Reinstalar a mesma versão

Antes de começar

Antes de iniciar a instalação, certifique-se de que você:

• revisou os requisitos;
• escolheu uma autoridade de certificação (CA);
• registrou o cluster;
• instalou as ferramentas necessárias;
• fez o download do script.

O script requer que você tenha as permissões necessárias ou que você inclua as sinalizações --enable_all ou --enable_gcp_iam_roles para permitir que o script ative a permissão para você. Da mesma forma, para permitir que o script ative as APIs necessárias e atualize o cluster, especifique a sinalização --enable_all ou as sinalizações de ativação mais granulares.

Como instalar o Anthos Service Mesh

1. Defina as opções e especifique as sinalizações para executar o script. Você sempre incluirá as seguintes opções: --project_id, --cluster_name, --cluster_location e --mode install. Se você quiser usar a CA do Istio (anteriormente conhecida como Citadel) como autoridade de certificação, especifique a opção --ca e algumas outras opções, conforme descrito em Instalação com CA do Istio Para uma descrição completa dos argumentos do script, consulte Opção e sinalizações.

2. Para concluir a configuração do Anthos Service Mesh, ative a injeção automática do arquivo secundário e implante ou reimplante cargas de trabalho.

Veja na seção a seguir exemplos típicos para executar o script. Consulte a barra de navegação à direita para ver uma lista dos exemplos.

Examples

Nesta seção, você verá exemplos de como executar o script para uma nova instalação com alguns argumentos adicionais que podem ser úteis. Consulte a barra de navegação à direita para ver uma lista dos exemplos.

Somente validar

Veja no exemplo a seguir a execução do script com a opção --only_validate. Com essa opção, o script não faz alterações no projeto nem no cluster, assim como não instala o Anthos Service Mesh. Quando você especifica --only_validate, o script falha se você inclui qualquer uma das sinalizações --enable_*.

O script confirma que:

• Seu ambiente tem as ferramentas necessárias.
• Você tem a permissão necessária no projeto especificado.
• O cluster atende aos requisitos mínimos.
• O projeto tem todas as APIs do Google necessárias ativadas.

Por padrão, o script faz o download e extrai o arquivo de instalação e faz o download do pacote de configuração asm (em inglês) do GitHub para um diretório temporário. Antes de sair, o script gera uma mensagem que fornece o nome do diretório temporário. É possível especificar um diretório para os downloads com a opção --output_dir DIR_PATH. A opção --output_dir facilita o uso da ferramenta de linha de comando istioctl, se for necessário usá-la. Além disso, os arquivos de configuração para ativar recursos opcionais estão incluídos no diretório asm/istio/options.

Execute o seguinte comando para validar a configuração e fazer o download do arquivo de instalação e do pacote asm para o diretório OUTPUT_DIR:

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

Em caso de sucesso, o script gera o seguinte:

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

Se um dos testes falhar na validação, o script exibirá uma mensagem de erro. Por exemplo, se seu projeto não tiver todas as APIs do Google necessárias ativadas, você verá o seguinte erro:

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

Se você recebeu uma mensagem de erro sobre a necessidade de executar o script com uma sinalização de ativação, terá as seguintes opções:

• Inclua a sinalização específica da mensagem de erro ou a sinalização --enable_all ao executar o script para realizar a instalação real (ou seja, sem --only_validate).

• Se preferir, atualize o projeto e o cluster antes de executar o script, conforme descrito em Como instalar o Anthos Service Mesh no GKE.

Observe que install_asm não permite nenhuma sinalização de ativação com --only_validate.

Instalação com recursos padrão

O comando a seguir executa o script para uma nova instalação com recursos padrão.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir DIR_PATH \
  --enable_registration \
  --enable_all

• --ca mesh_ca Embora a CA da malha seja a CA padrão para novas instalações, --ca mesh_ca está incluído na linha de comando para maior clareza. Se você não especificar --ca, o install_asm ativará a CA da malha.

• --output_dir DIR_PATH Inclua esta opção para especificar um diretório em que o script faz o download do pacote asm e do arquivo de instalação do Anthos Service Mesh, que contém istioctl, amostras e manifestos. Caso contrário, o script fará o download do pacote asm e do arquivo de instalação em um diretório temporário.

• --enable_registration Essa sinalização permite que o script registre o cluster no projeto em que ele está. Se você não incluir essa sinalização, siga as etapas em Como registrar um cluster para registrá-lo manualmente.

• --enable_all: permite que o script ative as APIs do Google necessárias, defina as permissões do Identity and Access Management e faça as atualizações necessárias no cluster, que incluem a ativação da Identidade da carga de trabalho do GKE. Se você preferir não permitir que install_asm cuide desses requisitos de projeto e cluster, consulte Configuração para instalar o Anthos Service Mesh no GKE.

Observação: se você não tiver a identidade da carga de trabalho do GKE ativada, a instalação falhará e será exibida. um "Erro de assinatura do cluster". Se a instalação falhar por esse motivo, registre o cluster na linha de comando com o seguinte comando: gcloud container hub memberships register --enable-workload-identity

Instalação com a CA do Istio

Esta seção explica como:

• Gerar certificados e chaves que o Anthos Service Mesh usa para assinar suas cargas de trabalho.
• Execute o script de uma instalação e ative a CA do Istio como autoridade de certificação.

Recomendamos que você use a CA do Istio somente quando precisar de uma CA personalizada.

Para ter a melhor segurança, recomendamos manter uma CA raiz off-line e usar as CAs subordinadas para emitir CAs para cada cluster. Para mais informações, consulte Conectar certificados de CA. Nesta configuração, todas as cargas de trabalho na malha de serviço usam a mesma CA raiz. Cada CA do Anthos Service Mesh usa um certificado e uma chave de assinatura de CA intermediários, assinados pela CA raiz. Quando houver várias CAs em uma malha, uma hierarquia de confiança entre as CAs será estabelecida. Repita essas etapas para provisionar certificados e chaves qualquer quantia de autoridades de certificação.

Importante: estas etapas criam certificados e chaves usando um comando make que fornecemos apenas para fins ilustrativos. Para ter a melhor segurança, use um computador seguro off-line e ferramentas prontas para produção. Por exemplo, use o HashiCorp Vault (em inglês) para gerar e proteger com segurança a chave de assinatura da CA.

1. Crie um diretório para certificados e chaves:

   mkdir -p certs && \
   pushd certs

2. Gere um certificado raiz e uma chave:

   make -f ../tools/certs/Makefile.selfsigned.mk root-ca
   

   Isso gera estes arquivos:

   • root-cert.pem: o certificado raiz
   • root-key.pem: a chave raiz
   • root-ca.conf: a configuração do openssl para gerar o certificado raiz
   • root-cert.csr: o CSR do certificado raiz

3. Gere um certificado intermediário e uma chave:

   make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

   Isso gera estes arquivos em um diretório chamado cluster1:

   • ca-cert.pem: os certificados intermediários
   • ca-key.pem: a chave intermediária
   • cert-chain.pem: a cadeia de certificados que o istiod usa
   • root-cert.pem: o certificado raiz
   Observação: é possível substituir cluster1 por um nome diferente. Por exemplo, make mycluster-certs cria um diretório chamado mycluster.

   Se você executar essas etapas usando um computador off-line, copie o diretório gerado para o computador em que você está executando o script.

4. Execute o script e inclua os arquivos gerados anteriormente para os certificados e a chave.

   ./install_asm \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --mode install \
     --ca citadel \
     --ca_cert FILE_PATH \
     --ca_key FILE_PATH \
     --root_cert FILE_PATH \
     --cert_chain FILE_PATH \
     --output_dir DIR_PATH \
     --enable_registration \
     --enable_all

Instalação com um arquivo de sobreposição

Um arquivo de sobreposição é um arquivo YAML contendo um recurso personalizado (CR) IstioOperator que você passa para install_asm para configurar o plano de controle. É possível substituir a configuração do plano de controle padrão e ativar um recurso opcional transmitindo o arquivo YAML para install_asm. É possível usar mais camadas, e cada arquivo de sobreposição substitui a configuração nas camadas anteriores.

Se você especificar mais de uma CR em um arquivo YAML, install_asm divide o arquivo em vários arquivos YAML temporários, um para cada resposta automática. O script divide as respostas em arquivos separados porque istioctl install só aplica a primeira resposta automática em um arquivo YAML contendo mais de uma resposta automática.

O exemplo a seguir faz uma instalação e inclui um arquivo de sobreposição para personalizar a configuração do plano de controle. No comando a seguir, altere OVERLAY_FILE para o nome do arquivo YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir DIR_PATH \
  --enable_registration \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Instalação com uma opção

O exemplo a seguir faz um upgrade e inclui o arquivo egressgateways.yaml do pacote asm (em inglês), que ativa um gateway de saída. Não inclua a extensão .yaml. O script recupera o arquivo, então não é necessário fazer o download do pacote asm primeiro.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca mesh_ca \
  --output_dir DIR_PATH \
  --enable_registration \
  --enable_all \
  --option egressgateways

É possível usar --option para ativar um recurso opcional. Se você precisar fazer modificações em qualquer um dos arquivos no diretório asm/istio/options no pacote asm, faça o download do pacote asm, faça suas alterações e inclua o arquivo usando --custom_overlay.

Para fazer o download do pacote asm para o diretório de trabalho atual, faça modificações nos arquivos:

kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.11 asm

Se você executou o exemplo Apenas validar em que especificou a opção --output_dir, os arquivos de configuração estão no diretório de saída especificado em asm/istio/options.

Ativar a CA da malha com o pool de identidades da carga de trabalho da frota

Visualização — Mesh CA with the fleet workload identity pool

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

A visualização da CA da malha com o pool de identidades da carga de trabalho da frota é limitada a novas instalações do Anthos Service Mesh no GKE. Upgrades e migrações não são compatíveis durante a visualização.

Neste exemplo, mostramos como permitir que a CA da malha use o pool de identidade da carga de trabalho do ambiente. A CA da malha com o pool de identidades da carga de trabalho da frota permite mesclar clusters em projetos separados do Google Cloud a um único domínio de confiança.

Para ativar a CA da malha com o pool de identidades da carga de trabalho da frota:

Se você ainda não registrou o cluster, inclua a sinalização --enable_registration ou --enable_all para permitir que o script se registre o cluster no projeto em que está o cluster.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --option hub-meshca

Esse comando executa o script para uma nova instalação, configura o projeto e o cluster com as opções exigidas pelo Anthos Service Mesh, registra o cluster no projeto em que ele está e configura o Mesh CA para usar o pool de identidade de carga de trabalho da frota.

Observação: se você usar o asmcli para instalar o Anthos Service Mesh, não precisará especificar o hub-meshca. Quando você executa asmcli install, o asmcli ativa automaticamente a CA da malha para usar o pool de identidades da carga de trabalho da frota.

Como implantar e reimplantar cargas de trabalho

O Anthos Service Mesh usa proxies sidecar para aumentar a segurança, a confiabilidade e a observabilidade da rede. Com o Anthos Service Mesh, essas funções são abstraídas do contêiner principal do aplicativo e implementadas em um proxy comum fora do processo, entregue como um contêiner separado no mesmo pod.

A instalação não será concluída até que você ative a injeção automática de proxy de arquivo secundário (injeção automática) e reinicie os pods de todas as cargas de trabalho que estavam sendo executadas no cluster antes de instalar o Anthos Service Mesh.

Para ativar a injeção automática, rotule os namespaces com o rótulo de revisão que foi definido no istiod quando você instalou o Anthos Service Mesh. O rótulo de revisão é usado pelo webhook do injetor automático de arquivo secundário para associar os arquivos secundários injetados a uma revisão istiod específica. Depois de adicionar o rótulo, todos os pods existentes no namespace precisarão ser reiniciados para que os arquivos secundários sejam injetados.

Antes de implantar novas cargas de trabalho em um novo namespace, configure a injeção automática para que o Anthos Service Mesh possa monitorar e proteger o tráfego.

Para ativar a injeção automática:

1. Use o seguinte comando para localizar o rótulo de revisão em istiod:

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

   A resposta será semelhante a:

   NAME                                READY   STATUS    RESTARTS   AGE   LABELS
   istiod-asm-1118-4-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586
   istiod-asm-1118-4-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586

   Na saída, na coluna LABELS, observe o valor do rótulo de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-1118-4.

2. Aplique o rótulo de revisão e remova o rótulo istio-injection, se ele existir. No comando a seguir, NAMESPACE é o nome do namespace em que você quer ativar a injeção automática, e REVISION é o rótulo de revisão que você anotou na etapa anterior.

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

   Você pode ignorar a mensagem "istio-injection not found" na saída. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente, que é esperado em novas instalações do Anthos Service Mesh ou em novas implantações. Como a injeção automática falha se um namespace tiver o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do rótulo istio-injection.

3. Se as cargas de trabalho estavam em execução no cluster antes de instalar o Anthos Service Mesh, reinicie os pods para acionar a nova injeção.

   A maneira como você reinicia os pods depende do seu aplicativo e do ambiente em que o cluster está. Por exemplo, no seu ambiente de preparo, basta excluir todos os pods, o que faz com que eles sejam reiniciados. Mas no ambiente de produção, há um processo que implementa uma implantação azul-verde para que você possa reiniciar os pods com segurança para evitar a interrupção do tráfego.

   É possível usar kubectl para executar uma reinicialização gradual:

   kubectl rollout restart deployment -n NAMESPACE
   

Como visualizar os painéis do Anthos Service Mesh

Depois de implantar as cargas de trabalho no seu cluster com os proxies sidecar injetados, acesse as páginas do Anthos Service Mesh no console do Google Cloud para ver todos os recursos de observabilidade que o Anthos Service Mesh oferece. Observe que leva cerca de um ou dois minutos para que os dados de telemetria sejam exibidos no console do Google Cloud após a implantação das cargas de trabalho.

O acesso ao Anthos Service Mesh no console do Google Cloud é controlado pelo Gerenciamento de identidade e acesso (IAM). Para acessar as páginas do Anthos Service Mesh, um proprietário do projeto precisa conceder aos usuários o papel de Editor ou Visualizador de projeto ou os papéis mais restritivos descritos em Como controlar o acesso ao Anthos Service Mesh no console do Google Cloud.

1. No console do Google Cloud, acesse Anthos Service Mesh.

   Acesse o Anthos Service Mesh

2. Selecione o projeto do Google Cloud na lista suspensa na barra de menus.

3. Se você tiver mais de uma malha de serviço, selecione a malha na lista suspensa Service Mesh.

Para saber mais, consulte Como explorar o Anthos Service Mesh no console do Google Cloud.

Além das páginas do Anthos Service Mesh, as métricas relacionadas aos seus serviços, como o número de solicitações recebidas por um serviço específico, são enviadas para o Cloud Monitoring, onde elas aparecem o Metrics Explorer.

Para ver métricas:

1. No Console do Google Cloud, acesse a página Monitoring.

   Acessar Monitoring

2. Selecione Recursos > Metrics Explorer.

Veja uma lista completa de métricas em Métricas do Istio na documentação do Cloud Monitoring.

A seguir

• Implantar o aplicativo de amostra Online Boutique
• Como configurar uma malha de vários clusters