O Kubernetes é um copo meio vazio ou meio cheio? Bem, depende da forma como se olha para ele! A mecânica das suas capacidades de orquestração é bastante complexa (na minha opinião), e não é invulgar, mesmo para os profissionais mais experientes, bater com a cabeça na parede por causa disso. Ao mesmo tempo, recomendei-o frequentemente a utilizadores principiantes e até a casos de negócio em que a capacidade de dívida técnica é mais limitada - com o objetivo de trabalhar de forma mais inteligente, não mais difícil. Estou a trabalhar num segundo emprego a tempo parcial como freelancer, mantendo um sistema para uma pequena organização sem fins lucrativos. Assim, quando não tenho 8 horas por dia para tomar conta, quanto mais trabalho pesado puder transferir para os K8s, melhor será a vida para todos nós. Melhor ainda, se estiver a trabalhar para uma grande empresa onde me pagam 8 horas por dia para tomar conta de crianças, prefiro aproveitar o poder do K8s para fazer a maior parte do trabalho por mim. Esta é a perspetiva do copo meio cheio - considerar o K8s um aliado que está lá para tornar a sua vida mais fácil. Declare o que pretende e deixe-o fazer o que faz melhor.
Uma vez que esta abordagem pode parecer demasiado simplista, chamo também a atenção para a nossa tendência para tornar as coisas demasiado complexas. Por exemplo, quando criamos uma solução excessivamente complexa para uma "proteção futura" que ainda nem sequer está no horizonte, ou quando reinventamos a roda em vez de utilizar ferramentas testadas em combate que já foram criadas para a tarefa. O mergulho na engenharia de plataformas não é exceção, mas falaremos mais sobre isso num artigo posterior.
O K8s é um organismo poderoso e complexo, mas lembre-se de que muitos de nossos colegas do setor dedicaram horas para torná-lo algo que "simplesmente funciona" e, como aprender a dirigir um carro, a melhor maneira de aprender é prática.
Fui apresentado pela primeira vez ao Kubernetes em 2019 - na linha de frente da equipe de suporte ao cliente da Linode - quando lançamos o Linode Kubernetes Engine (LKE). Foi um momento de afundar ou nadar que não pudemos evitar porque a demanda do usuário era muito grande. Tivemos que dar suporte a esse produto, o que significa que tivemos que aprendê-lo e, melhor ainda ... solucioná-lo! Embora frustrante por vezes, estas foram algumas das experiências mais valiosas da minha carreira.
Neste artigo, vamos explorar algumas estratégias para aprender e gerenciar o Kubernetes, com base em experiências do mundo real como a minha.
Aprender fazendo
A melhor maneira de compreender verdadeiramente a plataforma é construir e quebrando coisas. Combinar documentação e tutoriais é uma ótima maneira de colocar as mãos em um cluster funcional. Coloque seus manifestos em um repositório Git e você terá um modelo que será referência para sempre. A seguir, encontre uma forma interessante de o quebrar. Isso pode ser deixar um amigo ou colega de trabalho fazer uma tentativa para que você não tenha ideia da origem do problema até começar a diagnosticar. Ou outro método que utilizei para isto é fazer algo mais complexo do que o demonstrado no guia. Por exemplo, digamos que está a fazer o curso CKAD fornecido pela Linux Foundation. Eles podem instruí-lo a construir um cluster simplificado com apenas um único plano de controle e um nó de trabalho. Em vez disso, tente inicializar com êxito um cluster com três nós de plano de controle para alta disponibilidade e três nós de trabalho. Se isso não for suficientemente desafiador, tente implementar um VPC e personalizar o endereçamento de rede do cluster para evitar colisões no espaço IP. Mesmo que fique frustrado e desista após algum tempo, terá aprendido muito mais do que teria aprendido de outra forma. Estes são apenas dois exemplos da minha própria experiência. O céu é o limite.
Além disso, ferramentas como Minikube ou Kind podem ser muito úteis para experimentação localizada antes de tocar em qualquer coisa na nuvem. Independentemente de como você vai quebrar, solucionar problemas e consertar seu cluster, certifique-se de deixar algum rastro de documentação. O ato de escrever serve bem à sua memória, pois exige que você articule as etapas e soluções. Se tiver tempo para tornar isto público, não só poderá mostrar a sua excelente metodologia de resolução de problemas, como também ajudará os seus colegas.
A resolução de problemas como um caminho de aprendizagem
No que diz respeito à metodologia de resolução de problemas, não existe uma "melhor prática" em si, existe apenas a "sua prática", o que significa que deve encontrar a melhor prática para si - seja ela qual for. O importante é que se esforce por desenvolver este músculo e que se torne mais fácil com o tempo. Os melhores solucionadores de problemas que conheci tornaram-se os melhores ao longo de anos a fazer exatamente isto e, como resultado, posso atirar qualquer coisa para a frente deles. Consequentemente, são também os que aprendem mais facilmente.
Eis algumas técnicas que funcionam melhor para mim:
- Dividir e conquistar: Cortar o problema ao meio e eliminar sistematicamente as causas potenciais. Embora para alguns seja mais fácil escalar sistematicamente a pilha, eu normalmente tenho sucesso em saltar diretamente para o que posso excluir primeiro. Será que isso desafia os bons conselhos dos outros? Possivelmente! Mas eu preocupo-me mais com o que funciona para mim.
- Monitoring e a observabilidade são suas amigas, assim como os erros: Métricas, logs e rastreamentos podem dar uma visão holística do sistema e, melhor ainda, uma visão holística do problema! Prometheus e Grafana são os mais usados para monitorar e são um bom presságio para a sua escolha de ferramentas de agregação de logs e rastreamento. No mundo real, no entanto, você nem sempre é abençoado com uma pilha de observabilidade completa - às vezes, o melhor que você pode obter é o Prometheus e Grafana com alguns alvos remotos para raspar. Felizmente, isso ainda é muito útil na maior parte do tempo, e com ou sem, trate as mensagens de erro como suas amigas! Claro, algumas são mais úteis do que outras, mas, mesmo assim, são feedbacks do sistema com informações de que algo deu errado.
- Recriar o problema: Tanto quanto possível, recriar o problema num ambiente separado. Isto pode fornecer uma grande quantidade de informações sobre a causa, o que abre as portas para encontrar a solução. Também significa que tem um ambiente de teste com o qual pode fazer experiências em segurança. Um dos muitos motivos pelos quais é uma boa prática aproveitar o poder da infraestrutura como código (IaC) é a capacidade de recriar ou destruir rapidamente esse ambiente, conforme necessário. Mesmo que isso signifique escrevê-lo você mesmo, em situações em que o ambiente não foi codificado anteriormente, gastar um pouco mais de tempo com isso antecipadamente pode economizar muito mais tempo depois.
- Manter um registo de resolução de problemas: Poderá estar familiarizado com o conceito de um registo/log de decisões de arquitetura. O que é que o impede de aplicar um conceito semelhante à resolução de problemas? Nada! E não precisa de qualquer formatação ou convenção especial. Basta manter um registo dos seus passos de resolução de problemas à medida que os executa. Isto pode ser útil se precisar de voltar atrás ou reafirmar as coisas que já excluiu. Melhor ainda, pode revê-lo mais tarde para documentar a solução e explicar como chegou a ela. Ser capaz de articular os passos e a lógica por detrás deles pode criar rastos mais permanentes na sua memória. Também será útil para qualquer pessoa que leia a sua documentação. Um bom candidato para esta documentação é uma plataforma de base de conhecimentos interna, ou mesmo um blogue público para ensinar os outros.
Ao enfrentar problemas particularmente difíceis, abraçar a solução de problemas como uma oportunidade de aprendizado pode levar a melhorias de longo prazo nas habilidades de solução de problemas e ajudar a melhorar a maneira como você gerencia sua infraestrutura. As equipes que refinam e iteram seus processos de depuração estarão mais bem equipadas para aproveitar o poder do Kubernetes.
Utilizar tecnologia simples e fiável
O ecossistema nativo da nuvem (e o cenário da nuvem em geral) oferece uma infinidade de ferramentas e estruturas para unir. As possibilidades do que se pode construir são quase infinitas! No entanto, esta noção pode muitas vezes levar a algumas armadilhas importantes: demasiadas ferramentas, demasiada complexidade e demasiada dívida técnica. Felizmente, esta é uma armadilha fácil de evitar com apenas um pouco de disciplina e uma mentalidade: menos é mais. A melhor tecnologia é a mais fácil de manter e a mais estável, e verá que os seus utilizadores tendem a concordar. Se precisasse de subir uma escada para chegar ao telhado de uma casa, não quereria que ela fosse tão excessivamente concebida ao ponto de ter dúvidas sobre se a está a utilizar corretamente. Isso seria assustador!
Não há orgulho em manter uma base de código tão complicada que ninguém a consegue ler. Não há medalha de ouro ou troféu por construir um sistema tão complexo que quase ninguém o consegue utilizar. O que nós queremos são coisas que funcionem, que sejam estáveis e que possamos utilizar corretamente e de forma fiável sem acumular mais trabalho. A simplicidade é sua amiga aqui. Além disso, lembre-se de que um padrão de design nativo da nuvem é aquele que aceita mudanças rápidas. A arquitetura da sua aplicação irá naturalmente ganhar complexidade ao longo do tempo à medida que evolui, por isso não há necessidade de forçar essa mão. Com uma abordagem minimalista , além de um design modular nativo da nuvem, as equipes podem ter sistemas mais enxutos e seguros e simplificar implantações, manutenção e solução de problemas.
Além disso, manter a simplicidade ajuda a reduzir o risco de configurações incorrectas que reduzem o desempenho e/ou aumentam a superfície de ataque para falhas de segurança.
O Kubernetes em si é uma abstração. Não poderíamos chamá-lo de "nativo da nuvem" se não fosse, mas manter a quantidade de abstrações desnecessárias sob controle significa que os engenheiros gastam menos tempo gerenciando a complexidade subjacente e mais tempo se concentrando em fornecer valor. Defendo a minha opinião aqui, contra a corrente da abordagem "tudo o que se pode comer", porque a inovação mais avançada que vi ao longo da minha carreira vem de empresas que incorporam a abordagem da "dieta rigorosa"; aquelas que se concentraram em dominar o básico, para que possam construir com segurança e fiabilidade alguns produtos muito avançados que resolvem alguns problemas muito complexos.
Continuando a dominar o Kubernetes
Uma combinação de experiência prática, uma forte metodologia de solução de problemas e uma abordagem cuidadosa das ferramentas pode tornar o Kubernetes muito mais fácil de dominar. Aprender fazendo (em vez de apenas ler) ajuda a gravar habilidades de resolução de problemas que são críticas em operações do mundo real. A solução de problemas não se trata apenas de consertar o que está quebrado; é uma oportunidade de refinar seu entendimento, melhorar a documentação e desenvolver uma abordagem sistemática que torna os desafios futuros mais fáceis de resolver. E simplificar sua pilha Kubernetes minimizando abstrações desnecessárias reduz a sobrecarga cognitiva, facilitando o gerenciamento ao longo do tempo.
Como muitos profissionais experientes aprenderam, um cluster enxuto e bem estruturado é mais fácil de manter e escalar do que um sobrecarregado com ferramentas que adicionam complexidade sem oferecer benefícios claros. Em última análise, o sucesso com Kubernetes não é sobre o uso de todas as novas ferramentas no mercado, é sobre saber quais agregam valor real a longo prazo.
Se quiser saber mais sobre Kubernetes, falo sobre isso com mais detalhes no podcast KubeFM, que pode ser visto no YouTube ou abaixo.
Comentários