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 você precise fazer no Cloud Service Mesh gerenciado antes de modernizar a malha para o plano de controle TRAFFIC_DIRECTOR do plano de controle ISTIOD.

Confira a seguir uma lista de possíveis atualizações de configuração necessárias para preparar seu cluster para a modernização. Consulte as instruções de atualização em cada seção:

Vários clusters
Ativar a Federação de Identidade da Carga de Trabalho para o GKE
Ativar a CNI gerenciada
Uso de binários 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

Não há suporte para secrets de vários clusters quando um cluster está usando o plano de controle TRAFFIC_DIRECTOR. Este documento descreve como modernizar o uso de segredos de vários clusters do Istio para multicluster_mode.

Visão geral das chaves secretas do Istio e das APIs declarativas

A descoberta de endpoints de multicluster do Istio de código aberto funciona usando istioctl ou outras ferramentas para criar um secreto do Kubernetes em um cluster. Esse segredo permite que um cluster balanceie a carga de tráfego para outro cluster na malha. O plano de controle ISTIOD lê esse secret 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 segredos do Istio diretamente. Essa API considera os segredos do Istio como um detalhe de implementação e é mais confiável do que a criação manual de segredos do Istio. Os recursos futuros do Cloud Service Mesh vão depender da API declarativa, e não será possível usar esses novos recursos com segredos do Istio diretamente. A API declarativa é o único caminho com suporte.

Se você estiver usando o Istio Secrets, migre para a API declarativa o mais rápido 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 segredos 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 segredos do Istio, consulte Recursos compatíveis com as 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 precisa seguir estas instruções. Estas etapas só se aplicam se você fez a integração usando asmcli --managed.

Esse processo muda os segredos que apontam para um cluster. Durante esse processo, os endpoints são removidos e adicionados novamente. Entre os endpoints que estão sendo removidos e adicionados, o tráfego vai reverter brevemente para o roteamento local em vez de balanceamento de carga para outros clusters. Para mais informações, consulte o problema do GitHub.

Para mudar do uso de segredos do Istio para a API declarativa, siga estas etapas. Siga estas etapas ao mesmo tempo ou em sucessão:

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 a 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 secrets antigos.

Depois de definir multicluster_mode=connected nos clusters, cada cluster terá um novo segredo gerado para todos os outros clusters 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 segredo também terá o rótulo istio.io/owned-by: mesh.googleapis.com.

Depois que os novos secrets forem criados, você poderá excluir os criados manualmente com istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Após a migração, verifique as métricas de solicitação para garantir que elas sejam roteadas corretamente.

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 Google Cloud serviços como o Compute Engine, o BigQuery e as 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 de 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 fazer isso, verifique se o cluster do GKE tem um conjunto de pools 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 conjunto de pool de identidade de carga de trabalho de 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 for 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 padrão. 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 atual.

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

Esta seção orienta você a ativar o CNI gerenciado 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 do iptables. Isso permite a redirecionamento de tráfego entre aplicativos e proxies do Envoy, eliminando a necessidade de permissões privilegiadas para o init-container necessário para gerenciar iptables.

O plug-in da CNI do Istio substitui o contêiner istio-init. O contêiner istio-init era anteriormente responsável por configurar o ambiente de rede do pod para permitir a interceptação de tráfego do sidecar 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, melhorando a segurança.

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

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 do aplicativo 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 antes do aplicativo. Contêineres de inicialização que dependem do acesso à rede podem encontrar problemas quando a CNI gerenciada é ativada no cluster.

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

O plug-in da CNI configura interfaces de rede do pod, atribui IPs do 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 do aplicativo.

Portanto, se um contêiner inicializado 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 inicializados poderão ser descartadas ou redirecionadas. Isso ocorre porque o proxy do 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 Istio CNI.

Ativar a CNI gerenciada para o cluster

Siga as etapas desta seção para ativar a CNI gerenciada 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 seus 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 do aplicativo depois que o proxy sidecar for iniciado.
- Usar 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 do aplicativo. 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 método não é o recomendado para reiniciar o plano de controle e só deve ser usado para 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. Extraia 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. Geralmente, o FLEET_PROJECT_ID tem o mesmo nome do projeto.
  - Verifique se a condição MANAGED_CNI_NOT_ENABLED foi removida de servicemesh.conditions.
  - Pode levar de 15 a 20 minutos para que o estado seja atualizado. Aguarde alguns minutos e execute o comando novamente.
3. Quando o controlPlaneManagement.state estiver Active no estado de recurso do cluster, reinicie os pods.

Descontinuar o 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 do proxy do Envoy distroless.

Imagens de sidecar do proxy Envoy distroless

O Cloud Service Mesh usa dois tipos de imagens de sidecar de proxy do Envoy com base na configuração do plano de controle, imagem baseada no Ubuntu que contém vários binários e imagem distroless. As imagens de base distroless 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 do proxy do Distroless.

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 Distroless Sidecar 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 dentro do contêiner.

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

Remova da configuração as referências a binários sem suporte, como bash ou curl. Especificamente nas sondagens de prontidão, inicialização e atividade , e nos hooks de pós-início e pré-parada 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, use contêineres temporários para se conectar a um pod de carga de trabalho em execução. Em seguida, você pode inspecionar e executar comandos personalizados. Para conferir um 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 Google Cloud em Como receber suporte.

Migrar para o gateway de entrada do Istio

Esta seção mostra como migrar para o Istio Ingress Gateway. 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 de interrupções, em que você vai enviar tráfego incrementalmente para o novo gateway do Istio, permitindo monitorar o desempenho em uma pequena porcentagem de solicitações e reverter rapidamente, se necessário. Lembre-se de que configurar a divisão de tráfego da camada 7 pode ser desafiador para alguns aplicativos. Portanto, é necessário gerenciar os dois sistemas de gateway simultaneamente durante a transição. Consulte Migração por fases com divisão de tráfego para conferir as etapas.
Migração direta

Esse método envolve redirecionar simultaneamente todo o tráfego para o novo gateway do Istio depois de realizar testes completos. A vantagem dessa abordagem é a separação completa da infraestrutura do gateway antigo, permitindo a configuração adaptável do novo gateway sem as restrições da configuração atual. No entanto, há um aumento do risco de inatividade caso surjam problemas inesperados com o novo gateway durante a transição. Consulte as etapas em Migração direta.

Os exemplos de migração a seguir presumem que você tenha um serviço HTTP (httpbin) em execução no namespace do aplicativo (padrão) e exposto externamente usando a API Kubernetes Gateway. 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 de 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. Os exemplos no repositório anthos-service-mesh são destinados a implantar um serviço istio-ingressgateway loadBalancer e os 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 do 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 esse rótulo istio=ingressgateway.

Configurar o roteamento inicial para o novo gateway

Defina as regras de roteamento iniciais do 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 do host de entrada 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ções com o novo gateway de entrada do Istio

Modificar Entrada existente para a divisão de tráfego

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

Abra a httproute para edição:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Adicione uma nova referência de back-end que aponte 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ência entre namespaces com concessão de referência.

Para permitir que o HTTPRoute no namespace do aplicativo (padrão) acesse o serviço loadbalancer no namespace do gateway (istio-ingress), talvez seja necessário criar uma concessã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 (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, independentemente do caminho 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

Aumente lentamente a porcentagem de tráfego

Se não houver falhas de solicitação no 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 do back-end no HTTPRoute. Aumente o peso do istio-ingressgateway e diminua o peso do antigo gateway em pequenos incrementos, como 10%, 20% e assim por diante.

Use o comando a seguir para atualizar o 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 desempenho estável e processamento de solicitações bem-sucedido, desloque todo o tráfego para ele. Atualize o HTTPRoute para definir o peso do back-end do gateway antigo como 0 e o do novo gateway como 100.
Depois que o tráfego for totalmente roteado para o novo gateway, atualize os registros DNS externos do 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