Liste blanche des adresses IP sur Kubernetes : Ce que nous avons appris

Jon "jfred" Frederickson, ingénieur système chez Linode, partage son expérience de la construction de la fonctionnalité de liste blanche d'IP pour l'exécution de Kubernetes sur Linode.

Au fur et à mesure que l'équipe d'ingénieurs de Linode développait nos fonctionnalités Kubernetes, nous avons rencontré de nombreux obstacles, comme prévu. Cependant, un défi est apparu que nous n'avions pas anticipé : comment mettre sur liste blanche les applications fonctionnant dans Kubernetes sur l'infrastructure dont nous disposons déjà.

Chez Linode, nous utilisons plusieurs applications internes. Grâce à des règles de pare-feu, ces applications ne sont accessibles qu'aux réseaux et systèmes qui en ont besoin.

Si vous avez une application avec sa propre base de données, cette base de données n'a probablement besoin d'être accessible que par les instances de cette application. Si les deux s'exécutent dans un cluster Kubernetes, c'est assez simple ; les NetworkPolicies vous permettent de verrouiller cela. En revanche, si un service s'exécute en dehors du cluster, les choses commencent à se compliquer.

Nous disposions déjà d'une certaine automatisation autour de la liste blanche d'IP, mais les clusters Kubernetes ont le potentiel d'être plus dynamiques que tout autre élément de notre infrastructure jusqu'à présent. C'est pourquoi nous devions nous assurer que nous pouvions maintenir nos listes blanches à jour au fur et à mesure que des nœuds étaient ajoutés ou retirés des clusters. Nous avons pensé qu'il s'agissait d'un problème assez courant pour toute personne introduisant Kubernetes dans une infrastructure existante, mais nous n'avons pas trouvé d'autres solutions publiques à ce problème.

Le problème

Mon défi était le suivant : si je voulais mettre sur liste blanche tous les nœuds d'une grappe spécifique sur un serveur externe à la grappe, à quoi ressemblerait ma configuration idéale ?

Sans outil adapté à Kubernetes, je serais obligé de mettre manuellement sur liste blanche les adresses IP individuelles des nœuds de cluster, une par une. Non seulement cela prend du temps, mais cela augmente le risque d'erreur humaine, ce qui constitue un obstacle majeur dans le processus de développement.

La solution

Au cours des deux semaines suivantes, j'ai construit une solution qui rend (en grande partie) la mise en liste blanche d'un cluster Kubernetes aussi simple que la mise en liste blanche manuelle d'une seule IP.

Nous utilisons Salt pour gérer notre infrastructure, et nous avions déjà une formule Salt pour gérer les règles de pare-feu. Parmi les infrastructures inscrites sur Salt, nous avions déjà des mécanismes pour trouver des systèmes d'une classe donnée lors de la construction de listes blanches, nous cherchions donc quelque chose de similaire pour nos clusters Kubernetes.

Salt est extrêmement flexible et facilite l'écriture de modules personnalisés. Par exemple, notre formule iptables en utilise une pour générer des règles iptables à partir de la configuration par noeud de Salt(données "pillar"). Pour ce faire, nous construisons une règle à la fois à partir d'une liste de règles stockées dans pillar. Il s'agit d'une concaténation de chaînes de caractères qui, il faut bien l'admettre, est un peu moche. Heureusement, le format des règles d'iptables est suffisamment stable pour que cela fonctionne plutôt bien. Voici un extrait de ce à quoi cela ressemble :

Grâce à la souplesse de l'API de Kubernetes, cette intégration n'a pas été très difficile sur le plan conceptuel. Essentiellement, nous avons ajouté un nouveau type de règle pour les clusters K8s : lorsque la formule rencontre une règle de ce type, elle s'adresse à ce cluster pour récupérer les IP de ses nœuds, les met en cache localement et insère des règles iptables pour chaque IP. La mise en cache permet de s'assurer que les défaillances intermittentes du réseau ne causent pas de problèmes. Voici ce que cela donne à l'usage :

Quelle est la prochaine étape ?

À terme, j'aimerais mettre en open source l'ensemble de la formule pour développer encore plus les capacités de l'outil avec l'aide de la communauté Linode.

L'étape suivante consiste à mettre à jour ces règles automatiquement lorsque de nouveaux nœuds rejoignent ou quittent une grappe. L'objectif est de faire en sorte que l'établissement d'une liste blanche permanente pour une grappe soit aussi simple que l'établissement d'une liste blanche pour une seule IP, mais nous n'en sommes pas encore là.

Dans l'état actuel de la formule, les nouveaux nœuds ne sont détectés que lorsque la configuration du pare-feu est appliquée, mais pas automatiquement. Ce n'est pas un problème majeur, puisque nous pouvons contourner ce problème en réappliquant périodiquement la configuration du pare-feu.

Cependant, j'aimerais trouver un moyen de le rendre plus réactif. Le mécanisme que j'envisage serait à l'écoute de cet événement (la création d'un nouvel objet Node dans Kubernetes) et déclencherait une mise à jour (probablement par le biais du bus d'événements Salt ). Dans l'idéal, cela ne nécessiterait aucune étape manuelle, hormis la configuration d'une règle de pare-feu Kubernetes. Peut-être qu'une fois que nous aurons mis la formule en open source, vous pourrez nous aider à résoudre ce problème !

Pour l'instant, je suis vraiment satisfait de ce que nous avons créé et je pense que ce sera un atout pour les utilisateurs de Linode qui expérimentent Kubernetes.

Merci d'avoir découvert le processus d'ingénierie des systèmes de Linode. Si vous avez des questions sur ce que nous avons fait, n'hésitez pas à m'en faire part dans la section des commentaires.

Intéressé par Kubernetes sur Linode ?

Notre équipe est fière de présenter la version bêta de Linode Kubernetes Engine (LKE) - un moteur d'orchestration de conteneurs entièrement géré pour le déploiement et la gestion d'applications et de charges de travail conteneurisées.

Mais nous avons besoin de vos commentaires. Inscrivez-vous à la version bêta de LKE ici pour l'essayer et gagner un swag Linode gratuit.