Tras un primer artículo (Dashboards de Kubernetes 1) sobre Dashboards de Kubernetes generalistas, y un segundo (Dashboards de Kubernetes 2) centrado en dashboards específicos. Vamos a analizar aquellas herramientas que aunque no son exactamente dashboards integrados en kubernetes si que van a funcionar como clientes externos que dan acceso a la plataforma. Dashboards de Kubernetes Octant Está herramienta opensource de VMware (Con más de 3100 estrellas en github) y dentro del marco de herramientas VMware-Tanzu, está orientada a servir de herramienta explicativa de como está configurado y diseñado un entorno Kubernetes. La herramienta funciona como un servicio web, por lo que puede ponerse como un servicio o ejecutarse en la máquina local con la condición de que se disponga de un .kube/config configurado con un usuario con permisos suficientes. Tanto en octant como en el resto de entornos probados hemos usado el usuario admin. Como se instala Nos descargamos el .deb o el .rpm de https://github.com/vmware-tanzu/octant/releases y lo instalamos con las herramientas del sistema operativo, si tenemos el .kube/config para acceder al cluster a revisar basta con ejecutar octant desde la linea de comandos. Características Dispone de un limitado conjunto de los objetos de Kubernetes, suficiente para los objetivos de dicha aplicación, pero incompleto para un gestor de Kubernetes. En el siguiente gráfico podemos ver la lista de eventos que se muestra como un elemento más del menú de objetos. Pese a la limitación anterior y que no permite la modificación de los elementos, si dispone en cada elemento de una pestaña “Resource Viewer” donde se nos mostrará el estado del objeto examinado y de todos aquellos relacionados, algo que se ella a faltar en los gestor que hemos visto anteriormente y que nos permite discernir de un solo vistazo donde tenemos un problema con un servicio, como puede ser en el siguiente ejemplo: Otro ejemplo más de Resource Viewer Facilidad de uso Cumple sin problemas con su capacidad de herramienta de demostración, pero a la espera de que su diseño basado en plugins de frutos (extensiones que nos permita una gestión de Kubernetes), no es una herramienta que salga de su planteamiento original. Kontena Aplicación de escritorio no opensource, actualmente tiene versión gratuita. Sin embargo la versión que vamos a tratar es bastante completa. Como se instala Directamente desde la web del proyecto podemos descargar un archivo .appimage que es un autocontenido que puede ejecutarse en cualquier plataforma (es […]
Etiqueta: kubernetes
Dashboards de Kubernetes 2
Tras un primer artículo (Dashboards de Kubernetes 1) sobre Dashboards de Kubernetes generalistas, este artículo se centra en aquellos dashboards que están orientados a ciertas necesidades. Concretamente nos centraremos en tres dashboards que van a tres necesidades: Ver el estado de un gran número de pods, ver las relaciones entre objetos y obtener una visión de conjunto sobre una plataforma kubernetes sobre docker. Dashboards de Kubernetes Kube-ops-view Con 1200 estrellas en Github este proyecto nos presenta un dashboard muy básico pensando en grandes granjas de servidores, en donde tengamos un importante volumen de pods que necesitemos revisar de un vistazo. Como se instala Creamos un espacio de nombres para instalar kube-ops-view: Creamos una cuenta de sistema con capacidades de administrador Y realizamos la ejecución de un despliegue junto con un servicio para su publicación Pese a ser un único servicio (sin autenticación, importante) su contenedor tiene un tamaño parecido al de las soluciones anteriormente mostradas: Por lo que su despliegue ha de ser rápido. Características Su interfaz, mostrado en la siguiente figura es mínimo: Sin opciones de entrar en los objetos o de editar, la información aparece al pasar por encima de las “cajas”. Facilidad de uso Claramente limitado para el que se inicia en Kubernetes o quiere información adicional sobre los objetos, pero muy útil para el que quiere visualizar de golpe grandes volúmenes de pods. Kubeview Aunque con solo 150 estrellas en github, este proyecto se centra en representas las relaciones entre objetos en Kubernetes. Siendo muy interesante para demostraciones. Como se instala Hasta que se desarrolle el Helm Chart (https://github.com/benc-uk/kubeview/tree/master/deployments/helm) Se instala en el espacio de nombre “default” instalando dos ficheros: El primer fichero incluye la cuenta de usuario kubeview y los permisos correspondientes, el segundo el despliegue junto con un servicio tipo “LoadBalancer”. El tamaño de la imagen es pequeño y su despliegue es rápido. Características Kubeview es simple y su configuración gráfica lo hacen muy interesante para enseñar Kubernetes o presentaciones. Su menú está unicamento conformado por un selector de espacio de nombre y un tiempo de refresco de la ventana. Cuando seleccionamos un espacio de nombres nos va a mostrar todos los objetos que dicho espacio de nombres posee. De está manera podemos de un solo vistazo ver las relaciones y elementos como las IPs de publicación de los servicios. Cuando seleccionamos un objeto (por ejemplo un servicio) muestra información descriptiva del mismo. Facilidad […]
Dashboards de Kubernetes 1
Uno de los principales problemas al empezar a trabajar con Kubernetes es la falta de herramientas comprensibles sobre Kubernetes. Los dashboards de kubernetes (las herramientas de gestión de la plataforma) se convierten en el punto de entrada para muchos que quieren aprender Kubernetes. En esta serie de articulos vamos a examinar algunos de los dashboards más usados, inluyendo algunos más específicos (octant, kontena) y dejando aquellos orientados a PaaS/CaaS (Rancher, Openshift) ya que en ambos casos se sobrepasa el alcance de herramientas de entrada a Kubernetes. Dashboards de Kubernetes Kubernetes Dashboard Con más de 6000 estrellas en GitHUb, el dashboard oficial de Kubernetes es la opción estándar de este tipo de soluciones, a causa de las dependencias del mismo y su falta de compatibilidad con las versiones actuales de Kubernetes nos vamos a centrar en las versión v2-beta3. Como se instala Ejecutando el comando: Se instala en el espacio de nombre “kubernetes-dashboard” y para obtener las métricas utiliza el servicio “dashboard-metrics-scraper” que se instala en el mismo espacio de nombres. Se debe acceder vía IP external (servicio LoadBalancer o kubectl proxy), o configurar un Ingress con los mismos certificados SSL que la consola (lo que complica su despliegue). Los contenedores que forman parte de esta solución son: Por lo que su despliegue ha de ser rápido, ya que aunque son dos servicios son de reducido tamaño. Características Dispone de un interfaz limpio y claro, autenticación por token y un cuadro de mandos donde a un lado tenemos todos los elementos principales de Kubernetes y en la parte principal del panel una lista de los elementos seleccionados en el nombre de espacios seleccionado. Panel principal: Por comodidad dispone de un tema oscuro, de los elementos a los que permite acceder tenemos los roles de seguridad. Además cada elemento seleccionado dispone de dos acciones: editar y eliminar. Edición de roles: La acción editar nos da acceso al objeto que define el elemento seleccionado en formatos yaml o json. En ningún elemento hay definido un editor especifico que permita la gestión del objeto para los no conocedores de su estructura. Información del nodo: Cuando seleccionamos un nodo nos vuelca una gran cantidad de información sobre el mismo. Panel de control sobre un espacio de nombres: Al seleccionar un espacio de nombre sin seleccionar ningún elemento nos mostrará un cuadro de estado de dicho espacio de nombre con los elementos que lo forman y […]
Como publicar Kubernetes con External DNS, MetalLB y Traefik.
Kubernetes con External DNS, MetalLB y Traefik nos van a servir para que las aplicaciones web (en un entorno o no de microservicios) se publiquen, ya que los requisitos básicos son resolver por DNS el nombre del equipo y la ruta web que lleva a la aplicación. El gran mapa Tras los pasos realizados en K3s: Kubernetes más simple y Helm v3 para desplegar PowerDNS sobre Kubernetes vamos a darle forma a una solución Kubernetes más completa para que pueda publicar servicios bajo su propio dominio y ruta y que a su vez sea accesible desde el exterior. Y siempre usando los mínimos recursos en esta tarea. MetalLB MetalLB que nos permitirá emular la potencia de los balanceadores de los entornos Cloud, los requisitos de está solución son una versión de Kubernetes 1.13 o superior, que no exista otro balanceador de red operativo y que el controlador de red esté soportado en la lista indicada en https://metallb.universe.tf/installation/network-addons/, debemos tener en cuenta que K3s incluye flannel que está soportado y que en el caso de otros como Weave se requieren una serie de modificaciones. Para instalar MetalLB solo es necesario aplicar el archivo “yaml” que despliega todos los elementos: Y para activar MetalLB le creamos una configuración (archivo pool.xml) que tendrá la forma: Que al aplicar con k3s kubectl apply -f pool.yml configurará MetalLB para que en el caso de que existan servicios con loadBalancer utilicen una de las IPs definidas en el rango especificado (en este caso 192.168.9.240/28). MetalLB es una gran ventaja sobre otros tipos de soluciones locales, ya que no requiere del uso de SDN (como es el caso de Kubernetes sobre VMware NSX) o de servidores específicos para la publicación (como el caso de OpenShift, que ademas de SDN requiere de maquinas especificas para publicar servicios). Traefik Traefik es un servicio enrutador con múltiples características como son: Con K3s se despliega de forma automática Traefik al iniciar el nodo master, en el caso de Kubernetes se va a hacer a través de Helm y para la configuración necesitamos un archivo yaml como el siguiente: dashboard: enabled: “true” domain: “traefik-dashboard.DOMINIO” auth: basic: admin: $apr1$zjjGWKW4$W2JIcu4m26WzOzzESDF0W/ rbac: enabled: “true” ssl: enabled: “true” mtls: enabled: “true” optional: “true” generateTLS: “true” kubernetes: ingressEndpoint: publishedService: “kube-system/traefik” metrics: prometheus: enabled: “true” Esta configuración es muy parecida a la que despliega K3s y a la hemos añadido el dashboard donde podremos revisar el estado de […]
Helm v3 para desplegar PowerDNS sobre Kubernetes
En el artículo PowerDNS sobre Docker o Podman, fácil y rápido dejamos un punto pendiente sobre Kubernetes, esto es así porque la estructura de servicios de Kubernetes es mucho más compleja que la de Docker o Podman y por tanto hay que hacer un planteamiento completamente diferente. Empaquetar con Helm v3 Lo primero que debemos tener en mente es empaquetar aplicaciones para que su despliegue no requiera de amplios conocimientos sobre Kubernetes (hacer la vida al usuario más fácil) y lo segundo es que podemos tener muchos usuarios sobre el mismo entorno deseando querer la misma aplicación y no podemos crear un paquete para cada uno, debemos poder reutilizar el paquete creado. En Kubernetes el estándar de paquetes es Helm que nos va a permitir gestionar despliegues de forma fácil y siendo reutilizables por usuario, proyecto, etc. El paquete Helm está formado por: Helm v3 es la versión en desarrollo de Helm (en el momento de escribir estas lineas Helm va por la versión v3 beta3) pero que dispone de capacidades tan interesantes como gestión del ciclo de vida o no requerir de servicios integrados en Kubernetes para desplegar paquetes (para realizar algo parecido en la versión 2 ver Como lanzar un esquema (Chart) de Helm sin instalar Helm, que requiere de un job y un pod lanzador con Tiller, lo que representa una mayor complejidad). Usando Helm Una vez dispuesto nuestro cluster Kubernetes (ver Kubernetes: Crear un entorno mínimo para demos o K3s: Kubernetes más simple) procedemos a descargar en el nodo master el binario de Helm con: Y ya está, no hay que instalar nada y podemos instalar los paquetes que necesitemos directamente, eso si, hay que tener en cuenta que no crea automáticamente los espacios de nombres (namespaces) ya que se considera que eso no es una tarea de despliegue sino de gestión de la infraestructura.. En el caso de Powerdns, que tiene como dependencia una base de datos mariadb y al que podemos acoplar opcionalmente un dashboard con PowerDNS-Admin vamos a requerir este tipo de paquetes, porque son útiles si queremos que los clientes dispongan de su propio servidor DNS gestionado por ellos mismos. En próximos artículos veremos que además este servidor es integrable con External-DNS, que nos permitirá publicar en PowerDNS las modificaciones en los proxy de entrada de Kubernetes (por ejemplo un Ingress con Traefik). Para crear un paquete con la estructura mínima hacemos: […]
Kubernetes: aventuras y desventuras de parchear (kubectl patch).
Kubernetes es una potente herramienta de orquestación de contenedores donde se ejecutan muchos y diferentes objetos que en algún momento nos va a interesar modificar. Para ello Kubernetes nos ofrece un interesante mecanismo: patch que vamos a explicar y veremos que está lejos de ser una herramienta lo bastante potente como sería deseable. Operaciones de parcheo (sustitución) en Kubernetes Según la documentación de Kubernetes y las normas de la API de Kubernetes se definen tres tipos (con –type): Strategic Es el tipo de parche que usa Kubernetes por defecto y es un tipo nativo, definido en el SIG, sigue la estructura del objeto original pero indicando los cambios (por defecto unir: merge, por eso se conoce por strategic merge patch) en un fichero yaml. Por ejemplo si tenemos el siguiente servicio (en el fichero service.yml): Vamos a utilizar el comando kubectl patch -f service.yml –type=”strategic” -p “$(cat patch.yml)” –dry-run -o yaml que nos va a permitir realizar pruebas sobre los objetos sin el peligro de modificar su contenido en el cluster Kubernetes. Si queremos que dicho servicio escuche por un puerto adicional utilizaremos la estrategia “merge” y aplicaremos el siguiente parche (patch.yml): Como vemos, el parche solo sigue el objeto servicio hasta donde queremos realizar el cambio (el array “ports”) y al ser un cambio de tipo “strategic merge” se dedicará a añadirlo a la lista como se ve en el volcado del comando: Pero si en vez de “merge” utilizamos “replace” lo que hacemos es eliminar todo el contenido del subárbol donde estamos al indicar la etiqueta “$patch: replace” y en su lugar pone directamente el contenido del parche. Por ejemplo para cambiar el contenido del array usamos como “patch.yml”: En este ejemplo se elimina todo el contenido de “ports:” y en su lugar se deja el objeto definido después de la etiqueta “$patch: replace”, aunque el orden no es importante, la etiqueta puede ir detrás y tiene el mismo efecto. El resultado del anterior es: Por último “delete” que se indica con “$patch: delete” elimina el contenido del subárbol, aunque se le añada contenido este no es añadido. El resultado será el contenido de spec vacío: Merge Este tipo de parche es un cambio radical frente a “strategic” ya que requiere la utilización de JSON Merge Patch (RFC7386), se puede aplicar como yaml o json y se basa en un procedimiento de aplicación de cambios con a partir […]