8.2. 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
-
You installed the 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
Créez un projet appelé
hello-openshiften exécutant la commande suivante :$ oc new-project hello-openshiftCré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.jsonCréez un service appelé
hello-openshiften exécutant la commande suivante :$ oc expose pod/hello-openshiftCré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: sharded1 name: hello-openshift-edge namespace: hello-openshift spec: subdomain: hello-openshift2 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 champsubdomain, vous devez laisser le nom d'hôte non défini. Si vous spécifiez à la fois les champshostetsubdomain, l'itinéraire utilisera la valeur du champhostet ignorera le champsubdomain.
Utilisez
hello-openshift-route.yamlpour créer une route vers l'applicationhello-openshiften 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 yamlLa ressource
Routequi 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: sharded3 - 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
hostest 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.