"¿Cuál es la diferencia entre Kubernetes y OpenShift?" – esta pregunta surge con envidiable consistencia. Aunque en realidad esto es como preguntar en qué se diferencia un coche de un motor. Si continuamos con la analogía, entonces un automóvil es un producto terminado, puedes usarlo de inmediato, literalmente: súbete y listo. Por otro lado, para que un motor te lleve a alguna parte, primero debe complementarse con muchas otras cosas para, finalmente, conseguir el mismo coche.
Por tanto, Kubernetes es el motor alrededor del cual se ensambla el coche (plataforma) de la marca OpenShift, que te lleva a tu objetivo.
En este artículo queremos recordarte y examinar con un poco más de detalle los siguientes puntos clave:
- Kubernetes es el corazón de la plataforma OpenShift y es Kubernetes 100% certificado, completamente de código abierto y sin el más mínimo carácter propietario. Brevemente:
- La API del clúster OpenShift es XNUMX% Kubernetes.
- Si el contenedor se ejecuta en cualquier otro sistema Kubernetes, se ejecutará en OpenShift sin ningún cambio. No es necesario realizar cambios en las aplicaciones.
- OpenShift no solo agrega características y funcionalidades útiles a Kubernetes. Al igual que un automóvil, OpenShift está listo para usar, se puede poner en producción de inmediato y, como mostraremos a continuación, hace la vida del desarrollador mucho más fácil. Por eso OpenShift es una de cada dos personas. Es una plataforma PaaS de clase empresarial exitosa y reconocida desde la perspectiva del desarrollador. Y al mismo tiempo, es una solución de contenedor como servicio súper confiable desde el punto de vista de la operación industrial.
OpenShift es Kubernetes con certificación 100% CNCF
OpenShift se basa en . Por lo tanto, después de una capacitación adecuada, los usuarios quedan sorprendidos por el poder de kubectl. Y aquellos que cambiaron a OpenShift desde Kubernetes Cluster a menudo dicen lo mucho que les gusta que después de redirigir kubeconfig al clúster de OpenShift, todos los scripts existentes funcionen perfectamente.
Probablemente hayas oído hablar de la utilidad de línea de comandos de OpenShift llamada OC. Es totalmente compatible con los comandos de kubectl y, además, ofrece varios asistentes útiles que resultarán útiles a la hora de realizar una serie de tareas. Pero primero, un poco más sobre la compatibilidad de OC y kubectl:
comandos kubectl
Equipos CO
kubectl consigue vainas
oc conseguir vainas
kubectl obtiene espacios de nombres
oc obtener espacios de nombres
kubectl crear -f implementación.yaml
oc crear -f implementación.yaml
Así es como se ven los resultados del uso de kubectl en la API de OpenShift:
• kubectl get pods: devuelve pods como se esperaba.
• kubectl obtiene espacios de nombres: devuelve espacios de nombres como se esperaba.
El comando kubectl create -f mydeployment.yaml crea recursos de Kubernetes como en cualquier otra plataforma de Kubernetes, como se muestra en el siguiente vídeo:
En otras palabras, todas las API de Kubernetes están completamente disponibles en OpenShift y mantienen una compatibilidad del 100 %. Es por eso que .
OpenShift agrega funciones útiles a Kubernetes
Las API de Kubernetes están 100% disponibles en OpenShift, pero la utilidad estándar de Kubernetes kubectl claramente carece de funcionalidad y conveniencia. Es por eso que Red Hat ha agregado funciones útiles y herramientas de línea de comandos a Kubernetes, como OC (abreviatura de cliente OpenShift) y ODO (OpenShift DO, esta utilidad está dirigida a desarrolladores).
1. Utilidad OC: una versión más potente y cómoda de Kubectl
Por ejemplo, a diferencia de kubectl, le permite crear nuevos espacios de nombres y cambiar contextos fácilmente, y también ofrece una serie de comandos útiles para los desarrolladores, como crear imágenes de contenedores e implementar aplicaciones directamente desde el código fuente o binarios (Fuente a imagen, s2i).
Veamos ejemplos de cómo los asistentes integrados y la funcionalidad avanzada de la utilidad OC ayudan a simplificar el trabajo diario.
El primer ejemplo es la gestión de espacios de nombres. Cada clúster de Kubernetes siempre tiene varios espacios de nombres. Normalmente se utilizan para crear entornos de desarrollo y producción, pero también se pueden utilizar, por ejemplo, para proporcionar a cada desarrollador un entorno de pruebas personal. En la práctica, esto da como resultado que el desarrollador tenga que cambiar frecuentemente entre espacios de nombres, ya que kubectl se ejecuta en el contexto del espacio actual. Por lo tanto, en el caso de kubectl, la gente utiliza activamente scripts de ayuda para ello. Pero cuando use OC, para cambiar al espacio deseado, simplemente diga "espacio de nombres del proyecto oc".
¿No recuerdas cómo se llama el espacio de nombres que necesitas? No hay problema, simplemente escriba "oc get proyectos" para mostrar la lista completa. ¿Se pregunta escéptico cómo funcionará esto si solo tiene acceso a un subconjunto limitado de espacios de nombres en el clúster? Bueno, porque kubectl solo hace esto correctamente si RBAC le permite ver todos los espacios en el clúster, y en clústeres grandes no todos reciben esos permisos. Entonces, respondemos: para el OC esto no es ningún problema y fácilmente producirá una lista completa en tal situación. Son estos pequeños detalles los que conforman la orientación corporativa de Openshift y la buena escalabilidad de esta plataforma en términos de usuarios y aplicaciones.
2. ODO: una versión mejorada de kubectl para desarrolladores
Otro ejemplo de las mejoras de Red Hat OpenShift con respecto a Kubernetes es la utilidad de línea de comandos ODO. Está diseñado para desarrolladores y le permite implementar rápidamente código local en un clúster remoto de OpenShift. También puede optimizar los procesos internos para sincronizar instantáneamente todos los cambios de código en contenedores en un clúster remoto de OpenShift sin tener que reconstruir, registrar y volver a implementar imágenes.
Veamos cómo OC y ODO facilitan el trabajo con contenedores y Kubernetes.
Simplemente compare un par de flujos de trabajo cuando se crean sobre la base de kubectl y cuando se utilizan OC u ODO.
• Implementación de código en OpenShift para quienes no hablan YAML:
Kubernetes/kubectl
$>git clon
1- Crea un Dockerfile que construye la imagen a partir del código
-----
DESDE el nodo
DIRTRABAJO /usr/src/app
COPIAR paquete*.json ./
COPIAR index.js ./
COPIAR ./aplicación ./aplicación
EJECUTAR instalación npm
EXPONER 3000
CMD [ “npm”, “inicio” ] ————–
2- Construimos la imagen
$>compilación de podman...
3- Inicia sesión en el registro
iniciar sesión en podman...
4- Coloca la imagen en el registro.
empujón podman
5- Cree archivos yaml para la implementación de aplicaciones (deployment.yaml, service.yaml, ingress.yaml): este es el mínimo absoluto
6- Implementar archivos de manifiesto:
Kubectl aplica -f .
OpenShift/oc
$> oc nueva aplicación – nuestro_nombre_de_aplicación
OpenShift/odo
$>git clon
$> odo crear componente nodejs myapp
$>odo empujar
• Cambio de contexto: cambia el espacio de nombres de trabajo o el grupo de trabajo.
Kubernetes/kubectl
1- Crea un contexto en kubeconfig para el proyecto “myproject”
2- contexto establecido de kubectl…
OpenShift/oc
proyecto oc “miproyecto”
Control de calidad: “Aquí ha aparecido una característica interesante, todavía en versión alfa. ¿Quizás podamos ponerlo en producción?
Imagínese estar sentado en un coche de carreras y que le digan: “Hemos instalado un nuevo tipo de frenos y, para ser sincero, su fiabilidad aún no es buena... Pero no te preocupes, los mejoraremos activamente durante el curso. del campeonato”. ¿Qué te parece esta perspectiva? En Red Hat no estamos muy contentos. 🙂
Por lo tanto, intentamos posponer las versiones alfa hasta que estén lo suficientemente maduras y hayamos realizado pruebas de batalla exhaustivas y consideremos que son seguras de usar. Por lo general, todo pasa primero por la etapa Dev Preview y luego por y solo entonces sale como un lanzamiento público (GA), que ya es tan estable que es apto para la producción.
¿Porqué es eso? Porque, como ocurre con el desarrollo de cualquier otro software, no todas las ideas iniciales en Kubernetes llegan a la versión final. O lo alcanzan e incluso conservan la funcionalidad prevista, pero su implementación es radicalmente diferente a la de la versión alfa. Con miles y miles de clientes de Red Hat que utilizan OpenShift para soportar cargas de trabajo de misión crítica, ponemos especial énfasis en la estabilidad de nuestra plataforma y el soporte a largo plazo.
Red Hat se compromete a lanzar OpenShift con frecuencia y actualizar la versión de Kubernetes que lo acompaña. Por ejemplo, la versión GA actual de OpenShift 4.3 al momento de escribir este artículo incluye Kubernetes 1.16, que está solo una unidad por detrás de la versión anterior de Kubernetes numerada 1.17. Por lo tanto, estamos tratando de brindarle al cliente Kubernetes de clase empresarial y brindar control de calidad adicional a medida que lanzamos nuevas versiones de OpenShift.
Correcciones de software: “Hubo un agujero en la versión de Kubernetes que tenemos en producción. Y puedes cerrarlo solo actualizando tres versiones. ¿O hay alguna opción?
En el proyecto de código abierto de Kubernetes, las correcciones de software generalmente se publican como parte de la siguiente versión, a veces cubriendo una o dos versiones importantes anteriores, lo que brinda una cobertura de tan solo 6 meses.
Red Hat se enorgullece de publicar correcciones críticas antes que otros y de brindar soporte durante mucho más tiempo. Tomemos, por ejemplo, la vulnerabilidad de escalada de privilegios de Kubernetes (): se descubrió en Kubernetes 1.11, y las correcciones para versiones anteriores se publicaron solo hasta la versión 1.10.11, lo que deja a esta en el hueco de todas las versiones anteriores de Kubernetes, desde 1.xa 1.9.
A su vez, (Kubernetes 1.2 está ahí), capturando nueve versiones de OpenShift y demostrando claramente la atención a los clientes (más detalles ).
Cómo OpenShift y Red Hat están haciendo avanzar a Kubernetes
Red Hat es el segundo mayor contribuyente de software al proyecto Kubernetes de código abierto, sólo detrás de Google, y 3 de los 5 desarrolladores más prolíficos provienen de Red Hat. Otro hecho poco conocido: muchas funciones críticas aparecieron en Kubernetes precisamente por iniciativa de Red Hat, en particular, como por ejemplo:
- RBAC. Kubernetes no tenía funciones RBAC (ClusterRole, ClusterRoleBinding) hasta que los ingenieros de Red Hat decidieron implementarlas como parte de la propia plataforma y no como una funcionalidad adicional de OpenShift. ¿Red Hat tiene miedo de mejorar Kubernetes? Por supuesto que no, porque Red Hat sigue estrictamente los principios de código abierto y no juega juegos Open Core. Las mejoras e innovaciones impulsadas por comunidades de desarrollo, en lugar de las propietarias, son más viables y se adoptan más ampliamente, lo que se alinea bien con nuestro objetivo principal de hacer que el software de código abierto sea más útil para nuestros clientes.
- Políticas de seguridad para pods (Políticas de seguridad de pods). Este concepto de ejecutar aplicaciones de forma segura dentro de pods se implementó originalmente en OpenShift con el nombre SCC (Security Context Constraints). Y como en el ejemplo anterior, Red Hat decidió introducir estos desarrollos en el proyecto abierto Kubernetes para que todo el mundo pudiera utilizarlos.
Esta serie de ejemplos podría continuar, pero solo queríamos mostrar que Red Hat está realmente comprometido con el desarrollo de Kubernetes y hacerlo mejor para todos.
Está claro que OpenShift es Kubernetes. ¿Cuáles son las diferencias? 🙂
Esperamos que al leer hasta aquí se haya dado cuenta de que Kubernetes es el componente central de OpenShift. El principal, pero ni mucho menos el único. En otras palabras, simplemente instalar Kubernetes no le brindará una plataforma de clase empresarial. Deberá agregar autenticación, redes, seguridad, monitoreo, administración de registros y más. Además, tendrás que tomar algunas decisiones difíciles entre la gran cantidad de herramientas disponibles (para apreciar la diversidad del ecosistema, solo echa un vistazo ) y de alguna manera asegurar consistencia y coherencia para que funcionen como uno solo. Además, deberá realizar actualizaciones y pruebas de regresión periódicamente cada vez que se publique una nueva versión de cualquiera de los componentes que utilice. Es decir, además de crear y mantener la propia plataforma, también tendrás que ocuparte de todo este software. Es poco probable que quede mucho tiempo para resolver los problemas empresariales y lograr ventajas competitivas.
Pero en el caso de OpenShift, Red Hat asume todas estas complejidades y simplemente le brinda una plataforma funcionalmente completa, que incluye no solo el propio Kubernetes, sino también todo el conjunto de herramientas de código abierto necesarias que convierten a Kubernetes en una verdadera clase empresarial. solución que puede poner en producción de forma inmediata y completamente tranquila. Y, por supuesto, si tiene algunas de sus propias pilas de tecnología, puede integrar OpenShift en las soluciones existentes.
Mire la imagen de arriba: todo lo que está fuera del rectángulo de Kubernetes es donde Red Hat agrega funcionalidad que Kubernetes no tiene, como dicen, por diseño. Y ahora veremos la principal de estas áreas.
1. SO robusto como base: RHEL CoreOS o RHEL
Red Hat ha sido un proveedor líder de distribuciones de Linux para aplicaciones críticas para el negocio durante más de 20 años. Nuestra experiencia acumulada y constantemente actualizada en esta área nos permite ofrecer una base verdaderamente confiable y confiable para la operación industrial de contenedores. RHEL CoreOS utiliza el mismo kernel que RHEL, pero está optimizado principalmente para tareas como ejecutar contenedores y ejecutar clústeres de Kubernetes: su tamaño reducido e inmutabilidad facilitan la configuración de clústeres, el escalado automático, la implementación de parches, etc. Todas estas características lo hacen una base ideal para ofrecer la misma experiencia de usuario con OpenShift en una amplia gama de entornos informáticos, desde bare metal hasta la nube pública y privada.
2. Automatización de las operaciones de TI
La automatización de los procesos de instalación y las operaciones del día 4 (es decir, las operaciones del día a día) es el punto fuerte de OpenShift, ya que hace que sea mucho más fácil administrar, actualizar y mantener el rendimiento de la plataforma de contenedores al más alto nivel. Esto se logra mediante el soporte para los operadores de Kubernetes en el nivel del kernel OpenShift XNUMX.
OpenShift 4 es también todo un ecosistema de soluciones basadas en operadores de Kubernetes, desarrollado tanto por la propia Red Hat como por terceros socios (ver. Red Hat o tienda de operador , 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 (Plataforma como servicio) que hace la vida mucho más fácil a los desarrolladores, les ayuda a centrarse en la codificación y ofrece soporte nativo para lenguajes de programación como Java, Node.js. , PHP, Ruby, Python, Go, así como servicios de entrega e integración continua de 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 GUI dedicada (), que ayuda a los desarrolladores a implementar sin esfuerzo aplicaciones de diversas fuentes (git, registros externos, Dockerfile, etc.) en sus espacios de nombres y visualiza claramente las relaciones entre los componentes de la aplicación.
Además, OpenShift ofrece un conjunto de herramientas de desarrollo Codeready, que, en particular, incluye , un IDE completamente en contenedores con una interfaz web que se ejecuta directamente sobre OpenShift e implementa un enfoque de IDE como servicio. Por otro lado, para aquellos que quieran trabajar estrictamente en modo local, existe Codeready Containers, una versión completamente funcional de OpenShift 4 que se puede implementar en una computadora portátil.
IDE integrado como servicio para un desarrollo eficiente en la plataforma Kubernetes/OpenShift
OpenShift ofrece un sistema CI/CD completo listo para usar, ya sea basado en Jenkins en contenedores o un complemento para trabajar con canalizaciones o un sistema CI/CD orientado a Kubernetes (actualmente en versión de vista previa técnica). Ambas soluciones se integran completamente con la consola de OpenShift, lo que le permite ejecutar activadores de canalizaciones, ver implementaciones, registros y más.
4. Herramientas de aplicación
OpenShift le permite implementar tanto aplicaciones con estado tradicionales como soluciones basadas en la nube basadas en nuevas arquitecturas, como microservicios o sin servidor. La solución OpenShift Service Mesh viene lista para usar con herramientas clave para el mantenimiento de microservicios, como Istio, Kiali y Jaeger. A su vez, la solución OpenShift Serverless incluye no solo Knative, sino también herramientas como Keda creada como parte de una iniciativa conjunta con Microsoft para proporcionar funciones de Azure en la plataforma OpenShift.
La solución integrada OpenShift ServiceMesh (Istio, Kiali, Jaeger) será útil a la hora de desarrollar microservicios
Para cerrar la brecha entre las aplicaciones heredadas y los contenedores, OpenShift ahora permite la migración de máquinas virtuales a la plataforma OpenShift utilizando Container Native Virtualization (actualmente en TechPreview), haciendo realidad las aplicaciones híbridas y facilitando su migración entre diferentes nubes, tanto privadas como públicas.
Máquina virtual Windows 2019 que se ejecuta en OpenShift a través de la virtualización nativa de contenedores (actualmente en la versión de vista previa técnica)
5. Herramientas para clusters
Cualquier plataforma de clase empresarial debe tener servicios de monitoreo y registro centralizados, mecanismos de seguridad, autenticación y autorización, y herramientas de administración de red. Y OpenShift proporciona todo esto listo para usar, y todo es 100% de código abierto, incluidas soluciones como ElasticSearch, Prometheus, Grafana. Todas estas soluciones vienen con paneles, métricas y alertas que ya están creados y configurados utilizando la amplia experiencia en monitoreo de clústeres de Red Hat, lo que le permite controlar y monitorear de manera efectiva su entorno de producción desde el principio.
OpenShift también viene de serie con cosas tan importantes para los clientes corporativos como autenticación con un proveedor de autenticación integrado, integración con proveedores de credenciales, incluidos LDAP, ActiveDirectory, OpenID Connect y mucho más.
Panel de control de Grafana preconfigurado para la supervisión del clúster OpenShift
Más de 150 métricas y alertas de Prometheus preconfiguradas para la supervisión del clúster OpenShift
To be continued
La rica funcionalidad de la solución y la amplia experiencia de Red Hat en el campo de Kubernetes son las razones por las que OpenShift ha logrado una posición dominante en el mercado, como se muestra en la siguiente figura (leer más ).
“Red Hat actualmente lidera el mercado con una participación del 44%.
La empresa está cosechando los beneficios de su estrategia de ventas centrada en el cliente, donde primero consulta y capacita a desarrolladores empresariales y luego pasa a la monetización a medida que la empresa comienza a implementar contenedores en producción”.
(Historia: )
Esperamos que hayas disfrutado de este artículo. En futuras publicaciones de esta serie, analizaremos más de cerca las ventajas de OpenShift sobre Kubernetes en cada una de las categorías analizadas aquí.
Fuente: habr.com