Visão geral do Autopilot


Introdução

O Autopilot é um novo modo de operação no Google Kubernetes Engine (GKE) projetado para reduzir o custo operacional de gerenciamento de clusters, otimizar seus clusters para produção e produzir maior disponibilidade de cargas de trabalho. O modo de operação refere-se ao nível de flexibilidade, responsabilidade e controle que você tem sobre o cluster. Além dos benefícios de um plano de controle e automação de nós totalmente gerenciados, o GKE oferece dois modos de operação:

  • Piloto automático: o GKE provisiona e gerencia a infraestrutura subjacente do cluster, incluindo nós e pools de nós, oferecendo um cluster otimizado com uma experiência prática.
  • Padrão: você gerencia a infraestrutura subjacente do cluster, oferecendo flexibilidade de configuração de nós.

Com o Autopilot, não é mais necessário monitorar a integridade dos nós ou calcular a quantidade de capacidade de computação necessária para suas cargas de trabalho. O Autopilot é compatível com a maioria das APIs, ferramentas e do amplo ecossistema do Kubernetes. Você mantém o GKE sem precisar interagir com as APIs, CLIs ou IU do Compute Engine, porque os nós não são acessíveis por meio do Compute Engine, como no modo Standard. Você paga apenas pela CPU, memória e armazenamento que seus pods solicitam enquanto estão em execução.

Os clusters do piloto automático são pré-configurados com uma configuração de cluster otimizada pronta para cargas de trabalho de produção. Essa configuração simplificada segue as práticas recomendadas e recomendações do GKE para configuração e segurança de cluster e carga de trabalho. Algumas dessas configurações integradas (detalhadas na tabela abaixo são imutáveis e outras configurações opcionais podem ser ativadas ou desativadas).

O Autopilot tem um SLA que abrange o plano de controle e os pods. Com o Autopilot, como a infraestrutura subjacente é abstraída, é possível se concentrar na API Kubernetes e nas implantações. O Autopilot usa os requisitos de recursos que você define no PodSpec e provisiona os recursos para implantação, como CPU, memória e discos permanentes.

Há dois motivos principais para usar o modo de operação padrão, em vez do Autopilot:

  • Você precisa de um nível maior de controle sobre a configuração do cluster.
  • Os clusters precisam executar cargas de trabalho que não atendam às restrições do Autopilot.

Comparação entre os modos Autopilot e Standard

Com o Autopilot, o GKE gerencia muitas complexidades do ciclo de vida do cluster. Veja na tabela a seguir as opções disponíveis dependendo do modo de operação do cluster:

  • Pré-configurada: esta configuração é integrada, e não é possível alterá-la.
  • Padrão: esta configuração está ativada, mas você pode modificá-la.
  • Opcional: essa configuração está desativada, mas você pode ativá-la.
Opções Modo Autopilot Modo padrão
Tipo de cluster básico Disponibilidade e versão:

Pré-configurada: Regional
Padrão: canal de lançamento normal
Disponibilidade e versão:

Opcional:
Nós e pools de nós Gerenciado pelo GKE. Gerenciado, configurado e especificado por você.
Provisionamento de recursos O GKE provisiona dinamicamente recursos com base na sua especificação de pod. Você provisiona manualmente recursos adicionais e define o tamanho geral do cluster. Configure o escalonamento automático de clusters e o provisionamento automático de nós para automatizar o processo.
Tipo de imagem Pré-configurada: SO Container-Optimized com Containerd Escolha uma destas opções:
Faturamento Solicitações de recursos por Pod (CPU, memória e armazenamento temporário) Pagamento por (CPU, memória, disco de inicialização)
Segurança Pré-configurada:
Opcional:
Opcional:
Rede Pré-configurada:
Default:
  • Cluster público
  • Intervalos CIDR padrão

    Observação: revise seus intervalos CIDR para considerar o crescimento esperado do cluster.

  • Nome/sub-rede da rede
Opcional:
Opcional:
Upgrades, reparos e manutenção Pré-configurada:
Opcional:
Credenciais de autenticação Pré-configurada: Identidade da carga de trabalho Opcional:
Escalonamento Pré-configurada: o Autopilot gerencia todo o escalonamento e a configuração dos nós.

Padrão:
Opcional:
Como monitorar e gerar registros Pré-configurada: Cloud Operations for GKE

Padrão: geração de registros de sistema e carga de trabalho

Opcional: geração de registros somente do sistema
Default:
Opcional: geração de registros apenas do sistema
Roteamento Pré-configurada: roteamento baseado em pod. NEGs de rede são ativados. Roteamento de pacote baseado em nó (padrão) ou roteamento baseado em pod.
Complementos do cluster Pré-configurada:
Default:
Opcional:

1Outras configurações necessárias para ativar o Cloud NAT em um cluster.

Recursos de cluster incompatíveis

Os seguintes recursos de cluster do GKE não são compatíveis com clusters Autopilot:

Instâncias do Compute Engine

Segurança

Complementos e integrações

Escalonamento

O Autopilot faz o escalonamento automático dos recursos do cluster com base nas especificações do pod, para que seja possível se concentrar nos pods. Para aumentar ou diminuir automaticamente o número de pods, implemente o escalonamento automático de pod horizontal usando as métricas padrão de CPU ou memória do Kubernetes ou use métricas personalizadas por meio do Cloud Monitoring.

Intervalos de recursos permitidos

A tabela a seguir lista os intervalos de recursos permitidos para pods de Autopilot. Todos os valores se aplicam à soma de todas as solicitações de recursos do contêiner no pod, a menos que indicado de outra forma. A vCPU do pod está disponível em incrementos de 0,25 vCPU. Além dos valores mínimos, a proporção CPU:memória precisa estar no intervalo de 1 vCPU:1 GiB a 1 vCPU:6,5 GiB. Recursos fora dos intervalos permitidos serão aumentados. Para mais informações, consulte Intervalos de recursos e gerenciamento de proporções e exemplos de limitação de recursos.

Recurso Recursos mínimos Recursos máximos
Pods normais Pods do DaemonSet Pods normal e DaemonSet
CPU 250 mCPU 250 mCPU 28 vCPU2
Memória 512 MiB 10 MiB 80 GiB2
Armazenamento temporário 10 MiB (por contêiner) 10 MiB (por contêiner) 10 GiB

2Os limites máximos de CPU e memória para pods normais são reduzidos ainda mais pela soma total das solicitações de recursos de todos os pods do DaemonSet.

Solicitações padrão de recursos do contêiner

O Autopilot depende do que você especifica na configuração de implantação para provisionar recursos. Se você não especificar solicitações de recursos para qualquer contêiner no pod, o Autopilot aplicará valores padrão. Esses padrões são projetados para dar aos contêineres nos seus pods uma quantidade média de recursos, que são adequados para muitas cargas de trabalho menores.

O Autopilot aplica esses valores padrão a recursos que não estão definidos na especificação de pod.

Recurso Contêineres em pods normais Contêineres em DaemonSets
CPU 500 mCPU 50 mCPU
Memória 2 GiB 100 MiB
Armazenamento temporário 1 GiB 100 MiB

Para mais informações sobre os limites do cluster do Autopilot, consulte Cotas e limites.

Limitações e restrições da carga de trabalho

O Autopilot é compatível com a maioria das cargas de trabalho que executam seus aplicativos. Para que o GKE ofereça o gerenciamento dos nós e ofereça uma experiência operacional mais simplificada, há algumas restrições e limitações em comparação com o GKE Standard. Algumas dessas limitações são práticas recomendadas de segurança e outras permitem que os clusters do AutoPilot sejam gerenciados com segurança. As limitações de carga de trabalho se aplicam a todos os pods, incluindo aqueles lançados por implantações, DaemonSets, ReplicaSets, ReplicationControllers, StatefulSets, jobs e CronJobs.

Restrições de opções de host

HostPort e hostNetwork não são permitidos porque o gerenciamento de nós é gerenciado pelo GKE. O uso de volumes hostPath no modo de gravação é proibido, enquanto os volumes hostPath no modo de leitura só são permitidos para prefixos de caminho /var/log/. O uso de namespaces de host em cargas de trabalho é proibido.

Limitações de carga de trabalho do Linux

O Autopilot é compatível apenas com os seguintes recursos do Linux para cargas de trabalho:

"SETPCAP", "MKNOD", "AUDIT_WRITE", "CHOWN", "DAC_OVERRIDE", "FOWNER",
"FSETID", "KILL", "SETGID", "SETUID", "NET_BIND_SERVICE", "SYS_CHROOT", "SETFCAP"

Seletores de nós e afinidade de nó

Topologias de afinidade por zona são compatíveis. Afinidade do nó e seletores de nós são limitados para uso apenas com as seguintes chaves: topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, cloud.google.com/gke-os-distribution, kubernetes.io/os e kubernetes.io/arch. Nem todos os valores de SO e arco são compatíveis com o Autopilot.

Sem detecção de ameaça de contêiner

O Autopilot não é compatível com o Container Threat Detection.

Nenhum pod com privilégios

O modo privilegiado para contêineres em cargas de trabalho é usado principalmente para fazer alterações em nós, como alterar as configurações do kubelet ou de rede. Com os clusters do Autopilot, as alterações de nó não são permitidas. Portanto, esses tipos de pods também não são permitidos. Essa restrição pode afetar algumas cargas de trabalho administrativas.

Afinidade e antiafinidade do pod

Ainda que o GKE gerencie seus nós para você no Autopilot, você retém a capacidade de programar seus pods. O piloto automático é compatível com a afinidade de pod, assim é possível localizar pods em um único nó para aumentar a eficiência da rede. Por exemplo, é possível usar a afinidade de pods para implantar pods de front-end nos nós com pods de back-end. A afinidade de pod é limitada para uso apenas com as seguintes chaves: topology.kubernetes.io/region, topology.kubernetes.io/zone, failure-domain.beta.kubernetes.io/region e failure-domain.beta.kubernetes.io/zone.

O Autopilot também é compatível com antiafinidade para que seja possível espalhar pods nos nós a fim de evitar pontos únicos de falha. Por exemplo, é possível usar a antiafinidade de pods para impedir que os pods de front-end sejam localizados junto com eles.

Padrões e limitações de recursos ao usar a antiafinidade de pods

O Autopilot é compatível com a antiafinidade de pods, para que seja possível impedir que dois pods sejam colocados juntos no mesmo nó. Ao usar a antiafinidade, o Autopilot precisa alocar recursos de computação adicionais para garantir a separação adequada do pod, conforme definido pelo PodSpec. Ao usar a antiafinidade de pods, os padrões e os limites mínimos de recursos aumentam. Para todos os contêineres listados em PodSpec:

Recurso Valor padrão
CPU 0,75 vCPU
Memória 2 GiB
Armazenamento temporário 1 GiB

Quando se usa a antiafinidade de pods, são aplicadas as mesmas regras e limitações lógicas, mas com incrementos de vCPU maiores. A vCPU do pod é oferecida em um mínimo de 0,5 vCPU, e incrementos de 0,5 vCPU, arredondados para o incremento mais próximo. Por exemplo, se você solicitar um total de 0,66 vCPU (entre todos os contêineres usando antiafinidade), o PodSpec será modificado durante a admissão e definido como 1 vCPU. Seu pod tem acesso total ao recurso superior, com o recurso extra dividido entre as solicitações de todos os contêineres.

Tolerâncias compatíveis apenas com separação das cargas de trabalho

As tolerâncias são compatíveis somente com a separação de cargas de trabalho. Os taints são adicionados automaticamente pelo provisionamento automático de nós, conforme necessário.

Intervalos de recursos e gerenciamento de proporção

  • Aumento de vCPUs no pod: a vCPU do pod está disponível em incrementos de 0,25 vCPU (arredondado para cima). Por exemplo, se você solicitar um total de 0,66 vCPU (entre todos os contêineres), o PodSpec será modificado durante a admissão e definido como 0,75. Seu pod tem acesso total ao recurso superior, com o recurso extra dividido entre as solicitações de todos os contêineres. O valor mínimo é 250 miliCPU (mCPU). A vCPU do DaemonSet é oferecida em incrementos de 10 mCPU (arredondado para o incremento mais próximo).

  • Intervalo de proporção de memória para CPU: a proporção de memória (em GiB) para vCPU precisa estar no intervalo de 1 a 6,5 vCPUs. Por exemplo, é possível ter um pod com 1 vCPU e 1 GiB de memória ou 1 vCPU e 6,5 GiB de memória, mas não 1 vCPU e 7 GiB de memória. Para entregar a solicitação de recursos, o GKE dimensiona qualquer recurso que esteja muito baixo. Por exemplo, se você solicitar 1 vCPU e 7 GiB de memória, o PodSpec será modificado para 1,25 vCPU e 7 GiB de memória na admissão. Da mesma forma, se você solicitar 1 vCPU e 800 MiB de memória, seu PodSpec será modificado para 1 vCPU e 1 GiB de RAM, com o recurso extra dividido entre os contêineres.

Os requisitos de proporção e proporção de CPU e memória e possível aumento de escala das solicitações de recursos são calculados depois que os padrões são aplicados aos contêineres com solicitações de recursos ausentes.

Os contêineres sem solicitações de recursos terão como padrão os mínimos padrão de 500 mCPU e 1 GiB de memória. Para CPU e memória, quando o GKE aumenta uma solicitação de recurso para mais (por exemplo, para atender ao requisito mínimo ou o requisito de proporção), o recurso extra é alocado uniformemente entre os contêineres. Valores arredondados são distribuídos proporcionalmente entre contêineres. Por exemplo, um contêiner que tem duas vezes mais memória do que os outros receberá duas vezes mais memória.

  • Armazenamento temporário: o intervalo disponível está entre 10 MiB e 10 GiB. Isso afeta as camadas graváveis do contêiner e as montagens de emptyDir.

O armazenamento temporário tem uma solicitação mínima por contêiner, portanto, se as solicitações de armazenamento temporário de um contêiner forem menores que o mínimo, o AutoPilot aumentará a solicitação para o mínimo. O armazenamento temporário não tem uma solicitação mínima por pod. O armazenamento temporário tem uma solicitação máxima por pod, que é cumulativa em todos os contêineres. Se o valor cumulativo for maior que o máximo, o AutoPilot dimensionará a solicitação de volta ao máximo e, ao mesmo tempo, garantirá que a proporção de solicitações entre contêineres permaneça a mesma.

Exemplos de limitação de recursos

Exemplo 1: para um único contêiner com < mínimo de 250 mCPU:

Número do contêiner Solicitações de recursos originais Solicitações modificadas
1 CPU: 180 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
CPU: 250 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
Recursos totais do pod CPU: 250 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB

Exemplo 2: para vários contêineres, com um total de < 250 mCPU no mínimo, o Autopilot distribui o restante dos recursos (até 250 vCPU) de maneira uniforme entre todos os contêineres no pod.

Número do contêiner Solicitações de recursos originais Solicitações modificadas
1 CPU: 70 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
CPU: 84 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
2 CPU: 70 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
CPU: 83 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
3 CPU: 70 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
CPU: 83 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
Recursos totais do pod CPU: 250 mCPU
Memória: 1,5 GiB
Armazenamento temporário: 30 MiB

Exemplo 3: para vários contêineres com recursos totais >= 250 mCPU, a CPU é arredondada para múltiplos de 250 mCPU e a CPU extra é distribuída por todos os contêineres na proporção das solicitações originais. Neste exemplo, a CPU cumulativa original é 320 mCPU e é modificada para um total de 500 mCPU. O 180 mCPU extra é distribuído nos contêineres:

Número do contêiner Solicitações de recursos originais Solicitações modificadas
1 CPU: 170 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
CPU: 266 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
2 CPU: 80 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
CPU: 125 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
3 CPU: 70 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
CPU: 109 mCPU
Memória: 0,5 GiB
Armazenamento temporário: 10 MiB
4 Contêiner de inicialização, recursos não definidos Receberá recursos de pod
Recursos totais do pod CPU: 500 mCPU
Memória: 1,5 GiB
Armazenamento temporário: 30 MiB

Exemplo 4: para um único contêiner em que a CPU é muito baixa para a quantidade de memória (1 vCPU:6,5 GiB no máximo). A proporção máxima permitida para CPU para memória é de 1:6,5. Se a proporção for maior que isso, a solicitação de CPU aumentará e será arredondada para cima, se necessário:

Número do contêiner Solicitações de recursos originais Solicitações modificadas
1 CPU: 250 mCPU
Memória: 4 GiB
Armazenamento temporário: 10 MiB
CPU: 750 mCPU
Memória: 4 GiB
Armazenamento temporário: 10 MiB
Recursos totais do pod CPU: 750 mCPU
Memória: 4 GiB
Armazenamento temporário: 10 MiB

Exemplo 5: para um único contêiner em que a memória é muito baixa para a quantidade de CPU (1 vCPU:1 GiB mínima). A proporção mínima permitida para CPU para memória é 1:1. Se a proporção for menor que isso, a solicitação de memória aumentará.

Número do contêiner Solicitações de recursos originais Solicitações modificadas
1 CPU: 4 vCPUs
Memória: 1 GiB
Armazenamento temporário: 10 MiB
CPU: 4 vCPUs
Memória: 4 GiB
Armazenamento temporário: 10 MiB
Recursos totais do pod CPU: 4 mCPU
Memória: 4 GiB
Armazenamento temporário: 10 MiB

Exemplo 6: para um único contêiner com < 250 mCPU no mínimo, em que, após o ajuste, a CPU é muito baixa para a quantidade de memória (1 vCPU:6,5 GiB, no máximo).

Número do contêiner Solicitações de recursos originais Solicitações modificadas
1 CPU: 100 mCPU
Memória: 50 MiB
Armazenamento temporário: 10 MiB
CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 10 MiB
Recursos totais do pod CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 10 MiB

Exemplo 7: para um único contêiner com solicitações de armazenamento temporário > 10 GiB, a solicitação máxima de armazenamento temporário permitida é 10 GiB. Se a solicitação for maior que o valor máximo, ela será reduzida para 10 GiB.

Número do contêiner Solicitações de recursos originais Solicitações modificadas
1 CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 11 GiB
CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 10 GiB
Recursos totais do pod CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 10 GiB

Exemplo 8: para vários contêineres com solicitações de armazenamento temporárias maiores que 10 GiB, todas as solicitações de armazenamento temporário do contêiner são reduzidas para fazer a solicitação de armazenamento cumulativo final de 10 GiB.

Número do contêiner Solicitações de recursos originais Solicitações modificadas
1 CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 5 GiB
CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 2,94 GiB
2 CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 6 GiB
CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 3,53 GiB
3 CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 6 GiB
CPU: 250 mCPU
Memória: 256 MiB
Armazenamento temporário: 3,53 GiB
Recursos totais do pod CPU: 750 mCPU
Memória: 768 MiB
Armazenamento temporário: 10 GiB

Limitações de segurança

Isolamento de contêiner

O Autopilot aplica uma configuração reforçada para os pods que fornece isolamento de segurança aprimorado e ajuda a limitar o impacto das vulnerabilidades de escape do contêiner no cluster:

  • O perfil seccomp padrão do ambiente de execução de contêiner é aplicado, por padrão, a todos os pods no cluster.
  • A permissão de contêiner CAP_NET_RAW é descartada para todos os contêineres. A permissão CAP_NET_RAW não costuma ser usada e era alvo de várias vulnerabilidades de escape do contêiner. A falta de CAP_NET_RAW pode causar falha no uso de ping no contêiner.
  • A Identidade da carga de trabalho é aplicada e impede o acesso do pod à conta de serviço subjacente do Compute Engine e a outros metadados confidenciais de nós.
  • Os serviços com o conjunto spec.ExternalIPs estão bloqueados para se proteger contra o CVE-2020-8554. Esses serviços raramente são usados.
  • Os StorageTypes a seguir são permitidos. Outros StorageTypes são bloqueados porque exigem privilégios sobre o nó:

    "configMap", "csi", "downwardAPI", "emptyDir", "gcePersistentDisk", "hostPath",
    "nfs", "persistentVolumeClaim", "projected", "secret"
    

Políticas de segurança de pods

O Autopilot aplica configurações que fornecem isolamento aprimorado para seus contêineres. O PodSecurityPolicy, o OPA Gatekeeper e o Controlador de políticas do Kubernetes não são compatíveis com clusters do Autopilot.

Limites de segurança no Autopilot

Na camada do Kubernetes, o modo Autopilot do GKE fornece a API Kubernetes, mas remove permissões para usar alguns primitivos do Kubernetes altamente privilegiados, como pods com privilégios, com a meta de limitar a capacidade de acessar, modificar ou controlar diretamente a máquina virtual (VM, na sigla em inglês) do nó.

Essas restrições são implantadas para que o modo Autopilot do GKE permita às cargas de trabalho apenas o acesso básico à VM do nó, para que o Google Cloud ofereça gerenciamento completo dos nós e um SLA no nível do pod.

Nossa intenção é impedir o acesso indesejado à máquina virtual do nó. Aceitamos envios nesse sentido por meio do Programa de recompensa por vulnerabilidade do Google (VRP, na sigla em inglês) e recompensaremos os relatórios de acordo com o painel de recompensas do Google VRP.

Por padrão, usuários privilegiados, como administradores de cluster, têm controle total de qualquer cluster do GKE. Como prática recomendada de segurança, evite conceder privilégios avançados do GKE/Kubernetes amplamente. Em vez disso, use a delegação de administrador do namespace sempre que possível, conforme descrito na nossa orientação de multilocação.

As cargas de trabalho no Autopilot continuam desfrutando da mesma segurança do modo GKE Standard, em que as VMs de locatário individual são provisionadas no projeto do usuário para uso exclusivo. E, como o Standard, em cada VM individual, as cargas de trabalho do Autopilot em um cluster podem ser executadas juntas em uma VM com um kernel com aumento da proteção, mas compartilhado.

Como o kernel compartilhado representa um único limite de segurança, o GKE recomenda que, se você precisar de isolamento forte, como cargas de trabalho de alto risco ou não confiáveis, execute suas cargas de trabalho nos clusters do GKE Standard usando o GKE Sandbox. para fornecer proteção de segurança em várias camadas.

Outras limitações

Solicitações de assinatura de certificado

Não é possível criar solicitações de assinatura de certificado no Autopilot.

Ferramentas de monitoramento externas

A maioria das ferramentas de monitoramento externas exige acesso restrito. As soluções de vários parceiros do Google Cloud estão disponíveis para uso no Autopilot, mas nem todos são compatíveis, e as ferramentas de monitoramento personalizadas não podem ser instaladas em clusters do Autopilot.

Serviços externos

Os serviços de IP externo não são permitidos nos clusters do Autopilot. Para fornecer um IP externo a um serviço use um tipo de serviço ou uma entrada de LoadBalancer para adicionar o serviço a um IP externo compartilhado entre vários serviços.

Init containers

Os contêineres de inicialização são executados em série antes da inicialização dos contêineres de aplicativos. Por padrão, o GKE aloca todos os recursos disponíveis para o pod para cada contêiner de inicialização.

Ao contrário dos outros contêineres, o GKE recomenda deixar as solicitações de recurso não especificadas para contêineres "init", para que os contêineres tenham os recursos completos. Se você definir recursos inferiores, seu contêiner init será restrito desnecessariamente e, se você definir recursos mais altos, poderá aumentar sua fatura durante a vida útil do pod.

Namespaces gerenciados

O namespace kube-system é gerenciado, o que significa que todos os recursos neste namespace não podem ser alterados e não é possível criar novos recursos.

Nenhuma alteração nos nós

Como o GKE gerencia os nós para clusters de Autopilot, não é possível alterar os nós.

Sem conversão

A conversão de clusters padrão no modo Autopilot e a conversão de clusters de Autopilot no modo Standard não são compatíveis.

Nenhuma conexão de entrada externa direta para clusters privados

Os clusters de Autopilot com nós particulares não têm IPs externos e não podem aceitar conexões de entrada diretamente. Se você implantar serviços em um NodePort, não será possível acessá-los de fora da VPC, como da Internet. Para expor aplicativos externamente em clusters de Autopilot, use Serviços. Para mais informações, consulte Como exibir aplicativos usando serviços.

Sem bursting de pod

Para clusters padrão, os pods podem ser configurados para usar burst em capacidades não utilizadas no nó. Para clusters do Autopilot, como todos os pods têm limites definidos em solicitações, o bursting de recursos não é possível. É importante garantir que a especificação do pod defina recursos adequados para as solicitações de recursos e não dependa de bursting.

Sem encaminhamento de portas

Os clusters do Autopilot não são compatíveis com o comando kubectl port-forward.

Sem SSH

Como você não está mais provisiona nem gerenciando os nós no Autopilot, não há acesso SSH. O GKE manipula todos os aspectos operacionais dos nós, incluindo a integridade do nó e todos os componentes do Kubernetes em execução nos nós.

Limites de recurso

Em um cluster de Autopilot, cada pod é tratado como um pod de classe QoS garantido, com limites que são iguais às solicitações. O Autopilot define automaticamente os limites de recursos iguais às solicitações se você não tiver limites de recursos especificados. Se você especificar limites de recursos, os limites serão modificados e definidos como iguais às solicitações.

Limitações de webhooks

Não é possível criar webhooks de mutação automática personalizados para clusters com Autopilot, mas é possível criar webhooks de validação personalizados.

Solução de problemas

Não é possível criar um cluster: nenhum nó registrado

Quando você cria um cluster do Autopilot, ele falha com o seguinte erro:

All cluster resources were brought up, but: only 0 nodes out of 2 have registered.

Para resolver o problema, verifique se a conta de serviço padrão do Compute Engine não está desativada. Execute o seguinte comando para verificar:

   gcloud iam service-accounts describe SERVICE_ACCOUNT

Substitua SERVICE_ACCOUNT pelo ID numérico da conta de serviço ou endereço de e-mail da conta de serviço (como 123456789876543212345 ou my-iam-account@somedomain.com).

A seguir