Provisionar um plano de controle gerenciado do Cloud Service Mesh no GKE

Observação :este guia só oferece suporte ao Cloud Service Mesh com APIs do Istio e que não são compatíveis com as APIs do Google Cloud. Para mais informações, consulte Visão geral do Cloud Service Mesh.

O Cloud Service Mesh é uma malha de serviço gerenciada pelo Google que você simplesmente ativa. O Google cuida da confiabilidade, dos upgrades, do escalonamento e da segurança para você.

Nesta página, mostramos como usar a API fleet para configurar o Cloud Service Mesh gerenciado usando as APIs Istio.

Pré-requisitos

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

• Um projeto do Cloud
• Uma Conta de faturamento do Cloud.
• Conseguiu as permissões necessárias para provisionar o Cloud Service Mesh
• Ative a Identidade da carga de trabalho nos clusters e nos pools de nós.

Requisitos

• Um ou mais clusters com uma versão compatível do GKE, em uma das regiões compatíveis.
• Verifique se o cluster tem capacidade suficiente para os componentes necessários que instalações gerenciadas do Cloud Service Mesh no cluster.
  • A implantação mdp-controller no namespace kube-system solicita CPU: 50m, memória: 128Mi.
  • O daemonset istio-cni-node no namespace kube-system solicita cpu: 100m, memória: 100Mi em cada nó.
• Verifique se a política organizacional constraints/compute.disableInternetNetworkEndpointGroup está desativada. Se a política estiver ativada, a ServiceEntry pode não funcionar.
• Verifique se a máquina cliente da qual você provisiona o Cloud 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.
• 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 mais recentes.

• O Cloud Service Mesh 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.
  • Para um ambiente de vários clusters com um único projeto, o projeto da frota pode ser o mesmo que o do cluster. Para mais informações sobre frotas, consulte Informações gerais das frotas.
  • Para um ambiente de vários projetos, recomendamos que você hospede a frota em um projeto separado dos projetos do cluster. Se as políticas da organização e a configuração atual permitirem, recomendamos que você use o projeto da VPC compartilhada como o projeto host da frota. Para mais informações, consulte Como configurar clusters com a VPC compartilhada.

Papéis necessários para instalar o Cloud Service Mesh

A tabela a seguir descreve os papéis necessários para instalar aplicativos do Cloud Service Mesh.

Nome da função	ID do papel	Conceder local	Descrição
Administrador do GKE Hub	roles/gkehub.admin	Projeto da frota	Acesso total ao GKE Hub e recursos relacionados.
Administrador do Service Usage	roles/serviceusage.serviceUsageAdmin	Projeto da frota	Pode ativar, desativar e inspecionar estados de serviço, inspecionar operações, consumir cota e gerar faturamento para o projeto de um consumidor. ^(Observação 1)
Administrador de serviço de CA^Beta	roles/privateca.admin	Projeto da frota	Acesso completo a todos os recursos de serviço de CA. ^(Observação 2)

Limitações

Cuidado: observe as seguintes limitações específicas de frotas: - Todos os clusters em uma determinada Cloud Service Mesh precisam ser registrados na mesma frota. Os clusters não podem ser registrados em frotas diferentes. - Todos os clusters em um projeto que inclui um cluster do Cloud Service Mesh precisam registradas na mesma frota.

Recomendamos que você analise a lista de recursos e limitações compatíveis com o Cloud Service Mesh. Observe especificamente o seguinte:

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

  Observação: ainda é possível ativar recursos opcionais sem usar a API IstioOperator. Consulte Como ativar recursos opcionais no Cloud Service Mesh gerenciado. Também é possível usar a ferramenta de migração incluída no asmcli para fazer isso automaticamente converter outros recursos opcionais do IstioOperator para serem compatíveis com plano de controle gerenciado. Saiba mais em Migrar de IstioOperator.

• O uso do serviço de autoridade certificadora (CA Service) exige a configuração do Cloud Service Mesh por cluster e não é compatível com a configuração padrão da frota no GKE Enterprise.

• Nos clusters do GKE Autopilot, a configuração entre projetos é compatível apenas com o GKE 1.23 e posterior.

• Para que os clusters do GKE Autopilot se adaptem ao limite de recursos do Autopilot do GKE, as solicitações e os limites de recursos de proxy padrão são definidos como 500m de CPU e 512MB de memória. É possível modificar os valores padrão usando a injeção personalizada.

• Durante o processo de provisionamento de um plano de controle gerenciado, os CRDs do Istio são provisionados no cluster especificado. Se houver CRDs do Istio existentes no cluster, eles serão substituídos

• A CNI do Istio e o Cloud Service Mesh não são compatíveis com o GKE Sandbox. Portanto, o Cloud Service Mesh gerenciado com a implementação TRAFFIC_DIRECTOR faz não oferece suporte a clusters com o GKE Sandbox ativado.

Antes de começar

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. Configure gcloud, mesmo que você esteja usando o Cloud Shell.
1. Autentique-se com a Google Cloud CLI, em que FLEET_PROJECT_ID é o ID do projeto do host da frota. Geralmente, a FLEET_PROJECT_ID é criado por padrão e tem o mesmo nome como o projeto.

          gcloud auth login --project FLEET_PROJECT_ID
   

2. Atualize os componentes:

          gcloud components update
   

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

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

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

Observação: algumas APIs obrigatórias têm dependências transitivas de outras APIs.

API	Finalidade	Pode ser desativada?
meshconfig.googleapis.com	O Cloud Service Mesh usa a API Mesh Configuration para redirecionar os dados de configuração da malha para o Google Cloud. Além disso, ativar a API Mesh Configuration permite acessar as páginas do Cloud Service Mesh no console do Google Cloud e usar a autoridade certificadora do Cloud Service Mesh.	Não
meshca.googleapis.com	Relacionada à autoridade certificadora do Cloud Service Mesh usada pelo Cloud Service Mesh gerenciado.	Não
container.googleapis.com	Necessária para a criação de clusters do Google Kubernetes Engine (GKE).	Não
gkehub.googleapis.com	Necessária para o gerenciamento da malha como uma frota.	Não
monitoring.googleapis.com	Necessária para a captura da telemetria de cargas de trabalho da malha.	Não
stackdriver.googleapis.com	Necessária para uso da interface dos serviços.	Não
opsconfigmonitoring.googleapis.com	Necessária para uso da interface dos serviços para clusters fora do Google Cloud.	Não
connectgateway.googleapis.com	Necessária para que o plano de controle do Cloud Service Mesh gerenciado acesse cargas de trabalho da malha.	Sim*
trafficdirector.googleapis.com	Permite um plano de controle gerenciado altamente disponível e escalonável.	Sim*
networkservices.googleapis.com	Permite um plano de controle gerenciado altamente disponível e escalonável.	Sim*
networksecurity.googleapis.com	Permite um plano de controle gerenciado altamente disponível e escalonável.	Sim*

Aviso:connectgateway.googleapis.com desativar trafficdirector.googleapis.com, networkservices.googleapis.com, networksecurity.googleapis.com e/ou faz com que o plano de controle do Cloud Service Mesh gerenciado pare de funcionar. Se a frota não usar o Cloud Service Mesh gerenciado em nenhum cluster, essas APIs podem ser desativadas.

Configurar o Cloud Service Mesh gerenciado

As etapas necessárias para provisionar o Cloud Service Mesh gerenciado usando a API da frota dependem da sua preferência de ativar por padrão para novos clusters de frotas ou ativá-lo por cluster.

Configurar para sua frota

Se você ativou Google Kubernetes Engine (GKE) Enterprise, é possível ativar o Cloud Service Mesh gerenciado como uma configuração padrão para sua frota; Isso significa que cada novo cluster do GKE no Google Cloud registrado durante o cluster criação vai têm o Cloud Service Mesh gerenciado ativado no cluster. Saiba mais sobre configuração padrão da frota em Gerenciar no nível da frota .

Ativar o Cloud Service Mesh gerenciado como uma configuração padrão para a frota e registrar clusters na frota durante a criação de clusters tem suporte apenas para AC da malha. Se você quiser usar O Certificate Authority Service precisa ser ativado por cluster.

Para ativar os padrões de nível da frota para o Cloud Service Mesh gerenciado, conclua a seguintes etapas:

Console

1. No console do Google Cloud, acesse a página Gerenciador de recursos.

   Acessar o gerenciador de recursos

2. No painel Service Mesh, clique em Configurar.

3. Revise as configurações herdadas por todos os novos clusters que você criar no console do Google Cloud e se registrar na frota.

   Observação: essas configurações são pré-requisitos do GKE para usar o Cloud Service Mesh.

4. Para aplicar essas configurações, clique em Configurar.

5. Na caixa de diálogo, clique em Confirmar.

6. Opcional: sincronize os clusters atuais com as configurações padrão:

   1. Na lista Clusters na frota, selecione os clusters que você quer sincronizar. Só é possível selecionar clusters que tenham o Cloud Service Mesh instalado.
   2. Clique em Sincronizar com as configurações da frota e em Confirmar na caixa de diálogo de confirmação mostrada. Esta operação leva alguns minutos para ser concluída.

gcloud

Para configurar os padrões no nível da frota usando a CLI do Google Cloud, é necessário definir as seguintes configurações:

• Configurações no nível da frota

  • Crie um arquivo mesh.yaml que contenha apenas a única linha management: automatic:

    echo "management: automatic" > mesh.yaml
    

  • Ative o Cloud Service Mesh para sua frota:

    gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
        --fleet-default-member-config mesh.yaml
    

    Se você receber o erro abaixo, será necessário ativar o GKE Enterprise.

    ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
    [anthos.googleapis.com] service is required for this operation and is not
    enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
    Console to enable it.: failed precondition
    

• Configurações no nível da rede

  • Se o projeto da sua rede for diferente do projeto host da frota (por exemplo, estiver usando uma VPC compartilhada), você precisará permitir Contas de serviço do Cloud Service Mesh no projeto da frota para acessar o projeto de rede. Você só precisa fazer isso uma vez para o projeto de rede.

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

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
        --member "serviceAccount:[e-mail]" \
        --role roles/anthosservicemesh.serviceAgent
    

• Configurações no nível do cluster

  • Quando estiver tudo pronto para criar clusters para usar com o Cloud Service Mesh, crie e registrá-las em uma única etapa com a Google Cloud CLI para usar o configuração do Terraform. Exemplo:

    gcloud container clusters create-auto CLUSTER_NAME \
        --fleet-project FLEET_PROJECT_ID \
        --location=LOCATION
    

    Execute este comando para receber o número do seu projeto da frota:

    gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
    

    A sinalização --location é a zona ou região do Compute (como us-central1-a ou us-central1) para o cluster.

  • Se o projeto do cluster for diferente do projeto host da frota, será necessário permitir que as contas de serviço do Cloud Service Mesh no projeto da frota acessem o projeto de cluster e ativar as APIs necessárias nele. É necessário fazer isso apenas uma vez para cada projeto de cluster.

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

    gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
        --member "serviceAccount:[e-mail]" \
        --role roles/anthosservicemesh.serviceAgent
    

    Ative a API da malha no projeto do cluster:

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

    Substitua CLUSTER_PROJECT_ID pelo identificador exclusivo de seu projeto de cluster. Se você criou o cluster no mesmo projeto como sua frota, o CLUSTER_PROJECT_ID será igual a o FLEET_PROJECT_ID.

Prossiga para Verificar se o plano de controle foi provisionado.

Configurar por cluster

Siga as etapas abaixo para configurar o Cloud Service Mesh gerenciado para cada cluster na sua malha individualmente.

Ativar o recurso de frota do Cloud Service Mesh

Ativar o Cloud Service Mesh no projeto da frota. Observe que, se você planeja registrar vários clusters, a ativação do Cloud 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

Registrar clusters em uma frota

1. Registrar um cluster do GKE com a Identidade da carga de trabalho da frota A flag --location é a zona do Compute ou região (como us-central1-a ou us-central1) para o cluster.

   gcloud container clusters update CLUSTER_NAME \
     --location CLUSTER_LOCATION \
     --fleet-project FLEET_PROJECT_ID
   

2. Verifique se o cluster está registrado:

   gcloud container fleet memberships list --project FLEET_PROJECT_ID
   

   Exemplo de saída:

   NAME                 EXTERNAL_ID                           LOCATION
   cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1
   

   Anote o MEMBERSHIP_NAME, porque você vai precisar dele ao ativar o gerenciamento automático.

3. Se o projeto de rede do cluster for diferente do projeto host da frota (por exemplo, se você estiver usando uma VPC compartilhada), será necessário permitir que as contas de serviço do Cloud Service Mesh no projeto da frota acessem o projeto de rede. Você só precisa fazer isso uma vez para o projeto de rede.

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

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
         --member "serviceAccount:[e-mail]" \
         --role roles/anthosservicemesh.serviceAgent
   

4. Se o projeto do cluster for diferente do projeto host da frota, permita Contas de serviço do Cloud Service Mesh no projeto da frota para acessar o cluster projeto de cluster e ativar as APIs necessárias no projeto de cluster.

   É necessário fazer isso apenas uma vez para cada projeto de cluster. Se você já tiver configurado o Cloud Service Mesh gerenciado para essa combinação de projetos de cluster e de frota, essas mudanças já foram aplicadas e não será necessário executar os comandos 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 "CLUSTER_PROJECT_ID" \
        --member "serviceAccount:[e-mail]" \
        --role roles/anthosservicemesh.serviceAgent
   

   Ative a API da malha no projeto do cluster:

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

Configurar o Certificate Authority Service (opcional)

Se a implantação da malha de serviço exigir o Certificate Authority Service (serviço de CA), siga as instruções em Configurar o Certificate Authority Service para o Cloud Service Mesh gerenciado para ativar o serviço na sua frota. Conclua todas as etapas antes de passar para a próxima seção.

Ativar gerenciamento automático

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

Observação: é possível aplicar essa mudança a vários clusters de uma só vez transmitindo uma lista separada por vírgulas de nomes de assinaturas como o parâmetro --memberships.

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

em que:

• MEMBERSHIP_NAME é o nome da assinatura listado quando você verificou que o cluster foi registrado na frota.

• MEMBERSHIP_LOCATION é o local da assinatura (uma região ou global).

  Se você criou a assinatura recentemente usando o comando neste guia, ela precisa ser a região do cluster. Se você tiver um cluster zonal, use a região correspondente à zona do cluster. Por exemplo, se você tiver um cluster zonal em us-central1-c, use o valor us-central1.

  Esse valor pode ser global se você se registrou antes de maio de 2023 ou se especificou o local global ao registrar a assinatura. É possível verificar o local da sua assinatura com gcloud container fleet memberships list --project FLEET_PROJECT_ID.

Verificar se o plano de controle foi provisionado

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/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
        implementation: ISTIOD | TRAFFIC_DIRECTOR
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

Anote o plano de controle mostrado no campo implementation: ISTIOD ou TRAFFIC_DIRECTOR. Consulte Recursos compatíveis com o Cloud Service Mesh para saber as diferenças e as configurações compatíveis do plano de controle e como a implementação do plano de controle é selecionada.

Configure kubectl para apontar para o cluster.

As seções a seguir envolvem a execução de comandos kubectl em cada um dos clusters. Antes de prosseguir com as próximas seções, execute o o comando a seguir em cada um dos clusters para configurar kubectl de modo que aponte para o no cluster.

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_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 os gateways em um ambiente de produção. Se você quiser usar um gateway de entrada ou de saída do Istio, consulte Implantar gateways. Se você quiser usar a API Kubernetes Gateway, consulte Prepare o gateway para a malha. Para ativar outros recursos opcionais, consulte Como ativar recursos opcionais no Cloud Service Mesh

Plano de dados gerenciado

Se você usa o Cloud Service Mesh gerenciado, o Google gerencia totalmente os upgrades dos seus proxies a menos que você o desative.

Com o plano de dados gerenciado, os proxies sidecar e os gateways injetados são atualizados automaticamente em conjunto com o plano de controle gerenciado reiniciando cargas de trabalho para injetar novas versões do proxy novamente. Isso normalmente é concluído de uma a duas semanas após o upgrade do plano de controle gerenciado.

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 anteriores do proxy. As remoções são feitas gradualmente, respeitando o orçamento de interrupção do pod e controlando a taxa de mudança.

Observação: se o cluster tiver um Janela de manutenção do GKE definido, as remoções de pods vão começar no início da próxima fase janela de manutenção e continuar sem pausas até que todos os pods atualizados (geralmente 12 horas). A janela de manutenção não é observada para problemas relacionados ao CVE lançamentos.

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

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

Desativar o plano de dados gerenciado (opcional)

Se você estiver provisionando o Cloud Service Mesh gerenciado em um novo cluster, poderá desativar completamente o plano de dados gerenciado ou para namespaces ou pods individuais. O plano de dados gerenciado continuará desativado para os clusters atuais em que foi desativado por padrão ou manualmente.

Para desativar o plano de dados gerenciado no nível do cluster e voltar a gerenciar os proxies sidecar, altere a anotação:

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

Para desativar o plano de dados gerenciado de um namespace:

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

Para desativar o plano de dados gerenciado de um pod:

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

Ativar notificações de manutenção

É possível solicitar uma notificação sobre a futura manutenção do plano de dados gerenciados até uma semana antes do horário de manutenção. 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. Quando ativadas, as notificações são enviadas pelo menos dois dias antes da operação de upgrade.

Para ativar as notificações de manutenção do plano de dados gerenciado:

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

   Acesse a página Comunicação.

2. Na linha Upgrade do Cloud Service Mesh, 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 Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"

O exemplo a seguir mostra uma notificação típica de manutenção do plano de dados gerenciados:

Linha de assunto: Próximo upgrade do cluster "<location/cluster-name>" do Cloud Service Mesh

Olá, usuário do Cloud Service Mesh,

O upgrade dos componentes do Cloud Service Mesh no cluster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) está programado para ${scheduled_date_human_Read} às ${scheduled_time_human_Read}.

É possível conferir as notas da versão (https://cloud.google.com/service-mesh/docs/release-notes) para saber mais sobre a nova atualização.

Caso essa manutenção seja reprogramada, você receberá outro e-mail com informações.

Atenciosamente,

Equipe do Cloud Service Mesh

(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 Enviamos este aviso para informar sobre mudanças importantes no Google Cloud Platform ou na sua conta. Para desativar as notificações sobre janelas de manutenção, altere suas preferências de usuário: https://console.cloud.google.com/user-preferences/communication?project=

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

Caso sua malha tenha apenas um cluster, pule as etapas de vários clusters e prossiga para Implante aplicativos ou Migre aplicativos.

Antes de continuar, verifique se o Cloud Service Mesh está configurado em cada cluster.

Observação:: saiba mais sobre a descoberta de endpoints em Descoberta de endpoints com vários planos de controle.

Ativar o Cloud Service Mesh com a API frota vai ativar a descoberta de endpoints para neste 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 com a API declarativa.

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

Observação: o exemplo do serviço HelloWorld usa o Docker Hub. Em um cluster particular, o ambiente de execução do contêiner pode extrair imagens do Artifact Registry por padrão. O ambiente de execução do contêiner não pode extrair imagens de outros registros de imagem de contêineres na Internet. É possível fazer o download e enviar a imagem para o Artifact Registry ou usar o Cloud NAT para fornecer acesso de saída à Internet para determinados nós particulares. Para mais informações, consulte Migrar contêineres externos e Como criar um cluster particular.

Implanta aplicativos

Se você tiver mais de um cluster na frota usando o Cloud Service Mesh gerenciado, garantir que a descoberta de endpoints ou as portas do firewall estejam configuradas conforme o esperado e implantar aplicativos.

Ativar o namespace para injeção. As etapas dependem da implementação do plano de controle.

Gerenciado (TD)

1. Aplique o rótulo de injeção padrão ao namespace:

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

Gerenciado (Istiod)

Recomendado:execute o seguinte comando para aplicar a injeção padrão rótulo ao namespace:

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

Se você for um usuário com o plano de controle Managed Istiod: Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é suporte. Siga estas instruções:

1. Execute o seguinte comando para localizar os canais de lançamento disponíveis:

   kubectl -n istio-system get controlplanerevision
   

   O resultado será assim:

   NAME                AGE
   asm-managed-rapid   6d7h
   

   OBSERVAÇÃO: se duas revisões do plano de controle aparecerem na lista acima, remova uma. Não é possível ter vários canais de plano de controle no cluster.

   Na saída, o valor na coluna NAME é o rótulo de revisão que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh.

2. Aplique o rótulo de revisão ao namespace:

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

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

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.

Personalizar injeção (opcional)

É possível substituir os valores padrão e personalizar as configurações de injeção, mas isso pode levar a erros de configuração imprevistos e problemas resultantes com contêineres sidecar. Antes de personalizar a injeção, leia as informações após o exemplo para conferir notas sobre configurações e recomendações específicas.

A configuração por pod está disponível para substituir essas opções em pods individuais. Para fazer isso, adicione um contêiner istio-proxy ao seu pod. A injeção de sidecar vai tratar qualquer configuração definida aqui como uma substituição do modelo de injeção padrão.

Por exemplo, a configuração a seguir personaliza várias configurações, incluindo a redução das solicitações de CPU, adição de uma montagem de volume e adição de um hook preStop:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

Em geral, qualquer campo em um pod pode ser definido. No entanto, é preciso ter cuidado com alguns campos:

• O Kubernetes exige que o campo image seja definido antes da execução da injeção. Embora você possa definir uma imagem específica para substituir a padrão, recomendamos que você defina image como auto, o que fará com que o injetor do arquivo secundário para selecionar automaticamente a imagem a ser usada.
• Alguns campos em containers dependem de configurações relacionadas. Por exemplo, ele precisa ser menor ou igual ao limite da CPU. Se os dois campos não estiverem configurados corretamente, o pod pode não ser iniciado.
• O Kubernetes permite definir requests e limits para recursos no spec do pod. O GKE Autopilot só considera requests. Para mais informações, consulte Como definir limites de recursos no Autopilot.

Além disso, alguns campos podem ser configurados por anotações no pod, mas é recomendável usar a abordagem acima para personalizar as configurações. Tome ainda mais cuidado com as seguintes anotações:

• Para o GKE Standard, se sidecar.istio.io/proxyCPU estiver definido, defina explicitamente sidecar.istio.io/proxyCPULimit. Caso contrário, o limite de CPU do arquivo secundário será definido como ilimitado.
• Para o GKE Standard, se sidecar.istio.io/proxyMemory estiver definido, defina explicitamente sidecar.istio.io/proxyMemoryLimit. Caso contrário, o limite de memória do arquivo secundário será definido como ilimitado.
• No GKE Autopilot, configurar o recurso requests e limits usando anotações pode superprovisionar recursos. Use a abordagem de modelo de imagem para evitar. Consulte Exemplos de modificação de recursos no Autopilot.

Por exemplo, confira a anotação de recursos abaixo:

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

Migrar aplicativos para o Cloud Service Mesh gerenciado

Aviso: durante o processo de migração, os CRDs do Istio são instalados no cluster especificado. Se houver CRDs do Istio no cluster, eles serão substituído.

Para migrar aplicativos do Cloud Service Mesh no cluster para o Cloud Service Mesh gerenciado, siga estas etapas:

Observação: verifique se você provisionou o Cloud Service Mesh gerenciado seguindo todas as nas seções anteriores deste guia.
1. Substitua o rótulo de namespace atual. As etapas dependem da implementação do plano de controle.

Gerenciado (TD)

1. Aplique o rótulo de injeção padrão ao namespace:

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

Gerenciado (Istiod)

Recomendado:execute o seguinte comando para aplicar a injeção padrão rótulo ao namespace:

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

Se você for um usuário com o plano de controle Managed Istiod: Recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é suporte. Siga estas instruções:

1. Execute o seguinte comando para localizar os canais de lançamento disponíveis:

   kubectl -n istio-system get controlplanerevision
   

   O resultado será assim:

   NAME                AGE
   asm-managed-rapid   6d7h
   

   OBSERVAÇÃO: se duas revisões do plano de controle aparecerem na lista acima, remova uma. Não é possível ter vários canais de plano de controle no cluster.

   Na saída, o valor na coluna NAME é o rótulo de revisão que corresponde ao canal de lançamento disponível para a versão do Cloud Service Mesh.

2. Aplique o rótulo de revisão ao namespace:

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

1. Execute um upgrade contínuo das implantações no namespace:

   kubectl rollout restart deployment -n NAMESPACE
   

2. Teste o aplicativo para verificar se as cargas de trabalho funcionam corretamente.

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

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

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

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