Aujourd'hui, nous sommes très heureux de présenter le rapport d' utilisation des conteneurs Sysdig pour 2019 ( rapport d'utilisation des conteneurs Sysdig 2019 ). Kubernetes continue de prendre de l'ampleur, les architectures cloud explorent de plus en plus, et tout cela change non seulement les modèles d'utilisation, mais aussi les processus et les structures organisationnelles. Étonnamment, cette année, le nombre de conteneurs a doublé, dont la durée de vie ne dépasse pas 5 minutes. Plus les services deviennent dynamiques, meilleures sont les équipes cloud qui reconnaissent la nécessité d'intégrer la sécurité dans les processus DevOps. Dans le cadre de notre rapport d'utilisation pour 2019, nous explorons pour la première fois les détails de sécurité et de conformité, en plus d'un certain nombre de détails sur la façon dont les clients utilisent les conteneurs, Kubernetes, etc.
Position Sysdig unique
La plate-forme Sysdig Secure DevOps offre une véritable perspective sur l'infrastructure, les applications et les conteneurs. Notre rapport couvre les entreprises du monde entier et dans de nombreux domaines. Cette année, nous avons inclus des détails sur les utilisateurs locaux SaaS et Sysdig pour vous donner une image de l'utilisation commerciale de deux millions de conteneurs déployés à titre d'exemple.
En savoir plus sur les résultats.
Dans notre rapport de 2018, nous avons décrit comment l' Open Container Initiative (OCI) a aidé à introduire des environnements de lancement de conteneurs alternatifs. En 2019, cela s'est produit à grande échelle: le projet containerd s'est emparé d'une part importante de 18%. En toute honnêteté, il convient de noter que containerd est utilisé par Docker. Auparavant, son moteur implémentait à la fois des fonctions de haut niveau et de bas niveau de l'environnement de lancement. Maintenant, ils sont divisés en deux projets distincts: containerd et runc.
Le CRI-O a fait ses débuts cette année. Entre autres, nous avons été surpris par le faible niveau de développement aujourd'hui. CRI-O, le runtime léger Kubernetes, est apparu sur Red Hat en 2016 et a été accepté dans CNCF © en 2019. Nous pensons que le niveau de développement augmentera dès que les utilisateurs de Red Hat OpenShift migreront de la v3 vers la v4, où CRI-O remplace le moteur Docker précédemment adopté.
La densité des conteneurs sur un serveur physique augmente de 100%
Au cours de la dernière année, le nombre moyen de conteneurs par serveur physique est passé à 30, doublant par rapport à 15 en 2018 et 10 en 2017.
Nous pensons que ce chiffre augmentera en fonction de plusieurs facteurs:
- Une augmentation du nombre d'applications migrées vers l'infrastructure cloud;
- Inclusion de données provenant de clients Sysdig locaux exécutant des clusters plus grands et plus denses;
- La croissance du calcul de la "puissance", permettant à plus de conteneurs de fonctionner sur chaque serveur.
En 2019, la densité maximale de conteneurs par nœud était de 250, ce qui représente une augmentation de 38% par rapport à 2018.
Container Orchestra: Kubernetes domine
Il n'est pas surprenant qu'en tant qu'instrument d'orchestration de facto, Kubernetes ait pris jusqu'à 77% de la part des orchestrateurs utilisés. Ce nombre passera à 89% si vous ajoutez Red Hat OpenShift et Rancher - tous deux construits sur Kubernetes. Et voici la situation actuelle en chiffres:
Si vous séparez les données des entreprises qui déploient la plate-forme Sysdig localement, l'image de l'orchestration change considérablement. Dans ce segment, la plate-forme Red Hat OpenShift Container prend les devants. La raison principale est que les organisations d'utilisateurs, généralement grandes et prudentes, veulent tirer parti de Kubernetes, mais préfèrent le faire avec des solutions locales prises en charge commercialement telles que Platform as a Service (PaaS), telles que OpenShift.
Toujours dans le rapport 2019, nous examinons les statistiques sur l'utilisation des clouds publics. Téléchargez-le pour plus de détails .
Sécurité et conformité
«Mettre en œuvre la sécurité à l'avance» est devenu une expression obsessionnelle. Il décrit une approche où la sécurité est intégrée dans les premières étapes du cycle de vie du développement. En général, les organisations de conteneurs savent comment intégrer la sécurité et la conformité dans le flux de travail DevOps. Pour avoir un aperçu de la sécurité et de la conformité dans les conteneurs et Kubernetes, nous analysons les données des domaines de l'analyse des vulnérabilités, de la sécurité de l'environnement de démarrage et de la conformité CIS.
Gestion des vulnérabilités
Les clients analysent les images pour détecter, bloquer et éliminer les vulnérabilités des conteneurs dans les pipelines CI / CD et les registres de conteneurs. Dans le rapport complet, nous regardons les registres utilisés, le pourcentage d'images extraites de référentiels publics et privés. Nous donnons également le rapport de numérisation réussie / infructueuse des images pour les vulnérabilités. Voici quelques conclusions.
Extraction d'images: référentiels publics ou privés
Combien de conteneurs sont récupérés à partir de référentiels publics ou privés? Nous avons constaté que 40% des images proviennent de sources accessibles au public.
L'utilisation d'images de conteneurs à partir de référentiels ouverts est lourde - car seules quelques-unes d'entre elles répondent aux normes ou sont vérifiées pour les failles de sécurité. Prenons, par exemple, le Docker Hub : les images étiquetées «Certified», «Official» et «Verified Publisher» sont plus fiables. Cependant, sur les trois millions d'images hébergées sur le serveur, moins de 1% ont de telles désignations. Pour atténuer les risques, les équipes cloud créent des stratégies pour déterminer quels registres de conteneurs peuvent être approuvés pour une utilisation dans leurs organisations.
Numérisation d'image
Quelle que soit la source, l'analyse d'une image à la recherche de vulnérabilités connues avant de la déployer dans un environnement de production est la meilleure pratique à ne pas négliger. Pour évaluer l'étendue des risques ou des vulnérabilités, nous avons prélevé des échantillons des images qui ont réussi et échoué à l'analyse, numérisées sur une période de 5 jours. Plus de la moitié des images n'ont pas réussi le test, ce qui signifie que des vulnérabilités connues d'un degré de danger élevé et très élevé y ont été identifiées.
Risques de sécurité
Une fois que les développeurs ont résolu les problèmes connus, les équipes cloud doivent établir des politiques qui déterminent les comportements anormaux et forcent le déclenchement d'une alerte de sécurité dans un environnement de production. L'environnement de démarrage de la sécurité pour Kubernetes est quelque chose de nouveau pour les entreprises, mais elles comprennent rapidement ce qui est quoi. Au cours de la dernière année, Falco , le projet de sécurité open source du CNCF pour la sécurité de l'environnement de lancement, a contribué Sysdig à partir du Docker Hub 6,7 millions de fois. C'est 252% de plus que l'année précédente.
Nous avons examiné une violation de politique dans le contexte du volume d'alertes que les clients ont reçues de Sysdig Secure, qui automatise la sécurité de l'environnement de lancement avec les politiques Falco. Il identifie les types de risques de sécurité les plus fréquemment rencontrés par les utilisateurs de conteneurs. Parmi eux, les plus courants sont:
1 - Tentatives d'accès aux volumes, répertoires ou fichiers sensibles; 2 - Mise en route avec trop d'autorisations ou tentatives d'étendre les privilèges; 3 - Lancement d'un shell de commande depuis un terminal connecté
Dans un rapport complet sur l'utilisation, nous examinons en détail 10 violations, les classons par fréquence, et en même temps décrivons chacune d'entre elles, expliquons la menace potentielle.
Conformité
Pour réduire les risques et respecter les normes de conformité, notamment PCI-DSS, HIPAA et GDPR, les organisations doivent régulièrement revoir les serveurs et les conteneurs en utilisant les meilleures pratiques. Les audits effectués à l'aide des benchmarks CIS intégrés pour les vérifications Docker dans Sysdig Secure montrent qu'il y a encore place à amélioration. Par exemple, nous avons découvert qu'en général, sur les serveurs de conteneurs, il y a:
Top 10 des solutions de conteneurs Open Source
L'open source a changé le visage du traitement des données à l'échelle de l'entreprise. Il stimule non seulement l'innovation dans l'ensemble de l'infrastructure, mais aussi en particulier dans le développement d'applications. Sysdig ouvre automatiquement les processus à l'intérieur des conteneurs pour voir les solutions qui composent les services cloud que nos clients exécutent dans l'environnement de production. Et voici le top 10 d'entre eux:
Cette année, les nouveaux produits sont Node.js et Go (alias golang), qui sont en avance sur Java en termes d'utilisation. Java est à juste titre considéré comme l'un des langages de programmation exceptionnels. Les équipes DevOps et cloud semblent préférer les nouvelles options, comme Go, créées par les ingénieurs de Google, en partie parce qu'elles sont plus faciles à utiliser. Par exemple, Node.js, un framework JavaScript, facilite l'écriture de code qui fonctionne aussi bien sur les serveurs que sur les navigateurs. Il est également bien adapté à une nouvelle génération de bases de données telles que CouchDB et MongoDB qui prennent en charge les requêtes écrites en JavaScript.
Vie de conteneur
Les paramètres de la durée (ou de la durée) de vie des conteneurs, les images et les services des conteneurs sont l'un des sujets les plus populaires de notre rapport pour 2018. Il reflète la façon dont les applications modernes sont plus dynamiques, à la fois en termes de développement et en termes d'exécution.
Durée de vie courte du conteneur
En comparant année après année la durée de vie des conteneurs, nous avons constaté que le nombre de conteneurs vivant moins de 10 secondes doublait et s'élevait à 22%. Dans le même temps, le nombre de conteneurs qui vivent 5 minutes ou moins a également doublé.
De nombreux conteneurs nécessitent une courte durée de vie pour remplir simplement la fonction et s'autodétruire immédiatement. Il semble que les secondes ne soient pas suffisantes, mais pour certains processus, il n'est pas nécessaire d'en faire plus. Nous pensons que l'utilisation accrue des travaux Kubernetes, qui exécutent des tâches de fin comme les travaux par lots, a contribué à cette croissance. Pour en dire plus, nous nous attendons à une augmentation du nombre de conteneurs à faible niveau de vie, en particulier sur les plates-formes sans serveur qui sont bien adaptées pour exécuter des tâches à court terme.
La nature éphémère des conteneurs est l'un des avantages uniques de la technologie. Dans le même temps, cela complique considérablement les tâches telles que «voir les problèmes de sécurité, de performances et de performances». Des outils de surveillance, de sécurité et de conformité en temps réel qui fournissent une observabilité en temps réel à la lumière de processus de courte durée sont la clé du succès des opérations.
Développement et durée de vie continus des images
Les conteneurs sont le compagnon idéal de l'agilité. Ils aident à accélérer le développement et la publication de code, souvent sous la forme de microseurises conteneurisées. Nous avons constaté que plus de la moitié des images de conteneurs sont remplacées - ou révisées - en une semaine ou moins. C'est une indication de la façon dont le temps entre les versions de code a été raccourci. De plus, cela indique que les pipelines CI / CD aident les équipes de développement à fournir des mises à jour logicielles à un rythme inhabituellement rapide.
Mesures de code spéciales
Des métriques de code spéciales permettent aux développeurs et aux équipes de DevOps de personnaliser le code pour collecter des métriques uniques. Parmi les trois solutions fondamentales: JMX, StatsD et Prometheus, au cours de l'année écoulée, Prometheus est devenu un leader en termes de convivialité. En fait, au fil des ans, l'utilisation des métriques Prometheus pour nos clients qui utilisent des métriques personnalisées a augmenté de 130%. Les métriques JMX (pour les applications Java) et StatsD sont de moins en moins utilisées (45% et 17% respectivement cette année) à mesure que l'utilisation de nouveaux cadres de programmation prenant en charge Prometheus se développe.
Pour les principales métriques et exportateurs de Prometheus utilisés par les clients Sysdig, voir le rapport complet.
Principaux paramètres d'urgence
Les paramètres d'urgence des clients Sysdig montrent clairement quelles commandes cloud sont les plus grandes menaces pour les opérations de conteneur. Les paramètres d'urgence les plus courants se sont déplacés en faveur de l'infrastructure Kubernetes, tout en continuant de se concentrer sur l'utilisation des ressources et la disponibilité. Voici le Top 3 de plus de 800 paramètres d'urgence uniques distribués aux clients Sysdig:
De plus, les alertes peuvent être configurées pour des balises spécifiques ou des raccourcis cloud / Kubernetes. Supposons, en utilisant l'exemple des alertes ci-dessus, que vous pouvez lier l'alerte cpu.used.percent à un espace de noms individuel de type "istio-system", ou à un nom de pod spécifique de type "envoyé" à l'intérieur de l'espace de noms. Consultez les principales liaisons d'alerte dans le rapport complet.
Modèles d'utilisation de Kubernetes
Combien de clusters les utilisateurs gèrent-ils? Combien de pods sur chaque nœud? Quelqu'un utilise-t-il les travaux Kubernetes? Le rapport 2019 répond à ces questions et à d'autres. Voici un exemple de ce que les clients déploient avec Kubernetes.
Certains clients n'installent que quelques clusters - un plus grand et un peu plus petit - tandis que d'autres ont une flotte impressionnante de nombreux clusters de différentes tailles. Les tableaux ci-dessous indiquent la répartition du nombre de clusters et du nombre de nœuds par cluster pour les clients de la plateforme Sysdig:
Un grand nombre de clients gérant un seul cluster ou un petit nombre d'entre eux indique que de nombreuses entreprises commencent tout juste à développer Kubernetes. Le résultat de l'observation a également été influencé par l'utilisation des services gérés de Kubernetes dans les clouds publics. Avec des services comme Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) et IBM Cloud Kubernetes Service (IKS), les utilisateurs peuvent tourner et fractionner les clusters aussi rapidement qu'ils le souhaitent.
Le nombre de pods par cluster
Les pods sont le plus petit objet déployable de Kubernetes. Ils se composent d'un ou plusieurs conteneurs avec un stockage et un réseau communs, ainsi qu'une spécification sur la façon de démarrer les conteneurs. Voici une analyse des utilisateurs de la plateforme Sysdig:
Important! Ce tableau a été mis à jour pour corriger l'erreur dans l'image d'origine. Un grand merci à Chris Collins - alias @ChrisInDurham - pour avoir remarqué le problème!
Nombre de pods par serveur physique
Le pod existe sur le serveur physique jusqu'à ce que tous ses processus soient terminés, mais peut être supprimé lors du déplacement vers un autre serveur en cas de ressources insuffisantes ou d'une panne du serveur physique. Voici un aperçu de la distribution des pods sur le serveur pour les utilisateurs de la plateforme Sysdig:
Des informations sur le nombre d'espaces de noms, de déploiements, de StatefulSets et de tâches Kubernetes sont disponibles dans le rapport complet.
Conclusions
Depuis notre dernier rapport d'utilisation, la densité des conteneurs a doublé et il est évident que la vitesse de développement augmente à mesure que vous vous y habituez. Les principales conclusions de notre troisième rapport annuel soulignent la nécessité pour les entreprises de prendre des mesures pour se préparer à la croissance rapide attendue:
- Les organisations doivent investir dans les outils Kubernetes pour simplifier les opérations évolutives.
- L'observabilité en temps réel, fournissant des audits détaillés et des enregistrements analytiques pour les conteneurs à faible durée de vie, est essentielle à la sécurité des opérations.
- Pour devancer les risques pour le runtime, les équipes cloud doivent agir maintenant - et intégrer la sécurité dans DevOps.
- Alors que Prometheus renforce sa position de leader dans les normes de collecte de métriques d'application cloud, les utilisateurs doivent apprendre à l'utiliser tout en offrant fiabilité et évolutivité.
Pour en savoir plus, téléchargez le rapport d'utilisation Sysdig complet pour 2019 .