Endereços IP de lista branca na Kubernetes: O que aprendemos

O engenheiro da Linode Systems Jon "jfred" Frederickson compartilha sua experiência na criação do recurso de lista branca de IP para executar a Kubernetes na Linode.

Como a equipe de engenharia da Linode construiu nossas características Kubernetes, atingimos muitos obstáculos, como esperado. Entretanto, surgiu um desafio que não estávamos antecipando: como fazer uma lista branca de aplicações em Kubernetes sobre a infra-estrutura que já temos.

Aqui na Linode, nós executamos várias aplicações internas. Usando regras de firewall, estas aplicações são acessíveis apenas para aquelas redes e sistemas que precisam delas.

Se você tiver um aplicativo com seu próprio banco de dados, provavelmente esse banco de dados só precisará ser acessível por instâncias desse aplicativo. Se ambos estiverem funcionando em um cluster Kubernetes, isso é simples; NetworkPolicies permite que você bloqueie isso. Por outro lado, se um serviço está rodando fora do cluster, as coisas começam a ficar mais complicadas.

Já tínhamos alguma automação em torno da lista branca IP, mas os clusters Kubernetes têm o potencial de ser mais dinâmicos do que qualquer outra coisa em nossa infra-estrutura até agora. É por isso que precisávamos garantir que pudéssemos manter nossas whitelists atualizadas à medida que os nós eram adicionados e removidos dos clusters. Achamos que esta deveria ser uma questão bastante comum para qualquer pessoa que introduzisse Kubernetes na infra-estrutura existente, mas não descobrimos nenhuma outra solução pública para o problema.

O problema

Meu desafio era, se eu quisesse fazer uma lista branca de todos os nós em um cluster específico em um servidor externo ao cluster, qual seria minha configuração ideal?

Sem a ferramenta Kubernetes-aware, eu seria forçado a ter manualmente os endereços IP individuais dos nós de cluster da lista branca, um por um. Não só isso consome muito tempo, mas introduz mais potencial de erro humano, o que é um grande obstáculo no processo de desenvolvimento.

A solução

Durante as próximas semanas, construí uma solução que (em sua maioria) torna a lista branca de um cluster Kubernetes tão simples quanto a lista branca manual de um único IP.

Usamos Salt para gerenciar nossa infra-estrutura, e já tínhamos uma fórmula Salt para gerenciar as regras de firewall. Entre as infra-estruturas inscritas em Salt, já tínhamos mecanismos para encontrar sistemas de uma determinada classe ao construir listas brancas, então estávamos procurando algo semelhante para nossos clusters Kubernetes.

Salt é extremamente flexível e torna fácil a escrita de módulos personalizados. Por exemplo, nossa fórmula iptables usa uma para gerar regras iptables a partir da configuração por nó Salt(dados "pilares"). Fazemos isso construindo uma regra de cada vez a partir de uma lista de regras armazenadas em pilares. É um monte de concatenação de strings, o que, reconhecidamente, parece um pouco feio. Felizmente, o formato de regras iptables é estável o suficiente para que acabe funcionando muito bem. Aqui está um trecho de como isso se parece:

Graças à API flexível do Kubernetes, essa integração não foi tão difícil conceitualmente. Essencialmente, adicionamos um novo tipo de regra para clusters K8s: quando a fórmula encontra uma regra desse tipo, ela alcança esse cluster para buscar os IPs de seus nós, armazena-os em cache localmente e insere regras iptables para cada IP. O cache é para garantir que falhas intermitentes de rede não causem problemas. Veja como é usar:

O que vem a seguir?

Por fim, eu gostaria de abrir toda a fórmula para desenvolver ainda mais a capacidade da ferramenta com a ajuda da comunidade Linode.

O próximo passo, porém, é fazer com que estas regras sejam atualizadas automaticamente à medida que novos nós entram e saem de um cluster. O objetivo é que a listagem persistente de um cluster seja tão simples quanto a listagem branca de um único IP, mas ainda não estamos lá.

Como a fórmula está agora, ela captará novos nós somente quando a configuração do firewall for aplicada, mas não automaticamente. Isto não é um grande problema, uma vez que podemos contornar isto reaplicando periodicamente a configuração do firewall.

Entretanto, eu gostaria de descobrir uma maneira de torná-lo mais reativo. Meu mecanismo previsto seria ouvir esse evento (a criação de um novo objeto Nodo em Kubernetes) e acionar uma atualização (provavelmente através do ônibus de eventos Salt ). Idealmente, isto não exigiria nenhum passo manual além da configuração de uma regra de firewall Kubernetes. Talvez quando abrirmos o código fonte a fórmula você possa nos ajudar a descobrir isso!

Por enquanto, estou realmente feliz com o que criamos e acredito que será um trunfo para os usuários da Linode que experimentam com a Kubernetes.

Obrigado por aprender sobre o processo de engenharia de sistemas da Linode. Por favor, me informe na seção de comentários se você tiver alguma dúvida sobre o que fizemos.

Interessado em Kubernetes em Linode?

Nossa equipe tem o orgulho de apresentar a versão beta do Linode Kubernetes Engine (LKE) - um motor de orquestração de contêineres totalmente gerenciado para implantação e gerenciamento de aplicações e cargas de trabalho em contêineres.

No entanto, precisamos de seu feedback. Por favor, inscreva-se no LKE beta aqui para experimentar e ganhar uma troca Linode grátis.