Сегодня мы с огромной радостью представляем доклад Sysdig об использовании контейнеров за 2019 год (Sysdig 2019 Container Usage Report). Kubernetes продолжает набирать обороты, активнее осваиваются облачные архитектуры, и все это меняет не просто паттерны использования, но и процессы и организационные структуры. Удивительно, но в этом году двукратно увеличилось число контейнеров, срок жизни которых не превышает 5 минут. Чем динамичнее становятся сервисы, тем лучше облачные команды сознают необходимость интеграции безопасности в процессы DevOps. В рамках доклада об использовании за 2019 год мы впервые исследуем детали безопасности и соответствия — в дополнение к ряду деталей о том, как клиенты используют контейнеры, Kubernetes и проч.

Уникальная позиция Sysdig

Sysdig Secure DevOps Platform предоставляет реальный взгляд на инфраструктуру, приложения и контейнеры. Наш доклад охватывает компании по всему миру и во многих сферах деятельности. В этом году мы включили детали как по SaaS, так и по локальным пользователям Sysdig, чтобы представить вам картину коммерческого использования на примере двух с лишним миллионов развернутых контейнеров.

Подробнее о результатах.

Какие контейнерные платформы разворачивают?

В доклада за 2018 год мы описывали, как Open Container Initiative (OCI) помогала ввести альтернативные среды запуска контейнеров. В 2019 году это случилось и с большим размахом: проект containerd отхватил значительную долю в 18%. Справедливости ради стоит отметить, что containerd используется Docker'ом. Прежде его движок реализовал как высокоуровневые, так и низкоуровневые функции среды запуска. Теперь они разбиты на два отдельных проекта: containerd и runc.

В этом году дебютировала CRI-O. Среди прочего нас удивил низкий уровень освоения на сегодняшний день. CRI-O, облегченная среда исполнения Kubernetes, появилась в Red Hat в 2016 году и была принята в CNCF© в 2019-м. Мы думаем, уровень освоения вырастет, как только пользователи Red Hat OpenShift мигрируют с v3 на v4, где CRI-O замещает прежде принятый движок Docker'а.

Плотность контейнеров на физический сервер растет на 100%

За прошедший год среднее число контейнеров на физический сервер выросло до 30, удвоившись, по сравнению с 15 — за 2018 год и 10 в 2017-м.

Мы считаем, что эта цифра увеличится, основываясь на нескольких факторах:

Рост числа приложений, переводимых на облачную инфраструктуру;
Включение данных от локальных клиентов Sysdig, запускающих более крупные и плотные кластеры;
Рост вычислительных "лошадиных сил", позволяющий работать на каждом сервере большему числу контейнеров.

В 2019 году максимальная плотность контейнеров на узел составляла 250, а это — 38-процентное увеличение, по сравнению с 2018 годом.

Оркестрация контейнеров: Kubernetes доминирует

Неудивительно, что как инструмент оркестрации де-факто Kubernetes забрал аж 77% доли используемых оркестраторов. Это число увеличиться до 89%, если добавить Red Hat OpenShift и Rancher — оба построены на Kubernetes. А вот текущая ситуация в цифрах:

Какую платформу выбирают локальные клиенты?

Если разделить данные для компаний, которые разворачивают платформу Sysdig локально, картина оркестрации меняется значительным образом. В этом сегменте Red Hat OpenShift Container Platform выбивается в лидеры. Основная причина в том, что организации-пользователи — обычно крупные и осторожные, желают пользоваться преимуществами Kubernetes, но предпочитают делать это с коммерчески поддерживаемыми локальными решениями типа "Платформа как сервис" (PaaS), например OpenShift.

Также в докладе за 2019 год мы исследуем статистику использования общедоступных облаков. Скачайте его, чтобы узнать детали.

Безопасность и соответствие

"Внедряйте безопасность заранее" стало навязчивой фразой. Она описывает подход, когда безопасность встраивают на ранних стадиях жизненного цикла разработки. Вообще, организации, работающие с контейнерами, понимают, как необходимо внедрять безопасность и соответствие в рабочий процесс DevOps. Чтобы получить представление о безопасности и соответствии в сфере контейнеров и Kubernetes, мы анализируем данные из области сканирования на уязвимости, безопасности среды запуска и соответствия CIS.

Управление уязвимостями

Клиенты сканируют образы, чтобы обнаружить, блокировать и устранить уязвимости контейнеров в конвейерах CI/CD и реестрах контейнеров. В полном докладе мы рассматриваем используемые реестры, процент образов, извлекаемых из общедоступных и частных репозиториев. Также даем соотношение успешное/неуспешное сканирование образов на уязвимости. Вот несколько выводов.

Извлечение образов: общественные vs частные репозитории

Сколько контейнеров извлекается из общедоступных или частных репозиториев? Мы выяснили, что 40% образов происходят из общедоступных источников.

Использовать образы контейнеров из открытых репозиториев чревато — потому, что лишь немногие из них соответствуют стандартам или проверены на уязвимости в плане безопасности. Возьмем, к примеру, Docker Hub: образы, помеченные "Certified", "Official" и "Verified Publisher" больше достойны доверия. Однако из трех миллионов образов, размещенных на сервере, менее 1% имеют такие обозначения. С целью снизить риск, облачные команды создают политики для определения, какие реестры контейнеров могут быть одобрены к использованию в их организациях.

Сканирование образа

Независимо от источника, сканировать образа на предмет известных уязвимостей перед развертыванием в производственную среду — лучшая практика, пренебрегать которой нельзя. Чтобы оценить масштаб рисков или уязвимостей, мы взяли образцы прошедших и не прошедших проверку образов, просканированных за 5-дневный период. Больше половины образов проверку не прошли, а значит, в них были выявлены известные уязвимости высокой и очень высокой степени опасности.

Угрозы безопасности среды исполнения

После того, как разработчики рассмотрят известные проблемы, облачные команды должны установить политики, определяющие аномальное поведение и заставляющие срабатывать оповещение безопасности в производственной среде. Безопасность среды запуска для Kubernetes — это нечто новое для компаний, но понимают они, что к чему, быстро. За последний год из Docker Hub 6,7 млн раз извлекли Falco, открытый проект CNCF для безопасности среды запуска, вклад Sysdig. Это на 252% больше, чем за предшествующий год.

Мы смотрели на нарушение политик в контексте объема оповещений, которые клиенты получили от Sysdig Secure, который автоматизирует безопасность среды запуска с политиками Falco. Он определяет типы рисков для безопасности, с которыми чаще всего сталкиваются пользователи контейнеров. Среди них самые распространенные это:

1 — Попытки получить доступ к чувствительным томам, каталогам или файлам; 2 — Начало работы при слишком большом количестве разрешений или попыток расширить привилегии; 3 — Запуск командной оболочки с привязанного терминала

В полном докладе об использовании мы детально рассматриваем 10 нарушений, ранжируя их по частотности, а заодно описываем каждое из них, объясняем потенциальную угрозу.

Соответствие

Чтобы снизить риск и удовлетворить стандартам соответствия, включающим PCI-DSS, HIPAA и GDPR, организациям следует регулярно проверять серверы и контейнеры при помощи лучших практик. Аудиты, выполненные с использованием встроенных контрольных показателей CIS для проверок Docker в Sysdig Secure показывают, что улучшать еще есть что. Например, мы выяснили, что обычно на контейнерных серверах встречаются:

Топ-10 решений с открытым исходным кодом, работающих в контейнерах

Open-source изменил лицо обработки данных в масштабах организаций. Он не просто стимулирует инновации по всей инфраструктуре, но и особенно в разработке приложений. Sysdig автоматически вскрывает процессы внутри контейнеров, чтобы увидеть решения, составляющие облачные сервисы, которые наши клиенты запускают в производственной среде. И вот топ-10 из них:

Из новинок этого года — Node.js и Go (он же golang), которые в плане использования опережают Java. Java заслуженно считается одним из выдающихся языков программирования. Команды DevOps и облачные команды, похоже, предпочитают опции поновее, вроде Go, созданные инженерами Google, — отчасти, потому что они проще в использовании. Например, Node.js, среда для выполнения JavaScript, упрощает написание кода, который одинаково хорошо работает как на серверах, так и в браузерах. Он также хорошо подходит для нового поколения баз данных типа CouchDB и MongoDB, поддерживающих написанные на JavaScript запросы.

Срок жизни контейнеров

Параметры того, как долго (или как мало) живут контейнеры, образы контейнеров и сервисы, одна из самых популярных тем нашего доклада за 2018 год. Он отражает, насколько современные приложения динамичнее, — как с точки зрения разработки, так и с точки зрения среды выполнения.

Короткая жизнь контейнеров

Сравнивая год за годом сроки жизни контейнеров, мы обнаружили, что число контейнеров, живущих менее 10 секунд, удвоилось и составляет 22%. При этом число контейнеров, которые живут 5 минут и менее, также удвоилось.

Многим контейнерам требуется короткий срок жизни, чтобы только выполнить функцию и сразу самоуничтожиться. Секунды — это, вроде бы, мало, но для некоторых процессов большего не требуется. Мы считаем, что этому росту поспособствовало увеличенное использование Kubernetes Jobs, запускающих конечные задачи типа пакетных работ. Скажем больше, мы ожидаем увеличения количества маложивущих контейнеров, особенно на бессерверных платформах, которые хорошо подходят для запуска краткосрочных задач.

Эфемерная природа контейнеров — это одно из уникальных преимуществ технологии. В то же время она сильно усложняет задачи типа "увидеть проблемы с безопасностью, работоспособностью и производительностью". Инструменты мониторинга, безопасности и соответствия в реальном времени, обеспечивающие наблюдаемость в реальном времени, в свете коротко живущих процессов, — это ключ к успешным операциям.

Непрерывная разработка и сроки жизни образов

Контейеры — идеальный компаньон для гибкого движения. Они помогают ускорить разработку и релиз кода, зачастую в виде контейнеризированных микросеврисов. Мы выяснили, что более половины образов контейнеров заменяются — или пересматриваются — в течение недели или меньше. Это показатель того, как сократилось время между релизами кода. Далее, это указывает на то, что конвейеры CI/CD помогают командам разработчиков поставлять обновления ПО в необычайно высоких темпах.

Специальные метрики кода

Специальные метрики кода позволяют разработчикам и командам DevOps настраивать код так, чтобы он собирал уникальны метрики. Из трех основополагающих решений: JMX, StatsD и Prometheus, — за прошедший год Prometheus выбился в лидеры по используемости. На самом деле, с годами использование метрик Prometheus у наших клиентов, которые используют специальные метрики, выросло на 130%. Метрики JMX (для приложений на Java) и StatsD используются все реже (в этом году на 45% и 17% соответственно), по мере того как ширится использование новых фреймворков для программирования, поддерживающих Prometheus.

Чтобы узнать топовые метрики и exporters Prometheus, которыми пользуются клиенты Sysdig, смотрите полный доклад.

Топ аварийных настроек

Настройки аварийных ситуаций у клиентов Sysdig наглядно демонстрируют, в чем облачные команды наибольшие угрозы для операций контейнеров. Самые распространенные аварийные настройки сместились в пользу инфраструктуры Kubernetes, продолжая в то же время фокусироваться на использовании ресурсов и работоспособности. Вот Топ-3 из более чем 800 уникальных аварийных настроек, распространенных у клиентов Sysdig:

Плюс к этому, оповещения могут быть настроены на конкретные метки или облачные ярлыки / Kubernetes. Скажем, используя пример из вышеприведенных оповещений, вы можете привязать оповещение cpu.used.percent к индивидуальному пространству имен типа "istio-system", или конкретному имени Pod'а типа "envoy" внутри пространства имен. Посмотрите топ привязок для оповещений в полном докладе.

Паттерны использования Kubernetes

Сколькими кластерами управляют пользователи? Сколько Pod'ов на каждом узле? Использует ли кто-нибудь Kubernetes Jobs? Доклад за 2019 год отвечает на эти и другие вопросы. Вот пример того, что клиенты разворачивают с Kubernetes.

Какие-то клиенты устанавливают всего несколько кластеров — один больше и несколько поменьше, — тогда как другие располагают внушительным парком из множества кластеров разнообразных размеров. Таблицы ниже показывают распределение числа кластеров и количества узлов на кластер у клиентов платформы Sysdig:

Большое число клиентов, управляющих единственным кластером или небольшим их числом, указывает на то, что многие предприятия еще только начинают осваивать Kubernetes. На результат наблюдения повлияло и использование управляемых сервисов Kubernetes в общедоступных облаках. С сервисами типа Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS) и IBM Cloud Kubernetes Service (IKS) пользователи могут раскручивать и дробить кластеры так быстро, как им надо.

Количество Pod'ов на кластер

Pod'ы — это наименьший разворачиваемый объект в Kubernetes. Они состоят из одного или нескольких контейнеров с общим хранилищем и сетью, также как и спецификацией относительного того, как запускать контейнеры. Вот анализ по пользователям платформы Sysdig:

Важно! Эта таблица обновилась, чтобы исправить ошибку в оригинальном образе. Большое спасибо Крису Коллинзу — он же @ChrisInDurham — за то, что заметил проблему!

Количество Pod'ов на физический сервер

Pod существует на физическом сервере до завершения всех своих процессов, но может быть удален при перемещении на другой сервер в случае недостатка ресурсов или отказа физического сервера. Вот снимок распределения Pod'ов на сервер у пользователей платформы Sysdig:

Информация по числу пространств имен Kubernetes, развертываний, StatefulSets и задач доступна в полном докладе.

Выводы

С последнего нашего доклада об использовании плотность контейнеров удвоилась, и очевидно, что скорость освоения повышается по мере привыкания к использованию. Ключевые выводы из нашего третьего ежегодного доклада подчеркивают потребность предприятий в шагах по подготовке к ожидаемому бурному росту:

Организациям следует инвестировать в инструменты Kubernetes для того, чтобы упростить масштабируемые операции.
Наблюдаемость в реальном времени, обеспечивающая детальный аудит и аналитические записи для маложивущих контейнеров, — критически важна для безопасности операций.
Чтобы опережать риски для среды исполнения, облачные команды должны действовать уже сейчас — и интегрировать безопасность в DevOps.
По мере того, как Prometheus укрепляется на позиции лидера в области стандартов сбора метрик облачных приложений, пользователям следует научиться использовать его, обеспечивая надежность и масштабируемость.

Для того, чтобы узнать все детали, скачайте полный доклад Sysdig об использовании за 2019 год.

Доклад Sysdig об использовании контейнеров за 2019: новые сведения о Kubernetes и безопасности