Kubernetes & Helm Fundamentals

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 1 de 10. Durante anos, a Google operou a sua infraestrutura global de pesquisa e e-mail usando um sistema altamente secreto, batizado em homenagem aos vilões mais assustadores do Star Trek. Tiveram de o inventar porque a gestão de servidores existente simplesmente falhava à sua escala. Hoje, vamos olhar para as origens, do Borg ao Kubernetes, e porque é que as empresas modernas dependem dele. Para perceberes porque é que o Kubernetes existe, tens de olhar para como o deployment de aplicações evoluiu. Na era do deployment tradicional, corrias aplicações em servidores físicos. Não havia forma de definir limites de recursos. Se uma aplicação consumisse a maior parte da memória, outras aplicações naquele servidor físico sofriam. Podias comprar uma máquina física separada para cada app, mas isso resultava em hardware caro e subutilizado. A seguir, veio a era do deployment virtualizado. Corrias várias Virtual Machines no CPU de um único servidor físico. As VMs isolavam as aplicações e forneciam um nível de segurança, mas cada VM ainda exigia um sistema operativo completo e pesado. Finalmente, chegámos à era do deployment em containers. Os containers são semelhantes às VMs, mas partilham o sistema operativo subjacente entre as aplicações. Por serem desacoplados do hardware subjacente, são leves, rápidos a arrancar e portáteis entre diferentes clouds e distribuições de sistemas operativos. Mas os containers introduziram um novo problema. Se corres uma aplicação empresarial global, não tens apenas um container. Tens milhares. Se um container for abaixo, outro precisa de arrancar imediatamente. Se houver picos de tráfego, precisas de fazer spin up de mais containers e distribuir o network load uniformemente. Não consegues gerir isso manualmente em centenas de máquinas. A Google enfrentou exatamente este problema muito antes do resto da indústria. Eles construíram um cluster manager de containers interno chamado Borg para automatizar a orquestração de centenas de milhares de jobs. Quando ficou claro que o resto do mundo do software precisava desta mesma capacidade, os engenheiros da Google começaram um projeto open-source baseado nas lições aprendidas com o Borg. Deram-lhe uma referência ao Star Trek, chamando-o originalmente de Project Seven of Nine, um aceno a um drone Borg que escapou do coletivo. Esse projeto acabou por ser lançado como Kubernetes. O logótipo do leme que vês hoje tem sete raios como um tributo discreto a esse nome original do projeto. Esta é a parte que importa. O Kubernetes dá-te uma framework para correres sistemas distribuídos de forma resiliente. Ele trata do scaling e do failover da tua aplicação. Se um container crashar, o Kubernetes substitui-o. Se um node falhar, ele faz o reschedule dos containers em nodes saudáveis. Ele lida com o service discovery, o que significa que um container pode ser encontrado usando um nome DNS ou o seu próprio endereço IP, e faz o balanceamento do load para que nenhum container fique sobrecarregado. Também gere a storage orchestration, permitindo-te montar automaticamente storage local ou cloud providers, e automatiza rollouts e rollbacks. Tu descreves o state desejado dos teus containers em deployment, e o Kubernetes altera o state atual para o state desejado a um ritmo controlado. Não escreves scripts para gerir o state do servidor; declaras o que queres, e o sistema faz acontecer. A principal conclusão aqui é que o Kubernetes não é apenas um ambiente de hosting, é um control loop que mede constantemente a realidade em relação às tuas expectativas e corrige a diferença. Antes de terminarmos, se nos quiseres ajudar a continuar a fazer estes episódios, procura por DevStoriesEU no Patreon — agradecemos o apoio. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 2 de 10. Tens dezenas de servidores a correr centenas de containers. Quando uma máquina falha de repente, algo tem de decidir para onde vão a seguir esses workloads órfãos. Uma orquestra sem maestro é apenas ruído, e uma frota de containers sem um cérebro centralizado é um caos incontrolável. Esse cérebro centralizado, juntamente com as máquinas que fazem o trabalho propriamente dito, formam a Kubernetes Cluster Architecture. Um cluster de Kubernetes é dividido em duas metades distintas. Tens o Control Plane, que atua como o cérebro, e tens os Worker Nodes, que atuam como a força bruta. O Control Plane toma todas as decisões globais, como o scheduling de workloads, e deteta e responde a eventos do cluster. Os Worker Nodes alojam as tuas aplicações e executam as instruções enviadas pelo Control Plane. Qualquer cluster tem de ter pelo menos um worker node para correr aplicações. Olha primeiro para o Control Plane. O seu componente principal é o kube-apiserver. Quem ouve falar em API server às vezes imagina um web server standard a lidar com HTTP requests para uma aplicação. Mas não é nada disso. O kube-apiserver é o sistema nervoso central de todo o cluster. É o front end do Control Plane. Toda e qualquer comunicação, venha ela de um operador humano, de um worker node ou de um componente interno, passa por este API server. Como o API server é completamente stateless, o cluster precisa de uma memória. Essa memória é o etcd. Trata-se de um key-value store consistente e de alta disponibilidade que contém todos os dados do cluster. Sempre que uma configuração é criada ou o estado do sistema muda, o verdadeiro registo dessa mudança fica no etcd. A seguir, temos o kube-scheduler. Quando pedes ao cluster para correr um novo container workload, esse workload inicialmente não tem nenhuma máquina atribuída. O scheduler deteta este workload não atribuído. Ele avalia os requisitos de recursos, as restrições de hardware e as policy rules, e depois atribui o workload ao worker node mais apropriado. Finalmente, tens o kube-controller-manager. Este componente corre background loops contínuos chamados controllers. Estes controllers monitorizam constantemente o estado atual do cluster através do API server e trabalham ativamente para levar esse estado atual para o teu estado desejado. Se um worker node crashar, o controller manager nota a falta da máquina e desencadeia a resposta para substituir os workloads perdidos. Isso cobre o cérebro. Agora olha para os worker nodes que executam as tarefas. Os componentes de node correm em cada worker machine para manter o runtime environment. O componente mais crítico aqui é o kubelet. Trata-se de um agente a correr em cada node que comunica diretamente com o Control Plane. O kubelet recebe instruções do API server e garante que os containers necessários estão de facto a correr e healthy na sua máquina específica. O kubelet não inicia os containers por si próprio. Ele delega essa tarefa ao Container Runtime. O runtime é o software propriamente dito, como o containerd, responsável por fazer pull de container images de um registry e iniciar os processos no sistema operativo. Por fim, existe o kube-proxy. Este é um network proxy a correr em cada node. Ele mantém as regras de rede locais que permitem que a comunicação de rede chegue aos teus containers a partir de dentro ou de fora do cluster. Aqui está o ponto chave. O Control Plane dita o que deve acontecer, mas nunca executa o código da aplicação. Os worker nodes correm o código da aplicação, mas dependem inteiramente do Control Plane para lhes dizer o que correr. Esta separação estrita entre a tomada de decisão e a execução é o que permite ao Kubernetes fazer scale horizontalmente e recuperar automaticamente de falhas de hardware. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui é o Alex do DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 3 de 10. Fazes a build de um container, testas localmente e entregas ao Kubernetes para correr. Mas o Kubernetes recusa-se terminantemente a lidar diretamente com o teu container. Em vez disso, exige que o envolvas primeiro numa abstração completamente diferente. Estamos a desmistificar os Pods, a verdadeira unidade de trabalho neste ecossistema. Se os containers são as baleias independentes do mundo tradicional da containerização, os Pods são os grupos coesos onde nadam juntos. Um Pod é o objeto de deploy mais pequeno e básico que podes criar e gerir no Kubernetes. Representa uma única instância de um processo a correr no teu cluster. Podes perguntar-te por que razão o Kubernetes introduz esta camada extra em vez de simplesmente gerir os containers diretamente. A resposta está na abstração e no contexto partilhado. O Kubernetes precisa de uma forma uniforme de lidar com networking, storage e scheduling, independentemente do container runtime específico que usas. Ao envolver os containers num Pod, o Kubernetes trata o Pod como um host lógico. Aqui está o ponto-chave. Um Pod não envolve apenas um único container; estabelece um ambiente de execução partilhado. Embora um Pod muitas vezes contenha apenas um container, pode alojar múltiplos containers que precisam de trabalhar em estreita colaboração. Quando vários containers são colocados dentro do mesmo Pod, é garantido que vão ser scheduled na mesma máquina física ou virtual. Mais importante ainda, estes containers partilham o mesmo network namespace. Cada container dentro de um único Pod partilha um único endereço IP e um único port space. Como existem no mesmo contexto de rede, podem comunicar entre si simplesmente usando o localhost. Não há necessidade de DNS lookups internos ou routing de serviços complexo apenas para pôr dois processos locais a falar. Se o container A fizer bind ao port oito mil, o container B no mesmo Pod pode aceder-lhe no localhost, port oito mil. Este contexto partilhado estende-se ao storage. Podes definir volumes de storage partilhados ao nível do Pod. Uma vez definidos, qualquer container dentro desse Pod pode fazer mount desses volumes partilhados no seu próprio file system. Isto permite que containers tightly coupled leiam e escrevam exatamente os mesmos ficheiros sem problemas. Considera um container de web server principal. O seu trabalho é servir tráfego HTTP, mas também escreve access logs raw para um diretório local. Queres enviar esses logs para um sistema de monitorização central, mas não queres sobrecarregar a image do teu web server com logging agents e ficheiros de configuração. Em vez disso, crias um segundo container, um utilitário de logging leve. Fazes deploy tanto do web server como do container de logging dentro do exato mesmo Pod. O web server escreve os seus logs num volume de storage partilhado. O container de logging, atuando como um sidecar, faz mount desse mesmo volume, lê os ficheiros de log recebidos e faz stream deles para o teu sistema de monitorização. Operam como uma unidade integrada, partilhando recursos sem misturar as suas responsabilidades individuais. Ao decidir se dois containers pertencem ao mesmo Pod, pergunta-te se eles precisam inerentemente de ficar na exata mesma máquina e partilhar um lifecycle idêntico. Se não precisarem absolutamente de fazer deploy, arrancar e morrer juntos, pertencem a Pods separados. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 4 de 10. Estás a dormir. Às três da manhã, um memory leak manda abaixo o servidor principal da tua aplicação. Num setup tradicional, dispara um alerta e acordas para reiniciar o processo manualmente. No Kubernetes, o sistema cuida do turno da noite por ti. Este é o poder de gerir o state com Deployments. Um Deployment fornece updates declarativos para as tuas aplicações. Em vez de escreveres scripts que comandam o sistema passo a passo sobre como correr o teu software, descreves exatamente como deve ser o resultado final. Passas este estado desejado ao Deployment controller, e ele altera o estado real para corresponder, a um ritmo controlado. Para perceberes como isto acontece, precisas de conhecer a hierarquia. Raramente crias Pods individuais diretamente. Em vez disso, crias um Deployment. O Deployment cria depois um objeto secundário chamado ReplicaSet. O ReplicaSet é o mecanismo estritamente responsável por garantir que o número exato especificado de réplicas de Pods está a correr a qualquer momento. Se um node do servidor falhar, ou um Pod fizer crash devido àquele memory leak, o ReplicaSet nota que os números caíram abaixo do teu estado desejado. Arranca imediatamente com um novo Pod para substituir o perdido. Esse é o teu mecanismo de self-healing. Tu nunca intervens. A mesma lógica aplica-se ao scaling. Se houver um pico de tráfego, atualizas o teu ficheiro de Deployment para pedir cinco réplicas em vez de três. O controller vê a discrepância entre o teu pedido e a realidade, e instrui o ReplicaSet a lançar mais dois Pods. Esta abordagem declarativa é crucial durante os updates da aplicação. Imagina que tens três Pods a correr uma imagem do Nginx na versão 1.14. Precisas de fazer upgrade para a versão 1.16 sem deixar cair o tráfego dos utilizadores. Basta atualizares a versão da imagem na configuração do teu Deployment. O Deployment não termina todos os teus Pods antigos de uma só vez. Em vez disso, cria um ReplicaSet totalmente novo especificamente para a versão 1.16. Em seguida, inicia um rolling update. Arranca com um novo Pod no novo ReplicaSet. Assim que esse novo Pod estiver healthy, faz scale down do ReplicaSet antigo, terminando um Pod da versão 1.14. Repete este processo cuidadoso e faseado até que todos os três Pods antigos desapareçam e três novos Pods estejam a correr. A transição é completamente impercetível. Agora, o que acontece se o update falhar? Aqui está o ponto chave. Como o Deployment controller orquestra estes ReplicaSets, dá-te uma rede de segurança integrada. Se digitares acidentalmente o nome da imagem como Nginx 1.16-typo, os novos Pods vão fazer crash no startup. O Deployment deteta a falha e interrompe o rollout imediatamente. Mantém os restantes Pods antigos a correr para que a tua aplicação permaneça online. Assim que identificares o erro, podes executar um comando de rollback. O Deployment simplesmente faz scale up do ReplicaSet antigo e funcional, e faz scale down do que tem falhas para zero. A verdadeira força de um Deployment não está apenas em lançar containers, mas no seu loop contínuo e implacável de comparar o que pediste com o que realmente existe, forçando a realidade a corresponder. Queria aproveitar um momento para te agradecer por ouvires — ajuda-nos muito. Tem um ótimo dia!

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 5 de 10. Os Pods são mortais. Eles crasham, fazem scale down, são evicted, e quando são substituídos, recebem um endereço IP completamente novo. Se tens uma aplicação a tentar comunicar com eles, estás constantemente a atirar a um alvo em movimento. Os Services de Kubernetes resolvem exatamente este problema. Pensa numa aplicação web típica. Tens um deployment de frontend e uma base de dados no backend. Se o teu Pod da base de dados reiniciar, o control plane do cluster arranca um novo Pod para o substituir. Este novo Pod recebe um endereço IP completamente diferente na rede do cluster. Se o teu frontend estava configurado para falar diretamente com o IP antigo, a ligação cai e a tua aplicação quebra. Não podes confiar nos IPs individuais dos Pods para nada permanente. Um Service de Kubernetes é uma abstração que fornece uma identidade de rede estável e duradoura para um grupo dinâmico de Pods. Quando crias um Service, é-lhe atribuído um endereço IP que nunca vai mudar enquanto o Service existir. A tua aplicação de frontend não precisa de saber exatamente quais os Pods da base de dados que estão vivos a cada segundo. Simplesmente envia tráfego para o IP do Service. Além disso, o cluster atribui um nome DNS estável ao Service. O teu código de frontend pode simplesmente ligar-se a um hostname simples, e o cluster resolve isso automaticamente para o endereço IP correto. Nos bastidores, o Service atua como um load balancer interno. Ele depende de um componente chamado kube-proxy, a correr em cada node, para implementar as regras de routing reais. Quando o tráfego chega ao Service, é reencaminhado para um dos Pods saudáveis que o suportam. Para ligar um Service aos Pods certos, usas labels e selectors. Podes configurar o Service com um selector à procura da label que indica uma aplicação de base de dados. O Service monitoriza o cluster constantemente. Se um Pod da base de dados morrer, o seu IP é removido da pool ativa. Quando o Pod de substituição arranca, o seu novo IP é adicionado. A aplicação de frontend permanece completamente alheia ao facto de a topologia de rede subjacente ter acabado de mudar. Existem algumas formas de expor um Service, dependendo da origem do tráfego. O tipo por defeito é ClusterIP. Um Service ClusterIP recebe um endereço IP interno, acessível apenas a partir de dentro do cluster. Esta é a escolha certa para a tua base de dados de backend, mantendo-a isolada e segura do mundo exterior. Mas o teu frontend precisa de receber tráfego de utilizadores externos. Para isso, mudas o tipo de Service para LoadBalancer. Quando crias um Service LoadBalancer, o Kubernetes comunica com o teu cloud provider para provisionar um load balancer externo standard. O tráfego externo da internet atinge esse recurso na cloud, que reencaminha a ligação para o teu cluster, passando-a pelo Service e, finalmente, para os teus Pods de frontend. Aqui está o ponto-chave. Os Services desacoplam a identidade endereçável da tua aplicação dos workloads físicos que estão realmente a executar a lógica. Paras de fazer routing para instâncias específicas e frágeis e começas a fazer routing para um conceito resiliente e persistente. É tudo por este episódio. Obrigado por ouvires, e continua a programar!

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 6 de 10. Queres fazer o deploy de uma única aplicação, mas acabas a gerir centenas de linhas de YAML estático entre deployments, services e ingresses. Quando precisas de fazer push dessa mesma aplicação para um ambiente de staging, copias esses ficheiros para um novo diretório e procuras e substituis manualmente as image tags e hostnames. É frágil, altamente repetitivo e impossível de manter à medida que a tua infraestrutura cresce. Este é exatamente o problema que o Helm existe para resolver. O Helm é o package manager para Kubernetes. Podes pensar nele como o apt, yum ou Homebrew, mas desenhado especificamente para recursos de Kubernetes. Em vez de tratares a tua aplicação como uma coleção solta de YAML manifests independentes, o Helm agrupa-os numa única unidade coesa. Este formato de packaging chama-se Chart. Um Chart é essencialmente um diretório que contém ficheiros que descrevem um conjunto relacionado de recursos de Kubernetes. Ele contém todas as definições de que a tua aplicação precisa para correr. O principal mecanismo que torna um Chart útil é o templating. Os Kubernetes manifests raw são totalmente estáticos. Um Helm Chart, por outro lado, substitui detalhes de infraestrutura hardcoded por template variables. Em vez de escreveres um replica count específico, uma container image tag fixa ou uma environment variable distinta diretamente num ficheiro de deployment, defines placeholders. Quando chega a hora de fazer o deploy, o Helm faz merge destes templates com um ficheiro separado que contém os teus valores específicos. Esta arquitetura significa que só tens de manter um único Chart para a tua aplicação. Simplesmente passas-lhe diferentes parâmetros de configuração dependendo se estás a fazer o deploy localmente, para staging ou para produção. Quando pegas num Chart, o combinas com os teus valores de configuração específicos e fazes o deploy para um Kubernetes cluster, crias o que o Helm chama de Release. É aqui que a coisa fica interessante. Um Chart é apenas o blueprint genérico. Uma Release é a instância real com deploy feito a correr no teu cluster. Devido a esta separação estrita entre o blueprint e a instância, podes instalar exatamente o mesmo Chart várias vezes exatamente no mesmo cluster. Se precisares de três instâncias separadas de um caching server, não duplicas o YAML. Instalas o caching chart três vezes. O Helm faz o tracking de cada instalação como uma Release distinta, com o seu próprio nome único, os seus próprios valores de configuração e o seu próprio lifecycle isolado. O Helm também faz o tracking do estado e do histórico destas Releases dentro do cluster. Quando atualizas uma aplicação ao fornecer uma nova image tag ou ao modificar uma configuração, o Helm avalia as diferenças e cria uma nova revision dessa Release específica. Ele aplica apenas as alterações necessárias aos recursos de Kubernetes subjacentes. Se um update falhar ou uma aplicação começar a comportar-se de forma errática, dás o comando ao Helm para fazer rollback para uma revision anterior. O Helm sabe exatamente quais recursos de Kubernetes pertencem a que versão da tua aplicação, gerindo a criação, modificação e eliminação desses recursos como uma única operação. A principal mudança com o Helm é a abstração. Paras de gerir ficheiros de texto independentes que representam pods, services e volumes desconectados, e começas a fazer o deploy, a configurar e a fazer upgrade de aplicações completas. Obrigado por ouvirem, happy coding a todos!

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 7 de 10. Precisas de atualizar a password de uma base de dados, mas as credenciais estão hardcoded em quinze ficheiros YAML diferentes. Basta falhar um ficheiro, e o deployment inteiro falha. Fazer hardcode da configuração diretamente na tua estrutura de deployment é frágil. A solução é perceber a Anatomia de um Helm Chart. Um Helm chart é um package standard que contém todas as definições de recursos necessárias para correr uma aplicação, ferramenta ou serviço dentro de um cluster Kubernetes. Todo o sistema é construído à volta de uma filosofia central: uma separação estrita entre a definição estrutural e a configuração específica do ambiente. Defines a forma do teu deployment uma vez, e injetas os detalhes específicos quando chega a hora de fazer o deploy. Quando olhas para dentro de um Helm chart, encontras um layout de diretórios específico. A pasta de topo tem sempre o nome do próprio chart. Dentro desta pasta, três componentes principais controlam o sistema de packaging. O primeiro é um ficheiro chamado Chart ponto yaml. Este é o hub de metadados. Diz ao Helm exatamente o que o package é. Contém a versão da API para o standard do chart, o nome do chart, uma descrição e os números de versão. Crucialmente, faz o tracking tanto da versão do próprio chart, como da app version, que é a versão do software que está a ser alvo de deploy. Podes também encontrar um diretório charts ao lado, que guarda quaisquer subcharts dos quais a tua aplicação depende, mas o ficheiro de metadados é o identificador principal. O segundo componente principal é o diretório templates. É aqui que vive a definição estrutural. Lá dentro, colocas os teus ficheiros manifest standard do Kubernetes, como deployments e services. No entanto, em vez de escreveres YAML estático, estes ficheiros contêm lógica de Go template. Em vez de fazeres hardcode de um replica count de três, ou colares uma password específica da base de dados, escreves uma diretiva de template. Essa diretiva instrui o Helm a procurar o valor necessário dinamicamente durante o deployment. O terceiro componente responde a esses lookups dinâmicos. É um ficheiro chamado values ponto yaml, localizado na raiz do diretório do chart, ao lado do ficheiro de metadados. Este ficheiro guarda as configurações default. Quando um template pede um repositório de imagens, um número de porto, ou uma password, o ficheiro de values fornece a resposta de base. Aqui está a ideia chave. Os templates ditam a arquitetura da tua aplicação, enquanto os values ditam como essa arquitetura se comporta num ambiente específico. Quando corres um comando de install, o Helm pega nos templates raw, faz merge deles com o ficheiro de values, e faz o render de manifests Kubernetes finais e válidos. De seguida, envia esses manifests renderizados para a API do Kubernetes. Esta separação é o que torna os charts altamente reutilizáveis. Considera um cenário onde tens de fazer o deploy da exata mesma aplicação tanto para um ambiente de staging como para um ambiente de produção. Não copias nem alteras o chart. Usas exatamente a mesma estrutura de diretórios e os exatos mesmos templates. Para o deployment de staging, passas ao Helm um ficheiro de values customizado durante o comando de install. Este ficheiro faz override aos defaults, especificando uma pod replica, um URL de base de dados de teste local, e logging de nível debug. Quando fazes deploy para produção, passas um ficheiro de values completamente diferente. Este ficheiro de produção especifica dez replicas, um URL de base de dados managed, e restrições estritas de recursos. O Helm faz merge do conjunto único de templates com os respetivos ficheiros de values customizados, produzindo dois perfis de deployment completamente diferentes. O poder de um Helm chart não reside no YAML que contém, mas nas fronteiras que cria. Tranca a arquitetura de infraestrutura nos templates, enquanto mantém os detalhes operacionais totalmente fluidos nos values. É tudo por este episódio. Obrigado por ouvires, e continua a construir!

Olá, daqui fala o Alex da DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 8 de 10. Só porque podes criar templates para cada linha de um manifest do Kubernetes não significa que o devas fazer. Quando tentas tornar todos os campos configuráveis, acabas com um chart que ninguém consegue ler, muito menos manter. Este episódio aborda as melhores práticas para Helm charts, as regras que impedem que as tuas configurações entrem em colapso sob o próprio peso. A maior armadilha na criação de charts é o excesso de templates. Muitos developers tratam os templates do Helm como um simples script de substituição de texto. Isso é um equívoco comum. O Helm executa um Go template engine para produzir YAML estruturado e válido. Se simplesmente adicionares uma variável a um ficheiro sem gerir cuidadosamente a indentação e os tipos de dados, o YAML gerado ficará completamente corrompido. Por isso, deves criar templates apenas para os valores que realmente mudam entre ambientes. Pensa em image tags, replicas, resource limits ou ingress rules. Deixa os campos estruturais principais hardcoded. Se um utilizador nunca precisar de alterar um security context específico ou um volume mount, não o exponhas como uma variável. O ficheiro values ponto yaml funciona como a API pública do teu chart. Ao organizar este ficheiro, deves equilibrar estrutura e usabilidade. A recomendação oficial é manter a hierarquia o mais shallow possível. Embora devas agrupar parâmetros relacionados, evita o deep nesting. Considera o utilizador a passar overrides através da command line. Obrigá-lo a digitar um caminho separado por pontos com cinco níveis de profundidade apenas para alterar um número de porta causa atrito desnecessário. Se tiveres uma configuração de web server, coloca as propriedades sob uma única server key, mas mantém as propriedades internas flat. Ao nomear estas variáveis, usa sempre camel case. Começa com uma letra minúscula e coloca em maiúscula a primeira letra de cada palavra subsequente. Não uses hífens ou underscores no teu ficheiro de values. Podes criar uma variável chamada externalPort, em vez de external dash port. O uso consistente de camel case evita erros de parsing durante o template rendering e está em conformidade com os padrões mais amplos do ecossistema Kubernetes. Além disso, mantém uma consistência rigorosa de tipos. Se um parâmetro for um número inteiro no Kubernetes, como um número de porta, mantém-no como um número inteiro no teu ficheiro de values. Não o coloques entre aspas e não o transformes numa string. Esta consistência aplica-se diretamente à forma como aplicas as tags aos recursos gerados pelo teu chart. Cada objeto precisa de labels padrão. As melhores práticas do Helm recomendam o uso das labels oficiais de apps do Kubernetes. Especificamente, usa o prefixo app ponto kubernetes ponto io. A label name deve corresponder ao nome do chart, enquanto a label instance deve corresponder ao release name. Deves também incluir a label version e indicar que o recurso é gerido pelo Helm. Aplicar estas labels exatas a cada deployment, pod, service e config map garante que ferramentas de monitorização externas e service meshes possam descobrir e agrupar automaticamente os componentes da tua aplicação sem configuração manual. Aqui está a principal conclusão: o melhor Helm chart não é aquele com mais opções de configuração. É aquele que requer o mínimo de overrides para funcionar com sucesso out of the box. Se quiseres ajudar a manter o programa no ar, procura por DevStoriesEU no Patreon — agradecemos muito o apoio. Obrigado por passares uns minutos comigo. Até à próxima, e fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 9 de 10. Construir um cluster do zero é um ótimo exercício de aprendizagem, mas quando escalas para centenas de microserviços, não queres gerir o control plane tu mesmo. Queres que o cloud provider faça o trabalho pesado para que os teus engenheiros se possam focar em entregar código. É exatamente este o aspeto de uma implementação enterprise de Kubernetes e Helm no Azure. Numa arquitetura standard de Kubernetes, tens um control plane a tomar decisões globais e worker nodes a executá-las. Manter esse control plane altamente disponível é notoriamente difícil. Um cliente enterprise a fazer deploy no Azure normalmente usa o Azure Kubernetes Service, ou AKS. O AKS abstrai o control plane. O Azure gere o API server, o scheduler e o data store key-value. A tua equipa de operações é apenas responsável pelos worker nodes que realmente correm as tuas aplicações. Então, como é que uma aplicação sai da máquina do developer e chega a esses worker nodes? É aqui que o Helm entra no workflow. Uma aplicação enterprise raramente consiste num único container. Geralmente, é uma coleção de microserviços, cada um a precisar dos seus próprios deployments, services e configurações. Em vez de gerir dezenas de ficheiros YAML estáticos, os developers empacotam estes recursos num Helm chart. Um chart atua como um blueprint único e versionado para um microserviço. Como o Helm usa templates, os developers podem escrever a lógica estrutural uma única vez e injetar diferentes valores de configuração, dependendo se estão a fazer deploy para um cluster de development, staging ou production. Antes de qualquer coisa correr, é feito o build do código da aplicação para imagens de container. É feito o push destas imagens para um local de armazenamento seguro, como um container registry. Os próprios Helm charts também podem ser empacotados e enviados para um registry, o que permite que as equipas enterprise tratem as suas definições de infraestrutura exatamente como o seu código de aplicação compilado. Aqui está a ideia principal. Quando um release pipeline faz trigger de um deployment, o Helm avalia os seus templates com os valores específicos do ambiente e envia os manifests finais para o API server do AKS. O control plane do AKS lê este desired state e começa a fazer o scheduling de Pods para os teus worker nodes. Os nodes ligam-se ao container registry, autenticam-se com segurança, fazem pull das versões específicas da imagem e arrancam os containers. O Kubernetes monitoriza constantemente este estado. Se um worker node for abaixo, o control plane faz imediatamente o reschedule dos seus Pods para nodes saudáveis, de forma a manter o replica count definido no Helm chart. Assim que os Pods estiverem a correr, precisam de receber tráfego. Um Helm chart normalmente inclui uma definição de service para expor a aplicação. Quando é feito o deploy disto para o AKS, o Kubernetes comunica diretamente com a infraestrutura subjacente do Azure. Se o service pedir um entry point público, o AKS provisiona automaticamente um Azure Load Balancer. Este load balancer recebe o tráfego externo de entrada e encaminha-o com segurança para o cluster, distribuindo-o pelos Pods saudáveis. Os teus developers nunca precisaram de tocar no portal do Azure nem de escrever regras específicas de routing na cloud. Eles simplesmente definiram um service standard de Kubernetes no seu Helm chart, e a plataforma gerida tratou do provisionamento da rede física. O verdadeiro poder desta arquitetura enterprise é a clara separação de responsabilidades. O Helm padroniza a forma como a aplicação é definida entre ambientes, o registry protege os artefactos versionados, e a plataforma de cloud gerida garante que a infraestrutura subjacente se mantém viva para a correr. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. Fundamentos de Kubernetes e Helm, episódio 10 de 10. Já tens a teoria e as ferramentas. Mas quando olhas para um terminal vazio, o fosso entre uma infraestrutura cloud massiva e o teu portátil parece incrivelmente grande. Fechar esse fosso é exatamente o objetivo de começares a usar o Minikube. Um cluster Kubernetes de produção envolve várias máquinas a atuar como control planes e worker nodes. Provisionar isso na cloud custa dinheiro, leva tempo e exige uma configuração de rede complexa. Para um developer a solo ou uma pequena equipa a desenhar uma arquitetura day-one, precisas de um ambiente local que se comporte exatamente como a produção, sem o overhead. O Minikube é uma implementação leve de Kubernetes que cria uma máquina virtual ou um container diretamente no teu portátil. Dentro desse ambiente isolado, ele faz o deploy de um cluster simples de um único node. Normalmente, o Kubernetes separa o control plane, que gere o estado do cluster, dos worker nodes, que correm os containers da tua aplicação. O Minikube combina-os. A tua máquina local corre um node que lida tanto com a lógica de gestão como com os workloads reais da aplicação. Não foi feito para servir tráfego de produção. Existe apenas para que possas testar a tua orquestração de containers em segurança. Aqui está o ponto crucial. A interface que usas para interagir com o Minikube é idêntica à que usas para um cluster cloud massivo. Usas a ferramenta de linha de comandos chamada kubectl. Quando executas um comando kubectl, ele comunica diretamente com o control plane do Minikube através da sua API. Não há nenhuma sintaxe especial para aprenderes para desenvolvimento local. O workflow corresponde perfeitamente ao tutorial oficial de conceitos básicos de Kubernetes. Inicias o cluster com um simples comando start. O Minikube provisiona o ambiente e configura automaticamente o kubectl para apontar para a tua nova instância local. A partir daí, usas o kubectl para criar um deployment. Dizes ao control plane para fazer pull de uma imagem de container específica e corrê-la. Uma vez feito o deploy, a tua aplicação está a correr dentro de um pod nesse único node. No entanto, está isolada da tua rede host. Para acederes a partir do browser do teu portátil, tens de a expor criando um service. Um service encaminha o tráfego de um port específico na tua máquina local para o port correto no pod a correr dentro do Minikube. A partir deste ponto, podes praticar todas as funções core de Kubernetes. Podes escalar a tua aplicação dizendo ao kubectl para aumentar o número de replicas. O Minikube vai arrancar com pods adicionais ao lado do primeiro. Podes praticar rolling updates alterando a versão da imagem do container no teu deployment. O Minikube vai terminar os pods antigos de forma graceful e iniciar novos, simulando um deployment com zero-downtime. Como o Minikube expõe uma API standard de Kubernetes, o teu tooling externo integra-se perfeitamente. O Helm funciona imediatamente. Podes instalar bases de dados complexas, ingress controllers ou message queues usando Helm charts exatamente como farias num ambiente live. O Minikube até inclui addons built-in, como um web dashboard local, permitindo-te inspecionar visualmente o estado do teu cluster, ler logs e monitorizar o uso de recursos. O verdadeiro poder de um cluster local é a paridade. Quando escreves uma configuração de deployment ou um Helm chart que corra com sucesso no Minikube, já escreveste a configuração exata que vai correr na cloud. Tira algum tempo para explorar a documentação oficial de Kubernetes e experimentar estes comandos hands-on. Se tiveres sugestões de tópicos que devamos abordar na nossa próxima série, visita devstories dot eu e diz-nos. Por hoje é tudo. Obrigado por ouvires, vai construir algo fixe.