👨🏽‍💻 😖 🤳🏻 ¿Qué hay de nuevo en Red Hat OpenShift 4.2 y 4.3? 👨🏼‍🏭 🙇 🎂

La cuarta versión de OpenShift fue lanzada relativamente recientemente. La versión actual 4.3 está 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 le diremos debe saberlo, comprenderlo y tener en cuenta a quienes trabajan con OpenShift y planean actualizar a la nueva versión.

Con el lanzamiento de OpenShift 4.2, Red Hat ha simplificado 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, en lugar de litigar con Kubernetes.

En realidad, ¿qué hay de nuevo en las versiones de OpenShift 4.2 y 4.3?

Avanzar hacia nubes híbridas

Al planificar una nueva infraestructura de TI o desarrollar un panorama de TI existente, las empresas están considerando cada vez más el enfoque de la nube para proporcionar 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 están construyendo cada vez más en un modelo de nube "híbrido", cuando se utilizan tanto los recursos locales como los recursos de la 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 los recursos de proveedores como AWS, Azure y Google Cloud Platform al clúster junto con nubes privadas en VMware y OpenStack.

Nuevo enfoque de 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 el único archivo binario escrito en Go. Openshit-installer prepara un archivo yaml con la configuración requerida para la implementación.

En el caso de la instalación utilizando recursos de la nube, deberá especificar la información mínima sobre el futuro clúster: zona DNS, número de nodos de trabajo, 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.

Si instala en sus propios recursos informáticos, por ejemplo, cuando utiliza una nube privada (se admiten vSphere y OpenStack) o cuando se instala en servidores básicos, deberá configurar manualmente la infraestructura: prepare la cantidad mínima de máquinas virtuales o servidores físicos necesarios para crear un clúster de Control Plane, configure servicios de red. Después de esta configuración, el clúster OpenShift se puede crear de manera similar con un comando de utilidad openshift-installer.

Actualizaciones de infraestructura

Integración con CoreOS

Una actualización clave es la integración con Red Hat CoreOS. Ahora los nodos maestros de Red Hat OpenShift solo pueden funcionar en el nuevo sistema operativo. Este es un sistema operativo gratuito de Red Hat que está diseñado específicamente para soluciones en contenedores. Red Hat CoreOS es un Linux ligero optimizado para ejecutar contenedores.

Si en 3.11 el sistema operativo y OpenShift existían por separado, entonces en 4.2 está indisolublemente vinculado con OpenShift. Ahora se trata de un único dispositivo: infraestructura inmutable.

Para los clústeres que usan RHCOS para todos los nodos, la actualización de OpenShift Container Platform es un proceso simple y bien automatizado.

Anteriormente, para actualizar OpenShift, primero era necesario actualizar el sistema operativo subyacente en el que se ejecutaba el producto (en ese momento era Red Hat Enterprise Linux). Solo después de eso fue posible actualizar OpenShift 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 eso, se inicia un operador especial dentro del clúster OpenShift, que controla todo el proceso de actualización.

Nuevo CSI

El segundo es el nuevo CSI, el controlador de interfaz de almacenamiento, que le permite conectar varios sistemas de almacenamiento externo al clúster OpenShift. Se admite una gran cantidad de proveedores de controladores de almacenamiento para OpenShift en función de los controladores de almacenamiento escritos por los propios proveedores de almacenamiento. Puede encontrar una lista completa de controladores CSI compatibles en este documento: https://kubernetes-csi.imtqy.com/docs/drivers.html . 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 trabajar con 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 enrutar solicitudes entre servicios, le permite rastrearlas y visualizarlas. Esto ayuda a los desarrolladores a simplificar la interacción, el monitoreo y la administración de las aplicaciones implementadas dentro de Red Hat OpenShift.

Visualización de una aplicación con una arquitectura de microservicio utilizando Kiali

Para simplificar la instalación, el servicio y la gestión del ciclo de vida de Service Mesh, Red Hat OpenShift proporciona a los administradores un operador especial: Service Mesh Operator. Este es el operador de Kubernetes, que le permite implementar los paquetes reconfigurados de Istio, Kiali y Jaeger en el clúster, minimizando la carga administrativa de administrar las aplicaciones.

CRI-O en lugar de Docker

El contenedor predeterminado de tiempo de ejecución Docker ha sido reemplazado por CRI-O. CRI-O ya podría usarse en la versión 3.11, pero en 4.2 se convirtió en la principal. No es bueno ni está mal, pero vale la pena tenerlo en cuenta al usar el producto.

Operadores y aplicaciones de despliegue

Operadores: una nueva entidad para RedHat OpenShift, que apareció en la cuarta versión. Este es un método para empaquetar, implementar y administrar la aplicación Kubernetes. Se puede imaginar como un complemento para aplicaciones implementadas en contenedores administrados utilizando la API de Kubernetes y las herramientas de kubectl.

Los operadores de Kubernetes ayudan a automatizar cualquier tarea relacionada con la administración y gestión del ciclo de vida de una aplicación que implemente en su clúster. Por ejemplo, un operador puede automatizar actualizaciones, realizar copias de seguridad y escalar una aplicación, cambiar la configuración, etc. Puede encontrar una lista completa de operadores en https://operatorhub.io/ .

OperatorHub está disponible directamente desde la interfaz web de la consola de administración. Es un catálogo de aplicaciones para OpenShift mantenido por Red Hat. Aquellos. Todos los operadores aprobados por Red Hat estarán cubiertos por el soporte del proveedor.

OperatorHub Portal en la consola de administración de OpenShift

Imagen base universal

Este es un conjunto estandarizado de imágenes RHEL OS que puede usar para crear sus aplicaciones en contenedores. Hay conjuntos mínimos, estándar y completos. Ocupan muy poco espacio, admiten todos los paquetes instalados y los lenguajes de programación necesarios.

Herramientas CI / CD

RedHat OpenShif 4.2 tiene la capacidad de elegir entre Jenkins y OpenShift Pipelines basadas en Tekton Pipelines.

OpenShift Pipelines se basa en Tekton, que es mejor respaldado por Pipeline a medida que se acerca Code y GitOps. En las canalizaciones de OpenShift, cada paso se ejecuta en su propio contenedor, por lo que los recursos se usan solo durante la ejecución del paso. Esto proporciona a los desarrolladores un control completo sobre las tuberías de entrega de módulos, complementos y control de acceso sin un servidor central de CI / CD para la administración.

OpenShift Pipelines se encuentra actualmente en la etapa de Vista previa para desarrolladores y está disponible como operador en el clúster OpenShift 4. Por supuesto, los usuarios de OpenShift aún pueden usar Jenkins en RedHat OpenShift 4.

Actualizaciones de gestión para desarrolladores

En 4.2, OpenShift actualizó completamente la interfaz web tanto para desarrolladores como para administradores.

En versiones anteriores de OpenShift, todos trabajaban en tres consolas: un catálogo de servicios, una consola de administrador y una consola de trabajo. Ahora el clúster se divide en solo dos partes: la consola del administrador y la consola del desarrollador.

La consola del desarrollador ha recibido mejoras significativas en la interfaz de usuario. Ahora es más conveniente mostrar topologías de aplicaciones y sus ensamblajes. Esto facilita a los desarrolladores la creación, implementación y visualización de aplicaciones en contenedores y recursos de clúster. Le permite concentrarse en lo que es importante para ellos.

Portal del desarrollador en la consola de administración de OpenShift

Odo

Odo es una utilidad de línea de comandos orientada al desarrollador que simplifica el desarrollo de aplicaciones en OpenShift. Mediante la interacción de 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

Ha aparecido la extensión de implementación de Red Hat OpenShift para Microsoft Azure DevOps. Ahora los usuarios de este conjunto de herramientas DevOps pueden implementar sus aplicaciones en Azure Red Hat OpenShift o en cualquier otro clúster de OpenShift directamente desde Microsoft Azure DevOps.

Transición de la tercera versión a la cuarta.

Como estamos hablando de un nuevo lanzamiento, no de una actualización, no es tan fácil tomar y poner 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 mover proyectos de 3.7 a 4.2. Puede transferir cargas de trabajo de aplicaciones con la herramienta Cluster Application Migration (CAM). CAM le 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 versión 4.3 recientemente lanzada, los cambios no son tan significativos, pero todavía hay algo nuevo. La lista de cambios es bastante extensa, damos lo más significativo en nuestra opinión:

Actualice la versión de Kubernetes a 1.16.

La versión se actualizó inmediatamente a dos pasos, en OpenShift 4.2 era 1.14.

Cifrado de datos en etcd

A partir de la versión 4.3, se hizo posible encriptar datos en la base de datos etcd. Después de habilitar el cifrado, será posible cifrar los siguientes recursos de la API OpenShift y Kubernetes: Secretos, ConfigMaps, Rutas, tokens de acceso y autorización OAuth.

Timón

Se agregó soporte para la tercera versión de Helm, un popular administrador de paquetes para Kubernetes. Hasta ahora, el soporte tiene el estado de VISTA PREVIA DE TECNOLOGÍA. En futuras versiones de OpenShift, el soporte de Helm se ampliará por completo. La utilidad helm cli viene con OpenShift y se puede descargar desde la consola web de Cluster Management.

Project Dashboard Update

En la nueva versión de Project Dashboard, se proporciona información adicional en la página del proyecto: estado del proyecto, utilización de recursos y cuotas para el proyecto.

Mostrar vulnerabilidades para quay en la consola web

Se agregó la función de mostrar vulnerabilidades conocidas para imágenes en repositorios Quay a la consola de administración. Se admite el mapeo de vulnerabilidades para repositorios locales y externos.

Creación simplificada de operador sin conexión

Para el caso de implementar un clúster OpenShift en una red aislada, desde la cual el acceso a Internet es limitado o está ausente, se simplifica la creación de un "espejo" para el registro OperatorHub. Ahora esto se puede hacer con solo tres equipos.

Autor: Yuri Semenyukov

¿Qué hay de nuevo en Red Hat OpenShift 4.2 y 4.3?