Configura balanceadores de cargas agrupados con BGP

En este documento, se describe cómo configurar y usar los balanceadores de cargas en paquetes con el protocolo de puerta de enlace fronteriza (BGP) para clústeres de Anthos en equipos físicos. Este modo de balanceo de cargas admite el anuncio de direcciones IP virtuales (VIP) ServiceType LoadBalancer a través del protocolo de puerta de enlace fronteriza externa (eBGP) para tus clústeres. En esta situación, la red de tu clúster es un sistema autónomo, que se interconecta con otro sistema autónomo, una red externa, a través del intercambio de tráfico.

Los balanceadores de cargas en paquetes con capacidad BGP se aplican a todos los tipos de clústeres, pero los clústeres de administrador solo admiten la parte del balanceo de cargas del plano de control que forma parte de esta capacidad.

El uso de balanceadores de cargas en paquetes con la función de BGP proporciona los siguientes beneficios:

  • Usa la capacidad de balanceo de cargas activo/activo de N-way, lo que proporciona una conmutación por error más rápida y un uso más eficiente del ancho de banda disponible.
  • Admite el protocolo de capa 3 que interopera con routers y switches top-of-rack (ToR) de terceros que son compatibles con eBGP.
  • Habilita los centros de datos que ejecutan una pila de red definida software (SDN) avanzada para empujar el límite de la Capa 3 hasta los clústeres.

Cómo funciona el balanceo de cargas en paquetes con BGP

En las siguientes secciones, se proporciona un resumen rápido del funcionamiento de los balanceadores de cargas en paquetes con BGP.

Intercambio de tráfico de BGP

Los balanceadores de cargas en paquetes con la función de BGP inicia varias conexiones de BGP a tu infraestructura. BGP tiene los siguientes requisitos técnicos:

  • Las sesiones de intercambio de tráfico son independientes para las VIP del plano de control y las del servicio.
  • Las sesiones de intercambio de tráfico del plano de control se inician desde las direcciones IP de los nodos del plano de control.
  • Las sesiones de intercambio de tráfico de servicio se inician a partir de las direcciones IP flotantes que especifiques en el recurso personalizado de AnthosNetworkGateway.
  • El controlador de puerta de enlace de red de Anthos administra las direcciones IP flotantes.
  • El balanceo de cargas en paquetes basado en BGP solo es compatible con el intercambio de tráfico eBGP.
  • El intercambio de tráfico entre saltos es compatible de forma predeterminada.
  • Las contraseñas MD5 en sesiones de BGP no son compatibles.
  • Las sesiones de intercambio de tráfico basadas en IPv6 no son compatibles.
  • Se espera que las rutas anunciadas a cualquier intercambio de tráfico se redistribuyan en toda la red y se pueda acceder a ellas desde cualquier otro lugar del clúster.
  • Se recomienda el uso de la capacidad ADD-PATH de BGP en el modo de recepción para las sesiones de intercambio de tráfico.
  • Anunciar varias rutas de acceso de cada intercambio de tráfico genera un balanceo de cargas activo/activo.
  • El enrutamiento de varias rutas de igual costo (ECMP) debe estar habilitado para tu red a fin de que se puedan usar varias rutas para distribuir el tráfico entre un conjunto de nodos del balanceador de cargas.

Balanceo de cargas del plano de control

Cada nodo del plano de control en tu clúster establece sesiones de BGP con uno o más intercambios de tráfico en tu infraestructura. Necesitamos que cada nodo del plano de control tenga al menos un intercambio de tráfico. En el archivo de configuración del clúster, puedes configurar qué nodos del plano de control se conectan a qué intercambios de tráfico externos.

En el siguiente diagrama, se muestra un ejemplo del intercambio de tráfico del plano de control. El clúster tiene dos nodos del plano de control en una subred y uno en otra. Hay un intercambio de tráfico externo (TOR) en cada subred y los clústeres de Anthos en los nodos del plano de control de equipos físicos intercambian tráfico con el TOR.

Balanceo de cargas de servicios con intercambio de tráfico de BGP

Balanceo de cargas de servicios

Además de las sesiones de intercambio de tráfico que se inician desde cada nodo del plano de control para este intercambio de tráfico del plano de control, se inician sesiones de intercambio de tráfico adicionales para los servicios LoadBalancer. Estas sesiones de intercambio de tráfico no se inician directamente desde las IP de nodo de clúster, en su lugar, usan IP flotantes.

No se admiten los servicios con una política de red externalTrafficPolicy=Local.

Direcciones IP flotantes

El balanceo de cargas de servicios requiere que reserves direcciones IP flotantes en las subredes del nodo del clúster para usar en el intercambio de tráfico de BGP. Se requiere al menos una dirección IP flotante para el clúster, pero te recomendamos reservar al menos dos direcciones a fin de garantizar una alta disponibilidad para las sesiones de BGP. Las direcciones IP flotantes se especifican en el recurso personalizado de (CR) AnthosNetworkGateway, que se puede incluir en el archivo de configuración del clúster.

Las direcciones IP flotantes eliminan la preocupación de asignar direcciones IP de interlocutores de BGP a los nodos. El controlador de la puerta de enlace de red de Anthos se encarga de asignar AnthosNetworkGateway a los nodos y también administra las direcciones IP flotantes. Si un nodo falla, el controlador de la puerta de enlace de red de Anthos reasigna las direcciones IP flotantes para garantizar que los pares externos tengan una dirección IP determinista con la que intercambiar tráfico.

Intercambios de tráfico externos

Especifica los intercambios de tráfico externos que se usan para sesiones de intercambio de tráfico con las direcciones IP flotantes en el recurso personalizado BGPLoadBalancer, que agregas al archivo de configuración del clúster. Los intercambios de tráfico externos pueden ser iguales que se especificaron para el intercambio de tráfico del plano de control en la sección loadBalancer.controlPlaneBGP del archivo de configuración del clúster o puedes especificar diferentes intercambios de tráfico.

El controlador de la puerta de enlace de red de Anthos intenta establecer dos sesiones para cada par externo del conjunto de direcciones IP flotantes reservadas. Te recomendamos que especifiques al menos dos pares externos a fin de garantizar una alta disponibilidad para las sesiones de BGP. Cada par externo designado para el balanceo de cargas de servicios debe configurarse para intercambiar tráfico con cada dirección IP flotante especificada en el recurso personalizado AnthosNetworkGateway.

Nodos del balanceador de cargas

Se usa un subconjunto de nodos para el balanceo de cargas, lo que significa que son los nodos que se anuncian a fin de aceptar el tráfico de balanceo de cargas entrante. Este conjunto de nodos se establece de forma predeterminada en el grupo de nodos del plano de control, pero puedes especificar un grupo de nodos diferente en la sección loadBalancer del archivo de configuración del clúster. Si especificas un grupo de nodos, se usa para los nodos del balanceador de cargas, en lugar del grupo de nodos del plano de control.

Las direcciones IP flotantes, que funcionan como interlocutores de BGP, pueden o no ejecutarse en los nodos del balanceador de cargas. Las direcciones IP flotantes se asignan a un nodo en la misma subred y el intercambio de tráfico se inicia desde allí, sin importar si es un nodo del balanceador de cargas. Sin embargo, los saltos siguientes que se anuncian a través de BGP siempre son los nodos del balanceador de cargas.

Topología de intercambio de tráfico de ejemplo

En el siguiente diagrama, se muestra un ejemplo de balanceo de cargas de servicio con intercambio de tráfico de BGP. Hay dos direcciones IP flotantes asignadas a nodos en sus respectivas subredes. Hay dos pares externos definidos. Cada IP flotante intercambia tráfico con ambos pares externos.

Balanceo de cargas de servicios con intercambio de tráfico de BGP

Configura el balanceador de cargas de BGP

En las siguientes secciones, se describe cómo configurar los clústeres y la red externa para usar el balanceador de cargas en paquetes con BGP.

Planifica tu integración con infraestructura externa

Para usar el balanceador de cargas en paquetes con BGP, debes configurar la infraestructura externa:

  • La infraestructura externa se debe configurar para intercambiar tráfico con cada uno de los nodos del plano de control en el clúster a fin de configurar la comunicación del plano de control. Estas sesiones de intercambio de tráfico se usan para anunciar las VIP del plano de control de Kubernetes.

  • La infraestructura externa debe configurarse para intercambiar tráfico con un conjunto de direcciones IP flotantes reservadas para la comunicación del plano de datos. Las direcciones IP flotantes se usan para el intercambio de tráfico de BGP en las VIP del servicio. Te recomendamos usar dos direcciones IP flotantes y dos pares a fin de garantizar una alta disponibilidad para sesiones de BGP. El proceso de reserva de una IP flotante se describe como parte de la configuración del clúster para el balanceo de cargas en paquetes con BGP.

Cuando hayas configurado la infraestructura, agrega la información de intercambio de tráfico de BGP al archivo de configuración del clúster. El clúster que creas puede iniciar sesiones de intercambio de tráfico con la infraestructura externa.

Configura tu clúster para el balanceo de cargas en paquetes con BGP

Puedes habilitar y configurar el balanceo de cargas en paquetes con BGP en el archivo de configuración del clúster cuando creas un clúster.

  1. Agrega la anotación baremetal.cluster.gke.io/enable-anthos-network-gateway al archivo de configuración del clúster y configúrala como true.

    Esta anotación habilita el controlador de puerta de enlace de Anthos.

    apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
  # This annotation is required for BGP load balancer
  annotations:
    baremetal.cluster.gke.io/enable-anthos-network-gateway: "true"
spec:
...

  2. En la sección loadBalancer del archivo de configuración del clúster, configura mode como bundled y agrega un campo type con el valor bgp.

    Estos valores de campo permiten el balanceo de cargas en paquetes basado en BGP.

    ...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp
    ...

  3. Para especificar la información de intercambio de tráfico de BGP para el plano de control, agrega los siguientes campos a la sección loadBalancer:

        ...
    # AS number for the cluster
    localASN: CLUSTER_ASN

    # List of BGP peers used for the control plane peering sessions.
    bgpPeers:
    - ip: PEER_IP
      asn: PEER_ASN
      # optional; if not specified, all CP nodes connect to all peers.
      controlPlaneNodes:   # optional
      - CP_NODE_IP
...

    Reemplaza lo siguiente:

    • CLUSTER_ASN: el número del sistema autónomo para el clúster que se crea.
    • PEER_IP: Es la dirección IP del dispositivo de intercambio de tráfico externo.
    • PEER_ASN: El número del sistema autónomo para la red que contiene el dispositivo de intercambio de tráfico externo.
    • CP_NODE_IP: es la dirección IP del nodo del plano de control que se conecta al par externo (opcional). Si no especificas ningún nodo del plano de control, todos los nodos del plano de control pueden conectarse al par externo. Si especificas una o más direcciones IP, solo los nodos especificados participan en las sesiones de intercambio de tráfico.

    Puedes especificar varios intercambios de tráfico externos, bgpPeers toma una lista de asignaciones. Te recomendamos que especifiques al menos dos intercambios de tráfico externos para la alta disponibilidad de las sesiones de BGP. Para ver un ejemplo con varios intercambios de tráfico, consulta Ejemplos de configuración.

    Esta configuración de intercambio de tráfico de BGP para el plano de control no se puede actualizar después de que se crea el clúster.

  4. Establece los campos loadBalancer.ports, loadBalancer.vips y loadBalancer.addressPools (se muestran los valores predeterminados).

    ...
  loadBalancer:
  ...
    # Other existing load balancer options remain the same
    ports:
      controlPlaneLBPort: 443
    # When type=bgp, the VIPs are advertised over BGP
    vips:
      controlPlaneVIP: 10.0.0.8
      ingressVIP: 10.0.0.1

    addressPools:
    - name: pool1
      addresses:
      - 10.0.0.1-10.0.0.4
...

  5. Especifica el nodo del clúster que se usará para balancear las cargas del plano de datos.

    Este paso es opcional. Si no quitas el comentario de la sección nodePoolSpec, los nodos del plano de control se usan para el balanceo de cargas del plano de datos.

    ...
  # Node pool used for load balancing data plane (nodes where incoming traffic
  # arrives. If not specified, this defaults to the control plane node pool.
  # nodePoolSpec:
  #   nodes:
  #   - address: <Machine 1 IP>
...

  6. Reserva direcciones IP flotantes mediante la configuración del recurso personalizado AnthosNetworkGateway:

    Las direcciones IP flotantes se usan en las sesiones de intercambio de tráfico para el balanceo de cargas del plano de datos.

    ...
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: CLUSTER_NAMESPACE
spec:
  floatingIPs:
  - FLOATING_IP
...

    Reemplaza lo siguiente:

    • CLUSTER_NAMESPACE: es el espacio de nombres para el clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos en equipos físicos son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test al clúster, el espacio de nombres será cluster-test.
    • FLOATING_IP: es una dirección IP de una de las subredes del clúster. Debes especificar al menos una dirección IP, pero te recomendamos que especifiques al menos dos direcciones IP.

    Para ver un ejemplo de cómo podría verse la especificación de recursos personalizados AnthosNetworkGateway, consulta Configuraciones de ejemplo.

  7. Especifica la información de intercambio de tráfico de BGP para el plano de datos mediante la configuración del recurso personalizado BGPLoadBalancer:

    ...
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: CLUSTER_NAMESPACE
spec:
  localASN: CLUSTER_ASN
  peers:
  - peerIP: PEER_IP
    peerASN: PEER_ASN
    ...

    Reemplaza lo siguiente:

    • CLUSTER_NAMESPACE: es el espacio de nombres para el clúster. De forma predeterminada, los espacios de nombres de los clústeres de Anthos en equipos físicos son el nombre del clúster precedido por cluster-. Por ejemplo, si le asignas el nombre test al clúster, el espacio de nombres será cluster-test.
    • CLUSTER_ASN: el número del sistema autónomo para el clúster que se crea.
    • PEER_IP: Es la dirección IP del dispositivo de intercambio de tráfico externo. Debes especificar al menos un intercambio de tráfico externo, pero te recomendamos que especifiques al menos dos. Puedes usar los mismos intercambios de tráfico que se especificaron en el plano de control.
    • PEER_ASN: El número del sistema autónomo para la red que contiene el dispositivo de intercambio de tráfico externo.

    Puedes especificar varios intercambios de tráfico externos; peers toma una lista de intercambios de tráfico de asignación. Te recomendamos que especifiques al menos dos intercambios de tráfico externos para la alta disponibilidad de las sesiones de BGP. Para ver un ejemplo con varios intercambios de tráfico, consulta Ejemplos de configuración.

  8. Cuando ejecutas bmctl cluster create para crear tu clúster, se ejecutan las comprobaciones previas. Entre otras comprobaciones, las comprobaciones previas validan la configuración del intercambio de tráfico de BGP para el plano de control y, luego, informan cualquier problema directamente a la estación de trabajo de administrador antes de que se pueda crear el clúster.

Te recomendamos que uses la capacidad ADD-PATH de BGP para las sesiones de intercambio de tráfico, como se especifica en RFC 7911. De forma predeterminada, el protocolo BGP permite que solo se anuncie un siguiente salto a los pares para un solo prefijo. El ADD-PATH de BGP permite anunciar varios saltos siguientes para el mismo prefijo. Cuando ADD-PATH se usa con el balanceo de cargas en paquetes basado en BGP, el clúster puede anunciar varios nodos del clúster como nodos de frontend (saltos siguientes) para un servicio de balanceador de cargas (prefijo). Habilita ECMP en la red para que el tráfico pueda distribuirse a través de varias rutas. La capacidad de fan-out del tráfico mediante la publicidad de varios nodos del clúster como siguientes saltos proporciona un escalamiento mejorado de la capacidad del plano de datos para el balanceo de cargas.

Si el dispositivo de intercambio de tráfico externo, como un switch o router top-of-rack (ToR) admite BGP ADD-PATH, solo es suficiente activar la extensión de recepción. El balanceo de cargas en paquetes con BGP funciona sin la capacidad ADD-PATH, pero la restricción de anunciar un solo nodo de balanceo de cargas por sesión de intercambio de tráfico limita la capacidad del plano de datos del balanceador de cargas. Sin ADD-PATH, los clústeres de Anthos en equipos físicos eligen nodos para anunciar desde el grupo de nodos del balanceador de cargas e intentan distribuir los saltos siguientes para diferentes VIP en diferentes nodos.

Restringe el intercambio de tráfico de BGP a los nodos del balanceador de cargas

En la versión de vista previa de esta característica, los clústeres de Anthos en equipos físicos asignan las direcciones IP flotantes de forma automática en cualquier nodo de la misma subred que la dirección IP flotante. Las sesiones de BGP se inician desde estas direcciones IP, incluso si no llegan a los nodos del balanceador de cargas. Este comportamiento es de diseño porque desacoplamos el plano de control (BGP) del plano de datos (grupos de nodos de LB).

Si deseas restringir el conjunto de nodos que pueden usarse para el intercambio de tráfico de BGP, puedes designar una subred que se usará solo para los nodos del balanceador de cargas. Es decir, puedes configurar todos los nodos de esa subred en el grupo de nodos del balanceador de cargas. Luego, cuando configures las direcciones IP flotantes que se usan para el intercambio de tráfico de BGP, asegúrate de que provengan de esta misma subred. Los clústeres de Anthos en equipos físicos garantizan que las asignaciones de direcciones IP flotantes y el intercambio de tráfico de BGP se realicen solo desde los nodos del balanceador de cargas.

Configuración de ejemplo

En las siguientes secciones, se muestra cómo configurar el balanceo de cargas basado en BGP para diferentes opciones o comportamientos.

Configura todos los nodos para que usen los mismos intercambios de tráfico

Como se muestra en el siguiente diagrama, esta configuración da como resultado un conjunto de intercambios de tráfico externos (10.8.0.10 y 10.8.0.11) a los que pueden acceder todos los nodos. Los nodos del plano de control (10.0.1.10, 10.0.1.11 y 10.0.2.10) y las direcciones IP flotantes (10.0.1.100 y 10.0.2.100) asignadas a los nodos del plano de datos llegan a los intercambios de tráfico.

Se puede acceder a los mismos intercambios de tráfico externos mediante las direcciones IP flotantes (10.0.1.100 o 10.0.2.100) que se reservan para el intercambio de tráfico de servicios loadBalancer. Las direcciones IP flotantes se pueden asignar a nodos que están en la misma subred.

Balanceo de cargas de BGP en el que todos los nodos usan los mismos intercambios de tráfico

Como se muestra en la siguiente muestra de configuración del clúster, configuras los intercambios de tráfico para los nodos del plano de control, bgpPeers, sin especificar controlPlaneNodes. Cuando no se especifican nodos para los intercambios de tráfico, todos los nodos del plano de control se conectan a todos los intercambios de tráfico.

Especifica las direcciones IP flotantes que se usarán para las sesiones de intercambio de tráfico de balanceo de cargas de los servicios en el recurso personalizado AnthosNetworkGateway. Especifica los intercambios de tráfico externos correspondientes en el recurso BGPLoadBalancer.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.8.0.10
      asn: 65002
    - ip: 10.8.0.11
      asn: 65002

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
metadata:
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.8.0.10
    peerASN: 65002
  - peerIP: 10.8.0.11
    peerASN: 65002

Configura nodos de plano de control específicos para que intercambien tráfico con intercambios de tráfico externos específicos

Como se muestra en el siguiente diagrama, esta configuración genera dos nodos del plano de control (10.0.1.10 y 10.0.1.11) intercambien tráfico con un par externo (10.0.1.254). El tercer nodo del plano de control (10.0.2.10) intercambia tráfico con otro par externo (10.0.2.254). Esta configuración es útil cuando no quieres que todos los nodos se conecten a todos los pares. Por ejemplo, es posible que desees que los nodos del plano de control intercambien tráfico solo con los switches top-of-rack (ToR) correspondientes.

Se puede acceder a los mismos pares externos mediante las direcciones IP flotantes (10.0.1.100 o 10.0.2.100) que están reservan para sesiones de intercambio de tráfico de balanceo de cargas de servicios. Las direcciones IP flotantes se pueden asignar a nodos que se encuentran en la misma subred.

Balanceo de cargas de BGP con asignación explícita de nodos del plano de control a intercambios de tráfico

Como se muestra en la siguiente muestra de configuración del clúster, debes restringir qué nodos del plano de control pueden conectarse a un intercambio de tráfico determinado si especificas sus direcciones IP en el campo controlPlaneNodes del intercambio de tráfico en la sección bgpPeers.

Especifica las direcciones IP flotantes que se usarán para las sesiones de intercambio de tráfico de balanceo de cargas de los servicios en el recurso personalizado AnthosNetworkGateway. Especifica los intercambios de tráfico externos correspondientes en el recurso BGPLoadBalancer.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.10

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.1.100
  - 10.0.2.100
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
metadata:
  name: bgplb
  namespace: cluster-bm
spec:
  localASN: 65001
  peers:
  - peerIP: 10.0.1.254
    peerASN: 65002
  - peerIP: 10.0.2.254
    peerASN: 65002

Configura el plano de control y el plano de datos por separado

Como se muestra en el siguiente diagrama, esta configuración da como resultado dos nodos de plano de control (10.0.1.10 y 10.0.1.11) que intercambian tráfico con un par externo (10.0.1.254) y el tercer nodo del plano de control (10.0.2.10) intercambia tráfico con otro par externo (10.0.2.254).

Se puede acceder a un tercer intercambio de tráfico externo (10.0.3.254) mediante cualquiera de las direcciones IP flotantes (10.0.3.100 o 10.0.3.101) que están reservadas para las sesiones de intercambio de tráfico de balanceo de cargas de servicios. Las direcciones IP flotantes se pueden asignar a nodos que se encuentran en la misma subred.

Balanceo de cargas de BGP con configuración independiente para el plano de control y el plano de datos

Como se muestra en la siguiente muestra de configuración del clúster, debes restringir qué nodos del plano de control pueden conectarse a un intercambio de tráfico determinado si especificas sus direcciones IP en el campo controlPlaneNodes del intercambio de tráfico en la sección bgpPeers.

Especifica las direcciones IP flotantes que se usarán para las sesiones de intercambio de tráfico de balanceo de cargas de los servicios en el recurso personalizado AnthosNetworkGateway. Especifica los intercambios de tráfico externos correspondientes en el recurso BGPLoadBalancer.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: bm
  namespace: cluster-bm
spec:
...
  loadBalancer:
    mode: bundled

    # type can be 'bgp' or 'layer2'. If no type is specified, we default to layer2.
    type: bgp

    # AS number for the cluster
    localASN: 65001

    bgpPeers:
    - ip: 10.0.1.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.1.10
        - 10.0.1.11
    - ip: 10.0.2.254
      asn: 65002
      controlPlaneNodes:
        - 10.0.2.11

... (other cluster config omitted)
---
apiVersion: networking.gke.io/v1alpha1
kind: AnthosNetworkGateway
  name: default
  namespace: cluster-bm
spec:
  floatingIPs:
  - 10.0.3.100
  - 10.0.3.101
---
apiVersion: networking.gke.io/v1alpha1
kind: BGPLoadBalancer
  name: bgplb
  namespace: cluster-bm
spec:
  bgp:
    localASN: 65001
    peers:
    - peerIP: 10.0.3.254
      peerASN: 65002

Modifica tu configuración de balanceo de cargas basado en BGP

Después de crear el clúster configurado para usar el balanceo de cargas en paquetes con BGP, se pueden actualizar algunos parámetros de configuración, pero no se pueden actualizar algunos después de la creación del clúster.

Plano de control

Las modificaciones en la configuración del balanceo de cargas del plano de control no se admiten durante la vista previa.

Servicios

Puedes modificar la configuración del intercambio de tráfico de BGP después de crear el clúster si editas el CR de AnthosNetworkGateway y el CR de BGPLoadBalancer. Cualquier modificación en la información de intercambio de tráfico en estos CR se refleja en la configuración de la solución de balanceo de cargas en el clúster de destino.

Realiza actualizaciones en los recursos de origen en el espacio de nombres del clúster solo en el clúster de administrador. Se reemplazan todas las modificaciones realizadas en los recursos del clúster objetivo (usuario).

Solucionar problemas

En las siguientes secciones, se describe cómo acceder a la información de solución de problemas para el balanceo de cargas en paquetes con BGP.

Sesiones de BGP del plano de control

La configuración de intercambio de tráfico de BGP del plano de control se valida con comprobaciones previas durante la creación del clúster. Las comprobaciones previas intentan realizar lo siguiente:

  • Establecer una conexión BGP con cada par.
  • Anunciar la VIP del plano de control.
  • Verificar que se pueda acceder al nodo del plano de control mediante la VIP.

Si la creación de tu clúster falla en las comprobaciones previas, revisa los registros de las comprobaciones previas en busca de errores. Los archivos de registro de comprobaciones previas con marca de fecha se encuentran en el directorio baremetal/bmctl-workspace/CLUSTER_NAME/log.

En el entorno de ejecución, los hablantes de BGP del plano de control se ejecutan como pods estáticos en cada nodo del plano de control y escriben información de eventos en los registros. Estos pods estáticos incluyen “bgpadvertiser” en su nombre, por lo que debes usar el siguiente comando kubectl get pods para ver el estado de los pods del hablante de BGP:

kubectl -n kube-system  get pods | grep bgpadvertiser

Cuando los pods funcionan de forma correcta, la respuesta debería ser similar a la siguiente:

bgpadvertiser-node-01                            1/1     Running   1          167m
bgpadvertiser-node-02                            1/1     Running   1          165m
bgpadvertiser-node-03                            1/1     Running   1          163m

Usa el siguiente comando para ver los registros del Pod bgpadvertiser-node-01:

kubectl -n kube-system  logs bgpadvertiser-node-01

Sesiones de BGP de servicios

El recurso BGPSession proporciona información sobre las sesiones de BGP actuales. Para obtener información sobre la sesión, primero obtén las sesiones actuales y, luego, recupera el recurso BGPSession de una de las sesiones.

Usa el siguiente comando kubectl get para enumerar las sesiones actuales:

kubectl -n kube-system get bgpsessions

El comando muestra una lista de sesiones como el siguiente ejemplo:

NAME                            AGE
10.0.1.254-node-01              170m
10.0.1.254-node-05              170m
10.0.3.254-node-01              170m
10.0.3.254-node-05              170m

Usa el siguiente comando de kubectl describe a fin de obtener el recurso BGPSession para la sesión de BGP de 10.0.1.254-node-01:

kubectl -n kube-system describe bgpsession 10.0.1.254-node-01

El recurso BGPSession que se muestra debería ser similar al siguiente ejemplo:

Name:         10.0.1.254-node-01
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1alpha1
Kind:         BGPSession
Metadata:
 (omitted)
Spec:
  Floating IP:  10.0.1.178
  Local ASN:    65500
  Local IP:     10.0.1.178
  Node Name:    node-01
  Peer ASN:     65000
  Peer IP:      10.0.1.254
Status:
  Advertised Routes:
    10.0.4.1/32
  Last Report Time:  2021-06-14T22:09:36Z
  State:             Established

Usa el comando de kubectl get para obtener los recursos BGPAdvertisedRoute:

kubectl -n kube-system get bgpadvertisedroutes

La respuesta, que debería ser similar al siguiente ejemplo, muestra las rutas que se anuncian en este momento:

NAME                                  AGE
bgplb-default-load-balancer-example   5d5h
bgplb-gke-system-istio-ingress        6d

Usa kubectl describe para ver los detalles sobre qué saltos siguientes se anuncian en cada ruta.

Verificación de BGP manual

En esta sección, se incluyen instrucciones para verificar la configuración de BGP de forma manual. El procedimiento configura una conexión de BGP de larga duración para que puedas depurar aún más la configuración de BGP con tu equipo de redes. Usa este procedimiento para verificar la configuración antes de crear un clúster o úsalo si las verificaciones previas relacionadas con BGP fallan.

Las comprobaciones previas automatizan las siguientes tareas de verificación de BGP:

  • Configurar una conexión de BGP a un par.
  • Anunciar la VIP del plano de control.
  • Verificar que el tráfico enviado de todos los demás nodos del clúster a la VIP llegue al nodo del balanceador de cargas actual.

Estas tareas se ejecutan para cada par de BGP en cada nodo del plano de control. Pasar estas verificaciones es fundamental cuando se crea un clúster. Sin embargo, las verificaciones previas no crean conexiones de larga duración, por lo que es difícil depurar una falla.

En las siguientes secciones, se proporcionan instrucciones para configurar una conexión de BGP y anunciar una ruta desde una máquina de un solo clúster a un par. Para probar múltiples máquinas y pares, repite las instrucciones con una combinación diferente de máquina y par.

Recuerda que las conexiones de BGP se establecen desde los nodos del plano de control, por lo que debes asegurarte de probar este procedimiento desde uno de tus nodos planificados del plano de control.

Obtén el objeto binario del programa de prueba de BGP

Ejecuta los pasos que se indican en esta sección en la estación de trabajo del administrador. Con estos pasos, se obtiene el programa bgpadvertiser que se usa para probar las conexiones de BGP y se copia en los nodos del plano de control en los que deseas realizar pruebas.

  1. Extrae la imagen de Docker de ansible-runner.

    Sin duplicación de registro

    Si no usas una duplicación de registro, ejecuta los siguientes comandos para extraer la imagen de Docker de ansible-runner:

    gcloud auth login
gcloud auth configure-docker
docker pull gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Con duplicación de registro

    Si usas una duplicación del registro, ejecuta los siguientes comandos para extraer la imagen de Docker de ansible-runner:

    docker login REGISTRY_HOST
docker pull REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13

    Reemplaza REGISTRY_HOST por el nombre de tu servidor de duplicación de registro.

  2. Para extraer el objeto binario bgpadvertiser.

    Sin duplicación de registro

    Para extraer el objeto binario bgpadvertiser, ejecuta el siguiente comando:

    docker cp $(docker create gcr.io/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

    Con duplicación de registro

    Para extraer el objeto binario bgpadvertiser, ejecuta el siguiente comando:

    docker cp $(docker create REGISTRY_HOST/anthos-baremetal-release/ansible-runner:1.10.0-gke.13):/bgpadvertiser .

  3. Para copiar el objeto binario bgpadvertiser en el nodo del plano de control con el que deseas realizar pruebas, ejecuta el siguiente comando:

    scp bgpadvertiser USERNAME>@CP_NODE_IP:/tmp/

    Reemplaza lo siguiente:

    • USERNAME: El nombre de usuario que usas para acceder al nodo del plano de control.

    • CP_NODE_IP: La dirección IP del nodo del plano de control.

Configura una conexión de BGP

Ejecuta los pasos de esta sección en un nodo del plano de control.

  1. Crea un archivo de configuración en el nodo en /tmp/bgpadvertiser.conf que se vea así:

    localIP: NODE_IP
localASN: CLUSTER_ASN
peers:
- peerIP: PEER_IP
  peerASN: PEER_ASN

    Reemplaza lo siguiente:

    • NODE_IP: Dirección IP del nodo del plano de control en el que te encuentras.
    • CLUSTER_ASN: El número del sistema autónomo que usa el clúster.
    • PEER_IP: La dirección IP de uno de los pares externos que deseas probar.
    • PEER_ASN: El número del sistema autónomo para la red que contiene el dispositivo de intercambio de tráfico externo.

  2. Ejecuta el daemon bgpadvertiser y sustituye la VIP del plano de control en el siguiente comando:

    /tmp/bgpadvertiser --config /tmp/bgpadvertiser.conf --advertise-ip CONTROL_PLANE_VIP

    Reemplaza CONTROL_PLANE_VIP por la dirección IP que usarás para la VIP del plano de control. Este comando hace que el anunciante de BGP anuncie esta dirección al par.

  3. Consulta el resultado del programa.

    En este punto, el daemon bgpadvertiser se inicia, intenta conectarse al par y anuncia la VIP. El programa imprime mensajes de forma periódica (consulta el siguiente resultado de muestra) que incluyen BGP_FSM_ESTABLISHED cuando se establece la conexión de BGP.

    {"level":"info","ts":1646788815.5588224,"logger":"BGPSpeaker","msg":"GoBGP gRPC debug endpoint disabled","localIP":"21.0.101.64"}
{"level":"info","ts":1646788815.5596201,"logger":"BGPSpeaker","msg":"Started.","localIP":"21.0.101.64"}
I0309 01:20:15.559667 1320826 main.go:154] BGP advertiser started.
I0309 01:20:15.561434 1320826 main.go:170] Health status HTTP server started at "127.0.0.1:8080".
INFO[0000] Add a peer configuration for:21.0.101.80      Topic=Peer
{"level":"info","ts":1646788815.5623345,"logger":"BGPSpeaker","msg":"Peer added.","localIP":"21.0.101.64","peer":"21.0.101.80/4273481989"}
DEBU[0000] IdleHoldTimer expired                         Duration=0 Key=21.0.101.80 Topic=Peer
I0309 01:20:15.563503 1320826 main.go:187] Peer applied: {4273481989 21.0.101.80}
DEBU[0000] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ACTIVE old=BGP_FSM_IDLE reason=idle-hold-timer-expired
DEBU[0000] create Destination                            Nlri=10.0.0.1/32 Topic=Table
{"level":"info","ts":1646788815.5670514,"logger":"BGPSpeaker","msg":"Route added.","localIP":"21.0.101.64","route":{"ID":0,"Metric":0,"NextHop":"21.0.101.64","Prefix":"10.0.0.1/32","VRF":""}}
I0309 01:20:15.568029 1320826 main.go:199] Route added: {0 0 21.0.101.64 10.0.0.1/32 }
I0309 01:20:15.568073 1320826 main.go:201] BGP advertiser serving...
DEBU[0005] try to connect                                Key=21.0.101.80 Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENSENT old=BGP_FSM_ACTIVE reason=new-connection
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_OPENCONFIRM old=BGP_FSM_OPENSENT reason=open-msg-received
INFO[0005] Peer Up                                       Key=21.0.101.80 State=BGP_FSM_OPENCONFIRM Topic=Peer
DEBU[0005] state changed                                 Key=21.0.101.80 Topic=Peer new=BGP_FSM_ESTABLISHED old=BGP_FSM_OPENCONFIRM reason=open-msg-negotiated
DEBU[0005] sent update                                   Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer attributes="[{Origin: i} 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] received update                               Key=21.0.101.80 Topic=Peer attributes="[{Origin: i} 4273481989 4273481990 {Nexthop: 21.0.101.64}]" nlri="[10.0.0.1/32]" withdrawals="[]"
DEBU[0006] create Destination                            Nlri=10.0.0.1/32 Topic=Table
DEBU[0035] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"
DEBU[0065] sent                                          Key=21.0.101.80 State=BGP_FSM_ESTABLISHED Topic=Peer data="&{{[] 19 4} 0x166e528}"

Si no ves estos mensajes, vuelve a verificar los parámetros de configuración de BGP en el archivo de configuración y verifica con el administrador de red. Ahora tienes configurada una conexión de BGP. Puedes comunicarte con el administrador de red para verificar que ve la conexión establecida en su lado y que ve la ruta anunciada.

Prueba de tráfico

Para probar que la red puede reenviar tráfico a la VIP, debes agregar la VIP al nodo del plano de control que ejecuta bgpadvertiser. Ejecuta el siguiente comando en una terminal diferente para dejar bgpadvertiser en ejecución:

  1. Agrega la VIP al nodo del plano de control:

    ip addr add CONTROL_PLANE_VIP/32 dev INTF_NAME

    Reemplaza lo siguiente:

    • CONTROL_PLANE_VIP: El argumento --advertise-ip de VIP del bgpadvertiser.
    • INTF_NAME: La interfaz de Kubernetes en el nodo. Es decir, la interfaz que tiene la dirección IP que colocas en la configuración de clústeres de Anthos en equipos físicos para loadBalancer.bgpPeers.controlPlaneNodes.

  2. Haz ping a la VIP desde un nodo diferente:

    ping CONTROL_PLANE_VIP

    Si el ping no tiene éxito, es posible que haya un problema con la configuración de BGP en el dispositivo de red. Trabaja con tu administrador de red para verificar la configuración y resolver el problema.

Limpia

Asegúrate de seguir estos pasos para restablecer el nodo después de verificar de forma manual que BGP funciona. Si no restableces el nodo de forma correcta, la configuración manual puede interferir en la verificación previa o la creación posterior del clúster.

  1. Quita la VIP del nodo del plano de control si la agregaste para la prueba de tráfico:

    ip addr del CONTROL_PLANE_VIP/32 dev INTF_NAME

  2. En el nodo del plano de control, presiona Ctrl+C en la terminal bgpadvertiser para detener el bgpadvertiser.

  3. Verifica que no haya procesos bgpadvertiser en ejecución:

    ps -ef | grep bgpadvertiser

  4. Si ves procesos en ejecución, detenlos con el comando kill.