Integración de Kubernetes y Contrail
En este capítulo se realiza una profunda profundización en Contrail’función s en Kubernetes. Comienza con una sección sobre Contrail arquitectura de integración de Kubernetes, donde aprenderá cómo se manejan los objetos Kubernetes, como NS, Pod, Service, Ingress, Network Policy y More, en Contrail. A continuación, se examina en detalle la implementación de cada uno de los objetos.
Cuando sea necesario, el capítulo introducirá Contrail objetos. Como red Kubernetes, CNI Multiple interface pods es una de Contrail’s ventajas con respecto a otras implementaciones, por lo que en este capítulo se explican tales ventajas.
El capítulo concluye con una demostración del encadenamiento de servicios que’utiliza el contenedor Juniper s cSRX. ’Empiece a trabajar con la arquitectura de integración.
Arquitectura de Contrail Kubernetes
Después de buscar los principales conceptos de Kubernetes en los capítulos 2 y 3, ¿cuál podría ser la ventaja de agregar Contrail a la implementación estándar de Kubernetes?
En Resumen, consulte las páginas de productos de Contrail en www.Juniper.net para obtener las últimas ofertas, contrail ofrece una implementación común de varios entornos (OpenStack, Kubernetes, etc.) y enriquece las capacidades’ Kubernetes de redes y seguridad.
Cuando se trata de implementar para varios entornos, sí, los contenedores son la tendencia actual en la creación de aplicaciones (no para mencionar el enfoque anidado, en el que los contenedores se hospedan en la VM). ’Pero no esperemos que todos migren de máquinas virtuales a contenedores que sean rápidos. Agregue una carga de trabajo, total o parcialmente, en la nube pública, y podrá ver los Misery de los administradores de seguridad y de red donde los Kubernetes se convierta en algo más que administrar.
Los administradores de muchas organizaciones administran los gerentes o administradores individuales de cada entorno. OpenStack o VMware NSX para VMS, Kubernetes o mesos para los contenedores, la consola de AWS. WContrail alivia este Misery al proporcionar un control y una política de redes de extremo a extremo dinámicos para cualquier nube, cualquier carga de trabajo, cualquier implementación.
Desde una sola interfaz de usuario Contrail traduce flujos de trabajo abstractos en políticas específicas y simplifica la orquestación de la conectividad de superposición virtual en todos los entornos. Esto lo hace mediante la creación y protección de redes virtuales que conectan BMS, VM y contenedores ubicados en una nube privada o pública.
Puede implementar Kubernetes para iniciar su Pod en máquinas virtuales orquestadas por OpenStack y otras, pero este capítulo solo se centra en Kubernetes. Muchas de las características que se tratan aquí se pueden ampliar para otros entornos, pero Contrail simplemente enriquece la implementación estándar de Kubernetes.
Aunque Kubernetes no proporciona las funciones de red, impone los requisitos fundamentales de la implementación de la red, que se abordan mediante todos los proveedores CNI (interfaz de red contenedora). Juniper Contrail es uno de los proveedores CNI. Consulte: https://kubernetes.IO/docs/Concepts/Cluster-Administration/Networking/ para obtener más información.
Kubernetes tiene algunos requisitos bien definidos para su implementación de red:
Los pods de un nodo pueden comunicarse con todos los pods en todos los nodos sin TDR,
Los agentes de un nodo (p. ej., daemons de sistema, kubelet) se pueden comunicar con todos los pods de ese nodo, y
Los pods de la red de host de un nodo pueden comunicarse con todos los pods en todos los nodos sin TDR.
Kubernetes ofrece conectividad de red plana con algunas características de seguridad delimitadas en un clúster, pero por encima de esto, Contrail puede ofrecer:
Namespaces y servicios se han personalizado los aislamientos de segmentaciones y multiinquilinos,
Balanceo de cargas distribuido y firewall con un flujo centralizado y un amplio conocimiento de logs.
Una política de seguridad enriquecida que utiliza etiquetas que se pueden extender a otros entornos (stack abierto, VMWare, BMS, AWS, etc.), y
Encadenamiento de servicios.
En este capítulo se tratan algunas de estas funciones, pero’primero hay que hablar acerca de contrail arquitectura y la asignación de objetos.
Kube-administrador de Contrail
Se ha agregado un nuevo módulo de Contrail llamado contrail-kube-manager, abreviada como KM. Busca en el servidor de API Kubernetes los recursos de Kubernetes interesados y los traduce en un objeto de controlador de Contrail. La Figure 1 ilustra el flujo de trabajo básico.
Asignación de Kubernetes a objeto Contrail
Esto no es una gran parte del cambio de Contrail habituales que conocemos y encanta, pero hay’muchas cosas que ocurren en segundo plano. Tenga en cuenta que trabajar con Kubernetes/Contrail se trata de la asignación de objetos. Ya’que la contrail es una sola interfaz que administra varios entornos, y cada entorno tiene sus propios acrónimos y términos y, por lo tanto, la necesidad de esta asignación, que es realizada por un complemento. En Kubernetes, contrail-kube-manager hace esto.
Juniper Contrail tiene complementos específicos para cada entorno/Orchestrator. Para obtener más información, consulte Juniper Contrail, en https://www.Juniper.net/US/en/Products-Services/Sdn/contrail/, en inglés).
Por ejemplo, los espacios de nombres de Kubernetes están pensados para la segmentación entre varios equipos o proyectos, como si se estuvieran creando clústeres virtuales. En Contrail el concepto similar se denomina proyecto , de modo que cuando cree un espacio de nombres en Kubernetes, se creará automáticamente un proyecto equivalente en contrail. Más adelante se describirá todo esto, pero para familiarizarse con la lista de objetos que se muestra en la Figure 2 lo ayudará a comprender la arquitectura.
Espacios de nombres y aislamiento de Contrail
En el capítulo 3, se lee namespace o NS en Kubernetes y, al principio de este capítulo, hemos mencionado las asignaciones de objetos entre Kubernetes y Contrail. En esta sección’verá cómo funciona namespace en entornos de contrail y cómo contrail amplía aún más el conjunto de características.
Una analogía que se obtiene al introducir el namespace el concepto es OpenStack project, o bien tenant. Y eso es exactamente de lo Contrail lo mira. Siempre que una nueva namespace objeto se crea, contrail-kube-manager (KM) recibirá un aviso sobre el evento de creación de objetos y creará el proyecto correspondiente en Contrail.
Para diferenciar varios clústeres de Kubernetes en Contrail, se agregará un nombre de clúster Kubernetes al espacio de nombres Kubernetes o al nombre del proyecto. El nombre de clúster predeterminado Kubernetes es k8s. Por lo tanto, si crea un espacio de nombres Kubernetes ns-user-1, en una k8s-ns-user-1 el proyecto se creará en Contrail tal y como puede ver en la Figure 3, donde se muestra el contrail interfaz gráfica de usuario (GUI).
El Kubernetes cluster name se puede configurar, pero solo durante el proceso de implementación. Si no’lo configura k8s será el valor predeterminado. Una vez creado el clúster, no se puede cambiar el nombre. Para ver el cluster
name, debe ir a la contrail-kube-manager (KM) y compruebe su archivo de configuración.
Para ubicar el contenedor del Docker de KM:
$ docker ps -a | grep kubemanager 2260c7845964 ...snipped... ago Up 2 minutes kubemanager_kubemanager_1
Para iniciar una sesión en el contenedor de KM:
$ docker exec -it kubemanager_kubemanager_1 bash
Para encontrar el cluster_name ,
$ grep cluster /etc/contrail/contrail-kubernetes.conf
cluster_name=k8s #<---
cluster_project={}
cluster_network={}
El resto de este libro se referirá a todos estos términos namespace, NS, tenant, y project cambia.
Espacios de nombres no aislados
Debe tener en cuenta que un requisito de red básica de Kubernetes es para una red – plana o sin TDR cualquier conjunto Pod puede comunicarse con cualquier conjunto Pod – en cualquier espacio de nombres y cualquier proveedor CNI debe asegurarse de que. Por lo tanto, en Kubernetes, de forma predeterminada, todos los espacios de nombres no se aíslan:
El término aislado y no aislado se encuentra únicamente en el contexto de las redes (Contrail).
k8s-default-pod-network and k8s-default-service-network
Para proporcionar funciones de red a todos los espacios de nombres no aislados, debe haber una tabla de enrutamiento y reenvío virtual o una instancia de enrutamiento común. En el entorno Contrail Kubernetes, dos redes virtuales predeterminadas se preconfiguran’ en K8S espacio de nombres predeterminado para pod y para Service, respectivamente. Lo que corresponde, hay dos tablas VRF, cada una con el mismo nombre que su red virtual correspondiente.
El nombre de las dos tablas de redes virtuales/VRF tiene este formato:
<k8s-cluster-name>-<namespace name>-[pod|service]-network
Por lo tanto, para el espacio de nombres predeterminado con un nombre de clúster predeterminado, k8s, los dos nombres de las redes virtuales/VRF son:
k8s-default-pod-network: la red virtual Pod/tabla VRF, con la subred predeterminada10.32.0.0/12k8s-default-service-network: la tabla/VRF de red virtual de servicio, con una subred predeterminada10.96.0.0/12
La subred predeterminada para Pod o servicio es configurable.
Es importante saber que estas dos redes virtuales predeterminadas se comparten entre todos los espacios de nombres no aislados. Esto significa que estarán disponibles para cualquier nuevo espacio de nombres no aislado que cree, implícitamente. ’Por qué los pods de todos los espacios de nombres no aislados, incluidos los espacios de nombres predeterminados, se pueden comunicar entre sí.
Por otro lado, cualquier red virtual que cree se aislará con otras redes virtuales, independientemente del mismo espacio de nombres o de otros distintos. La comunicación entre Juniper en dos redes virtuales distintas requiere una política de red Contrail.
Más adelante, cuando lea acerca del servicio Kubernetes, es posible que se pregunte por qué los paquetes destinados a la red virtual de servicio/la tabla VRF pueden llegar al pod de back-end en la red virtual Pod/la tabla VRF. Una vez más, la buena noticia es a causa de Contrail Directiva de red. De forma predeterminada, la Directiva de red Contrail está habilitada entre las redes de servicio y Pod, lo que permite que los paquetes que llegan a la red virtual de servicio o la tabla VRF alcancen la Pod, y viceversa.
Espacios de nombres aislados
Por el contrario, los espacios de nombres aislados tienen su propia red Pod-Network y de servicio predeterminada, y por lo tanto, se crean también dos nuevas tablas VRF para cada espacio de nombres aislado. Las mismas subredes fijas 10.32.0.0/12 y 10.96.0.0/12 son compartidas por las redes Pod y de servicio en los espacios de nombres aislados. Sin embargo, dado que las redes tienen una tabla VRF diferente, se aísla de forma predeterminada con otro espacio de nombres. Los pods que se inician en espacios de nombres aislados solo pueden comunicarse con el servicio y los pods en el mismo espacio de nombres. Las configuraciones adicionales, por ejemplo, la política, son necesarias para que la caja Pod pueda conectar con la red fuera del espacio de nombres actual.
Para ilustrar este concepto,’deje que un ejemplo lo utilice. Supongamos que tiene tres espacios de nombres: el default espacio de nombres y dos espacios de nombres de usuario: ns-non-isolated y ns-isolated. En cada espacio de nombres puede crear una red virtual de usuario: vn-left-1. Finalizará a las siguientes redes virtuales o VRF en Contrail:
default-domain:k8s-default:k8s-default-pod-network
default-domain:k8s-default:k8s-default-service-network
default-domain:k8s-default:k8s-vn-left-1-pod-network
default-domain:k8s-ns-non-isolated:k8s-vn-left-1-pod-network
default-domain:k8s-ns-isolated:k8s-ns-isolated-pod-network
default-domain:k8s-ns-isolated:k8s-ns-isolated-service-network
default-domain:k8s-ns-isolated:k8s-vn-left-1-pod-network
Los nombres anteriores se enumeran en el formato FQDN. En Contrail, dominio es el objeto de nivel superior, seguido por proyecto/inquilino y, a continuación, por redes virtuales.
La Figure 4 , de expertos, lo ilustra todo esto.
A continuación se muestra el archivo YAML para crear un espacio de nombres aislado:
$ cat ns-isolated.yaml apiVersion: v1 kind: Namespace metadata: annotations: "opencontrail.org/isolation" : "true" name: ns-isolated
Y para crear el NS:
kubectl create -f ns-isolated.yaml $ kubectl get ns NAME STATUS AGE contrail Active 8d default Active 8d ns-isolated Active 1d #<--- kube-public Active 8d kube- system Active 8d
Las anotaciones en metadatos son una forma adicional de comparar un espacio de nombres K8S estándar (no aislado). El valor de True indica que se trata de un espacio de nombres aislado:
annotations: "opencontrail.org/isolation" : "true"
Puede ver que esta parte de la definición es Juniper’extensión. El servicio contrail-kube-manager (KM) Lee el espacio de nombres metadata desde Kube-apiserver, analiza la información definida en la annotations objeto y observa que el isolation Flag se establece en true. A continuación, crea el inquilino con la instancia de enrutamiento correspondiente (una para pod y una para el servicio) en lugar de usar las instancias de enrutamiento de espacio de nombres predeterminadas para el espacio de nombres aislado. Fundamentalmente, la forma de implementar el aislamiento.
En las siguientes secciones se comprobará que el aislamiento de enrutamiento funciona.
Comunicación con los pods a través de NS
Crear un espacio de nombres no aislado y un espacio de nombres aislado:
$ cat ns-non-isolated.yaml apiVersion: v1 kind: Namespace metadata: name: ns-non-isolated $ cat ns-isolated.yaml apiVersion: v1 kind: Namespace metadata: annotations: "opencontrail.org/isolation": "true" name: ns-isolated $ kubectl apply -f ns-non-isolated.yaml namespace/ns-non-isolated created $ kubectl apply -f ns-isolated.yaml namespace/ns-isolated created $ kubectl get ns | grep isolate ns-isolated Active 79s ns-non-isolated Active 73s
En ambos espacios de nombres y en el espacio de nombres predeterminado, cree una implementación para iniciar un conjunto de servidores WebServer:
#deploy-webserver-do.yaml
apiVersion: apps/v1
- {key: app, operator: In, values: [webserver]}
$ kubectl apply -f deploy-webserver-do.yaml -n default
deployment.extensions/webserver created
$ kubectl apply -f deploy-webserver-do.yaml -n ns-non-isolated
deployment.extensions/webserver created
$ kubectl apply -f deploy-webserver-do.yaml -n ns-isolated
deployment.extensions/webserver created
$ kubectl get pod -o wide -n default
NAME READY STATUS ... IP NODE ...
webserver-85fc7dd848-tjfn6 1/1 Running ... 10.47.255.242 cent333 ...
$ kubectl get pod -o wide -n ns-non-isolated...
NAME READY STATUS ... IP NODE ...
webserver-85fc7dd848-nrxq6 1/1 Running ... 10.47.255.248 cent222 ...
$ kubectl get pod -o wide -n ns-isolated
NAME READY STATUS ... IP NODE ...
webserver-85fc7dd848-6l7j2 1/1 Running ... 10.47.255.239 cent222 ...
Ping entre todos los pods en tres espacios de nombres:
#default ns to non-isolated new ns: succeed $ kubectl -n default exec -it webserver-85fc7dd848-tjfn6 -- ping 10.47.255.248 PING 10.47.255.248 (10.47.255.248): 56 data bytes 64 bytes from 10.47.255.248: seq=0 ttl=63 time=1.600 ms ^C --- 10.47.255.248 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 1.600/1.600/1.600 ms #default ns to isolated new ns: fail $ kubectl -n default exec -it webserver-85fc7dd848-tjfn6 -- ping 10.47.255.239 PING 10.47.255.239 (10.47.255.239): 56 data bytes ^C --- 10.47.255.239 ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
El resultado de la prueba muestra que la comunicación es bidireccional entre dos espacios de nombres no aislados (espacio de nombres ns-non-isolated y default, en este caso) funciona, pero el tráfico procedente de un espacio de nombres no aislado (default NS) hacia un espacio de nombres aislado no pasa a través de él. ¿Qué sucede con el tráfico dentro del mismo espacio de nombres aislado?
Con la potencia de deployment puede comprobarlo rápidamente: en un espacio de nombres aislado ns-isolated, clonar uno más Pod mediante la ampliación de la implementación con replicas=2 y ping entre los dos pods:
$ kubectl scale deployment webserver --replicas=2 $ kubectl get pod -o wide -n ns-isolated NAME READY STATUS RESTARTS AGE IP NODE webserver-85fc7dd848-6l7j2 1/1 Running 0 8s 10.47.255.239 cent222 webserver-85fc7dd848-215k8 1/1 Running 0 8s 10.47.255.238 cent333 $ kubectl -n ns-isolated exec -it webserver-85fc7dd848-6l7j2 -- ping 10.47.255.238 PING 10.47.255.238 (10.47.255.238): 56 data bytes 64 bytes from 10.47.255.238: seq=0 ttl=63 time=1.470 ms ^C --- 10.47.255.238 ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 1.470/1.470/1.470 ms
El paquete de ping pasa ahora. Para resumir los resultados de las pruebas:
El tráfico no se aísla entre los espacios de nombres no aislados.
El tráfico se aísla entre un espacio de nombres aislado y todos los demás inquilinos del clúster.
El tráfico no se aísla en el mismo espacio de nombres.
El aislamiento de nivel Pod puede lograrse a través de Kubernetes Directiva de red o de grupos de seguridad de Contrail, todo ello tratado más adelante en este capítulo.
Contrail de IP flotante
La comunicación se ha comentado y probado entre pods en el mismo espacio de nombres o en otro diferente’, pero en la medida en que el mismo se encuentra dentro del mismo cluster. ¿Qué ocurre con la comunicación con dispositivos fuera del clúster?
Es posible que ya sepa que en el entorno de Contrail tradicional (OpenStack), hay muchas maneras de que las entidades superpuestas (normalmente una máquina virtual) tengan acceso a Internet. Los tres métodos más frecuentes son:
IP flotante
Fabric SNAT
Enrutador lógico
La solución preferida para Kubernetes es exponer cualquier servicio por medio de service y Ingress objetos, de los’que puede leer en el capítulo 3. En el entorno Contrail Kubernetes, la dirección IP flotante se utiliza en la implementación del servicio y de la entrada para exponerlas en lo’que s se encuentra fuera del clúster. Posteriormente, en este capítulo se explica cada uno de estos dos objetos. Pero primero, vamos’a revisar la base de la dirección IP flotante y veremos cómo funciona con Kubernetes.
El servicio fabric SNAT y logical router son utilizados por las cargas de trabajo superpuestas (VM y Pod) para conectarse a Internet, pero no es posible inicializar la comunicación desde la dirección contraria. Sin floating IP admite el tráfico inicializado desde ambas – direcciones puede configurarlo para que admita tráfico de entrada, el tráfico de salida o ambos, y el valor predeterminado es bidireccional. Este libro se centra únicamente en floating Investigación. Consulte Contrail documentación para obtener información detallada acerca de la estructura SNAT y el enrutador lógico: https://www.juniper.net/ documentation/en_US/contrail5.0/information-products/pathway-pages/contrail-feature-guide-pwp.html.
IP flotante y grupo de direcciones IP flotantes
El servicio floating IP o FIP, es un concepto tradicional de que Contrail ha aceptado desde sus primeras versiones. Esencialmente,’es un concepto OpenStack para asignar una IP de VM, que normalmente es una dirección IP privada, a una IP pública (la IP flotante en este contexto) a la que se puede tener acceso desde el exterior del clúster. A nivel interno, TDR implementa la asignación uno a uno. Siempre que un vRouter reciba paquetes del exterior del clúster destinados a la dirección IP flotante, lo traducirá a la dirección’IP privada de VM s y lo reenviará a la máquina virtual. De manera similar, la traducción se realizará en dirección contraria. Finalmente, tanto la VM como el host de Internet pueden comunicarse entre sí y ambos pueden iniciar la comunicación.
VRouter es un plano de reenvío Contrail que reside en cada nodo de cálculo que controla el tráfico de la carga de trabajo.
La Figure 5 ilustra el flujo de trabajo básico de la IP flotante.
A continuación, se muestran algunos aspectos destacados relacionados con la dirección IP flotante que deben tenerse en cuenta:
Una IP flotante está asociada con una VM’s
porto una VMI (interfaz de máquina virtual).Una dirección IP flotante se asigna a partir de una
FIP pool.Se crea un grupo de direcciones IP flotantes basado en una red virtual (
FIP-VN).El FIP-VN estará disponible para fuera del clúster al establecer la coincidencia con
route-target (RT)atributos del enrutador’de puerta de enlace de la tabla VRF.Cuando un enrutador de puerta de enlace ve una coincidencia con su Directiva de importación de rutas en RT, cargará la ruta en su tabla VRF. Todos los clientes remotos conectados a la tabla VRF podrán comunicarse con la dirección IP flotante.
No hay nada nuevo en el entorno Contrail Kubernetes en relación con el concepto y la función de IP flotante. Pero el uso de IP flotante se ha ampliado en Kubernetes service y ingress implementación de objetos y desempeña una función importante para obtener acceso a Kubernetes service y ingress externamente. Puede consultar las secciones posteriores de este capítulo para obtener más detalles.
Crear agrupación FIP
’Cree un grupo de direcciones IP flotantes en un proceso de tres pasos:
Cree una dirección IP-VN pública y flotante.
Establece RT (destino de enrutamiento) para la red virtual de modo que se pueda anunciar e importar en la tabla VRF’del enrutador de puerta de enlace.
Cree un grupo de direcciones IP flotante basado en la red virtual IP-variable pública.
De nuevo, no hay nada nuevo aquí. Se requerirían los mismos pasos en otros entornos de Contrail sin Kubernetes. Sin embargo, como’aprendió en las secciones anteriores, con contrail integración con Kubernetes se puede crear una red virtual IP flotante en Kubernetes estilo.
Cree una red virtual IP pública flotante llamada vn-NS-predeterminado
# vn-ns-default.yaml
apiVersion: k8s.cni.cncf.io/v1
kind: NetworkAttachmentDefinition
metadata:
annotations:
"opencontrail.org/cidr": "101.101.101.0/24"
name: vn-ns-default
spec:
config: '{
"cniVersion": "0.3.0",
"type": "contrail-k8s-cni"
}'
$ kubectl apply -f vn-ns-default.yaml
networkattachmentdefinition.k8s.cni.cncf.io/vn-ns-default created
$ kubectl get network-attachment-definitions.k8s.cni.cncf.io
NAME AGE
vn-ns-default 22d
A continuación, establezca el destino de enrutamiento.
Si necesita que la dirección IP flotante sea accesible desde Internet a través del enrutador de puerta’de enlace, ll debe establecer un destino de ruta para el prefijo de red virtual que’se va a importar en la tabla VRF de enrutadores de puerta de enlace (consulte la Figure 6). Este paso es necesario siempre que sea necesario tener acceso a Internet.
La ruta de navegación de la interfaz de usuario para establecer RT es: Contrail comando > menú principal > superpuesto > redes virtuales > K8S-vn-NS-default-Pod-Network > Edit > enrutamiento, puentes y políticas.
Ahora vamos’a crear un grupo de direcciones IP flotante basado en la red virtual pública.
Este es el último paso. Desde la interfaz de usuario del comando Contrail, cree un grupo de direcciones IP flotante basado en la red virtual pública. La ruta de navegación de la interfaz de usuario para esta configuración mostrada en la Figure 7 es: Contrail comando > > menú principal superpuesto > IP flotante > crear.
La interfaz de usuario de Contrail también le permite establecer el indicador externo en opciones avanzadas de red virtual, de modo que se creará automáticamente un grupo de direcciones IP flotante llamado público .
Ámbito de grupo de IP flotante
Existen distintas formas de hacer referencia a un grupo de direcciones IP flotantes en el entorno Contrail Kubernetes y, en su caso, el alcance de los grupos también será diferente. Los tres niveles posibles con prioridad descendente son:
Específico del objeto
Nivel de espacio de nombres
Nivel global
Específico del objeto
Este es el nivel de ámbito más específico. Un grupo de IP flotante específico de objeto solo se enlaza al objeto que se especificó, lo que no afecta a ningún otro objeto del mismo espacio de nombres o clúster. Por ejemplo, puede especificar un objeto de servicio web para obtener la dirección IP flotante del grupo de direcciones IP flotantes pool1, un objeto de servicio dns para obtener la dirección IP flotante de otro grupo de direcciones IP flotantes pool2etc. Esto proporciona el control más granular del lugar desde el que se asignará la dirección IP flotante – para un objeto el costo es que es necesario especificarla explícitamente en el archivo YAML para cada objeto.
Nivel de espacio de nombres
En un entorno de varios inquilinos, cada espacio de nombres se asociaría con un inquilino y cada inquilino tendría un grupo de direcciones IP flotante dedicado. En ese caso, es mejor tener una opción para definir un grupo de direcciones IP flotante a nivel NS, de modo que todos los objetos creados en ese espacio de nombres obtengan una asignación de IP flotante de ese grupo. Con el grupo de nivel de espacio de nombres definido (por ejemplo, pool-ns-default), ya no hay necesidad de especificar un nombre de grupo de direcciones IP flotante en’cada archivo de YAML de objetos. Puede seguir asignando un nombre de agrupación diferente, por ejemplo my-webservice-pool de un objeto webservice. En ese caso, WebService de objeto obtendrá la IP flotante de my-webservice-pool en lugar de hacerlo desde el grupo de nivel de espacio de nombres pool-ns-default, ya que las primeras son más específicas.
Nivel global
El ámbito del grupo de nivel global sería todo el clúster. Los objetos de cualquier espacio de nombres pueden usar el conjunto global de direcciones IP flotante.
Puede combinar los tres métodos para aprovechar su flexibilidad combinada. Este’es un ejemplo práctico:
Definir un grupo global
pool-global-default, por lo que cualquier objeto de un espacio de nombres que no tenga definido un grupo de nivel de espacio de nombres o el OB, obtendrá una dirección IP flotante de este grupo.Para NS
dev, defina un grupo de direcciones IP flotantepool-dev, por lo que todos los objetos creados en NSdevobtendrá de forma predeterminada la dirección IP flotante depool-dev.Para NS
sales, defina un grupo de direcciones IP flotantepool-sales, por lo que todos los objetos creados en NSsalesobtendrá de forma predeterminada la dirección IP flotante depool-sales.Para NS
test-only, no defina ningún grupo de nivel de espacio de nombres, de modo que, de forma predeterminada, los objetos creados en él obtendrán una dirección IP flotante a partir delpool-global-default.Cuando un servicio
dev-webserviceen el desarrollo de NS, se necesita una IP flotante depool-salesen lugar depool-dev, especificandopool-salesendev-webserviceel archivo YAML del objeto conseguirá este objetivo.
Tenga en cuenta que la regla de pulgar – siempre prevalecerá sobre el ámbito más específico.
Grupo de IP flotante de objetos
’En primer lugar, echemos un vistazo al grupo de direcciones IP flotante específico del objeto:
#service-web-lb-pool-public-1.yaml
apiVersion: v1
kind: Service
metadata:
name: service-web-lb-pool-public-1
annotations:
"opencontrail.org/fip-pool": "{'domain': 'default-domain', 'project': 'k8s-ns-user-1', 'network': 'vn-public-1', 'name': 'pool-public-1'}"
spec:
ports:
- port: 8888
targetPort: 80
selector:
app: webserver
type: LoadBalancer
En este ejemplo, Service service-web-lb-pool-public-1 Obtendrá una dirección IP flotante del grupo pool-public-1, que se crea en función de la red virtual vn-public-1 en proyecto actual k8s-ns-user-1. El espacio de nombres Kubernetes correspondiente es ns-user-1. Dado que el grupo de direcciones IP flotantes de objetos solo se asigna a este objeto específico, cada nuevo objeto debe asignarse explícitamente a este método a un grupo de direcciones IP flotante.
Agrupación de IP flotante de NS
El siguiente ámbito de grupo de direcciones IP flotante se encuentra en el nivel de espacio de nombres. Cada espacio de nombres puede definir su propio grupo de direcciones IP flotante. De la misma manera que un objeto de anotaciones Kubernetes se utiliza para proporcionar una subred a una red virtual, también se utiliza para especificar un grupo de direcciones IP flotante. El archivo YAML tiene el siguiente aspecto:
#ns-user-1-default-pool.yaml
apiVersion: v1
kind: Namespace
metadata:
annotations:
opencontrail.org/isolation: "true"
opencontrail.org/fip-pool: "{'domain': 'default-domain', 'project': 'k8s-ns-user-1', 'network': 'vn-ns-default', 'name': 'pool-ns-default'}"
name: ns-user-1
Estas ns-user-1 se le da un grupo de direcciones IP flotantes de nivel de espacio de nombres denominado pool-ns-defaulty la red virtual correspondiente es vn-ns-default. Una vez que el ns-user-1 se crea con este archivo YAML, cualquier servicio nuevo que requiera una dirección IP flotante, si no se crea con el nombre de grupo específico del objeto en su archivo YAML, obtendrá una dirección IP flotante asignada desde este grupo. En la práctica, la mayoría de los espacios de nombres (especialmente los espacios de nombres aislados) necesitarán su propio grupo predeterminado de espacios de nombres, por lo que este tipo de configuración será muy frecuente en este campo.
Grupo global de direcciones IP flotante
Para especificar un grupo de IP flotante de nivel global, debe asignar el nombre completo del conjunto de la agrupación (domain > project > net-
work > name), en contrail-kube-manager (KM) ’Archivo de configuración del acoplador (/etc/contrail/contrail-kubernetes.conf). El acoplador genera este archivo automáticamente durante su arranque basándose en sus parámetros de ENV, que puede encontrarse en el /etc/contrail/common_kubemanagearchivo r. env en el nodo maestro:
$ cat /etc/contrail/common_kubemanager.env VROUTER_GATEWAY=10.169.25.1 CONTROLLER_NODES=10.85.188.19 KUBERNETES_API_NODES=10.85.188.19 RABBITMQ_NODE_PORT=5673 CLOUD_ORCHESTRATOR=kubernetes KUBEMANAGER_NODES=10.85.188.19 CONTRAIL_VERSION=master-latest KUBERNETES_API_SERVER=10.85.188.19 TTY=True ANALYTICS_SNMP_ENABLE=True STDIN_OPEN=True ANALYTICS_ALARM_ENABLE=True ANALYTICSDB_ENABLE=True CONTROL_NODES=10.169.25.19
Como puede ver, este .env el archivo contiene parámetros de entorno importantes sobre la instalación. Para especificar una global FIP pool, agregue la siguiente línea:
KUBERNETES_PUBLIC_FIP_POOL={'domain': 'default-domain','name':
'pool-global-default','network': 'vn-global-default','project': 'k8s-ns-user-1'}
Se lee lo siguiente: se llama al grupo global de direcciones IP flotante pool-global-default y se define a partir de una red virtual vn-global-default en Project k8s-ns-user-1. Esto indica que el espacio de nombres Kubernetes correspondiente es ns-user-1.
Ahora con esa parte de la configuración colocada, puede volver a redactar la contrail-kube-manager Contenedor del acoplador para que el cambio surta efecto. Esencialmente, es necesario apagarlo y, a continuación, volver a ponerlo en marcha:
$ cd /etc/contrail/kubemanager/ $ docker-compose down;docker-compose up -d Stopping kubemanager_kubemanager_1 ... done Removing kubemanager_kubemanager_1 ... done Removing kubemanager_node-init_1 ... done Creating kubemanager_node-init_1 ... done Creating kubemanager_kubemanager_1 ... done
Ahora se especificó el grupo de direcciones IP flotante global para el clúster.
En los tres ámbitos, la dirección IP flotante se asigna automáticamente y se asocia únicamente a los objetos servicio y ingreso. Si la dirección IP flotante tiene que asociarse a una caja Pod, debe hacerlo manualmente. En’la siguiente sección, hablaremos de esto.
IP flotante para pods
Una vez que se haya creado el grupo de IP flotante y esté disponible, se puede asignar una IP flotante del grupo de IP flotante para los pods que necesiten uno. Esto se puede hacer asociando una dirección IP flotante a una VMI (VM, o Pod, interfaz), puede crear manualmente una dirección IP flotante a partir de un grupo de direcciones IP flotantes en Contrail interfaz de usuario y, a continuación, asociarla con un conjunto Pod VMI, como en las Figure 8 y Figure 9
Asegúrese de que el grupo de direcciones IP flotante se comparte con el proyecto donde se va a crear una dirección IP flotante.
IP flotante de publicidad
Una vez asociada una dirección IP flotante a una interfaz Pod, se anunciará al equipo del mismo nivel del BGP MP, que normalmente son enrutadores de puerta de enlace. En las figuras, Figure 10, Figure 11y Figure 12siguientes, se muestra cómo agregar y editar una par BGP.
Escriba toda la información de par BGP y’no olvide asociar los controladores, que se muestran a continuación en la Figure 13.
Desde la lista desplegable de peer bajo Associated Peers, seleccione los controladores a igual que el enrutador nuevo BGP que intenta agregar. Elija save Cuando haya terminado. Aparecerá un nuevo par BGP con el enrutador de tipo enrutador.
Ahora hemos’agregado un enrutador de BGP del mismo nivel como enrutador de tipo. En el caso del anunciador BGP local, que es de tipo nodo de control, solo es necesario comprobar los parámetros haciendo clic en el botón Editar. En esta prueba, queremos crear un vecino de IBGP MP entre el controlador de Contrail y el enrutador de puerta de enlace, por lo que asegúrese de que los campos ASN y familias de direcciones coincidan en ambos extremos, consulte la Figure 15.
Ahora puede comprobar BGP el estado de vecino en el enrutador de puerta de enlace:
labroot@camaro> show bgp summary | match 10.169.25.19 10.169.25.19 60100 2235 2390 0 39 18:19:34 Establ
Una vez establecido el vecino, se intercambiarán BGP rutas entre los dos altavoces, lo que es cuando vemos’que la dirección IP flotante asignada al objeto Kubernetes es anunciada por el nodo maestro (10.169.25.19) y aprendida en el enrutador de la puerta de enlace:
labroot@camaro> show route table k8s-test.inet.0 101.101.101.2 Jul 11 01:18:31 k8s-test.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden) @ = Routing Use Only, # = Forwarding Use Only + = Active Route, - = Last Active, * = Both 101.101.101.2/32 *[BGP/170] 00:01:42, MED 200, localpref 100, from 10.169.25.19 AS path: ? validation-state: unverified, > via gr-2/3/0.32771, Push 47
El servicio detail versión del mismo comando indica más: la ruta IP flotante se refleja en el Contrail con-Troller, pero Protocol next hop es el nodo Compute (10.169.25.20) indica que la dirección IP flotante está asignada a un nodo de cálculo. Una entidad que se ejecuta actualmente en ese nodo de cálculo es propietaria de la IP flotante:
labroot@camaro> show route table k8s-test.inet.0 101.101.101.2 detail | match "next hop" Jul 11 01:19:18 Next hop type: Indirect, Next hop index: 0 Next hop type: Router, Next hop index: 1453 Next hop: via gr-2/3/0.32771, selected Protocol next hop: 10.169.25.20 Indirect next hop: 0x900e640 1048601 INH Session ID: 0x70f
La configuración de GRE suavizado dinámico hace que el enrutador de puerta de enlace cree automáticamente una interfaz de túnel GRE suave:
labroot@camaro> show interfaces gr-2/3/0.32771 Jul 11 01:19:53 Logical interface gr-2/3/0.32771 (Index 432) (SNMP ifIndex 1703) Flags: Up Point-To-Point SNMP-Traps 0x4000 IP-Header 10.169.25.20:192.168.0.204:47:df:64:0000000800000000 Encapsulation: GRE-NULL Copy-tos-to-outer-ip-header: Off, Copy-tos-to-outer-ip-header-transit: Off Gre keepalives configured: Off, Gre keepalives adjacency state: down Input packets : 0 Output packets: 0 Protocol inet, MTU: 9142 Max nh cache: 0, New hold nh limit: 0, Curr nh cnt: 0, Curr new hold cnt: 0, NH drop cnt: 0 Flags: None Protocol mpls, MTU: 9130, Maximum labels: 3 Flags: None
El servicio IP-Header indica un encabezado IP externo GRE, de modo que el túnel se crea a partir del enrutador de la puerta de enlace actual cuya dirección local BGP es 192.168.0.204, al nodo remoto 10.169.25.20, en este caso’, uno de los nodos contrail computacionales. El proceso de anuncios de IP flotante se ilustra en la Figure 16.
Resumen
En este capítulo, se han creado los siguientes objetos:
NS ns-user-1
FIP VN: VN-NS-predeterminado
Agrupación FIP: Pool-NS-predeterminado
El servicio ns-user-1 proyecto NS, que se refiere a un grupo de nivel de espacio de nombres pool-ns-default que debe crearse manualmente, contendrá todos nuestros objetos de prueba. El grupo de nivel de espacio de nombres se basa en la red virtual vn-ns-default que tenga la subred 101.101.101/24. La dirección IP flotante para objetos creados en un espacio de nombres NS-User-1 se asignará desde esta subred.
Una vez que haya YAML archivos (dados antes) preparados para el espacio de nombres y la red virtual de IP flotante, puede crear estos objetos:
Es necesario crear el conjunto IP flotante de forma independiente en la interfaz’de usuario de contrail s. Consulte la sección contrail de IP flotante para obtener más detalles.
Con estos objetos hay un espacio de nombres asociado con un grupo de direcciones IP flotante. Desde dentro de este espacio de nombres puede continuar para crear y estudiar otros objetos Kubernetes, como servicio.
Todas las pruebas de este libro que demuestran el servicio y la entrada se crearán en este espacio de nombres NS-User-1.