BUG REPORT (copied from @rhuss's issue filed here https://github.com/kubernetes/kubernetes/issues/5363)
1.8.0 - up to current master (2017-10-26)
When using kubeadm with a token generated by kubeadm token generate in advance, but also when letting kubeadm create the token, a tokenTTL
configuration is ignored. The same is true when not using a config file but using kubeadm init --token-ttl 0
I would expect when providing a tokenTTL of 0s that the token does not expire.
See https://github.com/kubernetes/kubernetes/issues/53637 where @rhuss described this nicely.
This bug was introduced in https://github.com/kubernetes/kubernetes/pull/48783 when default token TTL was changed.
The API machinery defaulting mechanism doesn't have a way to differentiate between an unset value and a value that's explicitly set to zero.
I did some manual testing on that change, but apparently only for kubeadm token create --ttl 0
, which works fine because it doesn't use the MasterConfiguration defaulting mechanism.
cc @kubernetes/sig-cluster-lifecycle-bugs
/type bug
My current workaround is to create an extra token on my own _after_ kubeadm init
:
kubeadm init --config /etc/kubernetes/kubeadm.yml
kubeadm token create --ttl 0 --groups system:bootstrappers:kubeadm:default-node-token --description "Bootstrap token which does not expire"
The later token is then used for kubeadm join
on the nodes.
Thanks @mattmoyer for the bug fix :clap:! Approved
This is fixed in master
and should be in v1.8.3.
Most helpful comment
My current workaround is to create an extra token on my own _after_
kubeadm init
:The later token is then used for
kubeadm join
on the nodes.