OpenShift 4 est déjà sorti depuis mai 2019, mais la version opensource et gratuite OKD 4 se faisait attendre. En effet, nous étions sans nouvelle version d’OKD depuis février 2019. Plusieurs doutes subsistaient sur son avenir après le rachat de Red Hat par IBM. Il faut savoir d’ailleurs qu’OpenShift 4.x constitue le va-tout pour IBM Cloud, qui compte bien grâce à lui rattraper son retard sur Azure et AWS...
Nous avons ainsi pu profiter longtemps d’une belle version 3.11, mais celle-ci commençait à vieillir et à s’éloigner des dernières versions de Kubernetes, qui lui, continuait sur sa lancée.
Il faut savoir que pour OpenShift la sortie d’une version majeure correspond à une vraie révolution d’architecture, pas une simple évolution.
Pour rappel historique
- Mai 2011 : Sortie OpenShift v1 suite au rachat de Makara par Red Hat
- Produit non opensource, basé sur une technologie de conteneurs Propriétaire
- OpenShift v2
- Séparation en trois projets : Origin (Opensource), Openshift (commercial) et Online (en SaaS). Même architecture technique que la V1
- 2015 : Sortie d’openshift v3
- Passage à Docker / Kubernetes, réécriture du produit à 100%.
- Mai 2019 : Sortie d’OpenShift v4
- Abandon de Docker, et passage à CRI-O comme moteur de conteneur
- Utilisation de CoreOS comme système d’exploitation des masters
- Nouvel installateur orienté cloud et infra as code.
- Consoles repensées
- Intégration poussée des opérateurs Kubernetes avec Operator Hub et Operator Lifecycle management.
Mais le voile a été levé le 15 juillet 2020 sur la version OKD 4.5. A l’heure de l’écriture de cet article, la dernière version stable est : 4.5.0-0.okd-2020-09-18-202631. Cette version est basée sur Kubernetes 1.18.
Dans cette série d’articles, nous allons découvrir cette nouvelle version, depuis son installation jusqu’à son utilisation en production.
Rappels : Qu’est-ce qu’OpenShift ? Quelles sont les différences avec OKD ?
Laissons Red Hat répondre à la question de ce qu’est OpenShift par rapport à Kubernetes :
https://www.redhat.com/fr/blog/OpenShift-and-kubernetes-whats-difference
Pour résumer, on peut comparer Kubernetes au noyau d’une distribution linux, OpenShift serait quant à lui une distribution à part entière.
C’est donc un produit complet, qui intègre Kubernetes comme noyau.
En quelques mots qu’apporte OpenShift par rapport à un Kubernetes “nu” ?
- Des consoles web, plus faciles d’accès que le dashboard Kubernetes. (une console orientée développeur et une console orientée administrateur)
- Une authentification simplifiée (LDAP, OAuth)
- La notion de S2I (Source To image), qui permet de prendre en charge la construction et le stockage des images.
- Une gestion plus stricte de la sécurité (Interdiction des conteneurs root).
OpenShift (OCP) vs OKD.
OKD, est la version opensource d’OpenShift, c’est un peu comme CentOS et RHEL. Les 2 produits possèdent exactement les mêmes fonctionnalités.
| OKD | OCP | |
|---|---|---|
| Coût | Gratuit (License Apache) | Payant (Souscription Annuelle Red Hat /IBM) |
| Support | Communautaire | Contractuel |
| OS | Fedora CoreOS | RHCOS (RHEL 7.6 supporté sur les compute Nodes) |
Les dessous d’OKD 4 : Fedora CoreOS
Fedora Core OS est une distribution Linux minimaliste dont le principal but est de servir de base à un cluster de conteneurs scalable. Elle inclut Docker et Podman pour le lancement des conteneurs. Fedora Core OS (FCOS) est le successeur de Fedora Atomic Host et de CoreOS Container Linux
Elle se configure avec un fichier yaml, le FCC (Fedora CoreOS Configuration) qui s’occupe, au démarrage, du partitionnement, de la configuration réseau, utilisateurs et sécurité.
Voilà à quoi un FCC (basique) peut ressembler :
variant: fcos
version: 1.1.0
passwd:
users:
- name: core
ssh_authorized_keys:
- ssh-rsa AAAA...
Fedora CoreOS est conçu pour être géré comme une infrastructure immuable. Une fois la machine mise en service, vous ne devez pas modifier ou reconfigurer la machine. Au lieu de cela, il faut modifier la FCC et l’utiliser pour provisionner une machine de remplacement. Cela ressemble de près à la façon dont vous gérez un conteneur.
Elle se met à jour automatiquement, c’est une rolling release, il suffit pour cela, de s’abonner à un canal de mises à jour (stable, testing…).
OKD 4 : Une nouvelle manière d’installer…
Avec OKD 3.x, nous utilisions un script ansible énorme (voire monstrueux) pour installer OpenShift sur les VMs d’une infrastructure préexistante. Ceci nous obligeait à maintenir une stack Terraform différente pour chaque cloud provider.
Avec OKD 4.x Red Hat a pris le train de l’infrastructure as code, et propose un programme d’installation (en go!) qui s’occupe à la fois de la partie infrastructure, de l’installation et de la configuration des nœuds du cluster OpenShift. Il embarque sa propre version de Terraform.
L'installateur OpenShift est clairement orienté cloud, il supporte nativement les opérateurs cloud suivants :
> aws
azure
gcp
openstack
ovirt
vsphere
L’installation sur du bare-metal n’est plus directement supportée (elle reste néanmoins possible)
Pour en savoir plus : https://docs.okd.io/latest/architecture/architecture-installation.html
L’installation des composants internes d’OpenShift, comme le routeur et la registry, utilise maintenant des opérateurs Kubernetes.
Installation sur AWS
Prérequis
- Créer un utilisateur avec la policy AdministratorAccess, récupérer ses credentials AWS
- Créer un domaine Route53 public
- Récupérer un pull secret chez Red Hat (optionnel) (https://cloud.Red Hat.com/OpenShift/install/pull-secret)
Téléchargement de l’installateur :https://github.com/OpenShift/okd/releaseshttps://github.com/OpenShift/okd/releases/download/4.5.0-0.okd-2020-09-18-202631/OpenShift-install-linux-4.5.0-0.okd-2020-09-18-202631.tar.gz
L’installation
Tout d’abord on crée le fichier de configuration install-config.yaml (recommandé) :
./openshift-install create install-config
Le programme vous pose plusieurs questions (cloud provider, région, clé ssh…)
On peut ensuite personnaliser le fichier install-config.yaml, pour par exemple
- Changer le type d’instance EC2 pour les control-planes et les workers
- Restreindre sur des AZ’s spécifiques
Pour le détail je vous renvoie à la documentation officielle :
Je vous conseille ensuite de sauvegarder ce fichier, car l’installateur le supprime une fois le cluster construit
cp install-config.yaml install-config.yaml.bak
Ensuite on peut lancer l’installation à proprement parler
[xxx@xxxx okd4-install]$ ./openShift-install create cluster
INFO Consuming Install Config from target directory
INFO Credentials loaded from the "default" profile in file "/home/xxx/.aws/credentials"
INFO Creating infrastructure resources...
INFO Waiting up to 20m0s for the Kubernetes API at https://api.okd4test.okd4.xxxx.fr:6443...
INFO API v1.18.3 up
INFO Waiting up to 40m0s for bootstrapping to complete...
INFO Destroying the bootstrap resources...
INFO Waiting up to 30m0s for the cluster at https://api.okd4test.okd4.xxxxx.fr:6443 to initialize...
INFO Waiting up to 10m0s for the OpenShift-console route to be created...
INFO Install complete!
INFO To access the cluster as the system:admin user when using 'oc', run 'export KUBECONFIG=/home/xxxx/Projects/okd4-install/auth/kubeconfig'
INFO Access the OpenShift web-console here: https://console-OpenShift-console.apps.okd4test.okd4.xxxx.fr
INFO Login to the console with user: "kubeadmin", and password: "xxxxx"
INFO Time elapsed: 32m7s
30 minutes après environ, vous avez accès à votre instance, et vous pouvez vous connecter à la console OKD.
Conclusion
Vous savez maintenant qu’OKD 4 est prêt à être installé sur votre cloud provider préféré. Je vous donne rendez-vous dans un prochain article, pour voir les évolutions concernant son utilisation dans un contexte DevOps.
