SupportConsoleDéveloppeursCommencer un essaiContact

12.4. Mise à jour d'un cluster dans un environnement déconnecté sans OpenShift Update Service

Utilisez les procédures suivantes pour mettre à jour un cluster dans un environnement déconnecté sans accès au service de mise à jour OpenShift.

12.4.1. Conditions préalables

  • L'outil d'interface de ligne de commande (CLI) oc doit être installé.
  • Vous devez approvisionner un registre local d'images de conteneurs avec les images de conteneurs pour votre mise à jour, comme décrit dans Mirroring the OpenShift Container Platform image repository.
  • Vous devez avoir accès au cluster en tant qu'utilisateur disposant de privilèges admin. Voir Utilisation de RBAC pour définir et appliquer des autorisations.
  • Vous devez disposer d'une sauvegarde etcd récente au cas où votre mise à jour échouerait et où vous devriez restaurer votre cluster à un état antérieur.
  • Vous devez vous assurer que tous les pools de configuration de machines (MCP) sont en cours d'exécution et ne sont pas en pause. Les nœuds associés à un MCP en pause sont ignorés lors du processus de mise à jour. Vous pouvez mettre les MCP en pause si vous effectuez une stratégie de mise à jour par déploiement canarien.
  • Si votre cluster utilise des informations d'identification gérées manuellement, mettez à jour les ressources du fournisseur de cloud pour la nouvelle version. Pour plus d'informations, notamment sur la manière de déterminer s'il s'agit d'une exigence pour votre cluster, voir Préparation de la mise à jour d'un cluster avec des informations d'identification gérées manuellement.
  • Si vous exécutez un opérateur ou si vous avez configuré une application avec le budget d'interruption des pods, il se peut que vous subissiez une interruption pendant le processus de mise à niveau. Si minAvailable est défini à 1 dans PodDisruptionBudget, les nœuds sont vidés pour appliquer les configurations de machine en attente, ce qui peut bloquer le processus d'éviction. Si plusieurs nœuds sont redémarrés, tous les pods peuvent s'exécuter sur un seul nœud, et le champ PodDisruptionBudget peut empêcher la vidange des nœuds.
Note

Si vous exécutez un opérateur ou si vous avez configuré une application avec le budget d'interruption des pods, il se peut que vous subissiez une interruption pendant le processus de mise à niveau. Si minAvailable est défini à 1 dans PodDisruptionBudget, les nœuds sont vidés pour appliquer les configurations de machine en attente, ce qui peut bloquer le processus d'éviction. Si plusieurs nœuds sont redémarrés, tous les pods peuvent s'exécuter sur un seul nœud, et le champ PodDisruptionBudget peut empêcher la vidange des nœuds.

12.4.2. Mise en pause d'une ressource MachineHealthCheck

Au cours du processus de mise à niveau, les nœuds de la grappe peuvent devenir temporairement indisponibles. Dans le cas des nœuds de travail, le contrôle de l'état de la machine peut identifier ces nœuds comme étant malsains et les redémarrer. Pour éviter de redémarrer ces nœuds, mettez en pause toutes les ressources MachineHealthCheck avant de mettre à jour le cluster.

Conditions préalables

  • Installez le CLI OpenShift (oc).

Procédure

  1. Pour dresser la liste de toutes les ressources MachineHealthCheck disponibles que vous souhaitez mettre en pause, exécutez la commande suivante : 

    $ oc get machinehealthcheck -n openshift-machine-api

  2. Pour mettre en pause les contrôles de santé de la machine, ajoutez l'annotation cluster.x-k8s.io/paused="" à la ressource MachineHealthCheck. Exécutez la commande suivante : 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""

    La ressource annotée MachineHealthCheck ressemble au fichier YAML suivant : 

    apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
  name: example
  namespace: openshift-machine-api
  annotations:
    cluster.x-k8s.io/paused: ""
spec:
  selector:
    matchLabels:
      role: worker
  unhealthyConditions:
  - type:    "Ready"
    status:  "Unknown"
    timeout: "300s"
  - type:    "Ready"
    status:  "False"
    timeout: "300s"
  maxUnhealthy: "40%"
status:
  currentHealthy: 5
  expectedMachines: 5
    Important

    Reprendre les contrôles de santé des machines après avoir mis à jour le cluster. Pour reprendre le contrôle, supprimez l'annotation de pause de la ressource MachineHealthCheck en exécutant la commande suivante : 

    $ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused-

12.4.3. Mise à jour du cluster déconnecté

Mettez à jour le cluster déconnecté vers la version d'OpenShift Container Platform pour laquelle vous avez téléchargé les images de mise à jour.

Note

Si vous avez un OpenShift Update Service local, vous pouvez mettre à jour en utilisant la console web connectée ou les instructions CLI au lieu de cette procédure.

Conditions préalables

  • Vous avez mis en miroir les images de la nouvelle version dans votre registre.
  • Vous avez appliqué à votre cluster la signature de l'image de version ConfigMap pour la nouvelle version.
  • Vous avez obtenu la valeur de la somme sha256 pour la version à partir de la signature de l'image ConfigMap.
  • Installez le CLI OpenShift (oc).
  • Mettre en pause toutes les ressources MachineHealthCheck.

Procédure

  • Mettre à jour le cluster : 

    $ oc adm upgrade --allow-explicit-upgrade --to-image ${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}<sha256_sum_value> 1
    1
    La valeur <sha256_sum_value> est la valeur de la somme sha256 pour la libération de la signature de l'image ConfigMap, par exemple, @sha256:81154f5c03294534e1eaf0319bef7a601134f891689ccede5d705ef659aa8c92

    Si vous utilisez ImageContentSourcePolicy pour le registre miroir, vous pouvez utiliser le nom canonique du registre au lieu de LOCAL_REGISTRY.

    Note

    Vous ne pouvez configurer des secrets de tirage globaux que pour les clusters qui ont un objet ImageContentSourcePolicy. Vous ne pouvez pas ajouter un secret d'extraction à un projet.

12.4.4. Configuration de la mise en miroir du référentiel du registre d'images

La configuration de la mise en miroir du référentiel du registre des conteneurs vous permet d'effectuer les opérations suivantes :

  • Configurez votre cluster OpenShift Container Platform pour rediriger les demandes d'extraction d'images à partir d'un dépôt sur un registre d'images source et les faire résoudre par un dépôt sur un registre d'images miroir.
  • Identifier plusieurs référentiels miroirs pour chaque référentiel cible, afin de s'assurer que si un miroir est en panne, un autre peut être utilisé.

Les attributs de la mise en miroir de référentiel dans OpenShift Container Platform sont les suivants :

  • Les extractions d'images résistent aux interruptions du registre.
  • Les clusters situés dans des environnements déconnectés peuvent extraire des images de sites critiques, tels que quay.io, et demander aux registres situés derrière le pare-feu de l'entreprise de fournir les images demandées.
  • Un ordre particulier de registres est essayé lorsqu'une demande d'extraction d'image est faite, le registre permanent étant généralement le dernier essayé.
  • Les informations sur le miroir que vous saisissez sont ajoutées au fichier /etc/containers/registries.conf sur chaque nœud du cluster OpenShift Container Platform.
  • Lorsqu'un nœud demande une image à partir du référentiel source, il essaie chaque référentiel miroir à tour de rôle jusqu'à ce qu'il trouve le contenu demandé. Si tous les miroirs échouent, le cluster essaie le référentiel source. En cas de succès, l'image est transférée au nœud.

La configuration de la mise en miroir du référentiel peut se faire de la manière suivante :

  • A l'installation d'OpenShift Container Platform :

    En extrayant les images de conteneurs nécessaires à OpenShift Container Platform, puis en amenant ces images derrière le pare-feu de votre entreprise, vous pouvez installer OpenShift Container Platform dans un centre de données qui se trouve dans un environnement déconnecté.

  • Après l'installation d'OpenShift Container Platform :

    Même si vous ne configurez pas la mise en miroir lors de l'installation d'OpenShift Container Platform, vous pouvez le faire plus tard en utilisant l'objet ImageContentSourcePolicy.

La procédure suivante fournit une configuration miroir post-installation, dans laquelle vous créez un objet ImageContentSourcePolicy qui identifie :

  • La source du référentiel d'images de conteneurs que vous souhaitez mettre en miroir.
  • Une entrée distincte pour chaque référentiel miroir dans lequel vous souhaitez proposer le contenu demandé au référentiel source.
Note

Vous ne pouvez configurer des secrets de tirage globaux que pour les clusters qui ont un objet ImageContentSourcePolicy. Vous ne pouvez pas ajouter un secret d'extraction à un projet.

Conditions préalables

  • Accès au cluster en tant qu'utilisateur ayant le rôle cluster-admin.

Procédure

  1. Configurer les référentiels miroirs, en utilisant l'un ou l'autre :

    • La configuration d'un référentiel miroir avec Red Hat Quay, comme décrit dans Red Hat Quay Repository Mirroring. L'utilisation de Red Hat Quay vous permet de copier des images d'un référentiel vers un autre et de synchroniser automatiquement ces référentiels de manière répétée au fil du temps.

    • Utilisation d'un outil tel que skopeo pour copier manuellement les images du répertoire source vers le référentiel miroir.

      Par exemple, après avoir installé le paquetage RPM skopeo sur un système Red Hat Enterprise Linux (RHEL) 7 ou RHEL 8, utilisez la commande skopeo comme indiqué dans cet exemple : 

      $ skopeo copy \
docker://registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6 \
docker://example.io/example/ubi-minimal

      Dans cet exemple, vous avez un registre d'images de conteneurs nommé example.io avec un dépôt d'images nommé example dans lequel vous voulez copier l'image ubi8/ubi-minimal à partir de registry.access.redhat.com. Après avoir créé le registre, vous pouvez configurer votre cluster OpenShift Container Platform pour rediriger les requêtes faites sur le dépôt source vers le dépôt miroir.

  2. Connectez-vous à votre cluster OpenShift Container Platform.

  3. Créez un fichier ImageContentSourcePolicy (par exemple, registryrepomirror.yaml), en remplaçant la source et les miroirs par vos propres paires et images de registres et de référentiels : 

    apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: ubi8repo
spec:
  repositoryDigestMirrors:
  - mirrors:
    - example.io/example/ubi-minimal 1
    - example.com/example/ubi-minimal 2
    source: registry.access.redhat.com/ubi8/ubi-minimal 3
  - mirrors:
    - mirror.example.com/redhat
    source: registry.redhat.io/openshift4 4
  - mirrors:
    - mirror.example.com
    source: registry.redhat.io 5
  - mirrors:
    - mirror.example.net/image
    source: registry.example.com/example/myimage 6
  - mirrors:
    - mirror.example.net
    source: registry.example.com/example 7
  - mirrors:
    - mirror.example.net/registry-example-com
    source: registry.example.com 8
    1
    Indique le nom du registre d'images et du référentiel.
    2
    Indique plusieurs référentiels miroirs pour chaque référentiel cible. Si un miroir est hors service, le référentiel cible peut utiliser un autre miroir.
    3
    Indique le registre et le référentiel contenant le contenu qui est mis en miroir.
    4
    Vous pouvez configurer un espace de noms à l'intérieur d'un registre pour utiliser n'importe quelle image dans cet espace de noms. Si vous utilisez un domaine de registre comme source, la ressource ImageContentSourcePolicy est appliquée à tous les référentiels du registre.
    5
    Si vous configurez le nom du registre, la ressource ImageContentSourcePolicy est appliquée à tous les référentiels, du registre source au registre miroir.
    6
    Tire l'image mirror.example.net/image@sha256:…​.
    7
    Extrait l'image myimage dans l'espace de noms du registre source à partir du miroir mirror.example.net/myimage@sha256:…​.
    8
    Extrait l'image registry.example.com/example/myimage du registre miroir mirror.example.net/registry-example-com/example/myimage@sha256:…​. La ressource ImageContentSourcePolicy est appliquée à tous les référentiels d'un registre source à un registre miroir mirror.example.net/registry-example-com.

  4. Créer le nouvel objet ImageContentSourcePolicy: 

    $ oc create -f registryrepomirror.yaml

    Une fois l'objet ImageContentSourcePolicy créé, les nouveaux paramètres sont déployés sur chaque nœud et le cluster commence à utiliser le référentiel miroir pour les requêtes vers le référentiel source.

  5. Pour vérifier que les paramètres de configuration en miroir sont appliqués, procédez comme suit sur l'un des nœuds.

    1. Dressez la liste de vos nœuds : 

      $ oc get node

      Exemple de sortie

      NAME                           STATUS                     ROLES    AGE  VERSION
ip-10-0-137-44.ec2.internal    Ready                      worker   7m   v1.25.0
ip-10-0-138-148.ec2.internal   Ready                      master   11m  v1.25.0
ip-10-0-139-122.ec2.internal   Ready                      master   11m  v1.25.0
ip-10-0-147-35.ec2.internal    Ready                      worker   7m   v1.25.0
ip-10-0-153-12.ec2.internal    Ready                      worker   7m   v1.25.0
ip-10-0-154-10.ec2.internal    Ready                      master   11m  v1.25.0

      La ressource Imagecontentsourcepolicy ne redémarre pas les nœuds.

    2. Lancez le processus de débogage pour accéder au nœud : 

      $ oc debug node/ip-10-0-147-35.ec2.internal

      Exemple de sortie

      Starting pod/ip-10-0-147-35ec2internal-debug ...
To use host binaries, run `chroot /host`

    3. Changez votre répertoire racine en /host: 

      sh-4.2# chroot /host

    4. Vérifiez le fichier /etc/containers/registries.conf pour vous assurer que les changements ont bien été effectués : 

      sh-4.2# cat /etc/containers/registries.conf

      Exemple de sortie

      unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
short-name-mode = ""

[[registry]]
  prefix = ""
  location = "registry.access.redhat.com/ubi8/ubi-minimal"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "example.io/example/ubi-minimal"

  [[registry.mirror]]
    location = "example.com/example/ubi-minimal"

[[registry]]
  prefix = ""
  location = "registry.example.com"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.net/registry-example-com"

[[registry]]
  prefix = ""
  location = "registry.example.com/example"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.net"

[[registry]]
  prefix = ""
  location = "registry.example.com/example/myimage"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.net/image"

[[registry]]
  prefix = ""
  location = "registry.redhat.io"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.com"

[[registry]]
  prefix = ""
  location = "registry.redhat.io/openshift4"
  mirror-by-digest-only = true

  [[registry.mirror]]
    location = "mirror.example.com/redhat"

    5. Transmet un condensé d'image au nœud à partir de la source et vérifie s'il est résolu par le miroir. Les objets ImageContentSourcePolicy ne prennent en charge que les condensés d'image, et non les balises d'image. 

      sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455ebaa6

Dépannage de la mise en miroir du référentiel

Si la procédure de mise en miroir du référentiel ne fonctionne pas comme décrit, utilisez les informations suivantes sur le fonctionnement de la mise en miroir du référentiel pour résoudre le problème.

  • Le premier miroir de travail est utilisé pour fournir l'image tirée.
  • Le registre principal n'est utilisé que si aucun autre miroir ne fonctionne.
  • Dans le contexte du système, les drapeaux Insecure sont utilisés comme solution de repli.
  • Le format du fichier /etc/containers/registries.conf a récemment changé. Il s'agit désormais de la version 2 et du format TOML.

12.4.5. Élargissement de la portée du catalogue d'images miroirs afin de réduire la fréquence des redémarrages des nœuds de la grappe

Vous pouvez définir la portée du catalogue d'images en miroir au niveau du référentiel ou au niveau du registre général. Une ressource ImageContentSourcePolicy à portée étendue réduit le nombre de fois où les nœuds doivent redémarrer en réponse aux changements apportés à la ressource.

Pour élargir la portée du catalogue d'images miroirs dans la ressource ImageContentSourcePolicy, procédez comme suit.

Conditions préalables

  • Install the OpenShift Container Platform CLI oc.
  • Connectez-vous en tant qu'utilisateur disposant des privilèges cluster-admin.
  • Configurez un catalogue d'images en miroir à utiliser dans votre cluster déconnecté.

Procédure

  1. Exécutez la commande suivante, en spécifiant des valeurs pour <local_registry>, <pull_spec>, et <pull_secret_file>: 

    $ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --icsp-scope=registry

    où :

    <local_registry>
    est le registre local que vous avez configuré pour votre cluster déconnecté, par exemple, local.registry:5000.
    <pull_spec>
    est la spécification de traction telle qu'elle est configurée dans votre registre déconnecté, par exemple, redhat/redhat-operator-index:v4.12
    <pull_secret_file>
    est le secret d'extraction de registry.redhat.io au format de fichier .json. Vous pouvez télécharger le pull secret depuis le Red Hat OpenShift Cluster Manager.

    La commande oc adm catalog mirror crée un répertoire /redhat-operator-index-manifests et génère des fichiers imageContentSourcePolicy.yaml, catalogSource.yaml et mapping.txt.

  2. Appliquer la nouvelle ressource ImageContentSourcePolicy au cluster : 

    $ oc apply -f imageContentSourcePolicy.yaml

Vérification

  • Vérifiez que oc apply a bien appliqué la modification à ImageContentSourcePolicy: 

    $ oc get ImageContentSourcePolicy -o yaml

    Exemple de sortie

    apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1alpha1
  kind: ImageContentSourcePolicy
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"operator.openshift.io/v1alpha1","kind":"ImageContentSourcePolicy","metadata":{"annotations":{},"name":"redhat-operator-index"},"spec":{"repositoryDigestMirrors":[{"mirrors":["local.registry:5000"],"source":"registry.redhat.io"}]}}
...

Après avoir mis à jour la ressource ImageContentSourcePolicy, OpenShift Container Platform déploie les nouveaux paramètres sur chaque nœud et le cluster commence à utiliser le référentiel miroir pour les requêtes vers le référentiel source.

12.4.6. Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.