The ingress controller can handle that directly since it watches for updates from the API server, but Kong cannot–it doesn’t have the ability to watch and must rely on DNS and/or connection resets on the existing connections.
You may want to review the suggestion/info in https://github.com/Kong/charts/pull/116 and https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/ regarding how Pods handle termination. That specific change won’t help here (it’s for adjusting how Kong terminates, for gracefully clients sending requests to it, and you’d need to modify how the upstream Pods terminate to gracefully handle inbound requests to Kong), but it’s similar to the changes you’d need to make on your own Pods/applications.
Keepalive behavior is tunable to a degree and you can send a Connection: close header to avoid them entirely (note that you can use a serverless plugin instance as an alternative to a full custom plugin). I’d recommend exploring termination policy first, however, since keepalive changes also affect performance when the upstream Pod is running normally, not just when it terminates–sending Connection: close in particular is pretty drastic, since it forces a new TCP connection for each request, which can increase overall request latency considerably.