Puede crear segmentos secundarios para habilitar IPAM, enrutamiento y NAT avanzados para cargas de trabajo de Kubernetes con Antrea. Los segmentos secundarios están diseñados para admitir funciones de Antrea, como IPAM flexible de pods enrutables y Egress de Antrea.

Nota: Esta función solo está disponible a través de la API.

El siguiente diagrama muestra cómo se conectan los segmentos secundarios a otros componentes.

Un segmento principal es un segmento de NSX normal. No se requiere ninguna configuración para convertir un segmento en un segmento principal. Un segmento secundario está asociado a uno o varios segmentos principales y se le asigna un identificador de VLAN para cada uno de sus segmentos principales. Un segmento principal solo enviará un tráfico de segmentos secundarios que esté etiquetado con el identificador de VLAN específico.

Propiedades de los segmentos secundarios y principales:
  • Un segmento secundario puede estar asociado con varios segmentos principales.
  • Un segmento principal puede tener varios segmentos secundarios.
  • Cada segmento secundario vinculado a un segmento principal debe tener un identificador de VLAN distinto, y ningún segmento secundario conectado al mismo segmento principal puede compartir su identificador de VLAN.
  • Un segmento secundario que se conecta a varios segmentos principales puede utilizar el mismo identificador de VLAN o uno diferente para estas conexiones.
  • Un segmento secundario no puede ser el segmento principal de otro segmento secundario.
  • Un segmento secundario puede ser un segmento de superposición o un segmento de VLAN.
  • Las máquinas virtuales (VM) pueden conectarse a segmentos secundarios. Cuando lo hacen, se crea un puerto de segmento, similar a cuando una máquina virtual está conectada a un segmento estándar.
  • No se crea ningún puerto de segmento en el segmento secundario para la conexión entre segmentos principales y secundarios.
  • Los segmentos secundarios y los segmentos principales son independientes. Eso significa que:
    • Pueden conectarse a la misma puerta de enlace de nivel 1 o nivel 0 o a otras diferentes.
    • Pueden tener diferentes configuraciones o perfiles de conmutación.
    • Sus segmentos secundarios no heredan las configuraciones en un segmento principal.
    • Un grupo que incluye un segmento principal no incluye automáticamente sus segmentos secundarios.
    • Los servicios configurados en un segmento principal, como un firewall distribuido, no se extienden a los segmentos secundarios.

Para las máquinas virtuales conectadas a un segmento secundario, se admiten todas las funciones relacionadas con segmentos. En la siguiente tabla se especifican las funciones compatibles y no compatibles para el tráfico de contenedor que pasa a través de un segmento secundario:

Función Compatible
Firewall distribuido No
Perfil de segmentos de detección de IP No
Perfil de segmentos de detección de MAC No
Perfil de seguridad de segmentos No
Perfil de segmentos de SpoofGuard No
Perfil de segmentos de calidad de servicio No
Reflejo del puerto No
IPFix No
Formación de equipos de vínculo superior Sí
Configuración de creación de reflejo (alcance de vínculo superior) Sí
NSGroup No
Latencia No

Uso de segmentos secundarios con Antrea

Cada subred enrutable (por ejemplo, grupos de direcciones IP para pods enrutables y grupos de direcciones IP externas para salida) configuradas en Antrea se asigna a un segmento secundario, y los segmentos de las máquinas virtuales del nodo de Kubernetes son los segmentos principales del segmento secundario. OVS (Open vSwitch) en la máquina virtual del nodo de Kubernetes etiquetará el tráfico con el identificador de VLAN correcto antes de enviar los paquetes a través de la VNIC.

Flujo de trabajo para crear una conexión entre un segmento principal y un segmento secundario:
  • Cree el segmento principal. Puede utilizar la API o la interfaz de usuario de NSX Manager.
  • Cree el segmento secundario. Puede utilizar la API o la interfaz de usuario de NSX Manager.
  • Utilice la API para crear una asignación de enlace de conexión en el segmento secundario especificando la ruta del segmento principal y el identificador de VLAN.
Flujo de trabajo para eliminar un segmento secundario:
  • Utilice la API para eliminar todas las asignaciones de enlace de conexión existentes del segmento secundario.
  • Elimine el segmento secundario. Puede utilizar la API o la interfaz de usuario de NSX Manager.
Flujo de trabajo para eliminar un segmento principal:
  • Utilice la API para eliminar todas las asignaciones de enlace de conexión existentes que conectan este segmento principal a todos sus segmentos secundarios.
  • Elimine el segmento principal. Puede utilizar la API o la interfaz de usuario de NSX Manager.

API

Las siguientes llamadas API se pueden utilizar para administrar segmentos secundarios. Para obtener más información, consulte la Guía de NSX API (vaya a Documentación de NSX y utilice el panel de navegación de la izquierda para localizar la guía de la 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}

Al crear una asignación de enlace de conexión, el identificador de asignación que especifique en la API PUT debe ser único. Ejemplo de uso de PUT /policy/api/v1/infra/segments/{segment-id}/segment-connection-binding-maps/{map-id} para crear una asignación de enlaces:

Solicitud de la 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"
}
Respuesta de la 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 admite los siguientes escenarios relacionados con segmentos secundarios:
  • El origen es un contenedor en un segmento secundario y el destino es un contenedor en un segmento secundario.
  • El origen es un contenedor en un segmento secundario y el destino es un puerto normal.
  • El origen es un puerto principal. No hay ningún segmento secundario porque los contenedores de Antrea se ejecutan dentro de una máquina virtual.

Para realizar una instancia de Traceflow de un paquete que pasará a través de un segmento secundario, debe utilizar la API. Para configurar una instancia de Traceflow, utilice la llamada API PUT https://<mgr-ip>/policy/api/v1/infra/traceflows/<traceflow-id>. Por ejemplo,

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
}

Tenga en cuenta que el parámetro connected_segment_path_as_source apunta al segmento secundario. Si no se establece este parámetro, el paquete no pasará por el segmento secundario.

Para obtener más información, consulte la Guía de NSX API (vaya a Documentación de NSX y utilice el panel de navegación de la izquierda para localizar la guía de la API).

Estadísticas de segmentos secundarios y principales

Las estadísticas de un segmento secundario solo incluirán estadísticas de las máquinas virtuales que están conectadas al segmento. No incluirán estadísticas para los contenedores de Antrea.

Para un segmento principal, las estadísticas de entrada incluirán estadísticas para los contenedores de Antrea. Las estadísticas de salida no incluirán estadísticas para los contenedores de Antrea.