«¿Cuál es la diferencia entre Kubernetes y OpenShift?» – esta pregunta surge con envidiable frecuencia. En realidad, es como preguntar en qué se diferencia un automóvil de un motor. Si continuamos con la analogía, el automóvil es un producto terminado, que se puede usar inmediatamente, literalmente: te subes y te vas. Por otro lado, para que el motor te lleve a algún lugar, primero hay que complementarlo con una serie de otras piezas para finalmente conseguir ese mismo automóvil.
Por lo tanto, Kubernetes es el motor alrededor del cual se ha construido el automóvil (plataforma) llamado OpenShift, que es el que te conduce a tu objetivo.
En este artículo queremos recordar y desglosar un poco más los siguientes puntos clave:
- Kubernetes es el corazón de la plataforma OpenShift Y es un Kubernetes 100% certificado, con código completamente abierto y sin la más mínima propiedad. En resumen:
- La API para el clúster de OpenShift es un Kubernetes al 100%.
- Si un contenedor funciona en cualquier otro sistema Kubernetes, funcionará sin cambios en OpenShift. No es necesario modificar las aplicaciones.
- OpenShift no solo complementa Kubernetes con funciones y capacidades útiles. Al igual que un automóvil, OpenShift está listo para usarse de inmediato, se puede poner en producción de inmediato y, como mostraremos más adelante, simplifica considerablemente la vida del desarrollador. Por eso OpenShift tiene doble cara. Desde la perspectiva del desarrollador, es una exitosa y ampliamente reconocida plataforma PaaS de clase empresarial. Y al mismo tiempo, es una solución súper confiable de tipo Container-as-a-Service desde el punto de vista de la explotación industrial.
OpenShift es Kubernetes con 100% de certificación por parte de la fundación CNCF
En la base de OpenShift hay . Por lo tanto, después de la formación adecuada, los usuarios quedan impresionados con el poder de kubectl. Y aquellos que han migrado a OpenShift desde un clúster de Kubernetes a menudo comentan cuánto les gusta que, tras redirigir kubeconfig al clúster de OpenShift, todos los scripts existentes funcionan a la perfección.
Seguramente has oído hablar de la utilidad de línea de comandos de OpenShift llamada OC. Es completamente compatible en comandos con kubectl, además, ofrece varios ayudantes útiles que serán útiles para realizar una serie de tareas. Pero primero, hablemos un poco más sobre la compatibilidad entre OC y kubectl:
Comandos kubectl
Comandos OC
kubectl get pods
oc get pods
kubectl get namespaces
oc obtener espacios de nombres
kubectl crear -f deployment.yaml
oc crear -f deployment.yaml
Así es como se ven los resultados del uso de kubectl en la API de OpenShift:
• kubectl obtener pods – devuelve los pods como era de esperar.
• kubectl obtener espacios de nombres – devuelve los espacios de nombres como era de esperar.
El comando kubectl crear -f mydeployment.yaml crea recursos de kubernetes exactamente igual que en cualquier otra plataforma de Kubernetes, como se muestra en el video a continuación:
En otras palabras, todas las API de Kubernetes están completamente disponibles en OpenShift con un 100% de compatibilidad. Por eso .
OpenShift complementa Kubernetes con funciones útiles
Las API de Kubernetes están disponibles al 100% en OpenShift, pero la utilidad estándar de Kubernetes, kubectl, carece de ciertas funcionalidades y conveniencia. Por lo tanto, Red Hat ha complementado Kubernetes con funciones útiles y herramientas de línea de comandos, como OC (abreviatura de OpenShift client) y ODO (OpenShift DO, esta utilidad está diseñada para desarrolladores).
1. La utilidad OC – una opción más potente y conveniente que Kubectl
Por ejemplo, a diferencia de kubectl, permite crear nuevos espacios de nombres y cambiar de contexto fácilmente, además de ofrecer una serie de comandos útiles para desarrolladores, como la construcción de imágenes de contenedores y el despliegue de aplicaciones directamente desde el código fuente o archivos binarios (Source-to-image, s2i).
Veamos con ejemplos cómo los helpers integrados y la funcionalidad ampliada de la utilidad OC ayudan a simplificar el trabajo diario.
Ejemplo uno – gestión de espacios de nombres. En cada clúster de Kubernetes siempre hay varios espacios de nombres. Generalmente se utilizan para crear entornos de desarrollo y producción, pero también pueden ser utilizados para, por ejemplo, proporcionar a cada desarrollador un "sandbox" personal. En la práctica, esto significa que un desarrollador tiene que cambiar frecuentemente entre espacios de nombres, ya que kubectl trabaja en el contexto del espacio actual. Por lo tanto, para kubectl, la gente utiliza activamente scripts helper para esto. En cambio, al usar OC, para cambiar al espacio necesario, solo es necesario decir “oc project espacio_nombre”.
¿No recuerdas cómo se llama el espacio de nombres que necesitas? No hay problema, simplemente escribe “oc get projects” para mostrar una lista completa en pantalla. ¿Tienes cierta escepticismo sobre cómo funcionará esto si solo tienes acceso a un subconjunto limitado de espacios de nombres en el clúster? Bien, porque kubectl lo hace correctamente solo si RBAC te permite ver todos los espacios en el clúster, y en clústeres grandes, tales permisos no se otorgan a todos. Así que, para OC, en realidad no es un problema y fácilmente te dará una lista completa en esa situación. De estas pequeñas cosas se compone la orientación empresarial de Openshift y su buena escalabilidad en términos de usuarios y aplicaciones.
2. ODO – versión mejorada de kubectl para desarrolladores
Como otro ejemplo de las mejoras de Red Hat OpenShift en comparación con Kubernetes, está la herramienta de línea de comandos ODO. Está diseñada para desarrolladores y permite desplegar rápidamente código local en un clúster remoto de OpenShift. Además, ayuda a optimizar procesos internos para sincronizar instantáneamente todos los cambios de código con contenedores en el clúster remoto de OpenShift sin la necesidad de reconstruir, almacenar en el registro y volver a desplegar las imágenes.
Veamos cómo OC y ODO facilitan el trabajo con contenedores y Kubernetes.
Compararemos un par de flujos de trabajo cuando se basan en kubectl y cuando se aplican OC o ODO.
• Despliegue de código en OpenShift para quienes no dominan el lenguaje YAML:
Kubernetes / kubectl
$> git clone
1- Creamos un Dockerfile que construya la imagen a partir del código
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ “npm”, “start” ]
————–
2- Construimos la imagen
$> podman build …
3- Iniciamos sesión en el registro
podman login …
4- Publicamos la imagen en el registro
podman push
5- Creamos archivos yaml para el despliegue de la aplicación (deployment.yaml, service.yaml, ingress.yaml) – este es el mínimo absoluto.
6- Desplegamos los archivos manifest:
Kubectl apply -f .
OpenShift / oc
$> oc new-app – nombre_de_nuestra_aplicación
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Cambio de contexto: cambio del espacio de nombres de trabajo o del clúster de trabajo.
Kubernetes / kubectl
1- Creamos un contexto en kubeconfig para el proyecto “myproject”
2- kubectl set-context …
OpenShift / oc
oc project “myproject”
Control de calidad: "Aquí ha surgido una función interesante, que está en versión alfa. ¿Podríamos implementarla en producción?"
Imagina que te sientan en un coche de carreras y te dicen: "Hemos instalado frenos de un nuevo tipo y, sinceramente, todavía no son completamente confiables... Pero no te preocupes, los estaremos perfeccionando a lo largo del campeonato". ¿Qué te parece esta perspectiva? A nosotros en Red Hat no nos parece muy atractiva. 🙂
Por lo tanto, tratamos de evitar versiones alfa hasta que no estén suficientemente maduras y hayamos realizado pruebas de combate exhaustivas y sintamos que se pueden usar de forma segura. Normalmente, todo pasa primero por una fase de Dev Preview, luego por y solo después se lanza como una versión pública. (GA), que es estable lo suficiente como para ser usada en producción.
¿Por qué es así? Porque, al igual que en el desarrollo de cualquier otro software, no todas las ideas iniciales de Kubernetes llegan a la versión final. O llegan y mantienen la funcionalidad prevista, pero su implementación difiere drásticamente de la que estaba en la versión alfa. Dado que miles y miles de clientes de Red Hat utilizan OpenShift para soportar tareas críticas, hacemos un énfasis especial en la estabilidad de nuestra plataforma y en el soporte a largo plazo.
Red Hat lanza intencionadamente versiones frecuentes de OpenShift y actualiza la versión de Kubernetes que incluye. Por ejemplo, en la versión GA de OpenShift 4.3, vigente en el momento de escribir este artículo, está incorporada Kubernetes 1.16, que solo se retrasa un número respecto a la versión upstream de Kubernetes 1.17. De esta forma, tratamos de proporcionar a los clientes Kubernetes de clase empresarial y garantizar un control de calidad adicional en el lanzamiento de nuevas versiones de OpenShift.
Correcciones de software: "En la versión de Kubernetes que tenemos en producción, se encontró una vulnerabilidad. Y solo puede ser cerrada con una actualización de tres versiones hacia arriba. ¿O hay otras opciones?"
En el marco del proyecto abierto Kubernetes, las correcciones de software suelen salir con el siguiente lanzamiento, a veces cubren una o dos versiones intermedias anteriores, lo que abarca un total de seis meses atrás.
Red Hat se enorgullece de lanzar correcciones críticas antes que otros y de ofrecer soporte durante mucho más tiempo. Tomemos como ejemplo la vulnerabilidad de escalada de privilegios en Kubernetes (): se descubrió en Kubernetes 1.11, y las correcciones para versiones anteriores se lanzaron solo hasta la versión 1.10.11, dejando esta brecha en todos los lanzamientos anteriores de Kubernetes, desde 1.x hasta 1.9.
Por su parte, (donde se encuentra Kubernetes 1.2), cubriendo nueve lanzamientos de OpenShift y demostrando claramente su compromiso con los clientes (más detalles ).
Cómo OpenShift y Red Hat impulsan Kubernetes
Red Hat ocupa el segundo lugar en contribuciones al proyecto de código abierto Kubernetes, superado solo por Google, y tres de los cinco desarrolladores más prolíficos son empleados de Red Hat. Otro hecho poco conocido: muchas funciones críticas en Kubernetes surgieron gracias a la iniciativa de Red Hat, en particular, tales como:
- RBAC. En Kubernetes no había funciones de RBAC (ClusterRole, ClusterRoleBinding) hasta que los ingenieros de Red Hat decidieron implementarlas como parte de la plataforma misma, y no como una funcionalidad adicional en OpenShift. ¿Tiene miedo Red Hat de mejorar Kubernetes? Por supuesto que no, ya que Red Hat sigue estrictamente los principios del software de código abierto y no juega a los juegos de Open Core. Las mejoras e innovaciones que se implementan a nivel de comunidades de desarrollo, y no bajo un modelo propietario, se vuelven más viables y se difunden más ampliamente, lo cual se alinea perfectamente con nuestro objetivo principal: hacer que el software de código abierto sea más útil para nuestros clientes.
- Políticas de seguridad para pods (Pod Security Policies). Originalmente, este concepto de ejecutar aplicaciones de manera segura dentro de los pods se implementó en OpenShift bajo el nombre de SCC (Security Context Constraints). Y como en el ejemplo anterior, Red Hat decidió incorporar estos desarrollos en el proyecto de código abierto Kubernetes para que todos los que lo deseen puedan beneficiarse de ellos.
Este conjunto de ejemplos se puede continuar, pero solo queríamos mostrar que Red Hat realmente se esfuerza por desarrollar Kubernetes y hacerlo mejor para todos.
Está claro, OpenShift es Kubernetes. ¿Y en qué se diferencian? 🙂
Esperamos que, al llegar a este punto, haya quedado claro que Kubernetes es el componente principal de OpenShift. Principal, pero no el único. En otras palabras, simplemente instalar Kubernetes no le proporcionará una plataforma de clase empresarial. Necesitará agregar autenticación, red, seguridad, monitoreo, gestión de registros y mucho más. Además, tendrá que hacer una difícil elección entre la gran cantidad de herramientas disponibles (para evaluar la diversidad del ecosistema, simplemente eche un vistazo a la ), y de alguna manera asegurar la coherencia y la sinergia para que funcionen como un todo. Además, deberá realizar actualizaciones y pruebas de regresión regularmente cada vez que se publique una nueva versión de cualquiera de los componentes utilizados. Es decir, además de crear y mantener la plataforma en sí, también deberá ocuparse de todo este software. Probablemente no quedará mucho tiempo para resolver problemas de negocio y alcanzar ventajas competitivas.
En el caso de OpenShift, la empresa Red Hat se encarga de todas estas complejidades y simplemente le proporciona una plataforma funcional completa, que no solo incluye Kubernetes, sino también todo el conjunto de herramientas necesarias de código abierto que transforman Kubernetes en una auténtica solución de clase empresarial que puede implementarse de inmediato y sin preocupaciones en producción. Y, por supuesto, si tiene sus propias pilas tecnológicas, puede integrar OpenShift en las soluciones existentes.
Mire la imagen de arriba: todo lo que está fuera del rectángulo de Kubernetes son las áreas donde Red Hat agrega funcionalidades que faltan en Kubernetes, que están ahí por diseño. Ahora revisaremos las principales de estas áreas.
1. Un sistema operativo confiable como base: RHEL CoreOS o RHEL
Red Hat ha sido durante más de 20 años el proveedor líder de distribuciones de Linux para aplicaciones empresariales críticas. La experiencia adquirida y constantemente actualizada en este campo nos permite ofrecer una base verdaderamente confiable y segura para la implementación industrial de contenedores. RHEL CoreOS utiliza el mismo núcleo que RHEL, pero está optimizada principalmente para tareas como la ejecución de contenedores y el funcionamiento en clústeres de Kubernetes: su tamaño reducido y su inalterabilidad (immutabilidad) facilitan la instalación de clústeres, el escalado automático, la implementación de parches, etc. Todas estas características la convierten en la base ideal para obtener la misma experiencia del usuario al trabajar con OpenShift en una variedad de entornos computacionales, desde hardware puro hasta nubes privadas y públicas.
2. Automatización de operaciones de TI
La automatización de procesos de instalación y operaciones del segundo día (es decir, la operación diaria) es el fuerte de OpenShift, que facilita en gran medida la administración, actualización y el mantenimiento del funcionamiento de la plataforma de contenedores al más alto nivel. Esto se logra gracias al soporte de operadores de Kubernetes a nivel del núcleo de OpenShift 4.
OpenShift 4 también es todo un ecosistema de soluciones basadas en operadores de Kubernetes, desarrolladas tanto por Red Hat como por socios externos (ver Red Hat, o la tienda de operadores , creado por Red Hat para desarrolladores externos).
El catálogo integrado de OpenShift 4 incluye más de 180 operadores de Kubernetes
3. Herramientas para desarrolladores
Desde 2011, OpenShift está disponible como una plataforma PaaS (Platform-as-a-Service), que facilita significativamente la vida a los desarrolladores, ayudándoles a concentrarse en la creación de código y ofreciendo soporte integrado para lenguajes de programación como Java, Node.js, PHP, Ruby, Python, Go, así como servicios de integración continua y entrega CI/CD, bases de datos, etc. OpenShift 4 ofrece , que incluye más de 100 servicios basados en operadores de Kubernetes, desarrollados por Red Hat y nuestros socios.
A diferencia de Kubernetes, OpenShift 4 tiene una interfaz gráfica especial (), ayudando a los desarrolladores a desplegar sin esfuerzo aplicaciones de diversas fuentes (git, registros externos, Dockerfile, etc.) en sus espacios de nombres y visualizando claramente las interconexiones entre los componentes de la aplicación.
Además, OpenShift ofrece un conjunto de herramientas de desarrollo Codeready, que incluye, entre otras, , una IDE completamente contenida con interfaz web que funciona directamente sobre OpenShift y aplica el enfoque de 'IDE como servicio'. Por otro lado, para aquellos que desean trabajar estrictamente en modo local, existe Codeready Containers, una versión completamente funcional de OpenShift 4 que se puede desplegar en una laptop.
IDE integrada como servicio para un desarrollo eficaz en la plataforma Kubernetes/OpenShift.
OpenShift ofrece, directamente desde la caja, un sistema completo de CI/CD, ya sea basado en Jenkins contenerizado y su complemento de para trabajar con canalizaciones, o un sistema de CI/CD orientado a Kubernetes. (actualmente en versión de Tech preview). Ambas soluciones se integran completamente con la consola de OpenShift, permitiendo activar disparadores de canalización, visualizar despliegues, registros, etc.
4. Herramientas para aplicaciones
OpenShift permite desplegar tanto aplicaciones tradicionales stateful como soluciones orientadas a la nube basadas en nuevas arquitecturas, como microservicios o serverless. La solución OpenShift Service Mesh incluye directamente herramientas clave para la gestión de microservicios, como Istio, Kiali y Jaeger. Por otro lado, la solución OpenShift Serverless incluye no solo Knative, sino también herramientas creadas en colaboración con Microsoft, como Keda, para proporcionar funciones de Azure en la plataforma OpenShift.
La solución integrada OpenShift ServiceMesh (Istio, Kiali, Jaeger) será útil en el desarrollo de microservicios.
Para cerrar la brecha entre las aplicaciones heredadas y los contenedores, OpenShift ahora permite migrar máquinas virtuales a la plataforma OpenShift mediante Contenedor de Virtualización Nativa (actualmente en versión de Tech Preview), convirtiendo las aplicaciones híbridas en una realidad y facilitando su portabilidad entre diferentes nubes, tanto privadas como públicas.
Máquina virtual Windows 2019 Virtual, ejecutándose en OpenShift a través de Contenedor de Virtualización Nativa (actualmente en versión de Tech preview).
5. Herramientas para clústeres
Cualquier plataforma de clase empresarial debe contar con servicios de monitoreo y registro centralizado, mecanismos de seguridad, autenticación y autorización, y herramientas de gestión de red. OpenShift ofrece todo esto de serie, y todo está bajo código abierto al 100%, incluyendo soluciones como ElasticSearch, Prometheus y Grafana. Todas estas soluciones vienen con paneles informativos, métricas y alertas que ya están organizadas y configuradas tomando en cuenta la amplia experiencia de Red Hat en monitoreo de clústeres, lo que permite controlar y rastrear eficientemente el funcionamiento de su entorno de producción desde el primer momento.
OpenShift también incluye de forma nativa elementos importantes para el cliente empresarial, como autenticación con un proveedor oauth integrado, integración con proveedores de credenciales, incluyendo LDAP, ActiveDirectory, OpenID Connect, y mucho más.
Panel informativo preconfigurado de Grafana para el monitoreo del clúster OpenShift
Más de 150 métricas y alertas preconfiguradas de Prometheus para el monitoreo del clúster OpenShift
Continuará
La rica funcionalidad de la solución y la amplia experiencia de Red Hat en Kubernetes son precisamente las razones por las que OpenShift ha logrado una posición dominante en el mercado, como se muestra en la imagen a continuación (más detalles ).
«Actualmente, Red Hat lidera el mercado con una participación del 44%.
La compañía está cosechando los frutos de su estrategia de ventas con una participación activa en los asuntos del cliente, donde primero asesora y capacita a los desarrolladores empresariales, y luego pasa a la monetización a medida que la empresa comienza a implementar contenedores en producción».
(Fuente: )
Esperamos que te haya gustado este artículo. En las siguientes publicaciones de esta serie, profundizaremos en las ventajas de OpenShift en comparación con Kubernetes en cada una de las categorías aquí discutidas.
Fuente: habr.com
