O Autopilot é um modo de funcionamento gerido no Google Kubernetes Engine (GKE). Esta página descreve as vantagens do modo de piloto automático e fornece informações sobre o planeamento de clusters, a implementação de cargas de trabalho e a configuração de rede e segurança. Os administradores, os arquitetos e os operadores podem usar estas informações para tomar decisões informadas ao avaliar como o modo Autopilot do GKE se alinha com os requisitos operacionais das respetivas cargas de trabalho contentorizadas.
Para mais informações sobre as diferenças entre os modos de funcionamento no GKE, consulte o artigo Compare o GKE Autopilot e o Standard.
O que é o Autopilot?
O GKE Autopilot é um modo de funcionamento no GKE em que a Google gere a configuração da sua infraestrutura, incluindo os nós, o escalamento, a segurança e outras definições pré-configuradas. O modo Autopilot está otimizado para executar a maioria das cargas de trabalho de produção e aprovisiona recursos de computação com base nos seus manifestos do Kubernetes.
Pode executar um cluster inteiro no modo Autopilot, para que o cluster e todas as respetivas cargas de trabalho sigam as práticas recomendadas e as recomendações do GKE para escalabilidade, segurança, atualizações e configuração de nós. Também pode executar cargas de trabalho específicas no modo Autopilot em clusters padrão do GKE. Esta opção permite-lhe usar o Autopilot em ambientes onde ainda precisa de controlo manual sobre a sua infraestrutura. Para mais informações, consulte o artigo Acerca das cargas de trabalho do modo Autopilot no GKE Standard.
Vantagens
- Foque-se nas suas apps: a Google gere a infraestrutura para que se possa focar na criação e implementação das suas aplicações.
- Segurança: os clusters do Autopilot têm uma configuração reforçada predefinida, com muitas definições de segurança ativadas por predefinição. O GKE aplica automaticamente patches de segurança aos seus nós quando disponíveis, seguindo os horários de manutenção que configurou.
- Preços: o modelo de preços do Autopilot simplifica as previsões de faturação e a atribuição.
- Gestão de nós: a Google gere os nós de trabalho, pelo que não tem de criar novos nós para acomodar as suas cargas de trabalho nem configurar atualizações e reparações automáticas.
- Escalabilidade: quando as suas cargas de trabalho experimentam uma carga elevada e adiciona mais pods para acomodar o tráfego, como com a escala automática horizontal de pods do Kubernetes, o GKE aprovisiona automaticamente novos nós para esses pods e expande automaticamente os recursos nos seus nós existentes com base na necessidade.
- Agendamento: o Autopilot gere o bin-packing de pods por si, para que não tenha de pensar em quantos pods estão a ser executados em cada nó. Pode controlar ainda mais o posicionamento de pods através de mecanismos do Kubernetes, como a afinidade e a topologia de dispersão de pods.
- Gestão de recursos: se implementar cargas de trabalho sem definir valores de recursos, como CPU e memória, o Autopilot define automaticamente valores predefinidos pré-configurados e modifica os seus pedidos de recursos ao nível da carga de trabalho.
- Rede: o Autopilot ativa algumas funcionalidades de segurança de rede por predefinição, como a passagem de todo o tráfego de rede de pods através das regras da firewall da nuvem privada virtual, mesmo que o tráfego se destine a outros pods no cluster.
- Gestão de lançamentos: todos os clusters do Autopilot estão inscritos num canal de lançamento do GKE para que o seu plano de controlo e nós sejam executados nas versões qualificadas mais recentes nesse canal.
- Flexibilidade gerida: se as suas cargas de trabalho tiverem requisitos de hardware ou de recursos específicos, como GPUs, pode definir esses requisitos nas ComputeClasses. Quando pede uma ComputeClass na sua carga de trabalho, o GKE usa os seus requisitos para configurar nós para os seus pods. Não precisa de configurar manualmente o hardware para nós ou cargas de trabalho individuais.
- Complexidade operacional reduzida: o Autopilot reduz as despesas gerais de administração da plataforma, eliminando a necessidade de monitorizar continuamente os nós, o escalonamento e as operações de agendamento.
O Autopilot inclui um ANS que abrange o plano de controlo e a capacidade de computação usada pelos seus pods.
Acerca da plataforma de computação otimizada para contentores do Autopilot
Na versão 1.32.3-gke.1927002 e posteriores do GKE, o Autopilot inclui uma plataforma de computação otimizada para contentores especializada para as suas cargas de trabalho. Esta plataforma funciona bem para a maioria das cargas de trabalho de uso geral que não requerem hardware específico, como servidores Web e trabalhos em lote de intensidade média.
A plataforma de computação otimizada para contentores usa nós do GKE Autopilot que podem ser redimensionados dinamicamente durante a execução, concebidos para serem expandidos a partir de frações de uma CPU com interrupções mínimas. Esta alteração de tamanho dinâmica reduz significativamente o tempo necessário para aprovisionar nova capacidade à medida que as suas cargas de trabalho são dimensionadas. Para melhorar a velocidade de escalabilidade e redimensionamento, o GKE também mantém um conjunto de capacidade de computação pré-aprovisionada que pode ser automaticamente atribuída a cargas de trabalho em resposta ao aumento das exigências de recursos.
A plataforma de computação otimizada para contentores oferece as seguintes vantagens:
- A capacidade de computação corresponde às cargas de trabalho: o Autopilot ajusta dinamicamente a capacidade de computação para a plataforma de computação otimizada para contentores com base em fatores como o número de pods e o consumo de recursos. Como resultado, a capacidade de computação no cluster corresponde às necessidades das suas cargas de trabalho.
- Tempos de escalabilidade rápidos: durante eventos de expansão, o GKE pode redimensionar dinamicamente os nós existentes para acomodar mais pods ou um maior consumo de recursos. Este aprovisionamento dinâmico de capacidade significa frequentemente que os novos pods não têm de esperar que os novos nós sejam iniciados.
Pode usar a plataforma de computação otimizada para contentores do Autopilot das seguintes formas:
- Clusters do Autopilot: os pods que não selecionam hardware específico usam esta plataforma de computação por predefinição.
- Clusters padrão: pode colocar Pods específicos na plataforma de computação otimizada para contentores selecionando uma das ComputeClasses do Autopilot incorporadas.
Preços
Os preços do Autopilot usam modelos diferentes consoante o tipo de hardware usado pelos seus Pods, da seguinte forma:
Pods do Autopilot de uso geral: os seguintes tipos de pods usam um modelo de faturação baseado em pods e são categorizados como pods de uso geral:
- Pods executados na plataforma de computação otimizada para contentores em clusters do Autopilot ou clusters padrão.
- Pods que selecionam as ComputeClasses incorporadas
Balanced
ouScale-Out
em clusters do Autopilot.
Para mais informações, consulte a secção "Cargas de trabalho do Autopilot de uso geral" em Preços do Google Kubernetes Engine.
Cargas de trabalho do Autopilot que selecionam hardware específico: os pods que selecionam hardware específico, como a série de máquinas do Compute Engine ou os aceleradores de hardware, usam um modelo de faturação baseado em nós. Neste modelo, paga pelo hardware subjacente e por um prémio de gestão de nós.
Para mais informações, consulte a secção "Cargas de trabalho do Autopilot que selecionam hardware específico" em Preços do Google Kubernetes Engine.
Clusters e cargas de trabalho do Autopilot
O GKE permite-lhe usar o modo Autopilot para clusters inteiros ou para cargas de trabalho específicas nos seus clusters Standard. Os clusters do Autopilot são a forma recomendada de usar o GKE, porque todo o cluster usa as práticas recomendadas da Google por predefinição.
No entanto, algumas organizações têm requisitos de controlo manual ou flexibilidade que exigem a utilização de um cluster padrão do GKE. Nestes casos, ainda pode usar o Autopilot para cargas de trabalho específicas nos seus clusters Standard, o que lhe permite beneficiar de muitas funcionalidades do Autopilot ao nível da carga de trabalho.
As secções seguintes mostram como planear e criar clusters do Autopilot. Se tiver um cluster Standard e quiser executar algumas das suas cargas de trabalho no modo Autopilot, consulte o artigo Acerca das cargas de trabalho do modo Autopilot no GKE Standard.
Planeie os seus clusters do Autopilot
Antes de criar um cluster, planeie e crie a sua Google Cloud arquitetura. No Autopilot, pede hardware nas especificações da carga de trabalho. O GKE aprovisiona e gere a infraestrutura correspondente para executar essas cargas de trabalho. Por exemplo, se executar cargas de trabalho de aprendizagem automática, pode pedir aceleradores de hardware. Se desenvolver apps Android, pede CPUs Arm.
Planeie e peça quota para o seu Google Cloud projeto ou organização com base na escala das suas cargas de trabalho. O GKE só pode aprovisionar infraestrutura para as suas cargas de trabalho se o seu projeto tiver quota suficiente para esse hardware.
Considere os seguintes fatores durante o planeamento:
- Estimativa da dimensão e escala do cluster
- Tipo de carga de trabalho
- Esquema e utilização do cluster
- Esquema e configuração de redes
- Configuração de segurança
- Gestão e manutenção de clusters
- Implementação e gestão de cargas de trabalho
- Registo e monitorização
As secções seguintes fornecem informações e recursos úteis para estas considerações.
Trabalhar em rede
Quando cria um cluster do Autopilot com rede pública, as cargas de trabalho no cluster podem comunicar entre si e com a Internet. Este é o modo de rede predefinido. Google Cloud O Google Cloud e o Kubernetes oferecem várias funcionalidades e capacidades de rede adicionais que pode usar com base nos seus requisitos, como clusters com redes privadas.
A rede no Kubernetes e na nuvem é complexa. Antes de começar a alterar as predefinições que Google Cloud são definidas para si, certifique-se de que conhece os conceitos básicos de redes. A tabela seguinte disponibiliza recursos para saber mais sobre as redes no GKE com base no seu exemplo de utilização:
Exemplo de utilização | Recursos |
---|---|
Compreenda como o trabalho em rede funciona no Kubernetes e no GKE |
Depois de conhecer o modelo de rede, considere os requisitos de rede e de segurança de rede da sua organização. Escolha o GKE e Google Cloud as funcionalidades de rede que satisfazem esses critérios. |
Planeie a configuração de rede do GKE | Recomendamos que compreenda as quotas de rede do GKE, como os pontos finais por serviço e os limites de pedidos de API. Os seguintes recursos ajudam a planear aspetos específicos da configuração de rede:
|
Exponha as suas cargas de trabalho |
|
Execute serviços associados de elevada disponibilidade em vários clusters | Use serviços em vários clusters (MCS). |
Equilibre a carga do tráfego recebido |
|
Configure a segurança da rede de clusters |
|
Observe o tráfego de rede do Kubernetes | Por predefinição, o Autopilot usa o GKE Dataplane V2 para métricas e observabilidade .
|
Dimensionar
A gestão eficaz de uma plataforma em grande escala requer planeamento e uma análise cuidadosa. Tem de considerar a escalabilidade do seu design, que é a capacidade dos seus clusters de crescerem enquanto permanecem dentro dos objetivos de nível de serviço (SLOs). Para obter orientações detalhadas para administradores de plataformas e programadores, consulte as diretrizes para criar clusters escaláveis.
Também deve considerar as quotas e os limites do GKE, especialmente se planeia executar clusters grandes com potencialmente milhares de pods.
No Autopilot, o GKE dimensiona automaticamente os seus nós com base no número de pods no seu cluster. Se um cluster não tiver cargas de trabalho em execução, o Autopilot pode dimensionar automaticamente o cluster para zero nós. Após a redução de recursos do cluster, não restam nós no cluster e, consequentemente, os pods do sistema estão num estado não agendável. Este comportamento é o esperado. Na maioria dos clusters do Autopilot criados recentemente, pode reparar que as primeiras cargas de trabalho que implementar demoram mais tempo a agendar. Isto deve-se ao facto de o novo cluster do Autopilot começar com zero nós utilizáveis após a criação e aguardar até implementar uma carga de trabalho para aprovisionar nós adicionais.
Para dimensionar automaticamente o número de pods no cluster, use um mecanismo como a escala automática horizontal de pods do Kubernetes, que pode dimensionar pods com base nas métricas de CPU e memória incorporadas ou com base em métricas personalizadas do Cloud Monitoring. Para saber como configurar o ajuste de escala com base em várias métricas, consulte o artigo Otimize o ajuste de escala automático de pods com base em métricas.
Segurança
Os clusters do Autopilot ativam e aplicam as práticas recomendadas de segurança e as definições por predefinição, incluindo muitas das recomendações em Reforce a segurança do cluster e na vista geral da segurança do GKE.
Se quiser saber mais sobre as medidas de reforço do Autopilot e como implementar os seus requisitos de segurança específicos, consulte o artigo Medidas de segurança no Autopilot.
Crie um cluster
Depois de planear o seu ambiente e compreender os seus requisitos, crie um cluster do Autopilot. Os novos clusters do Autopilot são clusters regionais que têm um endereço IP acessível publicamente. Cada cluster tem medidas de reforço de segurança de base aplicadas, bem como escalabilidade automática e outras funcionalidades. Para ver uma lista completa das funcionalidades pré-configuradas, consulte o artigo Compare o GKE Autopilot e o Standard.
Se quiser criar o cluster sem acesso a endereços IP externos, configure o isolamento da rede.
Implemente cargas de trabalho no modo de piloto automático
Pode executar cargas de trabalho do Kubernetes compatíveis no modo Autopilot para que o GKE faça a gestão do escalamento, da programação eficiente e da infraestrutura subjacente. Pode usar a plataforma de computação otimizada para contentores para as suas cargas de trabalho de uso geral ou selecionar hardware específico para as suas cargas de trabalho usando uma ComputeClass.
Pode executar estas cargas de trabalho do Autopilot de uma das seguintes formas:
- Implemente as cargas de trabalho num cluster do Autopilot.
- Selecione uma ComputeClass do Autopilot quando implementar as cargas de trabalho num cluster Standard.
Para um guia interativo na Google Cloud consola para implementar e expôr uma app num cluster do Autopilot, clique em Guiar-me:
A tabela seguinte mostra alguns requisitos comuns e fornece recomendações sobre o que deve fazer:
Exemplo de utilização | Recursos |
---|---|
Controle as propriedades dos nós individuais ao dimensionar um cluster | Crie uma ComputeClass personalizada e peça-a no manifesto da carga de trabalho. Para mais informações, consulte o artigo Acerca das ComputeClasses personalizadas. |
Execute cargas de trabalho do Autopilot num cluster Standard | Use uma ComputeClass do Autopilot no cluster Standard. Para mais informações, consulte o artigo Acerca das cargas de trabalho do modo Autopilot no GKE Standard. |
Execute cargas de trabalho Arm | Peça uma série de máquinas com CPUs Arm numa ComputeClass ou no manifesto da carga de trabalho. Para mais informações, consulte o artigo Acerca das ComputeClasses personalizadas. |
Execute cargas de trabalho de IA/AA aceleradas | Peça GPUs numa ComputeClass ou no manifesto da carga de trabalho. Para mais informações sobre como pedir GPUs no manifesto da carga de trabalho, consulte Implemente cargas de trabalho de GPU no Autopilot. |
Execute cargas de trabalho com tolerância a falhas, como tarefas em lote, a custos mais baixos. |
Pode usar qualquer ComputeClass ou configuração de hardware com Spot Pods. |
Executar cargas de trabalho que requerem interrupções mínimas, como servidores de jogos ou filas de trabalho | Apenas em clusters do Autopilot, especifique a anotação cluster-autoscaler.kubernetes.io/safe-to-evict=false na especificação do pod. Os pods estão protegidos contra despejos causados por atualizações automáticas de nós ou eventos de redução de escala durante um máximo de sete dias.
Para mais informações, consulte o artigo
Prolongue o tempo de execução dos pods do Autopilot. |
Permitir que as cargas de trabalho excedam os respetivos pedidos se existirem recursos disponíveis e não usados na soma dos pedidos de recursos de pods no nó. | Defina o recurso limits mais alto do que o requests
ou não defina limites de recursos.
Para mais informações, consulte o artigo
Configure o aumento rápido de pods no GKE. |
O Autopilot permite-lhe pedir recursos de CPU, memória e armazenamento temporário para as suas cargas de trabalho. Os intervalos permitidos dependem de querer executar os seus pods na plataforma de computação otimizada para contentores do Autopilot ou em hardware específico. Para obter informações sobre os pedidos de recursos de contentores predefinidos e os intervalos de recursos permitidos, consulte o artigo Pedidos de recursos no Autopilot.
Separação de cargas de trabalho
Os clusters do Autopilot suportam a utilização 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 precisa de
indicar ao GKE para colocar cargas de trabalho em nós que cumprem critérios específicos,
como etiquetas de nós personalizadas. Por exemplo, pode indicar ao GKE para agendar pods de servidores de jogos em nós com a etiqueta game-server
e evitar agendar outros pods nesses nós.
Para saber mais, consulte o artigo Configure a separação de cargas de trabalho no GKE.
Agende pods em zonas específicas através da topologia zonal
Se precisar de colocar pods numa Google Cloud zona específica, por exemplo, para aceder a informações num disco persistente do Compute Engine zonal, consulte o artigo Coloque pods do GKE em zonas específicas.
Afinidade e antiafinidade de pods
Use a afinidade e a antiafinidade de agrupamentos para colocar agrupamentos num único nó ou para fazer com que alguns agrupamentos evitem outros agrupamentos. A afinidade e a antiafinidade de pods indicam ao Kubernetes que deve tomar uma decisão de agendamento com base nas etiquetas dos pods em execução em nós num domínio de topologia específico, como uma região ou uma zona específica. Por exemplo, pode indicar ao GKE para evitar o agendamento de pods de front-end juntamente com outros pods de front-end nos mesmos nós para melhorar a disponibilidade em caso de indisponibilidade.
Para ver instruções e mais detalhes, consulte o artigo Afinidade e antiafinidade de pods.
No GKE, pode usar a afinidade e a antiafinidade de pods com as seguintes etiquetas em topologyKey
:
topology.kubernetes.io/zone
kubernetes.io/hostname
Restrições de propagação da topologia de agrupamentos
Para melhorar a disponibilidade das suas cargas de trabalho à medida que o Kubernetes dimensiona o número de pods para cima e para baixo, pode definir restrições de dispersão da topologia de pods. Isto controla a forma como o Kubernetes distribui os seus pods pelos nós num domínio de topologia, como uma região. Por exemplo, pode indicar ao Kubernetes que coloque um número específico de pods de sessão do servidor de jogos em cada uma das três zonas na região us-central1
. Google Cloud
Para ver exemplos, mais detalhes e instruções, consulte o artigo Restrições de dispersão da topologia de pods.
Faça a gestão e a monitorização dos seus clusters do Autopilot
No Autopilot, o GKE gere automaticamente as atualizações dos clusters e a manutenção do painel de controlo e dos nós de trabalho. Os clusters do Autopilot também têm funcionalidades incorporadas para monitorizar os seus clusters e cargas de trabalho.
Atualizações de versão do GKE
Todos os clusters do Autopilot estão inscritos num canal de lançamento do GKE. Nos canais de lançamento, o GKE gere a versão do Kubernetes do cluster, equilibrando a disponibilidade de funcionalidades e a estabilidade da versão consoante o canal. Por predefinição, os clusters do Autopilot estão inscritos no canal de lançamento normal, mas pode selecionar um canal diferente que satisfaça as suas necessidades de estabilidade e funcionalidade. Para mais informações sobre os canais de lançamento, consulte o artigo Acerca dos canais de lançamento.
O GKE inicia automaticamente as atualizações, monitoriza o progresso e pausa a operação se ocorrerem problemas. Pode controlar manualmente o processo de atualização das seguintes formas:
- Para controlar quando o GKE pode fazer atualizações automáticas, crie janelas de manutenção. Por exemplo, pode definir o período de manutenção para a noite anterior à reposição semanal do seu jogo multijogador, para que os jogadores possam iniciar sessão na reposição sem interrupções.
- Para controlar quando o GKE não pode iniciar atualizações automáticas durante um intervalo de tempo específico, use exclusões de manutenção. Por exemplo, pode definir uma exclusão de manutenção para a duração do seu evento de vendas da Black Friday e Cyber Monday para que os clientes possam fazer compras sem problemas.
- Para obter uma nova versão antes do início das atualizações automáticas, atualize manualmente o plano de controlo. O GKE reconcilia a versão do nó com a versão do plano de controlo ao longo do tempo.
- Para obter uma versão de patch que só está disponível num canal de lançamento mais recente, consulte o artigo Execute versões de patch a partir de um canal mais recente. Por exemplo, pode precisar de uma versão de patch específica para mitigar uma divulgação de vulnerabilidade recente.
Monitorize os seus clusters do Autopilot
Os clusters do Autopilot já têm o Cloud Logging, o Cloud Monitoring e o serviço gerido pela Google Cloud para o Prometheus ativados.
Os clusters do Autopilot recolhem automaticamente os seguintes tipos de registos e métricas, em conformidade com as práticas recomendadas da Google para a recolha de telemetria:
Registos do Cloud Logging
- Registos de sistema
- Registos de cargas de trabalho
- Registos de auditoria de atividade do administrador
- Registos de auditoria de acesso a dados
Métricas para o Cloud Monitoring
- Métricas do sistema
- Métricas de carga de trabalho (do serviço gerido do Google Cloud para Prometheus)
Não é necessária nenhuma configuração adicional para ativar o registo e a monitorização. A tabela seguinte mostra como interagir com a telemetria recolhida com base nos seus requisitos:
Exemplo de utilização | Recursos |
---|---|
Compreenda e aceda aos seus registos do GKE |
|
Observe o desempenho dos seus clusters do GKE | A monitorização eficaz do desempenho do cluster pode ajudar a otimizar os custos operacionais dos clusters e das cargas de trabalho.
|
Monitorize a postura de segurança dos seus clusters | Use o painel de controlo do estado de segurança para auditar as cargas de trabalho em execução em função das práticas recomendadas do GKE, procurar vulnerabilidades nos sistemas operativos de contentores e pacotes de idiomas, e receber recomendações de mitigação acionáveis. Para saber mais, consulte o artigo Acerca do painel de controlo da postura de segurança. |
Resolução de problemas
Para ver os passos de resolução de problemas, consulte o artigo Resolva problemas de clusters do Autopilot.