Endereços IP da lista branca em Kubernetes: O que aprendemos

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

Enquanto a equipe de engenharia da Linode construía as nossas características Kubernetes, nós atingimos muitos obstáculos, como esperado. No entanto, surgiu um desafio que não estávamos a esperando: como fazer uma lista branca de aplicações em execução em Kubernetes sobre a infraestrutura que já temos.

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

Se você tem uma aplicação com sua própria base de dados, essa base de dados provavelmente só precisa ser acessível por instâncias dessa aplicação. Se ambos estão a correr num cluster Kubernetes, isso é simples; NetworkPolicies permite-lhe bloquear isso. Por outro lado, se um serviço está funcionando fora do cluster, as coisas começam a ficar mais complicadas.

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

O Problema

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

Sem as ferramentas de Kubernetes-aware, eu seria forçado a fazer manualmente uma lista branca dos endereços IP individuais dos nós de cluster, um por um. Não só isso consome muito tempo, como 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 (na sua maioria) torna a lista branca de um cluster Kubernetes tão simples como a lista branca manual de um único IP.

Nós usamos o Salt para gerir a nossa infraestrutura, e já tínhamos uma fórmula de Salt para gerir as regras de firewall. Entre as infraestruturas inscritas no Salt, já tínhamos mecanismos para encontrar sistemas de uma determinada classe ao construir listas brancas, por isso estávamos à procura de algo semelhante para os nossos clusters Kubernetes.

O 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ó do Salt (dados "pilares"). Fazemos isto construindo uma regra de cada vez a partir de uma lista de regras armazenadas em pilares. É uma grande concatenação de linhas, o que, reconhecidamente, parece um pouco feio. Felizmente, o formato das regras do iptables é suficientemente estável para que acabe por funcionar bastante bem. Aqui está um bocadinho do que isso parece:

Graças ao API flexível da Kubernetes, esta 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 ir buscar os IPs de seus nós, coloca-os em cache localmente, e insere regras iptables para cada IP. O cachê é para garantir que falhas intermitentes na rede não causem problemas. Aqui está o que isso parece usar:

O que está por vir?

Em última análise, eu gostaria de abrir toda a fórmula para desenvolver ainda mais a capacidade da ferramenta com a ajuda da comunidade Linode.

O passo seguinte, no entanto, é fazer com que estas regras sejam actualizadas automaticamente à medida que novos nós entram e saem de um aglomerado. O objectivo é que a listagem persistente de um cluster seja tão simples como a listagem branca de um único IP, mas ainda não chegámos lá.

Como a fórmula está agora, ele irá pegar 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 este problema através da reaplicação periódica da configuração do firewall.

No entanto, gostaria de descobrir uma forma de o tornar mais reagentes. O meu mecanismo da minha imaginação ouviria esse evento (a criação de um novo objeto Nodo em Kubernetes) e acionaria uma atualização (provavelmente através do ônibus do evento Salt). Idealmente, isto não exigiria quaisquer passos manuais para 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 agora, estou muito feliz com o que criamos e acredito que será uma motivação para os utilizadores da Linode experimentarem 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 e em Linode?

A nossa equipa orgulha-se de apresentar a versão beta do Linode Kubernetes Engine (LKE) - um motor de orquestração de contentores totalmente gerido para a implantação e gestão de aplicações e cargas de trabalho em contentores.

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