8.9. Optimisation de l'acheminement

Le contrôleur d'entrée de la plateforme OpenShift Container, ou routeur, est le point d'entrée du trafic d'entrée pour les applications et les services qui sont configurés à l'aide de routes et d'entrées.

Lorsque l'on évalue les performances d'un routeur HAProxy unique en termes de requêtes HTTP traitées par seconde, les performances varient en fonction de nombreux facteurs. En particulier :

Bien que les performances dans votre environnement spécifique varient, les tests du laboratoire Red Hat sur une instance de cloud public de taille 4 vCPU/16GB RAM. Un routeur HAProxy unique gérant 100 routes terminées par des backends servant des pages statiques de 1kB est capable de gérer le nombre suivant de transactions par seconde.

Dans les scénarios du mode "keep-alive" de HTTP :

Dans les scénarios de fermeture HTTP (pas de keep-alive) :

La configuration par défaut du contrôleur d'entrée a été utilisée avec le champ spec.tuningOptions.threadCount défini sur 4. Deux stratégies différentes de publication des points finaux ont été testées : Load Balancer Service et Host Network. La reprise de session TLS a été utilisée pour les itinéraires cryptés. Avec HTTP keep-alive, un seul routeur HAProxy est capable de saturer un NIC de 1 Gbit avec des pages d'une taille aussi petite que 8 kB.

Lorsque le système est exécuté sur du métal nu avec des processeurs modernes, vous pouvez vous attendre à des performances environ deux fois supérieures à celles de l'instance de nuage public ci-dessus. Cette surcharge est introduite par la couche de virtualisation en place sur les nuages publics et s'applique également à la virtualisation basée sur les nuages privés. Le tableau suivant indique le nombre d'applications à utiliser derrière le routeur :

En général, HAProxy peut prendre en charge des routes pour un maximum de 1 000 applications, en fonction de la technologie utilisée. Les performances du contrôleur d'entrée peuvent être limitées par les capacités et les performances des applications qui se trouvent derrière lui, comme la langue ou le contenu statique par rapport au contenu dynamique.

La mise en commun des entrées, ou routeurs, devrait être utilisée pour servir davantage de routes vers les applications et contribuer à la mise à l'échelle horizontale du niveau de routage.

Les administrateurs de cluster peuvent configurer les valeurs de délai d'attente pour les sondes de disponibilité, de préparation et de démarrage du kubelet pour les déploiements de routeurs qui sont gérés par le contrôleur d'entrée de la plateforme OpenShift Container (routeur). Les sondes de disponibilité et de préparation du routeur utilisent la valeur de temporisation par défaut de 1 seconde, qui est trop courte lorsque les performances du réseau ou de l'exécution sont gravement dégradées. Les délais d'attente des sondes peuvent entraîner des redémarrages intempestifs du routeur qui interrompent les connexions des applications. La possibilité de définir des valeurs de délai plus importantes peut réduire le risque de redémarrages inutiles et non désirés.

Vous pouvez mettre à jour la valeur timeoutSeconds dans les paramètres livenessProbe, readinessProbe et startupProbe du conteneur de routeur.

L'exemple suivant montre comment vous pouvez corriger directement le déploiement du routeur par défaut pour définir un délai d'attente de 5 secondes pour les sondes de disponibilité et d'état de préparation :

$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'

$ oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
    Liveness:   http-get http://:1936/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:1936/healthz/ready delay=0s timeout=5s period=10s #success=1 #failure=3

Lorsque vous mettez à jour une route ou un point d'extrémité associé à une route, le routeur OpenShift Container Platform met à jour la configuration de HAProxy. Ensuite, HAProxy recharge la configuration mise à jour pour que ces modifications prennent effet. Lorsque HAProxy se recharge, il génère un nouveau processus qui gère les nouvelles connexions à l'aide de la configuration mise à jour.

HAProxy maintient l'ancien processus en cours d'exécution pour gérer les connexions existantes jusqu'à ce qu'elles soient toutes fermées. Lorsque d'anciens processus ont des connexions de longue durée, ils peuvent accumuler et consommer des ressources.

L'intervalle minimum de rechargement de HAProxy par défaut est de cinq secondes. Vous pouvez configurer un contrôleur d'entrée à l'aide de son champ spec.tuningOptions.reloadInterval pour définir un intervalle de recharge minimum plus long.