Visão geral do Autopilot

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Nesta página, descrevemos o modo de operação Autopilot no Google Kubernetes Engine (GKE) e fornecemos recursos que podem ser usados para planejar, configurar e gerenciar seus clusters.

O que é o Autopilot?

O Autopilot do GKE é um modo de operação no GKE em que o Google gerencia a configuração do cluster, incluindo nós, escalonamento, segurança e outras configurações prévias. Os clusters do Autopilot são otimizados para executar a maioria das cargas de trabalho de produção e provisionar recursos de computação com base nos manifestos do Kubernetes. A configuração simplificada segue as práticas recomendadas e recomendações do GKE para configuração, escalonabilidade e segurança do cluster e da carga de trabalho. Para ver uma lista de configurações integradas, consulte a Tabela de comparação do Autopilot e Standard.

Preços

Você só paga pela CPU, pela memória e pelo armazenamento que as cargas de trabalho solicitarem enquanto são executadas no Autopilot do GKE.

Você não é cobrado pela capacidade não utilizada nos nós, porque o GKE gerencia os nós. Você também não é cobrado por pods do sistema, custos de sistema operacional ou cargas de trabalho não programadas. Para informações detalhadas sobre preços, consulte preços do Autopilot.

Benefícios

  • Foco nos aplicativos: o Google gerencia a infraestrutura. Assim, você se concentra na criação e na implantação dos seus aplicativos.
  • Segurança: os clusters têm uma configuração reforçada de proteção padrão, com muitas configurações de segurança ativadas por padrão. O GKE aplica automaticamente os patches de segurança aos nós, quando disponíveis, aderindo a qualquer programação de manutenção configurada.
  • Preços: o modelo de preços do Autopilot simplifica as previsões de faturamento e a atribuição, porque é baseado nos recursos solicitados pelos pods.
  • Gerenciamento de nós: o Google gerencia nós de trabalho. Assim, você não precisa criar novos nós para acomodar cargas de trabalho ou configurar upgrades e reparos automáticos.
  • Escalonamento: quando suas cargas de trabalho tiverem carga elevada e você adicionar mais pods para acomodar o tráfego, como com o escalonamento automático e horizontal de pods do Kubernetes, o GKE provisiona automaticamente novos nós para esses pods e expande automaticamente os recursos nos nós atuais com base na necessidade.
  • Programação: o Autopilot gerencia o empacotamento de pods para você. Assim, não é necessário pensar em quantos pods estão em execução em cada nó. É possível controlar ainda mais o posicionamento de pods usando mecanismos do Kubernetes, como afinidade e topologia de propagação de pod.
  • Gerenciamento de recursos: se você implantar cargas de trabalho sem definir valores de recursos, como CPU e memória, o Autopilot definirá automaticamente os valores padrão pré-configurados e modificará as solicitações de recursos no nível da carga de trabalho.
  • Rede: o Autopilot ativa alguns recursos de segurança de rede por padrão, como garantir que todo o tráfego de rede do pod passe pelas regras de firewall da nuvem privada virtual, mesmo que o tráfego esteja indo para outros pods do cluster.
  • Gerenciamento da versão: todos os clusters do Autopilot são registrados em um canal de lançamento do GKE, o que garante que seu plano de controle e os nós sejam executados nas versões qualificadas mais recentes desse canal.
  • Flexibilidade gerenciada: se as cargas de trabalho tiverem requisitos específicos de hardware ou recursos, como alto uso de CPU ou memória, o Autopilot oferecerá classes de computação pré-configuradas feitas para essas cargas de trabalho. Você solicita a classe de computação na sua implantação em vez de criar manualmente novos nós baseados em tipos de máquina e hardware personalizados. Também é possível selecionar GPUs para acelerar cargas de trabalho como aplicativos em lote ou de IA/ML.
  • Menor complexidade operacional: o Autopilot reduz a sobrecarga de administração da plataforma removendo a necessidade de monitorar continuamente os nós, o escalonamento e as operações de programação.

O Autopilot vem com um SLA que abrange o plano de controle e a capacidade de computação usada pelos pods.

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

O Autopilot permite solicitar recursos de CPU, memória e armazenamento temporário para suas cargas de trabalho. Os intervalos permitidos dependem de se você quer executar os pods na plataforma de computação de uso geral padrão ou em uma classe de computação. Para informações sobre as solicitações de recursos de contêiner padrão e os intervalos de recursos permitidos, consulte Solicitações e limites de recursos no Autopilot

Limitações e restrições de carga de trabalho no Autopilot

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"

Na versão 1.21 e posteriores do GKE, o recurso "SYS_PTRACE" também é compatível com cargas de trabalho.

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.

Também é possível usar seletores e afinidade de nós para os seguintes objetivos:

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, kubernetes.io/hostname 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.

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.

Limitações de segurança no Autopilot

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 os contêineres. O PodSecurityPolicy do Kubernetes não é compatível com clusters do Autopilot. Nas versões do GKE anteriores à 1.21, o OPA Gatekeeper e o Policy Controller também não são compatíveis.

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 no Autopilot

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.

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

Não é possível fazer alterações nos nós do Autopilot, como alterações no tipo de máquina subjacente, se as cargas de trabalho tem requisitos de computação específicos.

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 SSH para nós

Como você não está mais provisionando 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.

Ainda é possível se conectar remotamente aos seus contêineres em execução usando a funcionalidade exec do Kubernetes para executar comandos nos contêineres para depuração, incluindo a conexão a um shell interativo, por exemplo, com kubectl exec -it deploy/YOUR_DEPLOYMENT -- sh.

Limites de recursos

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.

Geração de registros da porta serial

Os clusters do Autopilot exigem que a geração de registros de porta serial esteja ativada para depurar e resolver problemas nos nós. Se sua organização do Google Cloud tiver uma política da organização que aplique a restrição compute.disableSerialPortLogging, novos nós talvez não sejam provisionados.

Peça ao administrador da política da organização que remova essa restrição em projetos com clusters do Autopilot.

Limitações de webhooks

Na versão 1.21 e posteriores do GKE, também é possível criar webhooks de admissão dinâmica mutáveis. No entanto, o Autopilot modifica os objetos de webhook mutáveis para adicionar um seletor de namespace que exclua os recursos em namespaces gerenciados (atualmente, kube-system) da interceptação. Além disso, os webhooks que especificam um ou mais dos seguintes recursos (e qualquer um dos sub-recursos) nas regras serão rejeitados:

- group: ""
  resource: nodes
- group: ""
  resource: persistentvolumes
- group: certificates.k8s.io
  resource: certificatesigningrequests
- group: authentication.k8s.io
  resource: tokenreviews

Não é possível usar o token *, que representa todos os valores, no campo resources ou groups para permitir os recursos anteriores.

Limitação de representação do usuário

A versão 1.22.4-gke.1501 e mais recente do GKE é compatível com a representação do usuário para todos os usuários e grupos definidos pelo usuário. Usuários e grupos do sistema, como o usuário kube-apiserver e o grupo system:masters, não podem ser representados.

Nenhum aplicativo do Google Cloud Marketplace

Não é possível instalar apps do Cloud Marketplace em clusters do Autopilot.

Solução de problemas

Para etapas de solução de problemas, consulte Como solucionar problemas de clusters do Autopilot.

A seguir