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 fonctionnalité nécessite la version d'interfonctionnement Antrea-NSX disponible avec VMware Container Networking™ with Antrea™ 1.6.0 ou version ultérieure. Consultez les notes de mise à jour de 1.6.0.
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.
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.
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 :
|
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 :
|
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 :
|
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.
- Les deux critères utilisent le même type de membre Kubernetes.
- Les deux critères utilisent une condition unique.
- 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 |
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 |