plate-forme vous permet de rationaliser la création , y compris dans l'infrastructure des fournisseurs de services cloud, sur les plateformes de virtualisation ou dans les systèmes nus. Pour créer une véritable plateforme basée sur le cloud, nous avons dû contrôler strictement tous les éléments utilisés et ainsi augmenter la fiabilité d'un processus d'automatisation complexe.
La solution évidente consistait à utiliser Red Hat Enterprise Linux CoreOS (une variante de Red Hat Enterprise Linux) et CRI-O comme standard, et voici pourquoi...
Puisque le sujet de la voile est un très bon sujet pour trouver des analogies pour expliquer le travail de Kubernetes et des conteneurs, essayons de parler des problèmes commerciaux que CoreOS et CRI-O résolvent, à l'aide d'un exemple. . En 1803, Marc Brunel fut chargé de produire 100 19 poulies de gréement pour les besoins de la marine britannique en pleine croissance. Un bloc de gréement 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 parvient à automatiser la production et commence à produire des blocs standardisés à l'aide de machines-outils. L'automatisation de ce processus signifiait que les blocs résultants étaient essentiellement identiques, pouvaient être facilement remplacés en cas de bris et pouvaient être produits en grande quantité.
Imaginez maintenant si Brunel devait 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 cloud). De plus, il était exigé que tous les vaisseaux (clusters OpenShift), quelles que soient les planètes sur lesquelles la navigation s'effectue, du point de vue des capitaines (opérateurs qui gèrent le fonctionnement des clusters) se comportent de la même manière. Pour poursuivre l'analogie maritime, les capitaines de navires ne se soucient pas du tout du type de blocs de gréement (CRI-O) utilisés sur leurs navires - l'essentiel pour eux est que ces blocs soient solides et fiables.
OpenShift 4, en tant que plateforme cloud, est confrontée à un défi commercial très similaire. Les nouveaux nœuds doivent être créés au moment de la création du cluster, en cas de panne de l'un des nœuds ou lors de la mise à l'échelle du cluster. Lorsqu'un nouveau nœud est créé et initialisé, les composants hôtes critiques, y compris CRI-O, doivent être configurés en conséquence. Comme dans toute autre production, les « matières premières » doivent être fournies au départ. Dans le cas des navires, les matières premières sont le métal et le bois. Cependant, dans le cas de la création d'un hôte pour déployer des conteneurs dans un cluster OpenShift 4, vous devez disposer de fichiers de configuration et de serveurs fournis par l'API en entrée. OpenShift fournira alors le niveau d'automatisation requis tout au long du cycle de vie, offrant le support produit nécessaire aux utilisateurs finaux et récupérant ainsi l'investissement dans la plateforme.
OpenShift 4 a été créé de manière à offrir la possibilité de mettre à jour facilement le système tout au long du cycle de vie de la plate-forme (pour les versions 4.X) pour tous les principaux fournisseurs de cloud computing, plates-formes de virtualisation et même des systèmes nus. Pour ce faire, des nœuds doivent être créés à partir d'éléments interchangeables. Lorsqu'un cluster nécessite une nouvelle version de Kubernetes, il reçoit également la version correspondante de CRI-O sur CoreOS. Étant donné que la version CRI-O est directement liée à Kubernetes, cela simplifie grandement toutes les permutations à des fins de test, de dépannage ou de support. De plus, cette approche réduit les coûts pour les utilisateurs finaux et pour Red Hat.
Il s’agit d’une façon fondamentalement nouvelle de penser les clusters Kubernetes et jette les bases de la planification de nouvelles fonctionnalités très utiles et convaincantes. CRI-O (Container Runtime Interface - Open Container Initiative, en abrégé CRI-OCI) s'est avéré être le choix le plus efficace pour la création massive de nœuds nécessaires pour travailler avec OpenShift. CRI-O remplacera le moteur Docker précédemment utilisé, offrant aux utilisateurs d'OpenShift – oui, vous avez bien entendu – un moteur de conteneur ennuyeux créé spécifiquement pour travailler avec Kubernetes.
Le monde des conteneurs ouverts
Le monde s’oriente depuis longtemps vers les conteneurs ouverts. Que ce soit dans Kubernetes, ou à des niveaux inférieurs, se traduit par un écosystème d’innovation à tous les niveaux.
Tout a commencé avec la création de l’Open Containers Initiative . À ce stade précoce des travaux, les spécifications des conteneurs ont été établies и . Cela garantissait que les outils pouvaient utiliser une seule norme et un format unifié pour travailler avec eux. Les spécifications ont été ajoutées plus tard , permettant aux utilisateurs de partager facilement .
La communauté Kubernetes a ensuite développé un standard unique pour une interface enfichable, appelée . 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é que le marché avait besoin d'un moteur de conteneur capable d'accepter les requêtes Kubelet via le protocole CRI et ont introduit des conteneurs compatibles avec les spécifications OCI mentionnées ci-dessus. Donc . Mais excusez-moi, n’a-t-on pas dit que ce matériel serait dédié au CRI-O ? En fait, c'est le cas, juste avec la sortie le projet a été renommé CRI-O.
Fig. 1.
Innover avec CRI-O et CoreOS
Avec le lancement de la plateforme OpenShift 4, cela a changé , utilisé par défaut dans la plateforme, et Docker a été remplacé par CRI-O, offrant un environnement rentable, stable, simple et ennuyeux pour exécuter un conteneur qui se développe en parallèle avec Kubernetes. Cela simplifie grandement la prise en charge et la configuration du cluster. La configuration du moteur et de l'hôte du conteneur, ainsi que leur gestion, devient automatisée au sein d'OpenShift 4.
Attends, comment ça se passe ?
C'est vrai, avec l'avènement d'OpenShift 4, il n'est plus nécessaire de se connecter à des hôtes individuels et d'installer un moteur de conteneur, de configurer le stockage, de configurer les serveurs de recherche ou de configurer un réseau. La plateforme OpenShift 4 a été entièrement repensée pour utiliser le non seulement en termes d'applications d'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 gérer les applications en définissant l'état souhaité et en utilisant , pour garantir que l'état réel correspond le plus possible à l'état cible. Ce ouvre de grandes opportunités tant du point de vue du développement que des opérations. Les développeurs peuvent définir l'état requis en à l'opérateur sous la forme d'un fichier YAML ou JSON, puis l'opérateur pourra créer l'instance d'application requise dans l'environnement de production, et l'état de fonctionnement de cette instance correspondra entièrement à celui spécifié.
En utilisant des opérateurs dans la plateforme, 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 gestion des versions du système d'exploitation et du moteur de conteneur sont automatisées à l'aide de ce que l'on appelle . MCO simplifie grandement le travail de l'administrateur du cluster, en automatisant essentiellement les dernières étapes de l'installation, ainsi que les opérations post-installation ultérieures (opérations du deuxième jour). Tout cela fait d’OpenShift 4 une véritable plateforme cloud. Nous y reviendrons un peu plus tard.
Exécution de conteneurs
Les utilisateurs ont eu la possibilité d'utiliser le moteur CRI-O dans la plateforme OpenShift depuis la version 3.7 dans le statut Tech Preview et depuis la version 3.9 dans le statut Généralement disponible (actuellement pris en charge). De plus, Red Hat utilise massivement 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 massif de conteneurs sur de grands clusters Kubernetes. Pour avoir une compréhension de base de la façon dont Kubernetes utilise CRI-O, regardons l'illustration suivante, qui montre le fonctionnement de l'architecture.
Riz. 2. Comment fonctionnent les conteneurs dans un cluster Kubernetes
CRI-O simplifie la création de nouveaux hôtes de conteneurs en synchronisant l'ensemble du niveau supérieur lors de l'initialisation de nouveaux nœuds et lors de la publication de nouvelles versions de la plateforme OpenShift. La révision de l'ensemble de la plate-forme permet des mises à jour/annulations transactionnelles et évite également les blocages dans les dépendances entre le cœur de queue du conteneur, le moteur de conteneur, les nœuds (Kubelets) et le nœud maître Kubernetes. En gérant de manière centralisée tous les composants de la plateforme, avec contrôle et gestion des versions, il existe toujours 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 de performances et contribue à réduire le coût des mises à jour et des installations de nouvelles versions. .
Démontrer la puissance des éléments de remplacement
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 offre un nouveau niveau d'automatisation qui n'était pas possible auparavant sur la plate-forme Kubernetes. Pour démontrer les nouvelles fonctionnalités, nous montrerons comment apporter des modifications au fichier crio.conf. Pour éviter de 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 – Container Runtime Config. Considérez-le 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 quelque chose appelé MachineConfig, qui correspond à toute configuration déployée sur une machine RHEL CoreOS dans le cadre d'un cluster OpenShift.
Cette ressource personnalisée, appelée ContainerRuntimeConfig, a été créée pour permettre aux administrateurs de cluster de configurer plus facilement CRI-O. Cet outil est suffisamment puissant pour ne pouvoir être appliqué qu'à certains nœuds en fonction des paramètres de MachineConfigPool. Considérez-le comme un groupe de machines qui servent le même objectif.
Notez les deux dernières lignes que nous allons modifier 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
Poussons maintenant ce fichier vers le cluster Kubernetes et vérifions qu'il a bien été créé. Veuillez noter que le fonctionnement est exactement le même que pour toute autre ressource Kubernetes :
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Conclusion:
NAME AGE
set-log-and-pid 22h
Une fois que nous avons créé ContainerRuntimeConfig, nous devons modifier l'un des MachineConfigPools pour signaler à Kubernetes que nous souhaitons appliquer cette configuration à un groupe spécifique de machines du cluster. Dans ce cas, nous modifierons le MachineConfigPool pour les nœuds maîtres :
oc edit MachineConfigPool/master
Conclusion (pour plus de clarté, l'essentiel 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, le fichier de configuration entièrement terminé peut être visualisé à l'aide de l'API Kubernetes. N'oubliez pas que ContainerRuntimeConfig n'est qu'une version spécialisée de MachineConfig, nous pouvons donc voir le résultat en examinant les lignes pertinentes 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 était une version plus récente que les configurations d'origine. Pour l'afficher, exécutez la commande suivante. Au passage, notons qu’il s’agit peut-être de l’un des meilleurs one-liners 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
Assurons-nous 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
Regardons maintenant le fichier installé. Vous verrez que le fichier a été mis à jour avec les nouvelles valeurs des directives pid et debug que nous avons spécifiées dans la ressource ContainerRuntimeConfig. L'élégance elle-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 apportées au cluster ont été apportées sans même exécuter SSH. Tout le travail a été effectué en accédant au nœud maître Kuberentes. Autrement dit, ces nouveaux paramètres ont été configurés uniquement sur les nœuds maîtres. Les nœuds de travail n'ont pas changé, ce qui démontre les avantages de la méthodologie Kubernetes consistant à utiliser des états spécifiés et réels en relation avec les hôtes de conteneurs et les moteurs de conteneurs 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 production ou à un énorme cluster de production avec 3000 4 nœuds. Dans tous les cas, la quantité de travail sera la même - et très faible - il suffit de configurer le fichier ContainerRuntimeConfig et de modifier une étiquette dans MachineConfigPool. Et vous pouvez le faire avec n’importe quelle version d’OpenShift Container Platform XNUMX.X exécutant Kubernetes tout au long de son cycle de vie.
Souvent, les entreprises technologiques évoluent si rapidement que nous sommes incapables d’expliquer pourquoi nous choisissons certaines technologies pour les composants sous-jacents. 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 choisi CRI-O. Les conteneurs évoluent en mettant désormais l'accent sur l'orchestration, et nous avons constaté que CRI-O offre la meilleure expérience lorsque vous travaillez avec OpenShift 4.
Source: habr.com