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 os clusters.
Esta página é para administradores, arquitetos e operadores que definem soluções de TI e arquitetura de sistemas. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e funções de usuário comuns do GKE Enterprise.
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
Na maioria das situações, você paga apenas pela CPU, memória e armazenamento que suas cargas de trabalho solicitam durante a execução no GKE Autopilot. 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.
Vantagens
- Concentre-se nos seus apps: o Google gerencia a infraestrutura para que você possa se concentrar na criação e implantação dos seus aplicativos.
- Segurança: os clusters têm uma configuração reforçada 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 e a atribuição de faturamento.
- 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 apresentam cargas de trabalho altas e você adiciona mais pods para acomodar o tráfego, como no escalonamento automático 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 que você não precise pensar em quantos pods estão em execução em cada nó. É possível controlar ainda mais o posicionamento dos pods usando mecanismos do Kubernetes, como a topologia de afinidade e distribuição de pods.
- Gerenciamento de recursos: se você implantar cargas de trabalho sem definir valores de recursos, como CPU e memória, o Autopilot vai definir automaticamente valores padrão pré-configurados e modificar as solicitações de recursos no nível da carga de trabalho de dois minutos.
- 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 usados pelos pods.
Planejar os clusters do Autopilot
Antes de criar um cluster, planeje e projete sua arquitetura do Google Cloud. No Autopilot, você solicita hardware nas especificações da carga de trabalho. O GKE provisiona e gerencia a infraestrutura correspondente para executar essas cargas de trabalho. Por exemplo, se você executar cargas de trabalho de machine learning, será preciso solicitar aceleradores de hardware. Se você desenvolver apps Android, vai solicitar CPUs Arm.
Planeje e solicite cotas para seu projeto ou organização do Google Cloud com base na escala das suas cargas de trabalho. O GKE só poderá provisionar a infraestrutura para suas cargas de trabalho se o projeto tiver cota suficiente para esse hardware.
Considere os seguintes fatores durante o planejamento:
- Tamanho e escala estimados do cluster
- Tipo de carga de trabalho
- Layout e uso do cluster
- Layout e configuração de rede
- Configuração de segurança
- Gerenciamento e manutenção de clusters
- Implantação e gerenciamento de cargas de trabalho
- Geração de registros e monitoramento
As seções a seguir fornecem informações e recursos úteis para essas considerações.
Rede
Quando você cria um cluster do Autopilot com rede pública, as cargas de trabalho no cluster podem se comunicar entre si e com a Internet. Esse é o modo de rede padrão. O Google Cloud e o Kubernetes oferecem vários outros recursos de rede que podem ser aproveitados com base no seu caso de uso, como clusters com rede particular.
A rede no Kubernetes e na nuvem é complexa. Antes de começar a mudar os padrões definidos pelo Google Cloud, confira se você conhece os conceitos básicos de rede. A tabela a seguir apresenta recursos para você saber mais sobre rede no GKE com base no caso de uso:
| Caso de uso | Recursos |
|---|---|
| Entender como a rede funciona no Kubernetes e no GKE |
Depois de conhecer o modelo de rede, pense nos requisitos de rede e segurança de rede da sua organização. Escolha os recursos de rede do GKE e do Google Cloud que atendam a esses critérios. |
| Planejar a configuração de rede do GKE | Recomendamos que você entenda as cotas de rede do GKE, como os endpoints por Serviço e os limites de solicitações de API. Os recursos a seguir ajudarão você a planejar aspectos específicos da sua configuração de rede:
|
| Expor as cargas de trabalho |
|
| Executar serviços conectados altamente disponíveis em vários clusters | Use Serviços de vários clusters (MCS). |
| Balanceamento de carga do tráfego de entrada |
|
| Configurar a segurança de rede do cluster |
|
| Observe o tráfego de rede do Kubernetes | Por padrão, o Autopilot usa o GKE Dataplane V2 para métricas e observabilidade.
|
Escalonamento
O uso eficiente de uma plataforma em grande escala requer planejamento e consideração cuidadosa. Considere a escalonabilidade do design, que é a capacidade de clusters crescerem e permanecerem dentro dos objetivos de nível de serviço (SLOs). Para receber orientações detalhadas para administradores e desenvolvedores da plataforma, consulte as Diretrizes para criar clusters escalonáveis.
Considere também as cotas e limites do GKE, especialmente se você planeja executar clusters grandes com milhares de pods.
Escalonar cargas de trabalho do Autopilot
No Autopilot, o GKE escalona automaticamente os nós com base no número de pods no cluster. Se um cluster não tiver cargas de trabalho em execução, o Autopilot pode reduzir o cluster automaticamente para zero nós. Na maioria dos clusters do Autopilot recém-criados, é possível notar que as primeiras cargas de trabalho implantadas levam mais tempo para serem programadas. Isso ocorre porque o novo cluster do Autopilot começa sem nós utilizáveis na criação e aguarda até que você implante uma carga de trabalho para provisionar mais nós.
Para escalonar automaticamente o número de pods no cluster, recomendamos usar um mecanismo como o escalonamento automático e horizontal de pods do Kubernetes, que pode escalonar pods com base em métricas de CPU e memória ou métricas personalizadas do Cloud Monitoring. Para saber como configurar o escalonamento com base em várias métricas, consulte Otimizar o escalonamento automático de pods com base em métricas.
Segurança
Por padrão, os clusters do Autopilot ativam e aplicam práticas recomendadas de segurança e configurações, incluindo muitas das recomendações em Como aumentar a segurança do cluster e a Visão geral de segurança do GKE.
Se você quiser saber mais sobre as medidas de proteção do Autopilot e como implementar requisitos de segurança específicos, consulte Medidas de segurança no Autopilot.
Crie um cluster
Depois de planejar o ambiente e entender os requisitos, crie um cluster do Autopilot. Os novos clusters do Autopilot são regionais e têm um endereço IP acessível publicamente. Cada cluster aplica medidas de aumento da proteção com valores de referência, além de escalonamento automático e outros recursos. Para ver uma lista completa de recursos pré-configurados, consulte Comparar o Autopilot do GKE e o Standard.
Se você quiser criar o cluster sem um endereço IP público, crie um cluster particular.
Implantar cargas de trabalho no Autopilot
Para implantar uma carga de trabalho em um cluster do Autopilot em execução, grave um manifesto do Kubernetes e aplique-o ao cluster. Por padrão, os clusters do Autopilot são otimizados para executar a maioria das cargas de trabalho de produção.
Para ver um guia interativo no console do Google Cloud para implantar e expor um aplicativo, clique em Orientações:
Algumas das cargas de trabalho podem ter requisitos de hardware especializados, como cargas de trabalho de ML que precisam de aceleradores de hardware ou testes de apps para dispositivos móveis que exigem a arquitetura Arm. O Autopilot tem classes de computação pré-definidos que o Google Cloud configurou para executar cargas de trabalho com requisitos de computação especiais. Se você tiver requisitos de hardware mais específicos, poderá definir suas próprias classes de computação personalizadas. Ao implantar essas cargas de trabalho especializadas, solicite uma classe de computação no manifesto. O Autopilot provisiona automaticamente nós com suporte de máquinas especializadas, gerencia programações e aloca hardware.
Veja na tabela a seguir alguns requisitos comuns e recomendações sobre o que fazer:
| Caso de uso | Recursos |
|---|---|
| Controlar propriedades de nós individuais ao dimensionar um cluster | Implante uma classe de computação personalizada e solicite-a no manifesto da carga de trabalho. Para mais detalhes, consulte Sobre as classes de computação personalizadas. |
| Executar cargas de trabalho do Arm | Solicite a classe de computação Scale-Out e a arquitetura arm64 no manifesto. Para ver instruções, consulte Implantar cargas de trabalho do Autopilot na arquitetura do Arm. |
| Executar cargas de trabalho de IA/ML aceleradas | Solicite GPUs no manifesto. Para instruções, consulte Implantar cargas de trabalho da GPU no Autopilot. |
| Executar cargas de trabalho que exigem alta capacidade de computação ou memória | Solicite a classe de computação Balanced. Para instruções, consulte Escolher classes de computação para pods do Autopilot. |
| Executar cargas de trabalho que exigem escalonamento horizontal mais eficiente da capacidade da CPU e computação por uma única linha de execução por núcleo | Solicite a classe de computação Scale-Out. Para instruções, consulte Escolher classes de computação para pods do Autopilot. |
| Executar cargas de trabalho tolerantes a falhas, como jobs em lote com custos menores | Especifique Pods do Spot no manifesto. Para instruções, consulte Executar cargas de trabalho tolerantes a falhas com custos menores em pods do Spot. É possível usar qualquer configuração de hardware ou classe de computação com pods do Spot. |
| Executar cargas de trabalho que exigem interrupções mínimas, como servidores de jogo ou filas de trabalho | Especificar a anotação cluster-autoscaler.kubernetes.io/safe-to-evict=false na especificação do pod. Os pods são protegidos contra remoção
causada por upgrades automáticos de nós ou eventos de redução de escala vertical por até sete dias.
Para instruções, consulte Estender o ambiente de execução dos pods do Autopilot. |
| Permita que as cargas de trabalho ultrapassem as solicitações se houver recursos disponíveis e não utilizados na soma das solicitações de recursos do pod no nó. | Defina o limits do recurso como um valor mais alto que o requests
ou não defina limites de recursos.
Para mais instruções, acesse Configurar o bursting de pods no GKE. |
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
Separação da carga de trabalho
Os clusters do Autopilot são compatíveis com o uso de seletores de nós e afinidade de nós para
configurar a separação de cargas de trabalho. A separação de cargas de trabalho é útil quando você precisa informar ao GKE para colocar cargas de trabalho em nós que atendem a critérios específicos, como rótulos de nó personalizados. Por exemplo, é possível dizer ao GKE para
programar pods do servidor de jogos em nós com o rótulo game-server e evitar
a programação de outros pods nesses nós.
Para saber mais, consulte Configurar a separação de cargas de trabalho no GKE.
Programe pods em zonas específicas usando a topologia zonal
Se você precisar colocar pods em uma zona específica do Google Cloud, por exemplo, para acessar informações em um disco permanente zonal do Compute Engine, consulte Colocar pods do GKE em zonas específicas.
Afinidade e antiafinidade do pod
Use a afinidade e antiafinidade de pods para colocalizar os pods em um único nó ou fazer alguns pods evitarem outros. A afinidade e antiafinidade de pods dizem ao Kubernetes para tomar uma decisão de programação com base nos rótulos de pods em execução nos nós em um domínio de topologia específico, como uma região ou zona específica. Por exemplo, é possível dizer ao GKE para evitar a programação de pods de front-end junto a outros pods de front-end nos mesmos nós para melhorar a disponibilidade em caso de falha temporária.
Para instruções e mais detalhes, consulte Afinidade e antiafinidade de pods.
No GKE, é possível usar a afinidade e antiafinidade de pods com os
seguintes rótulos em topologyKey:
topology.kubernetes.io/zonekubernetes.io/hostname
Restrições de propagação de topologia de pods.
Para melhorar a disponibilidade das cargas de trabalho conforme o Kubernetes aumenta e
diminui o número de pods, defina restrições de propagação da topologia de pods. Isso
controla como o Kubernetes distribui seus pods em nós em um domínio de topologia,
como uma região. Por exemplo, é possível dizer ao Kubernetes para colocar um número
específico de pods de sessão do servidor de jogos em cada uma das três zonas do Google Cloud na
região us-central1.
Para exemplos, mais detalhes e instruções, consulte Restrições de propagação da Topologia de pod.
Gerenciar e monitorar seus clusters do Autopilot
No Autopilot, o GKE gerencia automaticamente upgrades e manutenção de cluster para o plano de controle e os nós de trabalho. Os clusters do Autopilot também têm funcionalidade integrada para você monitorar seus clusters e cargas de trabalho.
Upgrades da versão do GKE
Todos os clusters do Autopilot são registrados em um canal de lançamento. Nos canais de lançamento, o GKE gerencia a versão do Kubernetes do cluster, equilibrando a disponibilidade do recurso e a estabilidade da versão, dependendo do canal. Por padrão, os clusters do Autopilot são inscritos no canal de lançamento regular, mas é possível selecionar um canal diferente que atenda às suas necessidades de estabilidade e funcionalidade. Para mais informações sobre canais de lançamento, consulte Sobre canais de lançamento.
O GKE inicia automaticamente os upgrades, monitora o progresso e pausa a operação se ocorrerem problemas. É possível controlar manualmente o processo de upgrade das seguintes maneiras:
- Para controlar quando o GKE pode realizar upgrades automáticos, crie janelas de manutenção. Por exemplo, você pode definir a janela de manutenção para a noite anterior à redefinição semanal do jogo multijogador, de modo que os jogadores possam fazer login na redefinição sem interrupções.
- Para controlar quando o GKE não pode iniciar upgrades automáticos durante um período específico, use exclusões de manutenção. Por exemplo, é possível definir uma exclusão de manutenção durante o evento de vendas da Black Friday e da Cyber Monday para que os clientes possam fazer compras sem problemas.
- Para ter uma nova versão antes do início dos upgrades automáticos, faça upgrade do plano de controle manualmente. O GKE reconcilia a versão do nó com a versão do plano de controle ao longo do tempo.
- Para ver uma versão de patch que está disponível apenas em um canal de lançamento mais recente, consulte Executar versões de patch de um canal mais recente. Por exemplo, talvez você precise de uma versão de patch específica para reduzir uma divulgação de vulnerabilidade recente.
Monitorar os clusters do Autopilot
Os clusters do Autopilot já têm o Cloud Logging, o Cloud Monitoring e o Google Cloud Managed Service para Prometheus ativado.
Os clusters do Autopilot coletam automaticamente os seguintes tipos de registros e métricas, seguindo as práticas recomendadas do Google para coleta de telemetria:
Registros para o Cloud Logging
- Registros do sistema
- Registros de carga de trabalho
- Registros de auditoria de atividade do administrador
- Registros de auditoria de acesso a dados
Métricas do Cloud Monitoring
- Métricas do sistema
- Métricas de carga de trabalho (do Managed Service para Prometheus)
Nenhuma configuração adicional é necessária para ativar a geração de registros e o monitoramento. A tabela a seguir mostra como interagir com a telemetria coletada com base nos seus requisitos:
| Caso de uso | Recursos |
|---|---|
| Entender e acessar os registros do GKE |
|
| Observar o desempenho dos clusters do GKE | O monitoramento eficaz do desempenho do cluster pode ajudar você a otimizar os custos operacionais dos clusters e das cargas de trabalho.
|
| Monitorar a postura de segurança dos clusters | Use o painel de postura de segurança para auditar as cargas de trabalho em execução com base nas práticas recomendadas do GKE, verificar vulnerabilidades nos sistemas operacionais e pacotes de linguagem do contêiner e receber recomendações de mitigação acionáveis. Para saber mais, consulte Sobre o painel de postura de segurança. |
Solução de problemas
Para etapas de solução de problemas, consulte Como solucionar problemas de clusters do Autopilot.