Listas blancas de direcciones IP en Kubernetes: Lo que aprendimos

Linode El ingeniero de sistemas Jon "jfred" Frederickson comparte su experiencia en la creación de la función de listas blancas de IP para ejecutar Kubernetes en Linode.

A medida que el equipo de ingeniería de Linodefue creando nuestras funciones de Kubernetes, nos encontramos con muchos obstáculos, como era de esperar. Sin embargo, surgió un reto que no habíamos previsto: cómo poner en lista blanca las aplicaciones que se ejecutan en Kubernetes en la infraestructura que ya tenemos.

Aquí, en Linode, ejecutamos varias aplicaciones internas. Mediante reglas de cortafuegos, estas aplicaciones son accesibles sólo a las redes y sistemas que lo necesitan.

Si tienes una aplicación con su propia base de datos, esa base de datos probablemente sólo necesita ser accesible por las instancias de esa aplicación. Si ambos se ejecutan en un clúster de Kubernetes, eso es bastante simple; NetworkPolicies le permiten bloquear eso. Por otro lado, si un servicio se ejecuta fuera del clúster, las cosas empiezan a complicarse.

Ya teníamos cierta automatización en torno a las listas blancas de IP, pero los clústeres de Kubernetes tienen el potencial de ser más dinámicos que cualquier otra cosa en nuestra infraestructura hasta ahora. Por eso necesitábamos asegurarnos de que podíamos mantener nuestras listas blancas actualizadas a medida que se añadían y eliminaban nodos de los clústeres. Nos imaginamos que esto debe ser un problema bastante común para cualquiera que introduzca Kubernetes en una infraestructura existente, pero no descubrimos ninguna otra solución pública para el problema.

El problema

Mi reto era, si quería poner en lista blanca todos los nodos de un cluster específico en un servidor externo al cluster, ¿cómo sería mi configuración ideal?

Sin una herramienta compatible con Kubernetes, me vería obligado a incluir manualmente en la lista blanca las direcciones IP individuales de los nodos del clúster, una por una. Esto no solo lleva mucho tiempo, sino que introduce más posibilidades de error humano, lo que supone un gran obstáculo en el proceso de desarrollo.

La solución

Durante las siguientes dos semanas construí una solución que (en su mayor parte) hace que la lista blanca de un clúster Kubernetes sea tan simple como la lista blanca manual de una sola IP.

Utilizamos Salt para gestionar nuestra infraestructura, y ya teníamos una fórmula de Salt para gestionar las reglas del cortafuegos. Entre la infraestructura inscrita en Salt, ya contábamos con mecanismos para encontrar sistemas de una clase determinada al construir listas blancas, así que buscábamos algo similar para nuestros clústeres Kubernetes.

Salt es extremadamente flexible y facilita la escritura de módulos personalizados. Por ejemplo, nuestra fórmula de iptables utiliza uno para generar reglas de iptables a partir de la configuración por nodo de Salt(datos de "pilar"). Hacemos esto construyendo una regla a la vez desde una lista de reglas almacenadas en pillar. Es un montón de concatenación de cadenas, que hay que admitir que se ve un poco feo. Por suerte, el formato de las reglas de iptables es lo suficientemente estable como para que acabe funcionando bastante bien. Aquí hay un fragmento de lo que parece:

Gracias a la flexibilidad de Kubernetes API, esta integración no fue tan difícil conceptualmente. Esencialmente, añadimos un nuevo tipo de regla para los clústeres K8s: cuando la fórmula encuentra una regla de ese tipo, llega a ese clúster para obtener las IPs de sus nodos, las almacena en caché localmente, e inserta reglas iptables para cada IP. El almacenamiento en caché es para asegurar que los fallos intermitentes de la red no causen problemas. Esto es lo que se ve al usarlo:

¿Qué es lo siguiente?

En última instancia, me gustaría abrir el código abierto a toda la fórmula para desarrollar aún más la capacidad de la herramienta con la ayuda de la comunidad Linode.

El siguiente paso, sin embargo, es hacer que estas reglas se actualicen automáticamente a medida que nuevos nodos se unen y abandonan un clúster. El objetivo es que la creación de una lista blanca persistente en un clúster sea tan sencilla como la creación de una lista blanca para una sola IP, pero aún no lo hemos conseguido.

Tal y como está ahora la fórmula, recogerá nuevos nodos sólo cuando se aplique la configuración del cortafuegos, pero no automáticamente. Esto no es un gran problema, ya que podemos solucionarlo reaplicando periódicamente la configuración del cortafuegos.

Sin embargo, me gustaría encontrar una manera de hacerlo más reactivo. Mi mecanismo previsto escucharía ese evento (la creación de un nuevo objeto Node en Kubernetes) y activaría una actualización (probablemente a través del bus de eventos Salt ). Idealmente, esto no requeriría ningún paso manual aparte de la configuración de una regla de firewall de Kubernetes. Tal vez una vez que la fórmula sea de código abierto puedas ayudarnos a resolverlo.

Por ahora, estoy muy contento con lo que hemos creado y creo que será una ventaja para los usuarios de Linode que experimentan con Kubernetes.

Gracias por conocer el proceso de ingeniería de sistemas de Linode. Por favor, hazme saber en la sección de comentarios si tienes alguna pregunta sobre lo que hicimos.

¿Está interesado en Kubernetes en Linode?

Nuestro equipo se enorgullece de presentar la versión beta de Linode Kubernetes Engine (LKE), un motor de orquestación de contenedores totalmente gestionado para desplegar y gestionar aplicaciones y cargas de trabajo en contenedores.

Pero necesitamos tus comentarios. Inscríbete en la beta de LKE aquí para probarla y ganar un botín gratuito de Linode .