Kubettes 1.14.2 ha maître nginx charge balancer log.go: 172] http: TLS Handshake Erreur à partir de 192.168.5.32:43148: Erreur à distance: TLS: Bad certificat

Nope, cela n'a pas fonctionné non plus. Obtenir toujours l'erreur d'origine: I0526 15: 55: 51.990243 1 log.go: 172] http: TLS Handshake Erreur de 192.168.5.32:36638: Erreur à distance: TLS: Bad Certificat I0526 15: 55: 52.102702 1 LOG.GO: 172 ] Http: TLS Handshake Erreur de 192.168.5.32:36640: Erreur à distance: TLS: Bad certificat. Quelle était cette configuration qui envoiait le client Cert? Je devrais peut-être faire cela juste pour avoir dépassé cette erreur, puis revenez et résout cela plus.

Consultez le modifier les révisions à la réponse. Cela étant dit, envoyez-vous un certificat client des clients à travers Nginx?

Ok, je devrais peut-être expliquer cela un peu plus. Je ne vais pas au-delà du point de configuration d'un seul serveur API avant de commencer à rechercher cette exception. Donc, toutes les erreurs qui se produisent sur le serveur ont à voir avec le serveur agissant en tant que client si l'équilibreur de chargement Nginx. Donc, le Septir lui-même est de se plaindre qu'il ne peut pas valider le client car le Nginx ne transfère pas les certificats clients d'une couche 7 lb.

Après tout ce travail, la chose qui échoue à la vérification de la santé Nginx est réelle. Est-ce que quelqu'un a une configuration d'équilibreur de charge TCP qui spécifie ...: 6443 / Healthz en tant que contrôle de santé. J'ai déjà une configuration de couche 4, mais cela ne fonctionne pas du tout.

@Danielmaldonado Malheureusement, je n'ai pas pu trouver cet ancien config. Cela faisait partie d'une preuve de concept que j'ai fait un moment de retour mais ce n'était jamais contrôlé de la version.

Ne vous inquiétez pas, le problème est le chèque de santé de l'équilibreur de charge. Comme il n'a pas de certificat, il lance cette exception. Ce serait formidable si nous avions un chèque de santé qui n'avait pas besoin d'un certificat: - / C'est toujours un problème et je devrai travailler à ce sujet une fois que le cluster est complètement stable, nous venons de renverser des chèques de guérison dans la LB. . Ce n'est pas une solution idéale mais il nous a eu le point de voir constamment l'exception dans le journal.

C'était intéressant pour moi d'apprendre, que «TLS Handshake Error» observée dans Kube-Apiserver Les journaux se produisent en réalité lors des chèques de santé. @Daniel Maldonado, diriez-vous de résumer vos conclusions dans les commentaires sous forme de post-mise à jour, ou de la publication Wiki.

C'était mon erreur, j'avais une erreur de configuration du pare-feu et que tous les tests ont indiqué qu'il s'agissait de l'équilibreur de charge qui sonder le kube-apiscerver en fait ce n'est pas le cas. Le problème était totalement local sur l'API-Server lui-même. Si quelqu'un passe à ce point, veuillez vérifier que tous les ports sont disponibles sur le serveur API I.E. LOOPBACK.