Control del tráfico entre los pods con políticas de Kubernetes
Nube privada virtual
Puede utilizar políticas de Kubernetes para controlar el tráfico de red entre los pods del clúster y para aislar los microservicios de apps entre sí dentro de un espacio de nombres o entre espacios de nombres.
Nivel de aplicación: punto final de host de nodo trabajador
Comportamiento predeterminado: no existen políticas de red de Kubernetes de forma predeterminada en el clúster. De forma predeterminada, cualquier pod tiene acceso a cualquier otro pod del clúster. Además, cualquier pod tiene acceso a cualquier servicio que exponga la red de pod, como un servicio de métricas, el DNS de clúster, el servidor de API o cualquier servicio que cree manualmente en el clúster.
Caso de uso: las políticas de red de Kubernetes especifican el modo en que los pods se pueden comunicar con otros pods y con puntos finales externos. Se puede permitir tanto el tráfico de red entrante como saliente en función de protocolo, del puerto y de las direcciones IP de origen y destino. El tráfico también se puede filtrar basándose en las etiquetas de espacio de nombres y pod. Cuando se aplican políticas de red de Kubernetes, se convierten de forma automática en políticas de red de Calico. El plugin de red Calico en el clúster aplica estas políticas configurando las reglas de Iptables de Linux en los nodos trabajadores. Las reglas iptables sirven como cortafuegos para el nodo trabajador para definir las características que debe cumplir el tráfico de red para que se reenvíe al recurso de destino.
Si todos los pods o la mayoría no requieren acceso a pods o servicios específicos, y desea asegurarse de que los pods no pueden acceder a esos pods o servicios de forma predeterminada, puede crear una política de red de Kubernetes para bloquear el tráfico de entrada a esos pods o servicios.
Para obtener más información sobre cómo las políticas Kubernetes de red controlan el tráfico entre pods y para ver más ejemplos de políticas, consulte la Kubernetes documentación.
Aislamiento de los servicios de app dentro de un espacio de nombres
En el caso de ejemplo siguiente se muestra cómo gestionar el tráfico entre los microservicios de una app dentro de un espacio de nombres.
Un equipo del departamento de cuentas despliega varios servicios de app en un espacio de nombres, pero necesitan aislamiento para permitir únicamente la comunicación necesaria entre los microservicios a través de la red pública. Para la app
Srv1, el equipo tiene servicios frontal, de fondo y de base de datos. Etiquetan cada servicio con una etiqueta app: Srv1 y con la etiqueta tier: frontend, tier: backend o tier: db.
El equipo del departamento de cuentas desea permitir el tráfico procedente de un programa frontal y destinado al programa de fondo, y desde el programa de fondo a la base de datos. Utilizan etiquetas en sus políticas de red para designar los flujos de tráfico que se permiten entre los microservicios.
En primer lugar, crean una política de red de Kubernetes que permite el tráfico entre el programa frontal y el de fondo:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: backend-allow
spec:
podSelector:
matchLabels:
app: Srv1
tier: backend
ingress:
- from:
- podSelector:
matchLabels:
app: Srv1
Tier: frontend
La sección spec.podSelector.matchLabels lista las etiquetas para el servicio de fondo de Srv1, para que la política se aplique solo a esos pods. La sección spec.ingress.from.podSelector.matchLabels lista las
etiquetas del servicio frontal de Srv1 para que la entrada solo esté permitida desde esos pods.
A continuación, crean una política de red de Kubernetes similar que permite el tráfico entre el programa de fondo y la base de datos:
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: db-allow
spec:
podSelector:
matchLabels:
app: Srv1
tier: db
ingress:
- from:
- podSelector:
matchLabels:
app: Srv1
Tier: backend
La sección spec.podSelector.matchLabels lista las etiquetas para el servicio de base de datos de Srv1, para que la política se aplique solo a esos pods. La sección spec.ingress.from.podSelector.matchLabels lista las etiquetas del servicio de fondo de Srv1 para que la entrada solo esté permitida desde esos pods.
Ahora el tráfico puede fluir desea el programa frontal y destinado al programa de fondo, y desde el programa de fondo a la base de datos. La base de datos puede responder al programa de fondo y el programa de fondo puede responder al programa frontal, pero no se pueden establecer conexiones de tráfico inversas.
Aislamiento de servicios de app entre espacios de nombres
En el caso de ejemplo siguiente se muestra cómo gestionar el tráfico entre los microservicios de una app entre varios espacios de nombres.
Los servicios que pertenecen a diferentes subgrupos deben comunicarse entre sí, pero están implementados en diferentes espacios de nombres dentro del mismo clúster. El equipo de cuentas despliega servicios frontales, de fondo y de base de datos
para la app Srv1 en el espacio de nombres de cuentas. El equipo de finanzas despliega servicios frontales, de fondo y de base de datos para la app Srv2 en el espacio de nombres de finanzas. Ambos equipos etiquetan cada servicio con una etiqueta
app: Srv1 o app: Srv2 y con la etiqueta tier: frontend, tier: backend o tier: db. También etiquetan los espacios de nombres con la etiqueta usage: accounts o usage: finance.
El equipo de finanzas Srv2 necesita realizar una llamada a la información procedente del programa de fondo Srv1 del equipo de cuentas. Por lo tanto, el equipo de cuentas crea una política de red de Kubernetes que utiliza etiquetas para permitir todo el tráfico procedente del espacio de nombres de finanzas en el programa de fondo Srv1 en el espacio de nombres de cuentas. El equipo también especifica el puerto 3111 para aislar el acceso solo a través de dicho puerto.
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
Namespace: accounts
name: accounts-allow
spec:
podSelector:
matchLabels:
app: Srv1
Tier: backend
ingress:
- from:
- NamespaceSelector:
matchLabels:
usage: finance
ports:
port: 3111
La sección spec.podSelector.matchLabels lista las etiquetas para el servicio de fondo de Srv1, para que la política se aplique solo a esos pods. La sección spec.ingress.from.NamespaceSelector.matchLabels lista
la etiqueta del espacio de nombres de finanzas para que la entrada solo esté permitida desde los servicios en dicho espacio de nombres.
Ahora el tráfico puede fluir entre los microservicios financieros y el programa de fondo de cuentas Srv1. El programa de fondo Srv1 de cuentas puede responder a los microservicios de finanzas, pero no puede establecer una conexión de tráfico inversa.
En este ejemplo, se permite todo el tráfico procedente de todos los microservicios del espacio de nombres de finanzas. No puede permitir el tráfico procedente de pods específicos de una app a otro espacio de nombres porque podSelector y namespaceSelector no se pueden combinar.