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-openshift
en exécutant la commande suivante :$ oc new-project hello-openshift
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
Créez un service appelé
hello-openshift
en exécutant la commande suivante :$ oc expose pod/hello-openshift
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 champsubdomain
, vous devez laisser le nom d'hôte non défini. Si vous spécifiez à la fois les champshost
etsubdomain
, l'itinéraire utilisera la valeur du champhost
et ignorera le champsubdomain
.
Utilisez
hello-openshift-route.yaml
pour créer une route vers l'applicationhello-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
.