O Cloud Service Mesh e o Traffic Director agora são Cloud Service Mesh. Para mais informações, consulte a Visão geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

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:

Multi-cluster
Ativar a federação de identidade da carga de trabalho para o GKE
Ativar a CNI gerenciada
Uso binário não padrão no sidecar
Migrar para o Istio Ingress Gateway

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:

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"}}'
```
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

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

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

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.
Todos os contêineres de inicialização são executados e concluídos.
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.

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.
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.
    
    Observação: esse não é o método recomendado para reiniciar o plano de controle e só deve ser usado em esforços de modernização do Cloud Service Mesh.
```
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:

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

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"

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

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

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.

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}')
```
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).

Abra o httproute para edição:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

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

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

Aplique a concessão de referência:

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

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

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

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

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