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)
Esta página descreve os recursos suportados e as limitações do
Cloud Service Mesh usando TRAFFIC_DIRECTOR ou ISTIOD como plano de controle e o
as diferenças entre cada implementação. 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 TRAFFIC_DIRECTOR sempre que possível.
As migrações e os upgrades são compatíveis somente 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, você pode usar
gcloud beta container fleet mesh debug, conforme descrito nas
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 só estão disponíveis
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 equivale a
a opção PILOT_JWT_ENABLE_REMOTE_JWKS=envoy do Istio. Em comparação com as instalações em
os canais de lançamento regular e stable ou instalações no
canal de lançamento rápido antes de 14 de novembro de 2023, talvez você precise de mais
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 APIs de recurso podem
têm diferenças entre as 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
usados para todos os clusters que provisionam o Cloud Service Mesh gerenciado nessa frota.
As novas frotas que se integram ao Cloud Service Mesh gerenciado recebem a
Implementação do plano de controle TRAFFIC_DIRECTOR, com algumas exceções:
Se você for um usuário gerenciado do Cloud Service Mesh, receberá o ISTIOD
implementação de plano de controle ao integrar uma nova frota no mesmo Google Cloud
Organização para o Cloud Service Mesh gerenciado, pelo menos até 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 uma conta
Announcement.)
Se algum cluster da sua frota usar o Certificate Authority Service ao provisionar
Cloud Service Mesh, você 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
Instalação, upgrade e reversão
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
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 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 em
conectividade. 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.
Embora o TCP seja um protocolo com suporte para redes e
são coletadas, mas 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.
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
O valor MESH_INTERNAL está 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)
Arquivo secundário 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-10-12 UTC."],[],[]]
