«Quelle est la différence entre Kubernetes et OpenShift ?» – cette question revient avec une étonnante régularité. En réalité, c'est comme demander en quoi une voiture se distingue d'un moteur. Pour poursuivre l'analogie, la voiture est un produit prêt à l'emploi, que l'on peut utiliser immédiatement : il suffit de s'installer et de démarrer. En revanche, pour qu'un moteur vous emmène quelque part, il doit d'abord être complété par une multitude d'autres éléments pour obtenir cette même voiture.
C'est pourquoi Kubernetes est le moteur autour duquel est assemblée la voiture (plateforme) de marque OpenShift, qui vous conduit vers votre destination.
Dans cet article, nous souhaitons rappeler et examiner plus en détail les points clés suivants :
- Kubernetes est le cœur de la plateforme OpenShift. Et c'est un Kubernetes 100% certifié, avec un code entièrement ouvert et sans aucune part de propriété exclusive. En résumé :
- L'API pour le cluster OpenShift est un Kubernetes à 100%.
- Si un conteneur fonctionne dans n'importe quel autre système Kubernetes, il fonctionnera sans aucun changement sur OpenShift. Aucune modification des applications n'est nécessaire.
- OpenShift ne se contente pas de compléter Kubernetes avec des fonctionnalités et des capacités utiles. Tout comme une voiture, OpenShift est immédiatement prêt à l'emploi, pouvant être lancé en production immédiatement et, comme nous allons le montrer ci-dessous, il simplifie considérablement la vie des développeurs. C'est pourquoi OpenShift est unique sous deux aspects. C'est à la fois une plateforme PaaS de classe entreprise, reconnue et réussie, vu du point de vue des développeurs. Et en même temps, c'est une solution extrêmement fiable de type Container-as-a-Service en termes d'exploitation industrielle.
OpenShift est un Kubernetes avec une certification 100% de la CNCF.
À la base d'OpenShift, il y a . Ainsi, après la formation adéquate, les utilisateurs sont fascinés par la puissance de kubectl. Ceux qui sont passés d'un Cluster Kubernetes à OpenShift disent souvent à quel point ils apprécient le fait qu'après avoir redirigé kubeconfig vers le cluster OpenShift, tous leurs scripts existants fonctionnent à la perfection.
Vous avez sûrement entendu parler de l'outil en ligne de commande d'OpenShift appelé OC. Il est entièrement compatible en termes de commandes avec kubectl, de plus, il offre plusieurs assistants pratiques utiles pour effectuer une gamme de tâches. Mais d'abord, un peu plus sur la compatibilité entre OC et kubectl :
Commandes kubectl
Commandes OC
kubectl get pods
oc get pods
kubectl get namespaces
oc get namespaces
kubectl create -f deployment.yaml
oc create -f deployment.yaml
Voici à quoi ressemble les résultats de l'utilisation de kubectl sur l'API OpenShift :
• kubectl get pods – renvoie des pods comme on peut s'y attendre.
• kubectl get namespaces – renvoie des espaces de noms comme on peut s'y attendre.
La commande kubectl create -f mydeployment.yaml crée des ressources Kubernetes exactement 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 accessibles dans OpenShift avec 100 % de compatibilité. C'est pourquoi .
OpenShift complète Kubernetes avec des fonctionnalités utiles
Les API Kubernetes sont 100 % accessibles dans OpenShift, mais il manque clairement de fonctionnalités et de convivialité à l'outil kubectl standard de Kubernetes. C'est pourquoi Red Hat a ajouté des fonctionnalités et des outils en ligne de commande utiles à Kubernetes, tels que OC (abréviation de OpenShift client) et ODO (OpenShift DO, cet outil est destiné aux développeurs).
1. L'outil OC est une version plus puissante et conviviale de Kubectl
Par exemple, contrairement à kubectl, il permet de créer de nouveaux espaces de noms et de changer facilement de contexte, tout en offrant un certain nombre de commandes utiles pour les développeurs, notamment pour construire des images de conteneurs et déployer des applications directement à partir de code source ou de fichiers binaires (Source-to-image, s2i).
Voyons à travers des exemples comment les helpers intégrés et la fonctionnalité étendue de l'outil OC facilitent le travail quotidien.
Premier exemple – gestion des espaces de noms. Dans chaque cluster Kubernetes, il y a toujours 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 pour, par exemple, donner à chaque développeur un « bac à sable » personnel. En pratique, cela conduit à ce que le développeur doive souvent changer d'espace 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'aide à cet effet. En utilisant OC, pour changer d'espace, il suffit de dire "oc project espace_nom".
Vous ne vous souvenez pas du nom de l'espace de noms requis ? Pas de problème, il suffit de taper “oc get projects” pour afficher la 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 dans le cluster ? Eh bien, parce que kubectl le fait correctement uniquement si RBAC vous permet de voir tous les espaces dans le cluster, et dans les grands clusters, de tels privilèges ne sont pas accordés à tout le monde. Donc, la réponse est : pour OC, ce n’est absolument pas un problème et il fournira facilement une liste complète dans cette situation. C'est ce genre de détails qui montre l'orientation d'OpenShift vers l'entreprise et la bonne évolutivité de cette plateforme en ce qui concerne les utilisateurs et les 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'outil de ligne de commande ODO. Il est destiné aux développeurs et permet de déployer rapidement du code local sur un cluster OpenShift distant. En outre, il optimise les processus internes pour synchroniser instantanément toutes les modifications de code avec les conteneurs sur le cluster OpenShift sans avoir à reconstruire, à publier dans le registre et à redéployer les images.
Voyons comment OC et ODO facilitent le travail avec des conteneurs et Kubernetes.
Comparons simplement quelques flux de travail lorsqu'ils sont basés sur kubectl et lorsqu'OC ou ODO sont appliqués.
• Déploiement de code sur OpenShift pour ceux qui ne maîtrisent pas le langage YAML :
Kubernetes / kubectl
$> git clone
1- Créons un Dockerfile qui construit l'image à partir du code
————–
FROM node
WORKDIR /usr/src/app
COPY package*.json ./
COPY index.js ./
COPY ./app ./app
RUN npm install
EXPOSE 3000
CMD [ "npm", "start" ]
————–
2- Construisons l'image
$> podman build …
3- Connectons-nous au registre
podman login …
4- Publions l'image dans le registre
podman push
5- Créons des fichiers yaml pour le déploiement de l'application (deployment.yaml, service.yaml, ingress.yaml) – c'est le minimum absolu
6- Déployons les fichiers manifestes :
kubectl apply -f .
OpenShift / oc
$> oc new-app – nom_de_notre_application
OpenShift / odo
$> git clone
$> odo create component nodejs myapp
$> odo push
• Changement de contexte : changement d'espace de travail ou de cluster actif.
Kubernetes / kubectl
1- Créons un contexte dans kubeconfig pour le projet "myproject"
2- kubectl set-context …
OpenShift / oc
oc project "myproject"
Contrôle qualité : « Une fonction intéressante est récemment apparue, encore en version alpha. Peut-être que nous l'introduirons en production ? »
Imaginez que l'on vous installe dans une voiture de course et qu'on vous dit : « Nous avons installé de nouveaux freins et, pour être honnête, leur fiabilité n'est pas encore optimale… Mais ne vous inquiétez pas, nous allons les améliorer durant le championnat. » Comment trouvez-vous cette perspective ? Pour nous chez Red Hat, c'est un peu inquiétant. 🙂
C'est pourquoi nous évitons de déployer des versions alpha tant qu'elles ne sont pas suffisamment mûres, que nous n'avons pas effectué de tests rigoureux et que nous n'avons pas l'assurance qu'elles peuvent être utilisées en toute sécurité. En général, tout passe d'abord par une phase Dev Preview, puis par avant d'être enfin publié en tant que version publique (GA), qui est suffisamment stable pour être mis en production.
Pourquoi cela ? Parce que, comme pour le développement de tout autre logiciel, toutes les idées initiales dans Kubernetes n'atteignent pas la version finale. Ou elles y parviennent, et conservent même la fonctionnalité prévue, mais leur réalisation diffère radicalement de celle de la version alpha. Étant donné que des milliers et des milliers de clients de Red Hat utilisent OpenShift pour des tâches critiques, nous mettons un accent particulier sur la stabilité de notre plateforme et son soutien à long terme.
Red Hat s'efforce de publier régulièrement des mises à jour d'OpenShift et de mettre à jour la version de Kubernetes intégrée. Par exemple, à la date de rédaction de cet article, la version GA d'OpenShift 4.3 intègre Kubernetes 1.16, qui est seulement une version derrière la version upstream de Kubernetes numérotée 1.17. Ainsi, nous essayons d'offrir au client Kubernetes de classe entreprise et d'assurer un contrôle qualité supplémentaire lors de la sortie de nouvelles versions d'OpenShift.
Corrections logicielles : « Dans la version de Kubernetes que nous avons en production, il y a une faille. Et elle ne peut être corrigée qu'en mettant à jour de trois versions. Y a-t-il d'autres options ? »
Dans le cadre du projet open-source Kubernetes, les corrections logicielles sont généralement incluses dans la prochaine version, et parfois elles couvrent une ou deux versions intermédiaires précédentes, ce qui permet une couverture remontant à six mois.
Red Hat est fier de publier des corrections critiques plus rapidement que les autres et d'offrir un support pendant une période beaucoup plus longue. Prenons par exemple la vulnérabilité d'escalade de privilèges dans Kubernetes (): elle a été découverte dans Kubernetes 1.11, et les corrections pour les versions précédentes n'ont été publiées que jusqu'à la version 1.10.11, laissant une faille dans toutes les versions antérieures de Kubernetes, de 1.x à 1.9.
De son côté, (où Kubernetes 1.2 est utilisé), touchant neuf versions d'OpenShift et démontrant clairement son engagement envers ses clients (voir plus ).
Comment OpenShift et Red Hat font avancer Kubernetes
Red Hat est le deuxième plus grand contributeur en termes de code au projet open source Kubernetes, juste derrière Google, avec 3 des 5 développeurs les plus prolifiques étant employés par Red Hat. Un autre fait peu connu : de nombreuses fonctionnalités critiques ont été introduites dans Kubernetes grâce à l'initiative de Red Hat, notamment :
- RBAC. Kubernetes ne disposait pas de fonctionnalités RBAC (ClusterRole, ClusterRoleBinding) jusqu'à ce que les ingénieurs de Red Hat décident de les intégrer directement dans la plateforme, plutôt que comme une fonctionnalité additionnelle d'OpenShift. Red Hat craint-elle d'améliorer Kubernetes ? Bien sûr que non, car Red Hat suit strictement les principes du code ouvert et ne joue pas à des jeux de type Open Core. Les améliorations et innovations mises en œuvre au niveau des communautés de développement, et non de manière propriétaire, deviennent plus viables et obtiennent une plus large diffusion, ce qui s'aligne parfaitement avec notre objectif principal : rendre le logiciel open source plus utile pour nos clients.
- Politiques de sécurité pour les pods (Pod Security Policies). À l'origine, ce concept d'exécution sécurisée des applications à l'intérieur des pods avait été mis en œuvre dans OpenShift sous le nom de SCC (Security Context Constraints). Et comme dans l'exemple précédent, Red Hat a décidé d'intégrer ces travaux dans le cadre du projet open source Kubernetes, afin que tous ceux qui le souhaitent puissent en bénéficier.
Cette liste d'exemples pourrait se poursuivre, mais nous voulions seulement montrer que Red Hat s'efforce réellement de développer Kubernetes et de l'améliorer pour tous.
Il est clair qu'OpenShift est Kubernetes. Mais quelles en sont les différences ? 🙂
Nous espérons qu'une fois arrivé ici, vous avez compris que Kubernetes est le composant principal d'OpenShift. Principal, mais pas unique. Autrement dit, simplement en installant Kubernetes, vous n'obtiendrez pas une plateforme d'entreprise. Vous devrez ajouter l'authentification, le réseau, la sécurité, la surveillance, la gestion des journaux et bien plus encore. De plus, il sera nécessaire de faire un choix difficile parmi une multitude d'outils disponibles (pour évaluer la diversité de l'écosystème, jetez simplement un coup d'œil à la ) et de veiller à la cohérence et à la synergie pour qu'ils fonctionnent comme un tout. Par ailleurs, vous devrez régulièrement mettre à jour et effectuer des tests de régression à chaque nouvelle version de l'un des composants utilisés. En d'autres termes, en plus de créer et de maintenir la plateforme elle-même, vous devrez également gérer tout ce logiciel. Il est peu probable qu'il vous reste beaucoup de temps pour résoudre des problèmes d'affaires et atteindre des avantages concurrentiels.
En revanche, avec OpenShift, Red Hat prend tous ces défis en charge et vous fournit simplement une plateforme fonctionnellement complète, qui inclut non seulement Kubernetes, mais également l'ensemble des outils nécessaires en open source, transformant Kubernetes en une véritable solution d'entreprise, prête à être déployée immédiatement et sereinement en production. Bien sûr, si vous avez vos propres piles technologiques, vous pouvez intégrer OpenShift dans vos solutions existantes.
Regardez l'image ci-dessus : tout ce qui se trouve en dehors du rectangle Kubernetes représente les domaines où Red Hat ajoute des fonctionnalités qui ne sont pas présentes dans Kubernetes, ce que l'on appelle, par conception. Nous allons maintenant examiner les principaux de ces domaines.
1. Un système d'exploitation fiable en tant que base : RHEL CoreOS ou RHEL
Red Hat est depuis plus de 20 ans un fournisseur majeur de distributions Linux pour des applications professionnelles critiques. L'expérience accumulée et régulièrement mise à jour dans ce domaine nous permet d'offrir une base véritablement fiable et digne de confiance pour l'exploitation industrielle des conteneurs. RHEL CoreOS utilise le même noyau que RHEL, mais est avant tout optimisé pour des tâches telles que l'exécution de conteneurs et le fonctionnement dans des clusters Kubernetes : sa taille réduite et son immutabilité simplifient l'installation de clusters, le dimensionnement 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 lors de l'utilisation d'OpenShift dans divers environnements de calcul, allant du matériel nu au cloud privé et public.
2. Automatisation des opérations IT
L'automatisation des processus d'installation et des opérations du deuxième jour (c'est-à-dire l'exploitation quotidienne) est le point fort d'OpenShift, facilitant considérablement l'administration, la mise à jour et le maintien des performances de la plateforme de conteneurs à un niveau élevé. Cela est rendu possible grâce à la prise en charge des opérateurs Kubernetes au niveau du noyau d'OpenShift 4.
OpenShift 4 est également tout un écosystème de solutions basées sur des opérateurs Kubernetes, développées tant par Red Hat que par des partenaires tiers (voir Red Hat, ou magasin d'opérateurs , créé par Red Hat pour les développeurs tiers).
Le catalogue intégré d'OpenShift 4 comprend plus de 180 opérateurs Kubernetes
3. Outils pour développeurs
Depuis 2011, OpenShift est disponible en tant que plateforme PaaS (Platform-as-a-Service), ce qui facilite considérablement la vie des développeurs, les aide à se concentrer sur la création de code et propose un support intégré pour des 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. OpenShift 4 propose , comprenant plus de 100 services basés sur des opérateurs Kubernetes, développés par Red Hat et nos partenaires.
Contrairement à Kubernetes, OpenShift 4 dispose d'une interface graphique spécifique (), aidant les développeurs à déployer facilement des applications à partir de diverses sources (git, registres externes, Dockerfile, etc.) et visualisant clairement les relations entre les composants de l'application.
De plus, OpenShift propose un ensemble d'outils de développement Codeready, qui comprend notamment , une IDE entièrement conteneurisée avec une interface web, fonctionnant directement sur OpenShift et réalisant l'approche « IDE en tant que service ». D'autre part, pour ceux qui souhaitent travailler strictement en mode local, il existe Codeready Containers – une version complète d'OpenShift 4 que l'on peut déployer sur un ordinateur portable.
IDE intégrée « en tant que service » pour un développement efficace sur la plateforme Kubernetes/OpenShift.
Out of the box, OpenShift propose un système CI/CD complet, soit basé sur Jenkins conteneurisé et un plugin pour le travail avec des pipelines, soit un système CI/CD orienté Kubernetes. (actuellement en version Tech preview). Ces deux solutions s'intègrent entièrement à la console OpenShift, permettant de déclencher des pipelines, de visualiser des déploiements, des journaux, etc.
4. Outils pour les applications
OpenShift permet de déployer à la fois des applications traditionnelles stateful et des solutions cloud-native basées sur de nouvelles architectures, telles que les microservices ou le serverless. La solution OpenShift Service Mesh fournit directement des outils clés pour la gestion des microservices, tels qu'Istio, Kiali et Jaeger. D'autre part, la solution OpenShift Serverless comprend non seulement Knative, mais également des outils créés dans le cadre d'une initiative conjointe avec Microsoft, comme Keda, pour offrir des fonctionnalités Azure sur la plateforme OpenShift.
La solution intégrée OpenShift ServiceMesh (Istio, Kiali, Jaeger) sera 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 des machines virtuelles vers la plateforme OpenShift grâce à la Container Native Virtualization (actuellement en version Tech Preview), transformant ainsi les applications hybrides en réalité et facilitant leur migration entre divers environnements cloud, tant privés que publics.
La machine virtuelle Windows 2019 Virtual, exécutée sur OpenShift grâce à Container Native Virtualization (actuellement en version Tech preview).
5. Outils pour les clusters
Toute plateforme d'entreprise doit disposer de services de surveillance et de journalisation centralisée, de mécanismes de sécurité, d'authentification et d'autorisation, ainsi que d'outils de gestion réseau. OpenShift fournit tout cela dès le départ, et tout cela est en code source ouvert à 100 %, y compris des solutions telles qu'ElasticSearch, Prometheus, Grafana. Toutes ces solutions sont fournies avec des tableaux de bord, des métriques et des alertes qui sont déjà configurés en fonction de l'expérience approfondie de Red Hat dans le domaine de la surveillance des clusters, permettant ainsi de contrôler et de surveiller efficacement le fonctionnement de votre environnement de production dès les premières minutes.
OpenShift comprend également des éléments essentiels pour les clients d'entreprise, tels que l'authentification avec un fournisseur oauth intégré, l'intégration avec des fournisseurs d'identité, y compris LDAP, ActiveDirectory, OpenID Connect, et bien d'autres.
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
La suite à suivre
La richesse fonctionnelle de la solution et l'expérience approfondie de Red Hat dans Kubernetes sont précisément les raisons pour lesquelles OpenShift a occupé une position dominante sur le marché, comme le montre le graphique ci-dessous (voir plus) ).
« Actuellement, Red Hat est leader sur le marché avec une part de 44 %.
L'entreprise récolte les fruits de sa stratégie de vente grâce à une participation active aux affaires des clients, au cours de laquelle elle commence par conseiller et former 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 posts de cette série, nous examinerons plus en détail les avantages d'OpenShift par rapport à Kubernetes dans chacune des catégories abordées ici.
Source : habr.com
