plataforma le permite agilizar la creación , incluso en la infraestructura de los proveedores de servicios en la nube, en plataformas de virtualización o en sistemas bare-metal. Para crear una plataforma verdaderamente basada en la nube, 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 variante 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 bueno para encontrar analogías a la hora de explicar el trabajo de Kubernetes y los contenedores, intentemos hablar de los problemas de negocio que resuelven CoreOS y CRI-O, usando un ejemplo. . En 1803, a Marc Brunel se le encomendó la tarea de producir 100 bloques de aparejo para las necesidades de la creciente marina británica. Un bloque de aparejo es un tipo de aparejo que se utiliza para sujetar cuerdas a las velas. Hasta principios del siglo XIX, estos bloques se fabricaban a mano, pero Brunel logró automatizar la producción y comenzó a producir bloques estandarizados utilizando máquinas herramienta. La automatización de este proceso significó que los bloques resultantes eran esencialmente idénticos, podían reemplazarse fácilmente si se rompían y podían producirse en grandes cantidades.
Ahora imagine si Brunel tuviera 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 exigía que todas las naves (clusters OpenShift), independientemente de los planetas en los que se realice la navegación, desde el punto de vista de los capitanes (operadores que gestionan el funcionamiento de los clusters) se comportaran igual. Siguiendo con la analogía marítima, a los capitanes de barcos no les importa en absoluto qué tipo de bloques de aparejo (CRI-O) se utilizan en sus barcos; lo principal para ellos es que estos bloques sean fuertes y confiables.
OpenShift 4, como plataforma en la nube, enfrenta un desafío empresarial muy similar. Se deben crear nuevos nodos en el momento de la creación del clúster, en caso de una falla en uno de los nodos o al escalar el clúster. Cuando se crea e inicializa un nuevo nodo, los componentes críticos del host, incluido CRI-O, deben configurarse en consecuencia. Como en cualquier otra producción, es necesario suministrar “materias primas” desde el principio. En el caso de los barcos, las materias primas son el metal y la madera. Sin embargo, en el caso de crear un host para implementar contenedores en un clúster de OpenShift 4, debe tener archivos de configuración y servidores proporcionados por API como entrada. OpenShift proporcionará entonces el nivel requerido de automatización durante todo el ciclo de vida, ofreciendo el soporte de producto necesario a los usuarios finales y recuperando así la inversión en la plataforma.
OpenShift 4 se creó de tal manera que brinde 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 bare metal. Para ello, es necesario crear nodos a partir de elementos intercambiables. Cuando un clúster requiere una nueva versión de Kubernetes, también recibe la versión correspondiente de CRI-O en CoreOS. Dado que la versión CRI-O está vinculada directamente a Kubernetes, esto simplifica enormemente cualquier permutación con fines de prueba, resolución de problemas o soporte. Además, este enfoque reduce los costos para los usuarios finales y para Red Hat.
Esta es una forma fundamentalmente nueva de pensar sobre los clústeres de Kubernetes y sienta las bases para planificar algunas características nuevas muy útiles y atractivas. CRI-O (Container Runtime Interface - Open Container Initiative, abreviado CRI-OCI) resultó ser la opción más exitosa para la creación masiva de nodos necesarios para trabajar con OpenShift. CRI-O reemplazará el motor Docker utilizado anteriormente y ofrecerá a los usuarios de OpenShift – sí, escuchaste bien – un aburrido motor de contenedores creado específicamente para trabajar con Kubernetes.
El mundo de los contenedores abiertos
El mundo lleva mucho tiempo avanzando hacia los contenedores abiertos. Ya sea en Kubernetes o en niveles inferiores, da como resultado un ecosistema de innovación en todos los niveles.
Todo empezó con la creación de la Open Containers Initiative . En esta primera etapa del trabajo, se formaron las especificaciones del contenedor. и . Esto aseguró que las herramientas pudieran utilizar un único estándar. y un formato unificado para trabajar con ellos. Posteriormente se agregaron especificaciones. , permitiendo a los usuarios compartir fácilmente .
Luego, la comunidad de Kubernetes desarrolló un estándar único para una interfaz conectable, llamado . 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 la necesidad del mercado de un motor de contenedores que pudiera aceptar solicitudes de Kubelet a través del protocolo CRI e introdujeron contenedores que fueran compatibles con las especificaciones OCI mencionadas anteriormente. Entonces . Pero disculpe, ¿no dijimos que este material estaría dedicado al CRI-O? En realidad lo es, solo con el lanzamiento. el proyecto pasó a llamarse CRI-O.
La figura. 1.
Innovación con CRI-O y CoreOS
Con el lanzamiento de la plataforma OpenShift 4, esto cambió , utilizado de forma predeterminada en la plataforma, y Docker fue reemplazado por CRI-O, ofreciendo un entorno rentable, estable, simple y aburrido para ejecutar un contenedor que se desarrolla en paralelo con Kubernetes. Esto simplifica enormemente el soporte y la configuración del clúster. La configuración del motor y el host del contenedor, así como su gestión, se automatiza en OpenShift 4.
Espera, ¿cómo es esto?
Así es, con la llegada de OpenShift 4, ya no es necesario conectarse a hosts individuales e instalar un motor de contenedor, configurar el almacenamiento, configurar servidores de búsqueda o configurar una red. La plataforma OpenShift 4 ha sido completamente rediseñada para utilizar la 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 implementar imágenes, configurar el sistema o instalar actualizaciones.
Kubernetes siempre ha permitido a los usuarios administrar aplicaciones definiendo el estado deseado y usando , para garantizar que el estado real coincida lo más posible con el estado objetivo. Este abre grandes oportunidades tanto desde una perspectiva de desarrollo como de operaciones. Los desarrolladores pueden definir el estado requerido mediante al operador en forma de un archivo YAML o JSON, y luego el operador puede crear la instancia de aplicación requerida en el entorno de producción, y el estado operativo de esta instancia corresponderá completamente al especificado.
Al utilizar operadores en la plataforma, OpenShift 4 trae este nuevo paradigma (utilizando el concepto de estado establecido y real) a la gestión de RHEL CoreOS y CRI-O. Las tareas de configuración y gestión de versiones del sistema operativo y motor de contenedor se automatizan mediante el denominado . MCO simplifica enormemente el trabajo del administrador del clúster, esencialmente automatizando las últimas etapas de la instalación, así como las operaciones posteriores a la instalación (operaciones del segundo día). Todo esto hace de OpenShift 4 una verdadera plataforma en la nube. Hablaremos de esto un poco más adelante.
Contenedores en ejecución
Los usuarios han tenido la oportunidad de utilizar el motor CRI-O en la plataforma OpenShift desde la versión 3.7 en el estado Tech Preview y desde la versión 3.9 en el estado Generalmente Disponible (actualmente compatible). Además, Red Hat utiliza masivamente en OpenShift Online desde la versión 3.10. Todo esto permitió al equipo que trabaja en CRI-O adquirir una amplia experiencia en el lanzamiento masivo de contenedores en grandes clústeres de Kubernetes. Para obtener una comprensión básica de cómo Kubernetes usa CRI-O, veamos la siguiente ilustración, que muestra cómo funciona la arquitectura.
Arroz. 2. Cómo funcionan los contenedores en un clúster de Kubernetes
CRI-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. La revisión de toda la plataforma permite actualizaciones/reversiones transaccionales y también evita interbloqueos en las dependencias entre el núcleo de cola del contenedor, el motor del contenedor, los nodos (Kubelets) y el nodo maestro de Kubernetes. Al administrar de forma centralizada todos los componentes de la plataforma, con control y control de versiones, siempre hay un camino claro desde el 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 las actualizaciones y las instalaciones de nuevas versiones. .
Demostrando el poder de los elementos de reemplazo
Como se mencionó anteriormente, el uso del operador de configuración de máquina 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, le mostraremos cómo puede realizar cambios en el archivo crio.conf. Para evitar confundirse con la terminología, intente centrarse en los resultados.
Primero, creemos lo que se llama una configuración de tiempo de ejecución de contenedor: Configuración de tiempo de ejecución de contenedor. Piense en ello como un recurso de Kubernetes que representa la configuración para CRI-O. En realidad, es una versión especializada de algo llamado MachineConfig, que es cualquier configuración que se implementa en una máquina RHEL CoreOS como parte de un clúster OpenShift.
Este recurso personalizado, llamado ContainerRuntimeConfig, se creó para facilitar a los administradores del clúster la configuración de CRI-O. Esta herramienta es lo suficientemente potente como para que solo se pueda aplicar a ciertos nodos según la configuración de MachineConfigPool. Piense en ello como un grupo de máquinas que tienen el mismo propósito.
Observe 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 del archivo crio.conf, 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íemos este archivo al clúster de Kubernetes y verifiquemos que realmente se creó. Tenga en cuenta que el funcionamiento es exactamente el mismo que con cualquier otro recurso de Kubernetes:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Conclusión:
NAME AGE
set-log-and-pid 22h
Una vez que hayamos creado ContainerRuntimeConfig, debemos modificar uno de MachineConfigPools para indicarle a Kubernetes 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 la esencia 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, el archivo de configuración completamente terminado se puede ver utilizando 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 relevantes 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 era una versión más reciente que las configuraciones originales. Para verlo, ejecute el siguiente comando. De paso, observamos que esta es quizás una de las mejores frases ingeniosas 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 asegurémonos 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 veamos el archivo instalado. Verás que el archivo se ha actualizado con los nuevos valores para las directivas pid y debug que especificamos en el recurso ContainerRuntimeConfig. La 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 sin siquiera ejecutar SSH. Todo el trabajo se realizó accediendo al nodo maestro de Kuberentes. Es decir, estos nuevos parámetros se configuraron únicamente en los nodos maestros. Los nodos trabajadores no cambiaron, lo que demuestra los beneficios de la metodología de Kubernetes de utilizar estados específicos y reales en relación con 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 de OpenShift Container Platform 4 con tres nodos de producción o en un clúster de producción enorme con 3000 nodos. En cualquier caso, la cantidad de trabajo será la misma, y muy pequeña, simplemente configure el archivo ContainerRuntimeConfig y cambie una etiqueta en MachineConfigPool. Y puede hacer esto con cualquier versión de OpenShift Container Platform 4.X que ejecute Kubernetes durante todo su ciclo de vida.
A menudo, las empresas de tecnología evolucionan tan rápidamente que no podemos explicar por qué elegimos determinadas tecnologías para los componentes subyacentes. 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ó naturalmente con la llegada de los motores de contenedores, los usuarios suelen mostrar interés en ellos. Ésta es otra razón por la que Red Hat eligió CRI-O. Los contenedores están evolucionando centrándose ahora en la orquestación y hemos descubierto que CRI-O proporciona la mejor experiencia cuando se trabaja con OpenShift 4.
Fuente: habr.com