Comprendre les exemples Kubernetes: types, configuration et bonnes pratiques

Source



Cet article traite de la configuration des sondes de préparation, d'intégrité et de démarrage pour détecter et utiliser des modules défectueux tels que traduits par l'équipe aaS de Kubernetes .

Pourquoi les validations Kubernetes sont-elles nécessaires?

L'un des défis des systèmes distribués et de l'architecture de microservices est la détection automatique des applications défectueuses, la redirection des demandes vers d'autres systèmes disponibles et la réparation des composants endommagés. Les bilans de santé sont un moyen de résoudre ce problème et d'assurer la fiabilité. Dans Kubernetes, les vérifications de l'état sont configurées à l'aide de sondes pour déterminer l'état de chaque pod.



Par défaut, Kubernetes surveille le cycle de vie d'un pod et commence à acheminer le trafic vers le pod lorsque les conteneurs passent de En attente à Réussite. Kubelet surveille également les pannes d'application et redémarre le module pour la récupération.



De nombreux développeurs pensent que cette configuration de base est suffisante, en particulier lorsque l'application à l'intérieur du module est configurée à l'aide de gestionnaires de processus tels que PM2 pour Node.js.



Cependant, étant donné que Kubernetes considère que le module est sain et prêt pour les requêtes, dès que tous les conteneurs sont démarrés, l'application peut commencer à recevoir du trafic avant d'être réellement prête. Cela peut se produire lorsque l'application doit initialiser un état, établir une connexion à la base de données ou charger des données avant de traiter la logique de l'application.



Ce laps de temps entre la disponibilité réelle de l'application et le moment où Kubernetes la considère comme prête devient un problème lorsque le déploiement commence à évoluer et que les applications non préparées reçoivent du trafic et renvoient une erreur 500.



C'est là que les sondes Kubernetes sont utilisées pour déterminer quand un conteneur est prêt à accepter le trafic et quand il doit être redémarré. À partir de Kubernetes 1.16, trois types de sondes sont pris en charge.



Dans cet article, l'auteur présente différents types de sondes, ainsi que les meilleures pratiques et outils pour détecter les déploiements présentant des problèmes de configuration potentiels.

Sondes Kubernetes

Kubernetes prend en charge les sondes de disponibilité et d'intégrité pour les versions ≤ 1.15. Les sondes de lancement ont été ajoutées dans la version 1.16 en tant que fonctionnalité alpha et déplacées vers la version bêta de la version 1.18.



AVERTISSEMENT: dans la version 1.16, certaines parties de l'API Kubernetes sont devenues obsolètes. Utilisez ce guide de migration pour vérifier la compatibilité.



Tous les échantillons ont les paramètres suivants:

• initialDelaySeconds
  
  
  
  : ;
• periodSeconds
  
  
  
  : ;
• timeoutSeconds
  
  
  
  : - ( );
• successThreshold
  
  
  
  : , ;
• failureThreshold
  
  
  
  : . . , .

Les sondes de préparation sont utilisées pour indiquer au kubelet quand l'application est prête à accepter un nouveau trafic. Si votre application prend un certain temps à s'initialiser après le démarrage d'un processus, configurez une sonde de disponibilité pour que Kubernetes attende avant d'envoyer un nouveau trafic. Le principal cas d'utilisation des sondes de disponibilité est de diriger le trafic vers les déploiements pour les services.





Source



Il est important de se rappeler que les sondes de préparation fonctionnent tout au long de la vie d'un module. Cela signifie qu'ils seront lancés non seulement au démarrage, mais également pendant toute la durée de fonctionnement du module.



Ceci est nécessaire dans les situations où l'application est temporairement indisponible, comme le chargement de données volumineuses ou l'attente de connexions externes. Dans ce cas, nous ne voulons pas tuer l'application, mais attendons qu'elle soit restaurée. Les sondes de disponibilité sont utilisées pour détecter ce scénario et n'envoient pas de trafic vers ces modules tant qu'ils n'ont pas réussi à nouveau le contrôle de disponibilité.

Des tests de performance

Les sondes d'intégrité sont utilisées pour redémarrer les conteneurs défectueux. Le Kubelet appelle périodiquement un test de santé, détecte la santé du pod et le tue s'il échoue à une vérification de santé.



Un essai peut aider une application à sortir d'une impasse. Sans vérifications de l'état, Kubernetes considère comme verrouillé sous sain car le processus principal continue de s'exécuter du point de vue de Kubernetes. En configurant une sonde d'intégrité, kubelet peut détecter que l'application est dans un mauvais état et redémarrera le pod pour restaurer la disponibilité.





La source

Lancer des échantillons

Les tests de démarrage sont similaires aux tests prêts, mais ne sont exécutés qu'au démarrage. Ils sont optimisés pour le lancement lent de conteneurs ou d'applications avec des processus d'initialisation imprévisibles. Avec les sondes de préparation, nous pouvons ajuster initialDelaySeconds



pour déterminer combien de temps attendre avant de vérifier l'état de préparation.



Considérons maintenant une application qui a parfois besoin de charger de grandes quantités de données ou d'effectuer une opération gourmande en ressources au début du processus. Puisqu'il initialDelaySeconds



s'agit d'un nombre statique, nous sommes obligés de toujours prendre le pire des cas (ou d'augmenter la valeur failureThreshold



, ce qui peut affecter le comportement ultérieur) et d'attendre longtemps, même si cette application n'a pas besoin d'effectuer une longue initialisation.



Au lieu de cela, à l'aide de sondes de démarrage, nous pouvons configurerfailureThreshold



et periodSeconds



pour mieux gérer cette incertitude. Par exemple, un paramètre failureThreshold



de 15 et periodSeconds



5 signifie que l'application disposera de 15 x 5 = 75 secondes pour démarrer avant qu'une panne ne soit diagnostiquée.

Exemple de configuration

Maintenant que nous comprenons les différents types d'échantillons, nous pouvons explorer trois façons différentes de configurer chaque échantillon.

HTTP

Kubelet envoie une requête HTTP GET à l'URL spécifiée et recherche une réponse 2xx ou 3xx. Vous pouvez utiliser un point de terminaison HTTP existant ou configurer un serveur HTTP léger pour les tests (tel qu'un serveur Express avec un point de terminaison /healthz



).



Les sondes HTTP acceptent des paramètres supplémentaires:

• host
  
  
  
  : nom d'hôte pour la connexion (par défaut, c'est l'adresse IP du module);
• scheme
  
  
  
  : HTTP ou HTTPS par défaut;
• path
  
  
  
  : chemin sur le serveur HTTP / S;
• httpHeaders
  
  
  
  : en-têtes personnalisés si vous avez besoin de valeurs d'en-tête pour l'authentification, les paramètres CORS, etc.
• port
  
  
  
  : nom ou numéro de port pour accéder au serveur.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

TCP

Si vous avez juste besoin de vérifier si une connexion TCP peut être établie, utilisez une sonde TCP. Un module est marqué comme sain s'il peut établir une connexion TCP. L'utilisation de sondes TCP peut être utile pour les serveurs gRPC ou FTP où les appels HTTP ne sont pas appropriés.

readinessProbe:
  tcpSocket:
    port: 21

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Commander

Vous pouvez également configurer la sonde pour exécuter une commande shell. Le contrôle réussit si la commande revient avec le code de sortie 0. Sinon, le module est marqué comme défectueux.



Ce type de vérification peut être utile si vous ne voulez pas ouvrir un serveur / port HTTP, ou il est plus facile de vérifier les étapes d'initialisation avec des commandes. Par exemple, vérifiez si un fichier de configuration a été créé ou exécutez une commande CLI.

readinessProbe:
  exec:
    command: ["/bin/sh", "-ec", "vault status -tls-skip-verify"]

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Meilleures pratiques d'échantillonnage de Kubernetes

Les exemples de paramètres exacts dépendent de votre application, mais voici quelques instructions générales pour vous aider à démarrer:

1. Pour les clusters Kubernetes plus anciens (≤ 1,15), utilisez une sonde initiale prête pour le décalage pour gérer la phase de démarrage du conteneur. Pour ce faire, utilisez le temps centile de 99%. Mais simplifiez cette vérification car le test de préparation s'exécutera pendant toute la durée de vie du module. Nous ne voulons pas que la sonde expire car la vérification de l'état de préparation prend beaucoup de temps.
2. (≥ 1.16) Kubernetes . (, /healthz
   
   
   
   ), . failureThreshold
   
   
   
   , , . .
3. , . , , , . .
4. , . , , , . , .

En bref, des sondes bien définies augmentent généralement la stabilité et la disponibilité. Assurez-vous de garder une trace des heures de démarrage et du comportement du système pour ajuster vos paramètres d'échantillonnage à mesure que les applications changent.

Outils

Compte tenu de l'importance des sondes Kubernetes, vous pouvez utiliser les outils d'analyse des ressources Kubernetes pour trouver les sondes manquantes. Ces outils peuvent être exécutés sur des clusters existants ou intégrés dans un processus CI / CD pour échouer automatiquement lors du déploiement de charges de travail sans ressources correctement configurées:

• polaris est un utilitaire d'analyse de ressources avec une belle barre d'outils qui peut également être utilisée comme webhook de validation ou outil de ligne de commande.
• kube-score est un outil d'analyse de code statique qui fonctionne avec les fichiers Helm, Kustomize et YAML standard.
• popeye est un utilitaire en lecture seule qui analyse les clusters Kubernetes et signale les problèmes de configuration potentiels.

Dans ces deux canaux Telegram, vous trouverez des actualités de notre aaS Kubernetes et des annonces d' événements Meetup @Kubernetes .



Quoi d'autre à lire:

• 90 outils pour travailler avec Kubernetes .
• Fonctionnement de Kubernetes aaS sur la plate-forme MCS .
• Cinq échecs lors du déploiement de votre première application sur Kubernetes .