Provisionar o Cloud Service Mesh gerenciado com o asmcli

Visão geral

O Cloud Service Mesh gerenciado com asmcli é um plano de controle gerenciado e um plano de dados gerenciado 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 Cloud Service Mesh gerenciado em uma configuração de um ou vários clusters com asmcli.

Para saber mais sobre os recursos e as limitações compatíveis com o Cloud Service Mesh gerenciado, consulte Recursos compatíveis com o Cloud 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.

  • O Cloud Service Mesh gerenciado usa canais de lançamento do GKE para equilibrar a estabilidade e a velocidade de upgrade. As novas mudanças nos componentes do cluster do Cloud Service Mesh (incluindo CNI, MDPC, proxies e CRDs do Istio) serão lançadas primeiro nos clusters que se inscrevem no canal rápido do GKE. Elas serão promovidas para o canal normal do GKE e, por fim, para o canal estável do GKE, quando demonstrarem estabilidade suficiente.

    • O Cloud Service Mesh gerenciado não oferece suporte à alteração segura dos canais de lançamento do GKE.
    • Se você mudar o canal de lançamento do GKE, o Cloud Service Mesh vai fazer upgrade/downgrade automático dos componentes no cluster (CNI, MDPC, versão padrão do proxy injetado e CRDs do Istio) para se alinhar ao canal de lançamento atual do GKE.

  • Verifique se o cluster tem capacidade suficiente para os componentes necessários que gerenciaram as instalações 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. 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 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.
    • Se a organização usar o VPC Service Controls e você estiver provisionando o Cloud Service Mesh em clusters do GKE com uma versão maior ou igual a 1.22.1-gke.10, talvez seja necessário seguir outras etapas de configuração:

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

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

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 CABeta roles/privateca.admin Projeto da frota Acesso completo a todos os recursos de serviço de CA. (Observação 2)

Limitações

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.

  • 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 atuais do Istio 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 não oferece suporte a clusters com o GKE Sandbox ativado.

  • A ferramenta asmcli precisa ter acesso ao endpoint do Google Kubernetes Engine (GKE). É possível configurar o acesso por meio de um servidor"salto", como uma VM do Compute Engine na nuvem privada virtual (VPC) que dá acesso específico.

Antes de começar

Configurar a gcloud

Siga as etapas abaixo mesmo que você esteja usando o Cloud Shell.

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

    gcloud auth login --project PROJECT_ID

    em que PROJECT_ID é o identificador exclusivo do projeto do cluster. Execute o seguinte comando para receber o PROJECT_ID:

       gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```

  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 Cloud Service Mesh gerenciado 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. O canal do Cloud Service Mesh é determinado pelo canal do cluster do GKE no momento do provisionamento do Cloud Service Mesh gerenciado. Não é possível usar vários canais no mesmo cluster ao mesmo tempo.

Execute a ferramenta de instalação para cada cluster que usará o Cloud 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 de frota e o projeto de cluster também serão iguais. 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.

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.

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

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.
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --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

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

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

A resposta é semelhante a:

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

Se o status não atingir ACTIVE em alguns minutos, consulte Verificar o status do plano de controle gerenciado para 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.

Plano de dados gerenciado

Se você usa o Cloud Service Mesh gerenciado, o Google gerencia totalmente os upgrades dos proxies.

Com o recurso do plano de dados gerenciado ativado, os proxies sidecar e os gateways injetados são atualizados de forma ativa e automática em conjunto com o plano de controle gerenciado, reiniciando as cargas de trabalho para injetar novas versões do proxy novamente. Isso começa depois que o plano de controle é atualizado e normalmente é concluído em até duas semanas após o início.

O plano de dados gerenciado depende do canal de lançamento do GKE. Se você mudar o canal de lançamento do GKE enquanto o plano de dados gerenciado estiver ativado, o Cloud Service Mesh gerenciado vai atualizar os proxies de todas as cargas de trabalho atuais, como um lançamento de plano de dados gerenciado.

Se desativado, o gerenciamento de proxy é feito de forma passiva, 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.

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

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

Se você provisionou o Cloud Service Mesh gerenciado em um cluster mais antigo, pode ativar o gerenciamento do plano 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.

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 ativada, 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:

Assunto: Futuro upgrade para o cluster do Cloud Service Mesh "<location/cluster-name>"

Olá, usuário do Cloud Service Mesh,

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

É 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)

Se a malha tiver apenas um cluster, pule essas etapas de vários clusters e vá para Implantar aplicativos ou Migrar aplicativos.

Antes de continuar, verifique se o Cloud Service Mesh está configurado em cada 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.

Implanta 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 comando a seguir para aplicar o rótulo de injeção padrão ao namespace:

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

Se você já for usuário do plano de controle do Istiod gerenciado:recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é compatível. 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

Valide se o rótulo do namespace foi aplicado corretamente usando o comando abaixo.

  kubectl get namespace -L istio-injection

Exemplo de saída:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

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 seja possível definir uma imagem específica para substituir a padrão, recomendamos definir a image como auto, o que fará com que o injetor do sidecar selecione a imagem automaticamente.
  • 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. Tenha 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"

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 a configuração funciona conforme o esperado:

  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: marcador revision e proxy_version marcador
    • Soma do agregador
    • Período: 1 minuto

    Ao executar o Cloud 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 Cloud Service Mesh, consulte Versões do Cloud Service Mesh por canal.

Migrar aplicativos para o Cloud Service Mesh gerenciado

Preparar para a migração

Para preparar a migração de aplicativos do Cloud Service Mesh no cluster para o Cloud 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 Cloud Service Mesh no cluster para o Cloud Service Mesh gerenciado, siga estas etapas:

  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 comando a seguir para aplicar o rótulo de injeção padrão ao namespace:

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

Se você já for usuário do plano de controle do Istiod gerenciado:recomendamos que você use a injeção padrão, mas a injeção baseada em revisão é compatível. 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 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.

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