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.
A escala está limitada a 1000 serviços e 5000 cargas de trabalho por cluster.
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.
A partir de 14 de novembro de 2023, as novas instalações da malha de serviços na nuvem gerida no canal de lançamento rápido obtêm JWKS apenas através de Envoys. Isto é equivalente à opção PILOT_JWT_ENABLE_REMOTE_JWKS=envoy do Istio. Em comparação com as instalações nos canais de lançamento normais e estáveis, ou as instalações no canal de lançamento rápido antes de 14 de novembro de 2023, pode precisar de configurações ServiceEntry e DestinationRule adicionais. Para ver um exemplo, consulte o artigo
requestauthn-with-se.yaml.tmpl.
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 algum cluster na sua frota usar o serviço de autoridade de certificação quando aprovisiona o Cloud Service Mesh gerido, recebe a implementação do plano de controlo ISTIOD.
Se qualquer cluster 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 ISTIOD.
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
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 puderem comunicar diretamente, sem um gateway.
† 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.
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.
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
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 o campo trafficPolicy.loadBalancer.localityLbSetting e o campo trafficPolicy.tunnel.
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,[]]
