0
354
Vistas¿Cómo mantener viva la conexión de larga duración incluso cuando se elimina el pod de Kubernetes?
Tengo la siguiente arquitectura para el clúster de PostgreSQL:
Aquí, hay varios clientes que interactúan con los pods de PostgreSQL a través de pgpool, el problema es que cuando el pod (podría ser pgpool o pod de PostgreSQL ) termina (por varias razones), el cliente recibe impactos y tiene que volver a crear la conexión. Por ejemplo, en este diagrama, si postgresql-1 pod finaliza, client-0 tendrá que volver a crear la conexión con el clúster.
¿Hay alguna manera en kubernetes de manejarlo para que las conexiones al pgpool k8s service se equilibren/recreen en otros pods para que los clientes no vean el cambio y no se vean afectados ?
Tenga en cuenta que estas son conexiones TCP y no conexiones HTTP (que no tienen estado). Además, todos los pods de PostgreSQL siempre están sincronizados con remote_apply .
2 Respuestas
Responde la pregunta0
Sin un código personalizado sustancial para permitir transferencias de conexión TCP entre hosts, no puede. Cuando un proceso se cierra, todos los flujos TCP que tiene abiertos se cerrarán, así es como funciona la red normal de Linux. Si hace una ronda en su motor de búsqueda de elección para cosas como "migración de conexión TCP", encontrará muchos esfuerzos de investigación sobre este pero poco código real. Más a menudo, simplemente finaliza la conexión TCP en algún proxy de borde de larga duración y, si eso tiene que reiniciarse, se come las reconexiones.
0
¿Hay alguna manera en kubernetes de manejarlo para que las conexiones al servicio pgpool k8s se equilibren/recreen en otros pods?
Las conexiones al servicio pgpool k8s se equilibran mediante kube-proxy. Los puntos finales (pgpool pods) que respaldan el servicio se actualizarán automáticamente cada vez que haya un cambio (por ejemplo, escalamiento) en la población de pods.
...para que los clientes no vean el cambio y no se vean afectados?
Si el pod de pgpool que el cliente conectó se cancela, el estado de tcp del cliente se vuelve inválido (p. ej., anula la IP remota). No es necesario mantener activa dicha conexión, pero vuelva a conectarse al servicio pgpool, donde kube-proxy lo enrutará al próximo pod de pgpool disponible. pgpool administra la conexión real a la base de datos back-end, incluida la conmutación por error de la base de datos. Con pgpool como proxy, no necesita preocuparse por el cambio de base de datos.