Kubeadm: `kubeadm init --token-ttl 0` (drapeau) et `tokenTTL: "0"` (config) sont cassés depuis la 1.8.0

S'agit-il d'un rapport de bogue ou d'une demande de fonctionnalité ?

RAPPORT DE BUG (copié du @rhuss déposé ici https://github.com/kubernetes/kubernetes/issues/5363)

Versions

1.8.0 - jusqu'au maître actuel (2017-10-26)

Que s'est-il passé?

Lors de l'utilisation de kubeadm avec un jeton généré par kubeadm token généré à l'avance, mais également en laissant kubeadm créer le token, une configuration tokenTTL est ignorée. La même chose est vraie lorsque vous n'utilisez pas de fichier de configuration mais que vous utilisez kubeadm init --token-ttl 0

A quoi vous attendiez-vous ?

Je m'attendrais à ce que le jeton n'expire pas en fournissant un tokenTTL de 0.

Comment le reproduire (le plus minimalement et le plus précisément possible) ?

Voir https://github.com/kubernetes/kubernetes/issues/53637 où @rhuss a bien décrit cela.

Autre chose que nous devons savoir ?

Ce bogue a été introduit dans https://github.com/kubernetes/kubernetes/pull/48783 lorsque le jeton TTL par défaut a été modifié.

Le mécanisme de mise en défaut des machines de l'API ne permet pas de différencier une valeur non définie d'une valeur explicitement définie sur zéro.

J'ai effectué des tests manuels sur ce changement, mais apparemment uniquement pour kubeadm token create --ttl 0 , ce qui fonctionne bien car il n'utilise pas le mécanisme de mise en valeur par défaut de MasterConfiguration.