Docker&k8s (I)

? La función principal de la tecnología de contenedores es crear "límites" para los procesos restringiendo y modificando su comportamiento dinámico. Para la mayoría de los contenedores de Linux (como Docker), la tecnología Cgroups es el medio principal para crear límites y la tecnología Namespace es el medio principal para modificar las vistas de procesos.

En realidad, es solo un parámetro opcional para que Linux cree un nuevo proceso. Sabemos que la llamada al sistema para crear un hilo en un sistema Linux es clone(), por ejemplo:

? Esta llamada al sistema creará un nuevo proceso para nosotros y devolverá su número de proceso pid. Cuando usamos la llamada al sistema clone() para crear un nuevo proceso, podemos especificar el parámetro CLONE_NEWPID en los parámetros, por ejemplo:

En este momento, el proceso recién creado "verá" un nuevo proceso. espacio de proceso, su PID es 1. La razón por la que digo "ver" es porque es sólo un "encubrimiento". Digo "ver" porque esto es sólo un "encubrimiento"; en el espacio de proceso real del host, el PID del proceso sigue siendo un valor real, como 100.

? Además del espacio de nombres PID, el sistema operativo Linux también proporciona espacios de nombres de montaje, UTS, IPC, red y usuario, que se utilizan para enmascarar varios contextos de proceso.

Por ejemplo, el espacio de nombres Montaje se usa para permitir que un proceso aislado vea solo información del punto de montaje en el espacio de nombres actual, mientras que el espacio de nombres Red se usa para permitir que un proceso aislado vea dispositivos y configuraciones de red en el espacio de nombres actual.

? Esta es la implementación más básica de contenedores de Linux. Por lo tanto, el contenedor es en realidad un proceso especial y la tecnología de espacio de nombres en realidad modifica la forma en que el proceso de la aplicación ve toda la computadora, es decir, su vista está limitada por el sistema operativo y solo puede "ver" cierta cosa.

Ventajas: Más ligero, no consume recursos. Los Cgroups (Grupos de control de Linux) son una característica importante del kernel de Linux que se utiliza para establecer límites de recursos para los procesos. Su función principal es limitar los recursos que puede utilizar un grupo de procesos, incluyendo CPU, memoria, disco, ancho de banda de red, etc.

La interfaz expuesta a los usuarios por Cgroups es el sistema de archivos

Por ejemplo, si escribe en el archivo cfs_quota en el grupo contenedor durante 20 milisegundos (20000 us):

Por ejemplo, escribir 20 milisegundos (20000 us) en el archivo cfs_quota en el grupo contenedor:

Esto significa que cada 100 milisegundos, el proceso restringido por el grupo de control solo puede usar 20 milisegundos de Tiempo de CPU, es decir, el proceso Solo se puede utilizar el 20 del ancho de banda de la CPU.

Escriba el PID del proceso restringido en el archivo de tareas en el grupo de contenedores y la configuración anterior tendrá efecto en el proceso:

Excepto el subsistema de CPU, todos los subsistemas en Cgroups Tiene sus propias características únicas de restricción de recursos, tales como:

Los Cgroups de Linux están diseñados para ser simples y fáciles de usar. Diseñados para ser relativamente simples de usar, los Cgroups de Linux son una combinación de un directorio de subsistema y un conjunto de archivos de restricción de recursos. Los contenedores son un modelo de "proceso único".

? El espacio de nombres de montaje modifica la vista del proceso contenedor del "punto de montaje" del sistema de archivos. El uso del espacio de nombres de montaje es ligeramente diferente de otros espacios de nombres porque cambia la vista del proceso contenedor del sistema de archivos en un. forma ligeramente diferente. Sólo tiene efecto con la operación de montaje (montaje).

De hecho, el espacio de nombres Mount se inventó basándose en mejoras en chroot y es el primer espacio de nombres en el sistema operativo Linux.

? El sistema de archivos montado en el directorio raíz del contenedor para proporcionar un entorno de ejecución aislado para el proceso del contenedor se denomina imagen de contenedor. También tiene un nombre más profesional: rootfs.

Como núcleo del proyecto Docker, en realidad es solo una forma de crear un proceso de usuario:

? rootfs son solo los archivos, configuraciones y directorios contenidos en el sistema operativo. no el kernel del sistema operativo. En el sistema operativo Linux, estas dos partes se almacenan por separado y el sistema operativo solo cargará la versión especificada de la imagen del kernel al inicio.

El rootfs del contenedor se compone de tres partes, como se muestra en la siguiente figura:

La primera parte, la capa de solo lectura: estas son las cinco capas inferiores del contenedor rootfs, correspondiente a la imagen ubuntu:latest. Estas cinco capas se cargan en modo de solo lectura (ro wh, es decir, whiteout de solo lectura)

Cada una de estas capas contiene incrementalmente una parte del sistema operativo Ubuntu

Segunda Parte, capa de lectura y escritura. (rw)

? El directorio está vacío antes de escribir el archivo. Una vez que realice una operación de escritura en el contenedor, el contenido resultante de su modificación aparecerá de forma incremental en esta capa. Si desea eliminar AuFS, crea un archivo en blanco en la capa de lectura y escritura para "enmascarar" el archivo en la capa de solo lectura.

Esto se utilizará para almacenar los cambios incrementales que realices en los rootfs, dejando intacta la capa original de solo lectura.

Parte 3, la capa inicial.

Debido a que los usuarios necesitan escribir ciertos valores específicos (como el nombre de host) al iniciar el contenedor, algunos archivos que pertenecen a la imagen de Ubuntu de solo lectura deben modificarse en la capa de lectura y escritura. Sin embargo, estas modificaciones generalmente solo son válidas para el contenedor actual y no queremos enviar esta información junto con la capa de lectura y escritura cuando realizamos el envío de la ventana acoplable. Entonces lo que hace Docker es cargar estos archivos como una capa separada después de modificarlos. El usuario que realiza la confirmación de la ventana acoplable solo confirmará la capa de lectura/escritura, por lo que esta información no se incluirá. Vea el concepto que git ignora.

Dockerfile:

Punto de entrada: El punto de entrada es el nombre del archivo ejecutable utilizado para definir el inicio del contenedor. "

CMDT.

CMD: cmd proporciona el ejecutable predeterminado del contenedor. Es el comando predeterminado que se ejecutará cuando se inicie el contenedor. Si Docker Run no especifica ningún ejecutable , o no hay un punto de entrada en el archivo docker, se utilizará el archivo ejecutable predeterminado especificado por cmd para la ejecución. Siempre que lo especifique, cmd no se ejecutará, es decir, cmd se sobrescribirá

<. p> docker commit en realidad agrega la "capa de lectura y escritura" en la parte superior del contenedor a la capa de solo lectura de la imagen del contenedor original después de que el contenedor está en funcionamiento, y la empaqueta en una nueva imagen. -solo las capas están en el contenedor en el host y no ocuparán ningún espacio adicional.

Debido a la existencia del sistema de archivos de unión, cualquier cambio que realice en la imagen del contenedor rootfs se copiará primero. esta capa de lectura y escritura por el sistema operativo y luego modificarla. Esto se llama

? Cada espacio de nombres de Linux del proceso tiene un archivo virtual correspondiente en su correspondiente /proc/[número de proceso]/ns. , y está asociado con un espacio de nombres real. Los archivos están conectados.

? Esto significa que un proceso puede elegir unirse al espacio de nombres existente del proceso para "ingresar" al contenedor del proceso, que es exactamente lo que hace Docker Exec.

El mecanismo de volumen le permite montar directorios o archivos específicos en el host en un contenedor para su lectura y modificación.

? Después de crear un proceso contenedor, antes de realizar chroot (o pivot_root), puede ver todo el sistema de archivos en el host, incluso si Mount Namespace está habilitado. Por lo tanto, cuando rootfs esté listo, antes de ejecutar chroot, primero monte el directorio de host especificado por Volumen (por ejemplo, el directorio /home) en el directorio contenedor especificado (por ejemplo, /var/lib/docker/aufs/mnt/[Read/ Escriba ID de capa]/prueba) en el host (por ejemplo, /prueba).

? Dado que el proceso contenedor se creó durante el montaje, se abrió el espacio de nombres de montaje. Por lo tanto, sólo el contenedor puede ver el evento de montaje. El punto de montaje dentro del contenedor no es visible en el host. Esto asegurará que el volumen no rompa el aislamiento del contenedor.

? La tecnología de montaje utilizada aquí es el mecanismo de montaje vinculado de Linux. Le permite montar un directorio o archivo en lugar de todo el dispositivo en un directorio específico. Cualquier operación que realice en este punto de montaje solo ocurrirá en el directorio o archivo montado, y el contenido del punto de montaje original estará oculto y no se verá afectado. Bind mount es en realidad un proceso de reemplazo de inodos. En el sistema operativo Linux, un inodo puede considerarse como un "objeto" que contiene el contenido de un archivo, y una entrada de directorio o dentry es un "puntero" a ese inodo.

? Por lo tanto, siempre que se realice un montaje vinculado en el momento adecuado, Docker puede montar con éxito un directorio o archivo en el host en el contenedor sin ningún problema.