En el primer trimestre de 2026, el Grupo Comunitario de Tecnología de Ingeniería de Plataforma (TCG) de CNCF lanzó la actualización de dos documentos básicos:Informe técnico sobre la plataforma como productoyModelo de madurez de ingeniería de plataforma. El objetivo de la comunidad es publicar el borrador antes de KubeCon EU 2026 e incorporar la seguridad de las herramientas de inteligencia artificial en la gobernanza de la plataforma. Al mismo tiempo, el artículo práctico publicado por CNCF el 29 de mayo de 2026 es muy sencillo: la entrega moderna ya no está limitada por el código de la aplicación, sino por la plataforma que la aloja. Para un equipo como Wishes Niu Technology que realiza desarrollo empresarial personalizado, esta oración está más cerca de los puntos débiles reales que "reclutar dos backends más": deriva del entorno, claves escritas en la tubería, reversiones que dependen de acuerdos verbales y observación para esperar hasta que algo salga mal.
1. Primero desmonte las tres capas y luego hable sobre "¿deberíamos usar K8?"
La práctica CNCF anterior divide la plataforma enCapa de infraestructura, capa de plataforma, capa de aplicación, y una advertencia clara: si las tres capas se colocan en el mismo almacén demasiado pronto, los costes de mantenimiento posteriores aumentarán considerablemente. La capa de infraestructura es responsable de la red, los clústeres, los almacenes espejo y las bases clave; la capa de plataforma proporciona controladores, políticas, redes de servicios y componentes observables de GitOps; la capa de aplicación son los microservicios comerciales del cliente. El error más común en proyectos de personalización es escribir el código comercial del cliente, los scripts de Jenkins y los parámetros del clúster en el mismo documento. Como resultado, se debe cambiar todo el almacén al cambiar el entorno.
1.1 Los equipos pequeños y medianos no deben copiar la lista de herramientas de los grandes fabricantes
El mismo artículo también admitió que el apilamiento prematuro de herramientas superpuestas es un error típico en el ecosistema CNCF. Istio, OpenTelemetry y ApplicationSet de múltiples clústeres se pueden postinstalar. Para proyectos personalizados con un ciclo de entrega de medio año, el conjunto mínimo más pragmático es: una definición de entorno reproducible, un proceso de compilación con escaneo y firma, y un método de lanzamiento que trate a Git como la única verdad. Sin estas tres cosas, la llamada "transformación de microservicios" simplemente divide el monolito en un grupo de procesos que copian las configuraciones de los demás.
2. Trate la plataforma como un producto en lugar de una colección de scripts de operación y mantenimiento.
CNCF escribe ingeniería de plataformas como "Plataforma como producto". El núcleo no es comprar otro conjunto de portales, sinoDesarrolladores internos como clientes. Uno de los puntos clave de la revisión de 2026 del libro blanco y del modelo de madurez es agregar escenarios reales para que las organizaciones puedan evaluar en qué nivel se encuentran y cambiar solo una cosa en el siguiente paso. Si una empresa de software personalizado crea Jenkins desde cero, escribe Dockerfile desde cero y solicita una biblioteca de prueba desde cero para cada proyecto, el ciclo de entrega se verá afectado por el "impuesto laboral duplicado". El primer objetivo de la plataforma de desarrollo interno (IDP) es proporcionar un camino dorado para proyectos similares: crear un almacén, solicitar un entorno, ejecutar pruebas, obtener una vista previa y publicar. Los desarrolladores solo completan las diferencias comerciales.
- Infraestructura declarativa: El entorno se puede reconstruir, en lugar de "sólo Lao Wang puede abordar esta máquina".
- Reconciliación continua de GitOps: El estado del clúster está sujeto a Git y los cambios manuales de kubectl en producción deben poder retirarse.
-
La cadena de suministro está activada de forma predeterminada: Escaneo de dependencias, firma de imágenes, prohibición
latestEtiquetas, interceptadas antes de ingresar al clúster. - La observabilidad es una capacidad de la plataforma.: Los indicadores, registros y alarmas se proporcionan con la ruta dorada, en lugar de agregar un conjunto después de conectarse.
3. La seguridad de la cadena de suministro debe trasladarse al “antes del despliegue”
La práctica IDP de CNCF separa la construcción, la verificación de seguridad y los cambios de infraestructura en tuberías independientes. La canalización de aplicaciones es responsable de la compilación, las pruebas unitarias, SAST, el escaneo de Trivy en busca de dependencias y la firma de Cosign antes de ingresar al almacén; el canal de seguridad vuelve a verificar las firmas, escanea imágenes y utiliza KubeSec para ver el manifiesto; Solo después de pasar el código, el controlador GitOps puede sincronizarse. Sus observaciones en el entorno experimental interno son: la tasa de éxito de la implementación aumentó de aproximadamente el 70% en procesos manuales a aproximadamente el 95%, la preparación de la infraestructura se redujo de horas a menos de 15 minutos y aproximadamente el 80% de los descubrimientos de vulnerabilidades se pueden prevenir antes de la producción. Estos números provienen del laboratorio y del lanzamiento previo, y no se pueden incluir directamente en los compromisos del cliente, pero la dirección es clara——Cambie el derecho de verificación de "personas mirando la pantalla" a "rechazo de la línea de montaje".
| nivel | Capacidades de la plataforma | ¿Qué corresponde al proyecto personalizado? | No lo hagas de inmediato |
|---|---|---|---|
| infraestructura | Red, cluster, almacén, clave. | Tres conjuntos de bases para pruebas/prelanzamiento/producción de clientes | Cambie manualmente el grupo de seguridad sin volver a escribir el código |
| plataforma | GitOps, estrategia, observación. | Lanzamiento unificado, reversión unificada y alarma unificada | Cada proyecto construye su propia filosofía Jenkins |
| solicitud | Servicios comerciales publicables de forma independiente | Pedido, inventario, aprobación y otros módulos de clientes | Coloque la clave y el código comercial en la misma imagen. |
| gobernancia | Firmas, políticas de admisión, auditoría. | Las cláusulas de seguridad y aceptación en los contratos se pueden verificar mecánicamente. | Haga un acuerdo verbal para "escanear nuevamente antes de conectarse" |
4. La secuencia de aterrizaje del equipo de personalización.
Los modelos de madurez enfatizan los siguientes pasos viables en lugar de comprar el portal de una vez. Wishing Niu Technology recomienda cortar el camino dorado más estrecho según el tipo de proyecto: por ejemplo, "servicio Java + MySQL + almacenamiento de objetos" debe ejecutarse primero y luego expandirse al front-end y a la cola de mensajes. Estrategias de acceso como Kyverno priorizan sólo la interceptaciónlatestClaves de duplicación y texto plano; Istio es estricto con mTLS y no necesita ser único para todos los clústeres. Como está escrito en el artículo de práctica, activar Strict demasiado pronto provocará que se desconecten todos los servicios sin sidecars. El enfoque correcto es ser permisivo primero y luego cortar por espacio de nombres.
- Primero congele un conjunto de módulos de entorno (red, informática, clave) y utilice archivos variables para distinguir desarrollo/prelanzamiento/producción.
- Luego, convierta el producto compilado en un "artefacto verificable": solo cuando se registren el número de versión, el informe de escaneo y la firma se podrá lanzar previamente.
- Luego, deje que Git se convierta en el portal de lanzamiento y la reversión equivale a revertir la confirmación, en lugar de iniciar sesión en la máquina para sobrescribir el archivo.
- El último paso es crear un portal de autoservicio. Sin los primeros tres pasos, un portal es simplemente un caos envuelto en botones.
La ingeniería de plataformas no se trata de hacer que los proyectos personalizados "parecen nativos de la nube". Lo que quiere resolver es: la segunda entrega del mismo tipo de sistema no debería ser más lenta que la primera. Si está evaluando un lote de sistemas empresariales paralelos, primero cuente cuántas horas pasa el equipo cada semana "esperando el entorno, corrigiendo la configuración, adivinando quién la cambió" y luego decida de qué línea de negocio se debe cortar el camino dorado. Es más fácil conseguir que se acepte en el siguiente hito que dibujar primero un gran plan de mitad de etapa.