Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
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.
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 do GKE no Google Cloud na 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)
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
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.
† 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.
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. O plano de controle TRAFFIC_DIRECTOR
não oferece suporte à configuração da taxa de amostragem de rastros.
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.
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.
† O IPv6 está disponível como um recurso de rede de pilha dupla em visualização. No
gRPC sem proxy, os recursos de pilha dupla têm suporte apenas no gRPC 1.66.1 ou mais recente
em C++ e Python ou gRPC Node.js v1.12. Se você tentar configurar recursos de pilha dupla com uma versão do
gRPC que não oferece suporte a esse recurso, os clientes vão usar apenas o primeiro
endereço enviado pelo Traffic Director.
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
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 é compatível com os seguintes campos.
Campo trafficPolicy.loadBalancer.localityLbSetting
Campo trafficPolicy.tunnel
Campo trafficPolicy.tls.credentialName
Campo trafficPolicy.portLevelSettings[].tls.credentialName
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)
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-11-27 UTC."],[],[]]
