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 de 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 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 funciona 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 por 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
NetworkGatewayGroup
. - 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
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 direcciones IP de nodo del clúster, sino que usan direcciones 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) NetworkGatewayGroup
, 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 NetworkGatewayGroup
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
Para el balanceo de cargas del plano de datos, puedes usar los mismos pares externos que se especificaron en el intercambio de tráfico del plano de control en la sección loadBalancer.controlPlaneBGP
del archivo de configuración del clúster. Como alternativa, puedes especificar diferentes pares de BGP.
Si deseas especificar diferentes pares de BGP para el intercambio de tráfico del plano de datos, agrega las especificaciones de recursos BGPLoadBalancer
y BGPPeer
al archivo de configuración del clúster. Si no especificas estos recursos personalizados, los pares del plano de control se usan de forma automática para el plano de datos.
Debes especificar los pares externos que se usan para sesiones de intercambio de tráfico con las direcciones IP flotantes en el recurso personalizado BGPPeer
, que debes agregar al archivo de configuración del clúster. El recurso BGPPeer
incluye una etiqueta para la identificación del recurso personalizado BGPLoadBalancer
correspondiente. Debes especificar la etiqueta coincidente en el campo peerSelector
del recurso personalizado BGPLoadBalancer
para seleccionar el BGPPeer
que usarás.
El controlador de Anthos Network Gateway intenta establecer sesiones (la cantidad de sesiones se puede configurar) para cada par externo desde el 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 de modo que intercambie tráfico con cada dirección IP flotante especificada en el recurso personalizado NetworkGatewayGroup
.
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.
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.
Una vez que 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. En el archivo de configuración del clúster, debes habilitar las Herramientas de redes avanzadas y actualizar la sección loadBalancer
. También debes agregar especificaciones para estos tres recursos personalizados:
NetworkGatewayGroup
: Especifica las direcciones IP flotantes que se usan para las sesiones de intercambio de tráfico de BGP de servicios.BGPLoadBalancer
: Especifica con selectores de etiquetas qué pares se usan para el balanceo de cargas de BGP.BGPPeer
: Especifica los pares individuales, incluida una etiqueta que permite su selección, para sesiones de intercambio de tráfico de BGP.
En las siguientes instrucciones, se describe cómo configurar tu clúster y los tres recursos personalizados para configurar el balanceo de cargas en paquetes con BGP.
Agrega el campo
advancedNetworking
al archivo de configuración del clúster en la secciónclusterNetwork
y configúralo comotrue
.Este campo habilita la capacidad de Herramientas de redes avanzadas, en particular, el recurso de Network Gateway Group.
apiVersion: baremetal.cluster.gke.io/v1 kind: Cluster metadata: name: bm namespace: CLUSTER_NAMESPACE spec: ... clusterNetwork: advancedNetworking: true
Reemplaza
CLUSTER_NAMESPACE
por el espacio de nombres del 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 porcluster-
. Por ejemplo, si le asignas el nombretest
al clúster, el espacio de nombres escluster-test
.En la sección
loadBalancer
del archivo de configuración del clúster, configuramode
comobundled
y agrega un campotype
con el valorbgp
.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 ...
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.Establece los campos
loadBalancer.ports
,loadBalancer.vips
yloadBalancer.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 ...
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> ...
Reserva direcciones IP flotantes mediante la configuración del recurso personalizado
NetworkGatewayGroup
: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/v1 kind: NetworkGatewayGroup 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 porcluster-
. Por ejemplo, si le asignas el nombretest
al clúster, el espacio de nombres escluster-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.
Asegúrate de que el recurso personalizado
NetworkGatewayGroup
se llamedefault
y use el espacio de nombres del clúster. Para ver un ejemplo de cómo podría verse la especificación del recurso personalizadoNetworkGatewayGroup
, consulta Configuraciones de ejemplo.(Opcional) Especifica los pares que se usarán para el balanceo de cargas del plano de datos mediante la configuración del recurso personalizado
BGPLoadBalancer
:... --- apiVersion: networking.gke.io/v1 kind: BGPLoadBalancer metadata: name: default namespace: CLUSTER_NAMESPACE spec: peerSelector: PEER_LABEL: "true" ...
Reemplaza lo siguiente:
CLUSTER_NAMESPACE
es el espacio de nombres del 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 porcluster-
. Por ejemplo, si le asignas el nombretest
al clúster, el espacio de nombres escluster-test
.PEER_LABEL
: es la etiqueta que se usa para identificar qué pares usar en el balanceo de cargas. Cualquier recurso personalizadoBGPPeer
con una etiqueta coincidente especifica los detalles de cada par.
Asegúrate de que el recurso personalizado
BGPLoadBalancer
se llamedefault
y use el espacio de nombres del clúster. Si no especificas un recurso personalizadoBGPLoadBalancer
, los pares del plano de control se usan de forma automática para el balanceo de cargas del plano de datos. Para ver ejemplos completos, consulta Configuraciones de ejemplo.(Opcional) Especifica los pares externos para el plano de datos mediante la configuración de uno o más recursos personalizados
BGPPeer
:... --- apiVersion: networking.gke.io/v1 kind: BGPPeer metadata: name: BGP_PEER_NAME namespace: CLUSTER_NAMESPACE labels: PEER_LABEL: "true" spec: localASN: CLUSTER_ASN peerASN: PEER_ASN peerIP: PEER_IP sessions: SESSION_QTY ...
Reemplaza lo siguiente:
BGP_PEER_NAME
es el nombre del par.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 porcluster-
. Por ejemplo, si le asignas el nombretest
al clúster, el espacio de nombres escluster-test
.PEER_LABEL
: es la etiqueta que se usa para identificar qué pares usar en el balanceo de cargas. Esta etiqueta debe corresponder con la etiqueta especificada en el recurso personalizadoBGPLoadBalancer
.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. Te recomendamos que especifiques al menos dos pares externos, pero debes especificar al menos uno.PEER_ASN
: El número del sistema autónomo para la red que contiene el dispositivo de intercambio de tráfico externo.SESSION_QTY
es la cantidad de sesiones que se establecerán para este par. Te recomendamos que establezcas al menos dos sesiones para asegurarte de mantener una conexión con el par en caso de que uno de tus nodos se desconecte.
Puedes especificar varios pares externos mediante la creación de recursos personalizados
BGPPeer
adicionales. Te recomendamos que especifiques al menos dos pares externos (dos recursos personalizados) para una alta disponibilidad de las sesiones de BGP. Si no especificas un recurso personalizadoBGPPeer
, los pares del plano de control se usan de forma automática para el balanceo de cargas del plano de datos.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.Cuando el proceso finaliza con éxito, los recursos agregados de balanceo de cargas de BGP (NetworkGatewayGroup, BGPLoadBalancer y BGPPeer) se agregan al clúster de administrador en el espacio de nombres del clúster de usuario. Usa el archivo kubeconfig del clúster de administrador cuando realices actualizaciones posteriores en estos recursos. Luego, el clúster de administrador concilia los cambios en el clúster de usuario. Si editas estos recursos directamente en el clúster de usuario, el clúster de administrador reemplaza tus cambios en las conciliaciones posteriores.
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
Los clústeres de Anthos alojados en equipos físicos asignan de forma automática direcciones IP flotantes 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.
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 NetworkGatewayGroup
. En este ejemplo, como no se especifica BGPLoadBalancer
, los pares del plano de control se usan de forma automática para las sesiones de BGP del plano de datos.
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/v1
kind: NetworkGatewayGroup
metadata:
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.1.100
- 10.0.2.100
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.
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 NetworkGatewayGroup
. En este ejemplo, como no se especifica BGPLoadBalancer
, los pares del plano de control se usan de forma automática para las sesiones de BGP del plano de datos.
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/v1
kind: NetworkGatewayGroup
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.1.100
- 10.0.2.100
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.
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 NetworkGatewayGroup
.
Para configurar el balanceo de cargas del plano de datos, sigue estos pasos:
Especifica el par externo para el plano de datos en el recurso
BGPPeer
y agrega una etiqueta que se use en la selección de pares, comocluster.baremetal.gke.io/default-peer: "true"
.Especifica la etiqueta coincidente para el campo
peerSelector
en el recursoBGPLoadBalancer
.
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/v1
kind: NetworkGatewayGroup
name: default
namespace: cluster-bm
spec:
floatingIPs:
- 10.0.3.100
- 10.0.3.101
---
apiVersion: networking.gke.io/v1
kind: BGPLoadBalancer
metadata:
name: default
namespace: cluster-bm
spec:
peerSelector:
cluster.baremetal.gke.io/default-peer: "true"
---
apiVersion: networking.gke.io/v1
kind: BGPPeer
metadata:
name: bgppeer1
namespace: cluster-bm
labels:
cluster.baremetal.gke.io/default-peer: "true"
spec:
localASN: 65001
peerASN: 65002
peerIP: 10.0.3.254
sessions: 2
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.
Usa el archivo kubeconfig del clúster de administrador cuando realices actualizaciones posteriores en los recursos relacionados con BGP (NetworkGatewayGroup, BGPLoadBalancer y BGPPeer). Luego, el clúster de administrador concilia los cambios en el clúster de usuario. Si editas estos recursos directamente en el clúster de usuario, el clúster de administrador reemplaza tus cambios en las conciliaciones posteriores.
Plano de control
La información de intercambio de tráfico de BGP del plano de control se puede actualizar en el recurso Cluster
.
Puedes agregar o quitar pares especificados en la sección de balanceo de cargas del plano de control.
En las siguientes secciones, se describen las prácticas recomendadas para actualizar la información de intercambio de tráfico de BGP del plano de control.
Archivo Program.cs antes de la actualización:
Para minimizar el riesgo de configurar de forma incorrecta los pares, verifica que las sesiones de intercambio de tráfico de BGP del plano de control estén en el estado esperado antes de realizar cambios. Por ejemplo, si esperas que todas las sesiones de intercambio de tráfico de BGP estén activas, verifica que todos los Pods bgp-advertiser
informen ready
, lo que indica que las sesiones están activas.
Si el estado actual no coincide con lo que esperabas, soluciona el problema antes de actualizar la configuración de los pares.
Para obtener información sobre cómo recuperar los detalles de la sesión de BGP del plano de control, consulta Sesiones de BGP del plano de control.
Actualiza los pares de manera controlada
Si puedes, actualiza un par a la vez para ayudar a aislar los posibles problemas:
- Agrega o actualiza un solo par.
- Espera a que la configuración se concilie.
- Verifica que el clúster pueda conectarse al par nuevo o actualizado.
- Quita los pares antiguos o innecesarios.
Servicios
Para actualizar los grupos de direcciones y la configuración del nodo del balanceador de cargas, edita nodePoolSpec
en el recurso Cluster
.
Para modificar la configuración de intercambio de tráfico de BGP después de crear el clúster, edita los recursos personalizados NetworkGatewayGroup
y BGPLoadBalancer
. Cualquier modificación en la información de intercambio de tráfico en estos recursos personalizados 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).
Soluciona 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 se ve de la siguiente manera:
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 LOCAL ASN PEER ASN LOCAL IP PEER IP STATE LAST REPORT
bgppeer1-node-03 65500 65000 10.0.1.178 10.0.1.254 Established 2s
bgppeer1-node-05 65500 65000 10.0.3.212 10.0.1.254 Established 2s
bgppeer2-node-03 65500 65000 10.0.1.178 10.0.3.254 Established 2s
bgppeer2-node-05 65500 65000 10.0.3.212 10.0.3.254 Established 2s
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/v1
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 PREFIX METRIC
default-default-load-balancer-example 10.1.1.34/32
default-gke-system-istio-ingress 10.1.1.107/32
Usa kubectl describe
para ver los detalles sobre qué saltos siguientes se anuncian en cada ruta.
Recupera el acceso a la VIP del plano de control para clústeres autoadministrados
Para recuperar el acceso a la VIP del plano de control en un clúster híbrido, independiente o de administrador, debes actualizar la configuración de BGP en el clúster. Como se observa en la siguiente muestra de comandos, usa SSH para conectarte al nodo y, luego, usa kubectl
a fin de abrir el recurso del clúster y editarlo.
ssh -i IDENTITY_FILE root@CLUSTER_NODE_IP
kubectl --kubeconfig /etc/kubernetes/admin.conf edit -n CLUSTER_NAMESPACE cluster CLUSTER_NAME
Reemplaza lo siguiente:
IDENTITY_FILE
es el nombre del archivo de identidad SSH que contiene la clave de identidad para la autenticación de clave pública.CLUSTER_NODE_IP
es la dirección IP del nodo del clúster.CLUSTER_NAMESPACE
: el espacio de nombres del clúster.CLUSTER_NAME
: el nombre del clúster
Modifica la configuración de intercambio de tráfico de BGP en el objeto de clúster. Después de guardar la configuración nueva del clúster, supervisa el estado de los Pods bgpadvertiser
. Si la configuración funciona, los Pods se reinician y se recuperan una vez que se conectan a sus pares.
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.
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.
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 .
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.
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.
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.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 incluyenBGP_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:
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 delbgpadvertiser
.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 paraloadBalancer.bgpPeers.controlPlaneNodes
.
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.
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
En el nodo del plano de control, presiona
Ctrl
+C
en la terminalbgpadvertiser
para detener el bgpadvertiser.Verifica que no haya procesos
bgpadvertiser
en ejecución:ps -ef | grep bgpadvertiser
Si ves procesos en ejecución, detenlos con el comando
kill
.