Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Crear Directiva de red Kubernetes

 

A continuación’, deje que s cree la Directiva de red K8S para implementar nuestro diseño. A partir de nuestro objetivo inicial de diseño, esto son lo que queríamos lograr mediante una política de red:

  • cliente1: dev y pods en jtac namespace (es decir, jtac-dev POD) puede acceder a WebServer y a dev Pod

  • WebServer: un pod (y solo él) tiene permiso de acceso dbserver-pod de desarrollador

  • los demás pods de cliente no tienen permitido acceder a los dos pods de servidor

  • todos los demás pods de cliente pueden seguir comunicándose entre sí.

Traducción de estos requisitos al idioma de la Directiva de red Kubernetes,’trabajamos con este archivo de YAML de políticas de red:

A partir de la definición de la Directiva de red,’que se basa en lo aprendido en el capítulo 3, es fácil que pueda saber lo que la Directiva está intentando imponer en nuestra configuración actual:

  • Según la política de entrada, los siguientes clientes pueden acceder a la caja Pod del servidor WebServer-dev, que se encuentra en el espacio de nombres dev:

    • cliente1: desarrollo desde el espacio de nombres dev

    • todos los pods del espacio de nombres jtac, que es el conjunto pod de cliente-jtac en nuestra configuración

    • clientes con 10.169.25.20 IP de origen (cent222 en la configuración)

  • Según la Directiva de salida, el conjunto de servidores WebServer-dev del espacio de nombres dev puede iniciar una sesión TCP en dbserver-pod de dev con el puerto de destino 80 para tener acceso a los datos.

  • Para el conjunto pod de destino-dev, se denegarán todos los demás accesos.

  • La comunicación entre los demás pods no se ve afectada por esta política de red.

Tip

En realidad, se trata del archivo de YAML de políticas de’red exacto que se muestra en el capítulo 3.

Cree’la Directiva y compruebe que tiene efecto:

Creación de directiva de red post Kubernetes

Después de crear la Directiva de red directiva1,’deje que se pruebe el acceso al servidor http en WebServer-dev Pod desde podism-dev, Client-jtac y node cent222 host:

El acceso de estos dos pods a WebServer-dev es correcto y es lo que queremos. Ahora, si repetimos la misma prueba desde el otro Pod-dev, Client-QA y otro nodo, cent333 ahora se agotará el tiempo de espera:

Los nuevos resultados de la prueba después de aplicar la Directiva de red se ilustran en la Figure 1.

Figure 1: Directiva de red: Después de aplicar la Directiva1
Directiva de red: Después de aplicar la Directiva1

Un detalle del objeto de directiva de red indica lo mismo:

En el ejercicio anterior, podemos concluir que K8S Directiva de red funciona de la manera esperada en Contrail.

Pero nuestra prueba no se ha hecho todavía. En la Directiva de red en la que se definieron la Directiva de entrada y salida, pero desde la perspectiva’’del servidor WebServer-dev, solo comprobamos que la política de entrada de la directiva1 funciona correctamente. Además, no hemos aplicado ninguna directiva al resto del servidor Pod dbserver-dev. Según el valor predeterminado permitir cualquier política, cualquier pods puede acceder directamente a él sin problemas. Obviamente, esto no es lo que queríamos de acuerdo con nuestro diseño original. Se necesita otra directiva de red de entrada para dbserver-Pod-dev, y finalmente, necesitamos aplicar una directiva de salida a dbserver-dev para asegurarse de que se pueda’conectar a cualquier otro pods. Por lo tanto, hay que confirmar al menos tres elementos de prueba, es decir:

  • Probar la política de salida de directiva1 aplicada a WebServer-pod de desarrollo;

  • Definir y probar la política de Ingress para dbserver-pod de desarrollo;

  • Defina y pruebe la Directiva de salida para dbserver-Pod-dev. ’Observemos primero la política de salida de la directiva1.

Directiva de salida de WebServer-pod de desarrollo

A’continuación se muestra la prueba del tráfico de salida:

El resultado muestra que solo el acceso a dbserver-dev se realiza correctamente mientras se agota el tiempo de espera de otros accesos de salida:

Directiva de red de dbserver-pod de desarrollo

Hasta ahora, lo que es tan bueno. ’Observemos los elementos de prueba del segundo, el acceso de entrada a dbserver-dev pod de otros pods que no sea WebServer-pod de dev. Pruebe el tráfico de salida:

Todos los pods pueden acceder a dbserver, directamente a dev Pod:

Nuestro diseño es bloquear el acceso desde todos los pods excepto WebServer-dev Pod. Para ello, es necesario aplicar otra directiva. A continuación se muestra el archivo YAML de la segunda Directiva:

Esta directiva de red, policy2, es muy similar a la anterior directiva1, excepto que parece más simple – . los tipos de directiva solo tienen entrada en la lista, por lo que solo se definirá una directiva de entrada. Y que la Directiva de entrada defina una lista blanca con solo un podSelector. En nuestro caso de prueba, solo un servidor WebServer-dev tiene su etiqueta coincidente con el mismo, por lo que será el único autorizado para iniciar la conexión TCP hacia Target Pod dbserver-dev en el puerto 80. Deje’que s cree la Directiva policy2 ahora y compruebe el resultado de nuevo:

Ahora el acceso a dbserver-pod de dev es asegurado.

Directiva de salida en dbserver-dev

Bien, solo uno de los últimos requisitos de nuestro objetivo de diseño: dbserver del servidor-dev no debe poder iniciar ninguna conexión con otros nodos.

Cuando revisó policy2, es posible que se me haya preguntado cómo haremos eso. En el capítulo 3 destacamos que la Directiva de red se basa en la lista blanca únicamente por su diseño. Por lo tanto, todo lo que usted ponga en la lista blanca significa que estará permitido. Solo una lista negra ofrece una denegación, pero incluso con una lista’negra que ganó, no podrá enumerar todos los demás pods para obtenerlos denegados.

Otra forma de pensar en esto es hacer uso de la Directiva implícita denegar todo. Suponiendo que esta secuencia de directivas está en el diseño actual de la Directiva de red Kubernetes:

  • policy2 en dbserver-dev

  • denegar todo para dbserver-dev

  • permitir todos los demás pods

Parece que si damos una lista blanca vacía en la política de salida de dbserver-dev, no se permitirá nada y se entrará en juego la política deny All para el conjunto pod de destino. El problema es, ¿cómo definimos una lista blanca vacía?:

Esto resulta que no’funciona de la manera esperada:

La comprobación de los detalles del objeto de Directiva no descubre algo que obviamente sea incorrecto:

El problema está en el policyTypes. Se Haven’a agregar la salida, por lo que se pasará por alto cualquier cosa que esté configurada en la Directiva de salida. Si simplemente agrega salida en policyTypes, lo corregirá. Además, para expresar una lista blanca vacía, la salida: la palabra clave es opcional y no es obligatoria. A continuación se muestra el nuevo archivo de YAML de políticas:

Ahora elimine el policy2 antiguo y aplique esta nueva Directiva. Se bloquearán las solicitudes de dbserver-dev a cualquier pods (por ejemplo, Pod cliente1-dev):

Y este es el diagrama final que ilustra el resultado de nuestra prueba de la Directiva de red en la Figure 2.

Figure 2: Directiva de red: Después de aplicar una política de salida vacía en Observer-dev Pod
Directiva de red: Después de aplicar una política de salida vacía en Observer-dev Pod

La acción Drop en la tabla de flujo

Antes de concluir la prueba, dejemos que’echemos un vistazo a la tabla de flujo vRouter cuando la política interrumpa el tráfico. En el nodo cent333 donde se ubican los Pod dbserver-dev:

La acción: D se establece en D (FwPolicy), que significa eliminar debido a la Directiva de Firewall. Mientras tanto, en el otro nodo cent222, en la que se encuentra la caja Pod-dev’, no vemos ningún flujo generado, lo que indica que el paquete no llega: