fix(kube-ovn): reload kubeovn-webhook serving certificate on cert-manager renewal - #3557

The bug this fixes is real and well diagnosed: the webhook loaded its TLS serving cert once at startup into a static tls.Config.Certificates, so a cert-manager renewal of the Secret was never picked up by a running pod, and once the cert expired the apiserver's TLS call to the webhook failed — with failurePolicy: Fail, that takes down pod creation cluster-wide. Good catch, and the renewBefore: 24h → 720h change in templates/certmanager.yaml is a sensible independent hardening on top of it (30 days of margin for a renewal retry vs. 1 day).

On the implementation: I think cert.go's certReloader (mtime tracking, serialized refresh, retry backoff, rate-limited logging, last-good-certificate fallback — 155 lines, plus 245 lines of tests) can collapse to a GetCertificate closure that just re-reads the files on every handshake, with no watcher, cache, or extra state:

package main

import "crypto/tls"

// newReloadingTLSConfig returns a tls.Config that reloads the certificate and key
// from disk on every TLS handshake, so a cert-manager renewal of the mounted Secret
// is picked up by the running process without a restart.
func newReloadingTLSConfig(certFile, keyFile string) (*tls.Config, error) {
	if _, err := tls.LoadX509KeyPair(certFile, keyFile); err != nil {
		return nil, err
	}
	return &tls.Config{
		GetCertificate: func(*tls.ClientHelloInfo) (*tls.Certificate, error) {
			cert, err := tls.LoadX509KeyPair(certFile, keyFile)
			if err != nil {
				return nil, err
			}
			return &cert, nil
		},
	}, nil
}

Same function signature, so main.go doesn't need to change at all — this is a deletion inside cert.go, not a rewrite. A few things that make me confident this is sufficient rather than under-engineered:

• GetCertificate is called on every handshake whenever Certificates is left unset, per crypto/tls docs — no SNI dependency, no gap. I verified this empirically too: a standalone listener using exactly the closure above serves a stale cert before a file rewrite and the renewed one immediately after, across two separate connections, no polling involved.
• The torn-read scenario certReloader guards against (reading a cert/key pair mid-write, cert.go:81-107, tested in cert_test.go:165-245) isn't reachable here: templates/deployment.yaml mounts webhook-certs as a plain secret: volume with no subPath, and Kubernetes' atomic writer for Secret volumes swaps the whole ..data directory via a single symlink flip. A reader always sees a complete old generation or a complete new one, never a mixture — of a single file or of the cert/key pair. That's what the two extra tests are actually exercising: that the fallback machinery works internally, not that it's needed for anything this deployment can produce.
• The per-handshake LoadX509KeyPair cost (a few KB of file I/O plus a PEM/key parse) is negligible next to the asymmetric crypto a TLS handshake is already doing (ECDHE key exchange, certificate signing) — it shouldn't need caching to stay cheap.
• No mTLS is configured on this webhook (mutatingwebhookconfiguration.yaml has no client-cert verification, and neither version of cert.go sets ClientCAs), so GetCertificate's well-known limitation — it doesn't refresh CA pools, only server/client leaf certs — doesn't bite here.

One real trade-off worth naming: if the mounted cert genuinely becomes unreadable (Secret deleted, permissions changed — not a normal renewal), the closure above fails every handshake and logs on each one, where the current certReloader keeps serving the last good cert and rate-limits the log line. That's a narrow, admin-error-only scenario, and failing loudly there seems fine to me, but it's the one place the extra code isn't purely redundant.

Happy to open a follow-up PR with the smaller diff if that's useful, or if there's a reason to keep the extra machinery I'm missing, I'd like to hear it.

(Review drafted with Claude Code assistance.)