🥇Ferramentas para desenvolvedores de aplicativos que rodam em Kubernetes

Uma abordagem moderna para a operação resolve muitos problemas urgentes dos negócios. Contêineres e orquestradores permitem escalar facilmente projetos de qualquer complexidade, simplificam os lançamentos de novas versões, tornando-os mais confiáveis, mas ao mesmo tempo criam problemas adicionais para os desenvolvedores. O que mais preocupa um programador é seu código: arquitetura, qualidade, desempenho, elegância — e não como ele será executado no Kubernetes ou como testá-lo e depurá-lo após fazer até mesmo as menores alterações. Portanto, é bastante natural que ferramentas para Kubernetes estejam se desenvolvendo ativamente, ajudando a resolver problemas mesmo dos desenvolvedores mais "arcaicos" e permitindo que eles se concentrem no que realmente importa.

Esta revisão apresenta um resumo de algumas ferramentas que facilitam a vida do programador cujo código opera em pods de um cluster Kubernetes.

Auxiliares simples

Kubectl-debug

Essência: adicione seu contêiner ao Pod e veja o que está acontecendo nele.
GitHub.
Estatísticas breves do GH: 715 estrelas, 54 commits, 9 colaboradores.
Linguagem: Go.
Licença: Apache License 2.0.

Este plugin para kubectl permite criar dentro do pod de interesse um contêiner adicional que compartilhará o espaço de nomes dos processos com os outros contêineres. Nele, você pode depurar o funcionamento do pod: verificar a funcionalidade da rede, ouvir o tráfego de rede, fazer strace do processo de interesse, etc.

Você também pode alternar para o contêiner do processo executando chroot /proc/PID/root — isso pode ser muito conveniente quando você precisa obter um shell root no contêiner, para o qual foi definido no manifesto securityContext.runAs.

A ferramenta é simples e eficaz, sendo útil para todo desenvolvedor. Fomos mais a fundo sobre isso em um artigo separado.

Telepresence

Essência: mova o aplicativo para o seu computador. Desenvolva e depure localmente.
Site; GitHub.
Estatísticas breves do GH: 2131 estrelas, 2712 commits, 33 colaboradores.
Linguagem: Python.
Licença: Apache License 2.0.

A ideia deste plug-in é executar um contêiner com o aplicativo no computador do usuário local e encaminhar todo o tráfego do cluster para ele e vice-versa. Essa abordagem permite desenvolver localmente, simplesmente alterando os arquivos em seu IDE favorito: os resultados estarão disponíveis imediatamente.

As vantagens da execução local incluem a facilidade de edição e resultados instantâneos, bem como a possibilidade de depurar o aplicativo da maneira usual. Entre as desvantagens estão a exigência de uma conexão rápida, que se torna especialmente evidente ao trabalhar com aplicativos que têm um RPS e tráfego elevados. Além disso, o Telepresence enfrenta problemas com mounts de volume no Windows, o que pode se tornar uma limitação decisiva para os desenvolvedores acostumados a esse sistema operacional.

Já compartilhamos nossa experiência com o uso do Telepresence. aqui.

Ksync

Essência: sincronização quase instantânea de código com o contêiner no cluster..
GitHub.
Estatísticas rápidas do GH: 555 estrelas, 362 commits, 11 contribuidores.
Linguagem: Go.
Licença: Apache License 2.0.

A ferramenta permite sincronizar o conteúdo de um diretório local com o diretório de um contêiner executado no cluster. Essa ferramenta é ideal para desenvolvedores que trabalham com linguagens de programação script, cuja principal dificuldade é transferir o código para um contêiner em funcionamento. O Ksync foi projetado para aliviar essa dor de cabeça.

Com a inicialização única pelo comando ksync init , é criado um DaemonSet no cluster, que é utilizado para monitorar o estado do sistema de arquivos do contêiner selecionado. No computador local, o desenvolvedor executa o comando ksync watch, que monitora as configurações e inicia syncthing, que realiza a sincronização direta dos arquivos com o cluster.

Resta instruir o ksync sobre o que e como sincronizar. Por exemplo, o comando:

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

… criará um watcher chamado myproject, que procurará o pod com o rótulo app=backend e tentará sincronizar o diretório local /home/user/myproject/ com o diretório /var/www/myproject/ do contêiner chamado php.

Problemas e observações sobre ksync a partir da nossa experiência:

Nos nós do cluster Kubernetes, deve ser utilizado o overlay2 como driver de armazenamento para o Docker. Nenhuma outra ferramenta funcionará.
Ao usar o Windows como sistema operacional do cliente, pode haver um funcionamento incorreto do watcher do sistema de arquivos. Este bug foi observado ao trabalhar com diretórios grandes — com muitas camadas de arquivos e diretórios. Criamos um issue correspondente no projeto syncthing, mas ainda não houve progresso (desde o início de julho).
Use o arquivo .stignore para indicar caminhos ou padrões de arquivos que não devem ser sincronizados (por exemplo, diretórios app/cache e .git).
Por padrão, o ksync reiniciará o contêiner sempre que houver mudanças nos arquivos. Para Node.js isso é conveniente, mas para PHP é completamente desnecessário. É melhor desativar o opcache e usar a flag --reload=false.
A configuração pode sempre ser corrigida em $HOME/.ksync/ksync.yaml.

Squash

Essência: debute processos diretamente no cluster.
GitHub.
Estatísticas breves do GH: 1154 estrelas, 279 commits, 23 contribuidores.
Linguagem: Go.
Licença: Apache License 2.0.

Esta ferramenta é destinada à depuração de processos diretamente em pods. A utilidade é simples e em modo interativo permite escolher o depurador apropriado (veja abaixo) e namespace + pod, no processo no qual se deseja interferir. Atualmente, são suportados:

delve – para aplicações em Go;
GDB – através de target remote + redirecionamento de porta;
redirecionamento de porta JDWP para depuração de aplicações Java.

Do lado da IDE, há suporte apenas no VScode (usando para desenvolvimento remoto no VS Code (VS Code Remote — WSL) é a última etapa que garante um trabalho confortável para o desenvolvedor. A extensão permite que o VS Code execute todas as suas operações (comandos git, console, instalação de extensões e assim por diante) interagindo diretamente com a máquina virtual Linux. Isso torna todo o processo muito autônomo.), no entanto, está nos planos deste ano (2019) incluir Eclipse e Intellij.

Para depurar processos, o Squash inicia um contêiner privilegiado nos nós do cluster, portanto, é necessário primeiro se familiarizar com as possibilidades do modo seguro para evitar problemas de segurança.

Soluções complexas

Vamos passar para a pesada artilharia – projetos mais "escaláveis", destinados a atender várias necessidades dos desenvolvedores simultaneamente.

NB: Nesta lista, sem dúvida, há um espaço para nossa ferramenta de código aberto werf (anteriormente conhecida como dapp). No entanto, já escrevemos e falamos sobre ela muitas vezes, portanto decidimos não incluí-la na revisão. Para quem deseja se familiarizar mais com suas capacidades, recomendamos ler/escutar a apresentação "werf — nossa ferramenta para CI/CD no Kubernetes».

DevSpace

Essência: para aqueles que querem começar a trabalhar com Kubernetes, mas não querem se aprofundar em suas complexidades.
GitHub.
Estatísticas breves do GH: 630 estrelas, 1912 commits, 13 contribuidores.
Linguagem: Go.
Licença: Apache License 2.0.

Solução da empresa homônima, que fornece clusters gerenciados com Kubernetes para desenvolvimento em equipe. A ferramenta foi criada para clusters comerciais, mas funciona muito bem com qualquer outro tipo.

Ao executar o comando devspace init no diretório do projeto será apresentada (em modo interativo):

escolher um cluster Kubernetes ativo,
usar um existente Dockerfile (ou gerar um novo) para criar um contêiner com base nele,
escolher um repositório para armazenar as imagens dos contêineres, etc.

Após todas essas etapas preparatórias, é possível começar o desenvolvimento, executando o comando devspace dev. Ele irá montar o contêiner, fazer o upload para o repositório, implantar o deployment no cluster e iniciar o redirecionamento de portas e a sincronização do contêiner com o diretório local.

Opcionalmente, será sugerido abrir um terminal dentro do contêiner. Não hesite em aceitar, pois, na realidade, o contêiner é iniciado com o comando sleep, e para um teste real, o aplicativo precisa ser iniciado manualmente.

Finalmente, o comando devspace deploy implanta o aplicativo e a infraestrutura relacionada no cluster, após o que tudo começa a funcionar em modo de produção.

Toda a configuração do projeto é armazenada no arquivo devspace.yaml. Além das configurações de ambiente para desenvolvimento, nele também pode ser encontrado a descrição da infraestrutura, semelhante aos manifestos padrão do Kubernetes, mas muito simplificados.

A arquitetura e os principais etapas de trabalho com o DevSpace

Além disso, é fácil adicionar um componente pré-definido ao projeto (por exemplo, um banco de dados MySQL) ou um Helm chart. Para mais detalhes, veja documentação — não é complicado.

Skaffold

Site; GitHub.
Estatísticas rápidas do GH: 7423 estrelas, 4173 commits, 136 contribuidores.
Linguagem: Go.
Licença: Apache License 2.0.

Esta ferramenta do Google pretende cobrir todas as necessidades do desenvolvedor cujo código será executado de alguma forma em um cluster Kubernetes. Começar a usá-la não é tão simples quanto o devspace: não há interatividade, detecção de linguagem ou criação automática Dockerfile aqui não será oferecido.

No entanto, se isso não o assusta — aqui está o que o Skaffold permite fazer:

Monitorar alterações no código-fonte.
Sincronizá-lo com o contêiner do pod, se não for necessária a compilação.
Compilar contêineres com o código, se a linguagem for interpretada, ou compilar artefatos e empacotá-los em contêineres.
Verificar automaticamente as imagens resultantes usando container-structure-test.
Marcar e fazer upload das imagens no Docker Registry.
Implantar o aplicativo no cluster, usando kubectl, Helm ou kustomize.
Fazer o redirecionamento de portas.
Depurar aplicativos escritos em Java, Node.js, Python.

O fluxo de trabalho em várias variantes é descrito de forma declarativa no arquivo skaffold.yaml. Para o projeto, também é possível definir vários perfis, onde etapas de compilação e implantação podem ser alteradas parcial ou totalmente. Por exemplo, para desenvolvimento, pode-se especificar uma imagem base conveniente para o desenvolvedor, enquanto para staging e produção — mínima (+ utilizar securityContext dos contêineres ou redefinir o cluster no qual o aplicativo será implantado).

A construção de contêineres Docker pode ser realizada localmente ou remotamente: em Google Cloud Build ou em um cluster usando Kaniko. O Bazel e o Jib Maven/Gradle também são suportados. Para marcar, o Skaffold suporta várias estratégias: por hash do commit git, data/hora, soma sha256 dos fontes, etc.

Vale ressaltar a possibilidade de testar contêineres. O já mencionado framework container-structure-test oferece os seguintes métodos de verificação:

Execução de comandos no contexto do contêiner com rastreamento dos status de saída e verificação da saída textual do comando.
Verificação da presença de arquivos no contêiner e correspondência de atributos com os especificados.
Controle do conteúdo dos arquivos por expressões regulares.
Verificação de metadados da imagem (ENV, ENTRYPOINT, VOLUMES etc.).
Verificação de compatibilidade de licenças.

A sincronização de arquivos com o contêiner é feita de forma não otimizada: o Skaffold simplesmente cria um arquivo comprimido com os fontes, copia e descompacta no contêiner (é necessário ter tar instalado). Portanto, se a sua principal tarefa for a sincronização de código, é melhor olhar para uma solução especializada (ksync).

Principais etapas de trabalho do Skaffold

No geral, a ferramenta não permite abstrair-se dos manifests do Kubernetes e não possui qualquer interatividade, portanto pode parecer complexa para aprender. Mas esse é também seu ponto forte — maior liberdade de ação.

Garden

Site; GitHub.
Estatísticas rápidas do GH: 1063 estrelas, 1927 commits, 17 contribuidores.
Linguagem: TypeScript (pretende-se dividir o projeto em vários componentes, alguns dos quais estarão em Go, além de criar um SDK para desenvolver plugins em TypeScript/JavaScript e Go).
Licença: Apache License 2.0.

Assim como o Skaffold, o Garden se concentra na automação dos processos de entrega de código de aplicações em um cluster K8s. Para isso, primeiro é necessário descrever a estrutura do projeto em um arquivo YAML, após o que você deve executar o comando garden dev. Ele fará toda a mágica:

Construirá contêineres com diferentes partes do projeto.
Executará testes de integração e unitários, se assim forem definidos.
Implantará todos os componentes do projeto no cluster.
No caso de haver alterações no código fonte — reiniciará todo o pipeline.

O foco principal ao usar esta ferramenta é o compartilhamento de um cluster remoto pela equipe de desenvolvedores. Nesse caso, se algumas etapas de construção e teste já foram concluídas, isso acelera significativamente todo o processo, pois o Garden poderá reutilizar os resultados em cache.

Um módulo do projeto pode ser um contêiner, um contêiner Maven, um gráfico Helm, um manifesto para kubectl apply ou até mesmo uma função OpenFaaS. Qualquer um dos módulos pode ser puxado de um repositório Git remoto. Um módulo pode definir (ou não) serviços, tarefas e testes. Os serviços e tarefas podem ter dependências, permitindo assim definir a ordem de implantação de um serviço específico, organizar a execução de tarefas e testes.

O Garden oferece ao usuário um belo painel (ainda em estado experimental), onde é exibido o gráfico do projeto: componentes, sequência de construção, execução de tarefas e testes, suas conexões e dependências. É possível visualizar no navegador os logs de todos os componentes do projeto, verificar o que cada componente retorna via HTTP (caso um recurso ingress tenha sido declarado para ele).

Painel do Garden

Esta ferramenta também possui um modo de hot-reload, que simplesmente sincroniza as alterações dos scripts com o contêiner no cluster, acelerando consideravelmente o processo de depuração do aplicativo. O Garden tem um documentação e um bom conjunto de exemplos, permitindo que você se familiarize rapidamente e comece a usar. A propósito, recentemente publicamos tradução de artigo dos seus autores.

Conclusão

Certamente, esta lista não esgota as ferramentas para desenvolvimento e depuração de aplicativos no Kubernetes. Existem muitas outras utilitários bastante úteis e práticos, que merecem, se não um artigo separado, pelo menos uma menção. Conte-nos quais ferramentas você usa, quais problemas encontrou e como os resolveu!