O Kubernetes é um copo meio vazio ou meio cheio? Bem, depende de como você olha para ele! A mecânica de seus recursos de orquestração é bastante complexa (na minha opinião), e não é incomum, mesmo para os profissionais mais experientes, bater a cabeça na parede por causa disso. Ao mesmo tempo, sempre o recomendei para usuários iniciantes e até mesmo para casos de negócios 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 trabalhando em um segundo emprego de meio período como freelancer, mantendo um sistema para uma pequena organização sem fins lucrativos. Portanto, quando não tenho 8 horas por dia para ser babá, quanto mais trabalho pesado eu puder transferir para os K8s, melhor será a vida para todos nós. Melhor ainda, se eu estiver trabalhando para uma grande empresa, onde sou pago 8 horas por dia para ser babá, ainda prefiro aproveitar o poder do K8s para fazer a maior parte do trabalho para mim. Essa é a perspectiva do copo meio cheio - considerar o K8s um aliado que está lá para facilitar sua vida. Declare o que você deseja e deixe que ele faça o que faz de melhor.
Como essa abordagem pode parecer excessivamente simplista, também vou apontar nossa tendência de tornar as coisas excessivamente complexas. Por exemplo, quando projetamos demais uma solução para alguma "preparação para o futuro" que ainda nem está no horizonte, ou quando reinventamos a roda em vez de usar ferramentas testadas em batalha que já foram criadas para a tarefa. O mergulho na engenharia de plataforma não é exceção, mas falaremos mais sobre isso em um 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, assim como aprender a dirigir um carro, a melhor maneira de aprender é com as mãos.
Fui apresentado ao Kubernetes pela primeira vez 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 dos usuários era enorme demais. Tínhamos que dar suporte a esse produto, o que significava que tínhamos que aprendê-lo e, melhor ainda... solucionar problemas! Embora às vezes frustrante, essas foram algumas das experiências mais valiosas de minha carreira.
Neste artigo, exploraremos algumas estratégias para aprender e gerenciar o Kubernetes, com base em experiências do mundo real como a minha.
Aprendendo com a prática
A melhor maneira de realmente entender a plataforma é criando e quebrando coisas. A combinação de 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. Em seguida, encontre uma maneira interessante de quebrar o modelo. Isso pode ser deixar que um amigo ou colega de trabalho faça uma tentativa, de modo que você não tenha ideia da origem do problema até começar a diagnosticar. Ou outro método que usei para isso é fazer algo mais complexo do que o demonstrado no guia. Por exemplo, digamos que você esteja fazendo o curso CKAD fornecido pela Linux Foundation. Eles podem instruí-lo a criar um cluster simplificado com apenas um 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 uma VPC e personalizar o endereçamento de rede do cluster para evitar colisões no espaço IP. Mesmo que fique frustrado e desista depois de algum tempo, você terá aprendido muito mais do que aprenderia de outra forma. Esses são apenas dois exemplos de minha própria experiência. O céu é o limite.
Além disso, ferramentas como Minikube ou Kind podem ser muito úteis para a experimentação localizada antes de tocar em qualquer coisa na nuvem. Independentemente da forma 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 as soluções. Se você tiver tempo para tornar isso público, não só poderá exibir sua excelente metodologia de solução de problemas, mas também ajudará seus colegas.
Solução de problemas como um caminho de aprendizado
Sobre o tópico da metodologia de solução de problemas, não existe uma "prática recomendada" em si, existe apenas a "sua prática", o que significa que você deve encontrar o que funciona melhor para você - seja ele qual for. O importante é que você se empenhe em desenvolver esse músculo para si mesmo, e isso se torna mais fácil com o tempo. Os melhores solucionadores de problemas que conheci se tornaram os melhores depois de anos fazendo exatamente isso e, como resultado, posso jogar qualquer coisa na frente deles. Consequentemente, eles também são os que aprendem com mais facilidade.
Aqui estão algumas técnicas que funcionam melhor para mim:
- Dividir e conquistar: Corte o problema pela metade e elimine sistematicamente as possíveis causas. Embora para alguns seja mais fácil escalar sistematicamente a pilha, eu geralmente tenho sucesso em ir direto para o que posso descartar primeiro. Isso desafia os bons conselhos de outras pessoas? É possível! Mas eu me preocupo mais com o que funciona para mim.
- Monitoring e a observabilidade são seus amigos, assim como os erros: As métricas, os logs e os rastreamentos podem apresentar uma visão holística do sistema e, melhor ainda, uma visão holística do problema! Prometheus e Grafana são os principais recursos de monitoramento e são um bom presságio para a sua escolha de ferramentas de agregação de logs e rastreamento. No entanto, no mundo real, nem sempre você é abençoado com uma pilha de observabilidade completa - às vezes, o melhor que você pode conseguir é o Prometheus e Grafana com alguns alvos remotos para raspar. Felizmente, isso ainda é muito útil na maior parte do tempo e, com ou sem isso, trate as mensagens de erro como suas amigas! É claro que algumas são mais úteis do que outras, mas, mesmo assim, elas são um feedback do sistema com informações de que algo deu errado.
- Recriar o problema: na medida do possível, recrie o problema em um ambiente separado. Fazer isso pode fornecer uma grande quantidade de informações sobre a causa, o que abre as portas para encontrar a solução. Isso também significa que você tem um ambiente de teste com o qual pode fazer experiências com 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, dedicar um pouco mais de tempo a isso de antemão pode economizar muito mais tempo depois.
- Mantenha um registro de solução de problemas: Você deve estar familiarizado com o conceito de um registro/log de decisões de arquitetura. O que o impede de aplicar um conceito semelhante à solução de problemas? Nada! E ele não precisa de nenhuma formatação ou convenção especial. Basta manter um registro das etapas de solução de problemas à medida que as executa. Isso pode ser útil se você precisar voltar atrás ou reafirmar o que já foi descartado. Melhor ainda, você pode revisá-lo mais tarde para documentar a solução e explicar como chegou a ela. Ser capaz de articular as etapas e a lógica por trás delas pode deixar rastros mais permanentes em sua memória. Isso também será útil para qualquer pessoa que leia sua documentação. Um bom candidato para essa documentação é uma plataforma de base de conhecimento interna ou até mesmo um blog voltado para o público para ensinar outras pessoas.
Ao enfrentar problemas particularmente difíceis, adotar 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 se encontrarão mais bem equipadas para aproveitar o poder do Kubernetes.
Usando tecnologia simples e confiável
O ecossistema nativo da nuvem (e o cenário da nuvem em geral) oferece uma infinidade de ferramentas e estruturas para serem combinadas. As possibilidades do que você pode criar são quase infinitas! No entanto, essa noção muitas vezes pode levar a algumas armadilhas importantes: muitas ferramentas, muita complexidade e muita dívida técnica. Felizmente, essa é uma armadilha fácil de evitar com apenas um pouco de disciplina e uma mentalidade: menos é mais. A melhor tecnologia é a mais sustentável e a mais estável, e você verá que seus usuários tendem a concordar. Se você precisasse subir uma escada para chegar ao telhado de uma casa, não gostaria que ela fosse tão superprojetada a ponto de você ter dúvidas sobre se a está usando corretamente. Isso seria assustador!
Não há orgulho em manter uma base de código tão complicada que ninguém consegue lê-la. Não há medalha de ouro ou troféu por criar um sistema tão complexo que quase ninguém consegue usá-lo. O que queremos são coisas que funcionem, que sejam estáveis e que possamos usar corretamente e de forma confiá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 do seu aplicativo ganhará complexidade naturalmente com o tempo à medida que evoluir, portanto, 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, além de simplificar as implementações, a manutenção e a solução de problemas.
Além disso, manter a simplicidade ajuda a reduzir o risco de configurações incorretas que prejudicam 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 minha própria opinião aqui, contra a corrente da abordagem "tudo o que você pode comer", porque a inovação mais avançada que vi em minha carreira vem de empresas que incorporam a abordagem da "dieta rigorosa"; aquelas que se concentraram em dominar o básico, para que possam criar com segurança e confiabilidade alguns produtos de ponta que resolvem alguns problemas muito complexos.
Continuando a dominar o Kubernetes
Uma combinação de experiência prática, uma metodologia sólida 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 desenvolver habilidades de solução de problemas que são essenciais nas 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 facilita a solução de desafios futuros. E simplificar sua pilha do Kubernetes minimizando as 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 dimensionar do que um sobrecarregado com ferramentas que aumentam a complexidade sem oferecer benefícios claros. Em última análise, o sucesso com o Kubernetes não se trata de usar todas as novas ferramentas do mercado, mas de saber quais delas agregam valor real a longo prazo.
Se quiser saber mais sobre o Kubernetes, falo sobre isso com mais detalhes no podcast KubeFM, que você pode assistir no YouTube ou abaixo.
Comentários