0

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.

Ya lo quiero, como lo consigo?

El proyecto provee varias formas de instalación, yo he usado una mezcla del empaquetado .deb y Docker.

Aquí esta el dockerfile que he usado, esta algo crudo y merece mejoras.

FROM debian:buster-slim
RUN apt-get update && apt-get install -y \
apt-transport-https \
ca-certificates \
curl

RUN mkdir /octant && cd /octant && curl -o octant.deb -L https://github.com/vmware-tanzu/octant/releases/download/v0.8.0/octant_0.8.0_Linux-64bit.deb && dpkg -i octant.deb

ENV OCTANT_LISTENER_ADDR=0.0.0.0:8080
ENV OCTANT_DISABLE_OPEN_BROWSER=true

VOLUME ["/root/.kube"]
ENTRYPOINT ["octant"]

 

Para crear la imagen de Octant hacemos lo siguiente:

docker build . -t aredan/octant

El resultado será una imagen en Docker con el nombre aredan/octant la cual podemos usar de la siguiente manera:

docker run -it -p 8080:8080 -v /home/ariel/.kube/:/root/.kube/ aredan/octant

Ya Podemos acceder al Dashboard de Octant, recordar que Octant utiliza el kubeconfig que este en el home directory especificado en el Docker run y que solo tendrá acceso al cluster asociado a ese config. Aun no existe manera de cargar configuraciones de conexión a cluster independientes al config del usuario.

http://localhost:8080

Partiendo de este punto lo siguiente seria entender como Octant encaja en el día a día de un administrador de Kubernetes o un desarrollador que quiere entender como una actualización afecta su aplicación corriendo en k8s.

Aquí un video de VMware Cloud Native Apps con bastante información acerca del proyecto.

https://www.youtube.com/watch?v=D5PLsXP9aPc

0

NY/NJ – VMUG UserCon.

Hace ya 2 semanas (¿?) tuve la oportunidad de asistir al UserCon en New York, tener en cuenta que no pertenezco a ningún VMUG y que no había asistido a un VMUG meeting o a un UserCon anterior a este.

Si se es apasionado a la tecnología este es un evento al que no se puede faltar, lamentablemente en mi caso tuve que realizar un viaje desde RD a NY. La experiencia de reunirse con personas igual o más apasionadas a la tecnología es revitalizante, muchas personas (y no soy una excepción) a veces nos desconectamos un poco de las metas y caemos en una rutina que cuando nos damos cuenta ya han pasado varios meses y tenemos que retomar las cosas.

Imagínense un mini-VMworld donde asisten los partners y tenemos varios salones donde se están exponiendo temas de vanguardia (NSX, VSAN y seguridad por mencionar algunos) por personas calificadas para esto, el tema comercial existe y los representantes de ventas están ahí, pero se tiene la libertad de evitarlos como he hecho yo. En mi caso me tome la libertad de asistir a las sesiones relacionadas con NSX ya que es la tecnología en la cual me estoy enfocando más últimamente.

Los TechTalk no podían faltar, esta vez liderados por Ariel Sanchez (brother-in-name!) y para sorpresa de muchos Stalin Peña realizo una presentación sobre Micro-Segmentación con NSX en Español, por lo que pude escuchar es la primera vez que un UserCon tiene un espacio donde se habló en español.

En resumen, he quedado fascinado y planeo volver.

0

NSX Controller en estado DEPLOYING permanente!

La razón del porque el despliegue del primer controlador de NSX fallara en mi LAB fue debido a que el disco en mi R710 se llenó. No creo que esto pase a menudo en producción.

En fin, después de levantar todo el AutoLab y que arrancaran las VM dentro de los Nested ESXi, veo que el estado del controller-1 es deploying y nunca paso de ahí. La gran idea fue detener el Manager, detener el controller-1 (la VM) y borrarla del inventario/disco. En vano, ya que cuando inicie el Manager este seguía con el objeto registrado y en el mismo estado.

Un poco de Google-fu me mostro que otros pasaron por lo mismo y que la solución propuesta es hacer un DELETE usando el API REST de NSX.

Ummmm API, con que se come eso?

Luego de intentar hacer el DELETE desde el navegador de forma normal, entendí que tenía que leer la documentación para saber cuál era la manera en que esto de REST funcionaba. La forma más efectiva para una persona del área de administración es instalando un add-on de Mozilla Firefox (en mi caso Firefox, si usas Chrome también existe un app).

Un documento importante para leer es el NSX API Guide (https://pubs.vmware.com/NSX-6/topic/com.vmware.ICbase/PDF/nsx_604_api.pdf), el cual en la página 25 tiene el siguiente texto:

 

Realizando una llamada API podríamos configurar todo un ambiente de conectividad basado en NSX pero lo que me extraña es que no exista la opción de un borrado forzoso desde Web Client en la sección de NSX.

No pude capturar imágenes realizando los pasos desde el RESTclient que instale en Firefox, si realizamos una búsqueda en Google uno de los enlaces que me llevaron a la solución fue https://communities.vmware.com/thread/522857?start=0&tstart=0 y la única diferencia es que este es el segundo controller desplegado.

Otro enlace con más información es http://blog.jgriffiths.org/?p=1198 en el cual tenemos imágenes usando el RESTclient.

0

Aplicaciones para vExpert 2015 abiertas – Suerte!

Ya es noticia vieja que está abierto el formulario para vExpert 2015, y me emociona claro, pero al igual que el año pasado cuando también leía sobre la llegada del periodo donde se seleccionan los vExpert y no sabía que decir, que describir o que era valioso de “mis contribuciones”, lo mismo me pasa este año. Como comentaba en el VMworld 2014 donde tuve la oportunidad de hablar en un TechTalk (junto a otros vExperts de habla Hispana), sinceramente no sé cómo mantener la posición de vExpert.

Así que ahí vamos otra vez a llenar el formulario, lo único diferente esta vez es que usare el Fast Track. Suerte a todos!

http://blogs.vmware.com/vmtn/2014/11/vexpert-2015-applications-open.html

0

Actualizando Pernixdata FVP de 1.5 a 2.0

Hace varios días que está disponible para la descarga la nueva versión de PernixData FVP, no tenemos que ser magos para saber que inmediatamente queremos actualizar a esa versión para jugar con las nuevas funcionalidades.

El primer paso es mover todas las VM que están en modo Write Back a Write Through, una vez que todas esas VM están en este modo (lo podemos ver en Status) podremos actualizar el software de manejo (FVP Management Server) el cual es sorpréndete lo fácil que lo podemos actualizar contando con las avanzadas operaciones que FVP puede lograr en un ambiente de vSphere.

Cuando ejecutamos el instalador, automáticamente nos informara que estamos realizando una actualización de un servidor de manejo y procederemos haciendo click en Yes.

 

Aceptamos el EULA y hacemos click en Next para ver una ventana donde nos indica que esta hacienda un resumen de la instalación y no podemos volver atrás ya que el botón está deshabilitado.

Ya instalado el software de manejo, el próximo paso es actualizar el componente que se instala en los host de ESXi, la versión actual en mis equipos es la 1.5 y lo podemos revisar usando un comando en el mismo ESXi.

Para ser exacto, tienen instalada la versión 1.5.0.4-28301.

En el caso de los ESXi, el módulo de FVP debe ser desinstalado para luego instalar la versión nueva. La instalación anterior debe crear el script de desinstalación y solo lo debemos copiar a /tmp para luego ejecutarlo. Otro requerimiento es que los hosts deben ser puestos en modo mantenimiento para realizar estas operaciones.

Instalamos la nueva versión del módulo.

Debemos respaldar la configuración del ESXi ejecutando el auto-backup.sh que está en /sbin.

Por último, debemos sacar el host de mantenimiento, no creo que necesite un screenshot para esto!!

Este procedimiento se realiza por cada host ESXi que forma parte del cluster de FVP. Repeat!!