2026, y maquetar un libro técnico sigue siendo un infierno Cómo un libro sobre Kubernetes acabó teniendo su propio CI
He escrito un libro sobre Kubernetes y sin quererlo he construido una pipeline para generar diferentes formatos del mismo.
Quizá lo difícil no fue escribirlo
He escrito un libro sobre Kubernetes y, sin quererlo, he acabado construyendo una pipeline para generarlo en varios formatos.
Sí, he escrito un libro sobre Kubernetes.
Hoy quiero contaros cómo ha sido el proceso. Me gustaría decir que fue fácil, pero no lo fue.
¡Gracias por pasarte por aquí! 🙌
Si te interesa seguir recibiendo guías prácticas sobre Kubernetes, Azure, DevOps y contenedores directamente en tu email…
Suscríbete gratis y no te pierdas ninguna novedad. 🚀
Por qué en español
Llevaba tiempo dándole vueltas a cómo escribir más sobre Kubernetes, y en español.
Mi día a día se basa en conversaciones en inglés. Compro libros técnicos en inglés. Estudio las certificaciones en inglés. Pero hay momentos en los que estoy tan cansado que leer en otro idioma es sencillamente imposible. Y leo a menudo a gente frustrada buscando buena documentación en español.
Un día se lo comenté a mi amigo Eric: escribir un libro sobre Kubernetes. Una forma de darle salida a lo que sé de manera ordenada, y contado para que fuera más sencillo entender cómo funciona.
Eric ha acabado escribiendo el prólogo.
La primera bofetada
Empecé por el índice. Me salió uno tan grande que habría necesitado más de 2.000 páginas para publicar algo decente.
Después de aquel golpe conseguí definir una primera versión de lo que podía ser el índice de un libro básico sobre Kubernetes.
Elegí escribir en Google Docs. ¿Por qué no? Un editor fácil, sencillo, online.
Lo que hoy es el libro no se parece ni de lejos a lo que empecé escribiendo. Durante el último año ha habido muchísimas iteraciones hasta llegar a lo que podréis leer el 1 de septiembre.
Por el camino monté tablas infinitas explicando propiedades y funcionalidades. Párrafos infumables donde era imposible seguir el hilo.
Al final creo que he construido un hilo que sí ayuda a entender cómo funciona Kubernetes: el libro te presenta un sistema, una tienda con varios componentes, y cada componente se despliega usando una funcionalidad distinta. El formato de pregunta y respuesta también ayuda a fijar los conceptos.
Quizá alguna de esas preguntas te sirva en tu próximo proceso de selección. O para resolver un problema en tu clúster a las tres de la mañana.
Leer no basta
Mientras escribía, le daba vueltas a otra cosa. Vale, tienes un libro sobre Kubernetes.
Pero le falta algo.
Cuando trabajas con Kubernetes no lo haces de manera teórica. Lo haces con las manos.
«No temo al hombre que ha practicado 10.000 patadas una vez, sino al hombre que ha practicado una patada 10.000 veces.» — Bruce Lee
La primera opción era proporcionar un setup que pudieras ejecutar en local. Pero no lo veía. Mi ordenador personal es muy viejo: me sirve para el correo y poco más, desde luego no para levantar un clúster.
Y esa es exactamente la gente a la que quiero ayudar. No quiero crear más frustración alrededor de Kubernetes y su ecosistema de herramientas: ya hay bastante.
Al final di con la plataforma que me parecía perfecta, y preparé 52 laboratorios que puedes hacer desde el navegador. Sin setup, sin instalar nada. Cinco de ellos son retos: te entregan un clúster con algo roto y tienes que arreglarlo.
Si te va la marcha, en el repositorio de GitHub también puedes levantar la tienda entera en tu máquina.
Dónde publicarlo
Con una versión muy preliminar empecé a mirar cómo distribuirlo: venta directa, Leanpub, Gumroad, Amazon.
Una cosa tenía clara: quería versión digital y papel. Sí, papel. Leo en los dos formatos según lo que quiera leer y el momento. Y hay días en los que intento dejar de lado las pantallas — la experiencia del papel no se puede comparar.
Al final me decidí por Amazon KDP: digital, papel y una red de distribución que llega a casi cualquier país del mundo.
Y aquí empieza la parte que no me esperaba
El servicio de autopublicación de Amazon es genial. Permite a cualquiera publicar sin pasar por una editorial ni imprimir una tirada mínima.
La realidad de sus aplicaciones es otra historia.
Un único servicio. Cinco aplicaciones distintas.
Una para el libro digital. Otra para la tapa blanda. Otra para la tapa dura. Sí: son tres productos diferentes que se gestionan por separado. Los formatos que aceptan el digital y el papel tampoco son los mismos. Luego, otra aplicación para la información del autor. Y una quinta para gestionar el contenido A+ de las fichas.
Para más inri, Amazon no permite poner el libro en papel en preventa. Solo el digital.
El formato
Volvamos atrás. Había escrito el libro en Google Docs sin preocuparme por la maquetación, la tipografía ni el tamaño de página. Google Docs es estupendo, pero muy limitado para eso.
Amazon ofrece plantillas de Word. Dije: vamos a intentarlo.
Instalé LibreOffice y, tras el shock inicial de abrir una aplicación con tres millones y medio de botones —lo siento, cada día soy más fan de la sencillez—, empecé a maquetar.
Frustrante. Frustrante. Frustrante.
[FOTO: la captura de OpenOffice]
Estamos en 2026 y comprobé de primera mano lo difícil que sigue siendo maquetar un libro técnico.
Casi había llegado a la línea de meta, y era la maquetación la que amenazaba con ponerme la zancadilla e impedir que publicara.
La pipeline que no quería construir
Me puse a buscar soluciones, y me sorprendió la cantidad de caminos distintos que hay para resolver este problema. Lo cual confirma algo: cada uno lo resolvemos a nuestra manera.
Acabé pasando el libro a Markdown, generando el PDF con Typst —no con LaTeX— y el EPUB con Pandoc, más unos filtros en Lua que reordenan las figuras y sus pies. Todo orquestado desde un Makefile.
Parece una tontería, pero no lo es: la versión en papel tiene una configuración distinta a la digital. La numeración de páginas, las notas al pie, la posición de las imágenes. No es el mismo libro con otra portada.
Y aquí es donde esto dejó de parecerse a escribir y empezó a parecerse a mantener un repositorio.
Porque en cuanto tienes una compilación automática, quieres que falle cuando algo está mal. Así que fui añadiendo comprobaciones:
Que ningún YAML del libro sea inválido. Son cientos de líneas de manifiestos y no quiero que el lector copie algo que no aplica.
Que los manifiestos del libro no se desincronicen del repositorio.
Que ninguna referencia interna apunte a un sitio que ya no existe.
Que ningún texto de un diagrama baje de 7 puntos una vez escalado a la caja de la página. En pantalla se lee; impreso, no.
Que ningún diagrama use un carácter que no exista en la fuente.
Esa última es la que más me sorprendió, y la cuento porque me costó una tarde entera.
Pones un símbolo de aviso en un diagrama. En tu pantalla se ve perfecto. Pero ese glifo no existe en la tipografía que estás usando, así que el visor tira de la fuente de reserva — y no solo para ese carácter: arrastra el bloque de texto entero. Media frase cambia de tipografía sin avisar.
En pantalla no se nota. En papel, sí. Y en papel ya no se puede arreglar.
Las semanas siguientes fueron de iteración constante puliendo esas herramientas. No estaba escribiendo el libro: estaba construyendo la máquina que lo fabrica.
El 28 de julio
Recibí la primera prueba de impresión.
Tenía fallos. Pero la emoción con la que abrí el paquete es indescriptible. La voy a guardar, y probablemente la enmarque.
Estoy acostumbrado a construir soluciones digitales. Construir algo físico está a otro nivel.
Y después de pasar por todo el proceso, el precio de un libro técnico me parece otra cosa. Hay muchísimo trabajo detrás, y no solo del que escribe: también de toda la gente que se ocupa de cada detalle para que la experiencia del lector sea la que tiene que ser.
Lo que queda
Todavía faltan varias semanas hasta el 1 de septiembre. Sigo trabajando con una veintena de personas que, de manera totalmente desinteresada, me están ayudando a pulir detalles y a mejorar el libro. Gracias de nuevo, en serio.
Este proceso me ha hecho pasar por todo tipo de emociones. La bofetada del índice imposible. La frustración de OpenOffice. La tarde perdida detrás de un glifo. Y el paquete del 28 de julio.
Si me preguntas qué ha sido lo más difícil, no fue escribirlo.
Kubernetes 101 sale el 1 de septiembre. 350 páginas, 14 capítulos, 6 apéndices y 52 laboratorios en un clúster real.
Si este post te ha ayudado o aclarado algo, me harías muy feliz con un ❤️
Y si crees que le puede servir a alguien más… ¡compártelo! 🙌
PD 1: la lista de música que me ha acompañado ha sido esta:
PD 2: sí, he usado IA en el proceso. La considero una herramienta que, usada como toca, reduce los tiempos de creación. No ha escrito el libro por mí: el texto y las decisiones son míos, y los errores que queden, también.
PD 3: el capítulo gratis se ha hecho más grande. Ahora son 28 páginas y tres bloques: «Antes de empezar», «Arquitectura de Kubernetes» y el «Apéndice D: El clúster por dentro», con sus ocho diagramas. Si ya te lo descargaste, vuelve a bajarlo: https://www.javivela.dev/libros/kubernetes-101/downloads/Javier-Vela-Kubernetes-101-Arquitectura-de-Kubernetes.pdf