Plataforma permite establecer un proceso eficiente para la creación , incluyendo la infraestructura de proveedores de servicios en la nube, en plataformas de virtualización o en sistemas bare-metal. Para crear una plataforma verdaderamente en la nube, tuvimos que ejercer un control estricto sobre todos los elementos utilizados y así aumentar la fiabilidad de un complejo proceso de automatización.
La solución evidente fue adoptar Red Hat Enterprise Linux CoreOS (una variante de Red Hat Enterprise Linux) y CRI-O como estándar, y aquí está el porqué…
Dado que el tema de la navegación es un recurso exitoso para encontrar analogías al explicar el funcionamiento de Kubernetes y los contenedores, intentaremos ilustrar los problemas comerciales que resuelven CoreOS y CRI-O, utilizando como ejemplo . En 1803, Mark Brunel se enfrentó a la tarea de fabricar 100 mil poleas de aparejo para satisfacer las necesidades de la creciente flota naval del Reino Unido. Una polea de aparejo es un tipo de equipo utilizado para fijar cuerdas a las velas. Hasta principios del siglo XIX, estas poleas se fabricaban manualmente, pero Brunel logró automatizar la producción y comenzó a elaborar poleas estandarizadas con el uso de maquinaria. La automatización de este proceso significó que todas las poleas resultantes eran prácticamente idénticas, podían ser fácilmente reemplazadas en caso de fallos y podían fabricarse en grandes cantidades.
Ahora imagina que Brunel tuviera que realizar este trabajo para 20 modelos diferentes de barcos (versiones de Kubernetes) y para cinco planetas distintos con corrientes y vientos marinos completamente diferentes (proveedores de nube). Además, se requería que todos los barcos (clústeres de OpenShift), independientemente de los planetas por los que navegaran, se comportaran de manera idéntica desde el punto de vista de los capitanes (operadores que gestionan el funcionamiento de los clústeres). Siguiendo la analogía marítima, a los capitanes de los barcos realmente no les importa qué poleas de aparejo (CRI-O) se utilizan en sus embarcaciones; lo que les importa es que estas poleas sean robustas y fiables.
Antes de OpenShift 4, había un desafío empresarial muy similar que enfrentar en la plataforma en la nube. Nuevos nodos deben ser creados al momento de establecer un clúster, en caso de fallo de uno de los nodos, o al escalar el clúster. Durante la creación e inicialización de un nuevo nodo, los componentes críticos del host también deben ser configurados adecuadamente, incluyendo CRI-O. Al igual que en cualquier otro tipo de producción, primero se debe suministrar la "materia prima". En el caso de los barcos, la materia prima es el metal y la madera. Sin embargo, para crear un host que despliegue contenedores en el clúster de OpenShift 4, se necesitan archivos de configuración y APIs proporcionadas. Después de esto, OpenShift garantizará el nivel adecuado de automatización a lo largo de todo el ciclo de vida, ofreciendo el soporte de producto necesario para los usuarios finales y recuperando así la inversión en la plataforma.
OpenShift 4 fue diseñado para permitir actualizaciones cómodas del sistema a lo largo de todo el ciclo de vida de la plataforma (para las versiones 4.X), para todos los principales proveedores de computación en la nube, plataformas de virtualización e incluso sistemas bare metal. Para ello, los nodos deben ser construidos utilizando elementos intercambiables. Cuando un clúster necesita una nueva versión de Kubernetes, también recibe la versión correspondiente de CRI-O en CoreOS. Dado que la versión de CRI-O está directamente vinculada a Kubernetes, esto simplifica en gran medida cualquier reconfiguración para propósitos de prueba, solución de problemas o soporte. Además, este enfoque ayuda a reducir los costos para los usuarios finales y Red Hat.
Esta es una nueva perspectiva fundamental en los clústeres de Kubernetes, que establece las bases para planificar nuevas funciones muy útiles y atractivas. CRI-O (proyecto de Contenedor Runtime Interface de la Open Container Initiative, abreviadamente CRI-OCI) ha demostrado ser la opción más adecuada para la creación masiva de nodos, lo que es necesario para trabajar con OpenShift. CRI-O reemplazará el motor Docker utilizado anteriormente, ofreciendo a los usuarios de OpenShift – sí, no te has confundido – un motor de contenedor aburrido, creado específicamente para trabajar con Kubernetes.
El mundo de los contenedores abiertos
El mundo ya se mueve hacia contenedores abiertos. Ya sea en Kubernetes o en niveles más bajos, está dando lugar a un ecosistema de innovación en cada nivel.
Todo comenzó con la creación de la iniciativa Open Containers Initiative En esta fase temprana, se establecieron especificaciones para las imágenes de contenedor y Esto permitió garantizar que las herramientas pudieran utilizar un único estándar y un formato unificado para trabajar con ellas. Posteriormente, se añadieron especificaciones para lo que facilitó a los usuarios el intercambio de .
Luego, la comunidad de Kubernetes desarrolló un estándar único de interfaz conectable Container Runtime Interface (CRI).
Gracias a esto, los usuarios de Kubernetes pudieron conectar diferentes motores para trabajar con contenedores además de Docker. nació OCID. la versión 1.0,
el proyecto fue renombrado a CRI-O.
Fig. 1.
Innovaciones con CRI-O y CoreOS. motor de contenedor
utilizado por defecto en la plataforma, y CRI-O reemplazó a Docker, ofreciendo un entorno económico, estable, simple y aburrido para ejecutar contenedores, que se desarrolla paralelamente a Kubernetes. Esto simplifica significativamente el soporte y la configuración del clúster. La configuración y gestión del motor de contenedor y del host se automatizan dentro de OpenShift 4.
Espera, ¿cómo es eso? no solo desde la perspectiva de las aplicaciones de los usuarios finales, sino también desde la perspectiva de las operaciones básicas a nivel de plataforma, como el despliegue de imágenes, la configuración del sistema o la instalación de actualizaciones.
Kubernetes siempre ha permitido a los usuarios gestionar aplicaciones, definiendo el estado deseado y utilizando , para garantizar que el estado actual se asemeje lo más posible al estado especificado. Este abre grandes oportunidades tanto desde la perspectiva del desarrollo como de las operaciones. Los desarrolladores pueden definir el estado requerido, al operador en forma de archivo YAML o JSON, y luego el operador puede crear en el entorno de producción la instancia necesaria de la aplicación, de modo que el estado operativo de esa instancia esté completamente en línea con el especificado.
Al utilizar operadores (Operators) en la plataforma, OpenShift 4 introduce esta nueva paradigma (usando el concepto de estado deseado y estado actual) en la gestión de RHEL CoreOS y CRI-O. Las tareas de configuración y gestión de versiones del sistema operativo y del motor de contenedores se automatizan mediante lo que se conoce como . MCO simplifica considerablemente el trabajo del administrador del clúster, automatizando esencialmente las últimas etapas de la instalación, así como las operaciones posteriores a la instalación (day two operations). Todo esto convierte a OpenShift 4 en una auténtica plataforma en la nube. Hablaremos de esto más adelante.
Ejecución de contenedores
Los usuarios han tenido la posibilidad de utilizar el motor CRI-O en la plataforma OpenShift desde la versión 3.7 en estado de Tech Preview y desde la versión 3.9 en estado de Generally Available (actualmente soportado). Además, Red Hat utiliza masivamente en OpenShift Online desde la versión 3.10. Todo esto ha permitido al equipo que trabaja en CRI-O adquirir una gran experiencia en el despliegue masivo de contenedores en grandes clústeres de Kubernetes. Para obtener una idea básica de cómo Kubernetes utiliza CRI-O, veamos la siguiente ilustración, que muestra el principio de funcionamiento de la arquitectura.
Fig. 2. Cómo funcionan los contenedores en un clúster de Kubernetes
CRI-O simplifica la creación de nuevos hosts de contenedores a través de la sincronización de todo el nivel superior al inicializar nuevos nodos y al lanzar nuevas versiones de la plataforma OpenShift. La revisión de toda la plataforma en su conjunto permite realizar actualizaciones / retrocesos transaccionales, así como prevenir bloqueos mutuos en las dependencias entre el núcleo del host de contenedores, el motor de contenedores, los nodos (Kubelets) y el nodo maestro de Kubernetes Master. Con la gestión centralizada de todos los componentes de la plataforma, con control y gestión de versiones, se puede siempre seguir un camino claro del estado A al estado B. Esto simplifica el proceso de actualizaciones, mejora la seguridad, optimiza el seguimiento del rendimiento y ayuda a reducir los costos de actualizaciones e implementación de nuevas versiones.
Demostración del poder de los elementos intercambiables
Como se mencionó anteriormente, el uso de Machine Config Operator para gestionar el host del contenedor y el motor de contenedores en OpenShift 4 proporciona un nuevo nivel de automatización que no era posible en la plataforma Kubernetes anteriormente. Para demostrar las nuevas capacidades, mostraremos cómo podría hacer cambios en el archivo crio.conf. Para evitar confusiones terminológicas, trate de concentrarse en los resultados.
Primero, vamos a crear lo que se llama la configuración del entorno de ejecución del contenedor – Container Runtime Config. Considere esto como un recurso de Kubernetes que representa la configuración para CRI-O. En realidad, es una versión especializada de lo que se denomina MachineConfig, que representa cualquier configuración implementada en la máquina RHEL CoreOS dentro del clúster OpenShift.
Este recurso personalizado, llamado ContainerRuntimeConfig, fue diseñado para facilitar a los administradores del clúster la configuración de CRI-O. Es una herramienta lo suficientemente poderosa como para aplicarse solo a nodos específicos según las configuraciones de MachineConfigPool. Considere esto como un grupo de máquinas que cumplen el mismo propósito.
Preste atención a las dos últimas líneas que vamos a modificar en el archivo /etc/crio/crio.conf. Estas dos líneas son muy similares a las líneas en el archivo crio.conf, son:
vi ContainerRuntimeConfig.yaml
Salida:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
Ahora enviaremos este archivo al clúster de Kubernetes y verificaremos que realmente se haya creado. Tenga en cuenta que el trabajo se realiza exactamente igual que con cualquier otro recurso de Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Salida:
NAME AGE
set-log-and-pid 22h
Después de crear ContainerRuntimeConfig, necesitamos modificar uno de los MachineConfigPools para indicar a Kubernetes que queremos aplicar esta configuración a un grupo específico de máquinas en el clúster. En este caso, modificaremos el MachineConfigPool para los nodos master:
oc edit MachineConfigPool/master
Salida (se ha dejado la esencia principal para mayor claridad):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
En este momento, el MCO comienza a crear un nuevo archivo crio.conf para el clúster. A su vez, el archivo de configuración completamente listo se puede ver a través de la API de Kubernetes. Recuerde que ContainerRuntimeConfig es solo una versión especializada de MachineConfig, por lo que podemos ver el resultado al mirar las líneas necesarias en MachineConfigs:
oc get MachineConfigs | grep rendered
Salida:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Tenga en cuenta que el archivo de configuración obtenido para los nodos master es una versión más nueva que las configuraciones originales. Para ver este archivo, ejecute el siguiente comando. Por cierto, cabe mencionar que este podría ser uno de los mejores scripts de una sola línea en la historia de Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Salida:
pids_limit = 2048
Ahora asegurémonos de que la configuración se haya aplicado a todos los nodos master. Primero obtendremos una lista de nodos en el clúster:
oc get node | grep master
Salida:
ip-10-0-135-153.us-east-2.compute.internal Listo master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Listo master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Listo master 23h v1.12.4+509916ce1
Ahora veamos el archivo instalado. Verá que el archivo se ha actualizado con los nuevos valores de las directivas pid y debug que especificamos en el recurso ContainerRuntimeConfig. La propia elegancia:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Salida:
...
pids_limit = 2048
...
log_level = "debug"
...
Todos estos cambios en el clúster se realizaron incluso sin iniciar SSH. Todo el trabajo se llevó a cabo haciendo uso del nodo maestro de Kubernetes. Es decir, estos nuevos parámetros se configuraron solo en los nodos maestros. Los nodos de trabajo no se cambiaron, lo que demuestra las ventajas de la metodología Kubernetes utilizando estados deseados y actuales en relación con los hosts de contenedores y los motores de contenedores con elementos intercambiables.
El ejemplo anterior muestra la posibilidad de hacer cambios en un pequeño clúster de OpenShift Container Platform 4 con tres nodos de trabajo o en un enorme clúster de producción con 3000 nodos. En cualquier caso, la carga de trabajo será la misma: y muy pequeña, solo se necesita configurar el archivo ContainerRuntimeConfig y modificar una etiqueta en MachineConfigPool. Y puedes hacerlo con cualquier versión de la plataforma OpenShift Container Platform 4.X utilizada en Kubernetes durante todo su ciclo de vida.
A menudo, las empresas tecnológicas crecen tan rápido que no podemos explicar por qué elegimos ciertas tecnologías para los componentes fundamentales. Históricamente, los motores de contenedores han sido el componente con el que los usuarios interactúan directamente. Dado que la popularidad de los contenedores comenzó con la aparición de los motores de contenedores, los usuarios suelen mostrar interés en ellos. Esta es otra razón por la cual Red Hat optó por CRI-O. Los contenedores evolucionan, y hoy en día se pone un mayor énfasis en la orquestación, y hemos llegado a la conclusión de que CRI-O ofrece la mejor experiencia al trabajar con OpenShift 4.
Fuente: habr.com
