O novo modo GKE é mais caro e menos flexível, mas mais simples e seguro
O GKE Autopilot gerencia pods para você
Duas coisas são bem conhecidas sobre os clusters do Kubernetes. A primeira é que é absolutamente a melhor ferramenta para a tarefa crítica de orquestração de contêineres. E, segundo, sua complexidade é uma barreira para a implementação e uma causa comum de erros. Até o Google, o inventor e principal promotor do Kubernetes, admite isso.
Para simplificar a implantação e o gerenciamento de clusters, a empresa forneceu a todos os clientes do GKE acesso ao serviço Autopilot , que o Google usa há muito tempo em seus próprios clusters Borg . É a configuração automática de recursos com base no aprendizado de máquina.
“Apesar de 6 anos de progresso, o Kubernetes ainda é incrivelmente complexo ” , disse Drew Bradstock, chefe de produto do Google Kubernetes Engine (GKE), ao The Register. "Nos últimos anos, vimos muitas empresas adotarem o Kubernetes, mas depois enfrentaram dificuldades."
GKE é uma plataforma Kubernetes executada principalmente no Google Cloud Platform (GCP). Ele também está disponível em outras nuvens ou localmente como parte do Anthos .
Piloto automático - novo modo de operaçãoGKE, é mais automatizado e pré-configurado para reduzir custos operacionais para gerenciamento de cluster, otimizar clusters para produção e alta disponibilidade.
Usando o piloto automático na própria infraestrutura do Google, o
Kubernetes de origem tem os conceitos de clusters (uma coleção de servidores físicos ou virtuais), nós (servidores individuais), pods (um bloco de controle que representa um ou mais contêineres em um nó) e os próprios contêineres. O GKE é totalmente gerenciado no nível do cluster. O piloto automático estende isso para nós e pods.
A maneira mais fácil de entender os recursos e limitações do Autopilot é a partir da descrição do sistema.... Observe os parâmetros "pré-configurados" que não podem ser alterados.
Comparação dos modos de piloto automático e padrão
Basicamente, essa é outra maneira de reservar e gerenciar recursos do GKE que sacrifica a flexibilidade por conveniência. Como o Google gerencia a maior parte da configuração, ele garante um tempo de atividade superior de 99,9% para os pods do Autopilot com várias zonas (consulte o SLA ).
Na nuvem do Google, as regiões são compostas por três ou mais zonas. Colocar todos os recursos em uma zona é menos confiável do que em várias zonas, e a expansão para várias regiões oferece tolerância máxima a falhas. Os clusters no piloto automático são sempre distribuídos por regiões, não por zonas: é mais confiável, mas mais caro.
Outra limitação do Autopilot é o sistema operacional Linux pré-instalado com Containerd, "otimizado para containers". Não há como usar Linux com Docker ou Windows Server. O número máximo de pods por nó é 32, não 110 como no GKE padrão.
Não há acesso SSH aos nós, os nós do Autopilot estão bloqueados. O suporte para GPU e TPU (Tensor Processing Unit) não está disponível, embora planejado para o futuro. “Livrar-se do SSH foi uma decisão difícil”, diz Bradstock. Claro, isso limita as opções de controle. Mas Bradstock disse que a decisão foi baseada em pesquisas que mostraram uma alta taxa de erros críticos na configuração do cluster.
Dinheiro
O modelo de preços também é diferente aqui. Você não é cobrado por instâncias de computação (máquinas virtuais), mas pelo uso real de CPU, memória e armazenamento por todos os pods. Mais US $ 0,10 por hora por cluster no Autopilot, assim como o GKE padrão.
A questão óbvia é qual será mais caro, um cluster padrão ou piloto automático. A resposta não é fácil. Como se trata de um serviço premium, o Autopilot é mais caro do que uma implantação padrão do GKE cuidadosamente otimizada. "Há uma vantagem sobre um GKE regular", disse Bradstock, "porque fornecemos não apenas funcionalidade, mas suporte SRE (Site Reliability Engineering) completo e garantias de SLA."
No entanto, o Autopilot pode ser mais barato do que uma implantação GKE configurada incorretamente que não está totalmente carregada porque é difícil avaliar a especificação correta para instâncias de computação. Função de alocação cumulativa (CDF) de memória não utilizada e máquinas ocupadas para 5.000 tarefas após ativar o piloto automático na própria infraestrutura do Google, fonte Reduzindo erros de memória (OOM) e compartilhamento de memória não utilizada para 500 tarefas após ativar o piloto automático na infraestrutura do Google, fonte
Por que não apenas usar o Cloud Run, que executa cargas de trabalho de contêiner sem qualquer configuração de cluster, nó ou pod, mesmo no GKE? “Cloud Run é um ótimo ambiente para desenvolvedores, um aplicativo pode ir de zero a 1000 instâncias e voltar a zero, é para isso que servem as nuvens”, explica Bradstock. "O piloto automático torna a vida mais fácil para quem deseja usar o Kubernetes, ver e controlar tudo, usar scripts de terceiros, criar sua própria plataforma."
Um problema definitivo é a compatibilidade com complementos existentes com ferramentas de terceiros para Kubernetes. Alguns deles ainda não são compatíveis com o Autopilot, mas outros já estão funcionando, como o monitoramento do Datadog. DaemonSets também são suportados - este recurso é usado por muitas ferramentas para executar daemons em todos os nós.
A configuração de armazenamento, computação e rede forçou a queda de algum nível de flexibilidade e algumas integrações: “Mas definitivamente queremos um ecossistema de terceiros para rodar no [piloto automático]”, diz Bradstock.
Com o lançamento do Autopilot, a gama de opções de como executar o Kubernetes na nuvem do Google se expande. O trade-off não é apenas custo mais alto e menos flexibilidade, mas também desorientação potencial de Devops nas fábricas. No entanto, a lógica principal é que é melhor as empresas se concentrarem em seus negócios principais do que nos serviços executados pelo contratante.
A engenharia do Google tem uma reputação muito melhor do que o atendimento ao cliente. O desenvolvedor Kevin Lin descreveu recentemente como é o esquema de bônus de inicialização do AWS e do Google.
O Google provou ser uma organização lenta e ineficaz que acabou encaminhando o cliente a um parceiro terceirizado. “A primeira conversa foi sobre quanto dinheiro pretendo gastar no Google (em vez de ligar para a Amazon, onde eles queriam me ajudar a colocar o serviço em funcionamento). O Google Cloud tem uma ergonomia realmente boa e engenheiros de classe mundial, mas uma péssima reputação de atendimento ao cliente ”, disse ele.
Esta é mais uma prova de que bons engenheiros não são o único fator importante na escolha de uma nuvem.