SupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 8. Ingress sharding dans OpenShift Container Platform

Dans OpenShift Container Platform, un Ingress Controller peut servir toutes les routes ou un sous-ensemble de routes. Par défaut, le contrôleur d'ingestion sert toutes les routes créées dans n'importe quel espace de noms du cluster. Vous pouvez ajouter des contrôleurs d'entrée supplémentaires à votre cluster pour optimiser le routage en créant shards, qui sont des sous-ensembles d'itinéraires basés sur des caractéristiques sélectionnées. Pour marquer un itinéraire comme membre d'une grappe, utilisez des étiquettes dans le champ de l'itinéraire ou de l'espace de noms metadata. Le contrôleur d'entrée utilise selectors, également connu sous le nom de selection expression, pour sélectionner un sous-ensemble d'itinéraires à partir de l'ensemble des itinéraires à desservir.

La répartition des entrées est utile lorsque vous souhaitez équilibrer la charge du trafic entrant entre plusieurs contrôleurs d'entrée, lorsque vous souhaitez isoler le trafic à acheminer vers un contrôleur d'entrée spécifique, ou pour toute une série d'autres raisons décrites dans la section suivante.

Par défaut, chaque route utilise le domaine par défaut du cluster. Toutefois, les itinéraires peuvent être configurés pour utiliser le domaine du routeur à la place. Pour plus d'informations, voir Création d'un itinéraire pour le sharding de contrôleur d'entrée.

8.1. Regroupement des contrôleurs d'entrée

Vous pouvez utiliser le partage d'entrée, également connu sous le nom de partage de routeur, pour distribuer un ensemble d'itinéraires sur plusieurs routeurs en ajoutant des étiquettes aux itinéraires, aux espaces de noms ou aux deux. Le contrôleur d'entrée utilise un ensemble correspondant de sélecteurs pour n'admettre que les itinéraires dotés d'une étiquette spécifique. Chaque groupe d'entrée comprend les itinéraires filtrés à l'aide d'une expression de sélection donnée.

En tant que principal mécanisme d'entrée du trafic dans la grappe, le contrôleur d'entrée peut être fortement sollicité. En tant qu'administrateur de la grappe, vous pouvez répartir les routes pour :

  • Équilibrer les contrôleurs d'entrée, ou routeurs, avec plusieurs itinéraires pour accélérer les réponses aux changements.
  • Attribuer à certains itinéraires des garanties de fiabilité différentes de celles des autres itinéraires.
  • Permettre à certains contrôleurs d'entrée de définir des politiques différentes.
  • Ne permettre qu'à des itinéraires spécifiques d'utiliser des fonctionnalités supplémentaires.
  • Exposer des itinéraires différents sur des adresses différentes afin que les utilisateurs internes et externes puissent voir des itinéraires différents, par exemple.
  • Transférer le trafic d'une version d'une application à une autre lors d'un déploiement bleu-vert.

Lorsque les contrôleurs d'entrée sont groupés, une route donnée est admise par zéro ou plusieurs contrôleurs d'entrée du groupe. L'état d'une route indique si un contrôleur d'entrée l'a admise ou non. Un contrôleur d'entrée n'admettra une route que si elle est unique à son groupe.

Un contrôleur d'entrée peut utiliser trois méthodes de répartition :

  • Ajout d'un sélecteur d'espace de noms au contrôleur d'ingestion, de sorte que tous les itinéraires d'un espace de noms dont les étiquettes correspondent au sélecteur d'espace de noms se trouvent dans la grappe d'ingestion.
  • Ajout d'un sélecteur d'itinéraires au contrôleur d'entrée, de sorte que tous les itinéraires dont les étiquettes correspondent au sélecteur d'itinéraires se trouvent dans le groupe d'entrée.
  • Ajout d'un sélecteur d'espace de noms et d'un sélecteur d'itinéraires au contrôleur d'ingestion, de sorte que les itinéraires dont les étiquettes correspondent au sélecteur d'itinéraires dans un espace de noms dont les étiquettes correspondent au sélecteur d'espace de noms se trouvent dans la grappe d'ingestion.

Avec la répartition, vous pouvez distribuer des sous-ensembles d'itinéraires sur plusieurs contrôleurs d'entrée. Ces sous-ensembles peuvent ne pas se chevaucher ( traditional sharding) ou se chevaucher ( overlapped sharding).

8.1.1. Exemple de partage traditionnel

Un contrôleur d'entrée finops-router est configuré avec le sélecteur d'étiquettes spec.namespaceSelector.matchLabels.name réglé sur finance et ops:

Exemple de définition YAML pour finops-router

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: finops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - finance
          - ops

Un deuxième contrôleur d'entrée dev-router est configuré avec le sélecteur d'étiquettes spec.namespaceSelector.matchLabels.name réglé sur dev:

Exemple de définition YAML pour dev-router

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: dev-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name: dev

Si toutes les routes d'application sont dans des espaces de noms séparés, chacun étiqueté avec name:finance, name:ops, et name:dev respectivement, cette configuration distribue efficacement vos routes entre les deux contrôleurs d'entrée. Les routes de OpenShift Container Platform pour la console, l'authentification et d'autres objectifs ne doivent pas être gérées.

Dans le scénario ci-dessus, la répartition devient un cas particulier de partitionnement, sans que les sous-ensembles ne se chevauchent. Les routes sont réparties entre les routeurs.

Avertissement

Le contrôleur d'entrée default continue à servir toutes les routes à moins que les champs namespaceSelector ou routeSelector ne contiennent des routes à exclure. Consultez cette solution de la base de connaissances de Red Hat et la section "Sharding the default Ingress Controller" pour plus d'informations sur la manière d'exclure les itinéraires du contrôleur d'entrée par défaut.

8.1.2. Exemple de partage superposé

Outre finops-router et dev-router dans l'exemple ci-dessus, vous avez également devops-router, qui est configuré avec le sélecteur d'étiquettes spec.namespaceSelector.matchLabels.name défini sur dev et ops:

Exemple de définition YAML pour devops-router

apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: devops-router
    namespace: openshift-ingress-operator
  spec:
    namespaceSelector:
      matchLabels:
        name:
          - dev
          - ops

Les routes des espaces de noms intitulés name:dev et name:ops sont maintenant gérées par deux contrôleurs d'entrée différents. Avec cette configuration, les sous-ensembles d'itinéraires se chevauchent.

Le chevauchement de sous-ensembles d'itinéraires permet de créer des règles de routage plus complexes. Par exemple, vous pouvez détourner le trafic hautement prioritaire vers le site dédié finops-router tout en envoyant le trafic moins prioritaire vers devops-router.

8.1.3. Partage du contrôleur d'entrée par défaut

Après la création d'un nouveau shard d'ingestion, il se peut que des routes admises dans votre nouveau shard d'ingestion soient également admises par le contrôleur d'ingestion par défaut. En effet, le contrôleur d'entrée par défaut n'a pas de sélecteurs et admet tous les itinéraires par défaut.

Vous pouvez empêcher un contrôleur d'entrée de desservir des itinéraires avec des étiquettes spécifiques à l'aide de sélecteurs d'espace de noms ou de sélecteurs d'itinéraires. La procédure suivante empêche le contrôleur d'entrée par défaut de desservir les itinéraires finance, ops et dev, nouvellement partagés, à l'aide d'un sélecteur d'espace de noms. Cette procédure permet d'isoler davantage les groupes de serveurs d'entrée.

Important

Vous devez conserver toutes les routes d'administration d'OpenShift Container Platform sur le même Ingress Controller. Par conséquent, évitez d'ajouter des sélecteurs supplémentaires au contrôleur d'ingestion par défaut qui excluent ces routes essentielles.

Conditions préalables

  • You installed the OpenShift CLI (oc).
  • Vous êtes connecté en tant qu'administrateur de projet.

Procédure

  1. Modifiez le contrôleur d'entrée par défaut en exécutant la commande suivante : 

    $ oc edit ingresscontroller -n openshift-ingress-operator default

  2. Modifiez le contrôleur d'entrée pour qu'il contienne une adresse namespaceSelector qui exclut les itinéraires portant l'une des étiquettes finance, ops et dev: 

    apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
  namespaceSelector:
    matchExpressions:
    - key: type
      operator: NotIn
      values:
      - finance
      - ops
      - dev

Le contrôleur d'entrée par défaut ne desservira plus les espaces de noms intitulés name:finance, name:ops, et name:dev.

8.1.4. Sharding d'entrée et DNS

L'administrateur de la grappe est chargé de créer une entrée DNS distincte pour chaque routeur d'un projet. Un routeur ne transmettra pas de routes inconnues à un autre routeur.

Prenons l'exemple suivant :

  • Le routeur A se trouve sur l'hôte 192.168.0.5 et a des routes avec *.foo.com.
  • Le routeur B se trouve sur l'hôte 192.168.1.9 et a des routes avec *.example.com.

Des entrées DNS séparées doivent résoudre *.foo.com en nœud hébergeant le routeur A et *.example.com en nœud hébergeant le routeur B :

  • *.foo.com A IN 192.168.0.5
  • *.example.com A IN 192.168.1.9

8.1.5. Configuration de la répartition des contrôleurs d'entrée à l'aide d'étiquettes d'itinéraires

La répartition du contrôleur d'entrée à l'aide d'étiquettes d'itinéraires signifie que le contrôleur d'entrée dessert n'importe quel itinéraire dans n'importe quel espace de noms sélectionné par le sélecteur d'itinéraires.

Figure 8.1. Répartition des entrées à l'aide d'étiquettes d'itinéraires

A diagram showing multiple Ingress Controllers with different route selectors serving any route containing a label that matches a given route selector regardless of the namespace a route belongs to

La répartition des contrôleurs d'entrée est utile pour équilibrer la charge du trafic entrant entre un ensemble de contrôleurs d'entrée et pour isoler le trafic vers un contrôleur d'entrée spécifique. Par exemple, l'entreprise A s'adresse à un contrôleur d'entrée et l'entreprise B à un autre.

Procédure

  1. Modifiez le fichier router-internal.yaml: 

    # cat router-internal.yaml
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: sharded
    namespace: openshift-ingress-operator
  spec:
    domain: <apps-sharded.basedomain.example.net> 1
    nodePlacement:
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker: ""
    routeSelector:
      matchLabels:
        type: sharded
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
    1
    Indiquez un domaine à utiliser par le contrôleur d'entrée. Ce domaine doit être différent du domaine par défaut du contrôleur d'entrée.

  2. Appliquer le fichier du contrôleur d'entrée router-internal.yaml: 

    # oc apply -f router-internal.yaml

    Le contrôleur d'entrée sélectionne les routes dans n'importe quel espace de noms qui ont l'étiquette type: sharded.

  3. Créez une nouvelle route en utilisant le domaine configuré dans le site router-internal.yaml: 

    oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net

8.1.6. Configuration de la répartition des contrôleurs d'entrée à l'aide d'étiquettes d'espace de noms

La répartition du contrôleur d'entrée à l'aide d'étiquettes d'espace de noms signifie que le contrôleur d'entrée dessert n'importe quelle route dans n'importe quel espace de noms sélectionné par le sélecteur d'espace de noms.

Figure 8.2. La mise en commun à l'entrée à l'aide d'étiquettes d'espace de noms

A diagram showing multiple Ingress Controllers with different namespace selectors serving routes that belong to the namespace containing a label that matches a given namespace selector

La répartition des contrôleurs d'entrée est utile pour équilibrer la charge du trafic entrant entre un ensemble de contrôleurs d'entrée et pour isoler le trafic vers un contrôleur d'entrée spécifique. Par exemple, l'entreprise A s'adresse à un contrôleur d'entrée et l'entreprise B à un autre.

Procédure

  1. Modifiez le fichier router-internal.yaml: 

    # cat router-internal.yaml

    Exemple de sortie

    apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: sharded
    namespace: openshift-ingress-operator
  spec:
    domain: <apps-sharded.basedomain.example.net> 1
    nodePlacement:
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker: ""
    namespaceSelector:
      matchLabels:
        type: sharded
  status: {}
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

    1
    Indiquez un domaine à utiliser par le contrôleur d'entrée. Ce domaine doit être différent du domaine par défaut du contrôleur d'entrée.

  2. Appliquer le fichier du contrôleur d'entrée router-internal.yaml: 

    # oc apply -f router-internal.yaml

    Le contrôleur d'entrée sélectionne les itinéraires dans tout espace de noms sélectionné par le sélecteur d'espace de noms et portant l'étiquette type: sharded.

  3. Créez une nouvelle route en utilisant le domaine configuré dans le site router-internal.yaml: 

    oc expose svc <service-name> --hostname <route-name>.apps-sharded.basedomain.example.net
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.