Containers Anatomy 101 : Qu'est-ce qu'un cluster ?

Du point de vue de la mise en réseau, les conteneurs étendent la « périphérie » du réseau, c'est-à-dire la limite entre les décisions de transfert du réseau et l'atteinte d'un paquet à sa destination finale, jusqu'à un hôte. La périphérie n'est plus l'interface réseau d'un hôte, mais plutôt plusieurs couches profondément ancrées dans les constructions logiques d'un hôte. Et la topologie du réseau est abstraite et explore en profondeur ces constructions logiques au sein d'un hôte, sous la forme d'un tunnel réseau superposé, d'interfaces virtuelles, de limites NAT, d'équilibreurs de charge et de plug-ins réseau. Les architectes de réseau et de sécurité ne peuvent plus ignorer les composants internes du système d'exploitation lors de la conception de leurs architectures. Les conteneurs obligent ces architectures à comprendre où va un paquet une fois qu'il est passé par la carte réseau d'un hôte.

Systèmes d'orchestration

Cela dit, un système d'orchestration est nécessaire pour mettre de l'ordre dans les environnements de conteneurs. Un système d'orchestration gère les détails relatifs à l'organisation, à la mise à l'échelle et à l'automatisation des conteneurs, et crée des constructions logiques autour de divers composants pertinents pour le comportement des conteneurs. Ils sont également chargés d'organiser les limites logiques associées aux environnements d'exécution des conteneurs et de créer des constructions logiques auxquelles une adresse IP peut être attribuée. Cela dit, ces systèmes sont externes et ne peuvent pas réellement déployer et gérer le cycle de vie d'instances d'exécution de conteneurs spécifiques, qui sont toujours gérées par Docker, par exemple.

Il existe de nombreux systèmes d'orchestration de conteneurs, mais les deux plus couramment utilisés aujourd'hui sont Kubernetes et OpenShift. Ils ont tous deux les mêmes objectifs fondamentaux, à la différence près que l'un est un projet et l'autre un produit : Kubernetes est un projet né en grande partie de Google, et OpenShift est un produit appartenant à Red Hat. D'une manière générale, Kubernetes est le plus souvent utilisé dans les environnements de cloud public et OpenShift est le plus souvent utilisé dans les centres de données sur site, mais il existe un chevauchement important entre les deux. En résumé, Kubernetes est à la base des deux approches, avec quelques légères différences terminologiques entre chacune d'elles.

Bref historique des conteneurs

Croyez-le ou non, les conteneurs sont antérieurs à Kubernetes. Docker, par exemple, a lancé sa plateforme de conteneurs pour la première fois en 2013, tandis que Kubernetes n'a lancé son projet axé sur le cloud public qu'en 2014. OpenShift a été lancé avant les deux, en mettant l'accent sur les hôtes déployés dans des centres de données sur site.

Le simple déploiement d'environnements d'exécution de conteneurs sur un hôte local répond généralement aux besoins des développeurs, car les environnements d'exécution peuvent communiquer entre eux via « localhost » et des ports uniques. Aucune adresse IP spécifique n'est attribuée aux environnements d'exécution des conteneurs. Si vous vous concentrez sur l'écriture de code rapide et efficace et sur le déploiement de votre application sur un ensemble de runtimes de conteneurs associés, cette approche fonctionne parfaitement. Toutefois, si vous souhaitez que cette application accède à des ressources externes extérieures à l'hôte local, ou si vous souhaitez que des clients externes accèdent à cette application, vous ne pouvez pas ignorer les détails du réseau. C'est l'une des raisons pour lesquelles un système d'orchestration est nécessaire.

Kubernetes a été créé autour d'un ensemble de modules et d'un flux de travail piloté par API pour organiser le comportement des environnements d'exécution des conteneurs. Dans cette approche, Kubernetes crée une série de constructions logiques au sein et entre les hôtes associés à un environnement conteneurisé spécifique, et crée un tout nouvel ensemble de vocabulaire pour faire référence à ces constructions. Alors que Kubernetes applique ces éléments de base et ces flux de travail pilotés par API autour d'un ensemble de mesures de calcul associées à l'allocation du processeur, aux besoins en mémoire et à d'autres mesures telles que le stockage, l'authentification et le comptage, la plupart des professionnels de la sécurité et des réseaux se concentrent sur un point :

Quelles sont les limites franchies par un paquet IP lorsqu'il est en route vers une construction logique à laquelle une adresse IP est attribuée ?

Du point de vue de la mise en réseau, Kubernetes et OpenShift créent des constructions logiques et pertinentes dans le cadre d'une approche hiérarchique, avec une légère différence de vocabulaire entre chaque système. Ceci est illustré ci-dessous.

L'ABC d'un cluster de conteneurs

Ce diagramme montre la structure logique de base d'un environnement Kubernetes. Il n'explique pas ce que fait chaque construction, mais seulement comment elles sont logiquement liées les unes aux autres.

En partant de la construction la plus large jusqu'à la plus petite, voici quelques explications rapides :

• Cluster: Un cluster est l'ensemble d'hôtes associés à un déploiement conteneurisé spécifique.
• Nœuds: à l'intérieur d'un cluster se trouvent des nœuds. Un nœud est l'hôte sur lequel résident les conteneurs. Un hôte peut être un ordinateur physique ou une machine virtuelle, et il peut résider dans un centre de données sur site ou dans un cloud public. Généralement, il existe deux catégories de nœuds dans un cluster : les « nœuds maîtres » et les « nœuds de travail ». Pour simplifier les choses à l'extrême, un nœud maître est le plan de contrôle qui fournit la base de données centrale du cluster et le serveur d'API. Les nœuds de travail sont les machines qui exécutent les véritables modules d'application.
• Gousses: À l'intérieur de chaque nœud, Kubernetes et OpenShift créent des pods. Chaque pod comprend un ou plusieurs environnements d'exécution de conteneurs et est géré par le système d'orchestration. Des adresses IP sont attribuées aux pods par Kubernetes et OpenShift.
• Récipient: À l'intérieur des pods se trouvent les temps d'exécution des conteneurs. Les conteneurs d'un espace donné partagent tous la même adresse IP que ce module et communiquent entre eux via Localhost, en utilisant des ports uniques.
• Espace de noms: Une application donnée est déployée « horizontalement » sur plusieurs nœuds d'un cluster et définit une limite logique pour allouer les ressources et les autorisations. Les pods (et donc les conteneurs) et les services, mais aussi les rôles, les secrets et de nombreuses autres constructions logiques appartiennent à un espace de noms. OpenShift appelle cela un projet, mais c'est le même concept. D'une manière générale, un espace de noms correspond à une application spécifique, qui est déployée dans tous les conteneurs associés qu'il contient. Un espace de noms n'a rien à voir avec une structure de réseau et de sécurité (différent d'un espace de noms IP Linux)
• Service: Comme les pods peuvent être éphémères (ils peuvent disparaître soudainement puis être redéployés de manière dynamique), un service est un « front-end », qui est déployé devant un ensemble de modules associés et fonctionne comme un équilibreur de charge avec un VIP qui ne disparaît pas si un pod disparaît. Un service est une construction logique non éphémère, dotée de sa propre adresse IP. À quelques exceptions près dans Kubernetes et OpenShift, les connexions externes pointent vers l'adresse IP d'un service et sont ensuite transmises vers des pods « backend ».
• Serveur API Kubernetes: C'est là que le flux de travail de l'API est centralisé, Kubernetes gérant la création et le cycle de vie de toutes ces constructions logiques.

Les défis de sécurité liés aux conteneurs

Afin de créer des segments de sécurité le long des limites de la charge de travail, il est nécessaire de comprendre ces concepts logiques de base créés par Kubernetes. Le trafic réseau externe entrant et sortant de l'application hébergée ne pointe généralement pas vers l'adresse IP de l'hôte sous-jacent, le nœud. Au lieu de cela, le trafic réseau sera dirigé vers un service ou un pod au sein de cet hôte. Par conséquent, les services et modules associés à une charge de travail doivent être suffisamment compris afin de créer un architecture de sécurité de segmentation efficace.

Vous souhaitez en savoir plus ? Consultez notre article sur les défis des approches basées sur le réseau pour la segmentation des conteneurs et sur la manière de les surmonter à l'aide de la segmentation basée sur l'hôte.