È possibile creare gruppi Antrea e utilizzarli come origini o destinazioni nei criteri di firewall distribuito per proteggere il traffico tra i pod all'interno di un cluster Kubernetes Antrea.
La funzionalità dei gruppi Antrea è disponibile solo quando nell'ambiente NSX sono registrati uno o più cluster Kubernetes Antrea. Quando vengono rilevati cluster Kubernetes Antrea registrati, NSX Manager mostra un tipo di gruppo separato chiamato Antrea nella pagina Aggiungi gruppo dell'interfaccia utente. Per aggiungere gruppi Antrea, è necessario selezionare questo tipo di gruppo.
Se l'obiettivo è proteggere il traffico tra cluster Kubernetes Antrea e macchine virtuali nella rete di overlay NSX, è necessario creare gruppi Generico con tipi di membri Kubernetes nei criteri di appartenenza dinamica e utilizzare questi gruppi nelle regole del firewall. Per ulteriori informazioni, vedere Gruppi generici con tipi di membri Kubernetes nei criteri di appartenenza dinamica.
Un gruppo Antrea può includere indirizzi IP statici, criteri di appartenenza o entrambi. Gli indirizzi IP possono essere indirizzi IP di pod o indirizzi IP di servizi.
Quando un gruppo Antrea contiene criteri di appartenenza, i membri effettivi elaborati in base a tali criteri di appartenenza possono essere solo pod.
- I membri effettivi vengono elaborati per i gruppi Antrea solo quando i gruppi Antrea vengono utilizzati nelle regole del firewall distribuito.
Quando si aggiungono gruppi Antrea con criteri di appartenenza, ma questi gruppi non vengono utilizzati in alcuna regola del firewall distribuito, i membri effettivi di questi gruppi Antrea non vengono elaborati o valutati in NSX. In altre parole, la pagina Membri effettivi di questi gruppi Antrea è vuota.
- Quando si aggiungono indirizzi IP statici nei gruppi Antrea, i membri effettivi non vengono al momento visualizzati nell'interfaccia utente, indipendentemente dal fatto che i gruppi vengano utilizzati nelle regole del firewall distribuito.
- Spazio dei nomi
- Servizio
- Pod
Panoramica dei criteri di appartenenza
- Tipo di membro
- Nome del tipo di membro o un tag collegato al tipo di membro
- Operatore e valore del tag (solo quando viene utilizzato un tag)
- Operatore e valore dell'ambito (solo quando viene utilizzato un tag)
Per impostazione predefinita, NSX utilizza l'operatore logico AND dopo ogni condizione di un criterio di appartenenza. Gli altri operatori logici non sono supportati per l'unione di condizioni in un criterio di appartenenza.
- Esempi:
-
Criteri di appartenenza Descrizione Criterio 1:
Tag Pod uguale a App Ambito uguale a Server
Il criterio di appartenenza consiste solo di una singola condizione basata sul pod. Non vengono utilizzate più condizioni. I membri effettivi di questo gruppo Antrea includono tutti gli oggetti pod con il tag App.
Criterio 2:
Tag Pod uguale a App Ambito uguale a Server
Tag Pod uguale a DB Ambito uguale a Server
Tag Pod uguale a Web Ambito uguale a Server
Il criterio di appartenenza consiste di tre condizioni. Tutte le condizioni nel criterio si basano sul pod. I membri effettivi di questo gruppo Antrea includono tutti gli oggetti pod con i tag App, DB e Web.
Criterio 3:
Nome Spazio dei nomi uguale a Produzione
Nome Servizio uguale a Cache
Il criterio di appartenenza include due condizioni con una combinazione di Spazio dei nomi e Servizio. I membri effettivi di questo gruppo Antrea includono tutti i pod associati al Servizio Cache nello Spazio dei nomi Produzione.
Unione dei criteri di appartenenza con gli operatori OR e AND
- Entrambi i criteri utilizzano lo stesso tipo di membro.
- Entrambi i criteri utilizzano una singola condizione.
- Esempi:
-
- Il criterio 1, il criterio 2 e il criterio 3 sono tutti basati su Pod e non contengono condizioni multiple. In questo caso, il criterio 1 e il criterio 2 possono essere uniti con l'operatore OR o l'operatore AND. Analogamente, anche il criterio 2 e il criterio 3 possono essere uniti con l'operatore OR o l'operatore AND.
- Il criterio 1 si basa su Pod, mentre il criterio 2 utilizza due condizioni: una basata su Servizio e l'altra basata su Spazio dei nomi. In questo caso, per unire il criterio 1 e il criterio 2 è possibile utilizzare solo l'operatore OR. L'operatore AND non è consentito.
- Il criterio 1 e il criterio 2 si basano su Pod, mentre il criterio 3 utilizza due condizioni, una basata su Servizio e l'altra basata su Spazio dei nomi. In questo caso, il criterio 1 e il criterio 2 possono essere uniti con l'operatore AND o l'operatore OR. Tuttavia, il criterio 2 e il criterio 3 possono essere uniti solo con l'operatore OR. L'operatore AND non è consentito.
Funzionalità supportate e non supportate
| Tipo di membro | Attributo oggetto | Operatore tag | Operatore ambito | Criteri di esempio |
|---|---|---|---|---|
| Spazio dei nomi |
Nome |
Uguale a |
Non applicabile |
Nome Spazio dei nomi uguale a Produzione |
| Spazio dei nomi |
Tag |
Uguale a Non è uguale a |
Uguale a |
Tag Spazio dei nomi uguale a DB Ambito uguale a Server |
| Servizio |
Nome |
Non supportato |
Non supportato |
Nome Servizio uguale a Cache |
| Pod |
Tag |
Uguale a Non è uguale a |
Uguale a |
Tag Pod uguale a App Ambito uguale a Server |
- I seguenti operatori di tag non sono al momento supportati per i tipi di membri Spazio dei nomi e Pod:
- Contiene
- Inizia con
- Termina con
- In un criterio di appartenenza, una condizione basata su Servizio deve essere combinata con una condizione basata sull'attributo Nome di Spazio dei nomi. In altre parole, un criterio con il solo tipo di membro Servizio non è consentito.
- In un criterio di appartenenza, una condizione basata sul Servizio non può essere combinata con una condizione basata sul Pod. È tuttavia possibile aggiungere condizioni basate su Servizio e Pod in due criteri di appartenenza separati e unirli con un operatore OR.
- Per l'aggiunta di membri statici in un gruppo Antrea, sono supportati solo gli indirizzi IP. Spazio dei nomi, Pod e Servizio non possono essere aggiunti staticamente come membri in un gruppo Antrea.
- Quando si aggiunge un gruppo Antrea, in NSX viene visualizzato un messaggio informativo se si tenta di modificare il tipo di gruppo da Antrea a Generico o da Antrea a Solo indirizzi IP. Alla conferma della modifica, tutti i criteri di appartenenza nel gruppo vengono persi. Nel gruppo vengono conservati solo gli indirizzi IP.
Dopo che un gruppo Antrea è stato realizzato (salvato) in NSX, non è possibile modificare il tipo di gruppo. I tipi di gruppo Generico e Solo indirizzi IP sono disattivati.
Soluzione per versione Kubernetes ≤ 1.20
Il criterio del gruppo Antrea "Nome spazio dei nomi uguale a Valore" funziona con versione Kubernetes ≤ 1.21.
Kubernetes 1.21 o versione successiva aggiunge automaticamente un'etichetta speciale a tutti gli spazi dei nomi e il criterio "Nome spazio dei nomi uguale a Valore" utilizza internamente questa etichetta speciale. Tuttavia, per versione Kubernetes ≤ 1.20, è necessaria una soluzione. È necessario registrare il webhook Controller Antrea sugli eventi di creazione dello spazio dei nomi. Quando viene chiamato il webhook Controller Antrea, Controller Antrea aggiunge un'etichetta speciale al nuovo spazio dei nomi, quindi il criterio "Nome spazio dei nomi uguale a Valore" può utilizzare questa etichetta. Per informazioni dettagliate sulla registrazione del webhook Controller Antrea, vedere il passaggio 3 in Invio dei file YAML al server dell'API Kubernetes.
kube-system e
default non ottengono l'etichetta speciale e il criterio "Nome spazio dei nomi uguale a
Valore" non funziona con questi spazi dei nomi.
