È 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.

Nota: Questa funzionalità è disponibile solo tramite l'API.

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.

Proprietà dei segmenti secondario e principale:
  • 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
Configurazione mirroring (span uplink)
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.

Workflow per la creazione di una connessione tra un segmento principale e un segmento secondario:
  • 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.
Workflow per l'eliminazione di un segmento secondario:
  • 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.
Workflow per l'eliminazione di un segmento principale:
  • 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:

Richiesta API:
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"
}
Risposta API:
{
  "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

Traceflow supporta i seguenti scenari relativi ai segmenti secondari:
  • 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.