Guide de l’administration stockage et réseau sous Kubernetes

Introduction

Dès lors qu’une entreprise veut exécuter en containers des applications Windows ou Linux classiques, qui ne sont pas spécifiquement conçues pour être utilisées par un nombre variable d’internautes depuis n’importe quel endroit sur Internet, il devient nécessaire de transposer dans Kubernetes les fonctions d’infrastructure – stockage, sauvegarde, réseau, sécurité par firewall – d’un cluster classique, qu’il soit virtuel ou non.

Ce guide, qui va de pair avec celui consacré au passage de la virtualisation à la containerisation, donne les clés pour réussir cette transposition. Il succède également au guide qui explique pourquoi Kubernetes est la nouvelle infrastructure d’une IT en mode hybride.

Stockage et réseau : des différences entre Kubernetes et la virtualisation

Kubernetes, qui orchestre des instances virtuelles au format container, est de plus en plus utilisé par les DSI comme une alternative moderne aux hyperviseurs qui déploient des machines virtuelles. Car les containers consomment moins de ressources et qu’ils peuvent facilement être pilotés par des développeurs pour qu’ils activent eux-mêmes une infrastructure de test.

Pour autant, Kubernetes n’a pas été conçu au départ comme un concurrent de VMware. Il a été imaginé pour déployer des containers avec un très haut niveau d’abstraction du stockage et du réseau, afin qu’une entreprise puisse déployer des applications web en containers de manière transversale entre les clouds publics. Ceci afin que les applications soient élastiques : selon la quantité de trafic généré par les internautes, il est simple de démultiplier les copies des containers n’importe où, puisqu’il n’y a aucun lien direct avec les baies de disques ni avec les routeurs Ethernet des infrastructures sous-jacentes.

Kubernetes est un système que l’on peut déployer sur site via des distributions classiques (OpenShift...) ou activer en cloud sous la forme d’un service (EKS sur AWS, AKS, sur Azure, GTK sur GCP…). De base, les fonctions applicatives en containers stockent des données en les postant sur une URL, via un protocole S3, et s’échangent des informations en s’envoyant des requêtes HTTP à l’URL de leurs services. La réception des requêtes entre containers est concrétisée par la présence d’une API dans le code applicatif du container ; cette API écoute les requêtes qui arrivent sur un port réseau dynamiquement routé.

Mais les entreprises n’ont pas que des applications web à exécuter. Les applications classiques – métier, privées, bases de données, intensives, etc. – ont besoin d’avoir accès à un volume disque classique. Pour des questions de conception qu’il serait trop coûteux de refaire, mais aussi pour des raisons de performances. Quant au routage de leurs communications, il s’agit (au contraire des applications inter-cloud) de circonscrire la circulation des informations à un réseau privé, avec des bandes passantes données par switch et des droits d’accès ou de répartition de charge selon les adresses TCP/IP.

Pour transposer dans un cluster Kubernetes les volumes disques et les réseaux TCP/IP des infrastructures d’un cluster classique, qu’il soit virtualisé ou non, on utilise des pilotes, respectivement CSI et CNI, qui prennent la forme de plug-ins. Une fois ces pilotes déployés, l’équipe IT peut gérer le stockage et le réseau de ses containers comme elle le fait pour les machines virtuelles. Notamment, elle peut administrer la sauvegarde par snapshots et la sécurité des containers, via des firewalls ou l’isolation de réseaux privés.

Comment fonctionnent stockage persistant et sauvegardes

Dans les grandes lignes, il s’agit, pour les pilotes CSI, de mettre en place dans Kubernetes des volumes persistants (PV) qui sont indépendants de tout container, ou de tout pod. Un pod étant un jeu de containers déployés ensemble. Par exemple, un pod aura deux containers, l’un avec les fonctions applicatives et l’autre pour réceptionner les requêtes envoyées sur l’API de ces fonctions applicatives. 

Les PV sont définis en amont par l’administrateur, qui leur fait correspondre des baies de disque physiques, ou virtuelles (dans le cas de l’utilisation d’un SDS). Dans le cas de baies virtualisées, il peut s’agir d’un Storage Class, c’est-à-dire d’un volume qui correspond à une catégorie de stockage particulière (accès fichier ou bloc, bande passante élevée ou haute capacité, etc.). Ici, la capacité du Storage Class est attribuée dynamiquement.

Ensuite, un PVC (Persistent Volume Claim) est associé à chaque pod. Il définit le stockage dont le pod a besoin. Au démarrage du pod, le pilote lui attribue un PV qui correspond à son PVC, par une opération de binding.

Ensuite, la sauvegarde des clusters Kubernetes, à des fins de copie de secours, d’archivage, mais aussi de réplication, est plus simple. Pour autant, elle ne peut pas se contenter d’enregistrer une copie des volumes disques. Il faut aussi sauvegarder la logique du cluster pour le redéployer de manière cohérente : les fichiers de configuration YAML qui définissent les pods et l’ordre chronologique dans lequel ils sont déployés, les « secrets » qui permettent aux pods de s’authentifier entre eux, l’état du cluster à un moment donné, etc.

Comment fonctionnent le réseau et la sécurité

Un cluster Kubernetes attribue à chacun de ses pods, ou groupe logique de pods, un nom de service, qu’il référence dans un DNS. Pour se faire, il attribue à chaque pod une adresse IP interne (dite « ClusterIP »), qui permet de router les requêtes entre les pods, ainsi qu’un port réseau (« NodePort »), qui permet d’atteindre les services internes depuis le monde extérieur, lequel ne connaît que l’adresse IP publique du cluster Kubernetes. Kubernetes utilise également un Ingress, un module qui transfère les requêtes HTTP venues de l’extérieur vers les bons services, et un répartiteur de charge pour router ces requêtes vers les copies de pods internes qui sont disponibles.

Ce fonctionnement-là est dynamique : personne ne connaît exactement les adresses IP utilisées et Kubernetes se débrouille tout seul en utilisant les serveurs référencés dans son cluster. À ce stade, il n’y a aucune notion de bande passante, de groupes de serveurs avec une caractéristique commune (vitesse, étanchéité face à certains accès, etc.), de répartition physique (clone sur un second site à des fins de redondance), etc.

Les pilotes CNI, vont ajouter à chaque pod une carte réseau virtuelle, qui peut être configurée avec des caractéristiques plus précises, notamment des priorités de routage et des adresses IP circonscrites à une certaine numérotation. Il devient dès lors possible d’ajouter au firewall applicatif de Kubernetes des firewalls réseau qui, par exemple, détectent une requête illégitime entre deux pods.

En effet, la sécurité de base de Kubernetes ne s’applique qu’entre les requêtes venues de l’extérieur et les pods. Néanmoins, il est possible d’imaginer des scénarios d’attaque dans lesquels des cybermalfaiteurs ont compromis les images des containers en amont, ou dans lesquels les développeurs ont laissé traîner sur leurs pods des API publiques dangereuses. Par ailleurs, assurer une sécurité devant chaque pod est plus efficace pour contrer les attaques par déni de service qui saturent le cluster de requêtes une fois que celles-ci sont entrées.

1Stockage-

Des pilotes CSI et des SDS

2Sauvegarde-

Une profusion de solutions

3Réseau-

Des pilotes CNI et un maillage

4Sécurité-

Éviter les risques posés par les containers