Así que ha oído hablar de esta cosa llamada cgroups y está interesado en obtener más información. Quizás captó la mención mientras escuchaba una charla sobre contenedorización. Tal vez estaba investigando el ajuste del rendimiento de Linux, o tal vez un día estaba atravesando su sistema de archivos y descubrió /sys/fs/cgroups . De cualquier manera, desea obtener más información sobre esta funcionalidad que se ha integrado en el kernel durante bastante tiempo. Así que siéntate, toma unas palomitas de maíz y prepárate para (con suerte) aprender algo que tal vez no sabías antes.
¿Qué son los grupos c?
El diccionario Webster define cgroups como... Es broma. Siempre odié escuchar charlas que comenzaban con aburridas definiciones de diccionario. En cambio, intentaré destilar la definición técnica de cgroups en algo fácil de entender.
Los Cgroups son un tema enorme. He dividido esta discusión en una serie de cuatro partes. La primera parte, este artículo, cubre los conceptos fundamentales de cgroups. La segunda parte examina CPUShare con mayor profundidad. La tercera parte, titulada "Haciendo cgroups de la manera difícil", analiza las tareas administrativas de cgroup. Finalmente, la cuarta parte cubre cgroups administrados por systemd.
Como puede que sepa o no, el kernel de Linux es responsable de que todo el hardware interactúe de manera confiable en un sistema. Eso significa que, además de los bits de código (controladores) que permiten que el sistema operativo (OS) comprenda el hardware, también establece límites sobre la cantidad de recursos que un programa en particular puede demandar del sistema. Esto se entiende más fácilmente cuando se habla de la cantidad de memoria (RAM) que un sistema tiene que dividir entre todas las aplicaciones que puede ejecutar su computadora. En su forma más básica, un sistema Linux puede ejecutar la mayoría de las aplicaciones sin restricciones. Esto puede ser excelente para la informática en general si todas las aplicaciones funcionan bien juntas. Pero, ¿qué sucede si hay un error en un programa y comienza a consumir toda la memoria disponible? El kernel tiene una función llamada Out Of Memory (OOM) Killer. Su trabajo es detener las aplicaciones para liberar suficiente RAM para que el sistema operativo pueda continuar funcionando sin bloquearse.
Eso es genial, dices, pero ¿qué tiene esto que ver con cgroups? Bueno, el proceso OOM actúa como una última línea de defensa antes de que su sistema se derrumbe a su alrededor. Es útil hasta cierto punto, pero dado que el kernel puede controlar qué procesos deben sobrevivir al OOM, también puede determinar qué aplicaciones no pueden consumir demasiada RAM en primer lugar.
Los Cgroups son, por lo tanto, una función integrada en el núcleo que permite al administrador establecer límites de utilización de recursos en cualquier proceso del sistema. En general, cgroups controla:
- El número de recursos compartidos de CPU por proceso.
- Los límites de memoria por proceso.
- E/S de dispositivo de bloque por proceso.
- Qué paquetes de red se identifican como del mismo tipo para que otra aplicación pueda hacer cumplir las reglas de tráfico de la red.
Hay más facetas además de estas, pero esas son las principales categorías que preocupan a la mayoría de los administradores.
Los humildes comienzos de Cgroups
Los grupos de control (cgroups) son un mecanismo del kernel de Linux para el control detallado de los recursos. Presentado originalmente por los ingenieros de Google en 2006, cgroups finalmente se fusionó con el kernel de Linux alrededor de 2007. Si bien actualmente hay dos versiones de cgroups, la mayoría de las distribuciones y mecanismos usan la versión 1, ya que ha estado en el kernel desde 2.6.24. Al igual que con la mayoría de las cosas añadidas al núcleo de la línea principal, no hubo una gran tasa de adopción al principio. La versión 2 continúa con esta tendencia, ya que existe desde hace casi media década, pero aún no se implementa ampliamente.
Un problema que afecta la adopción de cgroup es la falta de conocimiento de su existencia y su papel en el sistema Linux moderno. La poca conciencia y adopción a menudo significa que la interacción con una interfaz de kernel es torpe, enrevesada o simplemente un proceso manual. Tal fue el caso con cgroups inicialmente. Claro, no es tan difícil crear cgroups únicos. Por ejemplo, si quisiera simular los primeros días antes de que se desarrollaran las herramientas en torno a cgroups, podría crear un montón de directorios, montar el cgroup sistema de archivos y comience a configurar todo a mano. Pero antes de llegar a todo eso, hablemos un poco sobre por qué Los cgroups son vitales en el ecosistema Linux actual.
Por qué son importantes los cgroups
Los Cgroups tienen cuatro características principales estrechamente relacionadas entre sí que las hacen muy importantes en un sistema moderno, especialmente si está ejecutando una carga de trabajo en contenedores.
1. Limitación de recursos
Como se mencionó anteriormente, los cgroups permiten que un administrador se asegure de que los programas que se ejecutan en el sistema permanezcan dentro de ciertos límites aceptables para CPU, RAM, E/S de dispositivos de bloque y grupos de dispositivos.
NOTA :Los grupos de dispositivos CGroup pueden ser un componente clave en la estrategia de seguridad integral de su sistema. Los grupos de dispositivos incluyen permisos de control para lectura, escritura y mknod operaciones. Las operaciones de lectura/escritura se explican por sí mismas, así que tomemos un momento para ver el mknod funcionalidad en un sistema Linux. mknod fue inicialmente diseñado para llenar todas las cosas que aparecen en /dev/ . Estas son cosas como discos duros, interfaces USB para dispositivos como Arduino, microcontroladores ESP8266 u otros dispositivos que puedan existir en un sistema. La mayoría de los sistemas Linux modernos usan udev para llenar automáticamente este sistema de archivos virtual con cosas detectadas por el kernel. mknod también permite que varios programas se comuniquen entre sí mediante la creación de una canalización con nombre. Este concepto está más allá del alcance de esta explicación, pero es suficiente para entender que esto facilita pasar información de un programa a otro. Independientemente, el mknod en un entorno controlado es algo que un administrador debe considerar restringir.
2. Priorización
La priorización es ligeramente diferente a la limitación de recursos porque no está restringiendo necesariamente los procesos. En cambio, simplemente está diciendo que, independientemente de cuántos recursos estén disponibles, procese X siempre tendrá más tiempo en el sistema que el proceso Y .
3. Contabilidad
Si bien la contabilidad está desactivada de forma predeterminada para la mayoría de las versiones empresariales de Linux debido a la utilización de recursos adicionales, puede ser muy útil activar la utilización de recursos para un árbol en particular (más sobre esto más adelante). Por lo tanto, puede ver qué procesos dentro de qué cgroup están consumiendo qué tipos o recursos.
4. Control de procesos
Hay una instalación en cgroups llamada freezer . Si bien una comprensión profunda de esta funcionalidad está fuera del alcance de este artículo, puede pensar en el congelador como la capacidad de tomar una instantánea de un proceso en particular y moverlo. Consulte la documentación del núcleo para obtener una comprensión más profunda.
Bien, entonces, ¿qué significa todo esto? Bueno, desde la perspectiva de un administrador de sistemas, significa varias cosas.
En primer lugar, incluso sin profundizar en la tecnología de contenedores, significa que puede lograr una mayor densidad en un solo servidor administrando cuidadosamente el tipo de carga de trabajo, las aplicaciones y los recursos que requieren.
En segundo lugar, mejora bastante su postura de seguridad. Si bien una instalación típica de Linux usa cgroups de forma predeterminada, no impone restricciones a los procesos. Puede imponer restricciones de forma predeterminada si así lo desea. También puede restringir el acceso a dispositivos específicos para usuarios, grupos o procesos específicos, lo que ayuda aún más a bloquear un sistema.
Finalmente, puede realizar una cantidad significativa de ajustes de rendimiento a través de cgroups. Eso, en combinación con tuned, significa que puede crear un entorno ajustado específicamente para sus cargas de trabajo individuales. A escala, o en un entorno sensible a la latencia, estos ajustes pueden significar la diferencia entre cumplir o no cumplir con sus Acuerdos de nivel de servicio (SLA).
¿Cómo funcionan los grupos c?
A los efectos de esta discusión, estamos hablando de cgroups V1 . Si bien la versión 2 está disponible en Red Hat Enterprise Linux 8 (RHEL 8), está deshabilitada de manera predeterminada. La mayoría de las tecnologías de contenedores como Kubernetes, OpenShift, Docker, etc. todavía dependen de la versión 1 de cgroups.
Ya hemos discutido que los cgroups son un mecanismo para controlar ciertos subsistemas en el núcleo. Estos subsistemas, como dispositivos, CPU, RAM, acceso a la red, etc., se denominan controladores. en la terminología de cgroup.
Cada tipo de controlador (cpu , blkio , memory , etc.) se subdivide en una estructura similar a un árbol. Cada rama u hoja tiene sus propios pesos o límites. Un grupo de control tiene varios procesos asociados, lo que hace que la utilización de recursos sea granular y fácil de ajustar.
NOTA :Cada hijo hereda y está restringido por los límites establecidos en el cgroup padre.
En el diagrama anterior, puede ver que es posible tener PID 1 en memory , disk i/o y cpu grupos de control Los cgroups se crean por tipo de recurso y no tienen asociación entre sí. Eso significa que podrías tener una database grupo asociado con todos los controladores, pero los grupos se tratan de forma independiente. Al igual que los GID, a estos grupos se les asigna un valor numérico en el momento de la creación y no un nombre descriptivo. Debajo del capó, el kernel usa estos valores para determinar la asignación de recursos. Para pensarlo de otra manera, suponga que cada nombre de cgroup, una vez adjunto a un controlador, se renombra al nombre del controlador más el nombre de su elección. Así que un grupo llamado database en la memory en realidad, se puede pensar que el controlador es memory-database . Por lo tanto, no hay relación con una database grupo asociado con el controlador cpu ya que el nombre descriptivo se puede considerar como cpu-database .
NOTA :Esta es una gran simplificación y NO es técnicamente precisa si desea involucrarse con el código cgroup subyacente. La explicación anterior está destinada a la claridad de comprensión.
Resumir
Así que ahora tiene una idea de qué son los cgroups y cómo pueden ayudarlo con el ajuste del rendimiento y la seguridad. También tiene una mejor comprensión de cómo interactúan los cgroups con los controladores.
Este artículo no es un desglose de todos los tipos de controladores que existen en cgroups. Algo en esa escala tomaría un libro entero para explicarlo correctamente. En el próximo artículo, analizo los CPUShares debido a su relativa complejidad y la importancia que tienen en la salud general de un sistema. Los otros controladores funcionan de manera similar. Por lo tanto, debería poder tomar las lecciones aprendidas del controlador de la CPU y aplicarlas a la mayoría de los controladores de cgroup restantes.
No olvide que en la parte tres examinaremos las tareas administrativas y en la cuarta parte terminaremos con la forma en que systemd interactúa con cgroups.
[ ¿Empezando con los contenedores? Consulta este curso gratuito. Implementación de aplicaciones en contenedores:una descripción técnica general. ]