🔱 🥄 ☑️ OpenShift en tant que version d'entreprise de Kubernetes 🐋 👼🏽 👆🏽

"Quelle est la différence entre Kubernetes et OpenShift?" - Cette question se pose avec une constance enviable. Bien qu'en réalité, c'est comme demander en quoi une voiture diffère d'un moteur. Si nous continuons l'analogie, alors une voiture est un produit fini, vous pouvez l'utiliser immédiatement, littéralement: vous vous êtes assis et vous êtes allé. D'autre part, pour que le moteur vous emmène quelque part, il doit d'abord être complété par une foule d'autres choses afin d'obtenir finalement la même voiture.

Par conséquent, Kubernetes est un tel moteur, autour duquel une automobile (plate-forme) de la marque OpenShift est assemblée, qui vous porte à l'objectif.

Dans cet article, nous voulons rappeler et analyser plus en détail les points clés suivants:

Kubernetes est au cœur de la plate-forme OpenShift et il est certifié 100% Kubernetes, entièrement open source et sans la moindre propriété. En bref:
- API OpenShift – Kubernetes.
- Kubernetes, - OpenShift. .
OpenShift Kubernetes . , OpenShift , , , . OpenShift . , PaaS- , . Container-as-a-Service .

OpenShift – Kubernetes 100% CNCF

OpenShift est basé sur Kubernetes Certified . Par conséquent, après une formation appropriée, les utilisateurs admirent la puissance de kubectl. Et ceux qui sont passés à OpenShift avec Kubernetes Cluster disent souvent à quel point ils aiment cela après avoir redirigé kubeconfig vers le cluster OpenShift, tous les scripts disponibles fonctionnent parfaitement.

Vous avez probablement entendu parler de l'utilitaire de ligne de commande OpenShift appelé OC. Il est entièrement compatible avec les commandes kubectl, plus il offre plusieurs helper'ov utiles qui sont utiles lors de l'exécution d'un certain nombre de tâches. Mais d'abord, un peu plus sur la compatibilité OC et kubectl:

Équipes Kubectl	Équipes OC
kubectl get pods	oc get pods
kubectl obtenir des espaces de noms	oc obtenir des espaces de noms
kubectl create -f deployment.yaml	oc create -f deployment.yaml

Voici à quoi ressemblent les résultats de l'utilisation de kubectl sur l'API OpenShift:

• kubectl get pods - il devrait renvoyer des pods.

• kubectl get namespaces - renvoie très probablement les espaces de noms.

La commande kubectl create -f mydeployment.yaml crée des ressources kubernetes comme sur toute autre plateforme Kubernetes, comme illustré dans la vidéo ci-dessous:

En d'autres termes, toutes les API de Kubernetes sont entièrement accessibles dans OpenShift avec une compatibilité à 100%. C'est pourquoi OpenShift est reconnu par la Cloud Native Computing Foundation (CNCF) comme une plate-forme Kubernetes certifiée .

OpenShift prend en charge Kubernetes avec des fonctionnalités utiles

Les API de Kubernetes sont disponibles à 100% dans OpenShift, mais l'utilitaire kubectl ordinaire de Kubernetes manque clairement de fonctionnalités et de commodité. Par conséquent, Red Hat a ajouté Kubernetes avec des fonctionnalités utiles et des outils de ligne de commande tels que OC (abréviation de OpenShift client) et ODO (OpenShift DO, cet utilitaire est conçu pour les développeurs).

1. L'utilitaire OC - une version plus puissante et pratique de Kubectl

Par exemple, contrairement à kubectl, il vous permet de créer de nouveaux espaces de noms et de changer facilement de contexte, et offre également un certain nombre de commandes utiles aux développeurs, par exemple, pour créer des images de conteneur et déployer des applications directement à partir du code source ou des fichiers binaires (source-à-image, s2i).

Examinons des exemples de la façon dont l'aide intégrée et les fonctionnalités avancées de l'utilitaire OC aident à simplifier le travail quotidien.

L'exemple un est la gestion des espaces de noms. Chaque cluster Kubernetes possède toujours plusieurs espaces de noms. Habituellement, ils sont utilisés pour créer des environnements de développement et de production, mais peuvent également être utilisés pour, par exemple, donner à chaque développeur un «bac à sable» personnel. En pratique, cela conduit au fait que le développeur doit souvent basculer entre les espaces de noms, car kubectl fonctionne dans le contexte de l'espace actuel. Par conséquent, dans le cas de kubectl, les gens utilisent activement des scripts d'assistance pour cela. Mais lorsque vous utilisez OC pour basculer vers l'espace souhaité, il suffit de dire «oc project namespace_».

Vous ne vous souvenez pas du nom de l'espace de noms? Pas de problème, tapez simplement «oc get projects» pour afficher une liste complète. Vous vous demandez sceptiquement comment cela fonctionnera si vous n'avez accès qu'à un sous-ensemble limité d'espaces de noms sur le cluster? Eh bien, car kubectl le fait correctement, uniquement si RBAC vous permet de voir tous les espaces sur le cluster, et dans les grands clusters, tout le monde ne donne pas une telle autorité. Donc, nous répondons: pour OC ce n'est pas un problème du tout et cela donnera facilement une liste complète dans une telle situation. C'est à partir de telles bagatelles que se concentrent la vision d'entreprise d'Openhift et la bonne évolutivité de cette plate-forme en termes d'utilisateurs et d'applications.

2. ODO - une version améliorée de kubectl pour les développeurs

Un autre exemple des améliorations de Red Hat OpenShift par rapport à Kubernetes est l'utilitaire de ligne de commande ODO. Il est destiné aux développeurs et vous permet de déployer rapidement du code local sur un cluster OpenShift distant. En outre, il peut être utilisé pour optimiser les processus internes afin de synchroniser instantanément toutes les modifications de code avec les conteneurs d'un cluster OpenShift distant sans avoir à réassembler, placer dans le registre et redéployer des images.

Voyons comment OC et ODO facilitent le conteneur et Kubernetes.

Il suffit de comparer quelques workflows lorsqu'ils sont construits sur la base de kubectl et lorsque OC ou ODO sont utilisés.

• Déploiement de code sur OpenShift pour ceux qui ne parlent pas le langage 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”

: « , -. ?»

Imaginez que vous êtes assis dans une voiture de course et ils disent: "Nous avons mis un nouveau type de freins ici et, franchement, ils ne sont pas encore corrects avec fiabilité ... Mais ne vous inquiétez pas, nous les affinerons activement au cours du championnat." Comment aimez-vous cette perspective? Chez Red Hat, nous ne sommes pas très en quelque sorte. :)

Par conséquent, nous essayons de nous abstenir des versions alpha jusqu'à ce qu'elles soient suffisamment mûres, et nous n'effectuons pas de tests de combat approfondis et estimons qu'elles peuvent être utilisées en toute sécurité. Habituellement, tout passe d'abord par l'étape Dev Preview, puis par Tech Preview, et ne sort ensuite que sous la forme d'une version publique General Availability (GA), qui est déjà suffisamment stable pour être adaptée à la production.

Pourquoi donc? Parce que, comme pour le développement de tout autre logiciel, toutes les idées initiales de Kubernetes n'atteignent pas la version finale. Ou bien ils atteignent et conservent même leurs fonctionnalités prévues, mais leur implémentation est fondamentalement différente de celle de la version alpha. Alors que des milliers et des milliers de clients Red Hat utilisent OpenShift pour prendre en charge des tâches critiques, nous accordons une importance particulière à la stabilité de notre plate-forme et au support à long terme.

Red Hat publie délibérément des versions d'OpenShift fréquentes et met à jour sa version de Kubernetes. Par exemple, au moment de la rédaction de cet article, la version GA d'OpenShift 4.3 inclut Kubernetes 1.16, qui n'est qu'une unité derrière la version en amont de Kubernetes avec le numéro 1.17. Ainsi, nous essayons de donner au client Kubernetes de classe entreprise et de fournir un contrôle de qualité supplémentaire dans le processus de publication de nouvelles versions d'OpenShift.

Correctifs logiciels: «Il y avait un trou dans cette version de Kubernetes que nous avons en production. Et vous ne pouvez le fermer qu'en mettant à jour trois versions. Ou y a-t-il des options? "

Dans le cadre du projet open source Kubernetes, les correctifs logiciels sont généralement publiés dans le cadre de la prochaine version, parfois ils couvrent une ou deux versions intermédiaires précédentes, ce qui donne une couverture il y a seulement 6 mois.

Red Hat est à juste titre fier de publier des correctifs critiques plus tôt que les autres et de fournir un support pour une période beaucoup plus longue. Prenons, par exemple, la vulnérabilité d'élévation de privilèges de Kubernetes ( CVE-2018-1002105 ): elle a été découverte dans Kubernetes 1.11 et les correctifs des versions précédentes ont été publiés uniquement vers la version 1.10.11, laissant ce trou dans toutes les versions précédentes de Kubernetes, à partir de 1 .x à 1.9.

À son tour, Red Hat a rapatrié OpenShift à la version 3.2(Kubernetes 1.2 est là), capturant neuf versions d'OpenShift et démontrant le service client (plus d'informations ici ).

Comment OpenShift et Red Hat font avancer Kubernetes

Red Hat se classe deuxième en termes de contributions logicielles à l'open source Kubernetes, deuxième derrière Google, avec 3 des 5 développeurs les plus prolifiques travaillant pour Red Hat. Autre fait méconnu: de nombreuses fonctions critiques sont apparues dans Kubernetes précisément à l'initiative de Red Hat, notamment:

RBAC. Kubernetes RBAC (ClusterRole, ClusterRoleBinding) , Red Hat , OpenShift. Red Hat Kubernetes? , Red Hat , Open Core. , , , , – .
Politiques de sécurité pour les pods (politiques de sécurité des pods). Initialement, ce concept d'exécution sécurisée des applications à l'intérieur des pods a été implémenté dans OpenShift sous le nom SCC (Security Context Constraints). Et comme dans l'exemple précédent, Red Hat a décidé d'introduire ces développements dans le projet open source Kubernetes afin que tout le monde puisse les utiliser.

Cette série d'exemples peut être poursuivie, mais nous voulions simplement montrer que Red Hat s'efforce vraiment de développer Kubernetes et de le rendre meilleur pour tout le monde.

De toute évidence, OpenShift est Kubernetes. Et quelles sont les différences? :)

Nous espérons qu'après avoir lu jusqu'à ce point, vous vous êtes rendu compte que Kubernetes est le composant principal d'OpenShift. Basique, mais pas le seul. En d'autres termes, rien qu'en installant Kubernetes, vous n'obtiendrez pas une plateforme de classe entreprise. Vous devrez ajouter l'authentification, le réseau, la sécurité, la surveillance, la gestion des journaux et plus encore. De plus, vous devrez faire un choix difficile parmi le grand nombre d'outils disponibles (pour évaluer la diversité de l'écosystème, il suffit de regarder le diagramme CNCF) et en quelque sorte assurer la cohérence et la cohérence afin qu'elles fonctionnent dans leur ensemble. De plus, vous devrez régulièrement effectuer des tests de mise à jour et de régression lorsqu'une nouvelle version de l'un des composants utilisés sera publiée. Autrement dit, en plus de créer et de maintenir la plate-forme elle-même, vous devrez également gérer tous ces logiciels. Il est peu probable qu'il reste beaucoup de temps ici pour résoudre les problèmes commerciaux et obtenir des avantages concurrentiels.

Mais dans le cas d'OpenShift, Red Hat prend toutes ces difficultés sur lui-même et vous donne simplement une plate-forme fonctionnellement complète, qui comprend non seulement Kubernetes lui-même, mais également l'ensemble des outils open source nécessaires qui font de Kubernetes une véritable solution de classe entreprise qui peut immédiatement et complètement calmement en production. Et bien sûr, si vous avez l'une de vos piles technologiques, vous pouvez intégrer OpenShift dans vos solutions existantes.

OpenShift est une plate-forme Kubernetes intelligente

Jetez un œil à l'image ci-dessus: tout ce qui se trouve en dehors du rectangle Kubernetes est la zone où Red Hat ajoute des fonctionnalités que Kubernetes n'a pas, ce qui est appelé par conception. Et maintenant, nous allons examiner les principaux de ces domaines.

1. Système d'exploitation fiable comme base: RHEL CoreOS ou RHEL

Depuis plus de 20 ans, Red Hat est l'un des principaux fournisseurs de distributions Linux pour les applications professionnelles critiques. L'expérience acquise et constamment mise à jour dans ce domaine nous permet d'offrir une base véritablement fiable et de confiance pour l'exploitation industrielle des conteneurs. RHEL CoreOS utilise le même noyau que RHEL, mais est principalement optimisé pour des tâches telles que l'exécution de conteneurs et le travail dans des clusters Kubernetes: sa taille réduite et son immuabilité simplifient l'installation du cluster, la mise à l'échelle automatique, le déploiement de correctifs, etc. Toutes ces fonctionnalités en font une base idéale pour obtenir la même expérience utilisateur lorsque vous travaillez avec OpenShift dans une grande variété d'environnements informatiques, du bare metal aux clouds privés et publics.

2. Automatisation des opérations informatiques

L'automatisation des processus d'installation et des opérations du deuxième jour (c'est-à-dire les opérations quotidiennes) est un cheval de bataille OpenShift qui facilite considérablement l'administration, la mise à jour et la maintenance de la plate-forme de conteneurs au plus haut niveau. Ceci est réalisé en soutenant les opérateurs Kubernetes au niveau central d'OpenShift 4.

OpenShift 4 est également tout un écosystème de solutions basées sur les opérateurs Kubernetes développées à la fois par Red Hat et des partenaires tiers (voir l' annuaire des opérateurs Red Hat ou le magasin de l'opérateur operatorhub.io , créé par Red Hat pour les développeurs tiers).

Le répertoire intégré d'OpenShift 4 comprend plus de 180 opérateurs Kubernetes

3. Outils de développement

Depuis 2011, OpenShift est disponible en tant que plate-forme PaaS (Platform-as-a-Service), ce qui simplifie considérablement la vie des développeurs, les aide à se concentrer sur la création de code et offre un support intégré pour les langages de programmation tels que Java, Node.js, PHP, Ruby, Python, Go, ainsi que des services d'intégration et de livraison continus CI / CD, des bases de données, etc. OpenShift 4 propose un catalogue complet qui comprend plus de 100 services basés sur les opérateurs Kubernetes développés par Red Hat et nos partenaires.

Contrairement à Kubernetes, OpenShift 4 possède une interface graphique spéciale ( Developer Console), qui aide les développeurs à déployer facilement des applications dans leurs espaces de noms à partir de diverses sources (git, registres externes, Dockerfile, etc.) et à visualiser visuellement les connexions entre les composants de l'application.

Developer Console visualise les composants d'application et simplifie l'utilisation de Kubernetes.

De plus, OpenShift propose un ensemble d'outils de développement Codeready, qui incluent Codeready Workspaces , un IDE Web entièrement conteneurisé qui s'exécute directement sur OpenShift et implémente l'approche de type IDE. un service". D'autre part, pour ceux qui veulent travailler strictement en mode local, il existe des conteneurs Codeready - une version entièrement fonctionnelle d'OpenShift 4 qui peut être déployée sur un ordinateur portable.

«IDE as a service» intégré pour un développement efficace sur la plate-forme Kubernetes / OpenShift.

Dès la sortie de la boîte, OpenShift propose un système CI / CD complet, basé soit sur le Jenkins conteneurisé et le plug-in DSL pour les pipelines, soit sur le système Tubton basé sur CI / CD Kubernetes (pour l'instant dans la version Tech preview). Ces deux solutions sont entièrement intégrées à la console OpenShift, vous permettant d'exécuter des déclencheurs de pipeline, d'afficher les déploiements, les journaux, etc.

4. Outils pour les applications

OpenShift vous permet de déployer à la fois des applications traditionnelles avec état et des solutions basées sur le cloud basées sur de nouvelles architectures, telles que des microservices ou sans serveur. La solution OpenShift Service Mesh prête à l'emploi est essentielle pour prendre en charge les outils de microservice comme Istio, Kiali et Jaeger. À son tour, la solution OpenShift Serverless comprend non seulement Knative, mais également des outils comme Keda, créés dans le cadre d'une initiative conjointe avec Microsoft, pour fournir des fonctions Azure sur la plate-forme OpenShift.

La solution OpenShift ServiceMesh intégrée (Istio, Kiali, Jaeger) est utile lors du développement de microservices.

Pour réduire l'écart entre les applications héritées et les conteneurs, OpenShift permet désormais de migrer les machines virtuelles vers la plate-forme OpenShift à l'aide de Container Native Virtualization (actuellement dans la version TechPreview), transformant les applications hybrides dans la réalité et facilitant leur transfert entre différents clouds, privés et publics.

Machine virtuelle virtuelle Windows 2019 s'exécutant sur OpenShift via la virtualisation native de conteneur (actuellement en version Tech preview)

5. Outils pour les clusters

Toute plate-forme de classe entreprise doit disposer de services de surveillance et de journalisation centralisée, de mécanismes de sécurité, d'authentification et d'autorisation et d'outils de gestion de réseau. Et OpenShift fournit tout cela hors de la boîte, et tout cela est 100% open source, y compris des solutions telles que ElasticSearch, Prometheus, Grafana. Toutes ces solutions sont livrées avec des tableaux de bord, des mesures et des alertes qui sont déjà configurés et configurés sur la base de la vaste expérience de surveillance de cluster de Red Hat, ce qui vous permet de surveiller et de suivre efficacement votre environnement de production dès les premières minutes.

OpenShift a également des choses importantes pour le client d'entreprise comme l'authentification avec le fournisseur oauth intégré, l'intégration avec les fournisseurs d'informations d'identification, y compris LDAP, ActiveDirectory, OpenID Connect, et bien plus encore.

Tableau de bord Grafana préconfiguré pour surveiller un cluster OpenShift

Plus de 150 mesures et alertes préconfigurées Prometheus pour la surveillance d'un cluster OpenShift

À suivre

La richesse des fonctionnalités de la solution et la vaste expérience de Red Hat dans le domaine de Kubernetes sont précisément pour ces raisons qu'OpenShift a pris une position dominante sur le marché, comme le montre la figure ci-dessous (plus de détails ici ).

«À l'heure actuelle, Red Hat est leader du marché avec une part de 44%.
La société récolte les fruits de sa stratégie de vente avec une participation active dans les affaires clients, dans lesquelles elle conseille et forme d'abord les développeurs d'entreprise, puis passe à la monétisation alors que la société commence à introduire des conteneurs en production. »

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

Nous espérons que vous avez apprécié cet article. Dans les prochains articles de cette série, nous examinerons de plus près les avantages d'OpenShift par rapport à Kubernetes dans chacune des catégories décrites ici.

OpenShift en tant que version d'entreprise de Kubernetes