You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using a CD system such as Flux to deploy an application exposed through a LoadBalancer service with a pre-provisioned certificate, if the certificate was renewed and its certificate ID consequently changed, a later re-deployment of the service by the CD system will be stuck with an external IP in pending state because the service.beta.kubernetes.io/do-loadbalancer-certificate-id annotation will be set to an earlier ID of the otherwise unmodified certificate.
To fix the deployment (after figuring out what is wrong...), the source repository used to drive the CD system must be updated. This is very undesirable and inconvenient as nothing really changed in the (intent of the) deployment specification.
I think that one possible and fairly simple solution would be to allow specifying the certificate name at time of deployment of the service. The name could then be converted to an ID by the CCM (using existing DO certificates API). The remainder and process could remain unchanged, with automatic updates of the certificate reflected in its ID.
I created PR #572 proposing this approach.
It uses the 'service.beta.kubernetes.io/do-loadbalancer-certificate-name' service annotation to specify the certificate by name.
The text was updated successfully, but these errors were encountered:
When using a CD system such as Flux to deploy an application exposed through a LoadBalancer service with a pre-provisioned certificate, if the certificate was renewed and its certificate ID consequently changed, a later re-deployment of the service by the CD system will be stuck with an external IP in pending state because the
service.beta.kubernetes.io/do-loadbalancer-certificate-id
annotation will be set to an earlier ID of the otherwise unmodified certificate.To fix the deployment (after figuring out what is wrong...), the source repository used to drive the CD system must be updated. This is very undesirable and inconvenient as nothing really changed in the (intent of the) deployment specification.
I think that one possible and fairly simple solution would be to allow specifying the certificate name at time of deployment of the service. The name could then be converted to an ID by the CCM (using existing DO certificates API). The remainder and process could remain unchanged, with automatic updates of the certificate reflected in its ID.
I created PR #572 proposing this approach.
It uses the 'service.beta.kubernetes.io/do-loadbalancer-certificate-name' service annotation to specify the certificate by name.
The text was updated successfully, but these errors were encountered: