Hace un par de semanas estuvimos trabajando con Docker. El trabajo era bastante sencillo pero me volví loco buscando como configurar el proxy en Docker y lograr que funcione, ya que sin eso no podía salir a buscar la imagen al repositorio de imágenes.
Tenemos dos opciones, crear un drop-in o modificar los archivos de configuración. Ambas son igual de validas, personalmente me inclino por la primera.
Crear un drop-in
1. Ejecutamos el siguiente comando para crear el drop-in sudo mkdir /etc/systemd/system/docker.service.d
2. Creamos un archivo que agregue la configuración de HTTP_PROXY y HTTPS_PROXY en /etc/systemd/system/docker.service.d/http-proxy.conf
[Service] Environment="HTTP_PROXY=http://USUARIO:PASSWORD@IP_PROXY:PROXY_PORT/" Environment="HTTPS_PROXY=https://USUARIO:PASSWORD@IP_PROXY:PROXY_PORT/" Environment="NO_PROXY= hostname.example.com,1.2.3.4" Un ejemplo de esto sería: Environment="HTTP_PROXY=http://nachogon:PASSWORD@1.2.3.4:8080/"
A fines de 2018 me tocó ser parte de un proyecto que requería que aprenda y certifique toda la suite de NSX, en Enero de 2019 terminé de certificar el examen VMware Certified Advanced Professional – Network Virtualization 6 (Deploy) y pude trabajar con eso por algunos meses. Entre abril de 2019 y mayo de 2020 estuve alejado de NSX por motivos laborales, durante ese año VMware decidió discontinuar la versión del producto que yo conozco (NSX-V) y darle foco a NSX-T, acompañando su visión Any App, Any Device, Any Cloud. Para no quedarme atrás estuve investigando, y algo que me sirve a mi es hacer paralelismos con lo que entiendo. En algunas líneas quiero compartir cuales son las diferencias entre NSX-V y NSX-T para que puedas “pasar tu conocimiento” haciendo algunas equivalencias y/o diferencias.
Arquitectura
Al igual que en NSX-V, NSX-T Cuenta con 3 planos (Management, Control, y Datos) pero en esta nueva versión hay algunas diferencias.
Management Plane
El Management Plane es el encargado de la administración de NSX. En NSX-V era un solo appliance (OVF) que después se registraba contra vCenter y hacia el deploy del control plane y preparaba los hosts, manteniendo un mapeo 1 a 1 entre el vCenter y el NSX Manager. El deploy de NSX-T comienza del mismo modo (instalando un appliance) pero no requiere un vCenter para funcionar. Adicionalmente ahora el NSX Manager está distribuido en un cluster de 3 virtual machines. En la tabla a continuación podemos ver algunas diferencias entre ambos productos:
Sin embargo, el NSX Manager (Cluster) sigue siendo responsable de preparar hosts, crear nuevos logical switches, crear VMs de NSX Edge, al igual que proveer la API y la línea de comandos centralizada.
Control Plane:
La mayor diferencia entre NSX-V y NSX-T en relación al plano de control es el hecho de que ahora corre en las mismas máquinas que el management Management Plane. Adicionalmente al no existir el concepto de Distributed Logical Router, la máquina de control del DLR no es necesaria.
Plano de datos – Encapsulación y Switching:
La mayor diferencia entre NSX for vSphere y NSX Transformers a nivel encapsulación dejamos de usar el protocolo VXLAN y pasamos a usar el protocolo GENEVE. Adicionalmente, NSX-V requeria MTU 1600 para funcionar y ahora requiere 1700. A continuación dejo algunos detalles extra:
Respecto a los distributed switches, para NSX-T solo en entornos VMware se recomienda usar vSphere vDS, si vamos a usar KVM estamos limitados a usar N-VDS.
Plano de datos – L2 Bridging:
Una vez más, al no existir la VM del DLR, el Bridging se modifica y se crean los bridge nodes (dentro del kernel para los hipervisores). Adicionalmente podemos crear bridge clusters para proveer redundancia.
Plano de datos – Routing:
Estas son algunas de las diferencias entre NSX-V y NSX-T a nivel routeo.
Esto me costó un poco entenderlo: Tanto el Service Router como el Distributed Router existen dentro de los logical routers (T1 y T0) Es decir, en un Logical Router T0 vamos a tener un componente del Distributed Router y un Componente del Service Router: – El distributed router vive en el kernel de todos los hipervisores (al igual que el DLR) – El service router vive en los edge nodes (debido a que hay servicios Norte-Sur que no son distribuidos, por ejemplo: NAT)
Adicionalmente, los Logical router Tier-0 corren sobre los recuirsos del Edge Cluster.
Plano de datos – NSX Edge
Ahora cada vez que creas un NSX Edge, vas a necesitar un NSX Edge cluster, como decíamos antes los Logical Router Tier-0 corren en los recursos del Edge Cluster, por más que tengas un solo NSX Edge, necesitas crear un Edge Cluster. Otro cambio importante a nivel NSX Edge es que ahora podemos instalarlo sobre servidores bare metal y no solo como VMs. Esto es sumamente interesante si tenemos en cuenta el partnership de VMware con Nvidia, Project monterey y el avance de ESXi on ARM, ¿Te imaginas corriendo un NSX edge en un raspberry pi?, no es algo tan lejano.
Seguridad
Algunas de las mejoras a nivel seguridad.
Cabe aclarar que el identity firewall solo funciona con VMs windows que tengan active directory (Windows 10 y Windows 2019 están soportados)
Migración
De momento exiten dos modos de migración: Migración en paralelo: en otras palabras significa tener NSX-V y NSX-T en paralelo, esta opción está buena si aprovechamos un recambio de hardware o un upgrade de versión. La migración In place sirve para entornos que es dificil el recambio, esto es un estilo Lift and Shift.
VMware recomienda contactar a PSO para revisar los pasos previos a la migración.
Conclusión
Por más que NSX for vSphere es un producto super robusto, está limitado al SDDC de VMware vSphere. NSX-T es un producto concebido para el Multi-Cloud, teniendo en cuenta productos Cloud Native como Kubernetes. Como se prevee que para 2025 el 60% de las empresas van a tener sus Workloads en la nube, sería una buena idea empezar a considerar NSX-T para llegar al Multi-Cloud
Espero que te haya servido, por favor comentame que te pareció.
Hoy, 6 de octubre VMware sacó la nueva versión de vSphere 7 Update 1, esta versión tiene algunos cambios sobre componentes clave de vSphere (Como ser DRS) por lo que me gustaría hacer una revisión rápida de estas actualizaciones.
vSphere Clustering Service (vCLS)
Para contarte que es, primero te cuento que viene a resolver: Algunos servicios a nivel cluster en vSphere (por ejemplo DRS, vSphere HA o vCenter HA) dependen de vCenter, si por algún motivo vCenter falla (algo que queremos evitar a toda costa, pero que todos hemos visto) estos servicios se pueden ver afectados. vSphere Clustering Service agrega un plano de control distribuido (similar al de NSX-V) de hasta 3 máquinas virtuales (basadas en Photon) que forman un cluster de quorum y ejecutan y controlan los servicios a nivel cluster de vSphere
Esta feature me parece algo hermoso. Lo que hace es permitirte presentar storage de vSAN entre distintos clusters dentro del inventario de vCenter. Te da la posibilidad de escalar hasta 64 hosts por cluster y es completamente agnóstico de hardware (siempre y cuando sean nodos vSAN ready)
Ya sabemos que VMware está empujando fuerte para meterse al mercado de Kubernetes. Algunas de las mejoras que implementaron en esta nueva versión de Tanzu Kubernetes Grid (TKG) service (El Kubernetes engine de VMware) son: Bring your own Networking/Storage/Load Balancer Le permite a las organizaciones aprovechar sus inversiones y conocimiento en Plugins para Kubernetes, siendo posible utilizar productos nativos de VMware (NSX/vSAN/etc.) o productos de terceros.
vSphere Ideas
Ahora los clientes con un contrato de soporte activo pueden cargar feature requests desde el vSphere cliente. Este cambio está muy bueno desde la perspectiva del usuario final, ya que antes el proceso era tedioso y poco claro.
Optimización para Monster VMs
Se revisaron los máximos de vSphere y ahora soporta hasta 24TB de memoria y 768 vCPU en una sola VM, teniendo en cuenta monster VMs.
Adicionalmente, se aumentó el máximo de hosts por cluster a 96.
Por último, aunque no es una feature es un gran esfuerzo de todos los equipos de VMware, se revisó la terminología que usa la suite para hacerla más inclusiva. Evitando términos como Master y Slave, siguiendo con la movida que arrancó en Silicon Valley a Raíz del Black Lives Matter.
Esta semana fue la edición 2020 del VMworld y hubo una palabra que se repitió más que nada: Kubernetes. El año pasado VMware compró Pivotal y a los pocos días anunciaron, Project Pacific, su re-ingeniería de la plataforma. Este año tuve la suerte de hacer cursos de vRealize Automation 8 y algo que me llamó la atención es que lo que antes eran servicios, ahora se maneja con pods dentro de los appliances.
Cómo hasta ese entonces no había visto mucho de Kubernetes, más que alguna charla y o algo en la facu, me decidí a investigar y “enseñarme” cómo funcionan.
Me gustaría compartirles este glosario con una descripción para que todos puedan entender que es este servicio que llegó para quedarse. Al final del post, comparto algunos recursos que me sirvieron para aprender y son 100% gratuitos.
¿Qué es Kubernetes?
Kubernetes es una plataforma Open-Source para administrar y orquestar containers que facilita la configuración declarativa y la automatización.
¿Quién desarrolla Kubernetes?
Kubernetes comenzó como un proyecto de Google y lo hicieron Open-Source en 2014, actualmente lo mantiene Cloud Native Foundation y los mayores vendors de tecnología tienen sus implementaciones. Por ejemplo RedHat con Openshift o VMware con Tanzu, entre otros.
Kubernetes en griego significa timonel, por eso el logo es un timón.
¿Por qué Implementar Kubernetes?
Para responder esta pregunta hay que ir un par de años atrás en el datacenter y entender cuáles son las problemáticas que viene a resolver.
Si nos fijamos en la primera etapa: todos los servidores eran físicos (bare metal), es decir, por cada aplicación que manteníamos necesitábamos tener un servidor con sus recursos (CPU/Memoria/NIC’s/Storage), un sistema operativo y sus aplicaciones: Este modelo aumentaba los costos de hardware, mantenimiento y era poco resiliente a fallas. Sumado a esto, la instalación y configuración de servidores bare-metal era (y sigue siendo) un proceso tedioso y lento.
Para resolver ese problema llegó la virtualización: La virtualización permite colocar múltiples máquinas virtuales (VMs) en un solo servidor físico (Hipervisor) esto permite consolidar recursos (CPU, Memoria, Storage) , acelerar tiempos de aprovisionamiento y da un mayor nivel de seguridad ya que una VM no puede acceder a los recursos de otra VM. Cada VM tiene su propio sistema operativo y aplicaciones.
Containers: Los containers son parecidos a las máquinas virtuales, pero tienen aislamiento flexible, por lo que comparten el sistema operativo entre distintas Apps. Al igual que las VMs los containers tienen su propio CPU, Memoria, tiempo de procesamiento y demás, pero no dependen de la infraestructura, por lo que son portables.
Adicionalmente, dentro de cada container están resueltas todas las dependencias de una aplicación: es decir si yo necesito instalar LAMP debería tener alguna versión de Linux, Apache, MySQL y PHP. El container se va a asegurar de que las versiones de Apache, MySQL y PHP sea la misma en cualquier lugar que corra el container. Lo que garantiza la portabilidad. Por último, los containers fueron concebidos con la agilidad en mente, por lo que la automatización es 100% compatible. Otra cosa importante, como las Máquinas virtuales tienen el hipervisor los containers tienen el Container Engine. En este caso vamos a hablar de Docker.
En este video dan una explicación muy buena del porqué del nombre containers.
Ahora sí, ¿por qué Kubernetes? Es sabido que todos los servidores pueden fallar, y nuestro trabajo como profesionales de IT es evitar que fallen. Kubernetes está pensado desde esa premisa, sabiendo que nuestros servicios van a fallar, nos da la posibilidad de controlar el cómo se va a comportar nuestra infraestructura cuando fallen.
– Balanceo de Cargas nativo: Podemos exponer un container por IP de servicio o DNS. Si el trafico es alto Kubernetes permite balancear la carga. – Orquestación de storage: Permite automatizar la provisión de storage a tus containers. – Rollouts y Rollbacks automáticos: Permite definir manifiestos YAML con el estado deseado de nuestros containers. – Self Healing: Kubernetes reinicia, reemplaza y mata containers en base a su estado.
Kubernetes es la clave para dejar de tratar a nuestros servidores como Mascotas y empezar a tratarlos como ganado.
¿Cómo funciona Kubernetes?
Cuando implementas Kubernetes tenés un cluster. El cluster es un conjunto de máquinas workers, o nodos, que va a correr nuestros containers, todos los clusters tienen al menos un nodo. En Kubernetes los nodos ejecutan Pods (que sería un container de containers) La implementación también tiene un plano de control que supervisa y administra los nodos y los pods. En entornos productivos, el control cluster tiene varias máquinas master y también múltiples nodos para aumentar la resiliencia del cluster.
Acá dejo un diagrama
Veamos que hace cada componente:
Componentes del Control plane:
Los componentes del control plane toman decisiones sobre los demás nodos de Kubernetes. Por Ejemplo: definir donde va a correr cada Pod, validar si hay que agregar más replicas, etc.
Estos componentes se instalan en la misma máquina por lo general, y se pueden usar clusters distribuidos como dijimos antes. En estos servidores no se ejecutan containers de usuario.
kube-apiserver:Se encarga de exponer la API de Kubernetes, el frontend del control plane de Kubernetes. Todas las interacciones que tengamos con nuestro cluster de Kubernetes van a ser mediante esta api.
etcd:Es la base de datos del cluster de Kubernetes.
kube-scheduler: Indica en que nodo se van a crear los pods.
kube-controller-manager: Unifica y administra los procesos del cluster de control. Algunos procesos que administra son: Node controller: Monitorea el estado de los nodes y notifica si alguno se cae. Replication Controller: Es el encargado de monitorear y aplicar la cantidad de replicas correctas para cada pod.
cloud-controller-manager: Te permite conectar tu cluster a un proveedor de servicios en la nube (Google Cloud, Amazon, Azure, etc) y separa los componetnes que interactúan con la nube de los que solo interactúan de forma local. Este componente solo existe en la nube, si tenés un entorno on-premise no lo vas a ver.
Componentes de los nodos:
Nota: los nodos tienen que correr sobre alguna distribución de Linux.
Container Engine: El software que se encarga de correr containers, por ejemplo Docker, containerd, podman, etc.
kubelet: Es un agente que corre en cada nodo del cluster y se asegura que los containers estén corriendo en un pod. Está hablando constantemente con el kube-apiserver para validar que los pods y servicios cumplan con el estado deseado. Adicionalmente ejecuta las acciones que le pasa el apiserver.
kube-proxy: es un proxy de red que corre en cada nodo. Se encarga de mantener las reglas de red en cada nodo. Esas reglas permiten que los pods puedan tener conectividad fuera del nodo.
Pods: es un grupo de uno o más containers, como me explico mi queridísimo Guille Deprati, es un container de containers.
Algo que a mi me sirvió mucho para entender la arquitectura de Kubernetes es compararlo con lo que entiendo y conozco. Cómo soy administrador VMware me sirve hacer la equivalencia entre Kubernetes y vSphere.
Otro recurso importante es el Container Registry: Basicamente es un repositorio de imagenes de containers (container images) a partir de las cuales vamos a crear nuestras pods. Existen los Registros Públicos como ser Docker Hub y podemos tener registros privados dentro de nuestra organización (Red Hat Quay, Harbor, etc). Los cloud providers (AWS, Azure, Google Cloud, Alibaba) probeen su servicio de container registry.
Recursos de estudio:
Los recursos que usé durante estos meses fueron los siguientes:
Hace rato que no escribo nada y quería hacer algo sencillo y apto para todo público. Cada vez son más las personas que empiezan a estudiar programación y a veces está bueno tener un tutorial explicado en lenguaje amigo.
Prerequisitos
Cómo dije antes, vamos a necesitar tener una máquina virtual con linux para este tutorial, voy a poner los comandos para el mundo RHEL y el mundo Ubuntu
Ubuntu
Primero vamos a actualizar el listado de paquetes. $ sudo apt update
Desinstalamos versiones viejas. $ sudo apt-get remove docker docker-engine docker.io containerd runc (Si recién instalas la máquina, apt-get debería decirte que esos paquetes no estan instalados).
Instalamos los paquetes que permiten a apt hablar HTTPS $ sudo apt install apt-transport-https ca-certificates curl software-properties-common
Agregamos la clave GPG del repositorio oficial de Docker
Por defecto, el comando docker solo puede ser ejecutado por el usuario root o un usuario en el grupo docker.
Para evitar tener que tipear sudo cada vez que usamos docker hay que agregar nuestro usuario al grupo de docker.
$ sudo usermod -aG docker ${USER}
Otra opción es agregar el usuario de forma explicita, por ejemplo: $ sudo usermod -aG docker username
Para aplicar los permisos es importante que hagamos logoff con el usuario y hagamos login nuevamente.
Una vez hecho esto. Deberíamos poder correr comandos de docker.
Por ejemplo: $ docker run hello-world
Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
9bb5a5d4561a: Pull complete
Digest: sha256:3e1764d0f546ceac4565547df2ac4907fe46f007ea229fd7ef28984514bcec35d
Status: Downloaded newer image for hello-world:latest
Hello from Docker!
This message shows that your installation appears to be working correctly.
...
