Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

490
Vistas
¿Cómo detecto el tráfico del host local a mi clúster k8s (ejecutándose localmente)?

Tengo un clúster de minikube ejecutándose localmente y un pod, clúster ip 172.17.0.8 .

Estoy usando ksniff para rastrear el tráfico en esa cápsula.

En el pod cuando hago ping www.google.com . Puedo ver, en la captura de wireshark, la solicitud ICMP va hacia/desde:

pod (172.17.0.8) <--> servidor de google (alguna IP)

Sé que hay un paso intermedio. Donde mi macbook (el host del clúster) realiza la solicitud en nombre del pod y recibe la respuesta para enviar al pod correcto.

pod (172.17.0.8) <--> host de clúster (macbook) <--> servidor de google (alguna IP)

¿Cómo puedo capturar el tráfico entre el pod y el host del clúster (p. ej., macbook)?

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

No he usado minikube ni una macbook, por lo que su millaje puede variar, pero intentemos resolver esto.

Por lo que he visto, el host suele proporcionar a los pods una puerta de enlace predeterminada. En otras palabras, el host sirve como enrutador para los pods que aloja. ¿Cómo lo sabemos? Cuando ejecuto una imagen de Ubuntu en un clúster K8s (e instalo iproute2), obtengo la siguiente tabla de enrutamiento:

 root@ubuntu:/# ip route sh default via 10.244.2.1 dev eth0 10.244.2.0/24 dev eth0 proto kernel scope link src 10.244.2.17

¿Ves ese default via 10.244.2.1 ? Ese es el "enrutador" que proporciona el host. Incluso podemos buscar su dirección mac:

 root@ubuntu:/# cat /proc/net/arp IP address HW type Flags HW address Mask Device 10.244.2.5 0x1 0x2 fa:26:3d:e1:10:f5 * eth0 10.244.2.1 0x1 0x2 8e:f7:54:7b:15:51 * eth0

Entonces, el flujo de tráfico entre el módulo e Internet probablemente sea como el flujo de tráfico de un host detrás de un enrutador NAT.

El pod realiza el baile de solicitud arp/respuesta arp , luego, después de conocer la dirección mac del "enrutador", enviará paquetes IP hacia el servidor externo con la dirección IP del servidor externo como destino y su propia dirección IP como fuente. La dirección MAC de destino de estos paquetes sería la dirección MAC de la tarjeta de red virtual del host. Por lo tanto, una captura realizada en el módulo le mostrará el tráfico entre el módulo y el host como si el host fuera un enrutador . Una vez que los hosts obtienen estos paquetes, probablemente los NAT en su caso y los envíe a través de Internet.

Entonces, en el host, si captura en 10.244.2.1 , debería ver el mismo tráfico que ve el pod. Pero si captura en la interfaz real orientada a Internet, probablemente verá el tráfico del módulo más allá de la NAT (es decir, con su dirección IP real como IP de origen).

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda