Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

6.4. Configuration du proxy

Dans le cas d’OpenShift Container Platform 4.1 et versions antérieures, vous devez configurer les proxies dans le manifeste de la ressource personnalisée (CR) MigrationController après avoir installé l’opérateur Migration Toolkit for Containers, car ces versions ne prennent pas en charge un objet proxy à l’échelle du cluster.

Pour OpenShift Container Platform 4.2 à 4.12, le Migration Toolkit for Containers (MTC) hérite des paramètres de proxy à l'échelle du cluster. Vous pouvez modifier les paramètres du proxy si vous souhaitez remplacer les paramètres du proxy à l'échelle du cluster.

6.4.1. Migration directe des volumes

La migration directe des volumes (DVM) a été introduite dans MTC 1.4.2. DVM ne prend en charge qu'un seul proxy. Le cluster source ne peut pas accéder à la route du cluster cible si ce dernier se trouve également derrière un proxy.

Si vous souhaitez effectuer un DVM à partir d'un cluster source situé derrière un proxy, vous devez configurer un proxy TCP qui fonctionne au niveau de la couche transport et transmet les connexions SSL de manière transparente sans les décrypter et les recrypter à l'aide de leurs propres certificats SSL. Un proxy Stunnel est un exemple de ce type de proxy.

6.4.1.1. Configuration du proxy TCP pour le DVM

Vous pouvez établir une connexion directe entre le cluster source et le cluster cible via un proxy TCP et configurer la variable stunnel_tcp_proxy dans le CR MigrationController pour utiliser le proxy :

Copy to Clipboard Toggle word wrap 
apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  stunnel_tcp_proxy: http://username:password@ip:port

La migration directe de volume (DVM) ne prend en charge que l'authentification de base pour le proxy. En outre, la DVM ne fonctionne que derrière des proxys qui peuvent tunneliser une connexion TCP de manière transparente. Les mandataires HTTP/HTTPS en mode man-in-the-middle ne fonctionnent pas. Les proxys existants à l'échelle du cluster peuvent ne pas prendre en charge ce comportement. Par conséquent, les paramètres du proxy pour DVM sont intentionnellement différents de la configuration habituelle du proxy dans MTC.

6.4.1.2. Pourquoi utiliser un proxy TCP plutôt qu'un proxy HTTP/HTTPS ?

Vous pouvez activer DVM en exécutant Rsync entre le cluster source et le cluster cible via une route OpenShift. Le trafic est chiffré à l'aide de Stunnel, un proxy TCP. Le Stunnel fonctionnant sur le cluster source initie une connexion TLS avec le Stunnel cible et transfère les données sur un canal crypté.

Les proxys HTTP/HTTPS à l'échelle du cluster dans OpenShift sont généralement configurés en mode man-in-the-middle où ils négocient leur propre session TLS avec les serveurs extérieurs. Cependant, cela ne fonctionne pas avec Stunnel. Stunnel exige que sa session TLS ne soit pas modifiée par le proxy, faisant essentiellement du proxy un tunnel transparent qui transmet simplement la connexion TCP telle quelle. Vous devez donc utiliser un proxy TCP.

6.4.1.3. Problème connu

La migration échoue avec l'erreur Upgrade request required

Le contrôleur de migration utilise le protocole SPDY pour exécuter des commandes dans des modules distants. Si le cluster distant se trouve derrière un proxy ou un pare-feu qui ne prend pas en charge le protocole SPDY, le contrôleur de migration ne parvient pas à exécuter les commandes à distance. La migration échoue avec le message d'erreur Upgrade request required. Solution : Utilisez un proxy qui prend en charge le protocole SPDY.

Outre la prise en charge du protocole SPDY, le proxy ou le pare-feu doit également transmettre l'en-tête HTTP Upgrade au serveur API. Le client utilise cet en-tête pour ouvrir une connexion websocket avec le serveur API. Si l'en-tête Upgrade est bloqué par le proxy ou le pare-feu, la migration échoue avec le message d'erreur Upgrade request required. Solution : Assurez-vous que le proxy transmet l'en-tête Upgrade.

6.4.2. Optimiser les politiques de réseau pour les migrations

OpenShift prend en charge la restriction du trafic vers ou depuis les pods à l'aide de NetworkPolicy ou EgressFirewalls en fonction du plugin réseau utilisé par le cluster. Si l'un des espaces de noms source impliqués dans une migration utilise de tels mécanismes pour restreindre le trafic réseau vers les pods, les restrictions peuvent par inadvertance arrêter le trafic vers les pods Rsync pendant la migration.

Les pods Rsync fonctionnant sur les clusters source et cible doivent se connecter l'un à l'autre via une route OpenShift. Les objets NetworkPolicy ou EgressNetworkPolicy existants peuvent être configurés pour exempter automatiquement les pods Rsync de ces restrictions de trafic.

6.4.2.1. Configuration de la politique de réseau

6.4.2.1.1. Trafic de sortie des pods Rsync

Vous pouvez utiliser les étiquettes uniques des modules Rsync pour autoriser le trafic sortant de ces modules si la configuration de NetworkPolicy dans les espaces de noms source ou destination bloque ce type de trafic. La stratégie suivante autorise le trafic de sortie all à partir des modules Rsync dans l'espace de noms :

Copy to Clipboard Toggle word wrap 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress-from-rsync-pods
spec:
  podSelector:
    matchLabels:
      owner: directvolumemigration
      app: directvolumemigration-rsync-transfer
  egress:
  - {}
  policyTypes:
  - Egress
6.4.2.1.2. Trafic entrant vers les pods Rsync
Copy to Clipboard Toggle word wrap 
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress-from-rsync-pods
spec:
  podSelector:
    matchLabels:
      owner: directvolumemigration
      app: directvolumemigration-rsync-transfer
  ingress:
  - {}
  policyTypes:
  - Ingress

6.4.2.2. Configuration de la politique de réseau EgressNetworkPolicy

L'objet EgressNetworkPolicy ou Egress Firewalls sont des constructions OpenShift conçues pour bloquer le trafic de sortie du cluster.

Contrairement à l'objet NetworkPolicy, le pare-feu Egress fonctionne au niveau du projet car il s'applique à tous les modules de l'espace de noms. Par conséquent, les étiquettes uniques des pods Rsync n'exemptent pas uniquement les pods Rsync des restrictions. Cependant, vous pouvez ajouter les plages CIDR du cluster source ou cible à la règle Allow de la politique afin qu'une connexion directe puisse être établie entre deux clusters.

En fonction du cluster dans lequel le pare-feu de sortie est présent, vous pouvez ajouter la plage CIDR de l'autre cluster pour autoriser le trafic de sortie entre les deux :

Copy to Clipboard Toggle word wrap 
apiVersion: network.openshift.io/v1
kind: EgressNetworkPolicy
metadata:
  name: test-egress-policy
  namespace: <namespace>
spec:
  egress:
  - to:
      cidrSelector: <cidr_of_source_or_target_cluster>
    type: Deny

6.4.2.3. Choix d'autres points d'arrivée pour le transfert de données

Par défaut, DVM utilise une route OpenShift Container Platform comme point final pour transférer les données PV vers les clusters de destination. Vous pouvez choisir un autre type de point d'extrémité pris en charge, si les topologies de cluster le permettent.

Pour chaque cluster, vous pouvez configurer un point de terminaison en définissant la variable rsync_endpoint_type sur le cluster destination approprié dans votre MigrationController CR :

Copy to Clipboard Toggle word wrap 
apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: migration-controller
  namespace: openshift-migration
spec:
  [...]
  rsync_endpoint_type: [NodePort|ClusterIP|Route]

6.4.2.4. Configuration de groupes supplémentaires pour les pods Rsync

Lorsque vos PVC utilisent un stockage partagé, vous pouvez configurer l'accès à ce stockage en ajoutant des groupes supplémentaires aux définitions de pods Rsync afin que les pods autorisent l'accès :

Tableau 6.2. Groupes supplémentaires pour les pods Rsync
VariableTypeDéfautDescription

src_supplemental_groups

chaîne de caractères

Non défini

Liste séparée par des virgules des groupes supplémentaires pour les pods Rsync source

target_supplemental_groups

chaîne de caractères

Non défini

Liste de groupes supplémentaires séparés par des virgules pour les pods Rsync cibles

Exemple d'utilisation

Le CR MigrationController peut être mis à jour pour définir les valeurs de ces groupes supplémentaires :

Copy to Clipboard Toggle word wrap 
spec:
  src_supplemental_groups: "1000,2000"
  target_supplemental_groups: "2000,3000"

6.4.3. Configuration des proxies

Conditions préalables

  • Vous devez être connecté en tant qu’utilisateur avec les privilèges cluster-admin sur tous les clusters.

Procédure

  1. Procurez-vous le manifeste du CR MigrationController :

    Copy to Clipboard Toggle word wrap 
    $ oc get migrationcontroller <migration_controller> -n openshift-migration

  2. Mettez à jour les paramètres du proxy :

    Copy to Clipboard Toggle word wrap 
    apiVersion: migration.openshift.io/v1alpha1
kind: MigrationController
metadata:
  name: <migration_controller>
  namespace: openshift-migration
...
spec:
  stunnel_tcp_proxy: http://<username>:<password>@<ip>:<port>
    1 
    
  noProxy: example.com
    2
    1
    URL du proxy Stunnel pour la migration directe des volumes.
    2
    Liste, séparée par des virgules, de noms de domaines de destination, de domaines, d’adresses IP ou d’autres CIDR de réseau à exclure de la mise en proxy.

    Faites précéder un domaine du signe . pour ne faire correspondre que les sous-domaines. Par exemple, .y.com correspond à x.y.com, mais pas à y.com. Utilisez * pour ignorer le proxy pour toutes les destinations. Si vous mettez à l’échelle des workers qui ne sont pas inclus dans le réseau défini par le champ networking.machineNetwork[].cidr à partir de la configuration d’installation, vous devez les ajouter à cette liste pour éviter les problèmes de connexion.

    Ce champ est ignoré si ni le champ httpProxy ni le champ httpsProxy ne sont définis.

  3. Enregistrez le manifeste en tant que migration-controller.yaml.

  4. Appliquez le manifeste mis à jour :

    Copy to Clipboard Toggle word wrap 
    $ oc replace -f migration-controller.yaml -n openshift-migration

Pour plus d'informations, voir Configuration du proxy pour l'ensemble du cluster.

Retour au début
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. Découvrez nos récentes mises à jour.

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 le Blog 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.

Theme

© 2025 Red Hat, Inc.