Comparar o Autopilot do GKE e o Standard

Autopilot Standard

---

Nesta página, você verá uma comparação de alto nível entre o modo Autopilot do Google Kubernetes Engine (GKE) e o modo padrão. A comparação inclui recursos importantes do GKE e as diferenças funcionais entre os modos.

Esta página é destinada às seguintes pessoas:

• Administradores de plataforma que estão familiarizados com o GKE e o Modo padrão e querem descobrir as diferenças de recursos e funcionalidades no Autopilot para tomar uma decisão de migração informada.
• Novos usuários do GKE que conhecem o GKE e querem saber qual modo oferece a funcionalidade mais adequada para um requisito específico.

Comparação Autopilot e recursos padrão

Veja na tabela a seguir uma comparação detalhada das opções disponíveis, pré-configuradas e padrão em cada modo de operação do Google Kubernetes Engine (GKE).

A tabela não mostra todos os recursos no GKE. Se você quiser saber se um recurso que não está nesta tabela é compatível com o Autopilot ou o Standard, verifique a documentação desse recurso.

Esta tabela usa a seguinte terminologia:

• Pré-configurado: sempre ativado. O Google define as configurações. Não é possível mudar as configurações ou desativá-lo.
• Padrão: configurado para você se não especificar outro. É possível mudar as configurações padrão.
• Opcional: disponível para você configurar e usar. Não ativado por padrão.

Opção	Piloto automático	Padrão
Versões e lançamentos	Padrão: canal de lançamento normal Opcional: Defina o canal de lançamento Defina a versão do GKE em canais	Opcional: Defina o canal de lançamento Defina uma versão estática do GKE Clusters Alfa para APIs Alfa do Kubernetes
Disponibilidade do local	Pré-configurado: regional	Opcional: regional ou zonal
Gerenciamento de nós	O Autopilot gerencia nós	Criar e gerenciar nós em pools de nós
Provisionamento e escalonamento de nós	Pré-configurado: o Autopilot escalona automaticamente a quantidade e o tamanho dos nós com base nos pods do cluster. Opcional: Escalonamento automático de pod horizontal Escalonamento automático vertical de pods: ativado no cluster, mas o GKE não configura parâmetros de escalonamento automático de pod por padrão.	Padrão: Provisionar manualmente novos nós Especificar manualmente os recursos de nós Opcional: Provisionamento automático de nós Escalonador automático de cluster Escalonamento automático de pod horizontal Escalonamento automático do pod vertical
Sistema operacional do nó	Pré-configurado: SO otimizado para contêiner com containerd	Padrão: SO otimizado para contêiner com containerd Opcional: SO otimizado para contêiner com Docker (descontinuado) Ubuntu com o containerd Ubuntu com Docker (descontinuado) Windows Server LTSC SAC do Windows Server (descontinuado)
Configuração de computação de nós	Padrão: plataforma de uso geral otimizada para a maioria das cargas de trabalho. Opcional: Classes de computação para cargas de trabalho que têm necessidades específicas, como arquitetura de ARM. Aceleradores de hardware (GPUs)	Padrão: tipos de máquinas de uso geral do Compute Engine Opcional: Escolha máquinas e hardware específicos do Compute Engine, como a arquitetura de ARM, para pools de nós Aceleradores de hardware (GPUs) SSDs locais
Upgrades e manutenção de nós	Pré-configurado: Reparo automático de nós Upgrade automático de nós Upgrades de sobretensão Opcional: Upgrades de versão manuais Janelas de manutenção Exclusões de manutenção	Opcional: Reparação automática de nós (apenas canais de lançamento) Upgrade automático de nós (apenas canais de lançamento) Upgrades de versão manuais Janelas de manutenção Exclusões de manutenção Estratégias de upgrade
Segurança	Pré-configurado: A federação de identidade da carga de trabalho para o GKE Nós protegidos do GKE Inicialização segura GKE Sandbox Opcional: Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) Criptografia de Secrets da camada de aplicativos Grupos do Google para RBAC Autorização binária	Opcional: A federação de identidade da carga de trabalho para o GKE Nós protegidos do GKE Inicialização segura Chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês) Criptografia de Secrets da camada de aplicativos Grupos do Google para RBAC Autorização binária Confidential GKE Nodes GKE Sandbox Controle de admissão PodSecurity
Rede	Pré-configurado: Cluster nativo de VPC Máximo de 32 pods em um nó Visibilidade intranós GKE Dataplane V2 ativado DNS: Cloud DNS: versão 1.25.9-gke.400 ou posterior e 1.26.4-gke.500 ou posterior kube-dns: versões anteriores a 1.25.9-gke.400 e 1.26.4-gke.500 Padrão: Endpoint de cluster IPv4 público Intervalos CIDR padrão para pods Nome da rede VPC e da sub-rede Intervalo de IP gerenciado pelo Google para serviços Tipo de NIC: NIC virtual do Google (gVNIC): para nós com a versão 1.30.2-gke.1023000 ou posterior Opcional: Desativar endpoint IPv4 público durante a criação do cluster Cloud NAT para clusters particulares (não para clusters não particulares) Adicionar redes autorizadas do plano de controle Política de rede do Kubernetes Aumentar o intervalo de endereços IP disponível para pods	Pré-configurado: máximo de 256 pods em cada nó Padrão: 110 pods em cada nó Cluster nativo de VPC Endpoint de cluster IPv4 público Nome da rede VPC e da sub-rede kube-dns Opcional: Visibilidade intranós Aumentar o intervalo de endereços IP disponível para pods Desativar endpoint IPv4 público durante a criação do cluster Cloud NAT para clusters particulares Adicionar redes autorizadas do plano de controle Política de rede do Kubernetes GKE Dataplane V2 ativado Cloud DNS Placa de rede virtual do Google (gVNIC, na sigla em inglês)
Geração de registros e monitoramento	Pré-configurado: Registros no nível do sistema Registros no nível da carga de trabalho Monitoramento no nível do sistema Google Cloud Managed Service para Prometheus	Padrão: Registros no nível do sistema Registros no nível da carga de trabalho Monitoramento no nível do sistema Google Cloud Managed Service para Prometheus Opcional: Métricas do plano de controle
Complementos	Pré-configurado: Balanceamento de carga HTTP Driver CSI de disco permanente do Compute Engine Driver CSI do Filestore Driver CSI do Cloud Storage FUSE NodeLocal DNSCache Streaming de imagens Opcional: Cloud Service Mesh gerenciado, que também fornece recursos de malha do Istio.	Opcional: Política de rede do Cilium Driver CSI de disco permanente do Compute Engine Driver CSI do Filestore Driver CSI do Cloud Storage FUSE NodeLocal DNSCache Balanceamento de carga HTTP Cloud Run Cloud TPU Config Connector Cloud Service Mesh gerenciado Kalm Medição de uso Streaming de imagens

Comparação Autopilot e funcional padrão

Na tabela a seguir, mostramos diferenças funcionais importantes entre o Autopilot do GKE e o Standard. Use essa comparação para escolher o modo mais informado ao criar um cluster do GKE.

Funcionalidade	Piloto automático	Padrão
Ferramentas de monitoramento de terceiros	Implante uma ferramenta de monitoramento de terceiros fornecida por parceiros do Google Cloud ou qualquer ferramenta de terceiros que não exija acesso elevado no nó.	Implante qualquer ferramenta de monitoramento de terceiros, independentemente do nível de acesso do nó.
Expor aplicativos externamente	Usar um serviço LoadBalancer. Isso provisiona um endereço IP externo temporário para você. Se você tiver um endereço IP estático disponível que queira usar, especifique-o no campo loadBalancerIP. O Autopilot não oferece suporte ao campo externalIps, que não usa o balanceamento de carga do Google Cloud.	Usar um serviço LoadBalancer. Isso provisiona um endereço IP externo temporário para você. Se você já tiver um endereço IP estático que queira usar, especifique-o no campo loadBalancerIP. Também é possível usar o campo externalIps no manifesto do serviço, embora não seja recomendado.
Bursting de pods	Os pods podem estourar na capacidade de burst não utilizada se os limites de recursos forem maiores que suas solicitações de recursos ou se você não os definir. A capacidade de burst é a soma das solicitações de recursos do pod no nó. Para saber mais, acesse Configurar o bursting de pods no GKE.	Os pods poderão estourar para capacidade do nó não utilizada se os limites de recursos forem maiores que as solicitações de recursos. No padrão, você paga pela capacidade do nó, independentemente de os pods usarem os recursos. Não dependa do bursting de pod. Avalie e defina solicitações e limites de recursos adequados para suas cargas de trabalho.
Namespaces gerenciados pelo GKE	Como medida de segurança, o Autopilot não permite implantar cargas de trabalho em namespaces gerenciados pelo GKE, como kube-system. Para saber mais, consulte Recursos de segurança do Autopilot.	As cargas de trabalho podem ser executadas em qualquer namespace, incluindo kube-system
Aplicativos do Google Cloud Marketplace	Não é possível instalar apps do Cloud Marketplace.	É possível instalar apps pelo Cloud Marketplace.
Solicitações de assinatura de certificado	É possível criar solicitações de assinatura de certificado. Para evitar interferências com componentes do sistema, o Autopilot rejeita CertificateSigningRequests para identidades privilegiadas conhecidas, como agentes do sistema, grupos do sistema ou agentes de serviço do IAM gerenciados pelo Google.	É possível criar solicitações de assinatura de certificado.
Pods de tolerância a falhas de longa duração	É possível proteger pods intolerantes a falhas, como servidores de jogos, contra remoções causadas por upgrades automáticos ou redução de escala vertical dos nós por até sete dias. Para mais detalhes, consulte Estender o ambiente de execução dos pods do Autopilot.	Não é possível proteger pods intolerantes a falhas contra remoções causadas por upgrades automáticos de nós. É possível proteger esses pods contra remoção de redução da escala indefinidamente, mas você continua pagando pelos nós subutilizados em que os pods são executados.

A seguir

• Sobre as opções de configuração de clusters.
• Escolha um modo de operação.