Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Intégration de Contrail avec Kubernetes

Contrail Networking prend en charge l’interface CNI (Container Network Interface) pour l’intégration de Contrail à la plate-forme d’automatisation Kubernetes.

Qu’est-ce que Kubernetes ?

Kubernetes, également appelé K8s, est une plate-forme open source permettant d’automatiser le déploiement, la mise à l’échelle et les opérations des conteneurs d’applications sur des clusters d’hôtes, fournissant ainsi une infrastructure centrée sur les conteneurs. Il fournit une plate-forme portable sur les clouds publics et privés. Kubernetes prend en charge le déploiement, la mise à l’échelle et la réparation automatique des applications.

Kubernetes prend en charge une infrastructure enfichable appelée Container Network Interface (CNI) pour la majeure partie de la connectivité réseau de base, y compris l’adressage des pods de conteneurs, l’isolation réseau, la sécurité basée sur des stratégies, une passerelle, SNAT, l’équilibreur de charge et la capacité de chaînage de services pour l’orchestration Kubernetes. Contrail version 4.0 prend en charge CNI pour Kubernetes.

Kubernetes fournit un modèle de mise en réseau plat dans lequel tous les pods de conteneurs peuvent communiquer entre eux. Une stratégie réseau est ajoutée pour assurer la sécurité entre les pods. L’intégration de Contrail à Kubernetes ajoute des fonctionnalités réseau supplémentaires, notamment la mutualisation, l’isolation réseau, la microsegmentation avec les politiques réseau, l’équilibrage de charge, etc.

Le tableau 1 répertorie le mappage entre les concepts Kubernetes et les ressources OpenContrail.

Tableau 1 : mappage de Kubernetes vers OpenContrail
Kubernetes Ressources OpenContrail

Noms

Projet partagé ou unique

Pod

Machine virtuelle, interface, ip-instance

Service

Équilibreur de charge natif basé sur ECMP

Pénétration

Équilibreur de charge L7 basé sur HAProxy pour le routage d’URL

Politique réseau

Groupe de sécurité basé sur les sélecteurs d’espace de noms et de pod

Qu’est-ce qu’un pod Kubernetes ?

Un pod Kubernetes est un groupe d’un ou plusieurs conteneurs (tels que des conteneurs Docker), le stockage partagé de ces conteneurs et les options d’exécution des conteneurs. Les pods sont toujours colocalisés et planifiés, et exécutés dans un contexte partagé. Le contexte partagé d’un pod est un ensemble d’espaces de noms Linux, de groupes et d’autres facettes de l’isolation. Dans le contexte d’un pod, d’autres sous-isolements peuvent être appliqués aux applications individuelles.

Vous trouverez plus d’informations sur Kubernetes sur : http://kubernetes.io/docs/whatisk8s/.

Modes de configuration de Contrail intégré à Kubernetes

Contrail peut être configuré dans plusieurs modes différents dans Kubernetes. Cette section décrit les différents modes de configuration.

Mode par défaut

Dans Kubernetes, tous les pods peuvent communiquer avec tous les autres pods sans utiliser la traduction d’adresses réseau (NAT). Il s’agit du mode par défaut du cluster Contrail Kubernetes. En mode par défaut, Contrail crée un réseau virtuel partagé par tous les espaces de noms, à partir duquel les adresses IP de service et de pod sont attribuées.

Tous les pods de tous les espaces de noms générés dans le cluster Kubernetes peuvent communiquer entre eux. Les adresses IP de tous les pods sont allouées à partir d’un sous-réseau de pods configuré dans le gestionnaire Contrail Kubernetes.

Note:

Les pods système générés dans l’espace de noms kube-system ne sont pas exécutés dans le cluster Kubernetes ; ils fonctionnent dans le sous-sol et la mise en réseau de ces pods n’est pas gérée par Contrail.

Mode d’isolation des espaces de noms

Outre le modèle de mise en réseau par défaut imposé par Kubernetes, Contrail prend en charge d’autres modèles de mise en réseau personnalisés qui mettent les nombreuses fonctionnalités enrichies de Contrail à la disposition des utilisateurs du cluster Kubernetes. L’une de ces fonctionnalités est l’isolation réseau pour les espaces de noms Kubernetes.

Pour le mode d’isolation des espaces de noms, l’administrateur du cluster peut configurer une annotation d’espace de noms pour activer l’isolation. Par conséquent, les services de cet espace de noms ne sont pas accessibles à partir d’autres espaces de noms, sauf si des groupes de sécurité ou des stratégies réseau sont explicitement définis pour autoriser l’accès.

Un espace de noms Kubernetes peut être configuré comme isolé en annotant les métadonnées de l’espace de noms Kubernetes :

opencontrail.org/isolation : true

L’isolation d’espace de noms assure l’isolation réseau aux pods, car les pods des espaces de noms isolés ne sont pas accessibles aux pods des autres espaces de noms du cluster.

L’isolation d’espace de noms permet également d’isoler les services aux pods. Si un service Kubernetes est implémenté par des pods dans un espace de noms isolé, ces pods ne sont accessibles qu’aux pods du même espace de noms via Kubernetes service-ip.

Pour que les services restent accessibles à d’autres espaces de noms, l’isolation des services peut être désactivée à l’aide de l’annotation supplémentaire suivante sur l’espace de noms :

opencontrail.org/isolation.service : false

La désactivation de l’isolation des services rend les services accessibles aux pods dans d’autres espaces de noms, mais les pods dans les espaces de noms isolés restent inaccessibles aux pods dans d’autres espaces de noms.

Un espace de noms annoté comme « isolé » pour l’isolation de pod et de service a le comportement réseau suivant :

  • Tous les pods créés dans un espace de noms isolé sont accessibles entre eux par le réseau.

  • Les pods des autres espaces de noms du cluster Kubernetes ne peuvent pas atteindre les pods de l’espace de noms isolé.

  • Les pods créés dans des espaces de noms isolés peuvent atteindre des pods dans des espaces de noms non isolés.

  • Les pods des espaces de noms isolés peuvent atteindre des services non isolés dans n’importe quel espace de noms du cluster Kubernetes.

  • Les pods d’autres espaces de noms ne peuvent pas atteindre les services dans les espaces de noms isolés.

Un espace de noms annoté comme « isolé », avec l’isolation de service désactivée et uniquement l’isolation de pod activée, a le comportement réseau suivant :

  • Tous les pods créés dans un espace de noms isolé sont accessibles entre eux par le réseau.

  • Les pods des autres espaces de noms du cluster Kubernetes ne peuvent pas atteindre les pods de l’espace de noms isolé.

  • Les pods créés dans des espaces de noms isolés peuvent atteindre les pods dans d’autres espaces de noms.

  • Les pods des espaces de noms isolés peuvent atteindre des services non isolés dans n’importe quel espace de noms du cluster Kubernetes.

  • Les pods d’autres espaces de noms peuvent accéder aux services dans des espaces de noms isolés.

Mode d’isolation personnalisé

Les administrateurs et les développeurs d’applications peuvent ajouter des annotations pour spécifier le réseau virtuel dans lequel un espace ou tous les pods d’un espace de noms doivent être provisionnés. L’annotation permettant de spécifier ce réseau virtuel personnalisé est la suivante :

"opencontrail.org/network: <fq_network_name>"

Si cette annotation est configurée sur une spécification de pod, le pod est lancé dans ce réseau. Si l’annotation est configurée dans la spécification de l’espace de noms, tous les pods de l’espace de noms sont lancés dans le réseau fourni.

Note:

Le réseau virtuel doit être créé à l’aide des API Contrail VNC ou de Contrail-UI avant de le configurer dans la spécification de l’espace de noms ou de l’espace de noms.

Mode imbriqué

Contrail prend en charge le provisionnement d’un cluster Kubernetes au sein d’un cluster OpenStack. Bien que cette imbrication de clusters ne soit pas unique en soi, Contrail fournit un plan de contrôle et de données réduit dans lequel un seul plan de contrôle Contrail et une seule pile réseau gèrent et entretiennent à la fois les clusters OpenStack et Kubernetes. Grâce à des plans de contrôle et de données unifiés, l’interfonctionnement et la configuration de ces clusters sont transparents, et l’absence de réplication et de duplicité en fait une option très efficace.

En mode imbriqué, un cluster Kubernetes est provisionné sur la machine virtuelle d’un cluster OpenStack. Le plug-in CNI et le gestionnaire Contrail-kubernetes du cluster Kubernetes s’interfacent directement avec les composants Contrail qui gèrent le cluster OpenStack.

Dans un déploiement en mode imbriqué, toutes les fonctionnalités, fonctions et spécifications de Kubernetes sont prises en charge en l’état. Le déploiement imbriqué repousse les limites de Kubernetes en lui permettant de fonctionner sur le même plan que le cluster OpenStack sous-jacent.

Pour plus d’informations, consultez Provisionnement de clusters Kubernetes.

Kubernetes Services

Un service Kubernetes est une abstraction qui définit un ensemble logique d’espaces et la stratégie utilisée pour accéder aux pods. L’ensemble des pods implémentant un service est sélectionné en fonction du champ LabelSelector de la définition de service. Dans Contrail, un service Kubernetes est implémenté en tant qu’équilibreur de charge ECMP natif.

L’intégration de Contrail Kubernetes prend en charge les types de servicesuivants :

  • 'clusterIP' : il s’agit du mode par défaut. Ce type de service rend le service accessible via le réseau de cluster.

  • 'LoadBalancer' : La désignation d’un ServiceType comme 'LoadBalancer' permet d’accéder au service en externe. Le _Service_ 'LoadBalancer' se voit attribuer des adresses CluserIP et ExternalIP. Ce ServiceType suppose que l’utilisateur a configuré le réseau public avec un pool d’adresses IP flottantes.

L’intégration de services Contrail Kubernetes prend en charge TCP et UDP pour les protocoles. En outre, le service peut exposer plusieurs ports où le port et le port cible sont différents. Par exemple :

Les utilisateurs Kubernetes peuvent spécifier spec.clusterIP et spec.externalIPs pour les types de service LoadBalancer et clusterIP.

Si ServiceType est LoadBalancer et qu’aucune spécification .externalIP n’est spécifiée par l’utilisateur, contrail-kube-manager alloue une adresse IP flottante du pool public et l’associe à l’adresse ExternalIP.

Pénétration

Les services Kubernetes peuvent être exposés en externe ou en dehors du cluster de nombreuses façons. Consultez https://kubernetes.io/docs/concepts/services-networking/ingress/#alternatives pour obtenir la liste de toutes les méthodes d’exposition externe des services Kubernetes. L’entrée est l’une de ces méthodes. Ingress fournit l’équilibrage de charge de couche 7 alors que les autres méthodes fournissent l’équilibrage de charge de couche 4. Contrail prend en charge l’entrée à service unique basée sur http, l’entrée à diffusion simple et l’entrée d’hébergement virtuel basée sur le nom.

Contrail Kubernetes Solution

La solution Contrail Kubernetes comprend les éléments suivants.

Responsable Contrail Kubernetes

L’implémentation de Contrail Kubernetes nécessite d’écouter les messages de l’API Kubernetes et de créer les ressources correspondantes dans la base de données de l’API Contrail.

Un nouveau module, contrail-kube-manager, s’exécute dans un conteneur Docker pour écouter les messages du serveur API Kubernetes.

Équilibreurs de charge ECMP pour les services Kubernetes

Chaque service dans Kubernetes est représenté par un objet d’équilibrage de charge. L’adresse IP de service allouée par Kubernetes est utilisée comme adresse IP virtuelle pour l’équilibreur de charge. Les écouteurs sont créés pour le port sur lequel le service écoute. Chaque pod est ajouté en tant que membre du pool d’écouteurs. Le gestionnaire contrail-kube écoute tous les changements basés sur les étiquettes de service ou les étiquettes de pod, et met à jour la liste des pools de membres avec tous les pods ajoutés, mis à jour ou supprimés.

L’équilibrage de charge pour les services est un équilibrage de charge de couche 4 natif, sans proxy, basé sur ECMP. L’instance-ip (service-ip) est liée aux ports de chacun des pods du service. Cela crée un saut suivant ECMP dans Contrail et la charge du trafic est équilibrée directement à partir du pod source.

HAProxy Loadbalancer pour Kubernetes Ingress

Kubernetes Ingress est implémenté via la fonctionnalité d’équilibrage de charge HAProxy de Contrail. Chaque fois qu’ingress est configuré dans Kubernetes, contrail-kube-manager crée l’objet load-balancer dans contrail-controller. Le moniteur de service Contrail écoute les objets d’équilibrage de charge et lance le HAProxy avec la configuration appropriée, basée sur les règles de spécification d’entrée en mode veille-actif.

Voir Utilisation des équilibreurs de charge dans Contrail pour plus d’informations sur les équilibreurs de charge .

Groupes de sécurité pour la stratégie réseau Kubernetes

La stratégie réseau Kubernetes est une spécification de la manière dont les groupes d’espaces sont autorisés à communiquer entre eux et avec d’autres points de terminaison réseau. Les ressources NetworkPolicy utilisent des étiquettes pour sélectionner les pods et définir des règles de liste blanche qui autorisent le trafic vers les pods sélectionnés en plus de ce qui est autorisé par la stratégie d’isolation pour un espace de noms donné.

Pour plus d’informations sur les stratégies réseau Kubernetes, consultez https://kubernetes.io/docs/concepts/services-networking/networkpolicies/.

Le contrail-kube-manager écoute les événements de stratégie réseau Kubernetes pour les créer, les mettre à jour et les supprimer, et traduit la stratégie réseau Kubernetes en objets de groupe de sécurité Contrail appliqués aux interfaces de machine virtuelle (VMI). Les VMI sont mises à jour dynamiquement à mesure que des pods et des étiquettes sont ajoutés et supprimés.

Prise en charge par Kubernetes de la stratégie de sécurité

Les stratégies réseau créées dans un environnement Kubernetes sont implémentées à l’aide du framework Contrail Security Policy. Les étiquettes de l’environnement Kubernetes sont exposées en tant que balises dans Contrail. À partir de Contrail Release 5.0, vous pouvez définir des balises pour un environnement Kubernetes. La stratégie de sécurité Contrail utilise ces balises pour implémenter les stratégies Kubernetes spécifiées. Vous pouvez définir des balises dans l’interface utilisateur ou télécharger des configurations au format JSON. Les balises nouvellement définies peuvent être utilisées pour créer et appliquer des stratégies dans Contrail Security.

Serveur de noms de domaine (DNS)

Kubernetes implémente DNS à l’aide de SkyDNS, une petite application DNS qui répond aux requêtes DNS de résolution de noms de service à partir de pods. SkyDNS s’exécute comme un pod dans Kubernetes.

Annotations Kubernetes prises en charge

Actuellement, Contrail Networking prend en charge les annotations Kubernetes suivantes :

Pour plus de détails, reportez-vous à https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/.

Documentation connexe