Міграція агентів телеметрії та безпеки з dockershim

Підтримка Kubernetes прямої інтеграції з Docker Engine є застарілою та була видалена. Більшість застосунків не мають прямої залежності від середовища виконання контейнерів. Однак, є ще багато агентів телеметрії та моніторингу, які мають залежність від Docker для збору метаданих, логів та метрик контейнерів. Цей документ збирає інформацію про те, як виявити ці залежності, а також посилання на те, як перенести ці агенти для використання загальних інструментів або альтернативних середовищ виконання.

Агенти телеметрії та безпеки

У кластері Kubernetes є кілька різних способів запуску агентів телеметрії чи безпеки. Деякі агенти мають пряму залежність від Docker Engine, коли вони працюють як DaemonSets або безпосередньо на вузлах.

Чому деякі агенти телеметрії взаємодіють з Docker Engine?

Історично Kubernetes був спеціально створений для роботи з Docker Engine. Kubernetes займався мережею та плануванням, покладаючись на Docker Engine для запуску та виконання контейнерів (у Podʼах) на вузлі. Деяка інформація, яка стосується телеметрії, наприклад, імʼя Podʼа, доступна лише з компонентів Kubernetes. Інші дані, такі як метрики контейнерів, не є обовʼязком середовища виконання контейнера. Ранні агенти телеметрії мали потребу у запиті середовища виконання контейнера та Kubernetes для передачі точної картини. З часом Kubernetes набув можливості підтримки кількох середовищ виконання контейнерів, і зараз підтримує будь-яке середовище виконання, яке сумісне з інтерфейсом середовища виконання контейнерів.

Деякі агенти телеметрії покладаються тільки на інструменти Docker Engine. Наприклад, агент може виконувати команду, таку як docker ps чи docker top для отримання переліку контейнерів та процесів або docker logs для отримання поточних логів. Якщо вузли у вашому проточному кластері використовують Docker Engine, і ви переходите на інше середовище виконання контейнерів, ці команди більше не працюватимуть.

Виявлення DaemonSets, що залежать від Docker Engine

Якщо Pod хоче викликати dockerd, що працює на вузлі, він повинен або:

• змонтувати файлову систему, що містить привілейований сокет Docker, як том; або
• безпосередньо змонтувати конкретний шлях привілейованого сокета Docker, також як том.

Наприклад: на образах COS Docker відкриває свій Unix сокет у /var/run/docker.sock. Це означає, що специфікація Pod буде містити монтування тому hostPath з /var/run/docker.sock.

Нижче наведено приклад сценарію оболонки для пошуку Podʼів, які мають монтування, які безпосередньо зіставляються з сокетом Docker. Цей сценарій виводить простір імен та імʼя Podʼу. Ви можете видалити grep '/var/run/docker.sock', щоб переглянути інші монтування.

kubectl get pods --all-namespaces \
-o=jsonpath='{range .items[*]}{"\n"}{.metadata.namespace}{":\t"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.hostPath.path}{", "}{end}{end}' \
| sort \
| grep '/var/run/docker.sock'

Виявлення залежності від Docker агентів вузлів

Якщо вузли кластера налаштовані та встановлюють додаткові заходи безпеки та агенти телеметрії на вузлі, перевірте у вендора агента, чи має він будь-які залежності від Docker.

Вендори агентів телеметрії та безпеки

Цей розділ призначений для збирання інформації про різноманітних агентів телеметрії та безпеки, які можуть мати залежність від середовищ виконання контейнерів.

Ми зберігаємо робочу версію інструкцій щодо перенесення для різних вендорів агентів телеметрії та безпеки у документі Google. Будь ласка, звʼяжіться з вендором, щоб отримати актуальні інструкції щодо міграції з dockershim.

Міграція з dockershim

Aqua

Ніяких змін не потрібно: все має працювати без перешкод при перемиканні середовища виконання.

Datadog

Як перенести: Застарівання Docker у Kubernetes Pod, який має доступ до Docker Engine, може мати назву, яка містить будь-що з:

• datadog-agent
• datadog
• dd-agent

Dynatrace

Як перенести: Міграція з Docker до загальних метрик контейнера в Dynatrace

Оголошення підтримки Containerd: Автоматична повна видимість у стеку в середовищах Kubernetes на основі containerd

Оголошення підтримки CRI-O: Автоматична повна видимість у ваших контейнерах Kubernetes з CRI-O (бета)

Pod, який має доступ до Docker, може мати назву, яка містить:

• dynatrace-oneagent

Falco

Як перенести: Міграція Falco з dockershim. Falco підтримує будь-яке середовище виконання, сумісне з CRI (стандартно використовується containerd); документація пояснює всі деталі. Pod, який має доступ до Docker, може мати назву, яка містить:

• falco

Prisma Cloud Compute

Перевірте документацію для Prisma Cloud, в розділі "Встановлення Prisma Cloud в кластер CRI (не Docker)". Pod, який має доступ до Docker, може мати назву, подібну до:

• twistlock-defender-ds

SignalFx (Splunk)

Смарт-агент SignalFx (застарілий) використовує кілька різних моніторів для Kubernetes, включаючи kubernetes-cluster, kubelet-stats/kubelet-metrics та docker-container-stats. Монітор kubelet-stats раніше був застарілим вендором на користь kubelet-metrics. Монітор docker-container-stats є одним з тих, що стосуються видалення dockershim. Не використовуйте монітор docker-container-stats з середовищами виконання контейнерів, відмінними від Docker Engine.

Як перейти з агента, залежного від dockershim:

1. Видаліть docker-container-stats зі списку налаштованих моніторів. Зверніть увагу, що залишення цього монітора увімкненим з не-dockershim середовищем виконання призведе до неправильних метрик при встановленні docker на вузлі та відсутності метрик, коли docker не встановлено.
2. Увімкніть та налаштуйте монітор kubelet-metrics.

Pod, який має доступ до Docker, може мати назву, подібну до:

• signalfx-agent

Yahoo Kubectl Flame

Flame не підтримує середовищ виконання контейнера, відмінні від Docker. Див. https://github.com/yahoo/kubectl-flame/issues/51