Guía

Establecer el principio fundamental para un equipo de plataforma a fin de asegurar la adopción y reducir la fricción para los desarrolladores.

→Tratar la plataforma interna como un producto. Tratar a los desarrolladores internos como clientes, realizar investigación de usuarios, recopilar comentarios e iterar sobre las funcionalidades para reducir su carga cognitiva.

Por qué: Esta mentalidad cambia el enfoque de construir infraestructura a entregar valor, asegurando que la plataforma resuelva problemas reales de los desarrolladores y no sea eludida ("shadow IT").

Establecer una única fuente de verdad para el estado deseado de toda la infraestructura y aplicaciones.

→Utilizar repositorios Git como única fuente de verdad. Desplegar un agente en el clúster (ArgoCD, Flux) que ejecute un ciclo de reconciliación continuo para comparar el estado del clúster con Git.

Por qué: Esto proporciona un registro de auditoría completo, permite reversiones sencillas y previene la desviación de configuración al revertir automáticamente los cambios fuera de banda.

Referencia↗

Prevenir la desviación de configuración y asegurar la consistencia de los artefactos desplegados en todos los entornos.

→Tratar la infraestructura como inmutable. Nunca modificar los recursos en ejecución. En su lugar, crear artefactos nuevos y versionados (imágenes de contenedor, imágenes de VM) y reemplazar los antiguos. Imponer esto con sistemas de archivos de contenedor de solo lectura (`readOnlyRootFilesystem: true`).

Por qué: La inmutabilidad elimina la desviación de configuración y hace que los despliegues sean predecibles y repetibles. "Reemplaza, no repares."

Elegir un modelo de despliegue GitOps seguro, especialmente en entornos de clústeres múltiples o redes restringidas.

→Implementar un modelo basado en "pull". Un agente (ArgoCD, Flux) ejecutándose dentro del clúster extrae los manifiestos de Git. Evitar los modelos basados en "push" donde un sistema CI externo envía a la API de Kubernetes.

Por qué: Los modelos basados en "pull" son más seguros ya que no requieren exponer el servidor API de Kubernetes externamente o gestionar credenciales para múltiples clústeres en CI.

Acelerar el desarrollo y asegurar las mejores prácticas sin restringir excesivamente a los equipos experimentados.

→Definir "caminos dorados" (o "carreteras pavimentadas"): plantillas y flujos de trabajo preconfigurados y bien soportados para tareas comunes (por ejemplo, crear un nuevo microservicio).

Por qué: Los caminos dorados reducen la carga cognitiva y la fatiga de decisión para el 80% de los casos, pero aún deben permitir "salidas de escape" para equipos expertos con requisitos únicos.

Proporcionar multi-tenencia en una plataforma Kubernetes compartida con niveles de aislamiento apropiados.

→Para el aislamiento más fuerte, usar clústeres separados. Para un equilibrio entre aislamiento fuerte y eficiencia, usar clústeres virtuales (vClusters). Para una multi-tenencia básica y flexible, usar aislamiento a nivel de namespace con RBAC, NetworkPolicies y ResourceQuotas.

Por qué: La elección depende del riesgo de seguridad y de "vecino ruidoso". Los clústeres virtuales proporcionan aislamiento del plano de control sin el coste de clústeres físicos completos.

Definir el modo de interacción principal entre el equipo de plataforma y los equipos alineados con el flujo (de producto).

→El equipo de plataforma debe operar principalmente en un modo "X-como-Servicio", proporcionando herramientas de autoservicio, APIs y documentación.

Por qué: A escala, un equipo de plataforma no puede usar un modelo de colaboración de alto contacto con cada equipo. El modelo "como-servicio" permite la escalabilidad y la autonomía del desarrollador.

Implementar una estrategia de observabilidad integral para un sistema distribuido.

→Recopilar y correlacionar los tres pilares: Métricas (datos numéricos de series de tiempo vía Prometheus), Logs (eventos estructurados vía Fluent Bit) y Trazas (flujos de solicitud vía OpenTelemetry).

Por qué: Ningún pilar por sí solo es suficiente. Correlacionarlos (por ejemplo, incrustar IDs de trazas en los logs) es esencial para diagnosticar rápidamente problemas en arquitecturas complejas de microservicios.

Aplicar políticas de seguridad y organizativas en todos los clústeres de Kubernetes automáticamente.

→Utilizar un motor de políticas como OPA/Gatekeeper o Kyverno, integrado como un controlador de admisión validador/mutador. Almacenar las políticas en Git y sincronizarlas vía GitOps.

Por qué: Esto proporciona barandillas de seguridad automatizadas y preventivas, dando a los desarrolladores una retroalimentación rápida en su pipeline de CI/CD en lugar de puertas de revisión lentas y manuales.

Seleccionar un motor de políticas para Kubernetes basado en las habilidades del equipo y la complejidad de las políticas.

→Usar Kyverno para políticas que puedan expresarse en YAML de estilo Kubernetes familiar. Usar OPA/Gatekeeper para políticas complejas que requieran un lenguaje más potente y específico (Rego) e integración de datos externos.

Por qué: Kyverno tiene una curva de aprendizaje más baja para los profesionales de Kubernetes. OPA/Rego es más potente pero requiere aprender un nuevo lenguaje.

Asegurar la integridad y autenticidad de las imágenes de contenedor desplegadas en producción.

→Implementar la firma de imágenes en el pipeline de CI usando Sigstore/Cosign. Usar un controlador de políticas (Kyverno, Gatekeeper) para crear una política de admisión que verifique las firmas de las imágenes antes de permitir la creación de un pod.

Por qué: Esto asegura que solo las imágenes construidas por pipelines de CI confiables y que no han sido manipuladas puedan ejecutarse en el clúster, previniendo la ejecución de código no autorizado.

Referencia↗

Asegurar todas las comunicaciones de servicio a servicio dentro del clúster con un enfoque de confianza cero.

→Desplegar una malla de servicios (por ejemplo, Istio, Linkerd) y habilitar TLS mutuo estricto (mTLS) para todo el tráfico dentro de la malla.

Por qué: mTLS proporciona tanto cifrado en tránsito como una identidad fuerte y criptográficamente verificable para el cliente y el servidor, previniendo la suplantación y ataques de intermediario dentro del clúster.

Aplicar las mejores prácticas de seguridad para todas las cargas de trabajo que se ejecutan en el clúster.

→Habilitar el controlador de admisión de seguridad de Pods incorporado. Configurar los namespaces para aplicar el perfil `restricted` para las cargas de trabajo y `baseline` para los componentes de la plataforma.

Por qué: El perfil `restricted` aplica un endurecimiento de seguridad crítico (por ejemplo, ejecutar como no-root, eliminar todas las capacidades, no permitir la escalada de privilegios) y es una medida de seguridad fundamental.

Referencia↗

Detectar comportamientos anómalos o maliciosos dentro de contenedores en ejecución a nivel del sistema operativo.

→Desplegar una herramienta de seguridad en tiempo de ejecución que utilice eBPF, como Falco o Tetragon. Definir reglas para detectar llamadas al sistema, acceso a archivos y ejecución de procesos sospechosos.

Por qué: Las herramientas de seguridad tradicionales son ciegas a la actividad dentro de los contenedores. eBPF proporciona una visibilidad profunda y de baja sobrecarga en los eventos a nivel del kernel, lo que permite la detección de amenazas que otras herramientas pasan por alto.

Construir un pipeline de datos de observabilidad escalable y resiliente.

→Utilizar el OpenTelemetry (OTel) Collector. Encadenar procesadores para transformar datos (por ejemplo, el procesador `attributes` para eliminar PII, el procesador `batch` para eficiencia). Usar el procesador `memory_limiter` al principio del pipeline para prevenir OOMs.

Por qué: El Collector desacopla la instrumentación de los backends y proporciona una forma flexible y agnóstica del proveedor para procesar, filtrar y enrutar datos de telemetría antes de la exportación.

Referencia↗

Desplegar nuevas versiones de aplicaciones en producción minimizando el riesgo y el radio de impacto.

→Implementar despliegues canary automatizados utilizando una herramienta como Flagger o Argo Rollouts. Desviar gradualmente el tráfico a la nueva versión mientras se analizan automáticamente métricas clave (tasa de éxito, latencia). Revertir automáticamente en caso de violación de SLO.

Por qué: El análisis canary automatizado valida nuevas versiones con tráfico de producción real, proporcionando un grado de seguridad mucho mayor que las simples actualizaciones continuas.

Desplegar una nueva versión de una aplicación con la capacidad de realizar una reversión instantánea.

→Mantener dos entornos de producción idénticos ("azul" y "verde"). Desplegar la nueva versión en el entorno inactivo (verde). Después de la validación, cambiar el balanceador de carga para enrutar todo el tráfico al verde. Mantener el azul inactivo para una reversión instantánea.

Por qué: Este patrón proporciona despliegues sin tiempo de inactividad y la reversión más rápida posible, pero típicamente requiere el doble de recursos de infraestructura.

Gestionar secretos de forma declarativa en un flujo de trabajo GitOps sin almacenar credenciales en texto plano en Git.

→Usar un operador de secretos dedicado. O bien cifrar los secretos antes de hacer commit (Bitnami Sealed Secrets, Mozilla SOPS) o referenciar secretos desde un vault externo (External Secrets Operator).

Por qué: Esto mantiene los datos sensibles fuera de Git mientras permite que los secretos se gestionen de forma declarativa junto con la configuración de la aplicación, manteniendo el flujo de trabajo GitOps.

Gestionar configuraciones de aplicaciones en múltiples entornos (desarrollo, staging, producción) sin duplicación.

→Utilizar una herramienta como Kustomize con una estructura de base y superposición, o Helm con archivos de valores específicos del entorno. Promover cambios actualizando las etiquetas de imagen o la configuración en el archivo de superposición/valores del entorno de destino, típicamente a través de una pull request.

Por qué: Este enfoque "No te Repitas" (DRY) previene la desviación de configuración entre entornos y hace que las diferencias sean explícitas y auditables.

Gestionar despliegues de la misma aplicación en una flota grande y dinámica de clústeres.

→Utilizar ArgoCD ApplicationSets con un generador de clústeres. El generador descubre dinámicamente los clústeres basándose en etiquetas y usa una plantilla para generar un recurso Application para cada clúster coincidente.

Por qué: Esto automatiza el arranque de aplicaciones para nuevos clústeres y gestiona la configuración a escala, evitando la necesidad de crear manualmente cientos de recursos Application.

Referencia↗

Habilitar el despliegue continuo a producción mientras se controla la liberación de nuevas funcionalidades a los usuarios.

→Integrar un sistema de feature flags. Desplegar nuevo código en producción detrás de un feature flag deshabilitado. Liberar la funcionalidad habilitando el flag para segmentos de usuarios específicos, desacoplando el despliegue de la liberación.

Por qué: Esto separa el riesgo técnico (despliegue) del riesgo de negocio (liberación), permitiendo despliegues de alta velocidad, pruebas A/B y capacidades de "interruptor de emergencia".

Desplegar automáticamente nuevas imágenes de contenedor tan pronto como se envían a un registro.

→Utilizar los componentes de automatización de imágenes de FluxCD. El `ImageRepository` escanea el registro, el `ImagePolicy` selecciona la nueva etiqueta (por ejemplo, basada en semver), y el `ImageUpdateAutomation` registra el cambio de etiqueta de vuelta al repositorio Git.

Por qué: Esto cierra el ciclo de CI (envío de imagen) a CD (despliegue) para un flujo de trabajo GitOps totalmente automatizado, sin que el sistema CI necesite acceso al clúster.

Proporcionar una API unificada y declarativa para que los desarrolladores aprovisionen en autoservicio recursos de Kubernetes y de infraestructura en la nube (por ejemplo, bases de datos, colas de mensajes).

→Utilizar Crossplane. Instalar plugins de proveedores de la nube y definir CompositeResourceDefinitions (XRDs) de alto nivel para desarrolladores (por ejemplo, `kind: PostgresSQLInstance`). Mapear estos a recursos de la nube subyacentes utilizando Compositions.

Por qué: Esto extiende el plano de control de Kubernetes para gestionar recursos externos, permitiendo a los desarrolladores usar flujos de trabajo `kubectl` y GitOps familiares para todas sus dependencias de aplicación, gobernados por patrones definidos por la plataforma.

Referencia↗

Automatizar la gestión del ciclo de vida de aplicaciones complejas y con estado (por ejemplo, instalación, actualizaciones, copias de seguridad, recuperación de fallos) de una manera nativa de Kubernetes.

→Construir un Operador de Kubernetes. Definir una Custom Resource Definition (CRD) para tu aplicación e implementar un controlador personalizado que ejecute un ciclo de reconciliación para gestionar el estado de la aplicación.

Por qué: Los Operadores codifican el conocimiento operativo humano en software, permitiendo una automatización robusta y tratando las aplicaciones complejas como recursos de primera clase de Kubernetes.

Asegurar que un operador pueda realizar la limpieza de recursos externos (por ejemplo, un balanceador de carga en la nube) antes de que su Custom Resource asociado sea eliminado de Kubernetes.

→Añadir un "finalizer" a los metadatos del Custom Resource. Cuando un usuario elimina el CR, este entra en un estado `Terminating`. La lógica de reconciliación del operador detecta esto, realiza la limpieza y luego elimina el "finalizer", permitiendo que el servidor API de K8s complete la eliminación.

Por qué: Sin un "finalizer", el CR podría ser eliminado antes de que el operador tenga tiempo de limpiar los recursos externos, lo que llevaría a infraestructura huérfana y costosa.

Gestionar el ciclo de vida de una flota de clústeres de Kubernetes utilizando herramientas declarativas y compatibles con GitOps.

→Utilizar Cluster API (CAPI). Un clúster de gestión ejecuta controladores CAPI que reconcilian recursos `Cluster` y `Machine` para aprovisionar y configurar clústeres de carga de trabajo en varios proveedores de la nube.

Por qué: CAPI convierte la gestión de clústeres en un flujo de trabajo declarativo de Kubernetes, permitiendo el aprovisionamiento y las actualizaciones consistentes, automatizadas y controladas por versiones de clústeres completos.

Referencia↗

Evolucionar las APIs de la plataforma (definidas como CRDs) sin romper a los usuarios existentes ni requerir una migración de "big bang".

→Soportar múltiples versiones en la definición de CRD (por ejemplo, v1beta1, v1). Implementar un webhook de conversión para traducir entre versiones, permitiendo que los nuevos clientes usen v1 mientras los clientes antiguos continúan usando v1beta1 contra el mismo objeto almacenado.

Por qué: Los webhooks de conversión son el mecanismo nativo de Kubernetes para permitir la evolución no disruptiva de la API, lo cual es crítico para un producto de plataforma estable.

Reducir la carga cognitiva del desarrollador y mejorar la capacidad de descubrimiento centralizando herramientas, documentación y activos de software.

→Implementar un Portal Interno de Desarrolladores (IDP) usando un framework como CNCF Backstage. Poblar su Catálogo de Software, proporcionar Plantillas de Software para andamiar nuevos servicios e integrar TechDocs para "documentación como código".

Por qué: Un IDP actúa como un "único panel de vidrio" para los desarrolladores, proporcionando caminos dorados y capacidades de autoservicio que abstraen la complejidad de la plataforma y aceleran la incorporación y el desarrollo.

Referencia↗

Proporcionar un inventario único y confiable de todo el software en la organización, incluyendo la propiedad, dependencias y estado operativo.

→Implementar un catálogo de software (por ejemplo, Backstage Software Catalog) poblado a través de archivos `catalog-info.yaml` en repositorios Git. Esto crea un registro central y searchable de servicios, librerías, APIs, etc.

Por qué: Un catálogo resuelve la capacidad de descubrimiento ("¿qué servicios existen?") y la propiedad ("¿con quién hablo sobre este servicio?"), lo cual es crítico para escalar arquitecturas de microservicios.

Permitir a los desarrolladores crear nuevos servicios listos para producción que cumplan con los estándares organizacionales en minutos.

→Utilizar una herramienta de andamiaje como Backstage Software Templates. Definir plantillas que generen un nuevo repositorio Git con una estructura de proyecto estándar, configuración de pipeline de CI/CD, paneles de observabilidad y `catalog-info.yaml`.

Por qué: Las plantillas codifican las mejores prácticas y proporcionan un "camino pavimentado" para los desarrolladores, reduciendo drásticamente el tiempo hasta el primer commit y asegurando que los nuevos servicios se creen con seguridad, observabilidad y cumplimiento integrados.

Asegurar que la documentación técnica esté actualizada, versionada y co-ubicada con el software que describe.

→Adoptar un enfoque de "documentación como código". Almacenar la documentación en archivos Markdown dentro del repositorio Git del servicio. Utilizar una herramienta como Backstage TechDocs para construir y renderizar automáticamente esta documentación en el IDP.

Por qué: Este modelo trata la documentación como código: puede revisarse en pull requests y se versiona junto con la funcionalidad que describe, evitando documentos obsoletos o desactualizados.

Medir la efectividad de la plataforma y su impacto en el rendimiento de la entrega de software.

→Rastrear las cuatro métricas DORA: Frecuencia de Despliegue (velocidad), Tiempo de Espera para Cambios (velocidad), Tasa de Fallo de Cambios (estabilidad) y Tiempo para Restaurar el Servicio (MTTR, estabilidad).

Por qué: Las métricas DORA son medidas estándar de la industria, orientadas a resultados, que han demostrado correlacionarse con el rendimiento organizacional. Proporcionan una visión equilibrada tanto de la velocidad como de la estabilidad.

Referencia↗

Proporcionar visibilidad de costos precisa y granular a los equipos que utilizan una plataforma Kubernetes compartida.

→Desplegar una herramienta FinOps como OpenCost o Kubecost. Atribuir costos a las cargas de trabajo basándose en su consumo real de recursos a lo largo del tiempo. Asignar los costos del clúster compartido (por ejemplo, componentes del sistema, sobrecarga de nodos) proporcionalmente.

Por qué: La asignación precisa de costos (chargeback/showback) impulsa la responsabilidad y anima a los equipos a optimizar el uso de los recursos. Sin ella, los costos de la plataforma compartida son opacos y difíciles de gestionar.

Medir si la plataforma realmente está proporcionando valor y siendo utilizada por los equipos de desarrollo.

→Rastrear la tasa de adopción de las características clave de la plataforma, especialmente las plantillas de caminos dorados y los pipelines de CI/CD compartidos. Complementar con encuestas de satisfacción del desarrollador (estilo NPS).

Por qué: Una alta adopción de características opcionales y con opinión de la plataforma es una señal fuerte de que la plataforma está resolviendo problemas reales. Una baja adopción indica una falta de coincidencia con las necesidades del desarrollador.

Evaluar el estado actual de la plataforma y crear una hoja de ruta para la mejora.

→Utilizar un Modelo de Madurez de Plataforma para evaluar las capacidades en múltiples dimensiones: por ejemplo, Autoservicio, Observabilidad, Seguridad, Fiabilidad y Gobernanza. Definir niveles desde ad-hoc/manual hasta totalmente automatizado y optimizado.

Por qué: Un modelo de madurez proporciona un marco estructurado para la autoevaluación, ayuda a identificar puntos débiles y alinea al equipo en una visión estratégica para la evolución de la plataforma.