Kubernetes – Explorando un Cluster de Kubernetes con VMware Octant.

Kubernetes – Explorando un Cluster de Kubernetes con VMware Octant.

VMware se ha montado en el ecosistema de Kubernetes, luego de adquirir Heptio, VMware recibió varias plataformas opensource tales como Velero y Sonobuoy.

Sin embargo, no solo estan las que llegaron via Heptio, un ejemplo notable es Octant, hace unos meses me tope con esta aplicacion en la cuenta de Github de Vmware mientras buscaba informacion sobre Tanzu.

https://github.com/vmware-tanzu/octant

Octant es una aplicacion para que los desarrolladores (¡¡también los administradores!!) entiendan como las aplicaciones son ejecutadas en Kubernetes. Con la información presentada en Octant se muestra de una manera mas clara la relacion entre Ingress, Services, Pod y Deployments. Desde hace un tiempo estoy usando Rancher, no planeo reemplazarlo ya que Octant esta pensado para ser ejecutado desde el desktop usando el kubeconfig local, desde mi punto de vista es una aplicación de diagnóstico.

Continuar leyendo «Kubernetes – Explorando un Cluster de Kubernetes con VMware Octant.»

Default Rule NDP – VMware NSX.

Siguiendo con las pruebas de IPv6 en NSX, he notado que una vez tenemos el Manager corriendo y al menos un Controller, si vamos a Firewall -> General, tenemos tres reglas creadas por defecto. En mi caso me ha llamado la atención una llamada Default Rule NDP la cual tiene un Action = Allow.

 

 

Primero, que es NDP?

Es un protocolo usado en IPv6, este opera en el Network Layer (Capa 3 del modelo OSI). Una de las tareas importantes es que este protocolo es el encargado de encontrar (descubrir) otros nodos en el mismo segmento (link).

A mi entender esta es la razón del porque esta regla está en la parte de General cuando entramos a Firewall, la primera prueba que hice fue cambiar el Allow por Block y automáticamente la VM en el cluster que está preparado para NSX y al cual esta política le aplica dejo de alcanzar TODOS los demás host en el mismo link layer. Por ejemplo, si quisiera hacer lo mismo en IPv4 dentro de NSX tendría que crear una regla en la parte de Ethernet tal vez usando la MAC de la VM que no quiero que genere tráfico a ningún otro hosts.

Personalmente pienso que esto no debería ser una política creada por defecto y más bien una opción habilitada en el mismo servicio de Firewall, se puede dar el caso que por equivocación se coloque una regla que interfiera con la comunicación NDP más arriba de esta por defecto y automáticamente tendremos un mal día.

Capturando paquetes en ESXi para diagnosticar errores en flowAnalyzer.

He estado investigando por qué cuando se envían datos IPFIX desde un vDS en vSphere el proceso que supone que recibe estos paquetes simplemente muere y reinicia sus operaciones, nada de la información enviada por el vDS se registra en los Index de Kibana.

Sometí un ticket al desarrollador de flowAnalyzer y quien a su vez me solicito un PCAP de los datos generados, en Linux esto se consigue con tcpdump, en Windows con Wireshark pero en ESXi ¿?

Que tenemos a disposición en ESXi para crear un PCAP?

Tenemos pktcap-uw!

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2051814

Entonces, para capturar este tráfico habilite IPFIX (NetFlow) nuevamente en sus respectivos lugares y luego ejecute:

pktcap-uw –uplink vmnic2 -o /vmfs/volumes/ADAPTEC-232GB-JBOD/vmnic2.pcap

nota: actualmente el ESXi donde estoy generando las pruebas tiene un vDS con dos uplink a diferentes Switches, uno de los swtiches está apagado y por esto solo estoy capturando datos en el vmnic2.

Esta es la configuración de IPFIX (NetFlow):

Aquí una captura de pktcap capturando tráfico:

Esperemos que la causa del problema este entre los paquetes capturados!

Enviando flow data desde vSphere vDS a flowAnalyzer.

Desde el punto de vista de los equipos de red físico estamos corriendo un PROBE y enviando esa información al COLLECTOR. Ahora le toca al ambiente virtual!

vSphere vDS (Distributed Switch) soporta la funcionalidad de NetFlow. Habilitando esta opción en nuestros vDS podremos ver información de red que posiblemente no paso por el PROBE que corre en el inter-vlan router o el router de borde. Por ejemplo, tráfico de una VM en 10.0.0.0/24 a otra VM en el mismo rango de red no llegara a los routers y por esto no lo veremos en en flowAnalyzer.

Así habilitamos Netflow en el vDS:

  1. habilitamos la funcionalidad en el vDS:

 

  1. habilitamos en cuales PortGroup queremos capturar trafico:

 

Inicialmente configure el probe para NetFlow 9, en la versión 5.1 en adelante soporta IPFIX. asi que cambie el puerto y pude ver el trafico llegando al colector.

Lamentablemente, el PROBE en vDS envía datos que el template en el colector no los tiene y esto hace que el proceso muera y reinicie, esto quiere decir que la información no llega al index de Kibana.

 

Investigare como puedo agregar los valores para inciar el proceso nuevamente. stay tunned!