emissary-ingress/emissary

`apiext` should eagerly generate TLS certificates

Open

#4,275 opened on Jun 10, 2022

 (4 comments) (7 reactions) (0 assignees)Python (679 forks)batch import
good first issuet:bug

Repository metrics

Stars
 (4,096 stars)
PR merge metrics
 (PR metrics pending)

Description

Please describe your use case / problem. A user reports that they're getting timeouts of the apiserver trying to talk to apiext Error from server: error when creating "STDIN": conversion webhook for getambassador.io/v3alpha1, Kind=Host failed: Post https://emissary-apiext.emissary-system.svc:443/webhooks/crd-convert?timeout=30s: net/http: TLS handshake timeout despite the apiext supposedly being ready (kubectl wait --timeout=90s --for=condition=available deployment emissary-apiext -n emissary-system).

I believe that this is because apiext is using up the whole timeout lazily generating the TLS certificate. This behavior of lazily generating it originates from before we knew what the deployment story would be.

Describe the solution you'd like Nowadays we know it always gets deployed in to the emissary-system namespace, with the same service name; it can know what hostname it needs ahead of time. And then we can build this in to the readiness checks, so a bod isn't ready until it has its TLS certificate, which would be a pretty unambiguously good thing.

Describe alternatives you've considered (none)

Additional context Ref: https://datawire-oss.slack.com/archives/CAULN7S76/p1654804207183139

Contributor guide