Caso de uso de la Directiva de red Contrail Kubernetes
En esta sección, vamos’a crear un caso de uso para comprobar cómo funciona Kubernetes Directiva de red en los entornos contrail. ’Empezamos creando unos cuantos espacios de nombres y pods Kubernetes necesarios en la prueba. ’Confirmamos que cada conjunto Pod puede comunicarse con el dut (dispositivo sometido a prueba) gracias al modelo predeterminado de redes allow-any-any, y luego crear las políticas de red y observar cualquier cambio con el mismo patrón de tráfico.
Diseño de red
El diseño del caso de uso se muestra en la Figure 1.
En la Figure 1 , seis nodos se distribuyen en tres departamentos: dev, QA y jtac. El Departamento de desarrollo está ejecutando un servidor de base de datos (dbserver-dev), donde se almacena toda la información valiosa recopilada por el cliente. En su lugar, el diseño requiere que nadie tenga acceso directo a este servidor de base de servidores, sino que solo se permite el acceso a él a través de otro servidor Apache front-end en el Departamento de desarrollo, que se denomina WebServer-dev. Además, por razones de seguridad, el acceso a la información del cliente sólo debe concederse a clientes autorizados. Por ejemplo, solo los nodos del Departamento jtac, un nodo en el Departamento de desarrollo llamado cliente1-dev, y el 10.169.25.20 IP de origen pueden acceder a la BD a través de webserver. Y, por último, el servidor de base de datos dbserver-dev no debe iniciar ninguna conexión con otros nodos.
Preparación de la práctica
Este es un diseño de red muy común y simplificado que puede ver en cualquier lugar. Si modelamos todos estos elementos de red en el mundo de la Kubernetes, se parece a la Figure 2.
Pods necesitamos crear los siguientes recursos:
Tres espacios de nombres: dev, QA, jtac
Seis pods:
Dos pods de servidor: WebServer-dev, dbserver-dev
Dos pods de cliente en el mismo espacio de nombres que los pods de servidor: client1-dev, client2-dev
Dos pods de cliente de dos espacios de nombres diferentes: cliente-QA, cliente-jtac
Dos CIDR:
Especificación 10.169.25.20/32, se trata de la estructura IP del nodo cent222
Especificación 10.169.25.21/32, se trata de la estructura IP del nodo cent333
Table 1: Entorno de prueba de la Directiva de red Kubernetes
NS | caja | FUNC |
partido | client1-dev | cliente web |
partido | client2-dev | cliente web |
asegura | cliente-QA | cliente web |
jtac | cliente: jtac | cliente web |
partido | servidor WebServer-dev | servidor WebServer que atiende a clientes |
partido | dbserver-dev | dbserver Serving Server |
Bien, deje’que prepare los recursos de namespace y K8S necesarios con un archivo todo en uno YAML que defina los espacios de nombres de dev, QA y jtac:
Idealmente, cada conjunto Pod debe ejecutarse con distintas imágenes. Por lo general, los puertos TCP son diferentes en un servidor WebServer y en un servidor de base de datos. En nuestro caso, para simplificar la prueba, usamos la misma imagen contrail-WebServer que’utilizamos a lo largo de todo el libro para todos los pods, de modo que la comunicación entre los clientes y el servidor WebServer y el servidor de base de datos utilice el mismo número de puerto 80 que atiende el mismo servidor http. Además, agregamos una etiqueta: política en todos los pods, de manera que la visualización de todos los pods utilizados en esta prueba también es más fácil.
Bien y ahora cree todos los recursos:
Modo de tráfico antes de crear la Directiva de red Kubernetes
Dado que tenemos todos los espacios de nombres y Juniper, antes de definir cualquier directiva de red’, voy a seguir adelante y enviar tráfico entre clientes y servidores.
Por supuesto, Kubernetes de redes, de forma predeterminada, sigue el modelo allow-any-any, por lo que deberíamos esperar que Access funcione entre cualquier conjunto Pod, que va a ser una relación de acceso completamente entrelazada. Sin embargo, tenga en cuenta que la DUT de esta prueba es WebServer-dev y dbserver-dev es aquél que más nos interesa observar. Para simplificar la verificación, según nuestro diagrama, nos’centramos en acceder a los pods de servidor de los pods de cliente, tal como se muestra en la figura 8,4.
Los puntos destacados de la figura 8,4 son que todos los clientes pueden tener acceso a los servidores, siguiendo el modelo permit-any-any:
no hay ninguna restricción entre los clientes ni WebServer-dev Pod
no hay ninguna restricción entre los clientes y dbserver, Pod de desarrollador
Y la comunicación entre el cliente y los servidores es bidireccional y simétrica – cada extremo puede iniciar una sesión o aceptar una sesión. Estas se asignan a la Directiva de salida y la Directiva de entrada, respectivamente, en Kubernetes.
Obviamente, esto no cumple nuestro objetivo de diseño, que es exactamente por qué necesitamos la Directiva de red Kubernetes, y’pronto nos encontraremos esa parte. Por ahora, veamos’rápidamente cómo comprobar el modelo allow-any-any networking.
Primero deje’que compruebe el servidor HTTP que se ejecuta en el puerto 80 de WebServer-dev y dbserver-pod de dev:
$kubectl exec -it webserver-dev -n dev -- netstat -antp| grep 80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/python $kubectl exec -it dbserver-dev -n dev -- netstat -antp| grep 80 tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1/python
Como se mencionó anteriormente, en esta prueba todos los pods tienen la misma imagen de contenedor, de manera que todos los pods ejecutan la misma aplicación WebServer en sus contenedores. Simplemente asignaremos a cada conjunto POD para que refleje sus diferentes funciones en el diagrama.
Ahora podemos comprobar el acceso a este servidor HTTP desde otros pods con los siguientes comandos. Para probar el tráfico de entrada:
Estos comandos desencadenan las solicitudes HTTP en el servidor WebServer-dev Pod desde todos los clientes y hosts de los dos nodos. La opción-M5 rizo hace que rizo espere un máximo de cinco segundos como respuesta antes de notificar el tiempo de espera. Como era de esperar, todos los accesos pasan y devuelven el mismo resultado mostrado a continuación.
Desde cliente1-dev:
$ kubectl exec -it client1-dev -n dev -- \ curl http://$webserverIP | w3m -T text/html | grep -v "^$" Hello This page is served by a Contrail pod IP address = 10.47.255.234 Hostname = webserver-dev
Aquí, w3m obtiene el resultado de rizo, que devuelve un código HTML de la página web y lo procesa en texto legible y, a continuación, lo envía a grep para eliminar las líneas vacías. Para hacer que el comando sea más corto, puede definir un alias:
alias webpr='w3m -T text/html | grep -v "^$"'
Ahora el comando es más corto:
$ kubectl exec -it client1-dev -n dev -- curl http://$webserverIP | webpr Hello This page is served by a Contrail pod IP address = 10.47.255.234 Hostname = webserver-dev
De manera similar’, ll obtiene los mismos resultados de pruebas para obtener acceso a dbserver-dev desde cualquiera de los otros pods.