devops
7a83ed61b9
Diagnostico: pg_isready y el cliente pg de Medusa fallan de forma consistente (100%, 186/186 intentos) cuando el pod queda agendado en un nodo distinto al de commerce-postgres-0. TCP handshake (nc/ping) funciona cruzando nodos, pero el primer paquete de datos real de la sesion nunca llega - blackhole de PMTU Discovery entre los nodos del cluster k3d (flannel VXLAN / MTU del bridge Docker subyacente). Se agrega podAffinity requiredDuringSchedulingIgnoredDuringExecution (no nodeSelector fijo, mantiene portabilidad) para que medusa-deploy siempre comparta nodo con commerce-postgres-0 y evite cruzar el blackhole. Es un workaround, no el fix de raiz: documentado en docs/known-issues.md junto con el TODO de ajustar el MTU del cluster a 1400.
2.3 KiB
Known issues
Blackhole de red cross-node en el cluster k3d (MTU/PMTUD, flannel VXLAN)
Estado: workaround aplicado, fix definitivo pendiente.
Síntoma: cualquier pod que necesite hablar con commerce-postgres-0
(StatefulSet, sin réplicas, fijo a un nodo) falla de forma consistente y
reproducible al 100% cuando queda agendado en un nodo distinto al de
Postgres. El handshake TCP (SYN/ACK, nc, ping) funciona perfecto entre
nodos, pero el primer paquete de datos real de la sesión (protocolo Postgres,
pg_isready incluido) nunca llega — se cuelga hasta hacer timeout.
Diagnóstico:
- Confirmado aislando el nodo con
nodeNameen pods de prueba: 100% de fallos (186/186 intentos) agendando cross-node (agent-0→ Postgres enserver-0); 100% de éxito agendando en el mismo nodo. - MTU dentro de los pods (interfaz
flannel.1/VXLAN) es 1450 en ambos nodos — consistente, no es un mismatch obvio a nivel flannel. pingsin-M do(permite fragmentación) no muestra pérdida de paquetes hasta payloads de 2000 bytes entre los contenedores Docker de los nodos.- Encaja con un blackhole de PMTU Discovery: el bridge Docker externo que conecta los contenedores de los nodos k3d probablemente tiene un MTU real menor a 1500, y los paquetes TCP con el bit DF puesto (como los de la sesión de Postgres) se pierden en vez de fragmentarse o generar el ICMP "fragmentation needed" que permitiría el ajuste automático.
Workaround temporal (aplicado en workloads/ecommerce/commerce/medusa.yaml):
podAffinity con requiredDuringSchedulingIgnoredDuringExecution sobre
medusa-deploy, forzando que sus pods se agenden siempre en el mismo nodo
que commerce-postgres-0 (matchLabels: app: commerce-postgres,
topologyKey: kubernetes.io/hostname). Esto evita el tráfico cross-node
entre Medusa y Postgres, pero no resuelve el problema de fondo — cualquier
otro workload que necesite cruzar nodos para hablar con Postgres (u otro
servicio) puede pisar el mismo blackhole.
TODO — fix definitivo pendiente:
Ajustar el MTU del cluster k3d a un valor seguro (1400) de forma
consistente en la red Docker del cluster y en flannel, para eliminar el
blackhole de raíz y poder quitar el podAffinity (o dejarlo como
optimización, no como requisito de disponibilidad).