Red Hat OpenShift 4.20 ya está disponible para el público en general. Se basa en Kubernetes 1.33 y CRI-O 1.33 y, junto con Red Hat OpenShift Platform Plus, destaca nuestro compromiso de ofrecer una plataforma de aplicaciones confiable, integral y uniforme. En OpenShift, las cargas de trabajo de inteligencia artificial, los contenedores y la virtualización coexisten sin problemas, lo que permite que las empresas generen innovaciones más rápido en la nube híbrida, sin comprometer la seguridad.
OpenShift, que está disponible en versiones de servicios de nube autogestionados o totalmente gestionados, ofrece una plataforma de aplicaciones con un conjunto completo de herramientas y servicios integrados para las cargas de trabajo nativas de la nube, de inteligencia artificial, virtuales y tradicionales por igual. Este artículo destaca las últimas innovaciones y mejoras clave de OpenShift 4.20. Para obtener una lista completa de las actualizaciones y las mejoras, consulta las notas de la versión de OpenShift 4.20.
Esta última versión aumenta las funciones de la plataforma para las cargas de trabajo de inteligencia artificial con la disponibilidad general de LeaderWorkerSet, la extensión de inferencia de API de Gateway y la fuente de volumen de imágenes de tiempo de ejecución en Container Initiative (OCI). Además, refuerza las funciones principales e incorpora mejoras esenciales, como el uso de un proveedor de identidad externo propio, Zero Trust Workload Identity Manager, el espacio de nombres de usuario, el External Secrets Operator for Red Hat OpenShift y la compatibilidad con el protocolo de puerta de enlace de borde (BGP). Además, OpenShift 4.20 ofrece avances clave en la virtualización, como el reequilibrio consciente de la carga de la CPU y la migración activa más rápida, lo que proporciona una plataforma más sólida y versátil para diversas necesidades informáticas.
OpenShift 4.20 ahora habilita el mecanismo de intercambio de claves híbridas X25519MLKEM768 con la versión Go 1.24 como parte de nuestro proceso para agregar compatibilidad con la criptografía post-cuántica (PQC). Esto mejora la comunicación TLS entre los elementos principales del plano de control de Kubernetes, como el servidor de la API, el kubelet, el programador y el controlador-gestor, lo cual ayuda a protegerlos de los ataques cuánticos.
Las últimas versiones de Red Hat de Trusted Artifact Signer 1.3 y usted Profile Analyzer 2.2 ofrecen una combinación sólida de funciones de firma criptográfica y análisis avanzado de la cadena de suministro.
Distribuye y escala las cargas de trabajo de inteligencia artificial/machine learning con LeaderWorkerSet y JobSet
OpenShift 4.20 simplifica la implementación de las cargas de trabajo de inteligencia artificial distribuidas y complejas. Con el LeaderWorkerSet, disponible para el público en general, los equipos de plataformas pueden distribuir y ajustar de manera eficiente los modelos de inteligencia artificial que exceden la capacidad de un solo pod, utilizando un pod líder para organizar sin problemas la comunicación entre los pods de trabajo. JobSet, que está disponible como versión de prueba de la tecnología, agrupa y gestiona las tareas distribuidas con programación flexible y tolerancia a los errores, permite que los equipos aprovechen las GitOpsconocidas, el control de acceso basado en funciones (RBAC) y los patrones de supervisión incluso para los flujos de trabajo de machine learning más exigentes. En conjunto, permiten la organización integral de las cargas de trabajo de entrenamiento (JobSet) y de inferencia (LeaderWorkerSet) a escala, lo que ofrece una gestión del ciclo de vida de inteligencia artificial/machine learning sólida, escalable y eficiente dentro de OpenShift.
Enrutamiento nativo de la inteligencia artificial con Red Hat OpenShift AI 3
Las cargas de trabajo de inteligencia artificial y del machine learning presentan desafíos únicos que impiden que las estrategias tradicionales de equilibrio de carga, como la operación por turnos, sean adecuadas. Red Hat OpenShift AI 3 aborda estos desafíos con la inferencia distribuida con llm-dy el uso de las extensiones de API Inference Extensions (GIE) de Kubernetes Gateway. OpenShift 4.20 incluye GIE, que se basa en la API de Kubernetes Gateway para proporcionar enrutamiento especializado y gestión del tráfico para las cargas de trabajo de inteligencia artificial/machine learning. Si ya utilizas la API de Kubernetes Gateway para tus aplicaciones, ahora puedes aplicar el mismo enfoque declarativo a la distribución de los modelos de inteligencia artificial.
GIE está disponible automáticamente en OpenShift 4.20 cuando se crea un recurso InferencePool. Un recurso InferencePool representa un conjunto de pods de inferencia de inteligencia artificial o machine learning y un endpoint dinámico que contiene una lógica de enrutamiento especializada. El programador de inferencias llm-d, que forma parte de Red Hat OpenShift AI 3, funciona como endpoint dinámico, ya que recopila los datos de telemetría expuestos por vLLM con el protocolo de servidor de modelos, lo que permite tomar decisiones de enrutamiento inteligentes basadas en la mejor instancia de modelo disponible en un momento dado.
La GIE se implementa con la puerta de enlace de Istio respaldada por el proxy Envoy a través de OpenShift Service Mesh 3.2. Actualmente, solo es compatible con Red Hat OpenShift AI 3. Con GIE, las cargas de trabajo de inteligencia artificial se pueden gestionar a través de los mismos canales de GitOps y políticas de RBAC. Ya sea que estés prestando servicios a un solo modelo u organizando un canal de inferencia complejo de varios modelos, GIE convierte lo que antes era una infraestructura de inteligencia artificial especializada en una ruta más en tu clúster.
Actualiza los modelos de inteligencia artificial sin tocar tus pods
Los LLM y los modelos de machine learning suelen superar los 10 GB, lo cual ralentiza las reconstrucciones de contenedores y consume mucho espacio de almacenamiento. Ya no tienes que reconstruir los contenedores cada vez que se actualiza tu modelo de inteligencia artificial. En OpenShift 4.20, puedes montar los pesos de los modelos directamente desde tu registro de contenedores como volúmenes, de modo que los analistas de datos puedan enviar nuevas versiones del modelo al registro mientras los contenedores de distribución de modelos permanecen sin cambios. Solo tienes que hacer referencia a la imagen OCI en la especificación de tu pod y OpenShift se encargará del resto. Ahora, los modelos se convierten en artefactos versionables independientes del código, se extraen bajo demanda utilizando la autenticación de registro familiar, se almacenan en caché localmente para mejorar el rendimiento y se actualizan sin tocar tus implementaciones.
Chatea con tus clústeres de OpenShift o Kubernetes con lenguaje natural
Nos complace anunciar la versión de prueba para desarrolladores del servidor del protocolo de contexto de modelo (MCP) de Kubernetes para OpenShift y Kubernetes. El servidor MCP de Kubernetes revoluciona la gestión de la infraestructura al conectar los asistentes de inteligencia artificial, como VS Code, Microsoft Copilot y Cursor, con los entornos de OpenShift y Kubernetes. El servidor MCP de Kubernetes, que cuenta con operaciones CRUD integrales, gestión avanzada de pods, integración de Helm e implementación en varias plataformas, transforma la gestión de los clústeres y la resolución de problemas a través de consultas en lenguaje natural.
Además, integramos la detección de incidentes en OpenShift Lightspeed con MCP. Esto lleva el análisis de incidentes directamente a la interfaz conversacional, lo que cambia la forma en que exploras y resuelves los problemas del clúster.
Agiliza las cargas de trabajo de inteligencia artificial con las DPU de NVIDIA Bluefield
Red Hat OpenShift junto con las DPU de NVIDIA Bluefield está disponible como versión de prueba y ofrece un enfoque optimizado para implementar soluciones de seguridad, enrutamiento y almacenamiento para las cargas de trabajo empresariales, de inteligencia artificial y de telecomunicaciones. Esta solución hace hincapié en la agilización del hardware y el aislamiento de la seguridad para las cargas de trabajo de la infraestructura y las aplicaciones, lo cual mejora el uso de los recursos y maximiza la capacidad del servidor. Las unidades de procesamiento de datos (DPU) de NVIDIA son esenciales para los diseños de las fábricas de inteligencia artificial y Spectrum-X de NVIDIA, y las futuras versiones de OpenShift están preparadas para permitir la implementación y la organización sin problemas de la solución Spectrum-X y los diseños de las fábricas de inteligencia artificial de NVIDIA.
Optimiza la gestión de identidades con soporte nativo de OIDC
OpenShift 4.20 ahora permite la integración directa con proveedores de identidad externos de OpenID Connect (OIDC) para emitir tokens para la autenticación, lo que te brinda más control sobre tus sistemas de autenticación. Al integrarte directamente con un proveedor de OIDC externo, puedes aprovechar las funciones avanzadas de tu proveedor de OIDC preferido en lugar de verte limitado por las funciones del servidor OAuth integrado. Tu empresa puede gestionar los usuarios y los grupos desde una sola interfaz y, al mismo tiempo, optimizar la autenticación en varios clústeres y en entornos híbridos.
Gestiona las identidades de las cargas de trabajo con la confianza cero en OpenShift
Zero Trust Workload Identity Manager estará disponible para el público en general en OpenShift 4.20 en las próximas semanas. Zero Trust Workload Identity Manager proporciona identidades certificadas en tiempo de ejecución y verificables mediante cifrado para todas las cargas de trabajo. Zero Trust Workload Identity Manager, que se basa en SPIFFE y SPIRE, ofrece funciones básicas como el registro automático de las cargas de trabajo, la federación de SPIRE a SPIRE para la confianza universal en los entornos híbridos y multicloud, la federación de OIDC para la integración con los sistemas de identidad empresariales actuales y la autenticación sin secretos con la integración de Hashicorp Vault.
Zero Trust Workload Identity Manager establece la confianza universal, elimina los secretos estáticos y permite que las identidades verificables y de corta duración se comuniquen entre cargas de trabajo centradas en la seguridad. Proporciona identidades uniformes y certificadas durante el tiempo de ejecución para todas las cargas de trabajo desarrolladas en la nube, desde los servicios tradicionales hasta los nuevos sistemas de inteligencia artificial con agentes, lo cual garantiza la responsabilidad y el seguimiento de cada acción de la carga de trabajo y constituye la base de las arquitecturas de confianza cero en todo el entorno de las aplicaciones. Se requieren suscripciones a OpenShift Platform Plus, Red Hat Advanced Cluster Security for Kubernetes o Red Hat Advanced Cluster Management para poder gestionar las identidades de las cargas de trabajo entre las nubes cuando se utilizan en más de un clúster.
Optimiza la gestión de secretos con External Secrets Operator
En OpenShift 4.20, el External Secrets Operator for Red Hat OpenShift (ESO) ya está disponible para el público en general. ESO es un servicio para todo el clúster que proporciona gestión del ciclo de vida de los secretos que se obtienen de los sistemas de gestión de secretos externos. Al integrarse con sistemas externos de gestión de secretos, como AWS Secrets Manager, HashiCorp Vault y Azure Key Vault, ESO obtiene, actualiza y prepara los secretos dentro del clúster, lo que garantiza que los secretos confidenciales fluyan de manera más segura y eficiente en las cargas de trabajo sin la intervención directa de las aplicaciones.
Elimina los riesgos del aumento de los privilegios de los contenedores con espacios de nombres de usuario
Con la disponibilidad general de los espacios de nombres de usuario en OpenShift 4.20, Red Hat permite que las cargas de trabajo se ejecuten con un aislamiento mejorado y, al mismo tiempo, mantiene la flexibilidad que los desarrolladores necesitan para diseñar aplicaciones modernas. Los espacios de nombres de usuario de OpenShift mejoran considerablemente la seguridad, ya que aíslan a los usuarios de los contenedores de los usuarios del host, reducen el riesgo de sufrir ataques de aumento de privilegios y permiten que los contenedores se ejecuten como usuarios que no son superusuarios en el host, mientras conservan los privilegios internos de superusuario para las operaciones. Esto se traduce en entornos multiempresa más seguros y en un mayor cumplimiento de los estándares de seguridad empresarial.
Malla de servicios sin sidecars con el modo Ambient de Istio
OpenShift Service Mesh 3.2 incorpora el soporte disponible para el público en general para la malla de servicios sin sidecars con el modo Ambient de Istio. Se trata de un plano de datos completamente nuevo para Istio que utiliza dos niveles de proxy para habilitar las funciones de la malla de servicios según sea necesario con un uso mínimo de recursos adicionales.
El primer proxy es el ztunnel de nivel de nodo («para la confianza cero») que proporciona cifrado TLS mutuo de capa 4, telemetría y políticas de autorización básicas. Si bien es un proxy de nodo, redirige el tráfico desde el espacio de nombres de red único de cada pod, lo que garantiza que el tráfico esté aislado y cifrado en el pod. El siguiente proxy es el waypoint orientado a la aplicación, que se puede implementar opcionalmente para proporcionar funciones de malla de capa 7, como la telemetría y las políticas basadas en las características específicas de la aplicación, como los tipos de solicitud HTTP o los encabezados.
Esta arquitectura reduce considerablemente los costos de los recursos para ejecutar una malla de servicios, en especial para las funciones que solo requieren el proxy ztunnel, como el cifrado mTLS de pod a pod. Obtén más información en Optimización del tráfico y la determinación del estado interno con OpenShift Service Mesh 3.
Soporte nativo de BGP en OpenShift Networking
Red Hat OpenShift Networking ahora ofrece funciones propias de enrutamiento del protocolo de puerta de enlace de borde (BGP) dentro de su plug-in de red predeterminado, OVN-Kubernetes. Esta mejora amplía considerablemente los casos prácticos de red que antes admitían MetalLB (equilibrio de carga de servicios externos) y el operador de red de clústeres (estructura de red de capa 3, multiconexión, redundancia de enlaces y convergencia rápida).
A partir de OpenShift 4.20, BGP permite que las redes de máquinas virtuales (VM) y pods con alcance de clúster se anuncien directamente en una red de proveedor compatible con BGP a través del enrutador BGP de la red externa. Por el contrario, las rutas aprendidas de BGP desde la red del proveedor se pueden volver a importar a OVN-Kubernetes, ya sea en la red de pods predeterminada o en una red definida por el usuario (UDN) específica. Esta integración bidireccional permite el intercambio fluido de rutas entre OpenShift y las estructuras de red externas. El soporte está disponible inicialmente para las plataformas de servidores dedicados (bare metal), y el soporte para la plataforma de nube está destinado a una versión posterior.
Para mejorar la capacidad de ajuste, los reflectores de ruta se pueden implementar opcionalmente entre el clúster y las redes externas. Un ejemplo común que ilustra la naturaleza dinámica y los beneficios del anuncio de ruta basado en BGP es un evento de conmutación por error o migración de máquina virtual. Cuando una máquina virtual se traslada a otro nodo, conserva su dirección IP estática, y la tabla BGP actualiza de forma automática y rápida la ruta anunciada para la red de esa máquina virtual, lo que garantiza una conectividad permanente con interrupciones mínimas.
Detecta los problemas antes de actualizar tu clúster
En OpenShift 4.20, dos comandos nuevos brindan a los usuarios visibilidad de los posibles problemas de actualización antes y durante las actualizaciones. Los comandos oc adm upgrade recommend y oc adm upgrade status ya están disponibles para el público en general.
Antes de que comiences una actualización, oc adm upgrade recommend analiza el clúster en busca de alertas conocidas. Muestra las alertas que causan problemas, como PodDisruptionBudgets en su límite, operadores de clústeres no disponibles o alertas que podrían ralentizar el drenaje de los nodos. Verás las versiones que están disponibles en tu canal de actualización, los problemas conocidos con esas versiones y, lo que es más importante, las condiciones que son realmente problemáticas en comparación con el comportamiento normal del clúster.
$ oc adm upgrade recommend
Failing=True:
Reason: ClusterOperatorNotAvailable
Message: Cluster operator monitoring is not available
The following conditions found no cause for concern in updating this cluster to later releases: recommended/NodeAlerts (AsExpected), recommended/PodImagePullAlerts (AsExpected)
The following conditions found cause for concern in updating this cluster to later releases: recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1
recommended/PodDisruptionBudgetAlerts/PodDisruptionBudgetAtLimit/1=False:
Reason: Alert: firing
Message: warning alert PodDisruptionBudgetAtLimit firing, which might slow node drains. Namespace=openshift-monitoring, PodDisruptionBudget-prometheus-k8s. The pod disruption budget is preventing further disruption to pods. The alert description is: The pod disruption budget is at the minimum disruptions allowed level. The number of current healthy pods is equal to the desired healthy pods.
https://github.com/openshift/runbooks/blob/master/alerts/cluster-kube-controller-manager-operator/PodDisruptionBudgetAtLimit.md
Upstream update service: https://api.integration.openshift.com/api/upgrades_info/graph
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.18, eus-4.18, fast-4.18, fast-4.19, stable-4.18, stable-4.19)
Updates to 4.18:
VERSION ISSUES
4.18.32 no known issues relevant to this cluster
4.18.30 no known issues relevant to this cluster
And 2 older 4.18 updates you can see with '--show-outdated-releases' or '--version VERSION'.Después de la actualización, oc adm upgrade status muestra a los usuarios lo que está sucediendo en tiempo real: el progreso del plano de control y del nodo de trabajo, los porcentajes de finalización, las estimaciones de tiempo y las advertencias si algo falla. Ambos comandos son de solo lectura y no cambian nada en el clúster de OpenShift. Para obtener más información, consulta Updating a cluster by using the CLI.
Optimiza las implementaciones en el extremo de la red con OpenShift de dos nodos
Optimiza las implementaciones en el extremo de la red con OpenShift de dos nodos con árbitro. Esto proporciona las mismas características de alta disponibilidad que un clúster estándar de OpenShift de tres nodos, pero requiere solo dos servidores de tamaño completo, complementados con un nodo árbitro ligero para el quórum.
El nodo árbitro se ejecuta como una tercera instancia de etcd para garantizar el quórum con solo 2 vCPU y 8 GB de memoria. Mientras tanto, los dos nodos de tamaño completo se encargan de toda la carga de trabajo real, mientras que el árbitro pequeño garantiza que el clúster pueda tolerar la interrupción de un solo nodo sin perder disponibilidad. Solo se necesitan dos suscripciones a servidores dedicados (bare metal), y el nodo árbitro no contribuye a los costos de licencia. Obtén más información en Efficient Two Node Edge Infrastructure delivered by Red Hat OpenShift and Portworx/Pure Storage.
Reequilibrio con reconocimiento de la carga y migración más rápida de las máquinas virtuales en Red Hat OpenShift Virtualization 4.20
El reequilibrio con reconocimiento de carga basado en la presión de la CPU en Red Hat OpenShift Virtualization 4.20 ya está disponible para el público en general. Esto mejora la distribución de las cargas de trabajo en los nodos del clúster al considerar de forma dinámica el uso de los recursos de los nodos en tiempo real y migrar las máquinas virtuales de los nodos sobreutilizados a aquellos con capacidad disponible.
OpenShift Virtualization también ofrece una gestión simplificada de las máquinas virtuales con funciones para varios clústeres, mejoras en la velocidad de migración a OpenShift a través del migration toolkit for virtualization, la función de distribución del almacenamiento de las soluciones de los principales proveedores de almacenamiento, migración en vivo a un nodo específico y ampliación del soporte para Arm. Las mejoras en las redes, como BGP para las redes definidas por el usuario de capa 2, mejoran aún más la eficiencia y la flexibilidad de las cargas de trabajo virtualizadas.
Adapta las cargas de trabajo de virtualización en Oracle Cloud Infrastructure
OpenShift Virtualization ya está disponible para el público en general en instancias con servidores dedicados (bare metal) en Oracle Cloud Infrastructure. Esto brinda a nuestros clientes en común la flexibilidad para ejecutar sus cargas de trabajo de máquinas virtuales desde cualquier ubicación a través de la nube distribuida de OCI. Más información en Unlocking Virtualization at Scale on OCI.
Expande OpenShift a las nubes soberanas de Oracle
Por último, pero no menos importante, OpenShift amplía su soporte para Oracle Cloud Infrastructure, y hace especial hincapié en las nubes soberanas, como Oracle EU Sovereign Cloud, Oracle US Government Cloud, Oracle Cloud for UK Government & Defence, Oracle Cloud Isolated Regions y Oracle Alloy. Esta mejora brinda a las empresas mayor flexibilidad y opciones para implementar OpenShift en las nubes que abordan las necesidades fundamentales de soberanía de los datos, cumplimiento normativo y seguridad mejorada dentro de los entornos de nube especializados. Más información en Expanded Oracle Cloud Infrastructure Support.
Prueba Red Hat OpenShift 4.20 hoy mismo
Comienza hoy mismo con Red Hat Hybrid Cloud Console y aprovecha las funciones y las mejoras más recientes de OpenShift. Para conocer las próximas novedades, consulta los siguientes recursos:
- What’s New and What’s Next in Red Hat OpenShift
- What’s New in Red Hat OpenShift 4.20
- Prueba las nuevas demostraciones interactivas de OpenShift 4.20
- In the Clouds
- Canal de YouTube de OpenShift
- OpenShift Blogs
- OpenShift Commons
- Red Hat Developer Blogs
- Red Hat Portfolio Architecture Center
- Validated Patterns
La lista completa de las actualizaciones de Red Hat OpenShift 4.20 se encuentra en las Notas de la versión de OpenShift 4.20. Envíanos tus comentarios a través de tus contactos de Red Hat o reporta problemas en GitHub.
Prueba del producto
Red Hat OpenShift Container Platform | Versión de prueba del producto
Sobre los autores
Ju Lim works on the core Red Hat OpenShift Container Platform for hybrid and multi-cloud environments to enable customers to run Red Hat OpenShift anywhere. Ju leads the product management teams responsible for installation, updates, provider integration, and cloud infrastructure.
Subin Modeel is a principal technical product manager at Red Hat.
Más como éste
Zero trust starts here: Validated patterns for confidential container deployment
The Red Hat OpenShift advantage: Zero trust and sovereignty for cloud-native and AI workloads
Navegar por canal
Automatización
Las últimas novedades en la automatización de la TI para los equipos, la tecnología y los entornos
Inteligencia artificial
Descubra las actualizaciones en las plataformas que permiten a los clientes ejecutar cargas de trabajo de inteligecia artificial en cualquier lugar
Nube híbrida abierta
Vea como construimos un futuro flexible con la nube híbrida
Seguridad
Vea las últimas novedades sobre cómo reducimos los riesgos en entornos y tecnologías
Edge computing
Conozca las actualizaciones en las plataformas que simplifican las operaciones en el edge
Infraestructura
Vea las últimas novedades sobre la plataforma Linux empresarial líder en el mundo
Aplicaciones
Conozca nuestras soluciones para abordar los desafíos más complejos de las aplicaciones
Virtualización
El futuro de la virtualización empresarial para tus cargas de trabajo locales o en la nube