Visão geral do Autopilot

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

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 de comparação Autopilot e Standard 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.

Veja alguns motivos 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.

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