Composants maître Red Hat OpenShift

Passez en revue les composants ci-après dans le maître géré par IBM de votre cluster Red Hat OpenShift on IBM Cloud.

Vous ne pouvez pas modifier ces composants. IBM gère les composants et les met automatiquement à jour durant les mises à jour des correctifs de maître.

Dans OpenShift Container Platform 4, de nombreux composants sont configurés par un opérateur correspondant une facilité de gestion. Le tableau suivant présente en même temps ces opérateurs et composants afin de se concentrer sur la fonctionnalité principale fournie par le composant au cluster :

Service exclusif

Le maître et tous les composants du maître vous sont exclusivement dédiés et ne sont pas partagés avec d'autres clients IBM.

Répliques

Les composants du maître, y compris le serveur d'API Red Hat OpenShift et le magasin de données etcd, possèdent trois répliques et, s'ils se trouvent dans une métropole multizone, ils sont répartis entre les zones pour une disponibilité encore plus élevée. Les composants du maître sont sauvegardés toutes les 8 heures.

cloud-controller-manager

Le gestionnaire de contrôleurs de cloud gère des composants propres au fournisseur de cloud, tels que l'équilibreur de charge IBM Cloud.

cluster-health

Le composant d'état de santé du cluster surveille la santé du cluster et s'intègre à la surveillance et aux métriques d'IBM Cloud pour le service.

cluster-policy-controller

Le module cluster-policy-controller gère les ressources stratégiques nécessaires à la création de pods au sein du cluster.

cluster-version-operator

L'opérateur de version de cluster (CVO) installe et met à jour d'autres opérateurs qui s'exécutent dans le cluster. Pour plus d'informations, voir le projet GitHub.

control-plane-operator

L'opérateur de plan de contrôle gère l'installation et la mise à jour des composants de plan de contrôle dans le maître.

etcd, etcd-molecule, etcd-operator

etcd est un magasin de paires clé/valeur à haute disponibilité qui contient l'état de toutes les ressources Kubernetes d'un cluster, comme par exemple les services, les déploiements et les pods. Les données dans etcd sont sauvegardées toutes les 8 heures sur une instance de stockage chiffrée gérée par IBM.

kube-controller-manager, openshift-controller-manager

Le contrôleur Kubernetes surveille l'état des objets au sein du cluster, comme l'ensemble de répliques d'une charge de travail. Lorsque l'état d'un objet change, par exemple si un pod d'un ensemble de répliques tombe en panne, le gestionnaire de contrôleur initie les actions correctives pour atteindre l'état requis. Le contrôleur Red Hat OpenShift exécute la même fonction pour les objets spécifiques à l'API Red Hat OpenShift, tels que les projets.

kube-scheduler

Le planificateur Kubernetes surveille les pods nouvellement créés et décide où les déployer en fonction de la capacité, des besoins de performance, des contraintes de politique, des spécifications anti-affinité et des exigences de la charge de travail. Si aucun noeud worker ne répond à ces exigences, le pod n'est pas déployé dans le cluster.

manifests-bootstrapper

La tâche manifests-boot-strapper configure le maître avec les certificats requis pour le rejoindre en tant que nœud maître de la grappe.

oauth-openshift

Le serveur OAuth intégré est automatiquement configuré pour s'intégrer à IBM Cloud Identity and Access Management (IAM). Vous ne pouvez pas ajouter d'autres fournisseurs d'identité pris en charge au cluster. Pour plus d'informations sur l'authentification auprès du cluster via IAM, voir Accès aux clusters Red Hat OpenShift.

openshift-apiserver, openshift-apiserver-operator, kube-apiserver

Le serveur d'API constitue le point d'entrée principal pour toutes les demandes de gestion de cluster du noeud worker au maître. Le serveur d'API valide et traite les demandes qui modifient l'état des objets Kubernetes, tels que les pods ou les services, et les objets Red Hat OpenShift, tels que les projets ou les utilisateurs. Ensuite, le serveur d'API stocke cet état dans le magasin de données etcd.

konnectivity-server, konnectivity-operator

Le serveur Konnectivity travaille avec l'agent Konnectivity pour connecter en toute sécurité le maître au nœud de travail. Cette connexion prend en charge les appels apiserver proxy vers vos pods et services, les appels oc exec, attach et logs vers le kubelet et les webhooks de modification et de validation.

Contrôleurs d'admission

Les contrôleurs d'admission sont implémentés pour des fonctions spécifiques dans les clusters Red Hat OpenShift on IBM Cloud. Avec ces contrôleurs, vous pouvez configurer des règles dans votre cluster pour déterminer si une action particulière dans le cluster est autorisée ou non. Dans la politique, vous pouvez spécifier les conditions dans lesquelles un utilisateur ne peut pas effectuer une action, même si cette action fait partie des autorisations générales que vous avez attribuées à l'utilisateur en utilisant RBAC. Par conséquent, les contrôleurs d'admission peuvent fournir une couche de sécurité supplémentaire pour votre cluster avant le traitement d'une demande d'API par le serveur d'API Red Hat OpenShift. Lorsque vous créez un cluster Red Hat OpenShift, les contrôleurs d'admission Kubernetes suivants sont automatiquement installés dans l'ordre donné dans le master Red Hat OpenShift, qui ne peut pas être modifié par l'utilisateur :

• NamespaceLifecycle
• LimitRanger
• ServiceAccount
• DefaultStorageClass
• ResourceQuota
• StorageObjectInUseProtection
• PersistentVolumeClaimResize
• Priority
• BuildByStrategy
• OriginPodNodeEnvironment
• PodNodeSelector
• ExternalIPRanger
• NodeRestriction
• SecurityContextConstraint
• SCCExecRestrictions
• PersistentVolumeLabel
• OwnerReferencesPermissionEnforcement
• PodTolerationRestriction
• openshift.io/JenkinsBootstrapper
• openshift.io/BuildConfigSecretInjector
• openshift.io/ImageLimitRange
• openshift.io/RestrictedEndpointsAdmission
• openshift.io/ImagePolicy
• openshift.io/IngressAdmission
• openshift.io/ClusterResourceQuota
• MutatingAdmissionWebhook
• ValidatingAdmissionWebhook

Vous pouvez installer vos propres contrôleurs d'admission dans le cluster ou choisir parmi les contrôleurs d'admission optionnels fournis par Red Hat OpenShift on IBM Cloud. Mise en œuvre de la sécurité des images de conteneurs : Installer Portieris pour bloquer les déploiements de conteneurs à partir d'images non signées.

Si vous avez installé manuellement des contrôleurs d'admission et que vous ne voulez plus les utiliser, veillez à les supprimer entièrement. Si les contrôleurs d'admission ne sont pas entièrement supprimés, ils peuvent bloquer toutes les actions que vous souhaitez effectuer sur le cluster.

Red Hat OpenShift composants du nœud de travail

Passez en revue les composants ci-après dans les noeuds worker gérés par le client de votre cluster Red Hat OpenShift on IBM Cloud.

Ces composants s'exécutent sur vos noeuds worker car vous pouvez les utiliser avec les charges de travail que vous déployez sur votre cluster. Par exemple, vos applications peuvent utiliser un opérateur de OperatorHub qui exécute un conteneur à partir d'une image dans le registre interne. Vous êtes responsable de l'utilisation que vous faites de ces composants, mais IBM fournit des mises à jour les concernant dans les mises à jour de correctif de noeud worker que vous choisissez d'appliquer.

Dans OpenShift Container Platform, de nombreux composants sont configurés par un opérateur correspondant pour faciliter la gestion. Le tableau suivant présente en même temps ces opérateurs et composants afin de se concentrer sur la fonctionnalité principale fournie par le composant au cluster :

Service exclusif

Les noeuds worker et tous les composants de noeud worker vous sont exclusivement dédiés et ne sont pas partagés avec d'autres clients IBM. Toutefois, si vous utilisez des machines virtuelles de nœuds de travail, le matériel sous-jacent peut être partagé avec d'autres clients IBM en fonction du niveau d'isolation matérielle que vous choisissez.

Système d'exploitation

Pour obtenir la liste des systèmes d'exploitation pris en charge par version de cluster, voir Informations sur la version.

Interface d'exécution de conteneur CRI-O

Vos nœuds de travail sont installés avec CRI-O comme interface d'exécution du conteneur. Pour plus d'informations, voir Interface d'exécution de conteneur.

Projets

Red Hat OpenShift organise vos ressources dans des projets, qui sont des espaces de noms Kubernetes avec des annotations, et inclut beaucoup plus de composants que les clusters de communauté Kubernetes pour exécuter des fonctions Red Hat OpenShift telles que le catalogue. Les lignes suivantes décrivent certains composants de projets. Pour plus d'informations, voir Travailler avec des projets.

calico-system, tigera-operator

Calico gère les règles réseau pour votre cluster et inclut un petit nombre de composants pour gérer la connectivité du réseau de conteneur, l'affectation d'adresse IP et le contrôle de trafic réseau. L'opérateur Tigera installe et gère le cycle de vie des composants Calico.

default

Ce projet est utilisé si vous ne spécifiez pas de projet ou si vous créez un projet pour vos ressources Kubernetes.

ibm-system

Ce projet inclut le déploiement ibm-cloud-provider-ip qui fonctionne avec keepalived pour fournir un diagnostic d'intégrité et un équilibrage de charge de couche 4 pour les demandes vers les pods d'application.

kube-system

Ce projet inclut de nombreux composants qui sont utilisés pour exécuter Kubernetes sur le noeud worker.

• ibm-master-proxy: ibm-master-proxy est un ensemble de démons qui achemine les demandes du noeud de travail vers les adresses IP des répliques maître hautement disponibles. Dans les clusters à zone unique, le maître comporte trois répliques sur des hôtes distincts. Pour les clusters qui se trouvent dans une zone compatible avec plusieurs zones, le maître comporte trois répliques réparties sur les différentes zones. Un équilibreur de charge à haute disponibilité transfère les demandes vers le nom de domaine maître aux répliques du maître.
• kubelet: kubelet est un agent de noeud worker qui s'exécute sur chaque noeud worker et qui est chargé de surveiller la santé des pods qui s'exécutent sur le noeud worker et de surveiller les événements envoyés par le serveur d'API. En fonction des événements, le kubelet crée ou retire des pods, assure la mise en place des sondes Liveness probe et Readiness probe et renvoie le statut des pods au serveur d'API.
• vpn: L'agent Konnectivity travaille avec le serveur Konnectivity pour connecter en toute sécurité le maître au nœud de travail. Cette connexion prend en charge les appels apiserver proxy vers vos pods et services, ainsi que les appels oc exec, attach et logs vers le kubelet.
• Autres composants : Le projet kube-system inclut également des composants pour gérer les ressources IBM, telles que les plug-ins de stockage pour le stockage de fichiers et de blocs, l'équilibreur de charge d'application (ALB) et keepalived.

openshift-cloud-credential-operator

L'opérateur de données d'identification de cloud gère un contrôleur pour les composants Red Hat OpenShift qui demandent des données d'identification de fournisseur de cloud. Le contrôleur garantit que seules les données d'identification requises pour l'opération sont utilisées, et non des droits élevés, tels que admin. Pour plus d'informations, voir le projet GitHub.

openshift-cluster-node-tuning-operator

IBM gère l'opérateur de réglage des nœuds, qui exécute un démon sur chaque nœud de travailleur de la grappe pour régler les nœuds de travailleur.

openshift-cluster-samples-operator

L' opérateur d'échantillons gère certains flux d'images et modèles qui sont fournis par défaut avec le cluster Red Hat OpenShift. Vous pouvez déployer ces modèles à partir de la perspective Développeur dans la console Web Red Hat OpenShift.

openshift-cluster-storage-operator

L'opérateur de stockage de cluster s'assure qu'une classe de stockage par défaut est définie.

openshift-console, openshift-console-operator

La console web Red Hat OpenShift est une interface web que vous pouvez utiliser pour gérer les ressources Red Hat OpenShift et Kubernetes qui fonctionnent dans votre cluster. Vous pouvez également utiliser la console pour afficher un jeton oc login pour vous authentifier auprès de votre cluster à partir d'une interface CLI. Pour plus d'informations, voir Navigation dans la console Red Hat OpenShift.

openshift-dns, openshift-dns-operator

Le projet DNS inclut les composants permettant de valider le trafic réseau entrant par rapport à des règles iptables qui sont configurées sur le noeud worker, et les demandes proxy qui sont autorisées à entrer dans le cluster ou à en sortir.

openshift-image-registry

Red Hat OpenShift fournit un registre d'images de conteneur interne que vous pouvez utiliser pour gérer et afficher localement les images via la console. Sinon, vous pouvez configurer l'IBM Cloud Container Registry privé ou importer des images d'IBM Cloud Container Registry dans le registre interne. Le registre interne est livré avec un volume File Storage for Classic dans votre compte d'infrastructure IBM Cloud pour stocker les images du registre. Le volume de stockage de fichiers est mis à disposition via la réservation de volume persistant image-registry-storage.

openshift-ingress, openshift-ingress-operator

Red Hat OpenShift utilise les routes pour exposer directement le service d'une application sur un nom d'hôte afin que les clients externes puissent accéder au service. Pour créer des routes, le cluster utilise l'opérateur Ingress. Vous pouvez également utiliser Ingress pour exposer des applications en externe et personnaliser le routage. Ingress se compose de trois composants : l'opérateur Ingress, Ingress contrôleur et Route resources. Le contrôleur Ingress mappe le service au nom d'hôte. Par défaut, le contrôleur Ingress comprend deux répliques. Assurez-vous que votre cluster comporte au moins deux nœuds worker afin que le contrôleur Ingress puisse fonctionner sur des hôtes de calcul distincts pour une plus grande disponibilité.

openshift-marketplace

La place de marché comprend le module OperatorHub qui est livré par défaut avec le cluster Red Hat OpenShift. OperatorHub inclut des opérateurs de Red Hat et de fournisseurs tiers. Gardez à l'esprit que ces opérateurs sont fournis par la communauté, qu'ils risquent de ne pas s'intégrer à votre cluster et qu'ils ne sont pas pris en charge par IBM. Vous pouvez activer des opérateurs à partir d'OperatorHub dans la console Web Red Hat OpenShift.

openshift-monitoring

OpenShift Container Platform comprend une pile de surveillance intégrée pour votre cluster, qui inclut des métriques et des capacités de gestion des alertes. Pour obtenir une comparaison de la pile de surveillance intégrée et d'autres options, telles qu'IBM Cloud Monitoring, voir Description des options de journalisation et de surveillance.

openshift-multus

OpenShift Container Platform utilise le plug-in Multus container network interface (CNI) pour permettre la mise en place de plusieurs réseaux de pods. Cependant, vous ne pouvez pas configurer le cluster pour qu'il utilise plusieurs réseaux pod. Les clusters Red Hat OpenShift on IBM Cloud prennent en charge uniquement Calico, qui est configuré par défaut pour votre cluster. Si cette option est activée, Service Mesh utilise le plug-in Multus.

openshift-network-operator

L' opérateur de réseau de cluster(CNO) gère les composants du réseau de cluster qui sont configurés par défaut, tels que le plug-in de fournisseur de réseau de pods CNI et l'opérateur DNS.

openshift-operator-lifecycle-manager

Le gestionnaire du cycle de vie des opérateurs(OLM ) gère le cycle de vie de tous les opérateurs et du catalogue qui s'exécutent dans le cluster, y compris les opérateurs des composants par défaut et tous les opérateurs personnalisés que vous ajoutez.

openshift-service-ca, openshift-service-ca-operator

L'opérateur d'autorité de certification (CA) exécute la signature de certificat et injecte des certificats dans les ressources de serveur d'API et les mappes de configuration du cluster. Pour plus d'informations, voir le projet GitHub.

Cluster avec noeuds finaux de service de cloud public et privé

Le diagramme ci-après présente les composants de votre cluster et montre leur interaction lorsque le noeud final de service cloud public et le noeud final de service cloud privé sont activés. Lorsque les deux noeuds finaux de service sont activés, votre cloud privé virtuel crée un équilibreur de charge public pour chacun d'eux pour le trafic entrant.

Cluster avec noeud final de service de cloud privé uniquement

Le diagramme ci-après présente les composants de votre cluster et montre leur interaction lorsque seul le noeud final de service cloud privé est activé. Etant donné que seul le noeud final de service cloud privé est activé, votre cloud privé virtuel crée un équilibreur de charge privé pour chacun d'eux pour le trafic entrant.

Composants des nœuds maître et travailleur du VPC

Les nœuds maîtres et de travail incluent les mêmes composants que ceux décrits dans l'architecture de cluster classique pour les clusters. Pour plus d'informations sur l'architecture OpenShift Container Platform, voir la documentation Red Hat OpenShift.

Maître

Les composants du maître, y compris le serveur d'API et etcd, possèdent trois répliques et sont répartis entre les zones pour une disponibilité encore plus élevée. Les masters comprennent les mêmes composants que ceux décrits dans l'architecture classique des clusters. Le maître et tous les composants du maître vous sont exclusivement dédiés et ne sont pas partagés avec d'autres clients IBM.

Noeud worker

Avec Red Hat OpenShift on IBM Cloud, les machines virtuelles que votre cluster gère sont des instances nommées noeuds worker. Ces machines virtuelles de noeud worker et tous les composants des noeuds worker vous sont exclusivement dédiés et ne sont pas partagés avec d'autres clients IBM. Cependant, le matériel sous-jacent est partagé avec d'autres clients IBM. Vous gérez les noeuds worker via les outils d'automatisation fournis par Red Hat OpenShift on IBM Cloud, tels que l'API, l'interface de ligne de commande ou la console. Contrairement aux clusters classiques, vous ne voyez pas les nœuds worker de traitement VPC dans votre portail d'infrastructure ou votre facture d'infrastructure séparée, mais vous gérez à la place toutes les activités de maintenance et de facturation pour les nœuds worker à partir de Red Hat OpenShift on IBM Cloud.

Les nœuds de travail comprennent les mêmes composants que ceux décrits dans l'architecture classique du cluster.

Lorsque vous exécutez la commande oc get nodes, vous constaterez peut-être que les rôles de vos noeuds worker sont identifiés comme master,worker. Ces nœuds sont des nœuds worker dans IBM Cloud et n'incluent pas les composants maître gérés par IBM. En revanche, ces noeuds sont identifiés comme master car ils exécutent des composants OpenShift Container Platform qui sont requis pour configurer et gérer des ressources par défaut dans le cluster, par exemple, OperatorHub et le registre interne.

Mise en réseau de cluster

Vos noeuds worker sont créés dans un sous-réseau VPC dans la zone que vous spécifiez. La communication entre le maître et les noeuds worker est établie sur le réseau privé. Si vous créez un cluster avec les noeuds finaux de service cloud public et de service cloud privé activés, les utilisateurs externes authentifiés peuvent communiquer avec le maître sur le réseau public, par exemple pour exécuter des commandes oc. Si vous créez un cluster uniquement avec les noeuds finaux de service cloud privés activés, les utilisateurs externes authentifiés peuvent communiquer avec le maître sur le réseau privé uniquement. Vous pouvez configurer votre cluster pour qu'il communique avec des réseaux sur site, d'autres VPC ou une infrastructure classique en configurant un VPN VPC, IBM Cloud Direct Link ou IBM Cloud Transit Gateway sur le réseau privé.

Mise en réseau d'application

Des équilibreurs de charge Virtual Private Cloud sont automatiquement créés dans votre VPC en dehors du cluster pour tous les services de réseau que vous créez dans votre cluster. Par exemple, par défaut, un équilibreur de charge VPC expose les services de routeur de votre cluster. Ou, vous pouvez créer un service Kubernetes LoadBalancer pour vos applications et un équilibreur de charge VPC est automatiquement généré. Les équilibreurs de charge VPC sont des demandes de multizone et de route pour votre application via les ports de noeud privés qui sont automatiquement ouverts sur vos nœuds worker. Si les noeuds finaux de service cloud public et de service cloud privé sont activés, les routeurs et les équilibreurs de charge VPC sont créés comme éléments publics par défaut. Si seul le noeud final de service cloud privé est activé, les routeurs et les équilibreurs de charge VPC sont créés comme éléments privés par défaut. Pour plus d'informations, voir Mise en réseau d'application publique pour les clusters de VPC ou Mise en réseau d'application privée pour les clusters de VPC. Calico est utilisé en tant que matrice de règles de mise en réseau de cluster.

Stockage

Vous pouvez uniquement configurer IBM Cloud Object Storage et Cloud Databases.