La
plate-forme Red Hat OpenShift Container Platform 4 vous permet de diffuser la création d'
hôtes pour le déploiement de conteneurs , y compris dans l'infrastructure des fournisseurs de services cloud, sur les plateformes de virtualisation ou dans les systèmes bare-metal. Pour créer une plateforme cloud au sens plein, nous avons dû prendre un contrôle serré de tous les éléments utilisés et ainsi augmenter la fiabilité d'un processus d'automatisation complexe.
La solution évidente était d'utiliser Red Hat Enterprise Linux CoreOS (une variante de Red Hat Enterprise Linux) et CRI-O en standard, et voici pourquoi ...
Étant donné que le sujet de la navigation est très efficace pour trouver des analogies dans l'explication du fonctionnement de Kubernetes et des conteneurs, essayons de parler des problèmes commerciaux que CoreOS et CRI-O résolvent, en utilisant l'exemple de
l'invention de
Brunel pour la production de blocs de gréement . En 1803, Mark Brunel fut chargé de fabriquer 100 000 blocs de gréement pour les besoins de la marine britannique en pleine croissance. Un bloc de levage est un type de gréement utilisé pour attacher des cordes aux voiles. Jusqu'au tout début du XIXe siècle, ces blocs étaient fabriqués à la main, mais Brunel a pu automatiser la production et a commencé à produire des blocs standardisés à l'aide de machines. L'automatisation de ce processus signifiait que, par conséquent, tous les blocs étaient presque les mêmes, pouvaient être facilement remplacés en cas de panne et pouvaient être fabriqués en grandes quantités.
Imaginez maintenant que Brunel devrait faire ce travail pour 20 modèles de navires différents (versions Kubernetes) et pour cinq planètes différentes avec des courants marins et des vents complètement différents (fournisseurs de nuages). De plus, il était nécessaire que tous les navires (clusters OpenShift), quelles que soient les planètes parcourues, se comportent de manière identique du point de vue des capitaines (opérateurs contrôlant le fonctionnement des clusters). Poursuivant l'analogie marine, les capitaines de navire ne se soucient absolument pas des blocs de gréement (CRI-O) utilisés sur leurs navires - l'essentiel pour eux est que ces blocs sont solides et fiables.
OpenShift 4, en tant que plateforme cloud, fait face à un défi commercial très similaire. De nouveaux nœuds doivent être créés au moment de la création du cluster, en cas de défaillance de l'un des nœuds, ou lors de la mise à l'échelle du cluster. Lors de la création et de l'initialisation d'un nouveau nœud, les composants hôtes critiques, y compris CRI-O, doivent être configurés en conséquence. Comme pour toute autre production, les «matières premières» doivent être fournies au départ. Dans le cas des navires, le métal et le bois servent de matières premières. Cependant, si vous créez un hôte pour déployer des conteneurs dans un cluster OpenShift 4, vous devez disposer de fichiers de configuration et de serveurs API fournis en entrée. Après cela, OpenShift fournira le niveau d'automatisation nécessaire tout au long du cycle de vie, offrant le support produit nécessaire aux utilisateurs finaux et donc rentabilisant les investissements dans la plate-forme.
OpenShift 4 a été créé de manière à offrir la possibilité de mettre à jour le système de manière pratique tout au long du cycle de vie de la plate-forme (pour les versions 4.X) pour tous les principaux fournisseurs de cloud computing, de plates-formes de virtualisation et même de systèmes bare metal. Pour cela, les nœuds doivent être créés sur la base d'éléments interchangeables. Lorsqu'un cluster nécessite une nouvelle version de Kubernetes, il reçoit également la version CRI-O correspondante sur CoreOS. Étant donné que la version CRI-O est directement liée à Kubernetes, tout cela simplifie considérablement les permutations pour les tests, le dépannage ou le support. De plus, cette approche réduit les coûts pour les utilisateurs finaux et Red Hat.
Il s'agit d'un regard fondamentalement nouveau sur les clusters Kubernetes, qui jette les bases de la planification de nouvelles fonctionnalités très utiles et attrayantes. Le CRI-O (projet de conteneur ouvert Container Runtime Interface - Open Container Initiative, abrégé CRI-OCI) était le choix le plus réussi pour la création en masse de nœuds, ce qui est nécessaire pour travailler avec OpenShift. CRI-O remplacera le moteur Docker précédemment utilisé, offrant aux utilisateurs d'OpenShift un moteur de conteneur ennuyeux
économique, stable, simple et ennuyeux - oui, vous l'avez bien entendu - conçu spécialement pour travailler avec Kubernetes.
Le monde des conteneurs ouverts
Le monde évolue depuis longtemps vers des conteneurs ouverts. Que ce soit chez Kubernetes ou à des niveaux inférieurs, le
développement de normes de conteneurs conduit à un écosystème d'innovation à tous les niveaux.
Tout a commencé avec la création de l'Open Containers Initiative
en juin 2015 . À ce stade précoce des travaux, des spécifications pour l'
image du conteneur
(image) et le
temps d'exécution ont été formées. Cela a permis de garantir que les outils peuvent utiliser un seul standard d'
images de
conteneurs et un seul format pour les utiliser.
Des spécifications de
distribution ont ensuite été ajoutées, ce qui a permis aux utilisateurs d'échanger facilement des
images de conteneurs .
La communauté Kubernetes a ensuite développé une norme d'interface enfichable unique appelée
Container Runtime Interface (CRI) . Grâce à cela, les utilisateurs de Kubernetes ont pu connecter différents moteurs pour travailler avec des conteneurs en plus de Docker.
Les ingénieurs de Red Hat et de Google ont constaté une demande du marché pour un moteur de conteneur capable d'accepter les demandes de Kubelet utilisant le protocole CRI et a introduit des conteneurs compatibles avec les spécifications OCI mentionnées ci-dessus. Il
y avait donc un OCID . Mais excusez-moi, parce que nous avons dit que ce matériel serait consacré au CRI-O? En fait, c'est juste avec la sortie de la
version 1.0 que le projet a été renommé CRI-O.
Fig. 1.Innovation avec CRI-O et CoreOS
Avec le lancement de la plate-forme OpenShift 4, le
moteur de conteneur utilisé dans la plate-forme par défaut a été modifié et Docker a été remplacé par CRI-O, qui offrait un environnement de lancement de conteneur économique, stable, simple et ennuyeux qui se développe en parallèle avec Kubernetes. Cela simplifie considérablement la prise en charge et la configuration du cluster. La configuration du moteur de conteneur et de l'hôte, ainsi que leur gestion, devient automatisée dans OpenShift 4.
Arrête, comment c'est?
C'est vrai, avec l'avènement d'OpenShift 4, il n'est désormais plus nécessaire de se connecter à des hôtes individuels et d'installer un moteur de conteneur, de configurer le stockage, de configurer des serveurs pour la recherche ou de configurer un réseau. La plate-forme OpenShift 4 a été entièrement repensée pour utiliser
Operator Framework non seulement en termes d'applications utilisateur final, mais également en termes d'opérations de base au niveau de la plate-forme, telles que le déploiement d'images, la configuration du système ou l'installation de mises à jour.
Kubernetes a toujours permis aux utilisateurs de contrôler les applications en définissant l'état souhaité et en utilisant des
contrôleurs pour s'assurer que l'état réel est aussi proche que possible de l'état donné. Cette
approche utilisant un état donné et un état réel ouvre de grandes opportunités tant du point de vue du développement que du point de vue des opérations. Les développeurs peuvent déterminer l'état requis, le
transférer à l' opérateur sous la forme d'un fichier YAML ou JSON, puis l'opérateur peut créer l'instance d'application nécessaire dans l'environnement d'exploitation, tandis que l'état opérationnel de cette instance correspondra entièrement à celui spécifié.
En utilisant des opérateurs dans la plate-forme, OpenShift 4 apporte ce nouveau paradigme (en utilisant le concept d'état défini et réel) à la gestion de RHEL CoreOS et CRI-O. Les tâches de configuration et de version du système d'exploitation et du moteur de conteneur sont automatisées à l'aide de ce que l'on appelle l'
opérateur de configuration de machine (MCO) . MCO simplifie considérablement le travail de l'administrateur de cluster, en automatisant essentiellement les dernières étapes de l'installation, ainsi que les opérations suivantes après l'installation (opérations du deuxième jour). Tout cela fait d'OpenShift 4 une véritable plateforme cloud. Nous y reviendrons un peu plus tard.
Lancement de conteneurs
Les utilisateurs ont eu la possibilité d'utiliser le moteur CRI-O dans la plate-forme OpenShift à partir de la version 3.7 dans l'état de Tech Preview et de la version 3.9 dans l'état de General Available (actuellement pris en charge). De plus, Red Hat utilise
largement CRI-O pour lancer des charges de
travail de production dans OpenShift Online depuis la version 3.10. Tout cela a permis à l'équipe travaillant sur CRI-O d'acquérir une vaste expérience dans le lancement en masse de conteneurs sur de grands clusters Kubernetes. Pour avoir une compréhension de base de la façon dont Kubernetes utilise CRI-O, jetons un coup d'œil à l'illustration suivante, qui montre comment l'architecture fonctionne.
Fig. 2. Fonctionnement des conteneurs dans le cluster KubernetesCRI-O simplifie la création de nouveaux hôtes de conteneur en synchronisant l'intégralité du niveau supérieur lors de l'initialisation de nouveaux nœuds et lors de la publication de nouvelles versions de la plate-forme OpenShift. Un audit de plate-forme complet permet des mises à jour / annulations transactionnelles et empêche également les blocages dans les dépendances entre le noyau de queue de conteneur, le moteur de conteneur, Kubelets et Kubernetes Master. Grâce à la gestion centralisée de tous les composants de la plate-forme, avec le contrôle et la gestion des versions, vous pouvez toujours suivre un chemin clair de l'état A à l'état B. Cela simplifie le processus de mise à jour, améliore la sécurité, améliore les rapports sur les performances et aide à réduire le coût de la mise à jour et de l'installation de nouvelles versions.
Démonstration de la puissance des éléments interchangeables
Comme mentionné précédemment, l'utilisation de Machine Config Operator pour gérer l'hôte de conteneur et le moteur de conteneur dans OpenShift 4 fournit un nouveau niveau d'automatisation qui n'était pas possible auparavant sur la plate-forme Kubernetes. Pour illustrer les nouvelles fonctionnalités, nous montrons comment vous pouvez apporter des modifications au fichier crio.conf. Afin de ne pas vous perdre dans la terminologie, essayez de vous concentrer sur les résultats.
Tout d'abord, créons ce qu'on appelle une configuration d'exécution de conteneur - la configuration d'exécution du conteneur. Considérez ceci comme une ressource Kubernetes qui représente la configuration de CRI-O. En réalité, il s'agit d'une version spécialisée de ce qu'on appelle MachineConfig, qui est toute configuration déployée sur une machine RHEL CoreOS au sein d'un cluster OpenShift.
Cette ressource personnalisée, appelée ContainerRuntimeConfig, a été inventée pour faciliter la configuration de CRI-O par les administrateurs de cluster. Il s'agit d'un outil suffisamment puissant pour qu'il ne puisse être appliqué qu'à certains nœuds en fonction des paramètres de MachineConfigPool. Considérez ceci comme un groupe de machines qui ont le même objectif.
Faites attention aux deux dernières lignes que nous allons changer dans le fichier /etc/crio/crio.conf. Ces deux lignes sont très similaires aux lignes du fichier crio.conf, ce sont:
vi ContainerRuntimeConfig.yaml
Conclusion:
apiVersion: machineconfiguration.openshift.io/v1 kind: ContainerRuntimeConfig metadata: name: set-log-and-pid spec: machineConfigPoolSelector: matchLabels: debug-crio: config-log-and-pid containerRuntimeConfig: pidsLimit: 2048 logLevel: debug
Envoyez maintenant ce fichier au cluster Kubernetes et vérifiez qu'il est bien créé. Veuillez noter que l'opération est effectuée de la même manière que pour toute autre ressource Kubernetes:
oc create -f ContainerRuntimeConfig.yaml oc get ContainerRuntimeConfig
Conclusion:
NAME AGE set-log-and-pid 22h
Après avoir créé ContainerRuntimeConfig, nous devons modifier l'un des MachineConfigPools pour que Kubernetes comprenne que nous voulons appliquer cette configuration à un groupe spécifique de machines du cluster. Dans ce cas, nous allons modifier MachineConfigPool pour les nœuds maîtres:
oc edit MachineConfigPool/master
Conclusion (pour plus de clarté, le principal point est laissé):
... metadata: creationTimestamp: 2019-04-10T23:42:28Z generation: 1 labels: debug-crio: config-log-and-pid operator.machineconfiguration.openshift.io/required-for-upgrade: "" ...
À ce stade, MCO commence à créer un nouveau fichier crio.conf pour le cluster. Dans ce cas, un fichier de configuration entièrement terminé peut être affiché à l'aide de l'API Kubernetes. Rappelez-vous, ContainerRuntimeConfig n'est qu'une version spécialisée de MachineConfig, donc nous pouvons voir le résultat en regardant les lignes dans MachineConfigs:
oc get MachineConfigs | grep rendered
Conclusion:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Veuillez noter que le fichier de configuration résultant pour les nœuds maîtres s'est avéré être une version plus récente que les configurations d'origine. Pour l'afficher, exécutez la commande suivante. En passant, nous notons que c'est probablement l'un des meilleurs scripts à ligne unique de l'histoire de Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Conclusion:
pids_limit = 2048
Assurez-vous maintenant que la configuration a été appliquée à tous les nœuds maîtres. Nous obtenons d'abord une liste de nœuds dans le cluster:
oc get node | grep master Output: ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1 ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Regardez maintenant le fichier installé. Vous verrez que le fichier a été mis à jour avec les nouvelles directives pid et debug que nous avons spécifiées dans la ressource ContainerRuntimeConfig. L'élégance même:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid'
Conclusion:
... pids_limit = 2048 ... log_level = "debug" ...
Toutes ces modifications dans le cluster ont été effectuées même sans démarrer SSH. Tout le travail a été effectué en contactant le nœud maître de Kuberentes. Autrement dit, ces nouveaux paramètres ont été configurés uniquement sur les nœuds maîtres. Dans le même temps, les nœuds de travail n'ont pas changé, ce qui démontre les avantages de la méthodologie Kubernetes utilisant des états prédéfinis et actuels appliqués aux hôtes de conteneur et aux moteurs de conteneur avec des éléments interchangeables.
L'exemple ci-dessus montre la possibilité d'apporter des modifications à un petit cluster OpenShift Container Platform 4 avec trois nœuds de travail ou à un énorme cluster de production avec 3000 nœuds. Dans tous les cas, la quantité de travail sera la même - et très petite - il suffit de configurer le fichier ContainerRuntimeConfig et de modifier une étiquette dans MachineConfigPool. Et vous pouvez le faire avec n'importe quelle version de la plate-forme OpenShift Container Platform 4.X utilisée par Kubernetes tout au long de son cycle de vie.
Souvent, les entreprises technologiques se développent si rapidement que nous ne sommes pas en mesure d'expliquer pourquoi nous choisissons certaines technologies pour les composants de base. Les moteurs de conteneurs ont toujours été le composant avec lequel les utilisateurs interagissent directement. Étant donné que la popularité des conteneurs a naturellement commencé avec l'avènement des moteurs de conteneurs, les utilisateurs s'y intéressent souvent. C'est une autre raison pour laquelle Red Hat a opté pour CRI-O. Les conteneurs évoluent, avec l'accent mis sur l'orchestration aujourd'hui, et nous sommes arrivés à la conclusion que CRI-O offre la meilleure expérience lorsque vous travaillez avec OpenShift 4.