Comment lancer les répliques mortes de Kubernetes Deployment

Question

Maintenant, nous avons déployé des services en tant que Déploiements Kubernetes avec plusieurs répliques. Une fois que le serveur tombe en panne, Kubernetes va migrer ses conteneurs vers un autre serveur disponible qui va durer entre 3 et 5 minutes. Lors de la migration, le client peut accéder au service de déploiement, car nous avons toujours d'autres réplicas en cours d'exécution. Mais parfois, les demandes échouent car l'équilibreur de charge redirige vers les conteneurs morts ou en cours de migration.

Ce serait génial si Kubernetes pouvait kickoff les répliques mortes automatiquement et les ajouter une fois qu'ils ont fonctionné sur d'autres serveurs. Sinon, nous devons configurer LB comme haproxy pour faire le même travail avec plusieurs instances de déploiement.

Answer 1

1, kubelet

--node statut de mise à jour de fréquence durée spécifie la fréquence statut de noeud de messages kubelet à maîtriser. Note: soyez prudent lorsque vous changez la constante, cela doit fonctionner avec nodeMonitorGracePeriod dans nodecontroller. Par défaut: 10s (10s par défaut)

2, contrôleur-manager

--node-moniteur période de grâce durée Montant du temps que nous courons nœud à autorisons ne pas répondre avant de marquer malsain. Doit être N fois plus que nodeStatusUpdateFrequency de Kubelet, où N signifie le nombre de tentatives autorisées pour que kubelet affiche l'état du nœud. (40s par défaut)

durée --pod-expulsion-délai La période de grâce pour la suppression de gousses sur les nœuds échoué. (par défaut 5m0s)

Answer 2

Vous devez configurer la vérification de l'intégrité pour équilibrer la charge de travail pour un service. S'il vous plaît avoir une lecture de:

https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/

Le kubelet utilise des sondes de préparation de savoir quand un conteneur est prêt à commencer à accepter le trafic. Un Pod est considéré comme prêt lorsque tous ses Conteneurs sont prêts. Une utilisation de ce signal consiste à contrôler quels modules sont utilisés comme backend pour les services. Lorsqu'un pod n'est pas prêt, il est supprimé des équilibreurs de charge du service.