Le livre «Maîtriser Kubernetes. Orchestration des architectures de conteneurs "

Salut, habrozhiteli! Nous avons récemment publié un livre sur Kubernetes version 1.10. La publication a passé en revue le passage "Networking Solutions for Kubernetes"

Le réseautage est un sujet vaste. Il existe de nombreuses façons de configurer un réseau avec des appareils, des foyers et des conteneurs. Kubernetes ne vous limite pas à cela. Tout ce que cette plateforme prescrit est un modèle de réseau de haut niveau avec un espace d'adressage plat pour les foyers. Dans cet espace, vous pouvez implémenter de nombreuses bonnes solutions avec différentes capacités et pour différents environnements. Dans cette section, nous allons examiner certains d'entre eux et essayer de comprendre comment ils s'intègrent dans le modèle de réseau Kubernetes.

Création de ponts dans des clusters matériels

L'environnement le plus simple est un cluster de métal nu, qui est un réseau physique régulier de niveau L2. Pour connecter des conteneurs à un tel réseau, vous pouvez utiliser le pont Linux standard. Il s'agit d'une procédure plutôt minutieuse qui nécessite de l'expérience avec les commandes réseau Linux de bas niveau, telles que brctl, ip addr, ip route, ip link, nsenter, etc. Vous pouvez commencer à implémenter une telle solution en lisant le guide suivant: blog.oddbit.com/
11/08/2014 / quatre-façons-de-connecter-un-docker / (recherchez la section Avec les périphériques Linux Bridge).

Contiv

Contiv est un module complémentaire réseau à usage général. Il est conçu pour connecter des conteneurs via CNI et peut être utilisé avec Docker (directement), Mesos, Docker Swarm et, naturellement, Kubernetes. Contiv traite des stratégies réseau et duplique partiellement un objet similaire dans Kubernetes. Voici quelques-unes des fonctionnalités de ce module complémentaire réseau:

• prise en charge de CNM dans libnetwork et de la spécification CNI;
• Un moteur de stratégie riche en fonctionnalités qui offre une sécurité et un déploiement d'application prévisible.
• les meilleures performances de conteneurs de leur catégorie;
• sous-réseaux à occupation multiple, isolement et chevauchement;
• Intégration IPAM et découverte de services;
• large choix de topologies physiques:
  
  a) protocoles de couche 2 (VLAN);
  b) protocoles de couche 3 (BGP);
  c) réseaux superposés;
  d) Cisco SDN (ACI);
• Prise en charge IPv6;
• politique évolutive et allocation des itinéraires;
• Intégration avec des modèles d'application, notamment:
  
  a) Docker-compose;
  b) gestionnaire de déploiement Kubernetes;
  c) répartition de charge sur les services, intégrée à l'équilibreur de microservices de type "est-ouest" (est-ouest);
  d) l'isolement du trafic pendant le stockage, le contrôle d'accès (par exemple, etcd / consul), la transmission et la gestion du réseau.

Contiv a de nombreuses fonctionnalités. Cet outil met en œuvre un large éventail de tâches et prend en charge diverses plates-formes, donc je ne sais pas si ce sera le meilleur choix pour Kubernetes.

Ouvrez vswitch

Open vSwitch est une solution de commutateur (logiciel) de commutateur virtuel mature prise en charge par de nombreux acteurs majeurs du marché. Le système Open Virtualization Network (OVN) vous permet de créer diverses topologies de réseau virtuel. Elle dispose d'un module complémentaire spécial pour Kubernetes, mais il est très difficile à configurer (voir le manuel github.com/openvswitch/ovn-kubernetes ). Le module complémentaire Linen CNI a moins de fonctionnalités, mais sa configuration est beaucoup plus simple: github.com/John-Lin/linen-cni . La structure Linen CNI est illustrée à la Fig. 10.6.


Open vSwitch peut intégrer des serveurs physiques, des machines virtuelles et des pods / conteneurs dans un seul réseau logique. Ce système prend en charge les modes superposition et physique.

Voici quelques-unes de ses principales caractéristiques:

• VLAN 802.1Q standard avec jonction et ports publics
• Liaison NIC avec ou sans LACP pour un commutateur de niveau supérieur
• NetFlow, sFlow® et la mise en miroir pour une meilleure visibilité;
• Configuration QoS (Qualité de service) plus politiques;
• tunneling via Geneve, GRE, VXLAN, STT et LISP;
• contrôle des ruptures dans 802.1ag;
• OpenFlow 1.0 et de nombreux modules complémentaires;
• base de données transactionnelle pour stocker la configuration avec des liaisons pour C et Python;
• redirection haute performance à l'aide de modules du noyau Linux.

Nuage Networks VCS

Virtualized Cloud Services (VCS) est un produit de Nuage, qui est une plate-forme bien évolutive basée sur des politiques pour la création de réseaux définis par logiciel (Software-Defined Networking, SDN). Il s'agit d'une solution de niveau entreprise basée sur le système Open Open vSwitch (pour la redirection des données) et un contrôleur SDN multifonctionnel basé sur des normes ouvertes.

La plateforme Nuage combine des pods Kubernetes et des environnements tiers (virtuels et matériels) en réseaux de superposition transparents et vous permet de décrire des politiques détaillées pour différentes applications. Son moteur d'analyse en temps réel vous permet de surveiller la visibilité et la sécurité des applications Kubernetes.

De plus, tous les composants VCS peuvent être installés en tant que conteneurs. Il n'y a pas de configuration matérielle spécifique.

Canal

Canal est un mélange de deux projets open source: Calico et Flannel. D'où le nom. Le projet Flannel, développé par l'équipe CoreOS, traite des capacités de mise en réseau des conteneurs, tandis que Calico est responsable des politiques de réseau. Initialement, ils ont été développés séparément les uns des autres, mais les utilisateurs voulaient les utiliser ensemble. Le projet open source Canal est maintenant un modèle de déploiement pour installer Calico et Flannel en tant que modules complémentaires CNI distincts. Créée par les fondateurs de Calico, Tigera a soutenu les deux projets et a même prévu une intégration plus étroite, mais depuis la sortie de sa propre solution de mise en réseau sécurisée entre les applications dans Kubernetes, la priorité s'est déplacée vers la simplification de la configuration et de l'intégration de Flannel et Calico au lieu de développer une solution unifiée. Dans la fig. 10.7 montre l'état actuel du système Canal et sa relation avec les plateformes d'orchestration telles que Kubernetes et Mesos.


Notez que lors de l'intégration avec Kubernetes, Canal n'accède pas directement à etcd, mais au serveur API Kubernetes.

Flanelle

Flannel est un réseau virtuel qui fournit à chaque nœud un réseau virtuel pour travailler avec les temps d'exécution des conteneurs. Sur chaque nœud, l'agent flaneld est lancé, augmentant le sous-réseau en fonction de l'espace d'adressage réservé stocké dans le cluster etcd. L'échange de paquets entre les conteneurs et, dans l'ensemble, le nœud est effectué par l'un des nombreux serveurs. Le plus souvent, le serveur utilise UDP sur le périphérique TUN qui, par défaut, tunnelise le trafic via le port 8285 (n'oubliez pas de l'ouvrir dans votre pare-feu).

Dans la fig. 10.8 décrit en détail les différents composants du réseau Flannel, les périphériques de réseau virtuel qu'il crée et comment ils communiquent avec l'hôte et le foyer via le pont docker0. Ici, vous pouvez également voir le processus d'encapsulation des paquets UDP et leur mouvement entre les nœuds.


D'autres technologies réseau sont prises en charge:

• vxlan - encapsule les paquets en utilisant VXLAN à l'intérieur du noyau;
• host-gw - crée des routes IP vers des sous-réseaux via les adresses IP du serveur distant. Il convient de noter que cela nécessite une connexion directe au niveau de la deuxième couche réseau entre les serveurs exécutant Flannel;
• aws-vpc - Créer des routes IP dans la table de routage Amazon VPC
• gce - crée des routes IP dans le réseau Google Compute Engine
• alloc - effectue uniquement la sélection du sous-réseau, mais pas la redirection des paquets;
• ali-vpc - Crée des routes IP dans la table de routage Alicloud VPC.

Projet Calico

Calico est une solution complète de mise en réseau entre conteneurs et sécurité réseau. Il peut être intégré à toutes les principales plates-formes d'orchestration et runtimes:

• Kubernetes (module complémentaire pour CNI);
• Mesos (module complémentaire pour CNI);
• Docker (module complémentaire pour libnework);
• OpenStack (module complémentaire pour Neutron).

Calico peut également être déployé localement ou dans un cloud public tout en préservant toutes les fonctionnalités. L'application des politiques de réseau peut dépendre de la charge, ce qui permet un contrôle clair du trafic et garantit que les paquets atteignent toujours les destinations souhaitées. Calico peut automatiquement importer des stratégies réseau à partir de plates-formes d'orchestration. En fait, il est responsable de la mise en œuvre des politiques de réseau chez Kubernetes.

Romana

Romana est une solution moderne de mise en réseau entre conteneurs. Il a été initialement conçu pour être utilisé dans le cloud et fonctionne sur la troisième couche réseau, en s'appuyant sur des méthodes standard de gestion des adresses IP. Romana vous permet d'isoler des réseaux entiers en leur créant des passerelles et des itinéraires à l'aide de serveurs Linux. Le travail sur la troisième couche réseau ne nécessite pas d'encapsulation. La stratégie réseau est appliquée à tous les points de terminaison et services en tant que pare-feu distribué. Romana facilite les déploiements locaux et hybrides entre différentes plates-formes cloud, car vous n'avez plus besoin de configurer de réseaux de superposition virtuels.

Récemment apparus dans Romana, les adresses IP virtuelles permettent aux utilisateurs locaux d'ouvrir l'accès à leurs services dans les réseaux locaux du deuxième niveau, en utilisant des adresses externes et des spécifications de service.

Les développeurs de Romana affirment que leur approche améliore considérablement les performances. Dans la fig. La figure 10.9 montre comment, en évitant l'encapsulation VXLAN, vous pouvez vous débarrasser de beaucoup de surcharge.

Filet tissé

Les principales caractéristiques du projet Weave Net sont la facilité d'utilisation et le manque de configuration. Il utilise l'encapsulation VXLAN et installe des micro-DNS sur chaque nœud. En tant que développeur, vous aurez affaire à un niveau d'abstraction élevé. Après avoir nommé vos conteneurs, Weave Net vous permettra de vous connecter aux ports standard et d'activer les services appropriés. Cela facilite la migration des applications existantes vers les plateformes de microservices et de conteneurisation. Weave Net fournit un module complémentaire CNI pour travailler avec Kubernetes et Mesos. À partir de Kubernetes 1.4, l'intégration avec Weave Net peut être réalisée avec une seule commande qui déploie DaemonSet:

kubectl apply -f https://git.io/weave-kube 

Les pods Weave Net hébergés sur chaque nœud sont responsables de la connexion de toute autre instance de pod au réseau Weave. Weave Net prend en charge les API avec des politiques de réseau, fournissant une solution complète et facile à configurer.

Utilisation efficace des politiques de réseau

La stratégie réseau de Kubernetes est conçue pour contrôler le trafic dirigé vers des pods et des espaces de noms spécifiques. Lors de la gestion de centaines de microservices déployés (comme c'est souvent le cas avec Kubernetes), la mise en réseau entre les foyers prend le dessus. Il est important de comprendre que ce mécanisme n'est qu'indirectement lié à la sécurité. Si un attaquant est capable de pénétrer le réseau interne, il sera très probablement en mesure de créer sa propre instance du foyer qui sera conforme à la politique du réseau et permettra une communication gratuite avec d'autres foyers. Dans la section précédente, nous avons examiné diverses solutions de mise en réseau dans Kubernetes, en nous concentrant sur les interfaces réseau. Ici, nous nous concentrerons sur la politique de réseau mise en œuvre au-dessus de ces solutions, bien que les deux composants soient étroitement interconnectés.

Architecture de stratégie réseau dans Kubernetes

La stratégie de réseau détermine la manière dont les sous-ensembles de foyers peuvent interagir entre eux et avec les autres points de terminaison du réseau. La ressource NetworkPolicy utilise des étiquettes pour sélectionner les foyers et définit une liste de règles d'autorisation qui permettent au trafic d'être dirigé vers les instances de foyers sélectionnées (en plus de ce qui est déjà autorisé par la stratégie d'isolement dans l'espace de noms donné).

»Plus d'informations sur le livre sont disponibles sur le site Web de l'éditeur
» Contenu
» Extrait

20% de réduction sur le Khabrozhitel - Kubernetes

Lors du paiement de la version papier du livre, une version électronique du livre est envoyée par e-mail.

PS: 7% du coût du livre ira à la traduction de nouveaux livres informatiques, la liste des livres remis à l'imprimerie est ici .