SupportConsoleDéveloppeursCommencer un essaiContact

27.3. Configuration du trafic d'entrée du cluster à l'aide d'un contrôleur d'entrée

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 un contrôleur d'entrée (Ingress Controller).

27.3.1. Utilisation de contrôleurs d'entrée et d'itinéraires

L'opérateur d'entrée gère les contrôleurs d'entrée et les DNS de type "wildcard".

L'utilisation d'un contrôleur d'ingestion est le moyen le plus courant d'autoriser l'accès externe à un cluster OpenShift Container Platform.

Un contrôleur d'entrée est configuré pour accepter les demandes externes et les transmettre par proxy sur la base des itinéraires configurés. Ceci est limité à HTTP, HTTPS utilisant SNI, et TLS utilisant SNI, ce qui est suffisant pour les applications et services web qui fonctionnent sur TLS avec SNI.

Travaillez avec votre administrateur pour configurer un contrôleur d'entrée qui acceptera les demandes externes et les transmettra par proxy en fonction des itinéraires configurés.

L'administrateur peut créer une entrée DNS générique et configurer ensuite un contrôleur d'entrée. Vous pouvez alors travailler avec le contrôleur d'entrée périphérique sans avoir à contacter les administrateurs.

Par défaut, chaque contrôleur d'entrée du cluster peut admettre n'importe quelle route créée dans n'importe quel projet du cluster.

Le contrôleur d'entrée :

  • Possède deux répliques par défaut, ce qui signifie qu'il doit être exécuté sur deux nœuds de travail.
  • Peut être étendu pour avoir plus de répliques sur plus de nœuds.
Note

Les procédures de cette section requièrent des conditions préalables effectuées par l'administrateur du cluster.

27.3.2. Conditions préalables

Avant de commencer les procédures suivantes, l'administrateur doit

  • Configurez le port externe de l'environnement réseau de la grappe pour que les demandes puissent atteindre la grappe.

  • Assurez-vous qu'il existe au moins un utilisateur ayant le rôle d'administrateur de cluster. Pour ajouter ce rôle à un utilisateur, exécutez la commande suivante : 

    $ oc adm policy add-cluster-role-to-user cluster-admin username
  • Disposer d'un cluster OpenShift Container Platform avec au moins un maître et au moins un nœud et un système extérieur au cluster qui a un accès réseau au cluster. Cette procédure suppose que le système externe se trouve sur le même sous-réseau que le cluster. La mise en réseau supplémentaire requise pour les systèmes externes sur un sous-réseau différent n'entre pas dans le cadre de cette rubrique.

27.3.3. Création d'un projet et d'un service

Si le projet et le service que vous souhaitez exposer n'existent pas, créez d'abord le projet, puis le service.

Si le projet et le service existent déjà, passez à la procédure d'exposition du service pour créer une route.

Conditions préalables

  • Installez le CLI oc et connectez-vous en tant qu'administrateur de cluster.

Procédure

  1. Créez un nouveau projet pour votre service en exécutant la commande oc new-project: 

    $ oc new-project myproject

  2. Utilisez la commande oc new-app pour créer votre service : 

    $ oc new-app nodejs:12~https://github.com/sclorg/nodejs-ex.git

  3. Pour vérifier que le service a été créé, exécutez la commande suivante : 

    $ oc get svc -n myproject

    Exemple de sortie

    NAME        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
nodejs-ex   ClusterIP   172.30.197.157   <none>        8080/TCP   70s

    Par défaut, le nouveau service n'a pas d'adresse IP externe.

27.3.4. Exposer le service en créant une route

Vous pouvez exposer le service en tant que route en utilisant la commande oc expose.

Procédure

Pour exposer le service :

  1. Connectez-vous à OpenShift Container Platform.

  2. Connectez-vous au projet dans lequel se trouve le service que vous souhaitez exposer : 

    $ oc project myproject

  3. Exécutez la commande oc expose service pour exposer la route : 

    $ oc expose service nodejs-ex

    Exemple de sortie

    route.route.openshift.io/nodejs-ex exposed

  4. Pour vérifier que le service est exposé, vous pouvez utiliser un outil, tel que cURL, pour vous assurer que le service est accessible depuis l'extérieur du cluster.

    1. Utilisez la commande oc get route pour trouver le nom d'hôte de la route : 

      $ oc get route

      Exemple de sortie

      NAME        HOST/PORT                        PATH   SERVICES    PORT       TERMINATION   WILDCARD
nodejs-ex   nodejs-ex-myproject.example.com         nodejs-ex   8080-tcp                 None

    2. Utilisez cURL pour vérifier que l'hôte répond à une requête GET : 

      $ curl --head nodejs-ex-myproject.example.com

      Exemple de sortie

      HTTP/1.1 200 OK
...

27.3.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 27.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

27.3.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 27.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

27.3.7. Création d'une route pour le sharding du contrôleur d'entrée

Une route vous permet d'héberger votre application à une URL. Dans ce cas, le nom d'hôte n'est pas défini et la route utilise un sous-domaine à la place. Lorsque vous spécifiez un sous-domaine, vous utilisez automatiquement le domaine du contrôleur d'entrée qui expose l'itinéraire. Lorsqu'un itinéraire est exposé par plusieurs contrôleurs d'ingestion, l'itinéraire est hébergé sur plusieurs URL.

La procédure suivante décrit comment créer une route pour le sharding du contrôleur d'entrée, en utilisant l'application hello-openshift comme exemple.

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.

Conditions préalables

  • Vous avez installé l'OpenShift CLI (oc).
  • Vous êtes connecté en tant qu'administrateur de projet.
  • Vous avez une application web qui expose un port et un point d'extrémité HTTP ou TLS qui écoute le trafic sur le port.
  • Vous avez configuré le contrôleur d'entrée pour le partage.

Procédure

  1. Créez un projet appelé hello-openshift en exécutant la commande suivante : 

    $ oc new-project hello-openshift

  2. Créez un pod dans le projet en exécutant la commande suivante : 

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json

  3. Créez un service appelé hello-openshift en exécutant la commande suivante : 

    $ oc expose pod/hello-openshift

  4. Créez une définition de route appelée hello-openshift-route.yaml:

    Définition YAML de la route créée pour le sharding :

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded 1
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift 2
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift

    1
    La clé d'étiquette et la valeur d'étiquette correspondante doivent toutes deux correspondre à celles spécifiées dans le contrôleur d'entrée. Dans cet exemple, le contrôleur d'entrée a la clé et la valeur d'étiquette type: sharded.
    2
    La route sera exposée en utilisant la valeur du champ subdomain. Lorsque vous spécifiez le champ subdomain, vous devez laisser le nom d'hôte non défini. Si vous spécifiez à la fois les champs host et subdomain, l'itinéraire utilisera la valeur du champ host et ignorera le champ subdomain.

  5. Utilisez hello-openshift-route.yaml pour créer une route vers l'application hello-openshift en exécutant la commande suivante : 

    $ oc -n hello-openshift create -f hello-openshift-route.yaml

Vérification

  • Obtenez l'état de la route à l'aide de la commande suivante : 

    $ oc -n hello-openshift get routes/hello-openshift-edge -o yaml

    La ressource Route qui en résulte devrait ressembler à ce qui suit :

    Exemple de sortie

    apiVersion: route.openshift.io/v1
kind: Route
metadata:
  labels:
    type: sharded
  name: hello-openshift-edge
  namespace: hello-openshift
spec:
  subdomain: hello-openshift
  tls:
    termination: edge
  to:
    kind: Service
    name: hello-openshift
status:
  ingress:
  - host: hello-openshift.<apps-sharded.basedomain.example.net> 1
    routerCanonicalHostname: router-sharded.<apps-sharded.basedomain.example.net> 2
    routerName: sharded 3

    1
    Le nom d'hôte que le contrôleur d'entrée, ou le routeur, utilise pour exposer l'itinéraire. La valeur du champ host est automatiquement déterminée par le contrôleur d'entrée et utilise son domaine. Dans cet exemple, le domaine du contrôleur d'entrée est <apps-sharded.basedomain.example.net>.
    2
    Le nom d'hôte du contrôleur d'entrée.
    3
    Le nom du contrôleur d'entrée. Dans cet exemple, le contrôleur d'entrée porte le nom sharded.

27.3.8. Ressources supplémentaires

L'opérateur d'entrée gère les DNS de type "wildcard". Pour plus d'informations, voir ce qui suit :

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.