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

Este documento descreve as atualizações de configuração que talvez sejam necessárias para o Cloud Service Mesh gerenciado antes de modernizar sua malha para o plano de controle TRAFFIC_DIRECTOR do plano de controle ISTIOD.

Confira abaixo uma lista de possíveis atualizações de configuração necessárias para preparar seu cluster para modernização. Consulte cada seção para conferir 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 controle gerenciado.

Migrar de chaves secretas do Istio para multicluster_mode

Os secrets de vários clusters não são compatíveis quando um cluster usa o plano de controle TRAFFIC_DIRECTOR. Neste documento, descrevemos como modernizar o uso de secrets de vários clusters do Istio para multicluster_mode.

Visão geral das chaves secretas do Istio x API declarativa

A descoberta de endpoints multi-cluster do Istio de código aberto funciona usando istioctl ou outras ferramentas para criar um secret do Kubernetes em um cluster. Esse secret permite que um cluster faça o balanceamento de carga do tráfego para outro cluster na malha. O plano de controle do ISTIOD lê esse secret e começa a rotear o tráfego para o outro cluster.

O Cloud Service Mesh tem uma API declarativa para controlar o tráfego entre vários clusters em vez de criar segredos do Istio diretamente. Essa API trata os secrets do Istio como um detalhe de implementação e é mais confiável do que criar secrets do Istio manualmente. Os futuros recursos do Cloud Service Mesh vão depender da API declarativa, e não será possível usar esses novos recursos diretamente com os secrets do Istio. A API declarativa é o único caminho compatível.

Se você estiver usando secrets do Istio, migre para a API declarativa assim que possível. A configuração multicluster_mode direciona cada cluster para direcionar o tráfego a todos os outros clusters na malha. O uso de secrets permite uma configuração mais flexível, permitindo que você configure para cada cluster qual outro cluster ele deve direcionar o tráfego na malha. Para uma lista completa das diferenças entre os recursos compatíveis da API declarativa e os secrets do Istio, consulte Recursos compatíveis usando APIs do Istio.

Migrar de chaves secretas do Istio para a API declarativa

Se você provisionou o Cloud Service Mesh usando o gerenciamento automático com a API de recursos da frota, não é necessário seguir estas instruções. Estas etapas só se aplicam se você fez a integração usando asmcli --managed.

Observação: esse processo muda os secrets que apontam para um cluster. Durante esse processo, os endpoints são removidos e adicionados novamente. Entre a remoção e a adição dos endpoints, o tráfego vai voltar brevemente ao roteamento local em vez do balanceamento de carga para outros clusters. Para mais informações, consulte o problema no GitHub (em inglês).

Para migrar do uso de segredos do Istio para a API declarativa, siga estas etapas. Execute estas etapas ao mesmo tempo ou em seguida:

  1. Ative a API declarativa para cada cluster na frota em que você quer ativar a descoberta de endpoints de vários clusters definindo multicluster_mode=connected. É necessário definir explicitamente multicluster_mode=disconnected se você não quiser que o cluster seja detectável.

    Use o comando a seguir para ativar um cluster para descoberta de endpoints de vários clusters:

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

    Use o comando a seguir para desativar a descoberta de endpoints em um cluster:

     kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
    
  2. Exclua os secrets antigos.

    Depois de definir multicluster_mode=connected nos clusters, cada um deles terá um novo secret gerado para todos os outros que também tiverem multicluster_mode=connected definido. O secret é colocado no namespace istio-system e tem o seguinte formato:

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

    Cada secret também terá o rótulo istio.io/owned-by: mesh.googleapis.com aplicado.

    Depois que os novos secrets forem criados, você poderá excluir manualmente os secrets criados com istioctl create-remote-secret:

    kubectl delete secret SECRET_NAME -n istio-system
    

Depois da migração, verifique as métricas de solicitação para garantir que elas sejam encaminhadas conforme o esperado.

Ativar a federação de identidade da carga de trabalho do GKE

A federação de identidade da carga de trabalho é o método seguro recomendado para cargas de trabalho do Google Kubernetes Engine. Isso permite o acesso a serviços Google Cloud como Compute Engine, BigQuery e APIs de machine learning. A federação de identidade da carga de trabalho não exige configuração manual ou métodos menos seguros, como arquivos de chave da conta de serviço, porque usa políticas do IAM. Para mais detalhes sobre a federação de identidade da carga de trabalho, consulte Como funciona a federação de identidade da carga de trabalho para o GKE.

A seção a seguir descreve como ativar a federação de identidade da carga de trabalho.

Ativar a Federação de Identidade da Carga de Trabalho em clusters

  1. Verifique se a federação de identidade da carga de trabalho está ativada no cluster. Para isso, verifique se o cluster do GKE tem um pool de federação de identidade da carga de trabalho configurado, o que é essencial para a validação de credenciais do IAM.

    Use o comando a seguir para verificar o pool de identidades da carga de trabalho definido para um cluster:

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

    Substitua CLUSTER_NAME pelo nome do cluster do GKE. Se você ainda não tiver especificado uma zona ou região padrão para o gcloud, talvez seja necessário especificar uma flag --region ou --zone ao executar este comando.

  2. Se a saída estiver vazia, siga as instruções em Atualizar um cluster atual para ativar a identidade da carga de trabalho em clusters do GKE.

Ativar a federação de identidade da carga de trabalho em pools de nós

Depois que a federação de identidade da carga de trabalho é ativada em um cluster, os pools de nós precisam ser configurados para usar o servidor de metadados do GKE.

  1. Liste todos os pools 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 cluster do GKE. Se você ainda não tiver especificado uma zona ou região padrão para o gcloud, talvez seja necessário especificar uma flag --region ou --zone ao executar este comando.

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

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

    Substitua:

    • NODEPOOL_NAME pelo nome do pool de nós.
    • CLUSTER_NAME pelo nome do cluster do GKE.
  3. Se a saída não contiver GKE_METADATA, atualize o pool de nós usando o guia Atualizar um pool de nós.

Ativar a interface de rede de contêiner gerenciada (CNI)

Nesta seção, mostramos como ativar a CNI gerenciada para o Cloud Service Mesh no Google Kubernetes Engine.

Visão geral da CNI gerenciada

A interface de rede de contêiner gerenciada (CNI) é uma implementação gerenciada pelo Google da CNI do Istio. O plug-in CNI simplifica a rede de pods ao configurar regras de iptables. Isso permite o redirecionamento de tráfego entre aplicativos e proxies Envoy, eliminando a necessidade de permissões privilegiadas para o init-container necessário para gerenciar iptables.

O plug-in CNI do Istio substitui o contêiner istio-init. Antes, o contêiner istio-init era responsável por configurar o ambiente de rede do pod para permitir a interceptação de tráfego para o arquivo secundário do Istio. O plug-in CNI executa a mesma função de redirecionamento de rede, mas com o benefício adicional de reduzir a necessidade de privilégios elevados, aumentando assim a segurança.

Portanto, para aumentar a segurança e a confiabilidade e simplificar o gerenciamento e a solução de problemas, a CNI gerenciada é necessária em todas as implantações do Managed Cloud Service Mesh.

Impacto nos contêineres de inicialização

Os contêineres de inicialização são contêineres especializados que são executados antes dos contêineres de aplicativos para tarefas de configuração. As tarefas de configuração podem incluir o download de arquivos de configuração, a comunicação com serviços externos ou a inicialização pré-aplicativo. Os contêineres de inicialização que dependem do acesso à rede podem encontrar problemas quando a CNI gerenciada está ativada no cluster.

O processo de configuração de pods com CNI gerenciada é o seguinte:

  1. O plug-in da CNI configura interfaces de rede de pod, atribui IPs de pod e redireciona o tráfego para o proxy sidecar do Istio, que ainda não foi iniciado.
  2. Todos os contêineres de inicialização são executados e concluídos.
  3. O proxy sidecar do Istio é iniciado junto com os contêineres de aplicativos.

Portanto, se um contêiner de inicialização tentar fazer conexões de rede de saída ou se conectar a serviços na malha, as solicitações de rede dos contêineres de inicialização poderão ser descartadas ou encaminhadas incorretamente. Isso acontece porque o proxy sidecar do Istio, que gerencia o tráfego de rede do pod, não está em execução quando as solicitações são feitas. Para mais detalhes, consulte a documentação do CNI do Istio.

Ative a CNI gerenciada para o cluster

Siga as etapas desta seção para ativar o CNI gerenciado no cluster.

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

    • Modificar a lógica ou os contêineres do aplicativo:é possível modificar os serviços para remover a dependência de contêineres de inicialização que exigem solicitações de rede ou realizar operações de rede nos contêineres de aplicativos depois que o proxy sidecar for iniciado.
    • Use ConfigMaps ou secrets do Kubernetes:armazene os dados de configuração buscados pela solicitação de rede em ConfigMaps ou secrets do Kubernetes e os monte nos contêineres de aplicativos. Para soluções alternativas, consulte a documentação do Istio.
  2. Ative a CNI gerenciada no cluster:

    1. Faça as seguintes mudanças de configuração:

      1. Execute o comando a seguir para localizar o controlPlaneRevision.

        kubectl get controlplanerevision -n istio-system
        
      2. No recurso personalizado (CR) ControlPlaneRevision (CPR), defina o rótulo 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" da saída da etapa 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 o rótulo mesh.cloud.google.com/force-reprovision como true. Essa ação aciona a reinicialização do plano de controle.

        kubectl label controlplanerevision CPR_NAME \
            -n istio-system mesh.cloud.google.com/force-reprovision=true \
            --overwrite
        
    2. Verifique o estado do recurso. Recupere o estado do recurso usando o seguinte comando:

      gcloud container fleet mesh describe --project FLEET_PROJECT_ID
      

      Substitua FLEET_PROJECT_ID pelo ID do projeto host da frota. Em geral, o FLEET_PROJECT_ID tem o mesmo nome do projeto.

      • Verifique se a condição MANAGED_CNI_NOT_ENABLED foi removida de servicemesh.conditions.
      • A atualização do estado pode levar de 15 a 20 minutos. Aguarde alguns minutos e execute o comando novamente.
    3. Quando o controlPlaneManagement.state estiver Active no estado do recurso do cluster, reinicie os pods.

Migrar do uso de binários não padrão no sidecar

Esta seção sugere maneiras de tornar suas implantações compatíveis com a imagem de proxy do Envoy sem distribuição.

Imagens de arquivo secundário do proxy Envoy distroless

O Cloud Service Mesh usa dois tipos de imagens secundárias de proxy do Envoy com base na sua configuração do plano de controle, uma imagem baseada no Ubuntu que contém vários binários e uma imagem sem distribuição. As imagens de base sem escala são imagens de contêiner mínimas que priorizam a segurança e a otimização de recursos, incluindo apenas 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 sem distribuição.

Compatibilidade binária

Como prática recomendada, restrinja o conteúdo de um ambiente de execução do contêiner apenas aos pacotes necessários. Essa abordagem melhora a segurança e a proporção de sinal para ruído dos verificadores de vulnerabilidades e exposições comuns (CVEs, na sigla em inglês). 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. Portanto, não é possível executar um comando de shell ou usar curl, ping ou outros utilitários de depuração, como kubectl exec, no contêiner.

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

  • Remova referências a binários sem suporte (como bash ou curl) da sua configuração. Principalmente dentro das sondagens de prontidão, inicialização e atividade e dos hooks PostStart e PreStop do ciclo de vida nos contêineres istio-proxy, istio-init ou istio-validation.
  • Considere alternativas como holdApplicationUntilProxyStarts para determinados casos de uso.
  • Para depuração, é possível usar contêineres temporários para anexar a um pod de carga de trabalho em execução. Depois, é possível inspecionar e executar comandos personalizados. Por exemplo, consulte Como coletar registros do Cloud Service Mesh.

Se você não encontrar uma solução para seu caso de uso específico, entre em contato com o suporte em Como receber suporte. Google Cloud

Migrar para o gateway de entrada do Istio

Nesta seção, mostramos como migrar para o gateway de entrada do Istio. Há dois métodos para migrar para o gateway de entrada do Istio:

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

    Esse método prioriza a minimização da interrupção, em que você envia o tráfego de forma incremental para o novo gateway do Istio, permitindo monitorar o desempenho em uma pequena porcentagem de solicitações e reverter rapidamente, se necessário. Configurar a divisão de tráfego da camada 7 pode ser difícil para alguns aplicativos. Por isso, é necessário gerenciar os dois sistemas de gateway simultaneamente durante a transição. Consulte Migração gradual com divisão de tráfego para conferir as etapas.

  2. Migração direta

    Esse método envolve o redirecionamento simultâneo de todo o tráfego para o novo gateway do Istio depois que você tiver realizado testes completos. A vantagem dessa abordagem é a separação completa da infraestrutura do gateway antigo, permitindo uma configuração adaptável do novo gateway sem as restrições da configuração atual. No entanto, há um risco maior de inatividade caso surjam problemas inesperados com o novo gateway durante a transição. Consulte Migração direta para conferir as etapas.

Os exemplos de migração a seguir pressupõem que você tenha um serviço HTTP (httpbin) em execução no namespace do aplicativo (padrão) e exposto externamente usando a API Gateway do Kubernetes. As configurações relevantes são:

  • Gateway: k8-api-gateway (no namespace istio-ingress) – configurado para detectar tráfego HTTP na porta 80 para qualquer nome de host que termine com .example.com.
  • HTTPRoute: httpbin-route (no namespace default): direciona qualquer solicitação HTTP com o nome do host httpbin.example.com e um caminho que começa com /get para o serviço httpbin no namespace default.
  • O aplicativo httpbin pode ser acessado usando o IP externo 34.57.246.68.

Diagrama básico do gateway

Migração por etapas com divisão de tráfego

Provisionar um novo gateway de entrada do Istio

  1. Implante um novo gateway de entrada seguindo as etapas na seção "Implantar gateway de exemplo" e personalize as configurações de exemplo de acordo com seus requisitos. As amostras no repositório anthos-service-mesh (em inglês) são destinadas à implantaçã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 do Gateway para gerenciar o tráfego:

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

    Verifique se o "spec.selector" no recurso de gateway corresponde aos rótulos dos pods ingress-gateway. Por exemplo, se os pods ingress-gateway tiverem o rótulo istio=ingressgateway, a configuração do gateway também precisará selecionar o rótulo istio=ingressgateway.

Configurar o roteamento inicial para o novo gateway

  1. Defina as regras de roteamento iniciais para seu aplicativo usando 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
    

Acesse o serviço de back-end (httpbin) pelo gateway de entrada do Istio recém-implantado.

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

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    
  2. Verifique se o aplicativo (httpbin) pode ser acessado usando o novo gateway:

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

    A saída é semelhante a:

    HTTP/1.1 200 OK
    

Fluxo de solicitação com o novo gateway de entrada do Istio

Modificar Entrada atual para divisão de tráfego

Depois de confirmar a configuração bem-sucedida do novo gateway (por exemplo, istio-api-gateway), comece a rotear uma parte do tráfego por ele. Para fazer isso, atualize sua HTTPRoute atual para direcionar uma pequena porcentagem do tráfego ao novo gateway, enquanto a maior parte continua usando o gateway atual (k8-api-gateway).

  1. Abra o httproute para edição:

    kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE
    
  2. Adicione uma nova referência de back-end apontando para o serviço de balanceador de carga do novo 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. Conceder permissão para referências entre namespaces com concessão de referência.

    Para permitir que seu HTTPRoute no namespace do aplicativo (padrão) acesse o serviço loadbalancer no namespace do gateway (istio-ingress), talvez seja necessário criar uma permissão de referência. Esse recurso serve como um controle de segurança, definindo explicitamente quais referências entre namespaces são permitidas.

    O istio-ingress-grant.yaml a seguir descreve um exemplo de 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 concessão de referência:

    kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE
    
  5. Verifique as solicitações para o endereço IP externo atual (por exemplo, 34.57.246.68) não estão falhando. O check-traffic-flow.sh a seguir descreve um script para verificar falhas de solicitação:

    # 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 nenhuma solicitação falha, independente da rota de tráfego:

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

Fluxo de solicitação com divisão de tráfego entre o gateway atual e o novo gateway de entrada do Istio

Aumentar lentamente a porcentagem de tráfego

Se não houver falhas de solicitação para o endereço IP externo atual (por exemplo, 34.57.246.68), transfira gradualmente mais tráfego para o novo gateway de entrada do Istio ajustando os pesos de back-end em HTTPRoute. Aumente o peso do istio-ingressgateway e diminua o peso do gateway antigo em pequenos incrementos, como 10%, 20% e assim por diante.

Use o comando a seguir para atualizar seu HTTPRoute:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

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

  1. Quando o novo gateway de entrada do Istio demonstrar performance estável e processamento de solicitações bem-sucedido, transfira todo o tráfego para ele. Atualize seu HTTPRoute para definir o peso do back-end do gateway antigo como 0 e o do novo como 100.

  2. Quando o tráfego for totalmente roteado para o novo gateway, atualize os registros DNS externos para o nome do host do aplicativo (por exemplo, httpbin.example.com) para apontar para o endereço IP externo do serviço de balanceador de carga criado em Provisionar um novo gateway de entrada do Istio.

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

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

Migração direta

Provisionar um novo gateway de entrada do Istio

  1. Implante um novo gateway de entrada seguindo as etapas na seção "Implantar gateway de exemplo" e personalize as configurações de exemplo de acordo com seus requisitos. As amostras no repositório anthos-service-mesh (em inglês) são destinadas à implantaçã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 do Gateway para gerenciar o tráfego:

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

    Verifique se o "spec.selector" no recurso de gateway corresponde aos rótulos dos pods ingress-gateway. Por exemplo, se os pods ingress-gateway tiverem o rótulo istio=ingressgateway, a configuração do gateway também precisará selecionar o rótulo istio=ingressgateway.

Configurar o roteamento inicial para o novo gateway

  1. Defina as regras de roteamento iniciais para seu aplicativo usando 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
    

Acesse o serviço de back-end (httpbin) pelo gateway de entrada do Istio recém-implantado.

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

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
    
  2. Verifique se o aplicativo (httpbin) pode ser acessado usando o novo gateway:

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

    A saída é semelhante a:

    HTTP/1.1 200 OK
    

Fluxo de solicitação com o novo gateway de entrada do Istio

Testar e monitorar o novo gateway

  1. Teste todas as regras de roteamento, valide a configuração de TLS, as políticas de segurança e outros recursos. Realize testes de carga para verificar se o novo gateway consegue processar o tráfego esperado.

  2. Depois que o novo gateway for totalmente testado, atualize os registros DNS externos para o nome do host do aplicativo (por exemplo, httpbin.example.com) para apontar para o endereço IP externo do serviço de balanceador de carga criado em Provisionar um novo gateway de entrada do Istio.

  3. Monitore as principais métricas, como taxa de sucesso de solicitações, latência, taxas de erro e a utilização de recursos dos pods de aplicativos para verificar a estabilidade com o novo Istio Ingress Gateway. Quando estiver estável, você poderá excluir o gateway antigo e os recursos associados a ele.

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

Considerações importantes: verifique se os certificados e as configurações TLS estão configurados corretamente no novo gateway de entrada do Istio se o aplicativo exigir HTTPS. Consulte Configurar o término de TLS no gateway de entrada para mais detalhes.