Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Recursos compatíveis que usam 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.
Migrações e upgrades são compatíveis apenas com o Cloud Service Mesh no cluster
versões 1.9+ instaladas com a CA da malha. 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 mais informações sobre o que está disponível
para assinantes e não inscritos, consulte
Diferenças entre a 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 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 ver 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 é
usada 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ê 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.
Usuários cujo uso atual não é compatível com o TRAFFIC_DIRECTOR
a implementação sem mudanças vai continuar recebendo o ISTIOD
até 8 de setembro de 2024. Esses usuários receberam um
anúncio de serviço.
Se algum cluster na sua frota usar o serviço de autoridade certificadora ao provisionar o Cloud Service Mesh gerenciado, você vai 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 da sua frota usar
GKE Sandbox,
ao provisionar o Cloud Service Mesh gerenciado, você recebe o ISTIOD
implementação do plano de controle.
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 (nível pulado) 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)
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 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) oferece suporte apenas
o tipo de imagem distroless. Não é possível alterá-la.
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 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 oferecer suporte ao protocolo
(por exemplo, 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),
porque o protocolo não é compatível.
† O IPv6 está disponível como recurso de pré-lançamento de rede de pilha dupla. Em
gRPC sem proxy, os recursos de pilha dupla têm suporte apenas no gRPC 1.66.1 ou mais recente.
em C++ e Python. Se você tentar configurar recursos de pilha dupla com uma versão do
gRPC que não oferece suporte à pilha dupla, os clientes usarão apenas o primeiro
endereço IP 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 do TRAFFIC_DIRECTOR não é compatível com os itens a seguir
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
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
Campo trafficPolicy.loadBalancer.localityLbSetting e trafficPolicy.tunnel
.
Além disso, a implementação do plano de controle TRAFFIC_DIRECTOR requer que o
a regra de destino que define subconjuntos está no mesmo namespace e cluster com
o serviço Kubernetes ou 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-11 UTC."],[],[]]
