La
plataforma Red Hat OpenShift Container Platform 4 le permite transmitir la creación de
hosts para el despliegue de contenedores , incluso en la infraestructura de proveedores de servicios en la nube, en plataformas de virtualización o en sistemas de metal desnudo. Para crear una plataforma en la nube en el sentido completo, tuvimos que tomar un control estricto de todos los elementos utilizados y así aumentar la confiabilidad de un proceso de automatización complejo.
La solución obvia era usar Red Hat Enterprise Linux CoreOS (una variación de Red Hat Enterprise Linux) y CRI-O como estándar, y he aquí por qué ...
Dado que el tema de la navegación es muy exitoso para encontrar analogías al explicar el funcionamiento de Kubernetes y contenedores, tratemos de hablar sobre los problemas comerciales que CoreOS y CRI-O resuelven, utilizando el ejemplo de
la invención de
Brunel para la producción de bloques de aparejo . En 1803, Mark Brunel tuvo la tarea de fabricar 100,000 bloques de aparejos para las necesidades de la creciente armada británica. Un bloque de elevación es un tipo de plataforma que se usa para unir cuerdas a velas. Hasta principios del siglo XIX, estos bloques se fabricaban a mano, pero Brunel pudo automatizar la producción y comenzó a producir bloques estandarizados utilizando máquinas. La automatización de este proceso significaba que, como resultado, todos los bloques eran casi iguales, podían reemplazarse fácilmente en caso de avería y podían hacerse en grandes cantidades.
Ahora imagine que Brunel tendría que hacer este trabajo para 20 modelos de barcos diferentes (versiones de Kubernetes) y para cinco planetas diferentes con corrientes marinas y vientos completamente diferentes (proveedores de nubes). Además, se requería que todos los barcos (conglomerados OpenShift), independientemente de los planetas que se navegaran, desde el punto de vista de los capitanes (operadores que controlan la operación de los conglomerados) se comporten de manera idéntica. Continuando con la analogía marina, a los capitanes de barco no les importa en absoluto qué bloques de aparejo (CRI-O) se utilizan en sus barcos; lo principal para ellos es que estos bloques son fuertes y confiables.
OpenShift 4, como plataforma en la nube, enfrenta un desafío comercial muy similar. Se deben crear nuevos nodos en el momento de la creación del clúster, en caso de falla en uno de los nodos o al escalar el clúster. Al crear e inicializar un nuevo nodo, los componentes críticos del host, incluido CRI-O, deben configurarse en consecuencia. Como en cualquier otra producción, las "materias primas" deben suministrarse al principio. En el caso de los barcos, el metal y la madera actúan como materia prima. Sin embargo, si crea un host para implementar contenedores en un clúster de OpenShift 4, debe tener archivos de configuración y servidores API proporcionados en la entrada. Después de eso, OpenShift proporcionará el nivel necesario de automatización durante todo el ciclo de vida, ofreciendo el soporte de producto necesario para los usuarios finales y, por lo tanto, amortizando las inversiones en la plataforma.
OpenShift 4 se creó de tal manera que proporciona la capacidad de actualizar convenientemente el sistema durante 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 de metal desnudo. Para esto, los nodos deben crearse sobre la base de elementos intercambiables. Cuando un clúster requiere una nueva versión de Kubernetes, también recibe la versión CRI-O correspondiente en CoreOS. Dado que la versión CRI-O está vinculada directamente a Kubernetes, todo esto simplifica enormemente cualquier permutaciones para pruebas, resolución de problemas o soporte. Además, este enfoque reduce los costos para los usuarios finales y Red Hat.
Este es un aspecto fundamentalmente nuevo en los clústeres de Kubernetes, que sienta las bases para planificar nuevas funciones muy útiles y atractivas. CRI-O (interfaz de tiempo de ejecución de contenedor de proyecto de contenedor abierto - Open Container Initiative, abreviado CRI-OCI) fue la opción más exitosa para la creación masiva de nodos, que es necesaria para trabajar con OpenShift. CRI-O reemplazará el motor Docker utilizado anteriormente, ofreciendo a los usuarios de OpenShift un motor
económico, estable, simple y aburrido , sí, lo entendieron bien, un contenedor aburrido diseñado específicamente para trabajar con Kubernetes.
El mundo de los contenedores abiertos.
El mundo lleva mucho tiempo avanzando hacia contenedores abiertos. Ya sea en Kubernetes, o en niveles inferiores, el
desarrollo de estándares de contenedores conduce a un ecosistema de innovación en todos los niveles.
Todo comenzó con la creación de la Iniciativa de Contenedores Abiertos
en junio de 2015 . En esta etapa temprana del trabajo, se formaron especificaciones para la
imagen del contenedor
(imagen) y el
tiempo de ejecución . Esto permitió garantizar que las herramientas puedan utilizar un único estándar de
imágenes de
contenedor y un único formato para trabajar con ellas. Posteriormente se agregaron especificaciones de
distribución , lo que permitió a los usuarios intercambiar fácilmente
imágenes de contenedores .
La comunidad de Kubernetes luego desarrolló un único estándar de interfaz enchufable llamado
Container Runtime Interface (CRI) . Gracias a esto, los usuarios de Kubernetes pudieron conectar varios motores para trabajar con contenedores además de Docker.
Los ingenieros de Red Hat y Google vieron una demanda en el mercado de un motor de contenedor que pudiera aceptar solicitudes de Kubelet usando el protocolo CRI e introdujo contenedores que eran compatibles con las especificaciones de OCI mencionadas anteriormente. Entonces
había un OCID . Pero discúlpeme, porque dijimos que este material se dedicará a CRI-O. De hecho, es solo con el lanzamiento de la
versión 1.0, el proyecto pasó a llamarse CRI-O.
Fig. 1)Innovación con CRI-O y CoreOS
Con el lanzamiento de la plataforma OpenShift 4, se cambió el
motor del
contenedor utilizado en la plataforma predeterminada, y Docker fue reemplazado por CRI-O, que ofrecía un entorno de lanzamiento de contenedor económico, estable, simple y aburrido, que se desarrolla en paralelo con Kubernetes. Esto simplifica enormemente el soporte y la configuración del clúster. La configuración del motor de contenedor y el host, así como su administración, se automatiza en OpenShift 4.
Para, como es?
Así es, con el advenimiento de OpenShift 4, ahora ya no es necesario conectarse a hosts individuales e instalar un motor contenedor, configurar el almacenamiento, configurar servidores para búsqueda o configurar una red. La plataforma OpenShift 4 ha sido completamente rediseñada para usar el
Marco del
operador no solo en términos de aplicaciones de usuario final, sino también en términos de operaciones básicas a nivel de plataforma, como desplegar imágenes, configurar el sistema o instalar actualizaciones.
Kubernetes siempre ha permitido que los usuarios administren aplicaciones determinando el estado deseado y usando
Controladores para garantizar que el estado real sea lo más cercano posible al estado dado. Este
enfoque que utiliza un estado dado y un estado real abre grandes oportunidades tanto desde el punto de vista del desarrollo como desde el punto de vista de las operaciones. Los desarrolladores pueden determinar el estado requerido,
transferirlo al operador en forma de un archivo YAML o JSON, y luego el operador puede crear la instancia de aplicación necesaria en el entorno operativo, mientras que el estado operativo de esta instancia corresponderá completamente al especificado.
Usando Operadores en la plataforma, OpenShift 4 trae este nuevo paradigma (usando el concepto de conjunto y estado actual) a la gestión de RHEL CoreOS y CRI-O. Las tareas de configurar y versionar el sistema operativo y el motor del contenedor se automatizan utilizando el llamado
Operador de configuración de la máquina (MCO) . MCO simplifica enormemente el trabajo del administrador del clúster, esencialmente automatizando las últimas etapas de instalación, así como las operaciones posteriores después de la instalación (operaciones del día dos). Todo esto hace de OpenShift 4 una verdadera plataforma en la nube. Nos detendremos en esto un poco más tarde.
Lanzamiento de contenedores
Los usuarios tuvieron la oportunidad de utilizar el motor CRI-O en la plataforma OpenShift a partir de la versión 3.7 en el estado de Tech Preview y de la versión 3.9 en el estado de Disponible en general (actualmente compatible). Además, Red Hat hace
un uso
extenso de
CRI-O para lanzar cargas de
trabajo de producción en OpenShift Online desde la versión 3.10. Todo esto permitió que el equipo que trabajaba en CRI-O obtuviera una vasta experiencia en el lanzamiento masivo de contenedores en grandes grupos de Kubernetes. Para obtener una comprensión básica de cómo Kubernetes usa CRI-O, echemos un vistazo a la siguiente ilustración, que muestra cómo funciona la arquitectura.
Fig. 2. Cómo funcionan los contenedores en el clúster de KubernetesCRI-O simplifica la creación de nuevos hosts de contenedores al sincronizar todo el nivel superior al inicializar nuevos nodos y al lanzar nuevas versiones de la plataforma OpenShift. Una auditoría completa de la plataforma permite actualizaciones / reversiones de transacciones, y también evita puntos muertos en las dependencias entre el kernel de la cola del contenedor, el motor del contenedor, Kubelets y Kubernetes Master. Con la administración centralizada de todos los componentes de la plataforma, con el control y la administración de versiones, siempre puede realizar un seguimiento de una ruta clara del estado A al estado B. Esto simplifica el proceso de actualización, mejora la seguridad, mejora los informes de rendimiento y ayuda a reducir el costo de actualizar e instalar nuevas versiones.
Demostración del poder de los elementos intercambiables.
Como se mencionó anteriormente, el uso de Machine Config Operator para administrar el host del contenedor y el motor del contenedor en OpenShift 4 proporciona un nuevo nivel de automatización que antes no era posible en la plataforma Kubernetes. Para demostrar las nuevas funciones, mostramos cómo puede realizar cambios en el archivo crio.conf. Para no confundirse con la terminología, intente concentrarse en los resultados.
Primero, creemos lo que se llama una configuración de tiempo de ejecución de contenedor: la configuración de tiempo de ejecución de contenedor. Considere esto un recurso de Kubernetes que representa la configuración para CRI-O. En realidad, esta es una versión especializada de lo que se llama MachineConfig, que es cualquier configuración implementada en una máquina RHEL CoreOS dentro de un clúster OpenShift.
Este recurso personalizado, llamado ContainerRuntimeConfig, se inventó para facilitar a los administradores del clúster configurar CRI-O. Esta es una herramienta lo suficientemente poderosa que solo se puede aplicar a ciertos nodos dependiendo de la configuración de MachineConfigPool. Considere esto un grupo de máquinas que tienen el mismo propósito.
Presta atención a las dos últimas líneas que vamos a cambiar en el archivo /etc/crio/crio.conf. Estas dos líneas son muy similares a las líneas en el archivo crio.conf, estas son:
vi ContainerRuntimeConfig.yaml
Conclusión
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 envíe este archivo al clúster de Kubernetes y verifique que realmente se haya creado. Tenga en cuenta que la operación se lleva a cabo de la misma manera que con cualquier otro recurso de Kubernetes:
oc create -f ContainerRuntimeConfig.yaml oc get ContainerRuntimeConfig
Conclusión
NAME AGE set-log-and-pid 22h
Después de crear ContainerRuntimeConfig, debemos modificar uno de los MachineConfigPools para que Kubernetes comprenda que queremos aplicar esta configuración a un grupo específico de máquinas en el clúster. En este caso, cambiaremos MachineConfigPool para los nodos maestros:
oc edit MachineConfigPool/master
Conclusión (para mayor claridad, queda el punto principal):
... 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 punto, MCO comienza a crear un nuevo archivo crio.conf para el clúster. En este caso, se puede ver un archivo de configuración completamente terminado usando la API de Kubernetes. Recuerde, ContainerRuntimeConfig es solo una versión especializada de MachineConfig, por lo que podemos ver el resultado mirando las líneas en MachineConfigs:
oc get MachineConfigs | grep rendered
Conclusión
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 resultante para los nodos maestros resultó ser una versión más nueva que las configuraciones originales. Para verlo, ejecute el siguiente comando. De paso, notamos que este es probablemente 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
Conclusión
pids_limit = 2048
Ahora asegúrese de que la configuración se haya aplicado a todos los nodos maestros. Primero obtenemos una lista de nodos en el clúster:
oc get node | grep master Output: ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Ahora mira el archivo instalado. Verá que el archivo se ha actualizado con las nuevas directivas pid y debug que especificamos en el recurso ContainerRuntimeConfig. Elegancia misma:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid'
Conclusión
... pids_limit = 2048 ... log_level = "debug" ...
Todos estos cambios en el clúster se realizaron incluso sin iniciar SSH. Todo el trabajo se realizó contactando el nodo maestro de Kuberentes. Es decir, estos nuevos parámetros se configuraron solo en los nodos maestros. Al mismo tiempo, los nodos de trabajo no cambiaron, lo que demuestra las ventajas de la metodología de Kubernetes usando el conjunto y los estados actuales aplicados a los hosts de contenedores y motores de contenedores con elementos intercambiables.
El ejemplo anterior muestra la capacidad de realizar cambios en un pequeño clúster OpenShift Container Platform 4 con tres nodos de trabajo o en un gran clúster de producción con 3000 nodos. En cualquier caso, la cantidad de trabajo será la misma, y muy pequeña, solo configure el archivo ContainerRuntimeConfig y cambie una etiqueta en MachineConfigPool. Y puede hacerlo con cualquier versión de la plataforma OpenShift Container Platform 4.X utilizada por Kubernetes a lo largo de su ciclo de vida.
A menudo, las compañías de tecnología se están desarrollando tan rápido que no podemos explicar por qué elegimos ciertas tecnologías para los componentes básicos. Los motores de contenedores han sido históricamente el componente con el que los usuarios interactúan directamente. Como la popularidad de los contenedores comenzó naturalmente con la llegada de los motores de contenedores, los usuarios a menudo muestran interés en ellos. Esta es otra razón por la cual Red Hat optó por CRI-O. Los contenedores están evolucionando, con el enfoque en la orquestación de hoy, y hemos llegado a la conclusión de que CRI-O proporciona la mejor experiencia al trabajar con OpenShift 4.