Configurar o Anthos Service Mesh gerenciado com uma API de frota

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 é uma malha de serviço gerenciada pelo Google que você simplesmente ativa. O Google lida com a confiabilidade, os upgrades, o escalonamento e a segurança de maneira compatível com versões anteriores.

Nesta página, mostramos como usar a API de atributos Fleet para configurar o Anthos Service Mesh gerenciado.

Ao ativar o Anthos Service Mesh gerenciado usando a API Fleet:

  • O Google aplica a configuração recomendada do plano de controle
  • O Google permite o gerenciamento automático do plano de dados
  • Seu cluster é inscrito em um canal de lançamento do Anthos Service Mesh com base no canal de lançamento do seu cluster do Google Kubernetes Engine (GKE), e seu plano de controle e o plano de dados são atualizados a cada nova versão.
  • O Google habilita a descoberta de endpoints e o balanceamento de carga entre clusters em toda a malha de serviço com as configurações padrão, embora você precise criar regras de firewall.

Use este caminho de integração se quiser:

  • Usar gcloud para configurar o Anthos Service Mesh gerenciado usando as APIs do Google Cloud e o IAM.
  • Configurar o Anthos Service Mesh usando as mesmas APIs de outros recursos de frota.
  • Receber automaticamente a configuração recomendada do Anthos Service Mesh em cada um de seus clusters.

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. Ela está incluída nas instruções ou pode ser feita separadamente antes da instalação.
  • Se você estiver registrando um cluster particular com acesso ao endpoint público desativado ou limitado a redes autorizadas, verifique se a máquina em que você quer executar o registro gcloud tem acesso ao endpoint externo do cluster ou adicione o IP externo dessa máquina às redes autorizadas do cluster.
  • O projeto precisa ter o recurso da frota Service Mesh ativado. Isso está incluído nas instruções ou pode ser feito separadamente.
  • 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.

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.

  • Ativar o Anthos Service Mesh gerenciado com a API Fleet usará o Mesh CA. Se a implantação da malha de serviço exigir o Certificate Authority Service (CA Service), siga as instruções em Configurar o Anthos Service Mesh gerenciado usando asmcli.

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

  • 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

  1. Faça login na sua conta do Google Cloud. Se você começou a usar o Google Cloud agora, crie uma conta para avaliar o desempenho de nossos produtos em situações reais. Clientes novos também recebem US$ 300 em créditos para executar, testar e implantar cargas de trabalho.
  2. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  3. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como verificar se o faturamento está ativado em um projeto.

  4. No console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acessar o seletor de projetos

  5. Verifique se o faturamento está ativado para seu projeto na nuvem. Saiba como verificar se o faturamento está ativado em um projeto.

  6. Ative as APIs necessárias no seu projeto do Fleet Host:

      gcloud services enable mesh.googleapis.com \
          --project=FLEET_PROJECT_ID
    

onde:

  • FLEET_PROJECT_ID é o ID do projeto atual.

A ativação do mesh.googleapis.com ativa as seguintes APIs:

API
meshconfig.googleapis.com
meshca.googleapis.com
container.googleapis.com
monitoring.googleapis.com
gkehub.googleapis.com
stackdriver.googleapis.com
opsconfigmonitoring.googleapis.com
connectgateway.googleapis.com

Ativar o recurso de frota do Anthos Service Mesh

Ative o Anthos Service Mesh no projeto da frota. Observe que, se você planeja registrar vários clusters, a ativação do Anthos Service Mesh acontece no nível da frota. Assim, você só precisa executar esse comando uma vez.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Configurar cada cluster

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

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
    

Registrar clusters em uma frota

  1. Registre um cluster do GKE usando a Identidade da carga de trabalho em uma frota:

    gcloud container fleet memberships register MEMBERSHIP_NAME \
      --gke-uri=GKE_URI \
      --enable-workload-identity \
      --project FLEET_PROJECT_ID
    

    onde:

    • MEMBERSHIP_NAME é o nome da assinatura que você escolhe para representar de maneira exclusiva o cluster que está sendo registrado na frota.

    • GKE_URI é o URI do cluster do GKE. Por exemplo: https://container.googleapis.com/v1/projects/my-gke-project/locations/us-central1-a/clusters/my-gke-cluster. Para conseguir o URI, execute gcloud container clusters list --uri.

  2. Verifique se o cluster está registrado:

    gcloud container fleet memberships list --project FLEET_PROJECT_ID
    
  3. Se o projeto do cluster for diferente do projeto host da frota, será necessário permitir que as contas de serviço do Anthos Service Mesh no projeto da frota acessem o projeto do cluster. É necessário fazer isso apenas uma vez para cada projeto de cluster.

    Se você já usou o asmcli para configurar o Anthos Service Mesh gerenciado para essa combinação de projetos de cluster e de frota, essas alterações já foram aplicadas e não é necessário executar o comando a seguir.

    Conceda às contas de serviço no projeto da frota permissão para acessar o projeto do cluster:

    gcloud projects add-iam-policy-binding "PROJECT_ID"  \
      --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
      --role roles/anthosservicemesh.serviceAgent
    

Aplicar o rótulo mesh_id

Cluster zonal

gcloud container clusters update  --project PROJECT_ID CLUSTER_NAME \
  --zone CLUSTER_LOCATION --update-labels mesh_id=proj-FLEET_PROJECT_NUMBER

Cluster regional

gcloud container clusters update  --project PROJECT_ID CLUSTER_NAME \
  --region CLUSTER_LOCATION --update-labels mesh_id=proj-FLEET_PROJECT_NUMBER

onde:

  • PROJECT_ID é o identificador exclusivo do seu projeto do cluster.
  • CLUSTER_NAME é o nome do cluster;
  • CLUSTER_LOCATION é a zona ou região de computação do cluster.
  • FLEET_PROJECT_NUMBER é o identificador exclusivo do seu projeto do host da frota.

Ativar gerenciamento automático

Execute o comando a seguir para ativar o gerenciamento automático:

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID

Observe que um gateway de entrada não é implantado automaticamente com o plano de controle. A dissociação da implantação do gateway de entrada e do plano de controle permite gerenciar mais facilmente os gateways em um ambiente de produção. Se o cluster precisar de um gateway de entrada ou de saída, veja Implantar gateways. Para ativar outros recursos opcionais, consulte Como ativar recursos opcionais no Anthos Service Mesh gerenciado.

Verificar se o plano de controle foi provisionado

  1. Após alguns minutos, verifique se o status no plano de controle é ACTIVE:

    gcloud container fleet mesh describe --project FLEET_PROJECT_ID
    

    A saída é semelhante a:

    ...
    membershipSpecs:
      projects/746296320118/locations/global/memberships/demo-cluster-1:
        mesh:
          management: MANAGEMENT_AUTOMATIC
    membershipStates:
      projects/746296320118/locations/global/memberships/demo-cluster-1:
        servicemesh:
          controlPlaneManagement:
            details:
            - code: REVISION_READY
              details: 'Ready: asm-managed'
            state: ACTIVE
          dataPlaneManagement:
            details:
            - code: OK
              details: Service is running.
            state: ACTIVE
        state:
          code: OK
          description: 'Revision(s) ready for use: asm-managed.'
    ...
    

    Anote o rótulo de revisão no campo details. Por exemplo, asm-managed na saída fornecida. Se você estiver usando rótulos de revisão, defina-o antes de Implantar aplicativos. Se você estiver usando rótulos de injeção padrão, não será necessário definir esse rótulo.

Plano de dados gerenciado

Se você usa o Anthos Service Mesh gerenciado com a API Fleet, o Google gerencia totalmente os upgrades dos proxies, a menos que você desative esse recurso no nível do namespace ou da carga de trabalho.

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 gerenciado é ativado para a revisão do plano de controle gerenciado provisionado automaticamente. No entanto, é possível desativá-lo de maneira seletiva para um namespace ou pod específico anotando-o com a mesma anotação. Se você controla componentes individuais de maneira seletiva, a ordem de precedência é a revisão do plano de controle (ativada), o namespace e, depois, o pod.

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 Anthos Service Mesh 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

Ativar o Anthos Service Mesh gerenciado com a API Fleet ativará a descoberta de endpoints para este cluster. No entanto, é necessário abrir portas de firewall. Para desativar a descoberta de endpoints de um ou mais clusters, consulte as instruções para desativá-la em Descoberta de endpoints entre clusters públicos com a API declarativa.

Clusters particulares

Configurar a descoberta de endpoints entre clusters particulares

Ativar o Anthos Service Mesh gerenciado com a API Fleet ativará a descoberta de endpoints para este cluster. No entanto, é necessário abrir portas de firewall. Para desativar a descoberta de endpoints de um ou mais clusters, consulte as instruções para desativá-la em Descoberta de endpoints entre clusters particulares com a API declarativa.

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.

Esse é o rótulo de revisão que você identificou quando verificou o plano de controle. 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

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

Desativar o gerenciamento automático

Desativar o gerenciamento automático não desprovisiona nenhum recurso. Todos os recursos são deixados no cluster para você gerenciar ou remover manualmente.

  1. Execute o seguinte comando para desativar o gerenciamento automático:

    gcloud container fleet mesh update \
       --management manual \
       --memberships MEMBERSHIP_NAME \
       --project FLEET_PROJECT_ID
    
  2. Após alguns minutos, verifique se o status do gerenciamento de plano de controle é DISABLED:

    gcloud container fleet mesh describe --project PROJECT_ID
    

    A resposta é semelhante a:

    ...
    membershipSpecs:
      projects/projectid/locations/global/memberships/cluster-name:
        mesh:
          controlPlane: management
    membershipStates:
      projects/projectid/locations/global/memberships/cluster-name:
        servicemesh:
          controlPlaneManagement:
            state: DISABLED
        state:
          code: OK
          description: 'Revision(s) ready for use: asm-managed.'
    ...
    

Desinstalar o Anthos Service Mesh.

Para desinstalar completamente o Anthos Service Mesh, 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