27.5. Configuration du trafic d'entrée des clusters sur AWS


OpenShift Container Platform fournit des méthodes pour communiquer depuis l'extérieur du cluster avec les services s'exécutant dans le cluster. Cette méthode utilise des répartiteurs de charge sur AWS, en particulier un répartiteur de charge réseau (NLB) ou un répartiteur de charge classique (CLB). Les deux types d'équilibreurs de charge peuvent transmettre l'adresse IP du client au nœud, mais un CLB nécessite la prise en charge du protocole proxy, qu'OpenShift Container Platform active automatiquement.

Il existe deux façons de configurer un contrôleur d'entrée pour qu'il utilise un NLB :

  1. En remplaçant de force le contrôleur d'entrée qui utilise actuellement un CLB. Cette opération supprime l'objet IngressController et une panne se produira pendant que les nouveaux enregistrements DNS se propagent et que le NLB est approvisionné.
  2. En modifiant un contrôleur d'entrée existant qui utilise un CLB pour utiliser un NLB. Cela permet de modifier l'équilibreur de charge sans avoir à supprimer et à recréer l'objet IngressController.

Les deux méthodes peuvent être utilisées pour passer d'un NLB à un CLB.

Vous pouvez configurer ces équilibreurs de charge sur un cluster AWS nouveau ou existant.

27.5.1. Configuration des délais d'attente de l'équilibreur de charge classique sur AWS

OpenShift Container Platform fournit une méthode pour définir un délai d'attente personnalisé pour une route ou un contrôleur d'entrée spécifique. En outre, un AWS Classic Load Balancer (CLB) dispose de son propre délai d'attente, dont la durée par défaut est de 60 secondes.

Si le délai d'attente du CLB est plus court que le délai d'attente de l'itinéraire ou le délai d'attente du contrôleur d'entrée, l'équilibreur de charge peut mettre fin prématurément à la connexion. Vous pouvez éviter ce problème en augmentant le délai d'expiration de l'itinéraire et du CLB.

27.5.1.1. Configuration des délais d'attente pour les itinéraires

Vous pouvez configurer les délais d'attente par défaut pour une route existante lorsque vous avez des services qui ont besoin d'un délai d'attente faible, qui est nécessaire pour la disponibilité du niveau de service (SLA), ou d'un délai d'attente élevé, pour les cas où le back-end est lent.

Conditions préalables

  • Vous avez besoin d'un contrôleur d'ingestion déployé sur un cluster en cours d'exécution.

Procédure

  1. À l'aide de la commande oc annotate, ajoutez le délai d'attente à l'itinéraire :

    $ oc annotate route <route_name> \
        --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> 1
    1
    Les unités de temps prises en charge sont les microsecondes (us), les millisecondes (ms), les secondes (s), les minutes (m), les heures (h) ou les jours (d).

    L'exemple suivant définit un délai d'attente de deux secondes sur une route nommée myroute:

    $ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s

27.5.1.2. Configuration des délais d'attente de l'équilibreur de charge classique

Vous pouvez configurer les délais par défaut d'un équilibreur de charge classique (CLB) pour prolonger les connexions inactives.

Conditions préalables

  • Vous devez disposer d'un contrôleur d'ingestion déployé sur un cluster en cours d'exécution.

Procédure

  1. Définissez un délai d'inactivité de connexion AWS de cinq minutes pour la valeur par défaut ingresscontroller en exécutant la commande suivante :

    $ oc -n openshift-ingress-operator patch ingresscontroller/default \
        --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
        {"type":"LoadBalancerService", "loadBalancer": \
        {"scope":"External", "providerParameters":{"type":"AWS", "aws": \
        {"type":"Classic", "classicLoadBalancer": \
        {"connectionIdleTimeout":"5m"}}}}}}}'
  2. Facultatif : Rétablissez la valeur par défaut du délai d'attente en exécutant la commande suivante :

    $ oc -n openshift-ingress-operator patch ingresscontroller/default \
        --type=merge --patch='{"spec":{"endpointPublishingStrategy": \
        {"loadBalancer":{"providerParameters":{"aws":{"classicLoadBalancer": \
        {"connectionIdleTimeout":null}}}}}}}'
Note

Vous devez spécifier le champ scope lorsque vous modifiez la valeur du délai de connexion, sauf si l'étendue actuelle est déjà définie. Lorsque vous définissez le champ scope, il n'est pas nécessaire de le faire à nouveau si vous rétablissez la valeur par défaut du délai d'attente.

27.5.2. Configuration du trafic d'entrée des clusters sur AWS à l'aide d'un équilibreur de charge réseau

OpenShift Container Platform fournit des méthodes pour communiquer depuis l'extérieur du cluster avec les services qui s'exécutent dans le cluster. L'une de ces méthodes utilise un équilibreur de charge réseau (NLB). Vous pouvez configurer un NLB sur un cluster AWS nouveau ou existant.

27.5.2.1. Passage du contrôleur d'entrée d'un équilibreur de charge classique à un équilibreur de charge réseau

Vous pouvez remplacer le contrôleur d'entrée qui utilise un équilibreur de charge classique (CLB) par un équilibreur de charge réseau (NLB) sur AWS.

Le passage d'un équilibreur de charge à l'autre ne supprime pas l'objet IngressController.

Avertissement

Cette procédure peut entraîner les problèmes suivants :

  • Une panne qui peut durer plusieurs minutes en raison de la propagation de nouveaux enregistrements DNS, du provisionnement de nouveaux équilibreurs de charge et d'autres facteurs. Les adresses IP et les noms canoniques de l'équilibreur de charge du contrôleur d'entrée peuvent changer après l'application de cette procédure.
  • Fuite de ressources de l'équilibreur de charge en raison d'un changement dans l'annotation du service.

Procédure

  1. Modifiez le contrôleur d'entrée existant pour lequel vous souhaitez passer à l'utilisation d'un NLB. Cet exemple suppose que votre contrôleur d'entrée par défaut dispose d'une portée External et d'aucune autre personnalisation :

    Exemple de fichier ingresscontroller.yaml

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
        type: LoadBalancerService

    Note

    Si vous ne spécifiez pas de valeur pour le champ spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.type, le contrôleur d'entrée utilise la valeur spec.loadBalancer.platform.aws.type de la configuration du cluster Ingress définie lors de l'installation.

    Astuce

    Si votre contrôleur d'ingestion comporte d'autres personnalisations que vous souhaitez mettre à jour, telles que la modification du domaine, envisagez plutôt de remplacer de force le fichier de définition du contrôleur d'ingestion.

  2. Appliquez les modifications au fichier YAML du contrôleur d'entrée en exécutant la commande :

    $ oc apply -f ingresscontroller.yaml

    Il faut s'attendre à des interruptions de plusieurs minutes pendant la mise à jour du contrôleur d'entrée.

27.5.2.2. Passage du contrôleur d'entrée d'un équilibreur de charge réseau à un équilibreur de charge classique

Vous pouvez remplacer le contrôleur d'entrée qui utilise un équilibreur de charge réseau (NLB) par un équilibreur de charge classique (CLB) sur AWS.

Le passage d'un équilibreur de charge à l'autre ne supprime pas l'objet IngressController.

Avertissement

Cette procédure peut provoquer une panne qui peut durer plusieurs minutes en raison de la propagation de nouveaux enregistrements DNS, du provisionnement de nouveaux équilibreurs de charge et d'autres facteurs. Les adresses IP et les noms canoniques de l'équilibreur de charge du contrôleur d'entrée peuvent changer après l'application de cette procédure.

Procédure

  1. Modifiez le contrôleur d'entrée existant pour lequel vous souhaitez passer à l'utilisation d'un CLB. Cet exemple suppose que votre contrôleur d'entrée par défaut dispose d'une portée External et d'aucune autre personnalisation :

    Exemple de fichier ingresscontroller.yaml

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: Classic
        type: LoadBalancerService

    Note

    Si vous ne spécifiez pas de valeur pour le champ spec.endpointPublishingStrategy.loadBalancer.providerParameters.aws.type, le contrôleur d'entrée utilise la valeur spec.loadBalancer.platform.aws.type de la configuration du cluster Ingress définie lors de l'installation.

    Astuce

    Si votre contrôleur d'ingestion comporte d'autres personnalisations que vous souhaitez mettre à jour, telles que la modification du domaine, envisagez plutôt de remplacer de force le fichier de définition du contrôleur d'ingestion.

  2. Appliquez les modifications au fichier YAML du contrôleur d'entrée en exécutant la commande :

    $ oc apply -f ingresscontroller.yaml

    Il faut s'attendre à des interruptions de plusieurs minutes pendant la mise à jour du contrôleur d'entrée.

27.5.2.3. Remplacement du contrôleur d'entrée, de l'équilibreur de charge classique par un équilibreur de charge réseau

Vous pouvez remplacer un contrôleur d'entrée qui utilise un équilibreur de charge classique (CLB) par un contrôleur qui utilise un équilibreur de charge réseau (NLB) sur AWS.

Avertissement

Cette procédure peut entraîner les problèmes suivants :

  • Une panne qui peut durer plusieurs minutes en raison de la propagation de nouveaux enregistrements DNS, du provisionnement de nouveaux équilibreurs de charge et d'autres facteurs. Les adresses IP et les noms canoniques de l'équilibreur de charge du contrôleur d'entrée peuvent changer après l'application de cette procédure.
  • Fuite de ressources de l'équilibreur de charge en raison d'un changement dans l'annotation du service.

Procédure

  1. Créez un fichier avec un nouveau contrôleur d'ingérence par défaut. L'exemple suivant suppose que votre contrôleur d'entrée par défaut possède une portée External et aucune autre personnalisation :

    Exemple de fichier ingresscontroller.yml

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
        type: LoadBalancerService

    Si votre contrôleur d'ingestion par défaut présente d'autres personnalisations, veillez à modifier le fichier en conséquence.

    Astuce

    Si votre contrôleur d'entrée n'a pas d'autres personnalisations et que vous ne mettez à jour que le type d'équilibreur de charge, envisagez de suivre la procédure décrite dans le document " Switching the Ingress Controller from using a Classic Load Balancer to a Network Load Balancer " (Passage du contrôleur d'entrée d'un équilibreur de charge classique à un équilibreur de charge réseau).

  2. Forcez le remplacement du fichier YAML du contrôleur d'entrée :

    $ oc replace --force --wait -f ingresscontroller.yml

    Attendez que le contrôleur d'entrée soit remplacé. Attendez-vous à plusieurs minutes d'interruption.

27.5.2.4. Configuration d'un contrôleur d'entrée Network Load Balancer sur un cluster AWS existant

Vous pouvez créer un contrôleur d'entrée soutenu par un équilibreur de charge réseau AWS (NLB) sur un cluster existant.

Conditions préalables

  • Un cluster AWS doit être installé.
  • PlatformStatus de la ressource d'infrastructure doit être AWS.

    • Pour vérifier que le site PlatformStatus est bien AWS, exécutez la commande :

      $ oc get infrastructure/cluster -o jsonpath='{.status.platformStatus.type}'
      AWS

Procédure

Créer un contrôleur d'entrée soutenu par AWS NLB sur un cluster existant.

  1. Créer le manifeste du contrôleur d'entrée :

     $ cat ingresscontroller-aws-nlb.yaml

    Exemple de sortie

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: $my_ingress_controller1
      namespace: openshift-ingress-operator
    spec:
      domain: $my_unique_ingress_domain2
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: External3
          providerParameters:
            type: AWS
            aws:
              type: NLB

    1
    Remplacez $my_ingress_controller par un nom unique pour le contrôleur d'entrée.
    2
    Remplacez $my_unique_ingress_domain par un nom de domaine unique pour tous les contrôleurs d'entrée du cluster. Cette variable doit être un sous-domaine du nom DNS <clustername>.<domain>.
    3
    Vous pouvez remplacer External par Internal pour utiliser un NLB interne.
  2. Créer la ressource dans le cluster :

    $ oc create -f ingresscontroller-aws-nlb.yaml
Important

Avant de pouvoir configurer un contrôleur d'entrée NLB sur un nouveau cluster AWS, vous devez suivre la procédure de création du fichier de configuration de l'installation.

27.5.2.5. Configuring an Ingress Controller Network Load Balancer on a new AWS cluster

You can create an Ingress Controller backed by an AWS Network Load Balancer (NLB) on a new cluster.

Conditions préalables

  • Créer le fichier install-config.yaml et y apporter les modifications nécessaires.

Procédure

Create an Ingress Controller backed by an AWS NLB on a new cluster.

  1. Change to the directory that contains the installation program and create the manifests:

    ./openshift-install create manifests --dir <installation_directory> $ ./openshift-install create manifests --dir <installation_directory> 1
    1
    Pour <installation_directory>, indiquez le nom du répertoire qui contient le fichier install-config.yaml pour votre cluster.
  2. Créez un fichier nommé cluster-ingress-default-ingresscontroller.yaml dans le répertoire <installation_directory>/manifests/:

    touch <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml 1
    1
    Pour <installation_directory>, indiquez le nom du répertoire qui contient le répertoire manifests/ de votre cluster.

    Après la création du fichier, plusieurs fichiers de configuration du réseau se trouvent dans le répertoire manifests/, comme indiqué :

    $ ls <installation_directory>/manifests/cluster-ingress-default-ingresscontroller.yaml

    Exemple de sortie

    cluster-ingress-default-ingresscontroller.yaml

  3. Ouvrez le fichier cluster-ingress-default-ingresscontroller.yaml dans un éditeur et saisissez une ressource personnalisée (CR) qui décrit la configuration de l'opérateur que vous souhaitez :

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      creationTimestamp: null
      name: default
      namespace: openshift-ingress-operator
    spec:
      endpointPublishingStrategy:
        loadBalancer:
          scope: External
          providerParameters:
            type: AWS
            aws:
              type: NLB
        type: LoadBalancerService
  4. Enregistrez le fichier cluster-ingress-default-ingresscontroller.yaml et quittez l'éditeur de texte.
  5. Facultatif : Sauvegardez le fichier manifests/cluster-ingress-default-ingresscontroller.yaml. Le programme d'installation supprime le répertoire manifests/ lors de la création du cluster.

27.5.3. 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.