[Resumen] En la era del vigoroso desarrollo de la tecnología nativa de la nube, el contenedor que transporta la aplicación en la capa inferior es muy importante. Sin embargo, una sola tecnología de aislamiento de contenedor ya no puede cumplir con los requisitos de varios escenarios. Diferentes escenarios requieren diferentes formas de contenedores para llevar, dando como resultado diferentes técnicas de caja de arena. Basado en el historial de desarrollo de los contenedores de sandbox, este artículo presenta las ventajas del proyecto Kuasar en el tiempo de ejecución de contenedores de múltiples sandbox de Huawei Cloud, y demuestra la instalación y operación de Kuasar para que los desarrolladores comiencen la experiencia práctica del tiempo de ejecución de contenedores de múltiples sandbox. !
Directorio de artículos
prefacio
En la principal cumbre anual de código abierto nativo de la nube KubeCon + CloudNativeCon Europe 2023, Kuasar, un tiempo de ejecución de contenedor multi-sandbox nativo de la nube iniciado conjuntamente por Huawei Cloud, el Banco Agrícola de China, la comunidad openEuler y el proyecto WasmEdge de CNCF, anunció oficialmente su código abierto. Amplia atención y debates acalorados por parte de la comunidad y los proveedores de la nube.
El nuevo proyecto de código abierto nativo de la nube, Kuasar, combina los años de práctica comercial de producción de Huawei Cloud y el pensamiento sobre el desarrollo de la tecnología sandbox, y se implementa en función de la interfaz sandbox emergente de la industria. Sobre la base de conservar las funciones de tiempo de ejecución de contenedores tradicionales, Kuasar reduce aún más los gastos generales de administración, simplifica los enlaces de llamadas, amplía de manera flexible el soporte para las principales tecnologías de sandbox en la industria y realiza servicios nativos de la nube a través de Rustization integral y modelos y marcos de administración optimizados. la escena. Además, al admitir la implementación de co-nodo de sandbox de seguridad múltiple, Kuasar puede hacer un uso completo de los recursos del nodo, reducir costos y aumentar la eficiencia, y brindar a los usuarios una solución de escenario de sandbox más segura y eficiente.
Desarrollo de contenedores sandbox
edad del contenedor
Ya en 2013 nació docker, que marcó la llegada de la era de los contenedores. La tecnología de contenedor original en realidad utiliza el espacio de nombres y las funciones de grupo de control del grupo C proporcionadas por el kernel de Linux para lograr el aislamiento y la limitación de recursos entre los procesos del contenedor. En la era de los contenedores, los contenedores son los únicos ciudadanos de primera clase en Docker.
Pronto, en 2014, el campo de la orquestación de contenedores estaba compitiendo por la hegemonía. Cuando Kubernetes finalmente se convirtió en la principal herramienta de orquestación de contenedores, Pod también se convirtió en un ciudadano de primera clase en el campo de la orquestación de contenedores. Para ser compatible con el concepto de Pod, docker introdujo el contenedor de pausa.
Sin embargo, la introducción de contenedores de pausa a menudo confunde a los desarrolladores porque existen muchas diferencias entre los pods y los contenedores de pausa. En kubernetes, Pod es el portador de un conjunto de recursos lógicos y físicos del contenedor, mientras que el contenedor de pausa solo proporciona un espacio de nombres compartido entre contenedores. Además, hay muchas lógicas de juicio redundantes y complejas en el tiempo de ejecución del contenedor para distinguir entre contenedores de pausa y contenedores de usuario, lo que dificulta la lectura y el desarrollo del código.
En 2019, containerd se graduó de CNCF y se convirtió en el tiempo de ejecución de contenedores preferido en Kubernetes. De manera similar, containerd también necesita usar el contenedor de pausa para ejecutar un pod.
Dado que el contenedor runC comparte el kernel con el sistema host, una vez que el contenedor se escapa, especialmente en un escenario de múltiples inquilinos, traerá grandes riesgos de seguridad.
aumento de la caja de arena
Con la aparición de los problemas anteriores, también han surgido soluciones relacionadas una tras otra. En 2018, el campo nativo de la nube se está desarrollando rápidamente, se han aplicado muchas tecnologías de aislamiento de sandbox (Sandbox) al campo de contenedores y los contenedores de sandbox están en pleno apogeo. El contenedor sandbox restringe el proceso del contenedor en un entorno sandbox cerrado, evitando que cause daños al sistema y a otros contenedores, y tiene una seguridad extremadamente alta. La zona de pruebas se ajusta naturalmente a la definición de Pod. Proporciona un entorno aislado para un grupo de contenedores. Los contenedores que se ejecutan en el entorno de la zona de pruebas son contenedores de zona de pruebas .
De acuerdo con el límite del aislamiento de sandbox, se puede dividir en sandbox de máquina virtual ligera (MicroVM Sandbox), sandbox de kernel en modo de usuario (Application Kernel Sandbox) y WebAssembly sandbox (Wasm Sandbox). Todos son productos incubados para satisfacer diferentes necesidades comerciales, por lo que tienen sus propias ventajas en diferentes dimensiones.
-
Caja de arena de máquina virtual ligera (MicroVM Sandbox): simule un conjunto completo de máquinas virtuales en la máquina host y el contenedor se ejecuta en la máquina virtual, lo que tiene un efecto de aislamiento de seguridad muy alto.
-
Sandbox de kernel de estado de usuario (Application Kernel Sandbox): a través de un programa de kernel que se ejecuta en estado de usuario, intercepte y realice la llamada al sistema del contenedor, para garantizar el aislamiento de seguridad entre contenedores.
-
WebAssembly Sandbox (Wasm Sandbox): ejecute el contenedor en el tiempo de ejecución de WebAssembly, confiando en la capacidad de WebAssembly para proporcionar aislamiento a nivel de proceso.
Cada tipo de sandbox tiene sus propias ventajas en términos de velocidad extrema, flexibilidad, aislamiento de seguridad y dimensiones comunes estándar. En la actualidad, los proveedores de la nube han implementado productos de contenedores de sandbox en el entorno de producción, y cada sandbox implementa un conjunto de programas de plano de administración containerd Shim v2. no son compatibles entre sí.
En marzo de 2023, se lanzó una característica containerden su versión, que proporciona un conjunto de API para administrar sandboxes, su apariencia desacopla los conceptos de contenedores y sandboxes, "los contenedores pertenecen a contenedores y los sandboxes pertenecen a sandboxes", crear Pod es crear una caja de arena, ya no es necesario usar el contenedor pasue.v1.7.0Sandbox API
Los contenedores Sandbox se han convertido en una solución de seguridad en escenarios nativos de la nube. Esperamos utilizar el poder de la API de Sandbox para implementar un tiempo de ejecución de contenedor que admita múltiples tecnologías de sandbox.
Introducción al proyecto Kuasar
Descripción del Proyecto
La aparición de la API de Sandbox convierte al sandbox en un nuevo ciudadano de primera clase en el mundo de los contenedores. Necesitamos un tiempo de ejecución de contenedor que admita múltiples tecnologías de sandbox principales y tenga un mecanismo extensible, mantenible y evolutivo. Así nació Kuasar.
KubeCon + CloudNativeCon Europe 2023Huawei Cloud abrirá oficialmente Kuasar en la Cloud Native Summit que se llevará a cabo en Ámsterdam, Países Bajos, en abril de 2023 . Kuasar, el nuevo tiempo de ejecución de contenedor de espacio aislado múltiple de código abierto, puede hacer un uso completo de los recursos del nodo, reducir los costos y aumentar la eficiencia, y brindar a los usuarios una solución de escenario de espacio aislado más segura y eficiente.
Kuasar es un tiempo de ejecución de contenedores desarrollado en base al lenguaje Rust que puede soportar múltiples tecnologías de aislamiento de sandbox principales al mismo tiempo. Tiene las siguientes características:
- Apto para Sandbox : desarrollado en base a la interfaz API de Sandbox, que es diferente de la interfaz actual de Shim v2 y tiene ventajas naturales en la definición de sandbox y la gestión del ciclo de vida.
- Implementación mixta de sandbox múltiple : al integrar varias tecnologías de sandbox principales, puede ejecutar varios tipos diferentes de contenedores de sandbox en un solo nodo.
- Modelo simplificado : se adopta un modelo de gestión de procesos de contenedores 1: N. En comparación con el enfoque 1: 1 del proceso Shim actual, brinda una mejora de la velocidad de inicio del 100% y una optimización de la sobrecarga de memoria del 99%.
Dirección de Github : https://github.com/kuasar-io/kuasar
Sitio web oficial del proyecto : https://kuasar.io
Posicionamiento Kuasar
Kuasar es un tiempo de ejecución de contenedor de múltiples sandbox, entonces, ¿qué es un tiempo de ejecución de contenedor? En pocas palabras, el tiempo de ejecución del contenedor es un componente de tiempo de ejecución responsable de extraer el contenedor y administrar el estado de ejecución del contenedor. Se puede dividir en dos tipos: tiempo de ejecución del contenedor de alto nivel y tiempo de ejecución del contenedor de bajo nivel:
- Tiempo de ejecución de contenedores de alto nivel : responsable de la implementación de CRI, la gestión de contenedores e instancias de imágenes desde una perspectiva de alta dimensión, containerd, CRI-O, docker e iSulad son tiempos de ejecución de contenedores de alto nivel típicos.
- Tiempo de ejecución del contenedor de bajo nivel : responsable de la implementación de OCI y, de hecho, opera el contenedor. Kata-containers y runC son tiempos de ejecución de contenedores de bajo nivel.
Kuasar pertenece al tiempo de ejecución del contenedor de bajo nivel e interactúa con el tiempo de ejecución del contenedor de alto nivel containerd. Kuasar se compone principalmente de dos módulos:
- Kuasar-Sandboxer: implementa la API de Sandbox y es responsable de administrar el ciclo de vida del sandbox y la asignación de recursos. Sandboxer interactúa con containerd como complemento.
- Kuasar-Task: implementa la Task API y se encarga de gestionar el ciclo de vida y la asignación de recursos de los contenedores.
En la actualidad, en el nivel de interfaz norte, Kuasar está construyendo conjuntamente el último estándar de interfaz sandbox con containerd, y el complemento sandboxer se ha agregado a la hoja de ruta de la versión de containerd v2.0; además, el motor de contenedor ligero iSulad proyecto de También se ha completado la comunidad OpenEuler. En el nivel de sandbox hacia el sur, Kuasar ya es compatible con varios sandboxes de seguridad convencionales, incluidos Cloud Hypervisor (categoría MicroVM), WasmEdge (categoría Wasm), StratoVirt (categoría MicroVM) y Quark (categoría App Kernel). Y está previsto admitir más sandboxes en Roadmap , que pueden adaptarse a más escenarios nativos de la nube en el futuro.
Sandboxer de MicroVM
En el escenario de la máquina virtual ligera, el proceso de la máquina virtual proporciona una capa de virtualización completa y el kernel de Linux. Tales máquinas virtuales incluyen Cloud Hypervisor , StratoVirt , Firecracker y QEMU . En MicroVM Sandboxer, vmm-sandboxer es responsable de crear una máquina virtual y llamar a la API vmm-task ya que el proceso de inicio en la máquina virtual es responsable de iniciar el proceso del contenedor, y el flujo de E/S del contenedor se puede exportar a través del vsock o uds de la máquina virtual.
Actualmente solo se admiten Cloud Hypervisor, QEMU y StratoVirt.
Sandboxer del núcleo de la aplicación
App Kernel Sandbox integra profundamente la capa de virtualización KVM y el kernel invitado en un proceso de kernel en modo de usuario e implementa el aislamiento del contenedor al interceptar las llamadas del sistema del contenedor. Los representantes típicos incluyen gVisor y Quark.
Quark es un espacio aislado de App Kernel que utiliza su propio hipervisor QVisor y QKernel de kernel personalizado. QVisor solo es responsable de la gestión del ciclo de vida de la máquina virtual KVM y no simula ningún dispositivo. Qkernel intercepta todas las llamadas al sistema y notifica a QVisor que procese a través de VM_Exit o eventfd si es necesario. Al asignar el espacio de memoria del proceso del host al espacio de memoria física de la máquina virtual, se realiza el intercambio de memoria entre QVisor y QKernel.
El quark-sandboxer de App Kernel Sandboxer activa Qvisor y Qkernel. Siempre que containerd necesite iniciar un contenedor en el sandbox, quark-task en QVisor llamará a Qkernel para iniciar un nuevo contenedor. Todos los contenedores en el mismo Pod se ejecutarán en el mismo proceso.
Actualmente solo se admite Quark.
Wasm boxeador de arena
Si la zona de pruebas de App Kernel implementa un conjunto de tecnologías de zona de pruebas de aislamiento en los niveles de virtualización y kernel, entonces la zona de pruebas de WebAssembly define una nueva arquitectura, que incluye un conjunto de conjuntos de instrucciones y máquinas virtuales. Todos los programas deben compilarse en el conjunto de instrucciones de WebAssembly para ejecutarse en la máquina virtual de WebAssembly. Por lo tanto, existen requisitos elevados para las aplicaciones. Los sandbox comunes de Wasm incluyen WasmEdge y Wasmtime.
wasm-sandboxer y wasm-task lanzan contenedores dentro de un sandbox de WebAssembly. Cuando containerd necesita iniciar un contenedor en el espacio aislado, wasm-task bifurcará un nuevo proceso, iniciará un nuevo tiempo de ejecución de WasmEdge y ejecutará el código Wasm en él. Todos los contenedores en el mismo pod compartirán los mismos recursos de espacio de nombres y Cgroup con el proceso wasm-task.
Actualmente solo se admite WasmEdge. Sujeto a ciertas limitaciones técnicas (principalmente, la entrada y salida estándar no se pueden redirigir), wasm-task usa fork para iniciar un nuevo tiempo de ejecución. La evolución posterior puede optar por iniciar el tiempo de ejecución directamente en el proceso para lograr un inicio más rápido y un menor uso de memoria.
Cambios en el modelo de gestión de Kuasar
En el modelo actual de tiempo de ejecución de contenedores de Shim v2, cada vez que containerd crea un Pod, necesita crear un proceso de Shim correspondiente para la gestión de Pod, y el proceso de Shim luego crea máquinas virtuales y contenedores.En este escenario, el plano de gestión Shim La relación entre el número de procesos y Pods es 1:1.
Pero en Kuasar, solo se necesita ejecutar un proceso Kuasar-Sandboxer. Containerd administra Pods llamando a la interfaz expuesta por Sandboxer. Ya no es necesario abrir un proceso de administración para cada Pod. Por lo tanto, el plano de administración Sandboxer process y Pod La relación cuantitativa es 1: N. Este modelo puede reducir en gran medida la cantidad de procesos residentes y toda la arquitectura se vuelve más clara y concisa.
Kuasar cambia el modelo de gestión actual de Shim V2, trayendo los siguientes beneficios:
- La lógica de gestión de sandbox es clara : la lógica de gestión de sandbox y la lógica de gestión de contenedores están completamente separadas, lo que es fácil de desarrollar y tiene una semántica clara.
- Simplifique la cadena de llamadas del contenedor : cancele la conversión de Task API a Shim v2 API, llame directamente y simplifique el enlace.
- Proceso Sandboxer eficiente : el proceso Sandboxer residente reduce el tiempo que lleva arrancar en frío el proceso Shim, el modelo de gestión 1:N reduce en gran medida la cantidad de procesos y el programa Rust es seguro para la memoria, con menos gastos generales que Golang.
- El contenedor de pausa desaparece : la creación de un pod ya no crea un contenedor de pausa y ya no es necesario preparar una instantánea de la imagen del contenedor de pausa.
actuación
Entonces, ¿cuál es el rendimiento de Kuasar? Seleccione los dos indicadores más preocupados de " tiempo de inicio del contenedor de extremo a extremo " y " consumo de memoria del componente del plano de gestión " como los dos indicadores para medir el rendimiento de Kuasar. Las definiciones específicas son las siguientes:
- Tiempo de inicio de contenedor de extremo a extremo : en la implementación CRI de containerd v1.7.0, se abandona la práctica de disfrazar el sandbox como un contenedor, y las nuevas funciones de Sandbox API se utilizan para crear un sandbox e iniciar el contenedor. Por lo tanto, necesitamos usar CRI como punto de entrada, el tiempo de prueba real requerido para extraer un proceso de contenedor de principio a fin.
- Consumo de memoria de los componentes del plano de gestión : mida el consumo de memoria de los componentes de gestión (excluidas las máquinas virtuales), es decir, compare la memoria PSS (Tamaño de conjunto proporcional) del proceso Sandboxer y todos los procesos Shim v2. PSS es la memoria física realmente ocupada por un solo proceso cuando se está ejecutando, incluida la memoria ocupada por la biblioteca compartida después de haber sido asignada en proporción.
Controla las siguientes variables:
- VMM, el sistema operativo invitado (excepto el proceso de inicio) y el kernel invitado son coherentes.
- La imagen del contenedor es la misma y usa la instantánea de la imagen local directamente.
- Todos los controladores de almacenamiento de contenedores usan Overlayfs.
- La red de contenedores está en modo HostNetwork.
prueba de tiempo de arranque
La prueba de tiempo de inicio se divide en dos grupos, un grupo cuenta el tiempo de inicio de un solo Pod y el otro grupo cuenta el tiempo para iniciar 50 Pods en paralelo:
La mejora del 100 % en la velocidad de inicio de Kuasar se debe principalmente a dos aspectos: por un lado, la implementación de la API Sandbox hace que la creación de un contenedor ya no sea un contenedor de pausa separado, lo que ahorra tiempo para preparar instantáneas de imágenes de contenedores de pausa; , se beneficia del modelo de gestión 1:N, el proceso Sandboxer es residente, lo que ahorra el tiempo de arranque en frío del proceso Shim, lo que mejora considerablemente la velocidad de arranque del contenedor.
prueba de consumo de memoria
La prueba de consumo de memoria se divide en tres rondas, en cada ronda se inician 1, 5, 10, 20, 30 y 50 Pods y se consultan los valores PSS del proceso Sandboxer y todos los procesos Shim.
Kuasar ahorra casi el 99% de la memoria. Las razones se pueden dividir en dos puntos: la razón principal es que el modelo de gestión 1:N reduce N procesos a 1 proceso, y los beneficios de memoria que se obtienen son proporcionales a la cantidad de Pods; en segundo lugar, Kuasar adopta el lenguaje de programación The Rust, en comparación con el lenguaje Golang utilizado por el proceso Kata Shim, el lenguaje en sí también traerá algunos beneficios de memoria.
Instalación y despliegue de Kuasar
Pre-preparación
Antes de instalar y configurar, debe preparar lo siguiente:
Para conocer otros requisitos de construcción específicos, consulte el sitio web oficial y la dirección de Github:
Dirección oficial: https://kuasar.io/docs/developer/build/
Dirección de Github: https://github.com/kuasar-io/kuasar
Instalación y despliegue
Descargar y compilar desde la fuente
Para la instalación y la implementación, consulte la dirección de Github: https://github.com/kuasar-io/kuasar
Comando de operación:
git clone https://github.com/kuasar-io/kuasar.git
cd kuasar
make all
make install
Nota: La imagen del sistema operativo invitado debe compilarse en un contenedor, por lo que es necesario iniciar containerd u otros tiempos de ejecución de contenedores.
configurar cotainerd
El archivo de configuración de containerd /etc/containerd/config.toml necesita agregar tres tiempos de ejecución, a saber, vmm, quark, wasm:
[proxy_plugins.vmm ]
type = "sandbox"
address = "/run/vmm-sandboxer.sock"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.vmm]
runtime_type = "io.containerd.kuasar.v1"
sandboxer = "vmm"
io_type = "hvsock"
[proxy_plugins.quark ]
type = "sandbox"
address = "/run/quark-sandboxer.sock"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.quark]
runtime_type = "io.containerd.quark.v1"
sandboxer = "quark"
[proxy_plugins.wasm ]
type = "sandbox"
address = "/run/wasm-sandboxer.sock"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.wasm]
runtime_type = "io.containerd.wasm.v1"
sandboxer = "wasm"
La función AppArmor no es compatible, por lo que disabled_apparmor = true también debe configurarse
componentes en funcionamiento
empezar kuasar
Inicie kuasar con el siguiente comando:
对于vmm: nohup vmm-sandboxer --listen /run/vmm-sandboxer.sock --dir /run/kuasar-vmm &
对于quark: nohup quark-sandboxer --listen /run/quark-sandboxer.sock --dir /var/lib/kuasar-quark &
对于wasm: nohup wasm-sandboxer --listen /run/wasm-sandboxer.sock --dir /run/kuasar-wasm &
Configurar variables de entorno de contenedores
ENABLE_CRI_SANDBOXES=1 contenedor, Sandbox API debe configurar la variable de entorno ENABLE_CRI_SANDBOXES=1 para que surta efecto
ejecutar contenedor
De acuerdo con la documentación, podemos ejecutar directamente el script proporcionado por el almacén de códigos para realizar pruebas.
Prepare la imagen de demostración:
ejecutar vmm sandbox
bash examples/run_example_container.sh vmm
Acceso al contenedor de prueba:
ejecutar quark sandbox
bash examples/run_example_container.sh quark
Acceso al contenedor de prueba:
Ejecute el entorno de pruebas de wasm
bash examples/run_example_wasm_container.sh
Ver pods existentes y demostraciones claras
Resumir
Como una nueva generación de tiempo de ejecución de contenedores, Kuasar ya no usa la interfaz shim v2 para administrar los Pods, sino que proporciona la nueva generación de interfaz de administración de Pods de tiempo de ejecución de contenedores API Sandbox al motor del contenedor. Este conjunto de interfaces no solo hace que la lógica sea más clara, sino que también admite el acceso a varios entornos limitados. Cada Sandboxer usa su propia tecnología de aislamiento de contenedores para administrar Pods del mismo tipo. Kuasar aprovechará la interfaz de sandbox y adoptará las interfaces de administración más recientes de la industria, como DRA (asignación dinámica de recursos) y CDI (interfaz de dispositivo de contenedor) para brindar soluciones de contenedor más seguras, eficientes y convenientes para escenarios nativos de la nube. mayor seguridad.
Referencia
Kuasar Github : https://github.com/kuasar-io
Sitio web oficial de Kuasar : https://kuasar.io
Este artículo participó en la edición número 22 del evento Huawei Cloud Community [Content Co-creation].
[Co-creación de contenido] Detalles de la actividad 22: https://bbs.huaweicloud.com/blogs/402312