Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Funcionalidades suportadas através das APIs Istio (plano de controlo gerido)
Esta página descreve as funcionalidades suportadas e as limitações da
Cloud Service Mesh que usa o TRAFFIC_DIRECTOR ou o ISTIOD como plano de controlo e as
diferenças entre cada implementação. Tenha em atenção que não pode escolher estas opções. A implementação do ISTIOD só está disponível para utilizadores existentes.
As novas instalações usam a implementação de TRAFFIC_DIRECTOR sempre que possível.
As migrações e as atualizações só são suportadas a partir de versões 1.9 ou superiores do Cloud Service Mesh no cluster instaladas com a AC de malha. As instalações com a AC do Istio (anteriormente conhecida como Citadel) têm primeiro de migrar para a AC da malha.
Apenas a opção de implementação com vários nós principais é suportada para vários clusters:
a opção de implementação principal-remota para vários clusters não é suportada.
O istioctl ps não é suportado. Em alternativa, pode usar os comandos gcloud beta container fleet mesh debug, conforme descrito na secção Resolução de problemas.
APIs não suportadas:
EnvoyFilter API
WasmPlugin API
IstioOperator API
Kubernetes Ingress API
Pode usar o plano de controlo gerido sem uma subscrição do GKE Enterprise, mas determinados elementos da IU e funcionalidades na Google Cloud consola só estão disponíveis para subscritores do GKE Enterprise. Para obter informações sobre o que está disponível
para subscritores e não subscritores, consulte
Diferenças entre a IU do GKE Enterprise e do Cloud Service Mesh.
Durante o processo de aprovisionamento de um plano de controlo gerido, os CRDs do Istio correspondentes ao canal selecionado são instalados no cluster especificado. Se existirem CRDs do Istio no cluster, estes vão ser
substituídos.
O Managed Cloud Service Mesh só suporta o domínio DNS predefinido .cluster.local.
As novas instalações da malha de serviços na nuvem gerida obtêm JWKS apenas através de Envoys, a menos que a frota contenha outros clusters para os quais esse comportamento não esteja ativado. Isto é equivalente à opção PILOT_JWT_ENABLE_REMOTE_JWKS=envoy
Istio. Em comparação com as instalações que não têm a condição VPCSC_GA_SUPPORTED (veja abaixo), pode precisar de uma configuração adicional para as configurações ServiceEntry e DestinationRule. Para ver um exemplo, consulte
requestauthn-with-se.yaml.tmpl.
Pode determinar se o modo de funcionamento atual é equivalente a
PILOT_JWT_ENABLE_REMOTE_JWKS=envoy determinando se os VPC Service
Controls são suportados para o plano
de controlo (ou seja, a condição VPCSC_GA_SUPPORTED é apresentada).
O plano de dados gerido só é suportado para cargas de trabalho sem sidecars adicionais (exceto o sidecar do Cloud Service Mesh).
Diferenças no plano de controlo
Existem diferenças nas funcionalidades suportadas entre as implementações do plano de controlo ISTIOD e TRAFFIC_DIRECTOR. Para verificar que implementação está a usar, consulte o artigo
Identifique a implementação do plano de controlo.
: indica que a funcionalidade está disponível e
ativada por predefinição.
† – indica que as APIs de funcionalidades podem ter diferenças entre várias plataformas.
* – indica que a funcionalidade é suportada para a plataforma e pode ser ativada, conforme descrito em
Ative funcionalidades opcionais
ou no guia de funcionalidades com link na tabela de funcionalidades.
§ – indica que a funcionalidade é suportada pela lista de autorizações. Os utilizadores anteriores do Anthos Service Mesh gerido são
automaticamente incluídos na lista de autorizações ao nível da organização.
Contacte Google Cloud o apoio técnico para pedir acesso
ou verificar o estado da sua lista de autorizações.
: indica que a funcionalidade não está disponível ou não é suportada.
As funcionalidades predefinidas e opcionais são totalmente suportadas pelo Google Cloud
apoio técnico. As funcionalidades não listadas explicitamente nas tabelas recebem suporte
de melhor esforço.
O que determina a implementação do plano de controlo
Quando aprovisiona o Cloud Service Mesh gerido pela primeira vez numa frota, determinamos que implementação do plano de controlo usar. A mesma implementação é usada para todos os clusters que aprovisionam o Cloud Service Mesh gerido nessa frota.
As novas frotas integradas no Cloud Service Mesh gerido recebem a implementação do
TRAFFIC_DIRECTOR painel de controlo, com determinadas exceções:
Se for um utilizador existente do Cloud Service Mesh gerido, recebe a implementação do ISTIOD
plano de controlo quando integrar uma nova frota na mesma Google Cloud
organização no Cloud Service Mesh gerido, pelo menos até 30 de junho de 2024.
Se for um destes utilizadores, pode contactar o apoio técnico para ajustar este comportamento.
Os utilizadores cuja utilização existente não seja compatível com a implementação sem alterações vão continuar a receber a implementação até 8 de setembro de 2024.TRAFFIC_DIRECTORISTIOD (Estes utilizadores receberam um anúncio de serviço.)
Se qualquer cluster do GKE na sua frota contiver um plano de controlo do Cloud Service Mesh no cluster quando aprovisionar o Cloud Service Mesh gerido, recebe a implementação do plano de controlo do ISTIOD. Google Cloud
Se algum cluster na sua frota usar o
GKE Sandbox,
quando aprovisiona a malha de serviços na nuvem gerida, recebe a implementação do ISTIOD
plano de controlo.
Funcionalidades suportadas do plano de controlo gerido
Instale, atualize e reverta
Funcionalidade
Gerido (TD)
Gerido (istiod)
Instalação em clusters do GKE através da API de funcionalidades fleet
Atualizações de versões do ASM 1.9 que usam a AC de malha
Atualizações diretas (de nível ignorado) a partir de versões do Cloud Service Mesh anteriores à 1.9 (consulte as notas para atualizações indiretas)
Atualizações diretas (sem níveis intermédios) a partir do Istio OSS (consulte as notas para atualizações indiretas)
Atualizações diretas (de nível inferior) a partir do suplemento Istio-on-GKE (consulte as notas para atualizações indiretas)
Ambientes fora do Google Cloud (GKE Enterprise on-premises,
GKE Enterprise noutras nuvens públicas, Amazon EKS, Microsoft AKS,
ou outros clusters do Kubernetes)
Evolua
Funcionalidade
Gerido (TD)
Gerido (istiod)
1000 serviços e 5000 cargas de trabalho por cluster
Descoberta de pontos finais de vários clusters com a API declarativa e uma topologia simples
Notas sobre a terminologia
Uma configuração com vários nós principais significa que a configuração tem de 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 prioritária.
O Cloud Service Mesh usa uma definição simplificada de rede baseada na conetividade geral. As instâncias de carga de trabalho estão na mesma rede se forem capazes de comunicar diretamente, sem um gateway.
A topologia simples para a descoberta de pontos finais de vários clusters significa que todos os clusters na frota participam ou não na descoberta de pontos finais. As topologias complexas não suportadas incluem (a) a deteção de pontos finais unidirecional (por exemplo, o cluster A pode detetar pontos finais no cluster B, mas não vice-versa) e (b) redes de deteção de pontos finais desarticuladas (por exemplo, os clusters A e B podem detetar os pontos finais uns dos outros, os clusters C e D podem detetar os pontos finais uns dos outros, mas A/B e C/D não podem detetar os pontos finais uns dos outros).
† O Cloud Service Mesh com um plano de controlo gerido (TD) só suporta o tipo de imagem sem distribuição. Não pode alterá-lo.
Tenha em atenção que as imagens sem distribuição têm ficheiros binários mínimos, pelo que não pode executar os comandos habituais, como bash ou curl, porque não estão presentes na imagem sem distribuição.
No entanto, pode usar contentores efémeros para anexar a um pod de carga de trabalho em execução para poder inspecioná-lo e executar comandos personalizados. Por exemplo, consulte o artigo Recolher registos da malha de serviços na nuvem.
Além de suportar as funcionalidades de segurança do Istio, o Cloud Service Mesh oferece ainda mais capacidades para ajudar a proteger as suas aplicações.
Adaptadores/backends personalizados, dentro ou fora do processo
Back-ends de telemetria e registo arbitrários
† O plano de controlo TRAFFIC_DIRECTOR suporta um subconjunto da API de telemetria do Istio
usado para configurar registos de acesso e
rastreio. O TRAFFIC_DIRECTOR
plano de controlo não suporta a configuração da taxa de amostragem de rastreio.
Embora o TCP seja um protocolo suportado para redes e as métricas de TCP sejam recolhidas, não são comunicadas. As métricas são apresentadas apenas para serviços HTTP na Google Cloud consola.
Os serviços configurados com capacidades da camada 7 para os seguintes protocolos não são suportados: WebSocket, MongoDB, Redis, Kafka, Cassandra, RabbitMQ e Cloud SQL. Pode conseguir fazer com que o protocolo funcione usando a compatibilidade com o fluxo de bytes TCP. Se a stream de bytes TCP não conseguir suportar o protocolo (por exemplo, o Kafka envia um endereço de redirecionamento numa resposta específica do protocolo e este redirecionamento é incompatível com a lógica de encaminhamento do Cloud Service Mesh), o protocolo não é suportado.
† No gRPC sem proxy, as funcionalidades de pilha dupla IPv6 só são suportadas no gRPC 1.66.1 ou mais recente em C++ e Python, gRPC Go v1.71 e/ou gRPC Node.js v1.12.
Se tentar configurar funcionalidades de pilha dupla com uma versão do gRPC que não
suporta a pilha dupla, os clientes usam apenas o primeiro endereço enviado pelo
Traffic Director.
Implementações do Envoy
Funcionalidade
Gerido (TD)
Gerido (istiod)
Sidecars
Gateway de entrada
Saia diretamente dos sidecars
Saída através de gateways de saída
*
*
Compatibilidade com CRD
Funcionalidade
Gerido (TD)
Gerido (istiod)
Recurso de ficheiro complementar
Recurso de entrada de serviço
Percentagem, injeção de falhas, correspondência de caminhos, redirecionamentos, novas tentativas, reescrita,
tempo limite, nova tentativa, replicação, manipulação de cabeçalhos e regras de encaminhamento CORS
Balanceador de carga para o gateway de entrada do Istio
Funcionalidade
Gerido (TD)
Gerido (istiod)
Balanceador de carga externo de terceiros
Google Cloud Balanceador de carga interno
*
*
Gateway de nuvem da malha de serviço
Funcionalidade
Gerido (TD)
Gerido (istiod)
Gateway de nuvem da malha de serviço
API Kubernetes Gateway
Funcionalidade
Gerido (TD)
Gerido (istiod)
API Kubernetes Gateway
Políticas de balanceamento de carga
Funcionalidade
Gerido (TD)
Gerido (istiod)
Ordem aleatória
Menos ligações
Aleatório
Transparente
Hash consistente
Localidade
GCPTrafficDistributionPolicy
GCPBackendPolicy
Entrada de serviço
Funcionalidade
Gerido (TD)
Gerido (istiod)
ServiceEntry v1beta1
†
† A implementação do plano de controlo TRAFFIC_DIRECTOR não suporta os seguintes campos e valores nos campos:
workloadSelector campo
endpoints[].network campo
endpoints[].locality campo
endpoints[].weight campo
endpoints[].serviceAccount campo
Valor DNS_ROUND_ROBIN no campo resolution
Valor MESH_INTERNAL no campo location
Endereço de socket de domínio Unix no campo endpoints[].address
subjectAltNames campo
Regra de destino
Funcionalidade
Gerido (TD)
Gerido (istiod)
DestinationRule v1beta1
†
† A implementação do plano de controlo TRAFFIC_DIRECTOR não suporta os seguintes campos.
trafficPolicy.loadBalancer.localityLbSetting campo
trafficPolicy.tunnel campo
trafficPolicy.tls.credentialName campo
trafficPolicy.portLevelSettings[].tls.credentialName campo
Além disso, a implementação do plano de controlo TRAFFIC_DIRECTOR requer que a regra de destino que define subconjuntos esteja no mesmo espaço de nomes e cluster com o serviço Kubernetes ou o ServiceEntry.
Sidecar
Funcionalidade
Gerido (TD)
Gerido (istiod)
Sidecar v1beta1
†
† A implementação do plano de controlo TRAFFIC_DIRECTOR não suporta os seguintes campos e valores nos campos:
ingress campo
egress.port campo
egress.bind campo
egress.captureMode campo
inboundConnectionPool campo
MeshConfig
Funcionalidade
Gerido (TD)
Gerido (istiod)
LocalityLB
§
ExtensionProviders
§
CACert
ImageType - distroless
§
OutboundTrafficPolicy
§
defaultProviders.accessLogging
defaultProviders.tracing
defaultConfig.tracing.stackdriver
§
accessLogFile
§
ProxyConfig
Funcionalidade
Gerido (TD)
Gerido (istiod)
Proxy DNS (ISTIO_META_DNS_CAPTURE, ISTIO_META_DNS_AUTO_ALLOCATE)
Suporte para HTTP/1.0 (ISTIO_META_NETWORK)
Seleção de imagens (imagem base ou sem distribuição)
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-23 UTC."],[],[],null,[]]
