Directiva de red Kubernetes

El modelo de red Kubernetes requiere que todos los pods tengan acceso a todos los demás pods de forma predeterminada. Esto se denomina red plana porque sigue un modelo Allow-any-any . Simplifica de forma significativa el diseño e implementación de las redes de Kubernetes y hace que sea mucho más escalable.

La seguridad es una preocupación importante. En realidad, en muchos casos es necesario un determinado nivel de métodos de segmentación de red para garantizar que solo determinados pods puedan comunicarse entre sí, y que es cuando la política de la red Kubernetes se incorpora a la imagen. Una directiva de red Kubernetes define los permisos de acceso para grupos de Juniper de la misma manera que un grupo de seguridad de la nube se usa para controlar el acceso a las instancias de VM.

Kubernetes admite la Directiva de red a través del objeto NetworkPolicy, que es un recurso Kubernetes como un conjunto de miembros, como Pod, Service,’Ingress y muchas otras que se aprendieron anteriormente en este capítulo. El rol del objeto de directiva de red es definir cómo se permite que los grupos de Juniper se comuniquen entre sí.

A’continuación, examine cómo funciona la Directiva de red de Kubernetes:

1. 1Initially, en un clúster de Kubernetes, todos los pods no se aíslan de forma predeterminada y funcionan en un modelo allow-any-any, por lo que cualquier Pod puede comunicarse con cualquier otro Pod.

2. 2. Aplique ahora una directiva de red denominada directiva1 a. En la Directiva directiva1, usted define una regla para permitir explícitamente que el conjunto Pod a hable con la Pod B. En este caso,’deje que s llame a POD a un pod de destino , ya que es la caja Pod en la que actuará la Directiva de red.

3. 3. A partir de este momento, ocurrirán algunas cosas:

   • La pod de destino a puede comunicarse con la Pod B y sólo puede hablar con la Pod b, ya que B es el único conjunto Pod permitido en la política. Debido a la naturaleza de las reglas de políticas, puede llamar a la regla una lista blanca.

   • En el caso del pod de destino A solamente, se rechazarán todas las conexiones que no estén explícitamente permitidas por la lista blanca de esta política de red. ’No es necesario definirlo explícitamente a la directiva1, porque se aplicará según la naturaleza de la Directiva de red Kubernetes. Deje’que se llame a esta política implícita denegar todas las políticas.

   • Como en el caso de otros pods no objetivo, por ejemplo, Pod B o Pod C, que no se aplican con la directiva1, ni a ninguna otra política de red, continuará siguiendo el modelo "Allow-any-any". Por lo tanto, no se ven afectados y pueden seguir comunicándose con todos los demás pods del clúster. Esta es otra directiva implícita, que es permitir todas las políticas.

4. Suponiendo que también desea que pod a pueda comunicarse con Pod C, debe actualizar la Directiva de red directiva1 y sus reglas para permitirlo de forma explícita . En otras palabras, debe seguir actualizando la lista blanca para permitir más tipos de tráfico.

Como puede ver, al definir una directiva, se aplicarán al menos tres políticas en el clúster:

• Explícito de la directiva1: Se trata de la Directiva de red definida, con las reglas de la lista blanca que permite determinados tipos de tráfico para el conjunto Pod seleccionado.

• Denegar implícitamente toda la Directiva de red: Esto deniega el resto del tráfico que no se encuentra en la lista blanca de la caja pod de destino.

• Activar implícitamente todas las políticas de red: Esto permite cualquier otro tráfico para los otros pods no objetivo que no estén seleccionados por la directiva1. Disponemos’que vea denegar todo y volver a permitir todas las políticas en el capítulo 8.

Estas son algunas de las características más destacadas de la Directiva de red Kubernetes.

• Específico del conjunto Pod: La especificación de políticas de red se aplica a un conjunto Pod o a un grupo de pods basado en la etiqueta, igual que RC o deploy do.

• Reglas basadas en listas blancas: reglas explícitas que componen una lista blanca, y cada regla describe cierto tipo de tráfico que se permitirá. Cualquier otro tráfico no descrito por ninguna regla de la lista blanca será rechazado para la caja de los pod de destino.

• Permitir todo todo implícito: Un conjunto de transformadores solo se verá afectado si lo selecciona una directiva de red como destino y solo se verá afectado por la Directiva de red de selección. La ausencia de una directiva de red aplicada a una caja Pod indica que se permite implícitamente esta directiva a este conjunto Pod. En otras palabras, si un conjunto Pod sin destino continúa su modelo de red allow-any-any.

• Separación de entrada y salida: Es necesario definir reglas de políticas para una dirección específica. La dirección puede ser entrada, salida, ninguna o ambas cosas.

• Basado en flujo (frente a paquetes): Una vez permitido el paquete de inicio, también se permitirá el paquete de retorno en el mismo flujo. Por ejemplo, supongamos que una directiva de ingreso aplicada al encajal A permite una solicitud HTTP de entrada y, a continuación, se permitirá toda la interacción HTTP para el conjunto Pod A. Esto incluye el establecimiento de la conexión TCP tridireccional y todos los datos y confirmaciones en ambas direcciones.

Definición de directiva de red

Como todos los demás objetos de Kubernetes, la Directiva de red puede definirse en un archivo YAML. Echemos’un vistazo a un ejemplo (el mismo ejemplo se utilizará en el capítulo 8):

Echemos’un vistazo a la parte de especificaciones de este archivo YAML, ya que las demás secciones son algo explicativos. La especificación tiene la siguiente estructura:

Aquí puede ver que un archivo YAML de definición de directiva de red puede dividirse lógicamente en cuatro secciones:

• podSelector: Define la selección de pods. Identifica a los pods a los que se aplicará la política de red actual.

• policyTypes: Especifica el tipo de reglas de directiva: Entrada, salida o ambas.

• entrada Define las reglas de la política de entrada para los Juniper de destino.

• salida Define las reglas de la Directiva de salida para los Juniper de destino.

A continuación’, examinaremos cada sección con más detalle.

Selección de pods de destino

Al definir una directiva de red, Kubernetes necesita saber a qué Juniper desea que actúe esta Directiva. De manera similar a cómo selecciona el servicio sus Juniper de back-end, la política de red selecciona los pods a los que se aplicará según las etiquetas:

Aquí, todos los pods que tienen la etiqueta app: webserver-dev la política de red selecciona como Juniper de destino. Todo el siguiente contenido en la especificación se aplicará solo a los pods de destino.

Tipos de políticas

En la segunda sección se definen los policyTypes para los pods de destino:

PolicyTypes puede ser ingreso, salida o ambos. Y ambos tipos definen los tipos de tráfico específicos en forma de una o más reglas, como se explica a continuación.

Reglas de políticas

Las secciones entrada y salida definen la dirección del tráfico, desde la perspectiva de los pods’ de destino seleccionados. Por ejemplo, considere el siguiente ejemplo simplificado:

Si damos por hecho que el pod de destino es WebServer-pod de desarrollador y solo hay un conjunto Pod-dev en el clúster con una etiqueta de cliente1-dev, se producirán dos cosas:

1. Dirección de entrada: el servidor WebServer de Pod-dev puede aceptar una sesión TCP con un puerto de destino 80, iniciado desde Pod client1-dev. Esto explica por qué dijimos Kubernetes la Directiva de red está basada en el flujo en lugar de en el paquete. No se pudo establecer la conexión TCP si la Directiva hubiera sido diseñada para el paquete porque al recibir la sincronización TCP entrante, la devolución de sincronización TCP-ACK de salida se habría rechazado sin una directiva de salida coincidente.

2. Dirección de salida: Pod WebServer: dev puede iniciar una sesión TCP con el puerto de destino 8080, hacia el conjunto Pod-dev.

Reglas de directiva de red

Cada instrucción from o to define una regla en la Directiva de red:

• Una instrucción from define una regla de la Directiva de entrada.

• Una instrucción to define una regla de directiva de salida

• Ambas reglas pueden tener opcionalmente sentencias ports, que se tratarán más adelante.

Por lo tanto, puede definir varias reglas para permitir modos de tráfico complejos para cada dirección:

Cada regla identifica los puntos de conexión de red en los que los pods de destino se pueden comunicar. Los puntos de conexión de red se pueden identificar mediante distintos métodos:

• ipBlock: Selecciona los pods basados en un bloque de direcciones IP.

• namespaceSelector: Selecciona los pods basados en la etiqueta del espacio de nombres.

• podSelector: Selecciona los pods basados en la etiqueta de la caja Pod.

Por lo tanto, la estructura YAML de una regla puede ser similar a la siguiente:

Por ejemplo:

Aquí, los puntos de conexión de la red de entrada son las subredes 10.169.25.20/32; o todos los pods en espacios de nombres que tengan el proyecto Label: jtac o los pods que tienen la aplicación de etiqueta: cliente1-dev en el espacio de nombres actual (espacio de nombres de Target POD) y el punto de red de salida es Pod dbserver-dev. ’Los puertos llegarán pronto a las piezas.

Y frente o

’También es posible especificar solo unos cuantos pods de espacios de nombres, en lugar de comunicarse con todos los pods. En nuestro ejemplo, podSelector se utiliza a todos, lo que supone el mismo espacio de nombres que el pod de destino. Otro método es usar podSelector junto con un namespaceSelector. En ese caso, los espacios de nombres a los que pertenecen los pods son aquellos que tienen etiquetas coincidentes con namespaceSelector, en lugar del mismo’que el espacio de nombres Pod s de destino.

Por ejemplo, si damos por hecho que el pod de destino es WebServer-dev y su espacio de nombres es dev, y solo la calidad de espacio de nombres tiene un proyecto de etiqueta = coincidencia de QA en la namespaceSelector:

Aquí, el conjunto de destinos solo se puede comunicar con aquellos pods que estén en el espacio de nombres de AC y (not OR) con la etiqueta app: client1-qa.

Tenga cuidado en este caso porque es totalmente diferente a la definición siguiente, lo que permite que el conjunto pod de destino hable con esos pods: en espacios de nombres qaO (not AND) con etiqueta app: client1-qa en el dispositivo de’espacio de nombres Pod s de destino:

Protocolo y puertos

También es posible especificar puertos para una regla de entrada y salida. El tipo de protocolo también se puede especificar junto con un puerto de protocolo. Por ejemplo:

Los puertos en la entrada indican que los pods de destino pueden permitir el tráfico entrante para los puertos y el protocolo especificados. Puertos en salida indican que los pods de destino pueden iniciar el tráfico en los puertos y protocolos especificados. Si no se menciona el puerto, se permiten todos los puertos y protocolos.

Explicación línea a línea

A’continuación, echemos un vistazo a nuestro ejemplo en detalle:

Ahora debe saber exactamente lo que la Directiva de red está intentando imponer.

Líneas 1-3: Pod WebServer: dev lo selecciona la política, por lo que es el pod de destino; se aplicarán todas las reglas de políticas siguientes, y solo lo será.

Líneas 4-6: la política definirá reglas tanto para el tráfico de entrada como para el de salida.

Líneas 7-19: entrada sección define la política de entrada.

Línea 8: contra y 17: puertos, estas dos secciones definen una regla de directiva en la Directiva de entrada.

Líneas 9-16: estas ocho líneas en la línea desde: sección redactar una lista blanca de entrada:

• Líneas 9-10: todos los datos que entran con la dirección IP de origen 10.169.25.20/32 pueden acceder al servidor webpod de destino-dev.

• Líneas 11-13: Any pods en namespace jtac puede acceder a WebServer de Target Pod-dev.

• Líneas 14-16: cualquier pods con la etiqueta client1-dev puede acceder a WebServer de Target Pod-dev.

Líneas 17-19: la sección de puertos es la segunda (y la opcional) parte de la misma regla de directiva. Solo el puerto TCP 80 (servicio Web) en WebServer del pod de destino-dev está expuesto y se puede acceder a él. Se denegará el acceso a todos los demás puertos.

Líneas 20-26: salida sección define la Directiva de salida.

Líneas 21: como y la línea 24: puertos, estas dos secciones definen una regla de directiva en la Directiva de salida.

• Líneas 21-24: estas cuatro líneas bajo: sección componen una lista blanca de salida, la caja de destino puede enviar tráfico de salida al desarrollo de la Pod dbserver.

Línea 25: la sección de puertos es la segunda parte de la misma regla de políticas. El servidor WebServer-pod de destino solo puede iniciar una sesión TCP con el puerto de destino 80 a otros pods.

’... Y no todo. Si no recuerda al principio de este capítulo, hablamos acerca del modelo predeterminado de red Allow-any-any de Kubernetes y las políticas de denegación-todos, permitir-todo IMPLÍCITAS, se dará cuenta de que hasta ahora acabamos de explicar la parte explícita de la misma (directiva1 en nuestra sección Introducción a la Directiva de red). Después de esto, existen dos políticas más implícitas:

Denegar toda la Directiva de red: para el servidor WebServer-dev del pod de destino, deniega todo el tráfico que no es lo permitido explícitamente en las listas blancas anteriores, lo que implica al menos dos reglas:

• entrada deniegue todo el tráfico entrante destinado al servidor WebServer de destino-dev (distinto de lo que se define en la lista blanca de entrada).

• salida deniegue todo el tráfico saliente del servidor WebServer-dev de destino, distinto de lo que se define en la lista blanca de salida.

Una directiva de permitir todas las redes permite todo el tráfico de otros pods que no son objetivos de esta política de red, tanto en la entrada como en la salida.

Crear Directiva de red

Puede crear y verificar la Directiva de red del mismo modo que crea otros objetos de Kubernetes:

En el capítulo 8’, configuramos un entorno de prueba para comprobar con más detalle el efecto de esta directiva de red.