Recursos compatíveis usando APIs do Istio (plano de controle gerenciado)

Nesta página, descrevemos os recursos e as limitações compatíveis com o Cloud Service Mesh usando TRAFFIC_DIRECTOR ou ISTIOD como o plano de controle e as diferenças entre cada implementação. Essas não são opções que você pode escolher. A implementação de ISTIOD está disponível apenas para usuários atuais. As novas instalações usam a implementação TRAFFIC_DIRECTOR sempre que possível.

Para conferir a lista de recursos compatíveis com o Cloud Service Mesh para um plano de controle no cluster, consulte Usar APIs do Istio (plano de controle istiod no cluster). Se você não souber qual plano de controle do Cloud Service Mesh está usando, confira a implementação do plano de controle usando as instruções em Identificar a implementação do plano de controle.

Limitações

Considere as seguintes limitações:

  • Os clusters do GKE precisam estar em uma das regiões compatíveis.
  • A versão do GKE precisa ser uma versão compatível.
  • Apenas as plataformas listadas em Ambientes são compatíveis.
  • Não é possível alterar canais de lançamento.
  • As migrações do Cloud Service Mesh gerenciado com asmcli para o Cloud Service Mesh com a API Fleet não são compatíveis. Da mesma forma, não é possível provisionar o Cloud Service Mesh gerenciado com a API Fleet de --management manual para --management automatic.
  • As migrações e os upgrades são compatíveis apenas com as versões 1.9 ou mais recentes do Cloud Service Mesh no cluster instaladas com a CA do Mesh. As instalações com a CA do Istio (antes conhecida como Citadel) precisam migrar para a CA da malha.
  • A escala é limitada a 1.000 serviços e 5.000 cargas de trabalho por cluster.
  • Apenas a opção de implantação multiprimária para vários clusters é compatível: a opção de implantação primária remota para vários clusters não é.
  • istioctl ps não é compatível. Em vez disso, use os comandos gcloud beta container fleet mesh debug, conforme descrito em Solução de problemas.
  • APIs sem suporte:

    • API EnvoyFilter

    • API WasmPlugin

    • API IstioOperator

    • API Kubernetes Ingress

  • É possível usar o plano de controle gerenciado sem uma assinatura do GKE Enterprise, mas alguns elementos e recursos da UI no console do Google Cloud estão disponíveis apenas para assinantes do GKE Enterprise. Para informações sobre o que está disponível para assinantes e não assinantes, consulte Diferenças na interface do GKE Enterprise e do Cloud Service Mesh.

  • Durante o processo de provisionamento de um plano de controle gerenciado, os CRDs do Istio correspondentes ao canal selecionado são instalados no cluster especificado. Se houver CRDs atuais do Istio no cluster, eles serão substituídos.

  • O Cloud Service Mesh gerenciado só oferece suporte ao domínio DNS padrão .cluster.local.

  • A partir de 14 de novembro de 2023, novas instalações do Cloud Service Mesh gerenciado no canal de lançamento rápido vão buscar JWKS apenas usando Envoys. Isso é equivalente à opção PILOT_JWT_ENABLE_REMOTE_JWKS=envoy do Istio. Em comparação com as instalações nos canais de lançamento regular e estável ou nas instalações no canal de lançamento rápido antes de 14 de novembro de 2023, talvez seja necessário fazer mais configurações de ServiceEntry e DestinationRule. Para conferir um exemplo, consulte requestauthn-with-se.yaml.tmpl.

Diferenças do plano de controle

Há diferenças nos recursos compatíveis entre as implementações do plano de controle ISTIOD e TRAFFIC_DIRECTOR. Para verificar qual implementação você está usando, consulte Identificar a implementação do plano de controle.

  • : indica que o recurso está disponível e ativado por padrão.
  • †: indica que as APIs de recursos podem ter diferenças entre várias plataformas.
  • *: indica que o recurso é compatível com a plataforma e pode ser ativado, conforme descrito em Ativar recursos opcionais ou no guia de recurso vinculado à tabela de recursos.
  • §: indica que o recurso tem suporte da lista de permissões. Os usuários anteriores do Anthos Service Mesh gerenciado são automaticamente incluídos na lista de permissões no nível da organização. Entre em contato com o suporte do Google Cloud para solicitar acesso ou verificar o status da lista de permissões.
  • : indica que o recurso não está disponível ou é incompatível.

Os recursos padrão e opcionais são totalmente compatíveis com o suporte do Google Cloud. Recursos não listados explicitamente nas tabelas recebem suporte de melhor esforço.

O que determina a implementação do plano de controle

Quando você provisiona o Cloud Service Mesh gerenciado pela primeira vez em uma frota, determinamos qual implementação do plano de controle usar. A mesma implementação é usada para todos os clusters que provisionam o Cloud Service Mesh gerenciado nessa frota.

As novas frotas que são integradas ao Cloud Service Mesh gerenciado recebem a implementação do plano de controle TRAFFIC_DIRECTOR, com algumas exceções:

  • Se você já for usuário do Cloud Service Mesh gerenciado, vai receber a implementação do plano de controle ISTIOD ao integrar uma nova frota na mesma organização do Google Cloud ao Cloud Service Mesh gerenciado, até pelo menos 30 de junho de 2024. Se você for um desses usuários, entre em contato com o suporte para ajustar esse comportamento. Os usuários cujo uso atual não é compatível com a implementação da TRAFFIC_DIRECTOR sem alterações vão continuar recebendo a implementação da ISTIOD até 8 de setembro de 2024. Esses usuários receberam um anúncio de serviço.
  • Se algum cluster na sua frota usar Certificate Authority Service ao provisionar o Cloud Service Mesh gerenciado, você vai receber a implementação do plano de controle ISTIOD.
  • Se algum cluster da sua frota tiver um plano de controle do Cloud Service Mesh no cluster quando você provisionar o Cloud Service Mesh gerenciado, você vai receber a implementação do plano de controle ISTIOD.
  • Se algum cluster na sua frota usar o sandbox do GKE, ao provisionar o Cloud Service Mesh gerenciado, você vai receber a implementação do plano de controle ISTIOD.

Recursos compatíveis do plano de controle gerenciado

Instalar, fazer upgrade e reverter

Recurso Gerenciado (TD) Gerenciado (istiod)
Instalação em clusters do GKE usando a API do recurso frota
Atualizações das versões ASM 1.9 que usam o Mesh CA
Upgrades diretos (pular nível) das versões do Cloud Service Mesh anteriores à 1.9 (consulte as observações para upgrades indiretos)
Upgrades diretos (pular nível) do Istio OSS (consulte as observações para upgrades indiretos)
Upgrades diretos (pular nível) do complemento Istio-on-GKE (consulte as observações para upgrades indiretos)
Como ativar recursos opcionais

Ambientes

Recurso Gerenciado (TD) Gerenciado (istiod)
GKE 1.25 a 1.27 em uma das regiões suportadas
Clusters 1.25 a 1.27 do GKE com Autopilot
Ambientes fora do Google Cloud (GKE Enterprise no local, GKE Enterprise em outras nuvens públicas, Amazon EKS, Microsoft AKS ou outros clusters do Kubernetes)

Escala

Recurso Gerenciado (TD) Gerenciado (istiod)
1.000 serviços e 5.000 cargas de trabalho por cluster
50 portas de serviço sem comando por malha e 36 pods por porta de serviço sem comando

Ambiente de plataforma

Recurso Gerenciado (TD) Gerenciado (istiod)
Rede única
Várias redes
Projeto único
Vários projetos com VPC compartilhada

Implantação de vários clusters

Recurso Gerenciado (TD) Gerenciado (istiod)
Modo multiprimário
Principal controle remoto
Descoberta de endpoints em vários clusters com a API declarativa
Descoberta de endpoints de vários clusters com segredos remotos

Observações sobre a terminologia

  • Uma configuração multiprimária significa que a configuração precisa ser replicada em todos os clusters.
  • Uma configuração primária remota significa que um único cluster contém a configuração e é considerado a fonte da verdade.
  • O Cloud Service Mesh usa uma definição simplificada de rede com base na conectividade geral. Instâncias de carga de trabalho ficam na mesma rede, se puderem se comunicar diretamente, sem um gateway.

Imagens de base

Recurso Gerenciado (TD) Gerenciado (istiod)
Imagem proxy distroless

† O Cloud Service Mesh com um plano de controle gerenciado (TD, na sigla em inglês) só oferece suporte ao tipo de imagem sem distribuição. Não é possível mudar isso.

As imagens distroless têm binários mínimos, então não é possível executar os comandos usuais, como bash ou curl, porque eles não estão presentes na imagem distroless. No entanto, é possível usar contêineres temporários para anexar a um pod de carga de trabalho em execução para inspecionar e executar comandos personalizados. Por exemplo, consulte Como coletar registros do Cloud Service Mesh.

Segurança

VPC Service Controls

Recurso Gerenciado (TD) Gerenciado (istiod)
Pré-lançamento do VPC Service Controls
GA do VPC Service Controls

Mecanismos de distribuição e rotação de certificados

Recurso Gerenciado (TD) Gerenciado (istiod)
Gerenciamento de certificados de carga de trabalho
Gerenciamento de certificados externos nos gateways de entrada e de saída.

Suporte para autoridade de certificação (CA)

Recurso Gerenciado (TD) Gerenciado (istiod)
Autoridade certificadora do Cloud Service Mesh
Certificate Authority Service
CA do Istio
Integração com CAs personalizadas

Recursos de segurança

Além de oferecer suporte aos recursos de segurança do Istio, o Cloud Service Mesh oferece ainda mais recursos para ajudar a proteger seus aplicativos.

Recurso Gerenciado (TD) Gerenciado (istiod)
Integração com o IAP
Autenticação de usuário final
Modo de teste
Registro de negação
Políticas de auditoria (sem suporte)

Política de autorização

Recurso Gerenciado (TD) Gerenciado (istiod)
Política de autorização v1beta1
Política de autorização PERSONALIZADA §

† A implementação do plano de controle TRAFFIC_DIRECTOR não oferece suporte aos campos rules.from.source.RemoteIp e rules.from.source.NotRemoteIp.

Autenticação de mesmo nível

Recurso Gerenciado (TD) Gerenciado (istiod)
Auto-mTLS
Modo mTLS PERMISSIVE
Modo mTLS STRICT * *
Modo mTLS DISABLE

Autenticação de solicitações

Recurso Gerenciado (TD) Gerenciado (istiod)
Autenticação JWT(Observação 1)
Roteamento com base em declarações JWT
JWT Copy Claim to Headers

Observações:

  1. O JWT de terceiros é ativado por padrão.
  2. Adicione o fqdn/nome de host completo no JWKSURI ao definir a API RequestAuthentication.
  3. O plano de controle gerenciado força o Envoy a buscar JWKS ao especificar o URI do JWKS.

Telemetria

Métrica

Recurso Gerenciado (TD) Gerenciado (istiod)
Cloud Monitoring (métricas HTTP no proxy)
Cloud Monitoring (métricas TCP no proxy)
Exportação de métricas do Prometheus para o Grafana (somente métricas do Envoy) * *
Exportação de métricas do Prometheus para o Kiali
Google Cloud Managed Service para Prometheus, sem incluir o painel do Cloud Service Mesh * *
API Istio Telemetry
Adaptadores/back-ends personalizados, dentro ou fora do processo
Back-ends de telemetria arbitrária e registro

† O plano de controle TRAFFIC_DIRECTOR oferece suporte a um subconjunto da API de telemetria do Istio usada para configurar registros de acesso e rastreamento.

Geração de registros de solicitação do proxy

Recurso Gerenciado (TD) Gerenciado (istiod)
Registros de tráfego
Registros de acesso * *

Cloud Trace

Recurso Gerenciado (TD) Gerenciado (istiod)
Cloud Trace * *
Rastreamento do Jaeger (permite o uso de Jaeger gerenciado pelo cliente) Compatível
Rastreamento de Zipkin (permite o uso de Zipkin gerenciado pelo cliente) Compatível

Rede

Mecanismos de interceptação e redirecionamento de tráfego

Recurso Gerenciado (TD) Gerenciado (istiod)
Uso tradicional de iptables usando contêineres init com CAP_NET_ADMIN
Interface de rede de contêineres do Istio (CNI, na sigla em inglês)
Sidecar de caixa baixa

Suporte a protocolo

Recurso Gerenciado (TD) Gerenciado (istiod)
IPv4
HTTP/1.1
HTTP/2
Streams de bytes TCP (Observação 1)
gRPC
IPv6

Observações:

  1. Embora o TCP seja um protocolo compatível com rede e as métricas TCP sejam coletadas, elas não são informadas. As métricas são exibidas apenas para serviços HTTP no console do Google Cloud.
  2. Os serviços configurados com os recursos de Camada 7 para os seguintes protocolos não são compatíveis: WebSocket, MongoDB, Redis, Kafka, Cassandra, RabbitMQ e Cloud SQL. É possível fazer o protocolo funcionar usando o suporte ao stream de bytes TCP. Se o fluxo de bytes TCP não for compatível com o protocolo, o protocolo não será compatível. Um exemplo disso é quando o Kafka envia um endereço de redirecionamento em uma resposta específica do protocolo e esse redirecionamento é incompatível com a lógica de roteamento do Cloud Service Mesh.

Implantações do Envoy

Recurso Gerenciado (TD) Gerenciado (istiod)
Sidecars
Gateway de entrada
Saída diretamente dos sidecars
Saída usando gateways de saída * *

Compatibilidade com CRD

Recurso Gerenciado (TD) Gerenciado (istiod)
Recurso de sidecar
Recurso de entrada de serviço
Porcentagem, injeção de falhas, correspondência de caminho, redirecionamentos, novas tentativas, regravação, tempo limite, repetição, espelhamento, manipulação de cabeçalho e regras de roteamento CORS
API "EnvoyFilter" §
API`WasmPlugin`
Operador do Istio

Balanceador de carga para o gateway de entrada do Istio

Recurso Gerenciado (TD) Gerenciado (istiod)
Balanceador de carga externo de terceiros
google-cloud-internal-load-balancer * *

Gateway da nuvem da malha de serviço

Recurso Gerenciado (TD) Gerenciado (istiod)
Gateway da nuvem da malha de serviço

API Kubernetes Gateway

Recurso Gerenciado (TD) Gerenciado (istiod)
API Kubernetes Gateway

Políticas de balanceamento de carga

Recurso Gerenciado (TD) Gerenciado (istiod)
Round-robin
Menos conexões
Aleatório
Passagem
Hash consistente
Localidade

Entrada de serviço

Recurso Gerenciado (TD) Gerenciado (istiod)
ServiceEntry v1beta1

† A implementação do plano de controle TRAFFIC_DIRECTOR não oferece suporte aos seguintes campos e valores em campos:

  • Campo workloadSelector
  • Campo endpoints[].network
  • Campo endpoints[].locality
  • Campo endpoints[].weight
  • Campo endpoints[].serviceAccount
  • Valor DNS_ROUND_ROBIN no campo resolution
  • Valor MESH_INTERNAL no campo location
  • Endereço de soquete de domínio Unix no campo endpoints[].address
  • Campo subjectAltNames

Regra de destino

Recurso Gerenciado (TD) Gerenciado (istiod)
DestinationRule v1beta1

† A implementação do plano de controle TRAFFIC_DIRECTOR não oferece suporte ao campo trafficPolicy.loadBalancer.localityLbSetting e ao campo trafficPolicy.tunnel. Além disso, a implementação do plano de controle TRAFFIC_DIRECTOR exige que a regra de destino que define subconjuntos esteja no mesmo namespace e cluster com o serviço do Kubernetes ou a ServiceEntry.

Arquivo secundário

Recurso Gerenciado (TD) Gerenciado (istiod)
Sidecar v1beta1

† A implementação do plano de controle TRAFFIC_DIRECTOR não oferece suporte aos seguintes campos e valores em campos:

  • Campo ingress
  • Campo egress.port
  • Campo egress.bind
  • Campo egress.captureMode
  • Campo inboundConnectionPool

MeshConfig

Recurso Gerenciado (TD) Gerenciado (istiod)
LocalityLB §
ExtensionProviders §
CACert
ImageType: distroless §
OutboundTrafficPolicy §
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver §
accessLogFile §

ProxyConfig

Recurso Gerenciado (TD) Gerenciado (istiod)
Proxy DNS (ISTIO_META_DNS_CAPTURE, ISTIO_META_DNS_AUTO_ALLOCATE)
Suporte a HTTP/1.0 (ISTIO_META_NETWORK)
Seleção de imagem (distroless ou imagem de base)

A imagem do DistroX é usada para a injeção.

Regiões

Os clusters do GKE precisam estar em uma das regiões ou em qualquer zona dentro das regiões a seguir.

Região Local
africa-south1 Johannesburgo
asia-east1 Taiwan
asia-east2 Hong Kong
asia-northeast1 Tóquio, Japão
asia-northeast2 Osaka, Japão
asia-northeast3 Coreia do Sul
asia-south1 Mumbai, Índia
asia-south2 Déli, Índia
asia-southeast1 Singapura
asia-southeast2 Jacarta
australia-southeast1 Sydney, Austrália
australia-southeast2 Melbourne, Austrália
europe-central2 Polônia
europe-north1 Finlândia
europe-southwest1 Espanha
europe-west1 Bélgica
europe-west2 Inglaterra
europe-west3 Frankfurt, Alemanha
europe-west4 Países Baixos
europe-west6 Suíça
europe-west8 Milão, Itália
europe-west9 França
europe-west10 Berlim, Alemanha
europe-west12 Turim, Itália
me-central1 Doha
me-central2 Damã, Arábia Saudita
me-west1 Tel Aviv
northamerica-northeast1 Montreal, Canadá
northamerica-northeast2 Toronto, Canadá
southamerica-east1 Brasil
southamerica-west1 Chile
us-central1 Iowa
us-east1 Carolina do Sul
us-east4 Norte da Virgínia
us-east5 Ohio
us-south1 Dallas
us-west1 Oregon
us-west2 Los Angeles
us-west3 Salt Lake City
us-west4 Las Vegas

Interface do usuário

Recurso Gerenciado (TD) Gerenciado (istiod)
Painéis do Cloud Service Mesh no console do Google Cloud
Cloud Monitoring
Cloud Logging

Ferramentas

Recurso Gerenciado (TD) Gerenciado (istiod)
Ferramenta gcloud beta container fleet mesh debug