Como instalar o Anthos Service Mesh no GKE

Neste guia, explicaremos como instalar, migrar ou fazer upgrade para a versão 1.7.8 do Anthos Service Mesh para uma malha contendo um ou mais clusters do GKE que estão no mesmo projeto. Você usa um script fornecido pelo Google, que configura o projeto e o cluster, em seguida instala o Anthos Service Mesh.

Use este guia e o script para os seguintes casos de uso:

  • Novas instalações do Anthos Service Mesh.

  • Como fazer upgrade do Anthos Service Mesh 1.6 ou da versão de patch 1.7. Upgrades de versões anteriores não são compatíveis.

  • Migração do Istio 1.6 ou 1.7 de código aberto para o Anthos Service Mesh. Não é possível migrar de uma versão anterior do Istio.

  • Como migrar da versão 1.6 do complemento Istio no GKE para o Anthos Service Mesh. Antes de migrar para o Anthos Service Mesh, é necessário Fazer upgrade para o Istio 1.6 com o Operator. Para ver as etapas de migração completas do complemento, consulte Como migrar para o Anthos Service Mesh (em inglês) na documentação do Istio no GKE.

Para uma malha de vários clusters em que os clusters estejam em projetos diferentes, consulte Instalação e migração de vários clusters/vários projetos do GKE.

Antes de começar

Este guia pressupõe que você já tem:

Se você estiver migrando do Istio, leia o artigo Como se preparar para migrar do Istio.

Diferenças entre o Anthos e o Anthos Service Mesh

  • Os assinantes do GKE Enterprise precisam ativar a API GKE Enterprise.

    Ativar a API

  • Mesmo que você não seja um assinante do GKE Enterprise, ainda é possível instalar o Anthos Service Mesh, mas alguns elementos e recursos da IU no console do Google Cloud estão disponíveis apenas para assinantes do GKE Enterprise. Para informações sobre o que está disponível para assinantes e não assinantes, consulte Diferenças na interface do GKE Enterprise e Anthos Service Mesh. Para informações sobre os preços do Anthos Service Mesh para não assinantes, consulte Preços.

O script ativa todas as outras APIs do Google necessárias para você.

Requisitos

  • Seu cluster do GKE precisa atender aos seguintes requisitos:

    • Um tipo de máquina que tem pelo menos quatro vCPUs, como e2-standard-4. Se o tipo de máquina do cluster não tiver pelo menos quatro vCPUs, altere o tipo de máquina conforme descrito em Como migrar cargas de trabalho para diferentes tipos de máquina.

    • O número mínimo de nós depende do seu tipo de máquina. O Anthos Service Mesh requer pelo menos oito vCPUs. Se o tipo de máquina tiver quatro vCPUs, o cluster precisará ter pelo menos dois nós. Se o tipo de máquina tiver oito vCPUs, o cluster precisará apenas de um nó. Se for preciso adicionar nós, veja Como redimensionar um cluster.

    • O script permite a Identidade da carga de trabalho no cluster. A identidade da carga de trabalho é o método recomendado para chamar APIs do Google. A ativação da Identidade da carga de trabalho altera a forma como as chamadas das cargas de trabalho para as APIs do Google são protegidas, conforme descrito em Limitações da Identidade da carga de trabalho.

    • Como opção recomendada, inscreva o cluster em um canal de lançamento. Recomendamos que você se inscreva no canal de lançamento regular porque outros canais podem estar baseados em uma versão do GKE que não é compatível com o 1.7.8 do Anthos Service Mesh. Saiba mais em Ambientes compatíveis. Siga as instruções em Como registrar um cluster existente em um canal de lançamento se você tiver uma versão estática do GKE.

  • Para serem incluídos na malha de serviço, as portas precisam ser nomeadas, e o nome precisa incluir o protocolo da porta na seguinte sintaxe: name: protocol[-suffix], em que os colchetes indicam um sufixo opcional que precisa começar com um traço. Saiba mais em Como nomear portas de serviço.

  • Se você estiver instalando o Anthos Service Mesh em um cluster particular, abra a porta 15017 no firewall para que o webhook usado com a injeção automática de sidecar funcione corretamente. Para mais informações, consulte Como abrir uma porta em um cluster particular.

  • Se você tiver criado um perímetro de serviço na sua organização, talvez seja necessário adicionar o serviço Mesh CA ao perímetro. Saiba mais em Como adicionar o Mesh CA a um perímetro de serviço.

  • Para migrações, istiod precisa ser instalado no namespace istio-system, o que normalmente acontece.

Restrições

Um projeto do Google Cloud só pode ter uma malha associada a ele.

Como escolher uma autoridade de certificação

Para novas instalações e migrações, é possível usar a autoridade de certificação do Anthos Service Mesh (Mesh CA) ou o Citadel (agora incorporado em istiod) como a autoridade de certificação (CA) para emitir certificados TLS mútuos (mTLS) (em inglês).

Recomendamos que você use a Mesh CA pelos seguintes motivos:

  • A Mesh CA é um serviço altamente confiável e escalonável, otimizado para cargas de trabalho escalonadas dinamicamente no Google Cloud.
  • Com ela, o Google gerencia a segurança e a disponibilidade do back-end da CA.
  • Esta autoridade de certificação possibilita confiar em uma única raiz de confiança entre os clusters.
Por padrão, o script ativa a CA da malha para novas instalações do Anthos Service Mesh.

No entanto, há casos em que é recomendável usar o Citadel, como os seguintes:

  • Se você tiver uma CA personalizada.

  • Se você estiver migrando do Istio.

    Caso você escolha o Citadel, não haverá inatividade porque o tráfego mTLS não será interrompido durante a migração. Se você escolher Mes CA, será necessário agendar o tempo de inatividade para a migração, porque a raiz da confiança é alterada de Citadel para Mesh CA. Para concluir a migração para a raiz de confiança da Mesh CA, é necessário reiniciar todos os pods em todos os namespaces. Durante esse processo, os pods antigos não podem estabelecer conexões mTLS com os novos pods.

Os certificados do Mesh CA incluem os seguintes dados sobre os serviços do aplicativo:

  • O ID do projeto do Google Cloud
  • O namespace do GKE
  • O nome da conta de serviço do GKE

Como se preparar para uma migração ou atualização

Se você estiver migrando do Istio, leia o artigo Como se preparar para migrar do Istio.

Se você personalizou a instalação anterior, precisará das mesmas personalizações ao migrar ou fazer upgrade para o Anthos Service Mesh. Se você tiver personalizado a instalação adicionando a sinalização --set values, recomendamos que adicione essas configurações a um arquivo de configuração IstioOperator. Especifique o arquivo de configuração usando --custom_overlay com o arquivo de configuração ao executar o script.

Como instalar as ferramentas necessárias

É possível executar o script no Cloud Shell ou na máquina local executando o Linux.

Para executar o script localmente:

  1. Verifique se você tem as seguintes ferramentas instaladas:

  2. Faça a autenticação com a gcloud CLI:

    gcloud auth login

  3. Atualize os componentes:

    gcloud components update

  4. Verifique se git está no seu caminho para que kpt possa encontrá-lo.

  5. Faça o download da versão kpt necessária.

Como executar o script

Nesta seção, descreveremos como fazer o download do script, definir os parâmetros obrigatórios e opcionais e como executar o script. Para uma explicação detalhada sobre o que o script faz, consulte Noções básicas sobre o script.

  1. Faça o download da versão do script que instala o Anthos Service Mesh 1.7.8 no diretório de trabalho atual:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7 > install_asm

    Embora você faça o download do script a partir de um local seguro do Cloud Source Repositories, ele também está disponível no GitHub no repositório anthos-service-mesh-packages. Assim, você pode ver o que ele faz antes de fazer o download. A versão do script install_asm na ramificação release-1.7-asm instala o Anthos Service Mesh 1.7.8.

  2. Faça o download do SHA-256 do arquivo para o diretório de trabalho atual:

    curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7.sha256 > install_asm.sha256

  3. Com os dois arquivos no mesmo diretório, verifique o download:

    sha256sum -c --ignore-missing install_asm.sha256

    Quando a verificação acabar, o comando gerará: install_asm: OK

    Para compatibilidade, o arquivo install_asm.sha256 inclui a soma de verificação duas vezes para permitir que qualquer versão do script seja renomeada como install_asm. Se você receber um erro informando que --ignore-missing não existe, execute novamente o comando anterior sem a sinalização --ignore-missing.

  4. Torne o script executável:

    chmod +x install_asm

  5. 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. Dependendo da mode, pode ser necessário incluir a opção ca.

    • As opções project_id, cluster_name e cluster_location identificam o cluster no qual instalar o Anthos Service Mesh.
    • O mode é install, migrate ou upgrade.
    • O ca especifica a autoridade de certificação para mesh_ca ou citadel.

    Veja na seção a seguir exemplos típicos para executar o script. Para uma descrição completa dos argumentos do script, consulte Opção e sinalizações.

  6. Para concluir a configuração do Anthos Service Mesh, você precisa ativar a injeção automática de arquivo secundário e implantar ou reimplantar cargas de trabalho.

Examples

Esta seção mostra exemplos de como executar o script em cada mode e 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 altera o cluster nem instala o Anthos Service Mesh. 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. Você pode especificar um diretório existente 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 necessário. 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
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

Instalação

O comando a seguir executa o script para uma nova instalação, ativa o Mesh CA (a CA padrão para novas instalações, portanto, a opção ca não é necessária) e permite que o script ativar as APIs do Google necessárias.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis

Instalação com Citadel como CA

Esta seção explica como:

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

Recomendamos que você use o Citadel como a CA 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.

  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

    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 \
  --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 \
  --enable_apis \
  --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 \
  --enable_apis \
  --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.7-asm 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.

Migração do Istio

Se você estiver migrando do Istio com o Citadel como CA, será possível continuar usando o Citadel após migrar para o Anthos Service Mesh. O comando a seguir executa o script para uma migração e ativa o Citadel como a CA. Essa migração só implanta o plano de controle. Ela não muda a CA raiz e não interrompe as cargas de trabalho atuais.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

Como migrar 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 migraçã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 migrate \
  --ca citadel \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Upgrade

O comando a seguir executa o script para fazer upgrade. O script não permite que você mude para outra CA. Portanto, não é necessário incluir a opção ca.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m upgrade \
  --enable_apis

Como fazer upgrade 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 um upgrade 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 upgrade \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Opções e sinalizadores

Esta seção descreve os argumentos disponíveis para o script.

Opções

-p|--project_id CLUSTER_PROJECT_ID
O ID do projeto em que o cluster foi criado.
-n|--cluster_name CLUSTER_NAME
O nome do cluster.
-l|--cluster_location CLUSTER_LOCATION
A zona (para clusters de zona única) ou a região (para clusters regionais) em que o cluster foi criado.
-m|--mode {install|migrate|upgrade}
Digite install se você estiver fazendo uma instalação do Anthos Service Mesh. Digite migrate se você estiver migrando do Istio. Insira upgrade para atualizar uma instalação atual do Anthos Service Mesh para uma nova versão.
-c|--ca {mesh_ca|citadel}
Para instalações, se você quiser usar o Mesh CA, não é necessário incluir essa opção porque o padrão do script é o Mesh CA. Para upgrades, não é necessário incluir essa opção porque o script não permite alterar a CA. Para migrações, especifique citadel ou mesh_ca. Se você puder programar o tempo de inatividade da migração, recomendamos que use mesh_ca. Para mais informações sobre qual CA usar, consulte Como escolher uma autoridade de certificação. Para conhecer outras opções que você precisa especificar ao usar o Citadel, consulte Opções para um certificado personalizado para o Citadel.
--co|--custom_overlay YAML_FILE
O nome do arquivo YAML de recurso personalizado (CR) IstioOperator para ativar um recurso que não é ativado por padrão. O script precisa localizar o arquivo YAML. Portanto, ele precisa estar no mesmo diretório que o script ou você pode especificar um caminho relativo. Para adicionar vários arquivos, especifique --co|--custom_overlay e o nome do arquivo, por exemplo: --co overlay_file1.yaml --co overlay_file2.yaml --co overlay_file3.yaml
-o|--option OPTION_FILE
O nome de um arquivo YAML do pacote anthos-service-mesh que contém a resposta automática IstioOperator para ativar um recurso opcional. Ao incluir um desses arquivos, não é necessário fazer o download do pacote anthos-service-mesh primeiro nem especificar a extensão .yaml. Se você precisar modificar qualquer um dos arquivos, faça o download do pacote anthos-service-mesh, faça as alterações e use a opção --custom_overlay. Para adicionar vários arquivos, especifique -o|--option e o nome do arquivo, por exemplo: -o option_file1 -o option_file2 -o option_file3
-s|--service_account ACCOUNT
O nome de uma conta de serviço usada para instalar o Anthos Service Mesh. Se não for especificado, a conta de usuário ativa na configuração de gcloud atual será usada. Se você precisar alterar a conta de usuário ativa, execute gcloud auth login.
-k|--key_file FILE_PATH
O arquivo de chave de uma conta de serviço. Omita essa opção se não estiver usando uma conta de serviço.
-D|--output_dir DIR_PATH
Se não for especificado, o script criará um diretório temporário em que fará o download dos arquivos e das configurações necessárias para instalar o Anthos Service Mesh. Especifique a sinalização --output-dir para designar um diretório existente a ser usado. Após a conclusão, o diretório especificado conterá os subdiretórios asm e istio-1.7.8-asm.10. O diretório asm contém a configuração da instalação. O diretório istio-1.7.8-asm.10 tem o conteúdo extraído do arquivo de instalação, que contém istioctl, amostras e manifestos.

Sinalizações

-e|--enable_apis
Permita que o script ative as APIs do Google exigidas pelo Anthos Service Mesh. Sem essa sinalização, o script será encerrado se as APIs necessárias ainda não estiverem ativadas. Para uma lista das APIs ativadas pelo script, consulte set_up_project.
-v|--verbose
Mostra comandos antes e depois da execução.
--dry_run
Mostra comandos, mas não os executa.
--only_validate
Execute a validação, mas não instale o Anthos Service Mesh.
--print_config
Em vez de instalar o Anthos Service Mesh, imprima todo o YAML compilado para a saída padrão (stdout). Todas as outras saídas são gravadas no erro padrão (stderr), mesmo que você normalmente acesse stdout. O script ignora todas as validações e a configuração quando você especifica essa sinalização.
--disable_canonical_service
Por padrão, o script implanta o controlador de serviço canônico no cluster. Se você não quiser que o script implante o controlador, especifique --disable_canonical_service. Para mais informações, consulte Como ativar e desativar o controlador de serviço canônico.
-h|--help
Mostrar uma mensagem de ajuda com a descrição das opções, sinalizações e saídas.
--version
Imprime a versão de install_asm e sai. Se o comando não gerar uma versão, faça o download da versão mais recente de install_asm_1.7.

Opções de certificado personalizado para o Citadel

Se você especificou citadel e está usando uma CA personalizada, inclua as seguintes opções:

  • --ca_cert FILE_PATH: o certificado intermediário
  • --ca_key FILE_PATH: a chave do certificado intermediário.
  • --root_cert FILE_PATH: o certificado raiz
  • --cert_chain FILE_PATH: a cadeia de certificados

Para ver mais informações, consulte Como conectar certificados de CA existentes.

Como implantar e reimplantar cargas de trabalho

A instalação não é completa até você ativar a injeção automática de proxy de arquivo secundário (injeção automática).

  • Para novas instalações, é preciso ativar a injeção automática e reiniciar os pods de todas as cargas de trabalho em execução no cluster antes de instalar o Anthos Service Mesh.

  • As migrações e upgrades seguem o processo de upgrade do plano de controle duplo (chamado de "upgrades canário" na documentação do Istio). Com um upgrade de plano de controle duplo, o script instala uma nova versão de istiod junto com o istiod existente. Depois, transfira algumas das cargas de trabalho para a nova versão. Esse processo permite monitorar o efeito da nova versão com uma pequena porcentagem das cargas de trabalho antes de migrar todo o tráfego para a nova versão.

  • Antes de implantar novas cargas de trabalho, ative 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, você recebe o rótulo de revisão que o script aplicou a istiod e rotula seus namespaces com o rótulo de revisão. As seções a seguir dão detalhes.

Acessar o rótulo de revisão

O script adiciona um rótulo de revisão no formato istio.io/rev=asm-178-10 a istiod. Para ativar a injeção automática, você adiciona um rótulo de revisão correspondente aos namespaces. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars 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 sidecars sejam injetados.

  1. Defina o contexto atual para kubectl:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID

  2. Exiba os rótulos em istiod para receber o rótulo de revisão definido pelo script:

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

    A saída deste comando é semelhante a: Observe que a saída de novas instalações, migrações e upgrades é um pouco diferente. O exemplo de saída a seguir é de uma migração.

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-178-10-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-178-10-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7

    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-178-10, mas você pode ter um valor diferente.

    Para upgrades e migrações, anote também o valor no rótulo de revisão da versão istiod antiga. Você precisa disso para excluir a versão antiga do istiod ao concluir a migração ou o upgrade. No exemplo de saída, o valor no rótulo de revisão para a versão antiga de istiod é default, mas você pode ter um valor diferente.

Como ativar a injeção automática

Siga estas etapas para novas instalações, migrações e upgrades para ativar a injeção automática.

  1. Receba o valor no rótulo de revisão para istiod.

  2. Adicione o rótulo de revisão a um namespace e remova o rótulo istio-injection original: No comando a seguir, altere REVISION para o valor que corresponda à revisão em istiod.

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

  3. Reinicie os pods para acionar a nova injeção:

    kubectl rollout restart deployment -n NAMESPACE

  4. 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

  5. Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.

  6. Se você tiver cargas de trabalho em outros namespaces, repita as etapas para rotular o namespace e reiniciar os pods.

Para migração e upgrades:

Concluir a transição

Para migrações e upgrades, é preciso remover a versão antiga de istiod. Se o aplicativo estiver funcionando corretamente, remova o plano de controle antigo para concluir a transição para a nova versão.

  1. Receba o valor no rótulo de revisão para a versão antiga do istiod.

  2. Exclua a versão antiga de istiod. No comando a seguir, substitua OLD_REVISION pela revisão da etapa anterior.

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION  -n istio-system --ignore-not-found=true

Reverter para a versão anterior

Para migrações e upgrades, se você encontrar um problema ao testar seu aplicativo com a nova versão de istiod, siga estas etapas para reverter para a versão anterior:

  1. Altere o nome do seu namespace para ativar a injeção automática com a versão anterior do istiod. O comando usado depende de você ter usado um rótulo de revisão ou istio-injection=enabled com a versão anterior.

    • Se você usou um rótulo de revisão para a injeção automática, faça o seguinte:

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

    • Se você usou istio-injection=enabled:

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

  2. Reinicie os pods para acionar a nova injeção de modo que os proxies tenham a versão do Istio:

    kubectl rollout restart deployment -n NAMESPACE

  3. Reimplante a versão anterior do istio-ingressgateway:

    kubectl -n istio-system rollout undo deploy istio-ingressgateway

  4. Remova o novo istiod:

    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION -n istio-system --ignore-not-found=true

  5. Se você não incluiu a sinalização --disable_canonical_service, o script ativou o controlador de serviço canônico. Siga as etapas em Como ativar e desativar o controlador de serviço canônico para desativá-lo.

Reinstalar a mesma versão

O script install_asm chama istioctl install para implantar os componentes do plano de controle do Anthos Service Mesh (istiod e istio-ingressgateway) para instalações, upgrades e migrações do Istio. Como o script usa istioctl install, se você precisar personalizar o Anthos Service Mesh para ativar um recurso opcional, será necessário reinstalar o plano de controle com a nova configuração.

Uma alteração foi feita no script install_asm para que você possa reinstalar a mesma versão do Anthos Service Mesh. Quando você reinstala a mesma versão para ativar um recurso opcional, a configuração do plano de controle atual é substituída. Por isso, se você tiver personalizado a instalação atual, será necessário incluir as mesmas opções --option e/ou --custom_overlay da instalação anterior e as opções --option e/ou --custom_overlay para os novos recursos que você quer ativar.

Se você estiver ativando o Cloud Trace ou alterando uma configuração de rastreamento, também precisará reimplantar cargas de trabalho para que o arquivo secundário. os proxies são injetados com a configuração atualizada do plano de controle.

Quando você reinstalar a mesma versão, especifique --mode install assim como as instalações. Para informações sobre a instalação usando o script, consulte Como instalar o Anthos Service Mesh.

Se você especificar mais de um recurso personalizado IstioOperator (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 CRs em arquivos separados porque istioctl install só aplica a primeira resposta automática em um arquivo YAML contendo mais de uma resposta automática.

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.

    Acessar 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.

Como registrar o cluster

É necessário registrar o cluster com a frota do projeto para ter acesso à interface do usuário unificada no console do Google Cloud. Uma frota fornece uma forma unificada de visualizar e gerenciar os clusters e as cargas de trabalho deles, incluindo clusters fora do Google Cloud.

Veja informações sobre como registrar seu cluster em Como registrar clusters na frota.

Como entender o script

É possível fazer o download do script a partir de um local seguro do Cloud Source Repositories, mas o script também estará disponível no GitHub para que você possa ver o que ele faz antes de iniciar o download. O script valida que seu cluster atende aos requisitos e automatiza todas as etapas que você faria manualmente em Como instalar o Anthos Service Mesh no GKE.

Com o Anthos Service Mesh 1.7.8, você usa a versão do script install_asm na ramificação release-1.7-asm. Para uma explicação do processo de controle de versão e lançamento, consulte Controle de versões/lançamento.

validate_args e validate_dependencies

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF
validate_dependencies() {
  validate_cli_dependencies
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_k8s
  validate_expected_control_plane

  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  elif [[ "${MODE}" = "upgrade" ]]; then
    validate_asm_version
    validate_ca_consistency
  fi

  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

As funções validate_args e validate_dependencies:

  • Verifique se todas as ferramentas necessárias estão instaladas.
  • Verifique se o nome e o local do cluster, além do ID do projeto que você inseriu como valores de parâmetro são válidos.
  • Garante que o cluster atenda ao tipo de máquina e ao número de nós mínimo necessário.

set_up_project

Se você tiver incluído a sinalização --enable_apis, a função set_up_project ativará as APIs necessárias:

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
stackdriver.googleapis.com
EOF
}

set_up_cluster

set_up_cluster(){
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi
  add_cluster_labels
  enable_workload_identity

  init_meshconfig

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

A função set_up_cluster faz as seguintes atualizações no cluster:

  • Ativa a Identidade da carga de trabalho, que é a maneira recomendada de acessar com segurança os serviços do Google Cloud a partir de aplicativos do GKE

  • Ativa o Cloud Monitoring e o Cloud Logging no GKE

  • Define o rótulo mesh_id no cluster, que é necessário para que as métricas sejam exibidas nas páginas do Anthos Service Mesh no Console do Google Cloud.

  • Define um rótulo como asmv=asm-178-10 para que você saiba que o cluster foi modificado pelo script

  • Vincula o usuário da GCP ou a conta de serviço que executa o script ao papel de administrador do cluster no cluster.

install_asm

install_asm() {

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST} -f ${MULTICLUSTER_MANIFEST}"
  while read -d ',' -r yaml_file; do
    PARAMS="${PARAMS} -f ${yaml_file}"
  done <<EOF

A função install_asm:

  • faz o download do pacote kpt para um diretório temporário;
  • executam os setters kpt para configurar o arquivo istio-operator.yaml;
  • instalam o Anthos Service Mesh.

A seguir