Redes en Red Hat OpenShift para Windows (es-MX)
Artículo original: https://blogs.technet.microsoft.com/networking/2018/12/06/drilling-into-networking-in-red-hat-openshift-for-windows/
Introducción
Hoy profundizaremos en un tema más complejo después de la introducción a Red Hat OpenShift para Windows en las instalaciones hace dos semanas. Nos expandiremos a la capa de red de la arquitectura que hemos elegido para las previsualizaciones de los desarrolladores actuales.
Puedes preguntarte "¿Por qué me importa cómo funcionan las redes?"
La respuesta obvia sería "Sin ella, su contenedor no puede escuchar o hablar mucho con otros".
¿Qué quiero decir con eso? la red es la columna vertebral de cualquier infraestructura de TI y las implementaciones de contenedores no son diferentes de eso. Los diversos componentes de red permiten la comunicación de contenedores, nodos, pods, clusters entre sí y con el mundo exterior.
Como DevOps, deberá tener un conocimiento básico de las piezas de infraestructura de red que se implementan en su infraestructura de contenedores y cómo interactúan, ya sea de forma simple, máquinas virtuales en un host de virtualización o en uno de los muchos servicios en la nube que se proporcionan. Puede adaptar la configuración de la red a sus necesidades.
Terminología
Primero vamos a cubrir algunas palabras de moda, TLA (acrónimos de tres letras) y otras cosas complejas para que todos estemos en la misma página
| Terminología | Descripción |
| CNI | Container Networking Interface, una especificación de una interfaz estandarizada que define el punto final del contenedor y su interacción con el nodo en el que se ejecuta el contenedor.. |
| Docker | Un contenedor popular en tiempo de ejecución. |
| vSwitch | Virtual Switch, el componente central en redes de contenedores. Cada host contenedor tiene uno. Sirve la conectividad básica para cada extremo del contenedor. En el lado de Linux se parece un poco a un puente de Linux. |
| NAT | Traducción de Direcciones de Red. Una forma de aislar espacios de direcciones IP privadas en varios hosts y nodos detrás de un espacio de direcciones IP público |
| Pod | La unidad atómica más pequeña en un Grupo de Kubernetes. Un Pod puede alojar uno o más contenedores. Todos los contenedores en un pod comparten la misma dirección IP |
| Node | Un componente de infraestructura que aloja uno o más pods. |
| Cluster | Un componente de infraestructura compuesto por múltiples nodos. |
| HNS | Host Network Service, un componente de Windows que interactúa con los aspectos de red de la infraestructura del contenedor de Windows |
| HCS | Host Compute Service, un componente de Windows que admite las interacciones del tiempo de ejecución del contenedor con el resto del sistema operativo |
| OVN | Open Virtual Network. OVN proporciona virtualización de red a contenedores. En el modo de "superposición", OVN puede crear una red lógica entre los contenedores que se ejecutan en varios hosts. En este modo, OVN programa las instancias de Open vSwitch que se ejecutan dentro de sus hosts. Estos hosts pueden ser máquinas de metal desnudo o máquinas virtuales de vainilla. OVN utiliza dos almacenes de datos: el almacén de datos Northbound (OVN-NB) y Southbound (OVN-SB). ovn-northbound
ovn-southbound
|
| OVS | Open Virtual Switch. Open vSwitch está adaptado para funcionar como un conmutador virtual en entornos VM. Además de exponer las interfaces de control y visibilidad estándar a la capa de red virtual, se diseñó para admitir la distribución en múltiples servidores físicos.. |
Aquí vamos a ver cómo todos estos componentes encajan en la arquitectura en el nodo de trabajo de Windows. Hablaré más sobre ellos a través del post.
Bien, ahora que estamos en la misma página, entremos.
Configuración Inicial
Para resumir de la última publicación, tendremos un nodo Linux Red Hat OpenShift Master que también funciona como Kubernetes Master y un nodo Windows Server Core Worker que se une al Master. La implementación también utilizará el tiempo de ejecución del contenedor Docker tanto en Linux como en el nodo de Windows para crear instancias y ejecutar los contenedores.
Puede implementar los nodos en un host de máquina virtual, en múltiples hosts de máquinas virtuales, sin restricciones y también implementar más de dos nodos en este entorno. Para el propósito de esta discusión, hemos implementado un host de máquina virtual por separado y lo usaremos para alojar tanto el nodo de Linux como el de Windows.
A continuación, vamos a profundizar en la red y cómo se crean las redes y cómo fluye el tráfico.
Arquitectura de red
La imagen a continuación muestra la arquitectura de red con más detalle y amplía la imagen anterior tanto en el nodo Linux como en el nodo Windows.
Al observar el diagrama a continuación, podemos ver que hay varios componentes que forman la capa de red.
Los componentes se pueden agrupar en varios grupos:
- Partes que son componentes de código abierto (naranja claro)
- Partes que se encuentran en el sistema operativo Windows principal (azul brillante).
- Las partes que son Open Source y Microsoft hicieron cambios específicos en el código y los compartieron con la comunidad (azul claro).
En el lado de Linux, los componentes de código abierto son el tiempo de ejecución del contenedor como el motor Docker, componentes de Kubernetes como
- kube-proxy - (proxy de red Kubernetes) que se ejecuta en cada nodo y refleja los servicios tal como se define en la API de Kubernetes en cada nodo para el reenvío de tráfico a través de un conjunto de backends.
- kubelet: es el "agente de nodo" principal que se ejecuta en cada nodo. El kubelet funciona leyendo un objeto PodSpec que es un documento YAML o JSON que describe un pod.
- Para obtener más información sobre los componentes de Kubernetes en Linux, consulte la documentación de Kubernetes aquí.
En el lado de Windows, Microsoft ha mejorado algunos de estos componentes, como el kube-proxy y el kubelet, para que funcionen con los componentes de red de Microsoft, como el Host Compute Service (HCS) y el Host Network Service (HNS). Estos cambios se realizan para permitir la interoperabilidad con los servicios centrales de Windows y también la abstracción de las diferencias en la arquitectura subyacente.
En el lado de Windows, Microsoft ha mejorado algunos de estos componentes, como el kube-proxy y el kubelet, para que funcionen con los componentes de red de Microsoft, como el Host Compute Service (HCS) y el Host Network Service (HNS). Estos cambios se realizan para permitir la interoperabilidad con los servicios centrales de Windows y la abstracción de las diferencias en la arquitectura subyacente.
Una de las diferencias entre los nodos de Linux y los nodos de Windows en este sistema es la forma en que los nodos se unen al clúster Kubernetes. En Linux usarías un comando como
kubeadm join 10.127.132.215:6443 –token <token> –discovery-token-ca-cert-hash <cert hash>
En Windows donde el comando kubeadm no está disponible, el servicio de cómputo del host maneja la unión cuando se crea el recurso.
El punto clave de la discusión aquí es que, en general, las diferencias de arquitectura subyacentes entre Linux y Windows se resumen y el proceso de configuración de Kubernetes para Windows y la administración de los componentes de red del entorno será sencillo y, en su mayoría, familiar si lo ha hecho. en Linux antes.
Además, dado que Red Hat OpenShift llama a Kubernetes, la experiencia administrativa será uniforme en todos los Nodos de Windows y Linux.
Dicho esto, lo que estamos discutiendo hoy es la arquitectura de la vista previa para desarrolladores actualmente disponible. Microsoft y Red Hat están trabajando para completar el trabajo para integrar la CNI de Windows en el flujo para reemplazar OVN / OVS. Mantendremos la compatibilidad con OVN / OVS y también agregaremos otros complementos CNI a medida que progresemos, pero cambiaremos a Windows CNI durante la primera mitad de 2019. Así que esté atento a una actualización al respecto.