Como aceleramos a adoção do Kubernetes em larga escala

fonte: Google Images

Se você não estava preso em uma cabana no meio da floresta totalmente isolado do mundo, com certeza já deve ter ouvido falar sobre o Kubernetes, caso ainda não tenha ouvido falar, o Kubernetes (também conhecido como k8s) segundo o site oficial.

É um sistema open source para deployments automatizados, scaling e gerenciamento de aplicações conteinerizadas

Se você ainda não teve a oportunidades de conhecer esse projeto fantástico, pause a leitura desse artigo e procure saber mais sobre, você pode começar por aqui.

Agora que você já sabe o que é o k8s, já sabe o impacto que ele vem causando na forma como colocamos aplicações no ar. De fato é muito simples escrever um yaml e rodar um comando kubectl apply -f my-project.yaml, porém, isso é escalável?

Você não pode simplesmente entregar o kubectl para todos os desenvolvedores da sua empresa e esperar que nenhum comando perigoso (ou desastroso) seja executado, principalmente se você conta com um número elevado de desenvolvedores (IMO, nesse cenário, 20 desenvolvedores já é um número grande). E é claro, kubectl é uma ferramenta para quem opera o cluster, não para quem desenvolve aplicações para ele :-].

A solução mais comum que vem sendo empregada por várias empresas é investir pesado em processos de CI/CD, porém, com CI/CD, até onde vai a autonomia do desenvolvedor e o quanto você consegue expor de funcionalidades para eles? Outros problemas nesse cenário podem vir a tona, como por exemplo, manter (ou pagar por) um registry de imagens docker privado, falta de padronização nos objetos criados no cluster, etc.

Aqui no LuizaLabs escolhemos outro caminho.

Kubernetes in real life

No LuizaLabs estamos na margem de 400 desenvolvedores e em constante expansão. Esses desenvolvedores possuem os mais diversos skills e backgrounds, alguns já experientes em aplicações que rodam no cloud, outros ainda com dependências rodando on premise.

Nosso desafio é continuar aumentando essa escala mas sem perder agilidade. Porém sem uma padronização na forma como provisionamos nossos ambientes, isso seria uma tortura. Nesse aspecto o k8s se torna nosso melhor amigo, no entanto temos os problemas já citados antes.

A partir dessa dor, resolvemos criar o nosso próprio PaaS.

Teresa — Nosso próprio PaaS

Sim, é isso mesmo, nós optamos por construir nosso próprio PaaS nos espelhando em projetos de sucesso como por exemplo o Heroku, porém, em cima do k8s.

O Teresa é um projeto open source, escrito em Golang e em constante evolução, com ele você consegue fazer o seu controle de usuários e permissões completamente apartado do k8s e de quebra você ainda possui uma ferramenta poderosa para fazer build de suas aplicações (baseado nos buildpacks do heroku).

E o melhor de tudo, com poucos comandos você pode instalar o Teresa em seu cluster de k8s e ter seu próprio PaaS (veremos como fazer isso em um próximo artigo :-] ).

Como o Teresa funciona

O Teresa após instalado no cluster, passa a consumir o kube-apiserver para criar objetos no cluster. Ao criar um novo app, o Teresa cria um novo namespace para esse app com alguns secrets.

De maneira simplificada, no momento do deploy desse app, é gerado um pod que utiliza o Slugbuilder em conjunto com os buildpacks do Heroku a fim de criar um build da aplicação.

Ao final da geração desse build, o Teresa gera um deploy do k8s utilizando como imagem o Slugrunner e caso a aplicação seja um webservice, um Service do k8s é criado (isso somente no primeiro deploy).

Autonomia com responsabilidade

Com o Teresa, os desenvolvedores têm a autonomia que precisam e o time de ops tem menos overhead.

A partir do cli da Teresa o desenvolvedor consegue criar usuários, times, aplicações, consegue deletá-los, criar deploys, cronjobs, fazer rollbacks, alterar regras de scaling, quotas de recurso, variáveis de ambiente, configurar healthchecks, estratégia de rolling update, consultar logs (com opção de follow), rodar comandos em réplicas isoladas, etc. Isso sem contar as vantagens de rodar uma aplicação no k8s, como por exemplo service discovery.

Em termos de operação do cluster, as aplicações criadas no k8s via Teresa segue o mesmo padrão, então é mais fácil entender o que está acontecendo no cluster e como debugar uma aplicação no meio de um troubleshooting.

Em um dos próximos artigos mostraremos como subir uma aplicação no k8s via Teresa e como manipulá-la.

Os resultados obtidos

Hoje, graças ao Teresa, já temos (até o momento) mais de 200 aplicações em produção, escritas em diferentes linguagens (python, go, java e nodejs) e já passamos por duas black friday.

Com pouquíssimas adequações (ouvir na porta especificada na variável de ambiente $PORT e ter um Procfile), qualquer aplicação já está preparada para rodar no k8s via Teresa, o que significa que a aplicação já se torna nativa ao cloud (ok, eu sei, só isso não torna a aplicação resiliente por exemplo, mas é um passo).

Outra vantagem de estar on top of kubernetes é que nossa infra se torna multi-cloud (inclusive já rodamos o Teresa em clusters de k8s on premise e em diferentes cloud providers)

Como posso usar?

Em outros posts pretendo mostrar os processos de instalação do Teresa em um cluster k8s (visão do admin do cluster) e como utilizar a ferramenta (visão do desenvolvedor), mas se você não quiser esperar, você pode olhar o README do projeto.

Caso você tenha alguma dúvida, pode entrar em contato conosco no canal #teresa no slack da comunidade go.

Like what you read? Give Diego Garcia a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.