Rechercher

9.2. Configuration des sondes de disponibilité, de préparation et de démarrage du contrôleur d'entrée

download PDF

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.

ParamètresDescription

livenessProbe

Le site livenessProbe signale au kubelet si un pod est mort et doit être redémarré.

readinessProbe

Le site readinessProbe indique si un pod est sain ou malsain. Lorsque la sonde de disponibilité signale un pod malsain, le kubelet marque le pod comme n'étant pas prêt à accepter du trafic. Par la suite, les points d'extrémité de ce module sont marqués comme n'étant pas prêts, et ce statut se propage au kube-proxy. Sur les plateformes en nuage dotées d'un équilibreur de charge configuré, le kube-proxy communique avec l'équilibreur de charge du nuage pour qu'il n'envoie pas de trafic au nœud contenant ce module.

startupProbe

Le site startupProbe donne au pod routeur jusqu'à 2 minutes pour s'initialiser avant que le kubelet ne commence à envoyer les sondes de disponibilité et de préparation du routeur. Ce temps d'initialisation permet d'éviter que les routeurs ayant de nombreux itinéraires ou points d'extrémité ne redémarrent prématurément.

Important

L'option de configuration du délai d'attente est une technique de réglage avancée qui peut être utilisée pour contourner les problèmes. Cependant, ces problèmes doivent être diagnostiqués et éventuellement faire l'objet d'un dossier d'assistance ou d'une question Jira pour tout problème entraînant un dépassement du délai d'attente des sondes.

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}}]}}}}'

Vérification

$ 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

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.