O Anthos Service Mesh 1.10 chegou ao fim da vida útil e não é mais compatível. Consulte Como fazer upgrade de versões anteriores.

Veja uma mais recente ou selecione outra versão disponível:

Versões disponíveis

1.20 (mais recente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Instale o Anthos Service Mesh

Nesta página, descrevemos como:

Execute asmcli para fazer uma nova instalação do Anthos Service Mesh 1.10.6-asm.2.
Implante ou reimplante suas cargas de trabalho para injetar proxies sidecar.

Antes de começar

Antes de começar, verifique se você:

Revise os pré-requisitos.
Leia as informações em Planejar a instalação.
Instalar as ferramentas necessárias
Fazer o download de asmcli
Conceder permissões de administrador de cluster
Validar o projeto e o cluster

Instale o Anthos Service Mesh

Veja a seguir como instalar o Anthos Service Mesh:

Execute asmcli install para instalar o plano de controle no cluster em um único cluster. Consulte as seções a seguir para exemplos de linha de comando. Os exemplos contêm argumentos obrigatórios e argumentos opcionais que podem ser úteis. Recomendamos que você sempre especifique o argumento output_dir para poder localizar facilmente gateways e ferramentas de amostra, como istioctl. Consulte a barra de navegação à direita para ver uma lista dos exemplos.
Como opção, instale um gateway de entrada.
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.
Se você estiver instalando o Anthos Service Mesh em mais de um cluster, execute asmcli install em cada cluster. Depois que o Anthos Service Mesh estiver instalado em todos os clusters, consulte Como configurar uma malha de vários clusters no local.
Se os clusters estiverem em redes diferentes, como no modo Ilha, transmita um nome de rede exclusivo para asmcli usando a sinalização --network_id.

Instalar recursos padrão e Mesh CA

Nesta seção, mostramos como executar o asmcli para instalar o Anthos Service Mesh com os recursos compatíveis padrão e ativar a autoridade de certificação do Anthos Service Mesh (Mesh CA) como o certificado autoridade.

GKE;

Execute o comando a seguir para instalar o novo plano de controle com recursos padrão. Digite seus valores nos marcadores fornecidos.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca

--project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
--fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
--output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
--enable_all Permite que o script:
- Conceder as permissões necessárias do IAM.
- Ative as APIs do Google necessárias.
- Defina um rótulo no cluster que identifique a malha.
- Registre o cluster na frota se ele ainda não estiver registrado.
--ca mesh_ca Use o Mesh CA como a autoridade de certificação. asmcliconfigura o Mesh CA para usar a identidade da carga de trabalho da frota

No local

Defina o contexto atual para o cluster de usuário:
```
kubectl config use-context CLUSTER_NAME
```
Execute o comando a seguir para instalar o novo plano de controle com recursos padrão. Digite seus valores nos marcadores fornecidos.
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca
```
- --fleet_id O ID do projeto host da frota.
- --kubeconfig O caminho para o arquivo kubeconfig. É possível especificar um caminho relativo ou completo. A variável de ambiente $PWD não funciona aqui.
- --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
- --platform multicloud Especifica que a plataforma é local.
- --enable_all Permite que o script:
  - Conceder as permissões necessárias do IAM.
  - Ative as APIs do Google necessárias.
  - Defina um rótulo no cluster que identifique a malha.
  - Registre o cluster na frota se ele ainda não estiver registrado.
- --ca mesh_ca Use o Mesh CA como a autoridade de certificação. asmcliconfigura o Mesh CA para usar a identidade da carga de trabalho da frota

Instalar recursos padrão com a CA do Istio

Esta seção explica como:

Gere certificados e chaves para a CA do Istio que o Anthos Service Mesh usa para assinar suas cargas de trabalho.
Execute asmcli para instalar o Anthos Service Mesh com recursos padrão e ativar a CA do Istio.

Para ter a melhor segurança, recomendamos manter uma CA raiz off-line e usar as CAs subordinadas para emitir certificados 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 autoridade de certificação 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 de qualquer quantia de autoridades de certificação.

Crie um diretório para certificados e chaves:
```
mkdir -p certs && \
pushd certs
```
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
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-cacerts cria um diretório chamado mycluster.

Se você executar essas etapas usando um computador off-line, copie o diretório gerado para um computador com acesso aos clusters.
Volte ao diretório anterior:
```
popd
```
Execute asmcli para instalar uma malha usando a CA do Istio:
GKE;
```
 ./asmcli install \
   --project_id PROJECT_ID \
   --cluster_name CLUSTER_NAME \
   --cluster_location CLUSTER_LOCATION \
   --fleet_id FLEET_PROJECT_ID \
   --output_dir DIR_PATH \
   --enable_all \
   --ca citadel \
   --ca_cert CA_CERT_FILE_PATH \
   --ca_key CA_KEY_FILE_PATH \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH
```
- --project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
- --fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
- --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
- --enable_all Permite que o script:
  - Conceder as permissões necessárias do IAM.
  - Ative as APIs do Google necessárias.
  - Defina um rótulo no cluster que identifique a malha.
  - Registre o cluster na frota se ele ainda não estiver registrado.
- -ca citadel Use a CA do Istio como autoridade de certificação.
- --ca_cert: o certificado intermediário
- --ca_key: a chave do certificado intermediário
- --root_cert: o certificado raiz
- --cert_chain: a cadeia de certificados
No local
1. Defina o contexto atual para o cluster de usuário:
  kubectl config use-context CLUSTER_NAME
2. Execute o seguinte comando para instalar o Anthos Service Mesh com recursos padrão e a CA do Istio:
  ./asmcli install \ --fleet_id FLEET_PROJECT_ID \ --kubeconfig KUBECONFIG_FILE \ --output_dir DIR_PATH \ --platform multicloud \ --enable_all \ --ca citadel \ --ca_cert CA_CERT_FILE_PATH \ --ca_key CA_KEY_FILE_PATH \ --root_cert ROOT_CERT_FILE_PATH \ --cert_chain CERT_CHAIN_FILE_PATH
  - --fleet_id O ID do projeto host da frota.
  - --kubeconfig O caminho para o arquivo kubeconfig. É possível especificar um caminho relativo ou completo. A variável de ambiente $PWD não funciona aqui.
  - --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
  - --platform multicloud Especifica que a plataforma é local.
  - --enable_all Permite que o script:
    
    Conceder as permissões necessárias do IAM.
    
    Ative as APIs do Google necessárias.
    
    Defina um rótulo no cluster que identifique a malha.
    
    Registre o cluster na frota se ele ainda não estiver registrado.
  - -ca citadel Use a CA do Istio como autoridade de certificação.
  - --ca_cert: o certificado intermediário
  - --ca_key: a chave do certificado intermediário
  - --root_cert: o certificado raiz
  - --cert_chain: a cadeia de certificados

Instalar com recursos opcionais

Um arquivo de sobreposição é um arquivo YAML contendo um recurso personalizado (CR) IstioOperator que você passa para asmcli 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 asmcli. É possível usar mais camadas, e cada arquivo de sobreposição substitui a configuração nas camadas anteriores.

GKE;

Execute o comando a seguir para instalar o novo plano de controle com recursos padrão. Digite seus valores nos marcadores fornecidos.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE

--project_id, --cluster_name e --cluster_location especifique o ID do projeto em que o cluster está, o nome dele e a zona ou região do cluster.
--fleet_id O ID do projeto host da frota. Se você não incluir essa opção, o asmcli usará o projeto em que o cluster foi criado durante o registro do cluster.
--output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
--enable_all Permite que o script:
- Conceder as permissões necessárias do IAM.
- Ative as APIs do Google necessárias.
- Defina um rótulo no cluster que identifique a malha.
- Registre o cluster na frota se ele ainda não estiver registrado.
--ca mesh_ca Use a Mesh CA como a autoridade de certificação. Observe que asmcli configura a CA da malha para usar a identidade da carga de trabalho da frota
--custom_overlay especifica o nome do arquivo de sobreposição.

No local

Defina o contexto atual para o cluster de usuário:
```
kubectl config use-context CLUSTER_NAME
```
Execute o comando a seguir para instalar o novo plano de controle com recursos padrão. Digite seus valores nos marcadores fornecidos.
```
./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE
```
- --fleet_id O ID do projeto host da frota.
- --kubeconfig O caminho para o arquivo kubeconfig. É possível especificar um caminho relativo ou completo. A variável de ambiente $PWD não funciona aqui.
- --output_dir Inclua esta opção para especificar um diretório em que asmcli faça o download do pacote anthos-service-mesh e extraia o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
- --platform multicloud Especifica que a plataforma é local.
- --enable_all Permite que o script:
  - Conceder as permissões necessárias do IAM.
  - Ative as APIs do Google necessárias.
  - Defina um rótulo no cluster que identifique a malha.
  - Registre o cluster na frota se ele ainda não estiver registrado.
- --ca mesh_ca Use a Mesh CA como a autoridade de certificação. Observe que asmcli configura a CA da malha para usar a identidade da carga de trabalho da frota
- --custom_overlay especifica o nome do arquivo de sobreposição.

Instalar gateways

O Anthos Service Mesh oferece a opção de implantar e gerenciar gateways como parte da malha de serviço. Um gateway descreve um balanceador de carga operando na borda da malha que recebe conexões HTTP/TCP de entrada ou saída. Os gateways são proxies Envoy que fornecem um controle refinado sobre o tráfego que entra e sai da malha.

Crie um namespace para o gateway de entrada, se você ainda não tiver um. Os gateways são cargas de trabalho de usuários. Como prática recomendada, não implante-os no namespace do plano de controle. Substitua GATEWAY_NAMESPACE pelo nome do namespace.
```
kubectl create namespace GATEWAY_NAMESPACE
```
Ative a injeção automática no gateway aplicando um rótulo de revisão no namespace do gateway. O rótulo de revisão é usado pelo webhook do injetor do arquivo secundário para associar os proxies injetados a uma revisão específica do plano de controle. O rótulo de revisão usado depende se você implantou o Anthos Service Mesh gerenciado ou o plano de controle no cluster.
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-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
```
  Na saída, na coluna LABELS, anote o valor do rótulo de revisão istiod, que segue o prefixo istio.io/rev=. Neste exemplo, o valor é asm-1106-2.
2. Aplique o rótulo de revisão ao namespace. No comando a seguir, REVISION é o valor do rótulo de revisão istiod que você anotou na etapa anterior.
```
kubectl label namespace GATEWAY_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
Altere para o diretório especificado em --output_dir.
É possível implantar a configuração de exemplo do gateway de entrada localizado no diretório samples/gateways/istio-ingressgateway/ como está ou modificá-lo conforme necessário.
```
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
```

Saiba mais sobre as práticas recomendadas para gateways.

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:

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-1106-2-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1106-2,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1106-2-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1106-2,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-1106-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.
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
```
Verifique se os pods estão configurados para apontar para a nova versão de istiod.
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
```

A seguir

GKE: configurar várias malhas
No local:
- Configurar um endereço IP externo
- Configurar uma malha de vários clusters