Guides Essentiels

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.

Télécharger gratuitement ce dossier au format PDF

1Stockage-

Des pilotes CSI et des SDS

Conseils IT

Kubernetes : comment déployer des containers persistants ?

Les containers persistants stockent leurs données de manière durable, ce qui est largement préférable pour exécuter des applications traditionnelles. Cet article détaille les possibilités pour y parvenir. Lire la suite

Conseils IT

Kubernetes : comment fonctionnent les pilotes de stockage CSI ?

Les pilotes CSI permettent aux administrateurs de déployer du stockage persistant sur les clusters Kubernetes, en réintégrant dans ce dernier toutes les fonctions d’une baie de disques ou d’un service en ligne. Lire la suite

Actualités

KubeCON 2023 : Veritas crée la surprise avec un SDS pour Kubernetes

L’éditeur spécialiste de la sauvegarde dévoile InfoScale 8, un système de stockage persistant pour Kubernetes qui se veut plus rapide que la concurrence. Le produit est resté confidentiel durant des années. Lire la suite

2Sauvegarde-

Une profusion de solutions

Actualités

Kubernetes : Velero veut incarner la sauvegarde « standard »

Le projet Open source est soutenu par plusieurs acteurs du datacenter qui cherchent à enrichir leurs solutions d’une sauvegarde pour Kubernetes. Mais il s’agit pour l’heure d’un produit plus technique que clés en main. Lire la suite

Actualités

Kubernetes : TrilioVault 3.0 synchronise les copies de clusters entre clouds

L’éditeur Trilio entend apporter aux entreprises une solution pour multiplier les copies de secours, sans la contrainte d’une adaptation technique à chaque implémentation de Kubernetes. Lire la suite

Actualités

KubeCON : Veeam positionne Kasten en leader du backup Kubernetes

Le champion de la sauvegarde des serveurs veut aussi être numéro 1 sur les containers. Le logiciel K10 atteint l’objectif de simplifier, mais se penche surtout les besoins de l’IT. Lire la suite

Conseils IT

Les 10 acteurs clés de la sauvegarde sous Kubernetes

Cet article passe en revue les principaux éditeurs de la sauvegarde sous Kubernetes : pourquoi ils sont nécessaires, ce qu’ils offrent et pourquoi il faut répartir les rôles entre les équipes de développement et celles de l’IT. Lire la suite

3Réseau-

Des pilotes CNI et un maillage

Conseils IT

Réseau : comment fonctionnent les pilotes CNI de Kubernetes

Cet article fait un point sur le fonctionnement des pilotes réseau CNI de Kubernetes et compare les plus populaires d’entre eux, dont Calico, Flannel, Weave Net, Cilium et Multus. Lire la suite

Actualités

Infrastructures Kubernetes : Solo.io enrichit le routage des containers

L’éditeur spécialiste du répartiteur de charge Open source Istio décline sa version commerciale en une plateforme complète pour supporter les déploiements les plus complexes. Lire la suite

Actualités

Kubernetes : Traefik Labs donne une dimension multicloud à son routeur

Commercialisé dans les prochains jours, Traefik Hub centralise la télémétrie, la sécurité et l’accessibilité des APIs pour une flotte de clusters Kubernetes. Lire la suite

4Sécurité-

Éviter les risques posés par les containers

Actualités

La sécurité de Kubernetes soumise aux risques de la supply chain logicielle

Si Kubernetes demeure relativement préservé des failles de sécurité, l’écosystème et la supply chain qui sous-tendent le déploiement de l’orchestrateur sont soumis à des risques majeurs de compromission. Lire la suite

Actualités

Cisco Live : l’administration réseau & sécurité arrive sur Kubernetes

Cisco a dévoilé Calisti, une console graphique qui permet de piloter un service Mesh comme un réseau classique, et Panoptica, un service SaaS qui teste les failles des containers. Lire la suite

Actualités

Sysdig, la startup qui renifle les problèmes de Kubernetes

Derrière la solution de cet éditeur, une plateforme d’investigation des chutes de performances et des failles de sécurité, on retrouve l’équipe à l’origine de WireShark, le « sniffer » de réseau par excellence. Lire la suite

Close