La cuarta versión de OpenShift se lanzó hace relativamente poco tiempo. La versión actual 4.3 ha estado disponible desde finales de enero y todos los cambios en ella son algo completamente nuevo que no estaba en la tercera versión o una actualización importante de lo que apareció en la versión 4.1. Todo lo que te contamos ahora debe ser conocido, comprendido y tenido en cuenta por quienes trabajan con OpenShift y planean cambiar a una nueva versión.
Con el lanzamiento de OpenShift 4.2, Red Hat facilitó el trabajo con Kubernetes. Han aparecido nuevas herramientas y complementos para crear contenedores, canalizaciones de CI/CD e implementaciones sin servidor. Las innovaciones brindan a los desarrolladores la oportunidad de concentrarse en escribir código y no en trabajar con Kubernetes.
En realidad, ¿qué hay de nuevo en las versiones de OpenShift 4.2 y 4.3?
Avanzando hacia las nubes híbridas
Al planificar una nueva infraestructura de TI o al desarrollar un panorama de TI existente, las empresas consideran cada vez más un enfoque de nube para el suministro de recursos de TI, para lo cual implementan soluciones de nube privada o utilizan el poder de los proveedores de nube pública. Por lo tanto, las infraestructuras de TI modernas se construyen cada vez más según un modelo de nube "híbrido", cuando se utilizan tanto recursos locales como recursos de nube pública con un sistema de gestión común. Red Hat OpenShift 4.2 está especialmente diseñado para simplificar la transición a un modelo de nube híbrida y facilita la conexión de recursos de proveedores como AWS, Azure y Google Cloud Platform al clúster, además del uso de nubes privadas en VMware y OpenStack.
Nuevo enfoque para la instalación.
En la versión 4, el enfoque para instalar OpenShift ha cambiado. Red Hat proporciona una utilidad especial para implementar un clúster OpenShift: openshift-install. La utilidad es un único archivo binario escrito en Go. Openshit-installer prepara un archivo yaml con la configuración necesaria para la implementación.
En caso de instalación utilizando recursos de la nube, deberá especificar información mínima sobre el futuro clúster: zona DNS, número de nodos trabajadores, configuraciones específicas para el proveedor de la nube, información de la cuenta para acceder al proveedor de la nube. Después de preparar el archivo de configuración, el clúster se puede implementar con un comando.
En caso de instalación en sus propios recursos informáticos, por ejemplo, cuando utilice una nube privada (se admiten vSphere y OpenStack) o cuando realice la instalación en servidores bare metal, deberá configurar manualmente la infraestructura: preparar la cantidad mínima de máquinas virtuales o servidores físicos necesarios para crear un clúster de plano de control y configurar servicios de red. Después de esta configuración, se puede crear de manera similar un clúster OpenShift con un comando de la utilidad openshift-installer.
Actualizaciones de infraestructura
Integración con CoreOS
La actualización clave es la integración con Red Hat CoreOS. Los nodos maestros de Red Hat OpenShift ahora pueden funcionar sólo en el nuevo sistema operativo. Este es un sistema operativo gratuito de Red Hat diseñado específicamente para soluciones de contenedores. Red Hat CoreOS es un Linux liviano optimizado para ejecutar contenedores.
Si en 3.11 el sistema operativo y OpenShift existían por separado, en 4.2 está indisolublemente ligado a OpenShift. Ahora bien, se trata de un único dispositivo: una infraestructura inmutable.
Para los clústeres que utilizan RHCOS para todos los nodos, actualizar OpenShift Container Platform es un proceso simple y altamente automatizado.
Anteriormente, para actualizar OpenShift, primero había que actualizar el sistema operativo subyacente en el que se ejecutaba el producto (en ese momento, Red Hat Enterprise Linux). Sólo entonces OpenShift podría actualizarse gradualmente, nodo por nodo. No se habló de ninguna automatización del proceso.
Ahora, dado que OpenShift Container Platform controla completamente los sistemas y servicios en cada nodo, incluido el sistema operativo, esta tarea se resuelve presionando un botón desde la interfaz web. Después de esto, se inicia un operador especial dentro del clúster de OpenShift, que controla todo el proceso de actualización.
Nuevo CSI
En segundo lugar, el nuevo CSI es un controlador de interfaz de almacenamiento que le permite conectar varios sistemas de almacenamiento externos al clúster OpenShift. Una gran cantidad de proveedores de controladores de almacenamiento para OpenShift son compatibles según los controladores de almacenamiento escritos por los propios fabricantes de sistemas de almacenamiento. Puede encontrar una lista completa de controladores CSI compatibles en este documento: . En esta lista puede encontrar todos los modelos principales de matrices de discos de los principales fabricantes (Dell/EMC, IBM, NetApp, Hitachi, HPE, PureStorage), soluciones SDS (Ceph) y almacenamiento en la nube (AWS, Azure, Google). OpenShift 4.2 admite controladores CSI de la versión 1.1 de la especificación CSI.
Malla de servicio RedHat OpenShift
Basado en los proyectos Istio, Kiali y Jaeger, Red Hat OpenShift Service Mesh, además de las tareas habituales de enrutamiento de solicitudes entre servicios, permite su seguimiento y visualización. Esto ayuda a los desarrolladores a comunicarse, monitorear y administrar fácilmente una aplicación implementada dentro de Red Hat OpenShift.
Visualización de una aplicación con arquitectura de microservicio usando Kiali
Para simplificar al máximo la instalación, el mantenimiento y la gestión del ciclo de vida de Service Mesh, Red Hat OpenShift proporciona a los administradores un operador especial, el Service Mesh Operador. Este es un operador de Kubernetes que le permite implementar paquetes Istio, Kiali y Jaeger reconfigurados en un clúster, maximizando la carga administrativa de administrar aplicaciones.
CRI-O en lugar de Docker
El tiempo de ejecución del contenedor predeterminado Docker ha sido reemplazado por CRI-O. Ya era posible utilizar CRI-O en la versión 3.11, pero en la 4.2 se convirtió en la principal. No es bueno ni malo, pero es algo a tener en cuenta a la hora de utilizar el producto.
Operadores y despliegue de aplicaciones.
Los operadores son una nueva entidad para RedHat OpenShift, que apareció en la cuarta versión. Es un método para empaquetar, implementar y administrar una aplicación Kubernetes. Puede considerarse como un complemento para aplicaciones implementadas en contenedores, impulsado por la API de Kubernetes y las herramientas kubectl.
Los operadores de Kubernetes ayudan a automatizar cualquier tarea relacionada con la administración y la gestión del ciclo de vida de la aplicación que implementa en su clúster. Por ejemplo, el operador puede automatizar actualizaciones, copias de seguridad y escalado de la aplicación, cambiar la configuración, etc. Puede encontrar una lista completa de operadores en .
Se puede acceder a OperadorHub directamente desde la interfaz web de la consola de administración. Es un directorio de aplicaciones para OpenShift mantenido por Red Hat. Aquellos. Todos los operadores aprobados por Red Hat estarán cubiertos por el soporte del proveedor.
Portal OperadorHub en la consola de gestión de OpenShift
Imagen base universal
Es un conjunto estandarizado de imágenes del sistema operativo RHEL que se puede utilizar para crear aplicaciones en contenedores. Hay juegos mínimos, estándar y completos. Ocupan muy poco espacio y admiten todos los paquetes instalados y lenguajes de programación necesarios.
Herramientas CI/CD
En RedHat OpenShif 4.2, fue posible elegir entre Jenkins y OpenShift Pipelines basados en Tekton Pipelines.
OpenShift Pipelines se basa en Tekton, que es mejor respaldado por Pipeline a medida que se acercan Code y GitOps. En las canalizaciones de OpenShift, cada paso se ejecuta en su propio contenedor, por lo que los recursos solo se utilizan mientras se ejecuta el paso. Esto brinda a los desarrolladores un control total sobre los canales de entrega de módulos, los complementos y el control de acceso sin un servidor CI/CD central para administrar.
OpenShift Pipelines se encuentra actualmente en Developer Preview y está disponible como operador en un clúster de OpenShift 4. Por supuesto, los usuarios de OpenShift aún pueden usar Jenkins en RedHat OpenShift 4.
Actualizaciones de gestión de desarrolladores
En 4.2 OpenShift, la interfaz web se actualizó completamente tanto para desarrolladores como para administradores.
En versiones anteriores de OpenShift, todos trabajaban en tres consolas: directorio de servicios, consola de administrador y consola de trabajo. Ahora el clúster está dividido en solo dos partes: consola de administrador y consola de desarrollador.
La consola del desarrollador ha recibido importantes mejoras en la interfaz de usuario. Ahora muestra de manera más conveniente las topologías de las aplicaciones y sus ensamblajes. Esto facilita a los desarrolladores la creación, implementación y visualización de aplicaciones en contenedores y recursos agrupados. Les permite centrarse en lo que es importante para ellos.
Portal de desarrollador en la consola de gestión de OpenShift
odo
Odo es una utilidad de línea de comandos orientada a desarrolladores que simplifica el desarrollo de aplicaciones en OpenShift. Utilizando la comunicación estilo git push, esta CLI ayuda a los desarrolladores nuevos en Kubernetes a crear aplicaciones en OpenShift.
Integración con entornos de desarrollo.
Los desarrolladores ahora pueden crear, depurar e implementar sus aplicaciones en OpenShift sin abandonar su entorno de desarrollo de código favorito, como Microsoft Visual Studio, JetBrains (incluido IntelliJ), Eclipse Desktop, etc.
Extensión de implementación de Red Hat OpenShift para Microsoft Azure DevOps
Se lanzó la extensión Red Hat OpenShift Deployment para Microsoft Azure DevOps. Los usuarios de este conjunto de herramientas DevOps ahora pueden implementar sus aplicaciones en Azure Red Hat OpenShift o cualquier otro clúster de OpenShift directamente desde Microsoft Azure DevOps.
Transición de la tercera versión a la cuarta.
Dado que estamos hablando de una nueva versión y no de una actualización, no se puede simplemente poner la cuarta versión encima de la tercera. No se admitirá la actualización de la versión XNUMX a la versión XNUMX..
Pero hay buenas noticias: Red Hat proporciona herramientas para migrar proyectos de 3.7 a 4.2. Puede migrar cargas de trabajo de aplicaciones utilizando la herramienta de migración de aplicaciones en clúster (CAM). CAM le permite controlar la migración y minimizar el tiempo de inactividad de las aplicaciones.
Open Shift 4.3
Las principales innovaciones descritas en este artículo aparecieron en la versión 4.2. Los cambios 4.3 lanzados recientemente no son tan grandes, pero todavía hay algunas cosas nuevas. La lista de cambios es bastante extensa, aquí están los más significativos en nuestra opinión:
Actualice la versión de Kubernetes a 1.16.
La versión se actualizó en dos pasos a la vez; en OpenShift 4.2 era 1.14.
Cifrado de datos en etcd.
A partir de la versión 4.3, fue posible cifrar datos en la base de datos etcd. Una vez habilitado el cifrado, será posible cifrar los siguientes recursos de la API de OpenShift y la API de Kubernetes: secretos, ConfigMaps, rutas, tokens de acceso y autorización de OAuth.
Casco
Se agregó soporte para Helm versión 3, un popular administrador de paquetes para Kubernetes. Por ahora, el soporte tiene el estado VISTA PREVIA DE TECNOLOGÍA. La compatibilidad con Helm se ampliará a compatibilidad total en futuras versiones de OpenShift. La utilidad helm cli viene con OpenShift y se puede descargar desde la consola web de administración del clúster.
Actualización del panel del proyecto
En la nueva versión, Project Dashboard proporciona información adicional en la página del proyecto: estado del proyecto, utilización de recursos y cuotas del proyecto.
Mostrando vulnerabilidades para quay en la consola web
Se ha agregado una función a la consola de administración para mostrar vulnerabilidades conocidas de imágenes en los repositorios de Quay. Se admite la visualización de vulnerabilidades para repositorios locales y externos.
Creación simplificada de operatorhub fuera de línea
Para el caso de implementar un clúster OpenShift en una red aislada, desde la cual el acceso a Internet es limitado o inexistente, se simplifica la creación de un "espejo" para el registro de OperadorHub. Ahora esto se puede hacer con sólo tres equipos.
Autores:
Víctor Puchkov, Yuri Semenyukov
Fuente: habr.com