« Quelle est la différence entre Kubernetes et OpenShift ? » – cette question se pose avec une cohérence enviable. Bien qu’en réalité, cela revient à se demander en quoi une voiture diffère d’un moteur. Si nous poursuivons l’analogie, alors une voiture est un produit fini, vous pouvez l’utiliser tout de suite, littéralement : montez et partez. En revanche, pour qu'un moteur vous emmène quelque part, il doit d'abord être complété par plein d'autres choses afin d'obtenir au final la même voiture.
Kubernetes est donc le moteur autour duquel est assemblée la voiture (plateforme) de la marque OpenShift, qui vous amène à votre objectif.
Dans cet article, nous souhaitons vous rappeler et examiner un peu plus en détail les points clés suivants :
- Kubernetes est le cœur de la plateforme OpenShift et c'est 100% certifié Kubernetes, totalement open source et sans le moindre caractère propriétaire. Brièvement:
- L'API du cluster OpenShift est XNUMX % Kubernetes.
- Si le conteneur s'exécute sur un autre système Kubernetes, il s'exécutera sur OpenShift sans aucune modification. Il n'est pas nécessaire d'apporter des modifications aux applications.
- OpenShift ajoute non seulement des fonctionnalités utiles à Kubernetes. Comme une voiture, OpenShift est prêt à l'emploi, peut être mis en production immédiatement et, comme nous le montrerons ci-dessous, facilite grandement la vie d'un développeur. C'est pourquoi OpenShift est réuni en deux personnes. Il s'agit d'une plate-forme PaaS d'entreprise à la fois réussie et bien connue du point de vue des développeurs. Et en même temps, il s’agit d’une solution Container-as-a-Service extrêmement fiable du point de vue de l’exploitation industrielle.
OpenShift c'est Kubernetes avec une certification 100% CNCF
OpenShift est basé sur . Par conséquent, après une formation appropriée, les utilisateurs sont émerveillés par la puissance de kubectl. Et ceux qui sont passés à OpenShift depuis le cluster Kubernetes disent souvent à quel point ils aiment vraiment qu'après avoir redirigé kubeconfig vers le cluster OpenShift, tous les scripts existants fonctionnent parfaitement.
Vous avez probablement entendu parler de l'utilitaire de ligne de commande d'OpenShift appelé OC. Il est entièrement compatible avec kubectl et offre plusieurs aides utiles qui seront utiles lors de l'exécution d'un certain nombre de tâches. Mais d’abord, un peu plus sur la compatibilité d’OC et kubectl :
commandes kubectl
Équipes du CO
kubectl obtenir des pods
oc prends des dosettes
kubectl récupère les espaces de noms
oc récupère les espaces de noms
kubectl créer -f déploiement.yaml
oc create -f déploiement.yaml
Voici à quoi ressemblent les résultats de l'utilisation de kubectl sur l'API OpenShift :
• kubectl get pods – renvoie les pods comme prévu.
• kubectl get namespaces – renvoie les espaces de noms comme prévu.
La commande kubectl create -f mydeployment.yaml crée des ressources Kubernetes comme sur n'importe quelle autre plateforme Kubernetes, comme le montre la vidéo ci-dessous :
En d’autres termes, toutes les API Kubernetes sont entièrement disponibles dans OpenShift tout en conservant une compatibilité à 100 %. C'est pourquoi .
OpenShift ajoute des fonctionnalités utiles à Kubernetes
Les API Kubernetes sont disponibles à 100 % dans OpenShift, mais l'utilitaire Kubernetes standard kubectl manque clairement de fonctionnalités et de commodité. C'est pourquoi Red Hat a ajouté des fonctionnalités utiles et des outils de ligne de commande à Kubernetes, tels que OC (abréviation de client OpenShift) et ODO (OpenShift DO, cet utilitaire est destiné aux développeurs).
1. Utilitaire OC - une version plus puissante et plus 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 propose également un certain nombre de commandes utiles pour les développeurs, telles que la création d'images de conteneurs et le déploiement d'applications directement à partir du code source ou des binaires (Source-to-image, s2i).
Examinons des exemples de la manière dont les assistants intégrés et les fonctionnalités avancées de l'utilitaire OC contribuent à simplifier le travail quotidien.
Le premier exemple est la gestion des espaces de noms. Chaque cluster Kubernetes dispose toujours de plusieurs espaces de noms. Ils sont généralement utilisés pour créer des environnements de développement et de production, mais peuvent également être utilisés, par exemple, pour fournir à chaque développeur un bac à sable personnel. En pratique, cela oblige le développeur à basculer fréquemment entre les espaces de noms, puisque kubectl s'exécute 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é, dites simplement « espace de noms du projet oc ».
Vous ne vous souvenez plus du nom de l'espace de noms dont vous avez besoin ? Pas de problème, tapez simplement « oc get project » pour afficher la liste complète. Vous êtes sceptique et vous vous demandez comment cela fonctionnera si vous n'avez accès qu'à un sous-ensemble limité d'espaces de noms sur le cluster ? Eh bien, parce que kubectl ne le fait correctement que si RBAC vous permet de voir tous les espaces du cluster, et dans les grands clusters, tout le monde ne dispose pas de telles autorisations. Alors, nous répondons : pour l'OC, ce n'est pas du tout un problème et il produira facilement une liste complète dans une telle situation. Ce sont ces petites choses qui font l’orientation corporate d’Openshift et la bonne évolutivité de cette plateforme en termes d’utilisateurs et d’applications.
2. ODO - une version améliorée de kubectl pour les développeurs
Un autre exemple d'améliorations de Red Hat OpenShift par rapport à Kubernetes est l'utilitaire de ligne de commande ODO. Il est conçu pour les développeurs et vous permet de déployer rapidement du code local sur un cluster OpenShift distant. Il peut également rationaliser les processus internes pour synchroniser instantanément toutes les modifications de code avec les conteneurs sur un cluster OpenShift distant sans avoir à reconstruire, enregistrer et redéployer les images.
Voyons comment OC et ODO facilitent le travail avec les conteneurs et Kubernetes.
Comparez simplement quelques workflows lorsqu'ils sont construits sur la base de kubectl et lorsqu'ils sont utilisés OC ou ODO.
• Déploiement de code sur OpenShift pour ceux qui ne parlent pas YAML :
Kubernetes/kubectl
$>clone git
1- Créez un Dockerfile qui construit l'image à partir du code
-----
DE nœud
RÉP TRAVAIL /usr/src/app
COPIER le paquet*.json ./
COPIER index.js ./
COPIER ./app ./app
Exécutez l'installation de npm
EXPOSER 3000
CMD [ "npm", "démarrer" ] ————–
2- On construit l'image
$>Construction Podman...
3- Connectez-vous au registre
Connexion Podman...
4- Placez l'image dans le registre
Poussée Podman
5- Créez des fichiers yaml pour le déploiement de l'application (deployment.yaml, service.yaml, ingress.yaml) - c'est le minimum absolu
6- Déployer les fichiers manifestes :
Kubectl applique -f .
OpenShift/oc
$> oc nouvelle application – notre_nom_application
OuvrirShift/odo
$>clone git
$> odo crée un composant nodejs myapp
$>odo pousser
• Changement de contexte : modifiez l'espace de noms de travail ou le cluster de travail.
Kubernetes/kubectl
1- Créer un contexte dans kubeconfig pour le projet « myproject »
2- Kubectl définir le contexte…
OpenShift/oc
projet oc « mon projet »
Contrôle qualité : « Une fonctionnalité intéressante est apparue ici, toujours en version alpha. Peut-être pouvons-nous le mettre en production ?
Imaginez-vous être assis dans une voiture de course et se faire dire : « Nous avons installé un nouveau type de freins et, pour être honnête, leur fiabilité n'est pas encore au rendez-vous... Mais ne vous inquiétez pas, nous les améliorerons activement au cours du parcours. du championnat. Comment aimez-vous cette perspective ? Chez Red Hat, nous ne sommes pas très satisfaits. 🙂
Par conséquent, nous essayons d’attendre les versions alpha jusqu’à ce qu’elles soient suffisamment matures et que nous ayons effectué des tests de combat approfondis et estimons qu’elles sont sûres à utiliser. Habituellement, tout passe d'abord par l'étape Dev Preview, puis par et ce n'est qu'alors qu'il sort sous forme de version publique (GA), qui est déjà si stable qu’il convient à 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 y parviennent et conservent même les fonctionnalités prévues, mais leur implémentation est radicalement différente de celle de la version alpha. Avec des milliers et des milliers de clients Red Hat utilisant OpenShift pour prendre en charge des charges de travail critiques, nous accordons une importance particulière à la stabilité de notre plateforme et à son support à long terme.
Red Hat s'engage à publier fréquemment OpenShift et à mettre à jour la version de Kubernetes qui l'accompagne. Par exemple, la version GA actuelle d'OpenShift 4.3 au moment d'écrire ces lignes inclut Kubernetes 1.16, qui n'est qu'une unité derrière la version amont de Kubernetes numérotée 1.17. Ainsi, nous essayons de fournir au client Kubernetes de classe entreprise et de fournir un contrôle qualité supplémentaire à mesure que nous publions de nouvelles versions d'OpenShift.
Correctifs logiciels : « Il y avait un trou dans la 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 projet open source Kubernetes, les correctifs logiciels sont généralement publiés dans le cadre de la version suivante, couvrant parfois une ou deux versions jalons précédentes, offrant une couverture sur une période aussi courte que 6 mois.
Red Hat est fier de publier les correctifs critiques plus tôt que les autres et de fournir une assistance beaucoup plus longtemps. Prenons par exemple la vulnérabilité d'élévation de privilèges de Kubernetes () : il a été découvert dans Kubernetes 1.11, et les correctifs des versions précédentes n'ont été publiés que jusqu'à la version 1.10.11, laissant celui-ci dans le trou dans toutes les versions précédentes de Kubernetes, de 1.x à 1.9.
À son tour, (Kubernetes 1.2 est là), capturant neuf versions d'OpenShift et démontrant clairement l'attention portée aux clients (plus de détails ).
Comment OpenShift et Red Hat font avancer Kubernetes
Red Hat est le deuxième plus grand contributeur logiciel au projet open source Kubernetes, derrière Google, avec 3 des 5 développeurs les plus prolifiques provenant de Red Hat. Autre fait peu connu : de nombreuses fonctions critiques sont apparues dans Kubernetes précisément à l'initiative de Red Hat, notamment :
- RBAC. Kubernetes ne disposait pas de fonctions RBAC (ClusterRole, ClusterRoleBinding) jusqu'à ce que les ingénieurs de Red Hat décident de les implémenter dans le cadre de la plate-forme elle-même, et non en tant que fonctionnalité OpenShift supplémentaire. Red Hat a-t-il peur d’améliorer Kubernetes ? Bien sûr que non, car Red Hat suit strictement les principes de l'open source et ne joue pas aux jeux Open Core. Les améliorations et les innovations portées par les communautés de développement, plutôt que par les communautés propriétaires, sont plus viables et plus largement adoptées, ce qui correspond bien à notre objectif principal : rendre les logiciels open source plus utiles à nos clients.
- Politiques de sécurité pour les pods (Politiques de sécurité des pods). Ce concept d'exécution sécurisée d'applications à l'intérieur de pods a été initialement implémenté dans OpenShift sous le nom de 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 ouvert Kubernetes afin que tout le monde puisse les utiliser.
Cette série d'exemples pourrait être poursuivie, mais nous voulions simplement montrer que Red Hat s'engage réellement à développer Kubernetes et à le rendre meilleur pour tout le monde.
Il est clair qu’OpenShift est Kubernetes. Quelles sont les différences? 🙂
Nous espérons qu'en lisant jusqu'ici, vous avez réalisé que Kubernetes est le composant central d'OpenShift. Le principal, mais loin d’être le seul. En d’autres termes, la simple installation de Kubernetes ne vous donnera pas une plateforme de classe entreprise. Vous devrez ajouter l'authentification, la mise en réseau, la sécurité, la surveillance, la gestion des journaux, etc. De plus, vous devrez faire des choix difficiles parmi le grand nombre d'outils disponibles (pour apprécier la diversité de l'écosystème, il suffit de jeter un oeil ) et assurer d'une manière ou d'une autre la cohérence et la cohérence afin qu'ils fonctionnent comme un seul. De plus, vous devrez régulièrement effectuer des mises à jour et des tests de régression chaque fois qu'une nouvelle version de l'un des composants que vous utilisez est 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 pour résoudre les problèmes commerciaux et obtenir des avantages concurrentiels.
Mais dans le cas d'OpenShift, Red Hat prend toutes ces complexités sur lui et vous offre 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 transforment Kubernetes en une véritable classe d'entreprise. solution que vous pouvez lancer immédiatement et en toute sérénité en production. Et bien sûr, si vous disposez de certaines de vos propres piles technologiques, vous pouvez intégrer OpenShift dans les solutions existantes.
Jetez un œil à l'image ci-dessus : tout ce qui se trouve en dehors du rectangle de Kubernetes est l'endroit où Red Hat ajoute des fonctionnalités que Kubernetes n'a pas, comme on dit, de par sa conception. Et maintenant, nous allons examiner les principaux de ces domaines.
1. OS robuste comme base : RHEL CoreOS ou RHEL
Red Hat est l'un des principaux fournisseurs de distributions Linux pour les applications critiques pour les entreprises depuis plus de 20 ans. Notre expérience accumulée et constamment mise à jour dans ce domaine nous permet d'offrir une base véritablement fiable et fiable pour l'exploitation industrielle des conteneurs. RHEL CoreOS utilise le même noyau que RHEL, mais est optimisé principalement pour des tâches telles que l'exécution de conteneurs et l'exécution de clusters Kubernetes : sa taille réduite et son immuabilité facilitent la configuration des clusters, la mise à l'échelle automatique, le déploiement de correctifs, etc. une base idéale pour offrir la même expérience utilisateur avec OpenShift dans un large éventail d'environnements informatiques, du bare metal au cloud privé et public.
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 le point fort d'OpenShift, ce qui facilite grandement l'administration, la mise à jour et le maintien des performances de la plate-forme de conteneurs au plus haut niveau. Ceci est réalisé grâce à la prise en charge des opérateurs Kubernetes au niveau du noyau OpenShift 4.
OpenShift 4, c'est aussi tout un écosystème de solutions basées sur les opérateurs Kubernetes, développées à la fois par Red Hat lui-même et par des partenaires tiers (voir. Red Hat ou magasin d'opérateur , créé par Red Hat pour les développeurs tiers).
Le catalogue intégré OpenShift 4 comprend plus de 180 opérateurs Kubernetes
3. Outils de développement
Depuis 2011, OpenShift est disponible en tant que plateforme PaaS (Platform-as-a-Service) qui facilite grandement la vie des développeurs, les aide à se concentrer sur le codage et offre un support natif pour les langages de programmation tels que Java, Node.js. , PHP, Ruby, Python, Go, ainsi que des services d'intégration et de livraison continue CI/CD, des bases de données, etc. Offres OpenShift 4 , 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 dispose d'une interface graphique dédiée (), qui aide les développeurs à déployer sans effort des applications provenant de diverses sources (git, registres externes, Dockerfile, etc.) dans leurs espaces de noms et visualise clairement les relations entre les composants de l'application.
De plus, OpenShift propose un ensemble d'outils de développement Codeready, qui comprend notamment , un IDE entièrement conteneurisé avec une interface Web qui s'exécute directement sur OpenShift et implémente une approche IDE en tant que service. D'autre part, pour ceux qui souhaitent travailler strictement en mode local, il existe Codeready Containers, une version entièrement fonctionnelle d'OpenShift 4 pouvant être déployée sur un ordinateur portable.
IDE intégré en tant que service pour un développement efficace sur la plateforme Kubernetes/OpenShift
OpenShift propose un système CI/CD complet prêt à l'emploi, soit basé sur Jenkins conteneurisé et un plugin pour travailler avec des pipelines ou un système CI/CD orienté Kubernetes (actuellement en version Tech Preview). Ces deux solutions s'intègrent entièrement à la console OpenShift, vous permettant d'exécuter des déclencheurs de pipeline, d'afficher les déploiements, les journaux, etc.
4. Outils de candidature
OpenShift vous permet de déployer à la fois des applications avec état traditionnelles et des solutions basées sur le cloud basées sur de nouvelles architectures, telles que les microservices ou le sans serveur. La solution OpenShift Service Mesh est livrée immédiatement avec des outils clés pour la maintenance des microservices, tels qu'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 plateforme OpenShift.
La solution intégrée OpenShift ServiceMesh (Istio, Kiali, Jaeger) sera utile lors du développement de microservices
Pour combler le fossé entre les applications existantes et les conteneurs, OpenShift permet désormais la migration de machines virtuelles vers la plateforme OpenShift à l'aide de Container Native Virtualization (actuellement dans TechPreview), faisant des applications hybrides une réalité et facilitant leur migration entre différents cloud, privés et publics.
Machine virtuelle virtuelle Windows 2019 exécutée sur OpenShift via Container Native Virtualization (actuellement en version Tech Preview)
5. Outils pour les clusters
Toute plate-forme d'entreprise doit disposer de services de surveillance et de journalisation centralisés, de mécanismes de sécurité, d'authentification et d'autorisation, ainsi que d'outils de gestion de réseau. Et OpenShift fournit tout cela immédiatement, et tout est 100 % open source, y compris des solutions telles que ElasticSearch, Prometheus, Grafana. Toutes ces solutions sont accompagnées de tableaux de bord, de métriques et d'alertes déjà créés et configurés à l'aide de l'expertise approfondie de Red Hat en matière de surveillance de clusters, vous permettant de contrôler et de surveiller efficacement votre environnement de production dès le départ.
OpenShift est également livré en standard avec des éléments aussi importants pour les entreprises clientes que l'authentification avec un fournisseur oauth intégré, l'intégration avec des fournisseurs d'informations d'identification, notamment LDAP, ActiveDirectory, OpenID Connect, et bien plus encore.
Tableau de bord Grafana préconfiguré pour la surveillance du cluster OpenShift
Plus de 150 métriques et alertes Prometheus préconfigurées pour la surveillance du cluster OpenShift
se poursuivre
La richesse fonctionnelle de la solution et la vaste expérience de Red Hat dans le domaine de Kubernetes sont les raisons pour lesquelles OpenShift a atteint une position dominante sur le marché, comme le montre la figure ci-dessous (en savoir plus ).
« Red Hat est actuellement leader du marché avec une part de 44 %.
L'entreprise récolte les bénéfices de sa stratégie de vente centrée sur le client, dans laquelle elle consulte et forme d'abord les développeurs d'entreprise, puis passe à la monétisation à mesure que l'entreprise commence à déployer des conteneurs en production.
(Source: )
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 abordées ici.
Source: habr.com