È possibile creare segmenti secondari per abilitare IPAM, routing e NAT avanzati per i carichi di lavoro Kubernetes con Antrea. I segmenti secondari sono progettati per supportare le funzionalità di Antrea come l'IPAM flessibile dei pod instradabili e l'uscita Antrea.
Il diagramma seguente mostra come i segmenti secondari sono connessi agli altri componenti.
Un segmento principale è un segmento NSX regolare. Per rendere principale un segmento non è necessaria alcuna configurazione. Un segmento secondario è associato a uno o più segmenti principali. Al segmento secondario viene assegnato un ID VLAN per ogni segmento principale. Un segmento principale invierà solo il traffico del segmento secondario contrassegnato con l'ID VLAN specifico.
- Un segmento secondario può essere associato a diversi segmenti principali.
- Un segmento principale può avere numerosi segmenti secondari.
- Ogni segmento secondario collegato a un segmento principale deve avere un ID VLAN distinto e due segmenti secondari connessi allo stesso segmento principale non possono condividere un ID VLAN.
- Un segmento secondario che si connette a più segmenti principali può utilizzare lo stesso ID VLAN o un ID VLAN diverso per queste connessioni.
- Un segmento secondario non può essere il segmento principale di un altro segmento secondario.
- Un segmento secondario può essere un segmento di overlay o un segmento VLAN.
- Le macchine virtuali possono connettersi a segmenti secondari. Quando lo fanno, viene creata una porta di segmento, in modo analogo a quando una macchina virtuale è connessa a un segmento standard.
- Non viene invece creata alcuna porta di segmento nel segmento secondario per la connessione segmento principale-segmento secondario.
- I segmenti secondari e i segmenti principali sono indipendenti. Ciò significa che:
- Possono connettersi allo stesso gateway di livello 1 o 0 oppure a gateway di livello 1 o 0 diversi.
- Possono avere configurazioni o profili di commutazione diversi.
- Le configurazioni in un segmento principale non vengono ereditate dai suoi segmenti secondari.
- Un gruppo che include un segmento principale non include automaticamente i suoi segmenti secondari.
- I servizi configurati in un segmento principale, ad esempio un firewall distribuito, non si estendono ai segmenti secondari.
Per le macchine virtuali connesse a un segmento secondario, sono supportate tutte le funzionalità correlate al segmento. Nella tabella seguente sono elencate le funzionalità supportate e non supportate per il traffico del container che passa attraverso un segmento secondario:
Funzionalità | Supportato |
---|---|
Firewall distribuito | No |
Profilo segmento individuazione IP | No |
Profilo segmento di individuazione MAC | No |
Profilo segmento di sicurezza del segmento | No |
Profilo segmento SpoofGuard | No |
Profilo segmento QoS | No |
Mirroring porta | No |
IPFix | No |
Raggruppamento uplink | Sì |
Configurazione mirroring (span uplink) | Sì |
NSGroup | No |
Latenza | No |
Utilizzo segmento secondario con Antrea
Ogni subnet instradabile (ad esempio, pool di IP per pod instradabili e pool di IP esterni per le uscite) configurata in Antrea viene mappata a un segmento secondario e i segmenti delle macchine virtuali del nodo Kubernetes sono i segmenti principali del segmento secondario. OVS (Open vSwitch) nella macchina virtuale del nodo Kubernetes contrassegnerà il traffico con l'ID VLAN corretto prima di inviare i pacchetti tramite la VNIC.
- Creare il segmento principale. È possibile utilizzare l'API o l'interfaccia utente di NSX Manager.
- Creare il segmento secondario. È possibile utilizzare l'API o l'interfaccia utente di NSX Manager.
- Utilizzare l'API per creare una mappa di associazione della connessione nel segmento secondario specificando il percorso del segmento principale e l'ID VLAN.
- Utilizzare l'API per eliminare tutte le mappe di associazione della connessione esistenti del segmento secondario.
- Eliminare il segmento secondario. È possibile utilizzare l'API o l'interfaccia utente di NSX Manager.
- Utilizzare l'API per eliminare tutte le mappe di associazione della connessione esistenti che connettono questo segmento principale a tutti i suoi segmenti secondari.
- Eliminare il segmento principale. È possibile utilizzare l'API o l'interfaccia utente di NSX Manager.
API
Le seguenti chiamate API possono essere utilizzate per gestire i segmenti secondari. Per ulteriori informazioni, vedere la Guida di NSX API (passare alla documentazione di NSX e utilizzare il riquadro di navigazione a sinistra per individuare la guida dell'API).
GET /policy/api/v1/infra/segments/{segment-id}/segment-connection-binding-maps GET /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/segments/{segment-id}/segment-connection-binding-maps DELETE /policy/api/v1/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id} DELETE /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id} GET /policy/api/v1/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id} GET /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id} PATCH /policy/api/v1/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id} PATCH /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id} PUT /policy/api/v1/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id} PUT /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id} GET /policy/api/v1/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps GET /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps DELETE /policy/api/v1/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps/{map-id} DELETE /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps/{map-id} GET /policy/api/v1/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps/{map-id} GET /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps/{map-id} PATCH /policy/api/v1/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps/{map-id} PATCH /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps/{map-id} PUT /policy/api/v1/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps/{map-id} PUT /policy/api/v1/orgs/{org-id}/projects/{project-id}/infra/tier-1s/{tier-1-id}/segments/{segment-id}/segment-connection-binding-maps/{map-id}
Quando si crea una mappa di associazione della connessione, l'ID mappa specificato nell'API PUT deve essere univoco. Esempio di utilizzo di PUT /policy/api/v1/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id}
per creare una mappa di associazione:
PUT https://<nsx-manager>/policy/api/v1/infra/segments/test2/segment-connection-binding-maps/map-id-1 { "vlan_traffic_tag": "1002", "segment_path": "/infra/segments/openshift-segment" }
{ "vlan_traffic_tag" : 1002, "segment_path" : "/infra/segments/openshift-segment", "resource_type" : "SegmentConnectionBindingMap", "id" : "map-id-1", "display_name" : "map-id-1", "path" : "/infra/segments/test2/segment-connection-binding-maps/map-id-1", "relative_path" : "map-id-1", "parent_path" : "/infra/segments/test2", "remote_path" : "", "unique_id" : "7ac8c0fb-a0e1-471a-bed6-d15f1b85e0c6", "realization_id" : "7ac8c0fb-a0e1-471a-bed6-d15f1b85e0c6", "owner_id" : "210584d9-6329-452e-bb01-0133945ab675", "marked_for_delete" : false, "overridden" : false, "_system_owned" : false, "_protection" : "NOT_PROTECTED", "_create_time" : 1712718210160, "_create_user" : "admin", "_last_modified_time" : 1712718210160, "_last_modified_user" : "admin", "_revision" : 0 }
Traceflow
- L'origine è un container in un segmento secondario e la destinazione è un container in un segmento secondario.
- L'origine è un container in un segmento secondario e la destinazione è una porta regolare.
- L'origine è una porta principale. Non è presente alcun segmento secondario perché i container Antrea sono in esecuzione in una macchina virtuale.
Per eseguire un traceflow di un pacchetto che passa attraverso un segmento secondario, è necessario utilizzare l'API. Per configurare un traceflow, utilizzare la chiamata API PUT https://<mgr-ip>/policy/api/v1/infra/traceflows/<traceflow-id>
. Ad esempio,
PUT https://<mgr-ip>/policy/api/v1/infra/traceflows/<traceflow-id> { "segment_port_path": "/infra/segments/parent/ports/default:658c6c45-286f-4a23-832f-a646253b200b", "connected_segment_path_as_source": "/infra/segments/child", "packet": { "eth_header": { "src_mac": "00:50:56:ad:28:d5", "dst_mac": "00:50:56:ad:c0:a4", "eth_type": 2048 }, "ip_header": { "src_ip": "192.168.100.10", "dst_ip": "192.168.100.20", "protocol": 1, "ttl": 64, "flags": 0 }, "transport_header": { "icmp_echo_request_header": { "id": 0, "sequence": 0 } }, "payload": "", "resource_type": "FieldsPacketData", "frame_size": 128, "routed": false, "transport_type": "UNICAST" }, "timeout": 10, "is_transient": true }
Si tenga presente che il parametro connected_segment_path_as_source punta al segmento secondario. Se questo parametro non è impostato, il pacchetto non passerà attraverso il segmento secondario.
Per ulteriori informazioni, vedere la Guida di NSX API (passare alla documentazione di NSX e utilizzare il riquadro di navigazione a sinistra per individuare la guida dell'API).
Statistiche del segmento secondario e del segmento principale
Le statistiche per un segmento secondario includeranno solo le statistiche per le macchine virtuali connesse a tale segmento. Non includeranno le statistiche per i container Antrea.
Per un segmento principale, le statistiche di ingresso includeranno le statistiche per i container Antrea. Le statistiche di uscita non includeranno le statistiche per i container Antrea.