Componentes de CN2
La arquitectura de CN2 consta de pods que realizan las funciones de plano de configuración de red y plano de control de red, y pods que realizan las funciones de plano de datos de red.
-
El plano de configuración de red hace referencia a la funcionalidad que permite a CN2 administrar sus recursos e interactuar con el resto del plano de control de Kubernetes.
-
El plano de control de red representa la capacidad SDN con todas las funciones de CN2. Utiliza BGP para comunicarse con otros controladores y XMPP para comunicarse con los componentes del plano de datos distribuidos en los nodos de trabajo.
-
El plano de datos de red se refiere a la función de transmisión y recepción de paquetes en cada nodo, especialmente en los nodos de trabajo donde residen las cargas de trabajo.
Los pods que realizan las funciones de configuración y plano de control residen en nodos del plano de control de Kubernetes. Los pods que realizan las funciones de plano de datos residen tanto en los nodos del plano de control de Kubernetes como en los nodos de trabajo de Kubernetes.
La Tabla 1 describe los principales componentes de CN2. Dependiendo de la configuración, también puede haber otros componentes (no mostrados) que realizan funciones auxiliares, como la administración de certificados y la supervisión del estado.
| Nombre del pod | donde | Descripción | |
|---|---|---|---|
| Plano de configuración1 | contrail-k8s-apiserver | Nodo plano de control | Este pod es un servidor API agregado que es el punto de entrada para administrar todos los recursos de Contrail. Está registrado con el kube-apiserver regular como APIService. El kube-apiserver normal reenvía todas las solicitudes relacionadas con la red al contrail-k8s-apiserver para su manejo. Hay un pod contrail-k8s-apiserver por nodo del plano de control de Kubernetes. |
| Contrail-K8S-Controller | Nodo plano de control | Este pod realiza la función de bucle de control de Kubernetes para conciliar los recursos de red. Supervisa constantemente los recursos de red para asegurarse de que el estado real de un recurso coincida con el estado deseado. Hay un pod controlador contrail-k8s por nodo del plano de control de Kubernetes. |
|
| Contrail-K8S-KubeManager | Nodo plano de control | Este pod es la interfaz entre los recursos de Kubernetes y los recursos de Contrail. Vigila el kube-apiserver en busca de cambios en los recursos normales de Kubernetes, como el servicio y el espacio de nombres, y actúa sobre cualquier cambio que afecte a los recursos de red. En una implementación de un solo clúster, hay un pod contrail-k8s-kubemanager por nodo del plano de control de Kubernetes. En una implementación de varios clústeres, también hay un pod contrail-k8s-kubemanager para cada clúster de carga de trabajo distribuida. |
|
| Plano de control1 | control de estela | Nodo plano de control | Este pod pasa la configuración a los nodos de trabajo y realiza el aprendizaje y la distribución de rutas. Vigila el kube-apiserver en busca de cualquier cosa que afecte al plano de control de red y, a continuación, se comunica con sus pares BGP y/o agentes vRouter (a través de XMPP) según corresponda. Hay un pod de control de estela por nodo del plano de control de Kubernetes. |
| Plano de datos | contrail-vrouter-nodes | Nodo de trabajo | Este pod contiene el agente de vRouter y el propio vRouter. El agente de vRouter actúa en nombre del vRouter local cuando interactúa con el controlador Contrail. Hay un agente por nodo. El agente establece sesiones XMPP con dos controladores Contrail para realizar las siguientes funciones:
El vRouter proporciona la función de envío y recepción de paquetes para los pods y las cargas de trabajo ubicados conjuntamente. Proporciona la funcionalidad de plug-in CNI. |
| contrail-vrouter-masters | Nodo plano de control | Este pod proporciona la misma funcionalidad que el pod contrail-vrouter-nodos, pero reside en los nodos del plano de control. | |
| 1Los componentes que componen el plano de configuración de red y el plano de control de red se denominan colectivamente controlador Contrail. |
|||
La figura 1 muestra estos componentes en el contexto de un clúster de Kubernetes.
Para mayor claridad y para reducir el desorden, las figuras no muestran los pods del plano de datos en el nodo con el controlador Contrail.
de CN2
Cuando se ejecuta en Kubernetes ascendente o Rancher RKE2, el controlador Contrail almacena todos los datos del clúster de CN2 en la base de datos principal de Kubernetes, etcd de forma predeterminada. Cuando se ejecuta en OpenShift, el controlador Contrail almacena todos los datos del clúster de CN2 en su propia base de datos Contrail etcd.
El kube-apiserver es el punto de entrada para las llamadas a la API REST de Kubernetes para el clúster. Dirige todas las solicitudes de red al servidor contrail-k8s-apiserver, que es el punto de entrada para las llamadas a la API de Contrail. El servidor contrail-k8s-apiserver traduce las solicitudes de red entrantes en llamadas a la API REST a los objetos CN2 respectivos. En algunos casos, estas llamadas pueden dar lugar a que el controlador de Contrail envíe mensajes XMPP al agente de vRouter en uno o más nodos de trabajo o envíe mensajes BGP (no mostrados) a otros nodos del plano de control o enrutadores externos. Estos mensajes XMPP y BGP se envían fuera de las comunicaciones normales de nodo a nodo de Kubernetes.
Los componentes de contrail-k8s-kubemanager (clúster) solo están presentes en implementaciones de varios clústeres. Para obtener más información sobre los distintos tipos de implementación, vea Modelos de implementación.
La figura 2 muestra un clúster con varios controladores Contrail. Estos controladores residen en nodos del plano de control. Los componentes de Kubernetes se comunican entre sí mediante REST. Los controladores Contrail intercambian rutas entre sí mediante iBGP, fuera de la interfaz REST normal de Kubernetes. Para mayor redundancia, los agentes de vRouter en los nodos de trabajo siempre establecen comunicaciones XMPP con dos controladores Contrail.
