El 1 de junio de 2025, durante las elecciones judiciales en México, mi equipo fue responsable de una misión crítica: garantizar la descarga, validación y publicación automatizada de resultados electorales provenientes del INE (Instituto Nacional Electoral). Este flujo de datos tenía que funcionar 24/7, con una frecuencia de actualización de cada 5 minutos, y con máxima seguridad y tolerancia a fallos.

Operamos bajo un entorno regulado y expuesto mediáticamente, donde cualquier retraso, inconsistencia o vulnerabilidad sería inaceptable. Para esto, diseñamos una solución de automatización sobre Kubernetes, combinando scripting en Bash, tokens de autenticación y firmas criptográficas GPG. Aquí les comparto cómo lo hicimos.

2. Desafíos Técnicos

• Alta disponibilidad: La solución debía ejecutarse cada 5 minutos, sin interrupciones, durante toda la jornada electoral.

• Seguridad de datos: Era indispensable garantizar la autenticidad y no-repudio de los datos publicados.

• Tolerancia a errores: El sistema debía manejar fallos parciales en servicios externos sin detener la operación general.

• Infraestructura controlada: El ambiente se desplegó sobre clústeres Kubernetes autoescalables con nodos específicos para tareas cron.

3. Solución Implementada

Decidimos implementar un cron job especializado en Kubernetes, responsable de:

1. Autenticarse con un sistema remoto mediante un API Token.

2. Recuperar el archivo de los resultados.

3. Verificar y validar digitalmente los datos recibidos usando GPG.

4. Publicar los datos procesados en uno micrositio (con backup inmediato).

4. Detalles de Implementación Técnica

Archivo YAML del CronJob en Kubernetes:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: resultados-electorales
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: recolector
            image: myregistry.com/electoral-job:latest
            imagePullPolicy: Always
            env:
            - name: API_TOKEN
              valueFrom:
                secretKeyRef:
                  name: electoral-secrets
                  key: api-token
            volumeMounts:
            - name: gpg-keys
              mountPath: /gpg
            command: ["/bin/sh"]
            args: ["-c", "/scripts/monitor.sh"]
          restartPolicy: OnFailure
          volumes:
          - name: gpg-keys
            secret:
              secretName: gpg-secret

El job se ejecuta cada 5 minutos utilizando una imagen liviana basada en Alpine, con herramientas mínimas necesarias, reforzada para evitar accesos no autorizados.

Mecanismo de seguridad adicional:

• Las claves GPG se inyectan como secreto de Kubernetes.

• Las salidas del script se redirigen a logs centralizados para auditoría.

• Las fallas se notifican vía webhook a un canal Slack monitoreado en tiempo real.

5. Resultados y Aprendizajes

• 🕔 100% de uptime durante más de 24 horas continuas.

• 🔐 0 incidentes de seguridad, gracias al control estricto de accesos y firmas.

• 📉 Carga minimizada gracias a imágenes optimizadas y nodos taintados solo para procesamiento.

• 🔁 Escalabilidad futura lista: el diseño permite extender el flujo a múltiples fuentes de datos judiciales o comiciales.

Este tipo de soluciones no solo demandan experiencia técnica, sino criterio operativo y sentido de urgencia. Lo que está en juego es la confianza pública y la responsabilidad institucional.

🚨 ¿Necesitas diseñar soluciones críticas como esta?

Si estás enfrentando un proyecto sensible en medios, gobierno o datos públicos, y necesitas:

• Consultoría para despliegues en Kubernetes

• Implementación de cron jobs confiables

• Diseño de infraestructura segura y autoescalable

📩 Contáctame para una sesión gratuita de diagnóstico técnico.
Haz que tu próxima implementación funcione como un reloj suizo, incluso bajo presión electoral.

Recientemente hemos estado haciendo PoC´s con Pulumi y Digital Ocean así que metimos a un tercero a la ecuación, ArgoCD, una herramienta de Delivery para Kubernetes.

A partir del PoC hecho con Pulumi y Digital Ocean instalamos ArgoCD en el cluster de Kubernetes creado y vinculamos un único repositorio con dos ramas, master y feature/python-simple-web para dos apps diferentes mypage y simple-web en ArgoCD, lo que hace difiere estas dos ramas son el namespace del proyecto, la imagen del contenedor y la url que nginx-ingress deberá administrar.

Esta nueva herramienta después de hacer todos los ajustes se vuelve divertida y amigable, como primer acercamiento puedo decir que tiene una agradable interface gráfica y que me hace pensar si dejaremos fuera a Pulumi para administrar el estatus deseado de los recursos creados previamente como deployments/services/ingress/configMaps etc, en el cluster.

A continuación les dejo unas capturas del PoC.

Branches Repositorio Git

ArgoCD Dashboard Applications

ArgoCD vista de red del app “mypage”

ArgoCD vista de arbol del app “mypage”

ArgoCD vista de red del app “simple-web”

ArgoCD vista de arbol del app “simple-web”

Vista en vivo de app “mypage”

Vista en vivo de app “simple’web” balance pod 2

Vista en vivo de app “simple’web” balance pod 1

Si requieres de mi ayuda para administrar tu infraestructura e implementar un sistema GitOps contáctame.

Puedes usar una gran variedad de software para llevarlo a cabo, lo que implica en algunos casos aprender un nuevo lenguaje, algo que Pulumi ha tomado en cuenta para su rápida adopción, por lo que si sabes Typescript, Go, Python, Javascript o .Net reducirás enormemente la curvatura de aprendizaje.

Había escuchado de Pulumi hace un año, hace unas semanas tome dos webinars  y las dudas que tenia sobre su uso, escenarios me animo a probarlo con una promo que obtuve en Digital Ocean por lo que inicie con la creación de un cluster Kuberntes usando Typescript. Pulumi te ofrece una version gratuita si únicamente tú usas el entorno.

La ventaja de esto que puedes ir haciéndolo poco a poco y esta es la lista ordenada de lo que fui administrando con mi código.

1. Creación del Cluster Kubernetes.
2. Creación de algunos namespaces, ex: staging, website
3. Creación de un primer Deployment con nginx en el namespace de staging.
4. Creación de un ClusterIP Service para el Deployment creado en el punto 3.
5. Una gran pausa para instalar Istio (muy complicado y tomaría mas horas) o nginx como Ingress
6. Después de decidirme en el punto 5 por nginx, procedí a crear el código para instalarlo como Ingress, con su namespace usando el Helm v3 Chart; esto me genero un LoadBalancer en Digital Ocean a su vez asignándome la IP Publica.
7. Creación de un Service Ingress para dirigir el tráfico del ingress-nginx creado en el punto 6 hacia el ClusterIP creado en el punto 4, puedes verlo en do.webmago.dev (puede no estar disponible en el futuro).

Ejecucion Paso 1 Pulumi

Revision Dashboard Digital Ocean

Dashboard Pulumi paso 1

Cabe señalar que para mantener mi entorno aislado y no interferir con mis configuraciones de mi equipo trabaje desde un contenedor de docker.

Tengo que aclarar que tuve algunos glitches con Pulumi al aplicar/actualizar cambios y al parecer es un comportamiento algo raro que tiene Digital Ocean, por lo que recibía errores y tenia que volver a ejecutar la actualización de cambios.

En mi experiencia, puedo decir que Pulumi reduce considerablemente su curvatura de aprendizaje y adopción permitiéndote administrar tu Infraestructura como Código con los lenguajes antes mencionados.

Para los clusters Kubernetes me auxilio de “Monitoring” (antes Stackdriver) en GCP o CloudWatch en AWS, o incluso Prometheus con Grafana.

Lo que hace de Weavescope un software Open Source tan peculiar no solo es ver métricas, sino pausar, detener, reiniciar un contenedor o acceder a la terminal del mismo para hacer algunas operaciones tal como si fuera una terminal remota.

Esta versatilidad de Weavescope me permite visualizar y hacer operaciones cuando solo cuento con un dispositivo móvil como una tableta o un iPad.

Weavescope ofrece varias alternativas de ser instalado, en mi caso donde uso VPS con docker-compose opte por esta version con algunos ajustes que no se mencionan en la version oficial, tal es el caso de la autenticacion, ya que de no contar con esto cualquiera que conozca la dirección de mi instalacion podria hacer un mal uso como detener o crear contenedores y vulnerar mi sistema.

Weaveworks la compañia creadora de Weavescope ofrece diferentes soluciones de automatizacion CI-CD, monitoreo y registros, una de las herramientas mas novedosas GitOps basado en Kubernetes.

No olvides contactarme si requieres asistencia en tus proyectos.

A continuacion dejo una serie de capturas de una de mis instalaciones de Weavescope.

Filtrando los recursos por contenedor

En la ficha del contenedor se observan varios botones para efectuar operaciones tales como adjuntar, acceder a la terminal, refrescar, pausar, detener el contenedor.

Esta version grafica es un atajo a la instruccion “docker exec -it dbadmin bash”

• Red/Black
• Blue/Green
• Rollout
• Canary

Me he inclinado por usar el segundo de la lista, el deploy Blue/Green, el cual te permite lanzar una nueva versión e ir redirigiendo tráfico de forma gradual a la nueva versión.

Existe una gran variedad de plugins en Codefresh uno de ellos, hacer un Deploy en tu entorno Kubernetes con Blue/Green, incluso hay un plugin y Howto para hacer un Canary Deployment.

Una de las ventajas de este plugin es que en caso de existir algun timeout, o error en el despliegue de la nueva version, la version actual no se ve afectada debido a que la nueva version es eliminada del clúster.

En caso de ser exitoso el despliegue el plugin en automatico inicia el proceso de redireccion del trafico hacia la  nueva version de forma gradual.

La integracion de este plugin en mis pipelines me ha permitido hacer despliegues sin caídas en entornos de producción de alto tráfico.

So, Kubernetes is deprecating Docker support and you’re either nervous or confused. That’s okay! I would like to help you understand what’s happening. A thread! 1/10

— Kat Cosgrove, but ✨festive✨ (@Dixie3Flatline) December 2, 2020

Quienes trabajamos con Kubernetes o en Desarrollo de Software hemos usado Docker para desarrollar y generar las imágenes que finalmente usaremos en nuestro clúster, por supuesto que existen mas proveedores compatibles con OCI (Open Container Initiative) y esto quiere decir que las imágenes que generamos en Docker cumplen con esta normativa.

Ayer 3 de Noviembre 2020, Docker publico un articulo (en inglés) detallando quá sucederá con este cambio dándonos una tranquilidad a toda la comunidad que usa la tecnología de contenedores.

What developers need to know about Docker, Docker Engine, and Kubernetes v1.20

En si, lo que se eliminará probablemente en un año será dockershim, por lo tanto, las imágenes que generes con Docker seguirán funcionando en tu clúster Kubernetes, el cambio es mas para los operadores y administradores de Kubernetes donde el acceso a la inspección de los contenedores usando comandos de Docker no podrán ser usados.

Así que mantén la calma y sigue usando Docker.

Lo anterior hizo que trabajara en la creación del espacio en GCR, generar los permisos IAM, ajustar todos los pipelines en Codefresh  para enviar las imágenes resultantes, exportar las imágenes mas recientes y descargadas y por ultimo hacer los cambios en el cluster Kubernetes para que los deployments pudieran descargar las imágenes durante el proceso de CI/CD o regeneración.

Quienes hemos trabajado con Kubernetes existe un parámetro ImagePullPolicy cuyos valores pueden ser Always o IfNotPresenty dependerá del comportamiento esperado tomando en cuenta estas recomendaciones.

Recientemente Docker anuncio a través de un correo electrónico  que haría cambios para las descargas y retención de imágenes en su servicio.

Los descargas anónimas de imágenes solo podrán hacerse 100 veces en 6 horas, las descargas de tus imágenes en tu cuenta gratuita se extiende hasta 200 cada 6 horas; las cuentas Pro y Team y Large no tienen esta limitante ver comparativo en su pagina de Precios, dicha política entro en vigor en Noviembre 2, 2020.

Por otro lado, las retenciones de las imágenes solo estarán disponibles por seis meses, por lo que si tu imagen no es actualizada o descargada en ese tiempo será eliminada, este ultimo ha sido pausado ya que entraría en vigor en noviembre 1, 2020; y será retomado a mediados del año 2021.

Como recordaran, tenia duda si realmente Codefresh daría de baja el servicio por falta de uso, o por que le estaba generando un costo enorme mantener varias imágenes de todos los que formamos su plantilla de clientes, algo que también Docker acaba de hacer con su servicio.

Creo que el costo de $5.00 US siendo Pro en Docker vale la pena para tener nuestro Hub de nuestras imágenes de forma privada.

Al momento de recibir la orden vía Webhook inicia el proceso de integración del código a través de las ordenes indicadas en el Dockerfile, con esta imagen y/o con la ayuda de otras se realizan pruebas unitarias que los desarrolladores acompañan con sus commits.

Muchos creen que Delivery y Deployment son lo mismo, sin embargo, Deployment es el siguiente paso a Continuos Delivery. En el proceso de Delivery, existe un paso manual, sin embargo, en el Deployment todo sucede de forma automática.

Inspired by Yassal Sundman’s blog post on Crisp’s Blog.

Tras el éxito del paso previo, viene el despliegue o liberación del producto final, Codefresh provee una vasta serie de plugins e imágenes para que no tengas que recurrir a pasos adicionales fuera de su entorno, para mis actuales proyectos en clusters Kubernetes hice uso de su imagen k8s-blue-green, esta me permite hacer despliegues de la version actual y sacar la version previa “del aire“.

Si todo ha ido bien, o mal, el mismo SaaS de forma nativa o haciendo uso de sus plugins puedes notificar via Slack o Telegram a tu equipo sobre el ciclo, haciéndolos participes y corresponsables.

¿Quieres emular un Delivery en esta plataforma?, sin problema, introduce el paso pending-aproval, y através de  Slack, el usuario indicado recibirá la notificación con las opciones para Aprobar o Declinar el proceso desde este medio o el Dashboard del SaaS.

Hoy que estoy trabajando en todo el ciclo de DevOps con Kubernetes no me hacia sentido trabajar en un VPS para generar mis ciclos y demos que veras en el blog, por lo que analice las diferentes ofertas como AWS, Azure, Digital Ocean y finalmente Google donde se encuentra hospedado este blog.

Al inicio intente poner en marcha October CMS, sin embargo tiene muchos puntos que resolver aun para hacer una portación a K8S de forma completa, por lo que opte por WordPress, ya lo he usado con otros proyectos y sé cómo vincularlo a un Volumen.

Inicie el cluster de forma micro, con 3 instancias f1-micro las cuales te dan 1 vCPU y 0.6 GB RAM, sin embargo siempre presentaba un problema alguno de los nodos, por lo que lo incremente a 8 y resulto mas o menos la estabilidad, nace un nuevo problema, montar una BD MySQL para el blog, ya lo he aplicado en clusters K8S con mayores recursos sin problemas, claro, sin la HA que ofrece Cloud SQL; debido a la poca memoria que los nodos tienen, era imposible mantener estable el pod de MySQL, así que analice el costo y bien podría usar una instancia micro sin obtener, claro esta, el SLA por una instancia mas grande, algo que para este proyecto personal no es de gran impacto.

Todo marcha bien hasta que recordé a spotinst.com quienes te ofrecen reducir en un margen del 70 al 80 por ciento del costo de tu cluster, así que manos a la obra y ahora tenemos un cluster de 2 nodos n1-standard-1, lo que representa 1 vCPU y 3.75 GB por nodo, ya les contare en otro post como me ha ido en costos con spotinst.com, de momento el dashboard indica que me he ahorrado 78.97%

El render de las versiones web y móvil lo hacia el código monolítico frontal, mientras que otro código (copia salvo entradas diferentes) proveían el acceso a la ingesta de contenidos.

Antes de separar todo, por encargo me solicitaron una aplicación móvil con una vista a sugerencia mía con Material Design, para ello, en la parte “frontal” monolítica se genero un exportador de contenidos en formato JSON, de esta forma la aplicación accedería a los contenidos de las portadas. Es a partir de este punto en donde se realizaron platicas con el Director de IT de la casa editorial para mejorar el CMS y separarlo, de tal forma que no fuera un sistema monolítico.

Así es como el equipo de desarrollo empieza separar en bloques el complejo sistema, al tiempo que nacía un segundo sitio hermano. De forma paralela tome cursos sobre Docker, Kubernetes y todo lo que conlleva su orquestación y uso.

Una vez separados los CMS, me di a la tarea de generar las imágenes y la IaC (Infraestructure as Code) de cada uno de los componentes y generar las pruebas de conectividad.

Hoy en día, ambos sitios gozan de estabilidad y auto-escalado vertical y horizontal a libre demanda.