Configurar o Anthos Service Mesh gerenciado com o asmcli

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Visão geral

O Anthos Service Mesh gerenciado com asmcli é um plano de controle gerenciado e um plano de dados gerenciado opcional que você simplesmente configura. O Google lida com a confiabilidade, os upgrades, o escalonamento e a segurança deles de maneira compatível com versões anteriores. Neste guia, explicamos como configurar ou migrar aplicativos para o Anthos Service Mesh gerenciado em uma configuração de um ou vários clusters com asmcli.

Para saber mais sobre os recursos e limitações compatíveis com o Anthos Service Mesh gerenciado, consulte Recursos compatíveis com o Anthos Service Mesh gerenciado.

Pré-requisitos

Como ponto de partida, neste guia presume-se que você:

Requisitos

  • Um ou mais clusters com uma versão compatível do GKE, em uma das regiões compatíveis.
  • Verifique se a máquina cliente da qual você instala o Anthos Service Mesh gerenciado tem conexão de rede com o servidor de API.
  • Os clusters precisam estar registrados em uma frota. Isso pode ser feito separadamente antes da instalação ou como parte da instalação, com a transmissão das sinalizações --enable-registration e --fleet-id.
  • O projeto precisa ter o recurso da frota Service Mesh ativado. Você pode ativá-lo como parte da instalação transmitindo --enable-gcp-components ou executando o seguinte comando:

    gcloud container fleet mesh enable --project=FLEET_PROJECT_ID
    

    FLEET_PROJECT_ID é o ID do projeto host da frota.

  • O GKE Autopilot é compatível apenas com o GKE versão 1.21.3 e posterior. A CNI será instalada e gerenciada pelo Google.

  • O Anthos Service Mesh gerenciado pode usar vários clusters do GKE em um ambiente de rede única de projeto único ou de vários projetos.

    • Se você mesclar clusters que não estejam no mesmo projeto, eles vão precisar ser registrados no mesmo projeto host da frota, e será preciso que os clusters estejam em um projeto de VPC compartilhada na mesma rede.
    • Além disso, recomendamos que você tenha um projeto para hospedar a VPC compartilhada e projetos separados de serviço para a criação de clusters. Para mais informações, consulte Como configurar clusters com a VPC compartilhada.
    • Se sua organização usa o VPC Service Controls, é necessário usar a sinalização --use-vpcsc extra ao aplicar o plano de controle gerenciado. Caso contrário, a instalação não vai ter os controles de segurança. A compatibilidade com o recurso VPC Service Controls está disponível nos canais "Normal" e "Rápido".

Limitações

Recomendamos que você analise a lista de recursos e limitações gerenciados do Anthos Service Mesh. Observe especificamente o seguinte:

  • Não há suporte para a API IstioOperator porque a finalidade principal dela é controlar componentes no cluster.

  • Se você já tiver implantado o plano de controle gerenciado e quiser implantar o plano de dados gerenciado, precisará executar novamente o script de instalação, conforme descrito em Aplicar o plano de controle gerenciado.

  • Nos clusters do Autopilot do GKE, a configuração entre projetos só é compatível com o GKE 1.23 e versões posteriores. Para se adaptar ao limite de recursos do Autopilot do GKE, as solicitações e limites padrão de recursos de proxy são definidos como 500m de CPU e 512 MB de memória.

  • O plano de dados gerenciado está disponível nos canais de lançamento regular e rápido.

  • Os recursos reais disponíveis no Anthos Service Mesh gerenciado dependem do canal de lançamento. Saiba mais na lista completa de recursos e limitações compatíveis com o Anthos Service Mesh.

  • Durante o processo de provisionamento de um plano de controle gerenciado, os CRDs do Istio correspondentes ao canal selecionado são instalados no cluster especificado. Se houver CRDs atuais do Istio no cluster, eles serão substituídos.

Antes de começar

Configurar a gcloud

Siga as etapas abaixo mesmo se estiver usando o Cloud Shell.

  1. Faça a autenticação com a Google Cloud CLI:

    gcloud auth login --project PROJECT_ID
    
  2. Atualize os componentes:

    gcloud components update
    
  3. Configure kubectl para apontar para o cluster.

    gcloud container clusters get-credentials CLUSTER_NAME \
         --zone CLUSTER_LOCATION \
         --project PROJECT_ID
    

Fazer o download da ferramenta de instalação

  1. Faça o download da versão mais recente da ferramenta para o diretório de trabalho atual:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli
    
  2. Torne a ferramenta executável:

    chmod +x asmcli
    

Configurar cada cluster

Siga as etapas abaixo para configurar o Managed Service Mesh para cada cluster na sua malha.

Aplicar o plano de controle gerenciado

Antes de aplicar o plano de controle gerenciado, é preciso selecionar um canal de lançamento.

Execute a ferramenta de instalação para cada cluster que usará o Anthos Service Mesh gerenciado. Recomendamos que você inclua as duas opções a seguir:

  • --enable-registration --fleet_id FLEET_PROJECT_ID Essas duas sinalizações registram o cluster em uma frota, em que FLEET_ID é o ID do projeto host da frota. Se você estiver usando um único projeto, FLEET_PROJECT_ID será o mesmo que PROJECT_ID, o projeto host da frota e o projeto de cluster serão os mesmos. Em configurações mais complexas, como vários projetos, recomendamos o uso de um projeto host de frota separado.

  • --enable-all. Essa sinalização ativa os componentes necessários e o registro.

Se a organização aplicar o VPC Service Control ao projeto, configure uma sinalização adicional: --use-vpcsc. Caso contrário, a instalação não vai ter os controles de segurança. A compatibilidade com o recurso VPC Service Controls está disponível nos canais "Normal" e "Rápido".

A ferramenta asmcli configura o plano de controle gerenciado diretamente usando ferramentas e lógica dentro da ferramenta CLI. Use o conjunto de instruções abaixo de acordo com sua CA preferencial.

Autoridades certificadoras

Selecione uma autoridade certificadora para usar na malha.

CA da malha

Execute o comando a seguir para instalar o plano de controle com recursos padrão e CA da malha. Digite seus valores nos marcadores fornecidos. Substitua RELEASE_CHANNEL pelo canal adequado: regular, stable ou rapid.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL

Serviço de CA

  1. Siga as etapas em Configurar o Certificate Authority Service.
  2. Execute o comando a seguir para instalar o plano de controle com recursos padrão e o Certificate Authority Service. Digite seus valores nos marcadores fornecidos. Substitua RELEASE_CHANNEL pelo canal adequado: regular, stable ou rapid.
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir CLUSTER_NAME \
      --enable-all \
      --channel RELEASE_CHANNEL \
      --ca gcp_cas \
      --ca_pool pool_name

A ferramenta faz o download de todos os arquivos para configurar o plano de controle gerenciado para o --output_dir especificado, instalando a ferramenta istioctl e os aplicativos de amostra. Para seguir as etapas deste guia, é necessário executar istioctl no local --output_dir especificado ao executar asmcli install, com istioctl presente no subdiretório <Istio release dir>/bin.

Se você executar novamente asmcli no mesmo cluster, ele substituirá a configuração do plano de controle existente. Especifique as mesmas opções e sinalizações, se quiser a mesma configuração.

Verificar se o plano de controle foi provisionado

A ferramenta asmcli cria um recurso personalizado ControlPlaneRevision no cluster. O status desse recurso é atualizado quando o plano de controle gerenciado é provisionado ou falha no provisionamento.

Inspecione o status do recurso. Substitua NAME pelo valor correspondente a cada canal: asm-managed, asm-managed-stable ou asm-managed-rapid.

kubectl describe controlplanerevision NAME -n istio-system

A saída é semelhante a:

    Name:         asm-managed

    …

    Status:
      Conditions:
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               The provisioning process has completed successfully
        Reason:                Provisioned
        Status:                True
        Type:                  Reconciled
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has finished
        Reason:                ProvisioningFinished
        Status:                True
        Type:                  ProvisioningFinished
        Last Transition Time:  2021-08-05T18:56:32Z
        Message:               Provisioning has not stalled
        Reason:                NotStalled
        Status:                False
        Type:                  Stalled

A condição reconciliada determina se o plano de controle gerenciado está em execução corretamente. Se true, o plano de controle está sendo executado com sucesso. Stalled determina se o processo de provisionamento do plano de controle gerenciado encontrou um erro. Se Stalled, o campo Message conterá mais informações sobre o erro específico. Consulte Códigos interrompidos para ver mais informações sobre possíveis erros.

Upgrades sem toque

Depois que o plano de controle gerenciado for instalado, o Google fará upgrade automaticamente dele quando novas versões ou patches forem disponibilizados.

Não é obrigatório fazer upgrade do plano de dados sempre que ocorrer um upgrade no plano de controle. O plano de controle continua funcionando com todos os proxies na janela de suporte, mas é recomendável ter as correções para acessar os recursos, e melhorias de desempenho mais recentes do plano de dados. Para fazer upgrade para a imagem de proxy publicada mais recentemente em seu canal, é possível realizar uma reinicialização gradual quando conveniente, ou aplicar o plano de dados gerenciado, que fará isso automaticamente.

Aplicar o plano de dados gerenciado (opcional)

Se você quiser que o Google gerencie totalmente os upgrades dos proxies, ative o plano de dados gerenciado.

Se ativados, os proxies sidecar e os gateways injetados serão atualizados automaticamente em conjunto com o plano de controle gerenciado, reiniciando as cargas de trabalho para injetar novas versões do proxy novamente. Se desativado, o gerenciamento de proxy é determinado pelo ciclo de vida natural dos pods no cluster e precisa ser acionado manualmente pelo usuário para controlar a taxa de atualização.

O plano de dados gerenciado faz o upgrade dos proxies removendo os pods que executam versões mais antigas do proxy. As remoções são feitas gradualmente, respeitando o orçamento de interrupção do pod e controlando a taxa de alteração.

Observe que o plano de dados gerenciado requer o plug-in da interface de rede de contêiner (CNI, na sigla em inglês) do Istio, que é ativado por padrão quando você implanta o plano de controle gerenciado.

O plano de dados gerenciado não gerencia o seguinte:

  • Pods não injetados
  • Pods injetados manualmente
  • Jobs
  • StatefulSets
  • DaemonSets

O plano de dados gerenciados está disponível nos canais de lançamento Rápido e Regular.

Para ativar o plano de dados gerenciado:

  1. Ative o gerenciamento de planos de dados para todo o cluster:

    kubectl annotate --overwrite controlplanerevision -n istio-system \
    REVISION_LABEL \
    mesh.cloud.google.com/proxy='{"managed":"true"}'
    

    Como alternativa, é possível ativar seletivamente o plano de dados gerenciado para uma revisão específica do plano de controle, o namespace ou o pod, anotando-o com a mesma anotação. Se você controla componentes individuais de forma seletiva, a ordem de precedência é a revisão do plano de controle, o namespace e o pod.

    O serviço pode levar até 10 minutos para gerenciar os proxies no cluster. Execute o seguinte comando para verificar o status:

    gcloud container fleet mesh describe --project FLEET_PROJECT_ID
    

    Resposta esperada

     membershipStates:
       projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
         servicemesh:
           dataPlaneManagement:
             details:
             - code: OK
               details: Service is running.
             state: ACTIVE
         state:
           code: OK
           description: 'Revision(s) ready for use: asm-managed-rapid.'
     ```
    

Se o serviço não ficar pronto em 10 minutos, consulte Status do plano de dados gerenciado para ver as próximas etapas.

Se você quiser desativar o plano de dados gerenciado e voltar a gerenciar os proxies secundários, altere a anotação:

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Para desativar o plano de dados gerenciado para um namespace, faça o seguinte:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Também é possível desativar o plano de dados gerenciado para um pod específico anotando-o com a mesma anotação.

Ativar notificações de manutenção

É possível solicitar uma notificação sobre a manutenção futura até uma semana antes da manutenção ser programada. As notificações de manutenção não são enviadas por padrão. Você também precisa configurar uma janela de manutenção do GKE antes de receber notificações.

Para ativar as notificações de manutenção, siga estas etapas:

  1. Acesse a página Comunicação.

    Acesse a página Comunicação.

  2. Na linha Anthos Service Mesh Upgrade, na coluna E-mail, selecione o botão de opção para ativar as notificações de manutenção.

Cada usuário que quer receber notificações precisa aceitar separadamente. Se você quiser definir um filtro de e-mail para essas notificações, a linha de assunto será:

Upcoming upgrade for your ASM cluster "CLUSTER_LOCATION/CLUSTER_NAME"

Configurar a descoberta de endpoint (somente para instalações de vários clusters)

Antes de prosseguir, você precisa ter configurado o Anthos Service Mesh gerenciado em cada cluster, conforme descrito nas etapas anteriores. Não há necessidade de indicar que um cluster é primário, pois esse é o comportamento padrão.

Além disso, verifique se você fez o download de asmcli (somente se quiser verificar sua configuração com o aplicativo de amostra) e defina as variáveis do projeto e do cluster.

Clusters públicos

Configurar a descoberta de endpoints entre clusters públicos

Se você estiver operando em clusters públicos (clusters não particulares), será possível Configurar a descoberta de endpoints entre clusters públicos ou simplesmente Ativar a descoberta de endpoints entre clusters públicos.

Clusters particulares

Configurar a descoberta de endpoints entre clusters particulares

Ao usar os clusters particulares do GKE, configure o endpoint do plano de controle do cluster para ser o endpoint público, e não o particular. Consulte Configurar a descoberta de endpoints entre clusters particulares.

Para um aplicativo de exemplo com dois clusters, veja Exemplo de serviço HelloWorld.

Implantar aplicativos

Para implantar aplicativos, use o rótulo correspondente ao canal que você configurou durante a instalação ou istio-injection=enabled se estiver usando rótulos de injeção padrão.

Rótulo de injeção padrão

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

Rótulo de revisão

Antes de implantar aplicativos, remova os rótulos istio-injection anteriores dos namespaces e defina o rótulo istio.io/rev=REVISION_LABEL.

Para alterá-lo para um identificador de revisão específico, clique em REVISION_LABEL e substitua-o pelo identificador aplicável: asm-managed-rapid para Rápido, asm-managed para Regular ou asm-managed-stable para Estável.

O rótulo de revisão corresponde a um canal de lançamento:

Rótulo de revisão Channel
asm-managed Normal
asm-managed-rapid Rápido
asm-managed-stable Canal Stable
kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL --overwrite

Até o momento, você configurou o plano de controle gerenciado do Anthos Service Mesh. Se você tiver cargas de trabalho em namespaces rotulados, reinicie-os para que possam ser injetados os proxies.

Agora está tudo pronto para implantar os aplicativos ou implantar o aplicativo de amostra Bookinfo.

Se você implantar um aplicativo em uma configuração de vários clusters, replique a configuração do Kubernetes e do plano de controle em todos os clusters, a menos que pretenda limitar essa configuração específica a um subconjunto de clusters. A configuração aplicada a um determinado cluster é a fonte da verdade desse cluster.

Verificar as métricas do plano de controle

É possível ver a versão do plano de controle e do plano de dados no Metrics Explorer.

Para verificar se configuração funciona corretamente:

  1. No Console do Google Cloud, veja as métricas do plano de controle:

    Acessar o Metrics Explorer

  2. Escolha o espaço de trabalho e adicione uma consulta personalizada usando os seguintes parâmetros:

    • Tipo de recurso: contêiner do Kubernetes
    • Métrica: clientes proxy
    • Filtro: container_name="cr-REVISION_LABEL"
    • Agrupar por: rótulo de revisão e rótulo do proxy_version
    • Soma do agregador
    • Período: 1 minuto

    Ao executar o Anthos Service Mesh com um plano de controle gerenciado pelo Google e outro no cluster, é possível diferenciar as métricas pelo nome do contêiner. Por exemplo, as métricas gerenciadas têm container_name="cr-asm-managed", enquanto métricas não gerenciadas têm container_name="discovery". Para exibir métricas de ambos, remova o filtro em container_name="cr-asm-managed".

  3. Verifique a versão do plano de controle e a versão do proxy inspecionando os seguintes campos no Metrics Explorer:

    • O campo revisão indica a versão do plano de controle.
    • O campo proxy_version indica o proxy_version.
    • O campo valor indica o número de proxies conectados.

    Para o canal atual para o mapeamento de versão do Mesh Service Mesh, consulte Versões do Anthos Service Mesh por canal.

Migrar aplicativos para o Anthos Service Mesh gerenciado

Preparar para a migração

Para preparar a migração de aplicativos do Anthos Service Mesh no cluster para o Anthos Service Mesh gerenciado, execute as seguintes etapas:

  1. Execute a ferramenta conforme indicado na seção Aplicar o plano de controle gerenciado pelo Google.

  2. (Opcional) Para usar o plano de dados gerenciado pelo Google, ative o gerenciamento:

      kubectl annotate --overwrite controlplanerevision REVISION_TAG \
      mesh.cloud.google.com/proxy='{"managed":"true"}'
    

Migrar aplicativos

Para migrar aplicativos do Anthos Service Mesh no cluster para o Anthos Service Mesh gerenciado, execute as seguintes etapas:

  1. Substitua o rótulo de namespace atual. As etapas necessárias dependem do uso de rótulos de injeção padrão (por exemplo, istio-injection enabled) ou do identificador de revisão

    Rótulo de injeção padrão

    1. Execute o seguinte comando para mover a tag padrão para a revisão gerenciada:

      istioctl tag set default --revision REVISION_LABEL
      
    2. Execute o seguinte comando para rotular o namespace usando istio-injection=enabled, se ele ainda não tiver sido feito:

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

    Rótulo de revisão

    Se você usou o rótulo istio.io/rev=REVISION_LABEL, execute o seguinte comando:

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION_LABEL \
        --overwrite
    
  2. Execute um upgrade contínuo das implantações no namespace:

    kubectl rollout restart deployment -n NAMESPACE
    
  3. Teste o aplicativo para verificar se as cargas de trabalho funcionam corretamente.

  4. Se você tiver cargas de trabalho em outros namespaces, repita os passos anteriores para cada namespace.

  5. Se você implantou o aplicativo em uma configuração de vários clusters, replique a configuração do Kubernetes e do Istio em todos os clusters, a menos você pretenda limitar essa configuração apenas a um subconjunto de clusters. A configuração aplicada a um determinado cluster é a fonte da verdade desse cluster.

  6. Verifique se as métricas aparecem conforme esperado seguindo as etapas em Verificar métricas do plano de controle.

Se o aplicativo funcionar como esperado, é possível remover o cluster istiod interno depois de alternar todos os namespaces para o plano de controle gerenciado pelo cliente ou mantê-los como backup. istiod reduzirá automaticamente para usar menos recursos. Para remover, pule para Excluir o plano de controle antigo.

Se você encontrar problemas, identifique e resolva-os seguindo as informações em Como resolver problemas do plano de controle gerenciado. Se necessário, reverta para a versão anterior.

Excluir o plano de controle antigo

Depois de instalar e confirmar que todos os namespaces usam o plano de controle gerenciado pelo Google, é possível excluir o plano de controle antigo.

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

Se você usou istioctl kube-inject em vez da injeção automática ou se instalou outros gateways, verifique as métricas do plano de controle e verifique se o número de endpoints conectados é zero.

Reverter

Siga estas etapas se precisar reverter para a versão anterior do plano de controle:

  1. Atualize as cargas de trabalho a serem injetadas com a versão anterior do plano de controle: No comando a seguir, o valor de revisão asm-191-1 é usado apenas como exemplo. Substitua o valor de exemplo pelo rótulo da revisão do plano de controle anterior.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite
    
  2. Reinicie os pods para acionar a reinjeção para que os proxies tenham a versão anterior:

    kubectl rollout restart deployment -n NAMESPACE
    

O plano de controle gerenciado será escalonado automaticamente para zero e não usará nenhum recurso quando não estiver em uso. Os webhooks e o provisionamento mutáveis não serão afetados e não afetarão o comportamento do cluster.

O gateway agora está definido para a revisão asm-managed. Para reverter, execute novamente o comando de instalação do Anthos Service Mesh, que implantará novamente o gateway que aponta para o plano de controle no cluster:

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

Esta é a resposta esperada em caso de êxito:

deployment.apps/istio-ingressgateway rolled back

Desinstalar

O plano de controle gerenciado reduz a escala a zero automaticamente quando nenhum namespace está usando esse recurso. Para etapas detalhadas, consulte Desinstalar o Anthos Service Mesh.

Solução de problemas

Para identificar e resolver problemas ao usar um plano de controle gerenciado, consulte Como resolver problemas do plano de controle gerenciado.

A seguir