Vous pouvez créer des groupes avec des types de membres (ressources) Kubernetes dans des critères d'appartenance dynamique pour faire correspondre le trafic entrant ou sortant de clusters Antrea Kubernetes.

Vous pouvez ensuite utiliser ces groupes génériques dans des règles de pare-feu distribué ou des règles de pare-feu de passerelle pour sécuriser le trafic entre les machines virtuelles dans l'environnement NSX et les espaces dans des clusters Antrea Kubernetes.

Cette documentation utilise l’expression « Types de membres Kubernetes » pour faire référence aux « ressources Kubernetes » que vous pouvez utiliser pour configurer des critères d’appartenance dynamique.

Actuellement, les groupes génériques avec des types de membres Kubernetes prennent uniquement en charge les critères d'appartenance dynamique. Vous ne pouvez pas ajouter des types de membres Kubernetes de manière statique dans une définition de groupe générique.

Note : Pour évaluer les membres effectifs d'un groupe générique qui contient des critères d'appartenance dynamique définis à l'aide des types de membres Kubernetes, NSX prend en compte l'inventaire de ressources signalé par les clusters Kubernetes avec Antrea CNI. L'inventaire de ressources signalé par les clusters Kubernetes avec NCP CNI est ignoré pour évaluer les membres effectifs du groupe.

Types de membres Kubernetes dans les critères d'appartenance

Dans un groupe générique, les types de membres Kubernetes sont disponibles sur la page Critères d'appartenance uniquement lorsqu'au moins un cluster Kubernetes Antrea est enregistré dans votre environnement NSX.

Note : Dans un environnement NSX mutualisé, les ressources de cluster Kubernetes ne sont pas exposées à l'inventaire du projet. Par conséquent, dans un projet, vous ne pouvez pas créer de groupes génériques avec des types de membres Kubernetes dans des critères d'appartenance dynamique.

Le tableau suivant répertorie les types de membres Kubernetes disponibles dans la vue Par défaut de NSX 4.1 et versions ultérieures pour ajouter des critères d'appartenance dynamique à un groupe générique. Chaque type de membre Kubernetes appartient à l'étendue du cluster ou à l'étendue de l'espace de noms.

Type de membre Portée

Cluster Kubernetes

Cluster

Espace de noms Kubernetes

Espace de noms

Nœud Kubernetes

Cluster

Service Kubernetes

Espace de noms

Entrée Kubernetes

Espace de noms

Passerelle Kubernetes

Espace de noms

Sortie Antrea

Cluster

Pool IP Antrea

Cluster

Conventions de dénomination utilisées pour les conditions avec des types de membres Kubernetes

Le tableau suivant décrit les conventions de dénomination utilisées dans cette documentation pour représenter les différentes conditions que vous pouvez ajouter dans les critères d'appartenance dynamique, qui sont basés sur les types de membres Kubernetes.

Convention de dénomination pour la condition Signification

Condition de cluster Kubernetes

Les conditions dans les critères d'appartenance dynamique sont basées sur le type de membre du cluster Kubernetes.

Condition d'espace de noms Kubernetes

Les conditions des critères d'appartenance dynamique sont basées sur le type de membre Espace de noms Kubernetes.

Condition de ressource

Les conditions du critère d'appartenance dynamique sont basées sur l'un de ces types de membres Kubernetes :
  • Service Kubernetes
  • Entrée Kubernetes
  • Passerelle Kubernetes
  • Sortie Antrea
  • Pool IP Antrea
  • Nœud Kubernetes

Condition de ressource d'étendue de cluster

Les conditions des critères d'appartenance dynamique sont basées sur l'un de ces types de membres Kubernetes :
  • Sortie Antrea
  • Pool IP Antrea
  • Nœud Kubernetes

Condition de ressource d'étendue d'espace de noms

Les conditions des critères d'appartenance dynamique sont basées sur l'un de ces types de membres Kubernetes :
  • Service Kubernetes
  • Entrée Kubernetes
  • Passerelle Kubernetes

Présentation des critères d'appartenance avec les types de membres Kubernetes

Un critère peut avoir une ou plusieurs conditions. Les conditions peuvent utiliser le même type de membre Kubernetes ou un mélange de différents types de membres Kubernetes. Cependant, certaines restrictions s'appliquent à l'ajout de plusieurs conditions avec des types de membres mélangés dans un critère d'appartenance. Reportez-vous à la section Restrictions pour l'utilisation des types de membres Kubernetes dans un critère plus loin dans cette documentation.

Par défaut, NSX utilise l'opérateur logique AND après chaque condition dans un critère d'appartenance. Les autres opérateurs logiques ne sont pas pris en charge pour joindre des conditions dans un critère d'appartenance.

Pour joindre les critères, des opérateurs OR et AND sont disponibles. Par défaut, NSX sélectionne l'opérateur OR pour joindre deux critères. L'opérateur AND est pris en charge entre deux critères uniquement lorsque :
  • Les deux critères utilisent le même type de membre Kubernetes.
  • Les deux critères utilisent une condition unique.
Les restrictions suivantes s'appliquent à l'ajout de plusieurs conditions :
  • Un maximum de cinq conditions avec le même type de membre Kubernetes est pris en charge dans un critère d'appartenance unique. Par exemple, dans un critère, vous pouvez ajouter un maximum de cinq conditions de service Kubernetes.
  • Un maximum de 15 conditions avec des types de membres mixtes Kubernetes est pris en charge dans un critère d'appartenance unique. Par exemple, dans un critère, vous pouvez ajouter un maximum de 15 conditions avec un mélange de condition d'espace de noms Kubernetes et de conditions d'entrée Kubernetes.
  • Un maximum de 35 conditions avec des types de membres mixtes est pris en charge dans un groupe générique.

Un groupe peut avoir un maximum de cinq critères d'appartenance. Toutefois, le nombre total de critères que vous pouvez ajouter à un groupe générique est déterminé par le nombre de conditions dans chaque critère. Consultez les exemples suivants.

Exemple 1
Un groupe générique avec trois critères d'appartenance et un total de 35 conditions :
  • Le critère 1 a 15 conditions avec des types de membres mixtes.
  • Le critère 2 a 15 conditions avec des types de membres mixtes.
  • Le critère 3 a 5 conditions avec le même type de membre.
Exemple 2
Un groupe générique avec 4 critères d'appartenance et un total de 35 conditions :
  • Le critère 1 a 15 conditions avec des types de membres mixtes.
  • Le critère 2 a 14 conditions avec des types de membres mixtes.
  • Le critère 3 a quatre conditions avec le même type de membre.
  • Le critère 4 a deux conditions avec le même type de membre.
Exemple 3
Un groupe générique avec 5 critères d'appartenance et un total de 22 conditions :
  • Le critère 1 a 10 conditions avec des types de membres mixtes.
  • Le critère 2 a trois conditions avec le même type de membre.
  • Le critère 3 a quatre conditions avec le même type de membre.
  • Le critère 4 a trois conditions avec le même type de membre.
  • Le critère 5 a deux conditions avec des types de membres mixtes.
Étant donné que ce groupe a atteint la limite de cinq critères, vous ne pouvez pas ajouter un autre critère d'appartenance. Cependant, vous pouvez ajouter d'autres conditions, si nécessaire, dans l'un des cinq critères tant que vous ne dépassez pas les limites maximales suivantes mentionnées précédemment :
  • Un maximum de cinq conditions avec le même type de membre dans un critère unique.
  • Un maximum de 15 conditions avec des types de membres mixtes dans un critère unique.
  • Un total de 35 conditions dans le groupe générique.

Restrictions pour l'utilisation de types de membres Kubernetes dans un critère

Le tableau suivant fournit un résumé général des restrictions ou validations qui s'appliquent à l'utilisation de types de membres Kubernetes dans un critère d'appartenance unique. Pour obtenir des exemples de validations, reportez-vous à la section Validations pour le regroupement dynamique avec des types de membres Kubernetes plus loin dans cette documentation.

Type de membre Restrictions d'utilisation du type de membre dans un critère Attributs pris en charge Opérateur de balise Opérateur d'étendue

Cluster Kubernetes

Ne peut pas être utilisé seul dans un critère.

Une seule condition de cluster est autorisée dans un critère.

Doit être mélangé à au moins une condition de ressource Kubernetes.

Éventuellement, peut être mélangé avec des conditions d'espace de noms Kubernetes et des conditions de ressources Kubernetes.

Nom

Non pris en charge

Non pris en charge

Espace de noms Kubernetes

Ne peut pas être utilisé seul dans un critère.

Ne peut pas être mélangé avec des conditions de ressources d'étendue de cluster.

Doit être mélangé à des conditions de ressources d'étendue d'espace de noms.

Éventuellement, peut être mélangé avec une condition de cluster Kubernetes.

Nom

Balise

Est égal à : une balise peut être sélectionnée

Est égal à

Sortie Antrea

Peut être utilisé seul dans un critère.

Éventuellement, peut être mélangé avec une condition de cluster Kubernetes.

Nom

Balise

Est égal à : une balise peut être sélectionnée

Est égal à

Pool IP Antrea

Peut être utilisé seul dans un critère.

Éventuellement, peut être mélangé avec une condition de cluster Kubernetes.

Nom

Balise

Est égal à : une balise peut être sélectionnée

Est égal à

Entrée Kubernetes

Peut être utilisé seul dans un critère.

Éventuellement, peut être mélangé avec uniquement des conditions d'espace de noms Kubernetes, uniquement une condition de cluster Kubernetes ou les deux.

Nom

Balise

Est égal à : une balise peut être sélectionnée

Est égal à

Passerelle Kubernetes

Peut être utilisé seul dans un critère.

Éventuellement, peut être mélangé avec uniquement des conditions d'espace de noms Kubernetes, uniquement une condition de cluster Kubernetes ou les deux.

Nom

Balise

Est égal à : une balise peut être sélectionnée

Est égal à

Service Kubernetes

Peut être utilisé seul dans un critère.

Éventuellement, peut être mélangé avec uniquement des conditions d'espace de noms Kubernetes, uniquement une condition de cluster Kubernetes ou les deux.

Nom

Balise

Est égal à : une balise peut être sélectionnée

Est égal à

Nœud Kubernetes

Peut être utilisé seul dans un critère.

Seule une condition de nœud unique est autorisée.

Éventuellement, peut être mélangé avec une condition de cluster Kubernetes.

Ne peut pas être mélangé avec des conditions d'espace de noms Kubernetes ou des conditions de ressources Kubernetes.

Adresse IP

CIDR d'espace

Non pris en charge

Reportez-vous à la section Remarque après ce tableau.

Non pris en charge

Note : Lorsque vous créez un groupe générique avec le type de membre de nœud Kubernetes à l'aide de l'API, seul l'opérateur Correspond est autorisé. Cet opérateur ne peut prendre que la valeur *. Le caractère générique * correspondra à tous les nœuds du cluster K8s (si la condition de nœud Kubernetes est mélangée à une condition de cluster Kubernetes), ou il correspondra aux nœuds sur tous les clusters (si la condition de nœud Kubernetes est utilisée seule).

Validations pour le regroupement dynamique avec des types de membres Kubernetes

Validation 1
Un critère d'appartenance peut avoir un maximum d'une condition de cluster Kubernetes. Pour faire correspondre un cluster Kubernetes unique par nom, utilisez l'opérateur Est égal à et entrez le nom du cluster.
Note : Le nom du cluster Kubernetes doit être unique.
Si vous souhaitez faire correspondre plusieurs clusters dans une condition de cluster Kubernetes unique, vous pouvez utiliser l'un de ces opérateurs :
  • Entrant
  • Commence par
  • Se termine par

Exemple :

Correspond au cluster K8s unique Correspond à plusieurs clusters K8s
Critère :

Le nom du cluster Kubernetes est égal à ClusterA

Critère :

Nom du cluster Kubernetes dans ClusterA, ClusterB, ClusterC

Un maximum de cinq valeurs séparées par des virgules est autorisé. Les valeurs ne doivent pas être séparées par des espaces.

Validation 2

Un critère d'appartenance avec une condition de cluster Kubernetes peut être mélangé à n'importe quelle condition de ressource Kubernetes. Si vous ajoutez également des conditions d'espace de noms Kubernetes dans le même critère, les conditions de ressources doivent être limitées uniquement aux conditions de ressources d'étendue d'espace de noms.

Exemples :
  • Un critère d'appartenance avec une condition de cluster Kubernetes et trois conditions d'entrée Kubernetes est valide.
  • Un critère d'appartenance avec une condition de cluster Kubernetes et deux conditions de sortie Antrea est valide.
  • Un critère d'appartenance avec une condition de cluster Kubernetes et trois conditions de pool d'adresses IP Antrea est valide.
  • Un critère d'appartenance avec une condition de cluster Kubernetes, une condition d'espace de noms Kubernetes et trois conditions de passerelle Kubernetes est valide.
Validation 3
Un critère d'appartenance doit inclure au moins une condition de ressource Kubernetes. Un critère d'appartenance n'est pas valide s'il contient :
  • Uniquement une condition de cluster Kubernetes
  • Uniquement une condition d'espace de noms Kubernetes
  • Uniquement la condition de cluster Kubernetes et la condition d'espace de noms Kubernetes
Exemples :
  • Un critère d'appartenance avec une condition de cluster Kubernetes, une condition d'espace de noms Kubernetes et une condition d'entrée Kubernetes est valide.
  • Un critère d'appartenance avec une condition de cluster Kubernetes, deux conditions d'espace de noms Kubernetes et trois conditions d'entrée Kubernetes est valide.
Validation 4

Un critère d'appartenance ne peut avoir qu'une seule condition de nœud Kubernetes. Éventuellement, une condition de nœud Kubernetes ne peut être mélangée qu'à une condition de cluster Kubernetes.

Une condition de nœud Kubernetes ne peut pas être mélangée avec des conditions d'espace de noms Kubernetes ou des conditions de ressources Kubernetes.

Un critère d'appartenance avec uniquement une condition de nœud Kubernetes peut être autonome. Cependant, un groupe avec uniquement une condition de nœud Kubernetes correspondra aux nœuds de tous les clusters Kubernetes Antrea qui sont enregistrés dans NSX.

L'opérateur de balise et l'opérateur d'étendue ne sont actuellement pas pris en charge pour la condition de nœud Kubernetes.

La condition de nœud Kubernetes prend en charge les deux propriétés suivantes.

Propriété Description

Adresse IP

Correspond à l'adresse IP interne de tous les nœuds de clusters Kubernetes Antrea spécifiés.

CIDR d'espace

Correspond au CIDR d'espace de tous les nœuds de clusters Kubernetes Antrea spécifiés.

Validation 5
Si un critère d'appartenance inclut une condition de cluster Kubernetes et des conditions d'espace de noms Kubernetes, il doit inclure au moins une condition de ressource Kubernetes à l'espace de noms. Vous ne pouvez pas mélanger les conditions de ressources Kubernetes basées sur le cluster suivantes dans le même critère :
  • Sortie Antrea
  • Antrea IP Pool
  • Nœud Kubernetes
Exemples :
  • Un critère d'appartenance avec une condition de cluster Kubernetes, deux conditions d'espace de noms Kubernetes et des conditions de passerelle Kubernetes est valide.
  • Un critère d'appartenance avec une condition de cluster Kubernetes, quatre conditions d'espace de noms Kubernetes et trois conditions de service Kubernetes est valide.
  • Un critère d'appartenance avec une condition de cluster Kubernetes, une condition d'espace de noms Kubernetes et une condition de sortie Antrea n'est pas valide, car la sortie Antrea est une ressource à l'échelle du cluster.
Validation 6
Un critère d'appartenance doit inclure au moins une condition de ressource Kubernetes. Une condition de ressource peut être autonome dans un critère. Cependant, si vous ajoutez plusieurs conditions de ressources dans un critère, toutes les conditions de ressources doivent être du même type de membre.
Note : La condition de cluster Kubernetes et les conditions d'espace de noms Kubernetes sont utilisées pour définir l'étendue d'un critère. Il ne s'agit pas de conditions de ressources Kubernetes. Elles ne sont donc pas limitées par cette règle de validation.
Exemples :
  • Un critère d'appartenance avec cinq conditions de service Kubernetes est valide.
  • Un critère d'appartenance avec une condition de cluster Kubernetes, trois conditions d'espace de noms Kubernetes et quatre conditions de service Kubernetes est valide.
  • Un critère d'appartenance avec une condition de cluster Kubernetes, trois conditions d'espace de noms Kubernetes, quatre conditions de service Kubernetes et trois conditions d'entrée Kubernetes n'est pas valide. Cela est dû au fait que vous avez mélangé les conditions de ressources de deux types de membres différents (Service Kubernetes et Entrée Kubernetes) dans le même critère.

    Cependant, vous pouvez créer des critères distincts avec une condition de ressource basée sur un type de membre unique, puis joindre les deux critères avec un opérateur OR, comme indiqué ci-dessous :

    Critère 1 :

    Une condition de cluster Kubernetes + trois conditions d'espace de noms Kubernetes + quatre conditions de service Kubernetes

    OU

    Critère 2 :

    Une condition de cluster Kubernetes + trois conditions d'espace de noms Kubernetes + trois conditions d'entrée Kubernetes

Validation 7

Dans un critère d'appartenance unique, les conditions basées sur des types de membres NSX ne peuvent pas être mélangées avec des conditions basées sur des types de membres Kubernetes. Cependant, vous pouvez disposer d'un groupe avec un critère basé uniquement sur des types de membres NSX et d'autres critères basés uniquement sur des types de membres Kubernetes, puis joindre les deux critères avec un opérateur OR.

Exemple :

Valide Non valide

Critère 1 :

Conditions de machine virtuelle

OU

Critère 2 :

Condition de cluster Kubernetes + conditions de la passerelle Kubernetes

Critère :

Condition de segment NSX + condition de port de segment

ET

Condition de cluster Kubernetes + conditions de la passerelle Kubernetes

Membres effectifs pour les conditions avec des types de membres Kubernetes

Du point de vue de NSX, les membres effectifs des groupes avec des types de membres Kubernetes sont des adresses IP, des plages d'adresses IP ou une liste d'adresses IP et de ports discrets.

Le tableau suivant fournit des exemples.

Exemple de définition de groupe Cas d'utilisation Description Membres effectifs

Condition de cluster Kubernetes

ET

Condition de nœud Kubernetes (basée sur l’adresse IP)

Trafic de cluster Antrea Kubernetes vers NSX

Correspond à toutes les adresses IP de nœud dans les clusters spécifiés

Adresses IP

Condition de cluster Kubernetes

ET

Condition de nœud Kubernetes (basé sur le CIDR d'espace)

Trafic de cluster Antrea Kubernetes vers NSX

Correspond aux CIDR d’espace de tous les nœuds des clusters spécifiés

CIDR d'espace

Condition de cluster Kubernetes

ET

Condition de sortie Antrea (basée sur le nom)

Trafic de cluster Antrea Kubernetes vers NSX

Correspond à la sortie par nom dans les clusters spécifiés

Adresses IP de sortie

Condition de cluster Kubernetes

ET

Condition de sortie Antrea (basée sur la balise)

ET

Plus de conditions de sortie Antrea (basées sur la balise)

Trafic de cluster Antrea Kubernetes vers NSX

Correspond à la sortie par balises dans les clusters spécifiés.

Adresses IP de sortie

Condition de cluster Kubernetes

ET

Condition de pool d'adresses IP Antrea (basée sur le nom)

Trafic de cluster Antrea Kubernetes vers NSX

Trafic de NSX vers cluster Kubernetes Antrea

Correspond au pool d’adresses IP par nom dans les clusters spécifiés

Plages d'adresses IP

Condition de cluster Kubernetes

ET

Condition de pool d'adresses IP Antrea (basée sur la balise)

ET

Plus de conditions de pool d'adresses IP Antrea (basées sur des balises)

Trafic de cluster Antrea Kubernetes vers NSX

Trafic de NSX vers cluster Kubernetes Antrea

Correspond aux pools d’adresses IP par balises dans les clusters spécifiés

Plages d'adresses IP

Condition de cluster Kubernetes

ET

Condition d'espace de noms Kubernetes

ET

Condition d’entrée Kubernetes (basée sur le nom)

Trafic de NSX vers cluster Kubernetes Antrea

Correspond à l’entrée par nom dans les clusters et l’espace de noms spécifiés

Adresses IP d’entrée

Condition de cluster Kubernetes

ET

Condition d'espace de noms Kubernetes

ET

Condition de passerelle Kubernetes (basée sur le nom)

Trafic de NSX vers cluster Kubernetes Antrea

Correspond à la passerelle par nom dans les clusters et l'espace de noms spécifiés

Adresses IP de passerelle

Condition de cluster Kubernetes

ET

Condition d'espace de noms Kubernetes

ET

Condition d'entrée Kubernetes (basée sur la balise)

ET

Plus de conditions d'entrée Kubernetes (basées sur des balises)

Trafic de NSX vers cluster Kubernetes Antrea

Correspond à l’entrée par balises dans les clusters et l’espace de noms spécifiés

Adresses IP d’entrée

Condition de cluster Kubernetes

ET

Condition d'espace de noms Kubernetes

ET

Condition de passerelle Kubernetes (basée sur la balise)

ET

Plus de conditions de passerelle Kubernetes (basées sur des balises)

Trafic de NSX vers cluster Kubernetes Antrea

Correspond à la passerelle par balises dans les clusters et l'espace de noms spécifiés

Adresses IP de passerelle

Condition de cluster Kubernetes

ET

Condition d'espace de noms Kubernetes

ET

Condition de service Kubernetes (basée sur la balise et le type=LoadBalancer)

ET

Plus de conditions de service Kubernetes (basées sur les balises et type=LoadBalancer)

Trafic de NSX vers cluster Kubernetes Antrea

Correspond au service (LoadBalancer) par balises dans les clusters et l'espace de noms spécifiés

Adresses IP d’entrée de LoadBalancer

Condition de cluster Kubernetes

ET

Condition d'espace de noms Kubernetes

ET

Condition du service Kubernetes (basée sur le nom, type=ClusterIP et fonctionnalité NodePortLocal activée)

Trafic de NSX vers cluster Kubernetes Antrea Correspond au service (ClusterIP avec NodePortLocal activé) par nom dans les clusters et l'espace de noms spécifiés.

Adresses IP du nœud, plage NodePortLocal