En el ecosistema de los sistemas distribuidos, la Elección de Líder (Leader Election) es un mecanismo fundamental para garantizar la consistencia y evitar conflictos de recursos. Dentro de Kubernetes, componentes críticos como el kube-scheduler y el kube-controller-manager utilizan esta estrategia para asegurar que, aunque existan múltiples réplicas para garantizar la alta disponibilidad, solo una instancia tome decisiones activas en un momento dado.

Fundamentos de la Elección de Líder en K8s

¿Por qué es necesaria?

Muchos servicios dentro de un clúster requieren un modelo de ejecución de instancia única por diversas razones:

• Evitar condiciones de carrera: Prevenir que múltiples controladroes intenten modifiacr el mismo objeto de la API simultáneamente.
• Gestión de fallos (Failover): Si el nodo principal falla, el sistema debe ser capaz de designar un sucesor de forma automática y rápida.
• Consistencia de datos: Garantizar que las operaciones de escritura o lógica de negocio no se dupliquen.

El recurso Lease: El candado distribuido

Históricamente, Kubernetes utilizaba ConfigMaps o Endpoints para gestionar bloqueos. Sin embargo, la implementación moderna utiliza el recurso Lease (coordination.k8s.io). Este recurso es significativamente más eficiente porque:

• Es ligero y reduce la carga en el servidor de la API (etcd).
• Está diseñado específicamente para el control de "arrendamientos" (leases).
• Contiene campos clave como holderIdentity (quién tiene el mando), leaseDurationSeconds (validez del mando) y renewTime (última actualización).

Implementación Práctica: Ejemplo en Go

A continuación, presentamos una implementación utilizando client-go que demuestra cómo integrar la elección de líder en una aplicación personalizada.

package main

import (
	"context"
	"fmt"
	"os"
	"time"
	"sync/atomic"

	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
	"k8s.io/client-go/kubernetes"
	"k8s.io/client-go/rest"
	"k8s.io/client-go/tools/leaderelection"
	"k8s.io/client-go/tools/leaderelection/resourcelock"
	"k8s.io/apimachinery/pkg/util/wait"
)

var esMaestro atomic.Bool

func ejecutarProcesoLider(ctx context.Context) {
	fmt.Println("Iniciando lógica de negocio exclusiva del Líder...")
	wait.Until(func() {
		fmt.Printf("[%s] Trabajando: Procesando tareas críticas...\n", time.Now().Format(time.RFC3339))
	}, 4*time.Second, ctx.Done())
}

func main() {
	// Configuración del cliente dentro del clúster
	config, err := rest.InClusterConfig()
	if err != nil {
		panic(err.Error())
	}
	clientset := kubernetes.NewForConfigOrDie(config)

	// Identificador único para esta réplica
	idNodo, _ := os.Hostname()
	nombreBloqueo := "app-sync-lock"
	namespace := "default"

	// Configuración del bloqueo basado en Lease
	bloqueoRecurso := &resourcelock.LeaseLock{
		LeaseMeta: metav1.ObjectMeta{
			Name:      nombreBloqueo,
			Namespace: namespace,
		},
		Client: clientset.CoordinationV1(),
		LockConfig: resourcelock.ResourceLockConfig{
			Identity: idNodo,
		},
	}

	ctx, cancel := context.WithCancel(context.Background())
	defer cancel()

	leaderelection.RunOrDie(ctx, leaderelection.LeaderElectionConfig{
		Lock:            bloqueoRecurso,
		LeaseDuration:   15 * time.Second,
		RenewDeadline:   10 * time.Second,
		RetryPeriod:     2 * time.Second,
		Callbacks: leaderelection.LeaderCallbacks{
			OnStartedLeading: func(ctx context.Context) {
				esMaestro.Store(true)
				fmt.Printf("Nodo %s ha ganado la elección\n", idNodo)
				ejecutarProcesoLider(ctx)
			},
			OnStoppedLeading: func() {
				esMaestro.Store(false)
				fmt.Printf("Nodo %s ha perdido el liderazgo\n", idNodo)
				os.Exit(0)
			},
			OnNewLeader: func(identity string) {
				if identity == idNodo {
					return
				}
				fmt.Printf("Nuevo líder detectado: %s\n", identity)
			},
		},
	})
}

Configuración de Permisos (RBAC)

Para que la aplicación pueda interactuar con el recurso Lease, es imperativo configurar los permisos adecuados mediante un Role y un RoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: gestor-de-leasings
  namespace: default
rules:
- apiGroups: ["coordination.k8s.io"]
  resources: ["leases"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-leader-binding
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
roleRef:
  kind: Role
  name: gestor-de-leasings
  apiGroup: rbac.authorization.k8s.io

Optimización de Parámetros

El comportamiento de la elección depende de tres variables críticas que deben ajustarse según la sensibilidad del negocio:

Nota de seguridad: El valor de RenewDeadline siempre debe ser menor que LeaseDuration para permitir reintentos antes de que el bloqueo expire.

Mejores Prácticas en Producción

Gestión de "Split Brain" (Cerebro Dividido)

Aunque Kubernetes garantiza la consistencia del Lease, es posible que una instancia crea que sigue siendo líder debido a latencias de red. Para mitigar esto:

• Idempotencia: Asegúrese de que las operaciones realizadas por el líder puedan repetirse sin efectos secundarios negativos.
• Contexto de cancelación: Utilice siempre el ctx proporcionado en OnStartedLeading. Si el liderazgo se pierde, este contexto se cancelará automáticamente, y su lógica debe detenerse de inmediato.

Monitoreo y Observabilidad

Es vital exponer métricas para saber qué instancia es el líder actual. Se recomienda:

• Registrar eventos de cambio de estado (transiciones de líder).
• Monitorear la latencia de las peticiones a la API de Kubernetes, ya que un retraso excesivo puede provocar la pérdida involuntaria del liderazgo.
• Implementar alertas si el clúster pasa demasiado tiempo sin un líder electo.

Estrategia de Salida

Cuando un Pod recibe un SIGTERM, debe liberar el Lease de forma proactiva si es posible, o simplemente cancelar el contexto de renovación. Esto permite que otras réplicas compitan por el mando de inmediato en lugar de esperar a que expire el tiempo de LeaseDuration.