Atualizações de configuração para modernização

Este documento descreve as atualizações de configuração que pode ter de fazer à sua malha de serviços na nuvem gerida antes de modernizar a malha para o plano de controlo TRAFFIC_DIRECTOR a partir do plano de controlo ISTIOD.

Segue-se uma lista de possíveis atualizações de configuração necessárias para preparar o cluster para a modernização. Consulte cada secção para ver as instruções de atualização:

Para mais informações sobre o fluxo de trabalho de modernização, consulte a página Modernização do plano de controlo gerido.

Migre de segredos do Istio para multicluster_mode

Os segredos de vários clusters não são suportados quando um cluster está a usar o plano de controlo TRAFFIC_DIRECTOR. Este documento descreve como pode modernizar a utilização de segredos de vários clusters do Istio para a utilização de multicluster_mode.

Vista geral da API declarativa versus segredos do Istio

A descoberta de pontos finais multi-cluster istio de código aberto funciona através da utilização de istioctl ou outras ferramentas para criar um segredo do Kubernetes num cluster. Este segredo permite que um cluster equilibre a carga do tráfego para outro cluster na malha. Em seguida, o plano de controlo ISTIOD lê este segredo e começa a encaminhar o tráfego para esse outro cluster.

O Cloud Service Mesh tem uma API declarativa para controlar o tráfego de vários clusters em vez de criar diretamente segredos do Istio. Esta API trata os segredos do Istio como um detalhe de implementação e é mais fiável do que criar segredos do Istio manualmente. As funcionalidades futuras da Cloud Service Mesh vão depender da API declarativa, e não vai poder usar essas novas funcionalidades diretamente com os segredos do Istio. A API declarativa é o único caminho suportado.

Se estiver a usar segredos do Istio, migre para a API declarativa assim que possível. Tenha em atenção que a definição multicluster_mode direciona cada cluster para direcionar o tráfego para todos os outros clusters na malha. A utilização de segredos permite uma configuração mais flexível, o que lhe permite configurar para cada cluster para que outro cluster deve direcionar o tráfego na malha. Para ver uma lista completa das diferenças entre as funcionalidades suportadas da API declarativa e os segredos do Istio, consulte o artigo Funcionalidades suportadas através das APIs Istio.

Migre de segredos do Istio para a API declarativa

Se aprovisionou a malha de serviços na nuvem através da gestão automática com a API de funcionalidades da frota, não tem de seguir estas instruções. Estes passos só se aplicam se tiver feito a integração através do asmcli --managed.

Tenha em atenção que este processo altera os segredos que apontam para um cluster. Durante este processo, os pontos finais são removidos e, em seguida, adicionados novamente. Entre os pontos finais removidos e adicionados, o tráfego reverte brevemente para o encaminhamento local em vez do equilíbrio de carga para outros clusters. Para mais informações, consulte o problema do GitHub.

Para mudar da utilização de segredos do Istio para a API declarativa, siga estes passos. Execute estes passos ao mesmo tempo ou em sucessão rápida:

  1. Ative a API declarativa para cada cluster na frota onde quer ativar a deteção de pontos finais de vários clusters definindo multicluster_mode=connected. Tenha em atenção que tem de definir explicitamente multicluster_mode=disconnected se não quiser que o cluster seja detetável.

    Use o seguinte comando para ativar um cluster para a deteção de pontos finais de vários clusters:

     kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'

    Use o seguinte comando para desativar a deteção de pontos finais num cluster:

     kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'

  2. Elimine segredos antigos.

    Depois de definir multicluster_mode=connected nos seus clusters, cada cluster tem um novo segredo gerado para todos os outros clusters que também têm multicluster_mode=connected definido. O segredo é colocado no espaço de nomes istio-system e tem o seguinte formato:

    istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS

    Cada segredo também tem a etiqueta istio.io/owned-by: mesh.googleapis.com aplicada.

    Depois de criar os novos segredos, pode eliminar manualmente os segredos criados com istioctl create-remote-secret:

    kubectl delete secret SECRET_NAME -n istio-system

Após a migração, verifique as métricas de pedidos para se certificar de que são encaminhadas conforme esperado.

Ative a federação de identidades da carga de trabalho para o GKE

A federação de identidade da carga de trabalho é o método seguro recomendado para cargas de trabalho do Google Kubernetes Engine. Isto permite o acesso a Google Cloud serviços como o Compute Engine, o BigQuery e as APIs de aprendizagem automática. A federação de identidades da carga de trabalho não requer configuração manual nem métodos menos seguros, como ficheiros de chaves de contas de serviço, porque usa políticas do IAM. Para mais detalhes sobre a federação de identidades da carga de trabalho, consulte o artigo Como funciona a federação de identidades da carga de trabalho para o GKE.

A secção seguinte descreve como ativar a Workload Identity Federation.

Ative a federação de identidades de cargas de trabalho em clusters

  1. Verifique se a federação de identidade da força de trabalho está ativada para o seu cluster. Para tal, certifique-se de que o cluster do GKE tem um conjunto da federação de identidade da força de trabalho configurado, o que é essencial para a validação de credenciais do IAM.

    Use o seguinte comando para verificar o Workload Identity Pool definido para um cluster:

    gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"

    Substitua CLUSTER_NAME pelo nome do seu cluster do GKE. Se ainda não especificou uma zona ou uma região predefinida para o gcloud, também pode ter de especificar uma flag --region ou --zone quando executar este comando.

  2. Se o resultado estiver vazio, siga as instruções em Atualize um cluster existente para ativar o Workload Identity em clusters do GKE existentes.

Ative a federação de identidades de cargas de trabalho em node pools

Depois de a Workload Identity Federation ser ativada num cluster, os grupos de nós têm de ser configurados para usar o servidor de metadados do GKE.

  1. Listar todos os conjuntos de nós de um cluster Standard. Execute o comando gcloud container node-pools list:

    gcloud container node-pools list --cluster CLUSTER_NAME

    Substitua CLUSTER_NAME pelo nome do seu cluster do GKE. Se ainda não especificou uma zona ou uma região predefinida para o gcloud, também pode ter de especificar uma flag --region ou --zone quando executar este comando.

  2. Verifique se cada pool de nós está a usar o servidor de metadados do GKE:

    gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"

    Substitua o seguinte:

    • NODEPOOL_NAME com o nome do seu nodepool.
    • CLUSTER_NAME com o nome do seu cluster do GKE.

  3. Se o resultado não contiver GKE_METADATA, atualize o node pool através do guia Atualize um node pool existente.

Ative a interface de rede do contentor (CNI) gerida

Esta secção explica como ativar a CNI gerida para a Cloud Service Mesh no Google Kubernetes Engine.

Vista geral da CNI gerida

A interface de rede de contentores (CNI) gerida é uma implementação gerida pela Google da CNI do Istio. O plug-in CNI simplifica a rede de pods configurando regras de iptables. Isto permite o redirecionamento de tráfego entre aplicações e proxies do Envoy, eliminando a necessidade de autorizações privilegiadas para o init-container necessário para gerir o iptables.

O plug-in CNI do Istio substitui o contentor istio-init. Anteriormente, o contentor istio-init era responsável por configurar o ambiente de rede do pod para permitir a interceção de tráfego para o sidecar do Istio. O plug-in CNI executa a mesma função de redirecionamento de rede, mas com a vantagem adicional de reduzir a necessidade de privilégios elevados, melhorando assim a segurança.

Por conseguinte, para uma maior segurança e fiabilidade, e para simplificar a gestão e a resolução de problemas, a CNI gerida é necessária em todas as implementações do Managed Cloud Service Mesh.

Impacto nos contentores de inicialização

Os contentores init são contentores especializados que são executados antes dos contentores de aplicações para tarefas de configuração. As tarefas de configuração podem incluir tarefas como transferir ficheiros de configuração, comunicar com serviços externos ou realizar a inicialização pré-aplicação. Os contentores de inicialização que dependem do acesso à rede podem ter problemas quando o CNI gerido está ativado no cluster.

O processo de configuração do pod com a CNI gerida é o seguinte:

  1. O plugin CNI configura interfaces de rede de pods, atribui IPs de pods e redireciona o tráfego para o proxy sidecar do Istio, que ainda não foi iniciado.
  2. Todos os contentores init são executados e concluídos.
  3. O proxy sidecar do Istio é iniciado juntamente com os contentores da aplicação.

Por conseguinte, se um contentor init tentar estabelecer ligações de rede de saída ou ligar-se a serviços na malha, os pedidos de rede dos contentores init podem ser ignorados ou encaminhados incorretamente. Isto deve-se ao facto de o proxy sidecar do Istio, que gere o tráfego de rede para o pod, não estar em execução quando os pedidos são feitos. Para mais detalhes, consulte a documentação do Istio CNI.

Ative a CNI gerida para o seu cluster

Siga os passos nesta secção para ativar a CNI gerida no seu cluster.

  1. Remova as dependências de rede do seu contentor de inicialização. Considere as seguintes alternativas:

    • Modifique a lógica ou os contentores da aplicação: pode modificar os seus serviços para remover a dependência de contentores init que requerem pedidos de rede ou realizar operações de rede nos contentores da aplicação, depois de o proxy sidecar ter sido iniciado.
    • Use ConfigMaps ou secrets do Kubernetes: armazene os dados de configuração obtidos pelo pedido de rede em ConfigMaps ou secrets do Kubernetes e monte-os nos contentores da sua aplicação. Para soluções alternativas, consulte a documentação do Istio.

  2. Ative a CNI gerida no cluster:

    1. Faça as seguintes alterações de configuração:

      1. Execute o seguinte comando para localizar o controlPlaneRevision. 

        kubectl get controlplanerevision -n istio-system

      2. No recurso personalizado (CR) ControlPlaneRevision (CPR), defina a etiqueta mesh.cloud.google.com/managed-cni-enabled como true.

        kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite

        Substitua CPR_NAME pelo valor na coluna NAME do resultado do passo anterior.

      3. No ConfigMap asm-options, defina o valor ASM_OPTS como CNI=on.

        kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'

      4. No recurso personalizado (CR) ControlPlaneRevision (CPR), defina a etiqueta mesh.cloud.google.com/force-reprovision como true. Esta ação aciona o reinício do plano de controlo.

        kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite

    2. Verifique o estado da funcionalidade. Recupere o estado da funcionalidade através do seguinte comando:

      gcloud container fleet mesh describe --project FLEET_PROJECT_ID

      Substitua FLEET_PROJECT_ID pelo ID do seu projeto de anfitrião do Fleet. Geralmente, o FLEET_PROJECT_ID tem o mesmo nome que o projeto.

      • Verifique se a condição MANAGED_CNI_NOT_ENABLED foi removida de servicemesh.conditions.
      • Tenha em atenção que o estado pode demorar até 15 a 20 minutos a ser atualizado. Experimente aguardar alguns minutos e executar novamente o comando.

    3. Quando o controlPlaneManagement.state estiver Active no estado da funcionalidade do cluster, reinicie os pods.

Afastar-se da utilização binária não padrão no Sidecar

Esta secção sugere formas de tornar as suas implementações compatíveis com a imagem do proxy do Envoy sem distribuição.

Imagens complementares do proxy do Envoy sem distribuição

O Cloud Service Mesh usa dois tipos de imagens secundárias do proxy Envoy com base na configuração do plano de controlo, numa imagem baseada no Ubuntu que contém vários ficheiros binários e numa imagem sem distribuição. As imagens de base sem distribuição são imagens de contentores mínimas que dão prioridade à segurança e à otimização de recursos, incluindo apenas os componentes essenciais. A superfície de ataque é reduzida para ajudar a evitar vulnerabilidades. Para mais informações, consulte a documentação sobre a imagem de proxy Distroless.

Compatibilidade binária

Como prática recomendada, deve restringir o conteúdo de um tempo de execução do contentor apenas aos pacotes necessários. Esta abordagem melhora a segurança e a relação sinal/ruído dos scanners de vulnerabilidades e exposições comuns (CVE). A imagem do sidecar sem distribuição tem um conjunto mínimo de dependências, sem todos os executáveis, bibliotecas e ferramentas de depuração não essenciais. Por conseguinte, não é possível executar um comando de shell nem usar curl, ping ou outras utilidades de depuração, como kubectl exec, no contentor.

Torne os clusters compatíveis com imagens sem distribuição

  • Remova referências a quaisquer ficheiros binários não suportados (como bash ou curl) da sua configuração. Particularmente nas sondas de Readiness, Startup e Liveness, e nos hooks Lifecycle PostStart e PreStop nos contentores istio-proxy, istio-init ou istio-validation.
  • Considere alternativas como holdApplicationUntilProxyStarts para determinados exemplos de utilização.
  • Para a depuração, pode usar contentores efémeros para anexar a um pod de carga de trabalho em execução. Em seguida, pode inspecioná-lo e executar comandos personalizados. Para ver um exemplo, consulte o artigo Recolher registos da malha de serviços na nuvem.

Se não conseguir encontrar uma solução para o seu exemplo de utilização específico, contacte o Google Cloud apoio técnico em Receber apoio técnico.

Migre para o Istio Ingress Gateway

Esta secção mostra como migrar para o Istio Ingress Gateway. Existem dois métodos para migrar para o Istio Ingress Gateway:

  1. Migração faseada com divisão de tráfego

    Este método dá prioridade à minimização da interrupção, em que envia incrementalmente tráfego para o novo gateway do Istio, o que lhe permite monitorizar o respetivo desempenho numa pequena percentagem de pedidos e reverter rapidamente, se necessário. Tenha em atenção que a configuração da divisão de tráfego da camada 7 pode ser desafiante para algumas aplicações, pelo que tem de gerir os dois sistemas de gateway em simultâneo durante a transição. Consulte o artigo Migração faseada com divisão de tráfego para ver os passos.

  2. Migração direta

    Este método envolve o reencaminhamento simultâneo de todo o tráfego para o novo gateway do Istio assim que tiver realizado testes exaustivos. A vantagem desta abordagem é a separação completa da infraestrutura da gateway antiga, o que permite uma configuração adaptável da nova gateway sem as restrições da configuração existente. No entanto, existe um risco acrescido de tempo de inatividade caso surjam problemas inesperados com o novo gateway durante a transição. Consulte o artigo Migração direta para ver os passos.

Os exemplos de migração seguintes pressupõem que tem um serviço HTTP (httpbin) a ser executado no espaço de nomes da aplicação (predefinição) e exposto externamente através da API Kubernetes Gateway. As configurações relevantes são:

  • Gateway: k8-api-gateway (no espaço de nomes istio-ingress) – configurado para ouvir o tráfego HTTP na porta 80 para qualquer nome de anfitrião que termine com .example.com.
  • HTTPRoute: httpbin-route (no espaço de nomes default) – direciona qualquer pedido HTTP com o nome do anfitrião httpbin.example.com e um caminho que comece por /get para o serviço httpbin no espaço de nomes default.
  • A aplicação httpbin está acessível através do IP externo 34.57.246.68.

Diagrama de gateway básico

Migração faseada com divisão de tráfego

Aprovisione um novo Istio Ingress Gateway

  1. Implemente um novo gateway de entrada seguindo os passos na secção Implementar gateway de exemplo e personalize as configurações de exemplo de acordo com os seus requisitos. Os exemplos no repositório anthos-service-mesh destinam-se à implementação de um serviço istio-ingressgateway loadBalancer e dos pods ingress-gateway correspondentes.

    Exemplo de recurso de gateway (istio-ingressgateway.yaml)

     apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

  2. Aplique a configuração de Gateway para gerir o tráfego:

    kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE

    Certifique-se de que o "spec.selector" no recurso Gateway corresponde às etiquetas dos seus pods ingress-gateway. Por exemplo, se os contentores ingress-gateway tiverem a etiqueta istio=ingressgateway, a configuração do gateway também tem de selecionar esta etiqueta istio=ingressgateway.

Configure o encaminhamento inicial para o novo gateway

  1. Defina as regras de encaminhamento iniciais para a sua aplicação através de um VirtualService do Istio.

    Exemplo de VirtualService (my-app-vs-new.yaml):

    apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

  2. Aplique o VirtualService:

    kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

Aceder ao serviço de back-end (httpbin) através do gateway de entrada do Istio recentemente implementado

  1. Defina a variável de ambiente Ingress Host para o endereço IP externo associado ao balanceador de carga istio-ingressgateway implementado recentemente:

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

  2. Valide se a aplicação (httpbin) está acessível através do novo gateway:

    curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"

    O resultado é semelhante ao seguinte:

    HTTP/1.1 200 OK

Fluxo de pedidos com o novo gateway de entrada do Istio

Modifique o Ingress existente para a divisão do tráfego

Depois de confirmar a configuração bem-sucedida do novo gateway (por exemplo, istio-api-gateway), pode começar a encaminhar uma parte do seu tráfego através dele. Para o fazer, atualize o seu HTTPRoute atual para direcionar uma pequena percentagem do tráfego para o novo gateway, enquanto a maior parte continua a usar o gateway existente (k8-api-gateway).

  1. Abra a httproute para edição:

    kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

  2. Adicione uma nova referência de back-end que aponte para o serviço de balanceamento de carga do gateway de entrada com um peso inicial de 10% e atualize o peso do back-end do gateway antigo.

    apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

  3. Conceda autorização para referências entre espaços de nomes com a concessão de referências.

    Para permitir que o seu HTTPRoute no espaço de nomes da aplicação (predefinição) aceda ao serviço loadbalancer no espaço de nomes do gateway (istio-ingress), pode ter de criar uma concessão de referência. Este recurso serve como um controlo de segurança, definindo explicitamente as referências entre espaços de nomes permitidas.

    O exemplo de istio-ingress-grant.yaml seguinte descreve uma concessão de referência:

    apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute 
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway

  4. Aplique a subvenção de referência:

    kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

  5. Valide pedidos para o endereço IP externo existente (por exemplo, 34.57.246.68) não estão a falhar. O exemplo seguinte check-traffic-flow.sh descreve um script para verificar falhas de pedidos:

    # Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

  6. Execute o script para confirmar que nenhum pedido falha, independentemente da rota de tráfego:

    chmod +x check-traffic-flow.sh
./check-traffic-flow.sh

Fluxo de pedidos com divisão de tráfego entre o gateway existente e o novo gateway de entrada do Istio

Aumente lentamente a percentagem de tráfego

Se não forem detetadas falhas de pedidos para o endereço IP externo existente (por exemplo, 34.57.246.68), transfira gradualmente mais tráfego para o novo Istio Ingress Gateway ajustando os pesos do back-end no seu HTTPRoute. Aumente o peso do istio-ingressgateway e diminua o peso da entrada antiga em pequenos incrementos, como 10%, 20% e assim sucessivamente.

Use o seguinte comando para atualizar o seu HTTPRoute existente:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migração total do tráfego e remoção do gateway antigo

  1. Quando o novo Istio Ingress Gateway demonstrar um desempenho estável e um processamento de pedidos bem-sucedido, transfira todo o tráfego para o mesmo. Atualize o HTTPRoute para definir o peso do back-end do gateway antigo para 0 e o do novo gateway para 100.

  2. Assim que o tráfego for totalmente encaminhado para o novo gateway, atualize os registos DNS externos do nome do anfitrião da sua aplicação (por exemplo, httpbin.example.com) para apontar para o endereço IP externo do serviço de balanceamento de carga criado em Aprovisione um novo Istio Ingress Gateway.

  3. Por fim, elimine o gateway antigo e os respetivos recursos associados:

    kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

Migração direta

Aprovisione um novo Istio Ingress Gateway

  1. Implemente um novo gateway de entrada seguindo os passos na secção Implementar gateway de exemplo e personalize as configurações de exemplo de acordo com os seus requisitos. Os exemplos no repositório anthos-service-mesh destinam-se à implementação de um serviço istio-ingressgateway loadBalancer e dos pods ingress-gateway correspondentes.

    Exemplo de recurso de gateway (istio-ingressgateway.yaml)

     apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

  2. Aplique a configuração de Gateway para gerir o tráfego:

    kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE

    Certifique-se de que o "spec.selector" no recurso Gateway corresponde às etiquetas dos seus pods ingress-gateway. Por exemplo, se os contentores ingress-gateway tiverem a etiqueta istio=ingressgateway, a configuração do gateway também tem de selecionar esta etiqueta istio=ingressgateway.

Configure o encaminhamento inicial para o novo gateway

  1. Defina as regras de encaminhamento iniciais para a sua aplicação através de um VirtualService do Istio.

    Exemplo de VirtualService (my-app-vs-new.yaml):

    apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

  2. Aplique o VirtualService:

    kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

Aceder ao serviço de back-end (httpbin) através do gateway de entrada do Istio recentemente implementado

  1. Defina a variável de ambiente Ingress Host para o endereço IP externo associado ao balanceador de carga istio-ingressgateway implementado recentemente:

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

  2. Valide se a aplicação (httpbin) está acessível através do novo gateway:

    curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"

    O resultado é semelhante ao seguinte:

    HTTP/1.1 200 OK

Fluxo de pedidos com o novo gateway de entrada do Istio

Teste e monitorize o novo gateway

  1. Teste todas as regras de encaminhamento, valide a configuração do TLS, as políticas de segurança e outras funcionalidades. Faça testes de carga para verificar se o novo gateway consegue processar o tráfego esperado.

  2. Assim que o novo gateway for totalmente testado, atualize os registos DNS externos para o nome do anfitrião da sua aplicação (por exemplo, httpbin.example.com) de modo a apontar para o endereço IP externo do serviço de balanceamento de carga criado em Aprovisione um novo gateway de entrada do Istio.

  3. Monitorize as principais métricas, como a taxa de sucesso de pedidos, a latência, as taxas de erro e a utilização de recursos dos pods da sua aplicação para validar a estabilidade com o novo Istio Ingress Gateway. Quando estiver estável, pode eliminar o gateway antigo e os respetivos recursos associados

    kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

Considerações importantes: certifique-se de que os certificados e as configurações TLS estão corretamente configurados no novo Istio Ingress Gateway se a sua aplicação exigir HTTPS. Consulte o artigo Configure a terminação TLS no gateway de entrada para ver mais detalhes.

Corrija vários planos de controlo

Anteriormente, o Cloud Service Mesh suportava a incorporação através do asmcli (descontinuado) que não bloqueava o aprovisionamento de vários planos de controlo. A Cloud Service Mesh aplica agora a prática recomendada de implementar apenas um canal por cluster que corresponde ao canal do cluster e não suporta a utilização de vários canais implementados no mesmo cluster.

Se quiser implementações canary em novas versões da malha rapidamente antes de ficarem disponíveis na versão estável ou normal, tem de usar dois clusters diferentes, cada um com um canal separado. Tenha em atenção que os canais são controlados pelo canal do cluster do GKE e que o Mesh não tem um canal separado associado.

Pode verificar se tem vários canais procurando a UNSUPPORTED_MULTIPLE_CONTROL_PLANES condição de estado na sua subscrição. Se este aviso não for apresentado, não é afetado e pode ignorar a leitura desta secção.

  1. Execute o seguinte comando para verificar se o cluster tem vários canais do plano de controlo:

    gcloud container fleet mesh describe

    O resultado é semelhante ao seguinte:

    ...
projects/.../locations/global/memberships/my-membership:
    servicemesh:
      conditions:
      - code: UNSUPPORTED_MULTIPLE_CONTROL_PLANES
        details: 'Using multiple control planes is not supported. Please remove a control plane from your cluster.'
        documentationLink: https://cloud.google.com/service-mesh/docs/migrate/modernization-configuration-updates#multiple_control_planes
        severity: WARNING
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed-stable'
        implementation: ISTIOD
        state: ACTIVE
...

  2. Se a condição UNSUPPORTED_MULTIPLE_CONTROL_PLANES aparecer, determine que canais existem para o seu cluster:

    kubectl get controlplanerevisions -n istio-system

    O resultado é semelhante ao seguinte:

    NAME                 RECONCILED   STALLED   AGE
asm-managed-stable   True         False     97d
asm-managed          True         False     97d
asm-managed-rapid    True         False     97d

    Neste exemplo, os três canais foram aprovisionados:

    • asm-managed-stable -> STABLE
    • asm-managed -> REGULAR
    • asm-managed-rapid -> RAPID

    Se aparecer apenas 1 resultado, significa que apenas um canal está aprovisionado no seu cluster e pode ignorar os restantes passos.

    Se aparecerem 2 ou mais resultados, siga os restantes passos para remover os canais em excesso.

Consolide as cargas de trabalho num único canal

Antes de poder remover canais adicionais, tem de garantir que as suas cargas de trabalho estão a usar apenas um canal.

  1. Encontre todas as etiquetas que está a usar no seu cluster:

    kubectl get namespaces -l istio.io/rev=RELEASE_CHANNEL

    Consoante o resultado do comando anterior, substitua RELEASE_CHANNEL por asm-managed-stable, asm-managed ou asm-managed-rapid. Repita este passo para cada canal aprovisionado.

    O resultado é semelhante ao seguinte:

    NAME      STATUS   AGE
default   Active   110d

    Tenha em atenção que, neste exemplo, o espaço de nomes predefinido está a ser injetado com o canal normal.

    Se todas as suas cargas de trabalho já estiverem a usar o mesmo canal, pode ignorar para o passo Remova os canais adicionais. Caso contrário, continue nesta secção.

  2. Altere as etiquetas para que apenas seja usado um canal:

    • Em alguns casos, os pods também podem ser injetados diretamente com a etiqueta sidecar.istio.io/inject. Certifique-se de que também as verifica para essa utilização.
    • Pode ignorar as etiquetas istio-injection=enabled para este passo. Os espaços de nomes com essa etiqueta mudam automaticamente para corresponder ao canal que restar no cluster.
    • Quando selecionar um canal para manter, experimente selecionar o canal que é igual ao canal do cluster do GKE. Se este canal não existir, selecione um dos canais ativos.
    • O canal que selecionar não é importante. O canal do cluster do GKE determina a versão da malha que recebe, e não o canal da malha.
    • Verifique a configuração do meshconfig entre os canais ativos que estão a ser usados para se certificar de que não existem diferenças entre eles. Cada canal usa um configmap separado para a configuração, pelo que a consolidação de dois canais num só deve garantir um comportamento consistente entre os dois canais.kubectl get configmap istio-asm-managed{-rapid | -stable} -n istio-system -o yaml
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

    Substitua NAMESPACE pelo nome do seu espaço de nomes.

    A prática recomendada é usar istio-injection=enabled. No entanto, se não quiser usar essa etiqueta, também pode usar istio.io/rev=RELEASE_CHANNEL.

    Depois de alterar a etiqueta de um espaço de nomes / pod, tem de reiniciar todas as cargas de trabalho para que sejam injetadas pelo plano de controlo correto.

Remova os canais adicionais

Depois de verificar que todas as cargas de trabalho estão a ser executadas num único canal, pode remover os canais adicionais não usados. Se os três canais de lançamento foram aprovisionados, lembre-se de executar os seguintes comandos para cada canal.

  1. Elimine o recurso ControlPlaneRevision adicional:

    kubectl delete controlplanerevision RELEASE_CHANNEL -n istio-system

    Substituir RELEASE_CHANNEL por asm-managed-stable, asm-managed ou asm-managed-rapid.

  2. Elimine o MutatingWebhookConfiguration:

    kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL

  3. Elimine o configmap meshconfig:

    kubectl delete configmap istio-RELEASE_CHANNEL

Ative a gestão automática

  1. Execute o seguinte comando para ativar a gestão automática:

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

    Substitua o seguinte:

    • MEMBERSHIP_NAME é o nome da associação apresentado quando validou que o seu cluster estava registado na frota.
    • PROJECT_ID é o ID do projeto.
    • MEMBERSHIP_LOCATION é a localização da sua subscrição (uma região ou global). Pode verificar a localização da sua subscrição com gcloud container fleet memberships list --project PROJECT_ID.

  2. Verifique se a gestão automática está ativada:

    gcloud container fleet mesh describe

    O resultado é semelhante ao seguinte:

    ...
membershipSpecs:
  projects/.../locations/us-central1/memberships/my-member:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/.../locations/us-central1/memberships/my-member:
    servicemesh:
      conditions:
      - code: VPCSC_GA_SUPPORTED
        details: This control plane supports VPC-SC GA.
        documentationLink: http://cloud.google.com/service-mesh/docs/managed/vpc-sc
        severity: INFO
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        implementation: TRAFFIC_DIRECTOR
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision ready for use: asm-managed.
        All Canonical Services have been reconciled successfully.
...