Hola habrozhiteli! Recientemente publicamos un libro sobre Kubernetes versión 1.10. La publicación revisó el pasaje "Soluciones de red para Kubernetes"
La creación de redes es un tema extenso. Hay muchas formas de configurar una red con dispositivos, hogares y contenedores. Kubernetes no te limita a esto. Todo lo que esta plataforma prescribe es un modelo de red de alto nivel con un espacio de direcciones plano para hogares. Dentro de este espacio, puede implementar muchas buenas soluciones con diferentes capacidades y para diferentes entornos. En esta sección, veremos algunos de ellos e intentaremos comprender cómo encajan en el modelo de red de Kubernetes.
Crear puentes en grupos de hardware
El entorno más simple es un clúster desnudo, que es una red física normal de nivel L2. Para conectar contenedores a dicha red, puede usar el puente Linux estándar. Este es un procedimiento bastante laborioso que requiere experiencia con comandos de red Linux de bajo nivel, como brctl, ip addr, ip route, ip link, nsenter, etc. Puede comenzar a implementar dicha solución leyendo la siguiente guía: blog.oddbit.com/
2014/08/11 / four-ways-to-connect-a-docker / (busque la sección Con dispositivos con puente de Linux).
Contiv
Contiv es un complemento de red de uso general. Está diseñado para conectar contenedores a través de CNI y puede usarse con Docker (directamente), Mesos, Docker Swarm y, naturalmente, Kubernetes. Contiv se ocupa de las políticas de red y duplica parcialmente un objeto similar en Kubernetes. Las siguientes son algunas de las características de este complemento de red:
- soporte para CNM en libnetwork y la especificación CNI;
- Un motor de políticas rico en funciones que proporciona seguridad e implementación de aplicaciones predecible.
- el mejor rendimiento de contenedor de su clase;
- multipropiedad, aislamiento y subredes superpuestas;
- Integración de IPAM y descubrimiento de servicios;
- Amplia selección de topologías físicas:
a) protocolos de capa 2 (VLAN);
b) protocolos de capa 3 (BGP);
c) redes superpuestas;
d) Cisco SDN (ACI); - Soporte IPv6;
- política escalable y asignación de ruta;
- Integración con plantillas de aplicaciones, incluidas las siguientes:
a) Docker-componer;
b) gestor de despliegue de Kubernetes;
c) equilibrio de carga en servicios, integrado en el equilibrador de microservicios del tipo "este - oeste" (este - oeste);
d) aislamiento del tráfico durante el almacenamiento, control de acceso (por ejemplo, etcd / cónsul), transmisión y gestión de la red.
Contiv tiene muchas características. Esta herramienta implementa una amplia gama de tareas y admite varias plataformas, por lo que no estoy seguro de si será la mejor opción para Kubernetes.
Abra vswitch
Open vSwitch es una solución madura para crear conmutadores virtuales (software), con el apoyo de muchos jugadores importantes en el mercado. El sistema Open Virtualization Network (OVN) le permite construir varias topologías de red virtual. Tiene un complemento especial para Kubernetes, pero es muy difícil de configurar (consulte el manual
github.com/openvswitch/ovn-kubernetes ). El complemento Linen CNI tiene menos funciones, pero su configuración es mucho más fácil:
github.com/John-Lin/linen-cni . La estructura CNI de lino se muestra en la Fig. 10.6
Open vSwitch puede integrar servidores físicos, máquinas virtuales y pods / contenedores en una única red lógica. Este sistema admite modos de superposición y físicos.
Estas son algunas de sus características clave:
- VLAN 802.1Q estándar con troncales y puertos públicos
- NIC vinculante con o sin LACP para un interruptor de nivel superior
- NetFlow, sFlow® y espejo para una mejor visibilidad;
- Configuración de QoS (calidad de servicio) más políticas;
- tunelización a través de Geneve, GRE, VXLAN, STT y LISP;
- romper el control en 802.1ag;
- OpenFlow 1.0 más numerosos complementos;
- base de datos transaccional para almacenar la configuración con enlaces para C y Python;
- redirección de alto rendimiento utilizando módulos de kernel de Linux.
Nuage Networks VCS
Virtualized Cloud Services (VCS) es un producto de Nuage, que es una plataforma escalable y basada en políticas para construir redes definidas por software (Networking Defined Software, SDN). Esta es una solución de nivel empresarial, que se basa en el sistema abierto Open vSwitch (para la redirección de datos) y un controlador SDN multifuncional basado en estándares abiertos.
La plataforma Nuage combina pods de Kubernetes y entornos de terceros (virtuales y hardware) en redes de superposición transparentes y le permite describir políticas detalladas para diferentes aplicaciones. Su motor de análisis en tiempo real le permite controlar la visibilidad y la seguridad de las aplicaciones de Kubernetes.
Además, todos los componentes de VCS se pueden instalar como contenedores. No hay requisitos de hardware específicos.
Canal
Canal es una mezcla de dos proyectos de código abierto: Calico y Flannel. De ahí el nombre. El proyecto Flannel, desarrollado por el equipo CoreOS, se ocupa de las capacidades de red de los contenedores, mientras que Calico es responsable de las políticas de red. Inicialmente, se desarrollaron por separado, pero los usuarios querían usarlos juntos. El proyecto de código abierto de Canal ahora es una plantilla de implementación para instalar Calico y Flannel como complementos CNI separados. Creado por los fundadores de Calico, Tigera ha apoyado ambos proyectos e incluso planeó una integración más estrecha, pero desde que lanzó su propia solución para redes seguras entre aplicaciones en Kubernetes, la prioridad se ha desplazado hacia la simplificación de la configuración e integración de Flannel y Calico en lugar de desarrollar una solución unificada. En la fig. 10.7 muestra el estado actual del sistema del Canal y cómo se relaciona con las plataformas de orquestación como Kubernetes y Mesos.
Tenga en cuenta que cuando se integra con Kubernetes, Canal no accede a etcd directamente, sino al servidor API de Kubernetes.
Franela
Flannel es una red virtual que proporciona a cada nodo una red virtual para trabajar con tiempos de ejecución de contenedor. En cada nodo, se inicia el agente flaneld, elevando la subred en función del espacio de direcciones reservado almacenado en el clúster etcd. El intercambio de paquetes entre contenedores y, en general, el nodo lo realiza uno de varios servidores. Muy a menudo, el servidor usa UDP sobre el dispositivo TUN, que de forma predeterminada canaliza el tráfico a través del puerto 8285 (no olvide abrirlo en su firewall).
En la fig. 10.8 describe en detalle los diversos componentes de la red Flannel, los dispositivos de red virtuales que crea y cómo se comunican con el host y el hogar a través del puente docker0. Aquí también puede ver el proceso de encapsulación de paquetes UDP y su movimiento entre nodos.
Se admiten otras tecnologías de red:
- vxlan - encapsula paquetes usando VXLAN dentro del kernel;
- host-gw: crea rutas IP a subredes a través de las direcciones IP del servidor remoto. Vale la pena señalar que esto requiere una conexión directa en la segunda capa de red entre los servidores que ejecutan Flannel;
- aws-vpc: crea rutas IP en la tabla de enrutamiento de Amazon VPC
- gce: crea rutas IP en la red de Google Compute Engine
- alloc: realiza solo la selección de la subred, pero no la redirección de paquetes;
- ali-vpc: crea rutas IP en la tabla de enrutamiento VPC de Alicloud.
Proyecto Calico
Calico es una solución completa para redes entre contenedores y seguridad de red. Se puede integrar con todas las principales plataformas de orquestación y tiempos de ejecución:
- Kubernetes (complemento para CNI);
- Mesos (complemento para CNI);
- Docker (complemento para libnework);
- OpenStack (complemento para Neutron).
Calico también se puede implementar localmente o en una nube pública mientras se conservan todas las funciones. La aplicación de políticas de red puede depender de la carga, lo que proporciona un control claro del tráfico y garantiza que los paquetes siempre lleguen a los destinos deseados. Calico puede importar automáticamente políticas de red desde plataformas de orquestación. De hecho, es responsable de implementar políticas de red en Kubernetes.
Romana
Romana es una solución moderna para la creación de redes entre contenedores. Originalmente fue diseñado para su uso en la nube y opera en la tercera capa de red, basándose en métodos estándar para administrar direcciones IP. Romana le permite aislar redes enteras mediante la creación de puertas de enlace y rutas para ellos utilizando servidores basados en Linux. El trabajo en la tercera capa de red no requiere encapsulación. La política de red se aplica a todos los puntos finales y servicios como un firewall distribuido. Romana facilita las implementaciones locales e híbridas entre diferentes plataformas en la nube, ya que ya no necesita configurar redes de superposición virtual.
Recientemente aparecido en Romana, las direcciones IP virtuales permiten a los usuarios locales abrir el acceso a sus servicios en redes locales del segundo nivel, utilizando direcciones externas y especificaciones de servicio.
Los desarrolladores de Romana afirman que su enfoque mejora significativamente el rendimiento. En la fig. La Figura 10.9 muestra cómo, junto con evitar la encapsulación de VXLAN, puede eliminar una gran cantidad de sobrecarga.
Tejido de red
Las características principales del proyecto Weave Net son la facilidad de uso y la falta de configuración. Utiliza la encapsulación VXLAN e instala micro-DNS en cada nodo. Como desarrollador, se enfrentará a un alto nivel de abstracción. Después de nombrar sus contenedores, Weave Net le permitirá conectarse a puertos estándar y habilitar los servicios apropiados. Esto ayuda en la migración de aplicaciones existentes a plataformas de microservicio y contenedorización. Weave Net proporciona un complemento CNI para trabajar con Kubernetes y Mesos. Comenzando con Kubernetes 1.4, la integración con Weave Net se puede lograr con un solo comando que implementa DaemonSet:
kubectl apply -f https://git.io/weave-kube
Los pods Weave Net alojados en cada nodo son responsables de conectar cualquier otra instancia de pod a la red Weave. Weave Net admite API con políticas de red, proporcionando una solución completa y fácil de configurar.
Uso efectivo de las políticas de red.
La política de red de Kubernetes está diseñada para controlar el tráfico que se dirige a pods y espacios de nombres específicos. Cuando se administran cientos de microservicios implementados (como suele ser el caso con Kubernetes), las redes entre los hogares se destacan. Es importante comprender que este mecanismo solo está relacionado indirectamente con la seguridad. Si un atacante puede penetrar en la red interna, lo más probable es que pueda crear su propia instancia del hogar que cumpla con la política de red y permita la comunicación gratuita con otros hogares. En la sección anterior, analizamos varias soluciones de red en Kubernetes, centrándonos en las interfaces de red. Aquí nos centraremos en la política de red implementada sobre estas soluciones, aunque ambos componentes están estrechamente interconectados.
Arquitectura de políticas de red en Kubernetes
La política de red determina cómo los subconjuntos de hogares pueden interactuar entre sí y con otros puntos finales de la red. El recurso NetworkPolicy utiliza etiquetas para seleccionar hogares y define una lista de reglas de permisos que permiten que el tráfico se dirija a instancias de hogares seleccionadas (además de lo que ya está permitido por la política de aislamiento en el espacio de nombres dado).
»Se puede encontrar más información sobre el libro en
el sitio web del editor»
Contenidos»
ExtractoCupón de 20% de descuento para
Khabrozhitel -
KubernetesTras el pago de la versión en papel del libro, se envía una versión electrónica del libro por correo electrónico.
PD: el 7% del costo del libro se destinará a la traducción de nuevos libros de computadora, la lista de libros entregados a la imprenta está
aquí .