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.
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 | Standard |
|---|---|---|
| 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. |
| Namespaces gerenciados pelo GKE | Como medida de segurança, o Autopilot não permite implantar
cargas de trabalho em namespaces gerenciados pelo GKE, como
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. |