I just hit a problem where the reachability test succeeded, but the ACME authorization failed. As a result, kube-lego retried it 4 more times immediately and then hit the rate limit. After the rate limit window expired (1h), it got the cert properly with no problems.
Ideally, there would be a LEGO_REQUEST_DELAY parameter or similar, where we could specify a backoff parameter to control how frequently the request is retried.
I'm 95% sure what happened was that the DNS record that I created went live to kube-lego before ACME's DNS servers had been updated. The certificate was for a brand new ingress, so I hadn't created DNS entries for it before, and everything's running in GCP so the DNS record goes live almost instantaneously for the kubernetes cluster, while it probably didn't for the ACME servers.
276 would have helped me debug this too, so +1 for that!
P.S. Thank you for putting kube-lego together! Having had to manually a million fiddly SSL certs in the past, this is a great step forward.
I just hit a problem where the reachability test succeeded, but the ACME authorization failed. As a result, kube-lego retried it 4 more times immediately and then hit the rate limit. After the rate limit window expired (1h), it got the cert properly with no problems.
Ideally, there would be a LEGO_REQUEST_DELAY parameter or similar, where we could specify a backoff parameter to control how frequently the request is retried.
I'm 95% sure what happened was that the DNS record that I created went live to kube-lego before ACME's DNS servers had been updated. The certificate was for a brand new ingress, so I hadn't created DNS entries for it before, and everything's running in GCP so the DNS record goes live almost instantaneously for the kubernetes cluster, while it probably didn't for the ACME servers.
276 would have helped me debug this too, so +1 for that!
P.S. Thank you for putting kube-lego together! Having had to manually a million fiddly SSL certs in the past, this is a great step forward.