👩🏿‍✈️ 👩‍👩‍👦‍👦 🚭 OpenShift como una versión empresarial de Kubernetes 🔧 🧤 🙍🏼

"¿Cuál es la diferencia entre Kubernetes y OpenShift?" - Esta pregunta surge con una constancia envidiable. Aunque en realidad es como preguntar en qué se diferencia un automóvil de un motor. Si continuamos con la analogía, entonces un automóvil es un producto terminado, puede usarlo inmediatamente, literalmente: se sentó y se fue. Por otro lado, para que el motor lo lleve a algún lugar, primero debe complementarse con una serie de otras cosas para poder obtener el mismo automóvil.

Por lo tanto, Kubernetes es un motor de este tipo, alrededor del cual se ensambla un automóvil (plataforma) de la marca OpenShift, que lo lleva a la meta.

En este artículo, queremos recordar y analizar con más detalle los siguientes puntos clave:

Kubernetes está en el corazón de la plataforma OpenShift, y está 100% certificada por Kubernetes, totalmente de código abierto y sin la más mínima propiedad. En breve:
- API OpenShift – Kubernetes.
- Kubernetes, - OpenShift. .
OpenShift Kubernetes . , OpenShift , , , . OpenShift . , PaaS- , . Container-as-a-Service .

OpenShift – Kubernetes 100% CNCF

OpenShift está basado en Kubernetes Certified . Por lo tanto, después de una capacitación adecuada, los usuarios admiran el poder de kubectl. Y aquellos que cambiaron a OpenShift con Kubernetes Cluster a menudo dicen que realmente les gusta eso después de redirigir kubeconfig al clúster OpenShift, todos los scripts disponibles funcionan a la perfección.

Probablemente haya escuchado sobre la utilidad de línea de comandos OpenShift llamada OC. Es totalmente compatible con los comandos de kubectl, además ofrece varios helper'ov útiles que son útiles al realizar una serie de tareas. Pero primero, un poco más sobre la compatibilidad con OC y kubectl:

Equipos Kubectl	Equipos OC
kubectl consigue vainas	oc obtener vainas
kubectl obtiene espacios de nombres	oc obtener espacios de nombres
kubectl create -f deploy.yaml	oc crear -f despliegue.yaml

Así es como se ven los resultados del uso de kubectl en la API de OpenShift:

• kubectl get pods: se espera que devuelva pods.

• kubectl obtiene espacios de nombres: se espera que devuelva espacios de nombres.

El comando kubectl create -f mydeployment.yaml crea recursos kubernetes como en cualquier otra plataforma Kubernetes, como se muestra en el siguiente video:

En otras palabras, todas las API de Kubernetes son totalmente accesibles en OpenShift con una compatibilidad del 100%. Es por eso que OpenShift es reconocido por la Cloud Native Computing Foundation (CNCF) como una plataforma certificada de Kubernetes .

OpenShift admite Kubernetes con características útiles

Las API de Kubernetes están 100% disponibles en OpenShift, pero la utilidad kubectl regular de Kubernetes carece claramente de funcionalidad y conveniencia. Por lo tanto, Red Hat agregó Kubernetes con características útiles y herramientas de línea de comandos como OC (abreviatura de cliente OpenShift) y ODO (OpenShift DO, esta utilidad está diseñada para desarrolladores).

1. La utilidad OC: una versión más potente y conveniente de Kubectl

Por ejemplo, a diferencia de kubectl, le permite crear nuevos espacios de nombres y cambiar fácilmente los contextos, y también ofrece una serie de comandos útiles para desarrolladores, por ejemplo, para construir imágenes de contenedores e implementar aplicaciones directamente desde el código fuente o archivos binarios (Source-to-image, s2i).

Veamos ejemplos de cómo el asistente integrado y la funcionalidad avanzada de la utilidad OC ayudan a simplificar el trabajo diario.

El primer ejemplo es la gestión del espacio de nombres. Cada clúster de Kubernetes siempre tiene múltiples espacios de nombres. Por lo general, se utilizan para crear entornos de desarrollo y producción, pero también se pueden utilizar para, por ejemplo, dar a cada desarrollador un "entorno limitado" personal. En la práctica, esto lleva al hecho de que el desarrollador a menudo tiene que cambiar entre espacios de nombres, ya que kubectl funciona en el contexto del espacio actual. Por lo tanto, en el caso de kubectl, la gente usa activamente scripts de ayuda para esto. Pero cuando se usa OC para cambiar al espacio deseado, es suficiente decir "oc proyecto namespace_".

¿No recuerdas cómo se llama el espacio de nombres? No hay problema, simplemente escriba "oc get projects" para mostrar una lista completa. ¿Se pregunta escépticamente cómo funcionará esto si solo tiene acceso a un subconjunto limitado de espacios de nombres en el clúster? Bueno, debido a que kubectl hace esto correctamente, solo si RBAC le permite ver todos los espacios en el clúster, y en grandes grupos, no todos otorgan dicha autoridad. Entonces, respondemos: para OC esto no es un problema en absoluto y proporcionará fácilmente una lista completa en tal situación. Es a partir de tales pequeñeces que se compone el enfoque corporativo 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 sobre Kubernetes es la utilidad de línea de comandos ODO. Está destinado a desarrolladores y le permite implementar rápidamente código local en un clúster remoto de OpenShift. Además, se puede usar para optimizar procesos internos para sincronizar instantáneamente todos los cambios de código con contenedores en un clúster remoto de OpenShift sin tener que volver a ensamblar, colocar en el registro y volver a implementar imágenes.

Veamos cómo OC y ODO hacen que el contenedor y Kubernetes sean más fáciles.

Simplemente compare un par de flujos de trabajo cuando se construyen sobre la base de kubectl, y cuando se utilizan OC u ODO.

• Implementación de código en OpenShift para aquellos que no hablan el lenguaje YAML:

Kubernetes / kubectl	$> git clone github.com/sclorg/nodejs-ex.git 1- Dockerfile, ————– FROM node WORKDIR /usr/src/app COPY package*.json ./ COPY index.js ./ COPY ./app ./app RUN npm install EXPOSE 3000 CMD [ “npm”, “start” ] ————– 2- $> podman build … 3- podman login … 4- podman push 5- yaml- (deployment.yaml, service.yaml, ingress.yaml) – 6- manifest-: Kubectl apply -f .
OpenShift / oc	$> oc new-app github.com/sclorg/nodejs-ex.git – __
OpenShift / odo	$> git clone github.com/sclorg/nodejs-ex.git $> odo create component nodejs myapp $> odo push

• : .

Kubernetes / kubectl	1- kubeconfig “myproject” 2- kubectl set-context …
OpenShift / oc	oc project “myproject”

: « , -. ?»

Imagina que estás sentado en un auto de carreras y dicen: "Hemos puesto un nuevo tipo de frenos aquí y, francamente, todavía no tienen todo en orden con fiabilidad ... Pero no te preocupes, los refinaremos activamente en el transcurso del campeonato". ¿Qué le parece esta perspectiva? Nosotros en Red Hat de alguna manera no somos muy buenos. :)

Por lo tanto, tratamos de abstenernos de las versiones alfa hasta que estén lo suficientemente maduras, y no realizamos pruebas de combate exhaustivas y sentimos que se pueden usar de manera segura. Por lo general, todo pasa primero a través de la etapa Vista previa de desarrollo, luego a través de Vista previa técnica, y solo luego sale en forma de lanzamiento público Disponibilidad general (GA), que ya es lo suficientemente estable como para ser adecuado para la producción.

¿Porqué es eso? Porque, como con el desarrollo de cualquier otro software, no todas las ideas iniciales en Kubernetes llegan a la versión final. O alcanzan e incluso retienen su funcionalidad prevista, pero su implementación es fundamentalmente diferente de la de la versión alfa. Como miles y miles de clientes de Red Hat usan OpenShift para respaldar tareas de misión crítica, ponemos un énfasis particular en la estabilidad de nuestra plataforma y el soporte a largo plazo.

Red Hat lanza deliberadamente lanzamientos frecuentes de OpenShift y actualiza su versión de Kubernetes. Por ejemplo, al momento de escribir este artículo, el lanzamiento de GA de OpenShift 4.3 incluye Kubernetes 1.16, que es solo una unidad detrás de la versión anterior de Kubernetes con el número 1.17. Por lo tanto, tratamos de ofrecer al cliente Kubernetes de clase empresarial y proporcionar un control de calidad adicional en el proceso de lanzamiento de nuevas versiones de OpenShift.

Correcciones de software: “Había una falla en esa versión de Kubernetes que tenemos en producción. Y solo puede cerrarlo actualizando tres versiones. ¿O hay opciones?

Como parte del proyecto de código abierto de Kubernetes, las correcciones de software generalmente se lanzan como parte de la próxima versión, a veces cubren una o dos versiones provisionales anteriores, lo que brinda cobertura solo hace 6 meses.

Red Hat está justificadamente orgulloso de lanzar soluciones críticas antes que otros y brindar soporte por un período mucho más largo. Tomemos, por ejemplo, la vulnerabilidad de escalada de privilegios de Kubernetes ( CVE-2018-1002105 ): se descubrió en Kubernetes 1.11, y los parches para versiones anteriores se lanzaron solo a la versión 1.10.11, dejando este agujero en todas las versiones anteriores de Kubernetes, desde 1 .x a 1.9.

A su vez, Red Hat parcheó OpenShift de nuevo a la versión 3.2(Kubernetes 1.2 está parado allí), capturando nueve versiones de OpenShift y demostrando atención al cliente (más información aquí ).

Cómo OpenShift y Red Hat hacen avanzar a Kubernetes

Red Hat ocupa el segundo lugar en términos de contribuciones de software al código abierto de Kubernetes, solo superado por Google, con 3 de los 5 desarrolladores más prolíficos que trabajan para Red Hat. Otro hecho poco conocido: muchas funciones críticas aparecieron en Kubernetes precisamente por iniciativa de Red Hat, en particular, tales como:

RBAC. Kubernetes RBAC (ClusterRole, ClusterRoleBinding) , Red Hat , OpenShift. Red Hat Kubernetes? , Red Hat , Open Core. , , , , – .
Políticas de seguridad para pods (Políticas de seguridad de pod). Inicialmente, este concepto de ejecución segura de aplicaciones dentro de pods se implementó en OpenShift bajo el nombre SCC (Restricciones de contexto de seguridad). Y como en el ejemplo anterior, Red Hat decidió introducir estos desarrollos en el proyecto Kubernetes de código abierto para que todos pudieran usarlos.

Esta serie de ejemplos puede continuar, pero solo queríamos demostrar que Red Hat realmente se esfuerza por desarrollar Kubernetes y mejorarlo para todos.

Claramente, OpenShift es Kubernetes. ¿Y cuáles son las diferencias? :)

Esperamos que después de leer hasta este punto, se haya dado cuenta de que Kubernetes es el componente principal de OpenShift. Básico, pero no el único. En otras palabras, simplemente instalando Kubernetes no obtendrá una plataforma de clase empresarial. Deberá agregar autenticación, red, seguridad, monitoreo, administración de registros y más. Además, tendrá que tomar una decisión difícil entre la gran cantidad de herramientas disponibles (para evaluar la diversidad del ecosistema, solo mire el diagrama CNCF) y de alguna manera aseguran coherencia y coherencia para que funcionen como un todo. Además, regularmente deberá realizar pruebas de actualización y regresión cuando se lance una nueva versión de cualquiera de los componentes utilizados. Es decir, además de crear y mantener la plataforma en sí, también tendrá que lidiar con todo este software. Es poco probable que quede mucho tiempo aquí para resolver problemas comerciales y lograr ventajas competitivas.

Pero en el caso de OpenShift, Red Hat toma todas estas dificultades sobre sí mismo y simplemente le brinda una plataforma funcionalmente completa, que incluye no solo a Kubernetes, sino también todo el conjunto de herramientas de código abierto necesarias que convierten a Kubernetes en una solución de clase empresarial real que puede Ejecución inmediata y completamente tranquila en producción. Y, por supuesto, si tiene alguna de sus pilas de tecnología, puede integrar OpenShift en sus soluciones existentes.

OpenShift es una plataforma inteligente de Kubernetes

Eche un vistazo a la imagen de arriba: todo lo que está fuera del rectángulo de Kubernetes es el área donde Red Hat agrega funcionalidades que Kubernetes no tiene, como dicen, por diseño. Y ahora consideraremos el principal de estas áreas.

1. Sistema operativo confiable como base: RHEL CoreOS o RHEL

Durante más de 20 años, Red Hat ha sido un proveedor líder de distribuciones de Linux para aplicaciones comerciales de misión crítica. La experiencia adquirida y constantemente actualizada en esta área nos permite ofrecer una base verdaderamente confiable para la operación industrial de contenedores. RHEL CoreOS utiliza el mismo núcleo que RHEL, pero está optimizado principalmente para tareas como ejecutar contenedores y trabajar en clústeres de Kubernetes: su tamaño reducido e inmutabilidad simplifica la instalación del clúster, el autoescalado, el despliegue de arreglos, etc. Todas estas funciones lo convierten en una base ideal para obtener la misma experiencia de usuario cuando se trabaja con OpenShift en una amplia variedad de entornos informáticos, desde el bare metal hasta las nubes privadas y públicas.

2. Automatización de las operaciones de TI.

La automatización de los procesos de instalación y las operaciones del segundo día (es decir, la operación diaria) es un caballo de batalla OpenShift que facilita enormemente la administración, actualización y mantenimiento de la plataforma de contenedores al más alto nivel. Esto se logra apoyando a los operadores de Kubernetes en el nivel central de OpenShift 4.

OpenShift 4 es también un ecosistema completo de soluciones basadas en operadores de Kubernetes desarrollados por Red Hat y socios externos (consulte el directorio de operadores de Red Hat o la tienda del operador operatorhub.io , creado por Red Hat para desarrolladores de terceros).

El directorio integrado de OpenShift 4 incluye más de 180 operadores de Kubernetes

3. Herramientas para desarrolladores

Desde 2011, OpenShift ha estado disponible como una plataforma PaaS (plataforma como servicio), que simplifica enormemente la vida de los desarrolladores, les ayuda a centrarse en la creación de código y ofrece soporte integrado para lenguajes de programación como Java, Node.js, PHP, Ruby, Python, Go, así como servicios de integración continua y entrega de CI / CD, bases de datos, etc. OpenShift 4 ofrece un extenso catálogo que incluye más de 100 servicios basados en operadores Kubernetes desarrollados por Red Hat y nuestros socios.

A diferencia de Kubernetes, OpenShift 4 tiene una interfaz gráfica especial ( Consola de desarrollador), que ayuda a los desarrolladores a implementar fácilmente aplicaciones en sus espacios de nombres de varias fuentes (git, registros externos, Dockerfile, etc.) y visualizar visualmente las conexiones entre los componentes de la aplicación.

Developer Console visualiza los componentes de la aplicación y simplifica el trabajo con Kubernetes.

Además, OpenShift ofrece un conjunto de herramientas de desarrollo de Codeready, que incluyen Codeready Workspaces , un IDE basado en web totalmente contenedorizado que se ejecuta directamente sobre OpenShift e implementa el enfoque tipo IDE 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 implementar en una computadora portátil.

“IDE como un servicio” integrado para el desarrollo eficiente de la plataforma Kubernetes / OpenShift.

Cabo la derecha de la caja, OpenShift ofrece un sistema completo CI / CD, ya sea basado en la Jenkins en contenedores y el DSL plug-in de tuberías, o la basada en CD Kubernetes CI / Tekton sistema (por ahora en la versión de vista previa de Tech). Ambas soluciones están completamente integradas con la consola OpenShift, lo que le permite ejecutar disparadores de canalización, ver implementaciones, registros, etc.

4. Herramientas para aplicaciones

OpenShift le permite implementar aplicaciones tradicionales con estado y soluciones basadas en la nube basadas en nuevas arquitecturas, como microservicios o sin servidor. La solución OpenShift Service Mesh de fábrica es clave para admitir herramientas de microservicio 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.

Una solución integrada de OpenShift ServiceMesh (Istio, Kiali, Jaeger) es útil al desarrollar microservicios.

Para reducir la brecha entre las aplicaciones y los contenedores heredados, OpenShift ahora le permite migrar máquinas virtuales a la plataforma OpenShift utilizando la Virtualización nativa de contenedores (mientras está en la versión en TechPreview), convirtiendo aplicaciones híbridas en realidad y facilitando su transferencia entre diferentes nubes, tanto privadas como públicas.

Máquina virtual virtual de Windows 2019 que se ejecuta en OpenShift a través de la virtualización nativa de contenedor (actualmente en versión de vista previa técnica)

5. Herramientas para clusters

Cualquier plataforma de clase empresarial debe tener servicios de monitoreo y registro centralizado, mecanismos de seguridad, autenticación y autorización, y herramientas de administración de red. Y OpenShift proporciona todo esto de forma inmediata, y todo esto es 100% de código abierto, incluidas soluciones como ElasticSearch, Prometheus, Grafana. Todas estas soluciones vienen completas con tableros, métricas y alertas que ya están configuradas y configuradas en base a la amplia experiencia de monitoreo de clúster de Red Hat, que le permite monitorear y rastrear de manera efectiva su entorno de producción desde los primeros minutos.

OpenShift también tiene cosas tan importantes para el cliente corporativo como la autenticación con el proveedor incorporado oauth, la integración con proveedores de credenciales, incluidos LDAP, ActiveDirectory, OpenID Connect y mucho más.

Panel de control de Grafana preconfigurado para monitorear un clúster OpenShift

Más de 150 métricas y alertas preconfiguradas de Prometheus para monitorear un clúster OpenShift

Continuará

La rica funcionalidad de la solución y la amplia experiencia de Red Hat en el campo de Kubernetes son precisamente por estas razones que OpenShift ha tomado una posición dominante en el mercado, como se muestra en la figura a continuación (más detalles aquí ).

“En la actualidad, Red Hat lidera el mercado con una participación del 44%.
La compañía está cosechando los beneficios de su estrategia de ventas con una participación activa en los asuntos de los clientes, en la que primero asesora y capacita a los desarrolladores corporativos, y luego pasa a la monetización a medida que la compañía comienza a introducir contenedores en la producción ".

(Fuente: www.lightreading.com/nfv/containers/ihs-red-hat-container-strategy-is-paying-off/d/d-id/753863 )

Esperamos que haya disfrutado este artículo. En las próximas publicaciones de esta serie, veremos más de cerca las ventajas de OpenShift en comparación con Kubernetes en cada una de las categorías discutidas aquí.

OpenShift como una versión empresarial de Kubernetes