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

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

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

Limitações

Cuidado:todos os clusters do Cloud Service Mesh de uma malha precisam ser sempre registrados na mesma frota para usar o Cloud Service Mesh. Outros clusters no projeto de um cluster do Cloud Service Mesh não podem ser registrados em uma frota diferente.

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.
• Não há suporte para migrações do Cloud Service Mesh gerenciado com asmcli para o Cloud Service Mesh com API frota. Da mesma forma, não há suporte para o provisionamento do Cloud Service Mesh gerenciado com a API de frota 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

  • API Kubernetes Gateway

  Observação: ainda é possível ativar recursos opcionais sem usar a API IstioOperator. Consulte Ativar recursos opcionais no Cloud Service Mesh gerenciado. Também é possível usar a ferramenta de migração incluída em asmcli para converter automaticamente outros recursos opcionais do IstioOperator para serem compatíveis com o plano de controle gerenciado. Para mais informações, consulte Migrar de IstioOperator.

• É possível usar o plano de controle gerenciado sem uma assinatura do GKE Enterprise, mas alguns elementos e recursos da IU 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 entre o GKE Enterprise e a interface 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 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 buscam o 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 instalações no canal de lançamento rápido anteriores a 14 de novembro de 2023, talvez você precise de mais configurações ServiceEntry e DestinationRule. Para ver um exemplo, consulte requestauthn-with-se.yaml.tmpl.

Diferenças do plano de controle

Há diferenças entre os recursos compatíveis entre a istiod e as implementações do plano de controle do Cloud Service Mesh. 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 recurso podem ter diferenças entre várias plataformas.
• *: indica que o recurso tem suporte para a plataforma e pode ser ativado, conforme descrito em Ativar recursos opcionais ou no guia de recursos vinculado na tabela de recursos.
• §: indica que o recurso tem suporte da lista de permissões. Entre em contato com o suporte do Google Cloud para solicitar acesso.
• : 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

Ao provisionar o Cloud Service Mesh gerenciado pela primeira vez em uma frota, determinamos qual implementação do plano de controle será usada. A mesma implementação é usada para todos os clusters que provisionam o Cloud Service Mesh gerenciado nessa frota.

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

• Se já for um usuário gerenciado do Cloud Service Mesh, você 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 24 de junho de 2024. Se você for um desses usuários, entre em contato com o suporte para ajustar esse comportamento.
• Se algum cluster na sua frota usar o Certificate Authority Service ao provisionar o Cloud Service Mesh gerenciado, você receberá a implementação do plano de controle ISTIOD. Antes de fazer a integração usando o Certificate Authority Service pela primeira vez, entre em contato com o suporte para saber como reduzir a sobrecarga futura da migração do plano de controle.
• Se algum cluster na sua frota tiver um plano de controle do Cloud Service Mesh no cluster ao provisionar o Cloud Service Mesh gerenciado, você receberá a implementação do plano de controle ISTIOD.
• Se qualquer cluster na sua frota usar o GKE Sandbox, ao provisionar o Cloud Service Mesh gerenciado, você receberá a implementação do plano de controle ISTIOD.

Identificar a implementação do plano de controle

Execute o seguinte comando para identificar a implementação do plano de controle:

  gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Se você estiver usando o Cloud Service Mesh com as APIs do Google Cloud (consulte Sobre o Cloud Service Mesh), esse comando não vai funcionar.

O resultado será assim:

  ...
  membershipSpecs:
    projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
      mesh:
        management: MANAGEMENT_AUTOMATIC
  membershipStates:
    projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
      servicemesh:
        controlPlaneManagement:
          details:
          - code: REVISION_READY
            details: 'Ready: asm-managed'
          state: ACTIVE
          implementation: TRAFFIC_DIRECTOR
  ...

Os valores possíveis implementation são:

• TRAFFIC_DIRECTOR: a infraestrutura principal do Google Cloud serve como o plano de controle do Cloud Service Mesh.
• ISTIOD: a instância gerenciada de istiod serve como o plano de controle do Cloud Service Mesh.
• UPDATING: o cluster está sendo migrado entre as implementações. Em breve, você terá a implementação de TRAFFIC_DIRECTOR.

Recursos compatíveis do plano de controle gerenciado

Instalação, upgrade e reversão

Engenharia de	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 (ignorados) das versões do Cloud Service Mesh anteriores à 1.9. Consulte as observações sobre 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

Observação: migrações e upgrades indiretos são compatíveis, o que significa que é possível seguir os caminhos de upgrade padrão do Cloud Service Mesh em cada versão até chegar ao Cloud Service Mesh com um plano de controle no cluster. Depois disso, é possível migrar para o plano de controle gerenciado. Migrações e upgrades diretos são compatíveis apenas com as versões 1.9 ou mais recentes do Cloud Service Mesh instaladas com a CA do Mesh. As instalações com a CA do Istio precisam migrar primeiro para a CA do Mesh.

Ambientes

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
GKE 1.25 a 1.27 em uma das regiões suportadas
Clusters do GKE 1.25 a 1.27 com o 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

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
1.000 serviços e 5.000 cargas de trabalho por cluster
50 ServicePorts por malha e 36 pods por ServicePort

Observação: esse é um limite flexível para o número de serviços e cargas de trabalho compatíveis por cluster. Entre em contato com o suporte do Cloud ao exceder esse limite.

Ambiente de plataforma

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

Implantação de vários clusters

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

Observações sobre a terminologia

• Uma configuração multiprimária significa que ela precisa ser replicada em todos os clusters.
• Uma configuração remota primária 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

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
Imagem proxy distroless	†

† O Cloud Service Mesh com um plano de controle gerenciado (TD) oferece suporte apenas ao tipo de imagem distroless. Não é possível alterá-la.

Observe que as imagens distroless têm binários mínimos, portanto, 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 inspecioná-lo e executar comandos personalizados. Por exemplo, consulte Como coletar registros do Cloud Service Mesh.

Segurança

VPC Service Controls

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
Prévia do VPC Service Controls
VPC Service Controls GA

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

Engenharia de	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)

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
Autoridade de certificação 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 você a proteger seus aplicativos.

Engenharia de	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 (não compatíveis)

Política de autorização

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
Política de autorização v1beta1	†
Política de autorização CUSTOM	§

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

Autenticação de mesmo nível

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
Auto-mTLS
Modo mTLS PERMISSIVE
Modo mTLS STRICT	*	*
Modo mTLS DESATIVAR

Autenticação de solicitações

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
Autenticação JWT^(Observação 1)
Roteamento com base em declaração JWT
Declaração de cópia do JWT para os cabeçalhos

Observações:

1. O JWT de terceiros é ativado por padrão.
2. Adicione o fqdn/hostname completo em JWKSURI ao definir a API RequestAuthentication.
3. O plano de controle gerenciado aplica o Envoy para buscar JWKS ao especificar o URI do JWKS.

Telemetria

Métricas

Engenharia de	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 do Cloud Service Mesh oferece suporte a um subconjunto da API de telemetria do Istio usada para configurar registros de acesso e trace.

Observação: é possível configurar produtos de telemetria de terceiros (como Grafana e Prometheus), mas não podemos garantir compatibilidade futura, e o suporte do Cloud não pode oferecer ajuda para gerenciá-los.

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

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

Cloud Trace

Engenharia de	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

Observação: é possível configurar produtos de telemetria de terceiros (como Jaeger, Zipkin e Grafana), mas não podemos garantir compatibilidade futura, e o suporte do Google Cloud não pode oferecer ajuda para gerenciá-los.

Rede

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

Engenharia de	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

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

Observações:

1. O TCP é um protocolo compatível com a coleta de métricas de rede e TCP, mas 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 oferecer suporte ao protocolo (por exemplo, o Kafka envia um endereço de redirecionamento em uma resposta específica do protocolo e esse redirecionamento for incompatível com a lógica de roteamento do Cloud Service Mesh), o protocolo não será compatível.

Implantações do Envoy

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

Compatibilidade com CRD

Engenharia de	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

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

Gateway da nuvem da malha de serviço

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

Políticas de balanceamento de carga

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

Entrada de serviço

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
ServiceEntry v1beta1	†

† A implementação do plano de controle do Cloud Service Mesh não é compatível com os seguintes campos e valores nos campos:

• Campo workloadSelector
• Campo endpoints[].network
• Campo endpoints[].locality
• Campo endpoints[].weight
• Campo endpoints[].serviceAccount
• O valor DNS_ROUND_ROBIN está no campo resolution
• O valor MESH_INTERNAL está no campo location
• Endereço do soquete de domínio Unix no campo endpoints[].address

Regra de destino

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
DestinationRule v1beta1	†

† A implementação do plano de controle do Cloud Service Mesh não é compatível com os campos trafficPolicy.loadBalancer.localityLbSetting e trafficPolicy.tunnel. Além disso, a implementação do plano de controle do Cloud Service Mesh exige que a regra de destino que define os subconjuntos esteja no mesmo namespace e cluster com o serviço do Kubernetes ou a ServiceEntry.

Arquivo secundário

Engenharia de	Gerenciado (TD)	Gerenciado (istiod)
Arquivo secundário v1beta1	†

† A implementação do plano de controle do Cloud Service Mesh não é compatível com os seguintes campos e valores nos campos:

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

MeshConfig

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

ProxyConfig

Engenharia de	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)	†

† Imagem Distroless é 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
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

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

Ferramentas

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