La cuarta versión de OpenShift se lanzó relativamente hace poco. La versión actual 4.3 está disponible desde finales de enero, y todos los cambios que presenta son o algo completamente nuevo que no existía en la tercera versión, o una actualización importante de lo que ya estaba en la versión 4.1. Todo lo que vamos a contar ahora es necesario saber, entender y tener en cuenta para aquellos que trabajan con OpenShift y planean hacer la transición a la nueva versión.
Con el lanzamiento de OpenShift 4.2, Red Hat facilitó el trabajo con Kubernetes. Aparecieron nuevas herramientas y complementos para la creación de contenedores, procesos de CI/CD y despliegues sin servidor. Las innovaciones permiten a los desarrolladores centrarse en escribir código, en lugar de lidiar con Kubernetes.
Entonces, ¿qué hay de nuevo en las versiones OpenShift 4.2 y 4.3?
Movimiento hacia la nube híbrida
Al planificar una nueva infraestructura de TI o al desarrollar el paisaje de TI existente, las empresas consideran cada vez más el enfoque en la nube para proporcionar recursos de TI, implementando soluciones de nube privada o utilizando los servicios de proveedores de nube pública. Así, las modernas infraestructuras de TI se construyen con un modelo de nube 'híbrido', que utiliza tanto recursos on-premises como recursos de nube pública con un sistema de gestión compartido. Red Hat OpenShift 4.2 está diseñado específicamente para simplificar la transición al modelo de nube híbrida y permite integrar fácilmente recursos de proveedores como AWS, Azure y Google Cloud Platform junto con soluciones de nube privada en VMware y OpenStack.
Un nuevo enfoque para la instalación
En la cuarta versión, se cambió el enfoque para la instalación de OpenShift. Red Hat proporciona una herramienta especial para desplegar clústeres de OpenShift: openshift-install. La herramienta es un único archivo binario escrito en Go. Openshift-installer prepara un archivo yaml con la configuración necesaria para el despliegue.
En caso de instalación utilizando recursos en la nube, será necesario indicar la información mínima sobre el futuro clúster: zona DNS, número de nodos worker, configuraciones específicas para el proveedor de nube y los datos de la cuenta para acceder al proveedor de nube. Después de preparar el archivo de configuración, el clúster puede ser desplegado con un solo comando.
En el caso de la instalación en recursos computacionales propios, como al usar una nube privada (se admiten vSphere y OpenStack) o al instalar en servidores bare metal, será necesario configurar manualmente la infraestructura: preparar la cantidad mínima de máquinas virtuales o servidores físicos requeridos para crear un clúster de Control Plane y configurar los servicios de red. Después de dicha configuración, el clúster de OpenShift podrá ser creado de manera similar con un solo comando de la herramienta openshift-installer.
Actualizaciones en la infraestructura
Integración con CoreOS
La clave de la actualización es la integración con Red Hat CoreOS. Ahora, los nodos master de Red Hat OpenShift pueden operar solo en un nuevo sistema operativo. Este es un sistema operativo gratuito de Red Hat, diseñado específicamente para soluciones de contenedores. Red Hat CoreOS es una versión ligera de Linux, optimizada para ejecutar contenedores.
Si en 3.11 el sistema operativo y OpenShift existían por separado, en 4.2 están intrínsecamente relacionados con OpenShift. Ahora es un appliance único: infraestructura inmutable.
Para clústeres que utilizan RHCOS para todos los nodos, la actualización de OpenShift Container Platform es un proceso simple y bien automatizado.
Antes, para actualizar OpenShift, era necesario primero actualizar el sistema operativo base sobre el cual se ejecutaba el producto (en ese momento era Red Hat Enterprise Linux). Solo después de eso se podía actualizar OpenShift de manera gradual, nodo por nodo. No había automatización en el proceso.
Ahora, dada la capacidad de OpenShift Container Platform para controlar todos los sistemas y servicios en cada nodo, incluido el sistema operativo, esta tarea se resuelve con un solo clic desde la interfaz web. Después de esto, se inicia un operador especial dentro del clúster de OpenShift, que gestiona todo el proceso de actualización.
Nuevo CSI
El segundo — un nuevo CSI — es un controlador de interfaz de almacenamiento, que permite conectar diferentes sistemas de almacenamiento externos al clúster de OpenShift. Se admite una amplia gama de proveedores de controladores de almacenamiento para OpenShift, basados en controladores de almacenamiento que escriben los mismos fabricantes de sistemas de almacenamiento. La lista completa de los controladores CSI admitidos se puede encontrar en este documento: . En esta lista puedes 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 soporta el uso de controladores CSI de la especificación CSI versión 1.1.
RedHat OpenShift Service Mesh
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 trazabilidad y visualización. Esto ayuda a los desarrolladores a simplificar la interacción, la supervisión y la gestión de la aplicación desplegada dentro de Red Hat OpenShift.
Visualización de una aplicación con arquitectura de microservicios utilizando Kiali
Para simplificar al máximo los procesos de instalación, servicio y gestión del ciclo de vida de Service Mesh, Red Hat OpenShift proporciona a los administradores un operador especial: Service Mesh Operator. Este es un operador de Kubernetes que permite desplegar en el clúster paquetes reconfigurados de Istio, Kiali y Jaeger, reduciendo al máximo la carga administrativa para gestionar aplicaciones.
CRI-O en lugar de Docker
El runtime de contenedor predeterminado Docker ha sido reemplazado por CRI-O. Se podía utilizar CRI-O desde la versión 3.11, pero en 4.2 se convirtió en el principal. No es ni bueno ni malo, pero es importante tenerlo en cuenta al usar el producto.
Operadores y despliegue de aplicaciones
Los operadores son una nueva entidad para RedHat OpenShift que apareció en la cuarta versión. Este es un método de empaquetado, despliegue y gestión de aplicaciones Kubernetes. Se puede imaginar como un complemento administrado a través de la API de Kubernetes y herramientas kubectl para aplicaciones desplegadas en contenedores.
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 estás desplegando en tu clúster. Por ejemplo, un operador puede automatizar actualizaciones, copias de seguridad y escalado de la aplicación, cambiar configuraciones, etc. Puedes ver la lista completa de operadores en .
OperatorHub está disponible directamente desde la interfaz web de la consola de gestión. Es un catálogo de aplicaciones para OpenShift, soportado por Red Hat. Es decir, todos los operadores aprobados por Red Hat contarán con soporte del proveedor.
Portal OperatorHub en la consola de gestión de OpenShift
Imagen base universal
Este es un conjunto estandarizado de imágenes del sistema operativo RHEL que se pueden utilizar para crear sus aplicaciones en contenedores. Hay conjuntos mínimos, estándar y completos. Ocupan muy poco espacio y soportan todos los paquetes e idiomas de programación necesarios.
Herramientas CI/CD
En RedHat OpenShift 4.2, ahora se tiene la opción de elegir entre Jenkins y OpenShift Pipelines basado en Tekton Pipelines.
OpenShift Pipelines se basa en Tekton, que admite mejor los enfoques de Pipeline as Code y GitOps. En los pipelines de OpenShift, cada paso se ejecuta en su propio contenedor, por lo que los recursos sólo se utilizan durante la ejecución del paso. Esto da a los desarrolladores un control total sobre los pipelines de entrega de módulos, plugins y control de acceso sin un servidor central de CI/CD para gestionar.
OpenShift Pipelines se encuentra actualmente en fase Preview para desarrolladores y está disponible como operador en el clúster OpenShift 4. Por supuesto, los usuarios de OpenShift aún pueden utilizar Jenkins en RedHat OpenShift 4.
Actualizaciones en la gestión para desarrolladores
En 4.2, OpenShift ha renovado completamente la interfaz web tanto para desarrolladores como para administradores.
En versiones anteriores de OpenShift, todos trabajaban en tres consolas: catálogo de servicios, consola de administración y consola de trabajo. Ahora el clúster se ha dividido en solo dos partes: consola de administrador y consola de desarrollador.
La consola de desarrollador ha recibido mejoras significativas en la interfaz de usuario. Ahora muestra de manera más clara las topologías de aplicaciones y sus construcciones. Esto facilita a los desarrolladores crear, desplegar y visualizar aplicaciones en contenedores y recursos del clúster. Permite a los desarrolladores concentrarse en lo que realmente les importa.
Portal del desarrollador en la consola de administración de OpenShift
Odo
Odo es una herramienta de línea de comandos orientada a desarrolladores que simplifica el desarrollo de aplicaciones en OpenShift. Usando una interacción al estilo de git push, este CLI ayuda a los desarrolladores que no están familiarizados con Kubernetes a crear aplicaciones en OpenShift.
Integración con entornos de desarrollo
Los desarrolladores ahora pueden crear, depurar y desplegar sus aplicaciones en OpenShift sin salir de su entorno de desarrollo favorito, como Microsoft Visual Studio, JetBrains (incluyendo IntelliJ), Eclipse Desktop, etc.
Extensión de implementación de Red Hat OpenShift para Microsoft Azure DevOps
Ha surgido la extensión Red Hat OpenShift Deployment para Microsoft Azure DevOps. Ahora los usuarios de este conjunto de herramientas DevOps pueden desplegar sus aplicaciones en Azure Red Hat OpenShift o en cualquier otro clúster de OpenShift directamente desde Microsoft Azure DevOps.
Migración de la tercera versión a la cuarta
Dado que se trata de un nuevo lanzamiento y no de una actualización, no se puede simplemente instalar la cuarta versión sobre la tercera. No se admitirá la actualización de la tercera a la cuarta versión.
Pero hay buenas noticias: Red Hat proporciona herramientas para migrar proyectos de 3.7 a 4.2. Puedes trasladar cargas de trabajo de aplicaciones utilizando la herramienta Cluster Application Migration (CAM). CAM permite controlar la migración y minimizar el tiempo de inactividad de la aplicación.
OpenShift 4.3
Las principales innovaciones descritas en este artículo aparecieron en la versión 4.2. En la recién lanzada 4.3, los cambios no son tan significativos, pero aún hay algo nuevo. La lista de cambios es bastante amplia; mencionaremos las más relevantes a nuestro juicio:
Actualización de la versión de Kubernetes a 1.16.
La versión ha avanzado dos pasos; en OpenShift 4.2 era 1.14.
Cifrado de datos en etcd
A partir de la versión 4.3, existe la posibilidad de cifrar datos en la base etcd. Después de habilitar el cifrado, será posible cifrar los siguientes recursos de OpenShift API y Kubernetes API: Secrets, ConfigMaps, Routes, tokens de acceso y autorización OAuth.
Helm
Se ha añadido soporte para Helm versión 3, un popular gestor de paquetes para Kubernetes. Por ahora, el soporte tiene estatus de TECHNOLOGY PREVIEW. En futuras versiones de OpenShift, el soporte para Helm se ampliará a completo. La utilidad helm cli se proporciona junto con OpenShift y se puede descargar desde la consola web de gestión del clúster.
Actualización del Project Dashboard
En la nueva versión, el Project Dashboard proporciona información adicional en la página del proyecto: estado del proyecto, utilización de recursos y cuotas para el proyecto.
Visualización de vulnerabilidades para quay en la consola web
Se ha añadido a la consola de gestión la función de visualización de vulnerabilidades conocidas para imágenes en los repositorios Quay. Se admite la visualización de vulnerabilidades para repositorios locales y externos.
Simplificación de la creación de operatorhub offline
Para la implementación de un clúster OpenShift en una red aislada, cuyo acceso a Internet está restringido o es inexistente, se ha simplificado la creación de un "espejo" para el registro de OperatorHub. Ahora se podrá hacer con solo tres comandos.
Autores:
Victor Puchkov, Yuri Semenyukov
Fuente: habr.com
