Controladores de Kubernetes: reconciliación idempotente

Comenzar por el estado deseado

Un entorno de autoservicio debería describir lo que un equipo necesita, en lugar de una secuencia de operaciones manuales. Por ejemplo, una solicitud puede identificar una aplicación y su política de acceso. La plataforma traduce esa intención a recursos de Kubernetes.

Un recurso personalizado define la API de esa intención. Un controlador aporta el comportamiento. Los controladores de Kubernetes comparan repetidamente el estado solicitado con el observado y trabajan para acercarlos. Crear el recurso personalizado no implementa el aprovisionamiento por sí solo.

Reconciliar varias veces con seguridad

La idempotencia implica que aplicar de nuevo la misma intención no produce efectos adicionales continuamente. Un controlador no debería crear otro namespace o duplicar un recurso externo cada vez que procesa la misma solicitud.

Usa identidades estables e inspecciona el estado existente antes de decidir qué cambiar. Considera normal la ejecución parcial. Si se crea el namespace pero falla la siguiente operación, una reconciliación posterior debe continuar desde el estado observado, sin asumir que empieza de cero.

Comunicar un resultado observable

Aceptar una solicitud en la API no significa que el entorno esté listo. Mantén la intención en spec y comunica el resultado observado en status. El estado debe ayudar al equipo a distinguir una operación en curso de una que necesita intervención.

Para una API de plataforma, recomiendo definir qué significa estar listo antes de implementar el caso exitoso. Decide qué dependencias deben estar disponibles y qué detalles del error ayudan a quien hizo la solicitud. Evita exponer credenciales en los mensajes de diagnóstico.

Diseñar la eliminación junto con la creación

Algunos recursos necesitan limpieza antes de terminar su eliminación. Los finalizers permiten realizar esa limpieza mientras Kubernetes mantiene el objeto en terminación. El controlador responsable debe retirar el finalizer al completar el trabajo; de lo contrario, la eliminación queda bloqueada.

La limpieza también debe tolerar reintentos. Documenta qué administra la plataforma, qué conserva y qué debe inspeccionar un operador cuando no puede terminar. Retirar accesos forma parte del ciclo de vida del recurso.

Probar la recuperación, no solo la creación

Para revisar un controlador de aprovisionamiento, comenzaría con estos escenarios. Son comprobaciones de diseño y no sustituyen las pruebas de integración con las APIs que usa el controlador.

Definir expectativas de pruebas independientes

• Reconciliar dos veces la misma solicitud y comprobar que no se duplican recursos.
• Interrumpir el aprovisionamiento tras una operación exitosa y reintentar.
• Cambiar la configuración deseada y verificar la convergencia.
• Eliminar una solicitud y comprobar que la limpieza se recupera de un fallo temporal.
• Comprobar que status comunica el resultado sin revelar información sensible.