Recursos compatíveis com as 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.
Para conferir a lista de recursos compatíveis com o Cloud Service Mesh para um plano de controle
no cluster, consulte
Como usar as APIs do Istio (plano de controle istiod
no cluster).
Se você não souber qual plano de controle do Cloud Service Mesh está usando, confira a implementação do plano de controle usando as instruções em
Identificar a implementação do plano de controle.
Limitações
Considere as seguintes limitações:
- Os clusters do GKE precisam estar em uma das regiões compatíveis.
- A versão do GKE precisa ser uma versão compatível.
- Apenas as plataformas listadas em Ambientes são compatíveis.
- Não é possível alterar canais de lançamento.
- As migrações do
Cloud Service Mesh gerenciado com
asmcli
para o Cloud Service Mesh com a API Fleet não são compatíveis. Da mesma forma, não é possível provisionar o Cloud Service Mesh gerenciado com a API Fleet de--management manual
para--management automatic
. - 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, use os comandosgcloud 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 IU 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
.As novas instalações do Cloud Service Mesh gerenciado buscam JWKS apenas usando Envoys, a menos que a frota contenha outros clusters para os quais esse comportamento não esteja ativado. Isso é equivalente à opção
PILOT_JWT_ENABLE_REMOTE_JWKS=envoy
do Istio. Em comparação com instalações que não têm a condição VPCSC_GA_SUPPORTED (confira abaixo), talvez seja necessário fazer uma configuração extra paraServiceEntry
eDestinationRule
. Confira um exemplo emrequestauthn-with-se.yaml.tmpl
. É possível determinar se o modo de operação atual é equivalente aPILOT_JWT_ENABLE_REMOTE_JWKS=envoy
verificando se o VPC Service Controls é compatível com o plano de controle (ou seja, a condição VPCSC_GA_SUPPORTED é exibida).O plano de dados gerenciado tem suporte apenas para cargas de trabalho sem sidecars adicionais (exceto o sidecar do Cloud Service Mesh).
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 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 têm suporte total do Google Cloud Suporte. 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 Google Cloud organização 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 daTRAFFIC_DIRECTOR
sem alterações vão continuar recebendo a implementação daISTIOD
até 8 de setembro de 2024. Esses usuários receberam um anúncio de serviço. - Se algum cluster do GKE no Google Cloud na sua frota contiver um plano de controle do Cloud Service Mesh
no cluster ao provisionar o Cloud Service Mesh gerenciado, você
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) | ||
Como ativar recursos opcionais |
Ambientes
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Versões do GKE disponíveis no momento nos canais de lançamento, em uma das regiões com suporte | ||
Versões do GKE disponíveis no momento nos canais de lançamento, em uma das regiões com suporte e clusters do Autopilot do GKE. | ||
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 | ||
50 portas de serviço sem comando por malha e 36 pods por porta de serviço sem comando |
Ambiente de plataforma
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Rede única | ||
Várias redes | ||
Projeto único | ||
Vários projetos com VPC compartilhada |
Implantação de vários clusters
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Modo multiprimário | ||
Principal controle remoto | ||
Descoberta de endpoints em vários clusters com a API declarativa | ||
Descoberta de endpoints de vários clusters com segredos remotos |
Observações sobre a terminologia
- 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.
Imagens de base
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Imagem proxy distroless | † |
† 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.
Segurança
VPC Service Controls
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
VPC Service Controls |
Mecanismos de distribuição e rotação de certificados
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Gerenciamento de certificados de carga de trabalho | ||
Gerenciamento de certificados externos nos gateways de entrada e de saída. |
Suporte para autoridade de certificação (CA)
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Autoridade certificadora do Cloud Service Mesh | ||
Certificate Authority Service | ||
CA do Istio | ||
Integração com CAs personalizadas |
Recursos de segurança
Além de oferecer suporte aos recursos de segurança do Istio, o Cloud Service Mesh oferece ainda mais recursos para ajudar a proteger seus aplicativos.
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Integração com o IAP | ||
Autenticação de usuário final | ||
Modo de teste | ||
Registro de negação | ||
Políticas de auditoria (não é compatível) |
Política de autorização
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Política de autorização v1beta1 | † | |
Política de autorização PERSONALIZADA | § |
† A implementação do plano de controle TRAFFIC_DIRECTOR
não oferece suporte aos campos
rules.from.source.RemoteIp
e rules.from.source.NotRemoteIp
.
Autenticação de mesmo nível
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Auto-mTLS | ||
Modo mTLS PERMISSIVE | ||
Modo mTLS STRICT | * | * |
Modo mTLS DISABLE |
Autenticação de solicitações
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Autenticação JWT(Observação 1) | ||
Roteamento com base em declarações JWT | ||
JWT Copy Claim to Headers |
Observações:
- O JWT de terceiros é ativado por padrão.
- Adicione o fqdn/nome de host completo no JWKSURI ao definir a API RequestAuthentication.
- O plano de controle gerenciado força o Envoy a buscar JWKS ao especificar o URI do JWKS.
Telemetria
Métrica
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Cloud Monitoring (métricas HTTP no proxy) | ||
Cloud Monitoring (métricas TCP no proxy) | ||
Exportação de métricas do Prometheus para o Grafana (somente métricas do Envoy) | * | * |
Exportação de métricas do Prometheus para o Kiali | ||
Google Cloud Managed Service para Prometheus, sem incluir o painel do Cloud Service Mesh | * | * |
API Istio Telemetry | † | |
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.
Geração de registros de solicitação do proxy
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Registros de tráfego | ||
Registros de acesso | * | * |
Cloud Trace
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Cloud Trace | * | * |
Rastreamento do Jaeger (permite o uso de Jaeger gerenciado pelo cliente) | Compatível | |
Rastreamento de Zipkin (permite o uso de Zipkin gerenciado pelo cliente) | Compatível |
Rede
Mecanismos de interceptação e redirecionamento de tráfego
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Uso de iptables usando contêineres init
com CAP_NET_ADMIN |
† | |
Interface de rede de contêineres do Istio (CNI, na sigla em inglês) | ||
Sidecar de caixa baixa |
† É altamente recomendável usar a interface de rede de contêineres (CNI) em vez de
contêineres init
.
Suporte a protocolo
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
IPv4 | ||
HTTP/1.1 | ||
HTTP/2 | ||
Streams de bytes TCP (Observação 1) | ||
gRPC | ||
IPv6 | † |
Observações:
- 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 são compatíveis apenas com o 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 ofereça 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 | ||
API "EnvoyFilter" | § | |
API WasmPlugin | ||
Operador do Istio |
Balanceador de carga para o gateway de entrada do Istio
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Balanceador de carga externo de terceiros | ||
Google Cloud Balanceador de carga interno | * | * |
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 | ||
GCPTrafficDistributionPolicy | ||
GCPBackendPolicy |
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 camporesolution
- Valor
MESH_INTERNAL
no campolocation
- 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) | ||
Suporte a HTTP/1.0 (ISTIO_META_NETWORK) | ||
Seleção de imagem (distroless ou imagem de base) | † | |
Sidecar nativo do Kubernetes (ENABLE_NATIVE_SIDECARS) |
A imagem do DistroX é usada para a injeção.
Regiões
Os clusters do GKE precisam estar em uma das regiões ou em qualquer zona dentro das regiões a seguir.
Região | Local |
---|---|
africa-south1 |
Johannesburgo |
asia-east1 |
Taiwan |
asia-east2 |
Hong Kong |
asia-northeast1 |
Tóquio, Japão |
asia-northeast2 |
Osaka, Japão |
asia-northeast3 |
Coreia do Sul |
asia-south1 |
Mumbai, Índia |
asia-south2 |
Déli, Índia |
asia-southeast1 |
Singapura |
asia-southeast2 |
Jacarta |
australia-southeast1 |
Sydney, Austrália |
australia-southeast2 |
Melbourne, Austrália |
europe-central2 |
Polônia |
europe-north1 |
Finlândia |
europe-southwest1 |
Espanha |
europe-west1 |
Bélgica |
europe-west2 |
Inglaterra |
europe-west3 |
Frankfurt, Alemanha |
europe-west4 |
Países Baixos |
europe-west6 |
Suíça |
europe-west8 |
Milão, Itália |
europe-west9 |
França |
europe-west10 |
Berlim, Alemanha |
europe-west12 |
Turim, Itália |
me-central1 |
Doha |
me-central2 |
Damã, Arábia Saudita |
me-west1 |
Tel Aviv |
northamerica-northeast1 |
Montreal, Canadá |
northamerica-northeast2 |
Toronto, Canadá |
southamerica-east1 |
Brasil |
southamerica-west1 |
Chile |
us-central1 |
Iowa |
us-east1 |
Carolina do Sul |
us-east4 |
Norte da Virgínia |
us-east5 |
Ohio |
us-south1 |
Dallas |
us-west1 |
Oregon |
us-west2 |
Los Angeles |
us-west3 |
Salt Lake City |
us-west4 |
Las Vegas |
Interface do usuário
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Painéis do Cloud Service Mesh no console do Google Cloud | ||
Cloud Monitoring | ||
Cloud Logging |
Ferramentas
Recurso | Gerenciado (TD) | Gerenciado (istiod) |
---|---|---|
Ferramenta gcloud beta container fleet mesh debug |