Hoy nos complace presentar el Informe de uso de contenedores Sysdig para 2019 ( Informe de uso de contenedores Sysdig 2019 ). Kubernetes continúa ganando impulso, las arquitecturas en la nube están explorando cada vez más, y todo esto está cambiando no solo los patrones de uso, sino también los procesos y las estructuras organizativas. Sorprendentemente, este año el número de contenedores se duplicó, cuya vida útil no supera los 5 minutos. Cuanto más dinámicos sean los servicios, mejores equipos en la nube reconocerán la necesidad de integrar la seguridad en los procesos de DevOps. Como parte de nuestro informe de uso para 2019, estamos explorando detalles de seguridad y cumplimiento por primera vez, además de una serie de detalles sobre cómo los clientes usan contenedores, Kubernetes y más.
Posición única de Sysdig
La plataforma Sysdig Secure DevOps proporciona una perspectiva real de la infraestructura, las aplicaciones y los contenedores. Nuestro informe cubre empresas de todo el mundo y en muchas áreas. Este año incluimos detalles sobre los usuarios locales de SaaS y Sysdig para proporcionarle una imagen del uso comercial de dos millones de contenedores desplegados como ejemplo.
Más sobre los resultados.
En nuestro informe de 2018, describimos cómo la Open Container Initiative (OCI) ayudó a introducir entornos de lanzamiento de contenedores alternativos. En 2019, esto sucedió a gran escala: el proyecto de contenedores obtuvo una participación significativa del 18%. Para ser justos, vale la pena señalar que Docker utiliza contenedores. Anteriormente, su motor implementaba funciones de alto y bajo nivel del entorno de lanzamiento. Ahora se dividen en dos proyectos separados: containerd y runc.
CRI-O debutó este año. Entre otras cosas, nos sorprendió el bajo nivel de desarrollo actual. CRI-O, el tiempo de ejecución ligero de Kubernetes, apareció en Red Hat en 2016 y fue aceptado en CNCF © en 2019. Creemos que el nivel de desarrollo aumentará tan pronto como los usuarios de Red Hat OpenShift migren de v3 a v4, donde CRI-O reemplaza el motor Docker adoptado anteriormente.
La densidad de contenedores en un servidor físico está creciendo al 100%
Durante el año pasado, el número promedio de contenedores por servidor físico aumentó a 30, duplicándose en comparación con 15 en 2018 y 10 en 2017.
Creemos que esta cifra aumentará en función de varios factores:
- Un aumento en el número de aplicaciones que se migran a la infraestructura de la nube;
- Inclusión de datos de clientes locales de Sysdig que ejecutan clústeres más grandes y densos;
- El crecimiento de la computación "caballos de fuerza", permitiendo que más contenedores trabajen en cada servidor.
En 2019, la densidad máxima de contenedores por nodo fue de 250, y este es un aumento del 38 por ciento en comparación con 2018.
Orquesta de contenedores: domina Kubernetes
No es sorprendente que, como instrumento de orquestación de facto, Kubernetes se haya hecho con el 77% de la participación de los orquestadores usados. Este número aumentará al 89% si agrega Red Hat OpenShift y Rancher, ambos construidos en Kubernetes. Y aquí está la situación actual en números:
Si separa los datos de las empresas que implementan la plataforma Sysdig localmente, la imagen de la orquestación cambia significativamente. En este segmento, la plataforma de contenedores Red Hat OpenShift está tomando la delantera. La razón principal es que las organizaciones de usuarios, generalmente grandes y cautelosas, quieren aprovecharse de Kubernetes, pero prefieren hacerlo con soluciones locales compatibles comercialmente, como Platform as a Service (PaaS), como OpenShift.
También en el informe de 2019, examinamos estadísticas sobre el uso de nubes públicas. Descárgalo para más detalles .
Seguridad y cumplimiento
"Implementar seguridad por adelantado" se ha convertido en una frase obsesiva. Describe un enfoque en el que la seguridad está integrada en las primeras etapas del ciclo de vida del desarrollo. En general, las organizaciones de contenedores entienden cómo integrar la seguridad y el cumplimiento en el flujo de trabajo de DevOps. Para obtener información sobre la seguridad y el cumplimiento en contenedores y Kubernetes, analizamos los datos de las áreas de escaneo en busca de vulnerabilidades, la seguridad del entorno de inicio y el cumplimiento de CIS.
Gestión de vulnerabilidades
Los clientes escanean imágenes para detectar, bloquear y eliminar vulnerabilidades de contenedores en canalizaciones de CI / CD y registros de contenedores. En el informe completo, observamos los registros utilizados, el porcentaje de imágenes extraídas de repositorios públicos y privados. También damos la proporción de escaneo exitoso / no exitoso de imágenes en busca de vulnerabilidades. Aquí hay algunas conclusiones.
Extracción de imagen: repositorios públicos vs privados
¿Cuántos contenedores se recuperan de repositorios públicos o privados? Descubrimos que el 40% de las imágenes provienen de fuentes disponibles públicamente.
El uso de imágenes de contenedor de repositorios abiertos es complicado, porque solo unos pocos cumplen con los estándares o se verifican las vulnerabilidades de seguridad. Tomemos, por ejemplo, el Docker Hub : las imágenes etiquetadas como "Certificado", "Oficial" y "Editor verificado" son más confiables. Sin embargo, de los tres millones de imágenes alojadas en el servidor, menos del 1% tienen tales designaciones. Para mitigar el riesgo, los equipos en la nube crean políticas para determinar qué registros de contenedores se pueden aprobar para su uso en sus organizaciones.
Escaneo de imagen
Independientemente de la fuente, escanear una imagen en busca de vulnerabilidades conocidas antes de implementarla en un entorno de producción es la mejor práctica que no se puede descuidar. Para evaluar el alcance de los riesgos o vulnerabilidades, tomamos muestras de las imágenes que pasaron y fallaron el escaneo, escaneadas durante un período de 5 días. Más de la mitad de las imágenes no pasaron la prueba, lo que significa que en ellas se identificaron vulnerabilidades conocidas de alto y muy alto grado de peligro.
Riesgos de seguridad
Después de que los desarrolladores aborden problemas conocidos, los equipos en la nube deben establecer políticas que determinen un comportamiento anormal y obliguen a que se active una alerta de seguridad en un entorno de producción. El entorno de inicio de seguridad para Kubernetes es algo nuevo para las empresas, pero entienden qué es qué, rápidamente. Durante el año pasado, Falco , el proyecto de seguridad de código abierto de CNCF para la seguridad del entorno de lanzamiento, contribuyó con Sysdig del Docker Hub 6,7 millones de veces. Esto es un 252% más que en el año anterior.
Observamos una violación de la política en el contexto del volumen de alertas que los clientes recibieron de Sysdig Secure, que automatiza la seguridad del entorno de lanzamiento con las políticas de Falco. Identifica los tipos de riesgos de seguridad más comúnmente encontrados por los usuarios de contenedores. Entre ellos, los más comunes son:
1 - Intenta acceder a volúmenes, directorios o archivos confidenciales; 2 - Comenzar con demasiados permisos o intentos de expandir privilegios; 3 - Lanzar un shell de comandos desde un terminal conectado
En un informe completo sobre el uso, examinamos en detalle 10 violaciones, clasificándolas por frecuencia, y al mismo tiempo describimos cada una de ellas, explicamos la amenaza potencial.
Conformidad
Para reducir el riesgo y cumplir con los estándares de cumplimiento, incluidos PCI-DSS, HIPAA y GDPR, las organizaciones deben revisar periódicamente los servidores y contenedores utilizando las mejores prácticas. Las auditorías realizadas con los puntos de referencia integrados de CIS para las comprobaciones de Docker en Sysdig Secure muestran que todavía hay margen de mejora. Por ejemplo, descubrimos que generalmente en los servidores de contenedores hay:
Las 10 mejores soluciones de contenedores de código abierto
El código abierto ha cambiado la cara del procesamiento de datos en toda la empresa. No solo impulsa la innovación en toda la infraestructura, sino también especialmente en el desarrollo de aplicaciones. Sysdig abre automáticamente los procesos dentro de los contenedores para ver las soluciones que componen los servicios en la nube que nuestros clientes ejecutan en el entorno de producción. Y aquí están los 10 mejores de ellos:
De los nuevos productos de este año son Node.js y Go (también conocido como golang), que están por delante de Java en términos de uso. Java es merecidamente considerado uno de los lenguajes de programación sobresalientes. DevOps y los equipos en la nube parecen preferir nuevas opciones, como Go, creado por ingenieros de Google, en parte porque son más fáciles de usar. Por ejemplo, Node.js, un marco de trabajo de JavaScript, facilita la escritura de código que funciona igualmente bien tanto en servidores como en navegadores. También es adecuado para una nueva generación de bases de datos como CouchDB y MongoDB que admiten consultas escritas en JavaScript.
Vida del envase
Los parámetros de cuánto tiempo (o qué tan poco) viven los contenedores, las imágenes y los servicios de los contenedores son uno de los temas más populares en nuestro informe para 2018. Refleja cómo las aplicaciones modernas son más dinámicas, tanto en términos de desarrollo como en términos de tiempo de ejecución.
Corta vida útil del contenedor
Comparando año tras año la vida útil de los contenedores, encontramos que el número de contenedores que viven menos de 10 segundos se duplicó y alcanzó el 22%. Al mismo tiempo, la cantidad de contenedores que viven 5 minutos o menos también se duplicó.
Muchos contenedores requieren una vida útil corta para cumplir la función y autodestruirse inmediatamente. Parece que los segundos no son suficientes, pero para algunos procesos no se requiere más. Creemos que el mayor uso de Kubernetes Jobs, que ejecuta tareas finales como trabajos por lotes, contribuyó a este crecimiento. Para decir más, esperamos un aumento en la cantidad de contenedores de baja vida útil, especialmente en plataformas sin servidor que son adecuadas para ejecutar tareas a corto plazo.
La naturaleza efímera de los contenedores es una de las ventajas únicas de la tecnología. Al mismo tiempo, complica enormemente tareas como "ver problemas de seguridad, rendimiento y rendimiento". Las herramientas de monitoreo, seguridad y cumplimiento en tiempo real que brindan observabilidad en tiempo real a la luz de los procesos de corta duración son clave para las operaciones exitosas.
Desarrollo continuo y vida útil de las imágenes.
Los contenedores son el compañero perfecto para la agilidad. Ayudan a acelerar el desarrollo y la liberación de código, a menudo en forma de microseurises en contenedores. Descubrimos que más de la mitad de las imágenes del contenedor son reemplazadas, o revisadas, en una semana o menos. Esto es una indicación de cómo acortó el tiempo entre lanzamientos de código. Además, esto indica que las canalizaciones de CI / CD ayudan a los equipos de desarrollo a entregar actualizaciones de software a un ritmo inusualmente rápido.
Métrica de código especial
Las métricas de código especiales permiten a los desarrolladores y equipos de DevOps personalizar el código para recopilar métricas únicas. De las tres soluciones fundamentales: JMX, StatsD y Prometheus, durante el año pasado, Prometheus se ha convertido en un líder en términos de usabilidad. De hecho, a lo largo de los años, el uso de métricas de Prometheus para nuestros clientes que usan métricas personalizadas ha crecido un 130%. Las métricas JMX (para aplicaciones Java) y StatsD se usan cada vez menos (45% y 17% respectivamente este año) a medida que crece el uso de nuevos marcos de programación que admiten Prometheus.
Para conocer las principales métricas y exportadores de Prometheus utilizados por los clientes de Sysdig, consulte el informe completo.
Configuración de emergencia superior
La configuración de emergencia de los clientes de Sysdig demuestra claramente qué comandos de la nube son las mayores amenazas para las operaciones de contenedores. La configuración de emergencia más común ha cambiado a favor de la infraestructura de Kubernetes, mientras continúa centrándose en la utilización de recursos y el tiempo de actividad. Aquí están los 3 principales de más de 800 configuraciones de emergencia únicas distribuidas a los clientes de Sysdig:
Además, las alertas se pueden configurar para etiquetas específicas o accesos directos a la nube / Kubernetes. Digamos que, utilizando el ejemplo de las alertas anteriores, puede vincular la alerta cpu.used.percent a un espacio de nombres individual de tipo "istio-system", o a un nombre de Pod específico de tipo "enviado" dentro del espacio de nombres. Vea los enlaces de alerta superior en el informe completo.
Patrones de uso de Kubernetes
¿Cuántos clústeres están administrando los usuarios? ¿Cuántas vainas en cada nodo? ¿Alguien usa Kubernetes Jobs? El informe de 2019 responde a estas y otras preguntas. Aquí hay un ejemplo de lo que los clientes están implementando con Kubernetes.
Algunos clientes instalan solo unos pocos grupos, uno más grande y un poco más pequeño, mientras que otros tienen una flota impresionante de muchos grupos de varios tamaños. Las tablas a continuación muestran la distribución de la cantidad de clústeres y la cantidad de nodos por clúster para clientes de la plataforma Sysdig:
Un gran número de clientes que administran un solo clúster o un pequeño número de ellos indica que muchas empresas recién comienzan a desarrollar Kubernetes. El resultado de la observación también estuvo influenciado por el uso de los servicios gestionados de Kubernetes en las nubes públicas. Con servicios como Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) e IBM Cloud Kubernetes Service (IKS), los usuarios pueden girar y dividir clústeres tan rápido como quieran.
El número de pods por cluster
Las vainas son el objeto desplegable más pequeño en Kubernetes. Consisten en uno o más contenedores con un almacenamiento y una red comunes, así como una especificación sobre cómo iniciar contenedores. Aquí hay un análisis de los usuarios de la plataforma Sysdig:
Importante! Esta tabla ha sido actualizada para corregir el error en la imagen original. ¡Muchas gracias a Chris Collins, también conocido como @ChrisInDurham , por notar el problema!
Número de pods por servidor físico
El pod existe en el servidor físico hasta que se completen todos sus procesos, pero puede eliminarse cuando se traslada a otro servidor en caso de recursos insuficientes o una falla del servidor físico. Aquí hay una instantánea de la distribución de Pods al servidor para los usuarios de la plataforma Sysdig:
La información sobre el número de espacios de nombres, implementaciones, StatefulSets y tareas de Kubernetes está disponible en el informe completo.
Conclusiones
Desde nuestro último informe de uso, la densidad del contenedor se ha duplicado, y es obvio que la velocidad de desarrollo aumenta a medida que se acostumbra. Los hallazgos clave de nuestro tercer informe anual enfatizan la necesidad de que las empresas tomen medidas para prepararse para el rápido crecimiento esperado:
- Las organizaciones deberían invertir en las herramientas de Kubernetes para simplificar las operaciones escalables.
- La observabilidad en tiempo real, que proporciona registros detallados de auditoría y análisis para contenedores de baja vida, es fundamental para la seguridad de las operaciones.
- Para adelantarse a los riesgos del tiempo de ejecución, los equipos en la nube deben actuar ahora e integrar la seguridad en DevOps.
- A medida que Prometheus fortalece su posición como líder en los estándares de recopilación de métricas de aplicaciones en la nube, los usuarios deben aprender cómo usarlo mientras proporcionan confiabilidad y escalabilidad.
Para conocer todos los detalles, descargue el Informe de uso de Sysdig completo para 2019 .