Когда в пятый раз у тебя появляется на работе падаван, которому надо все рассказать по нескольку раз, в какой-то момент приходит в голову светлая мысль все свои речи законспектировать, попутно хоть немного структурировав все это дело. Так что сия заметка о сontainerd для того, чтобы не повторяться в сотый раз. Возможно, кому-то еще это будет интересно, хотя тут все без рокет-сайнс.
После скачивания архива из релиза containerd мы получаем набор бинарей:
Пример конфига containerd, а также здесь есть более подробное описание всей структуры конфига. В частности, описано как настроить insecure registry
Пример
[plugins]
[plugins.cri.containerd]
snapshotter = "overlayfs"
[plugins.cri.registry.mirrors."local.insecure-registry.io"]
endpoint = [" http://registry.com:5000"]
Kubelet взаимодействует с containerd через сокет, расположение которого указывается через аргумент:
--container-runtime-endpoint=unix:///var/run/containerd/containerd.sock
Сontainerd, получив спеки от кубелета, запускает контейнеры через прослойку - containerd-shim, который уже в свою очередь выполняет бинарь рантайма с нужными параметрами. Эталонной реализацией считается runc.
В данный момент есть две версии api, которое использует containerd-shim. На данный момент актуальной является v2. (Прошу понять и простить за то, что примеры будут с v1). Подробнее описано здесь.
Сontainerd-shim позволяет не привязывать процессы, запущенные в контейнере к демону containerd, что есть весьма хорошо, на случай если вы вдруг решили, например, добавить внезапно "insecure registry" или другой параметр в конфиге и, вследствие этого, понадобилось перезапустить демон containerd. Если посмотреть на список процессов, то можно увидеть что изолированные процессы являются дочерними по отношению к containerd-shim, который в свою очередь выглядит примерно следующим образом:
containerd-shim -namespace k8s.io -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/k8s.io/2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd
-namespace в данному случае - это не тот, немспейс, который в кубе. Это изолированный раздел в рамках самого containerd. Для kubelet'а по умолчанию создается немспейс k8s, но вы можете создать другой, если вдруг нашли оркестратор получше или запускаете что-то руками.
-workdir определяет рабочую директорию для процесса, как ни странно.
-address и -containerd-binary указывают на сокет и бинарь containerd (а точнее, containerd-shim стучится в аргумент "containerd publish"), для того, чтобы уведомлять о состоянии контейнера в основной демон. Именно из-за этого, в случае рестарта containerd, шимы оперативно сообщат о своем состоянии и вы сможете наблюдать актуальную картину запущенных контейнеров без запуска всего с нуля для приведения к тому состоянию, которое от него требует kubelet.
Собственно, запуск контейнеров осуществляется не самим containerd, а через исполняемый файл рантайма, коих в наше время больше, чем кажется. Эталонным в наше время, как уже было отмечено, является runc, который и занимается, собственно, изоляцией или "контейнеризацией". Запускать контейнеры можно и напрямую через него (runc --help), однако при использовании containerd, runc list нам ничего не покажет. Это потому, что директория с информацией о запущенных контейнерах хранится в другом месте, в частности контейнеры бьются на каталоги соответствующие немспейсам containerd, например для куба это:
runc --root /run/containerd/runc/k8s.io/ list
Можете посмотреть состояние какого-нибудь контейнера, например:
root@kube03a:~# runc --root /run/containerd/runc/k8s.io/ state 2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644
Результат
{
"ociVersion": "1.0.2-dev",
"id": "2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644",
"pid": 28627,
"status": "running",
"bundle": "/run/containerd/io.containerd.runtime.v1.linux/k8s.io/2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644",
"rootfs": "/run/containerd/io.containerd.runtime.v1.linux/k8s.io/2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644/rootfs",
"created": "2021-07-05T02:22:28.018197224Z",
"annotations": {
"io.kubernetes.cri.container-name": "nginx",
"io.kubernetes.cri.container-type": "container",
"io.kubernetes.cri.image-name": "docker.io/library/nginx:latest",
"io.kubernetes.cri.sandbox-id": "aae43202632ad129b71f6672c3ca089e76a399d6234d89cc08751b85645f31c6",
"io.kubernetes.cri.sandbox-name": "nginx-7848d4b86f-xztfp",
"io.kubernetes.cri.sandbox-namespace": "default"
},
"owner": ""
}
Но runc, за счет своей низкоуровневости, не самое лучшее место для просмотра состояния контейнеров. Containerd распологает двумя утилитами для взаимодействия пользователя с ним: crictl и ctr.
crictl является основной утилитой для взаимодействия с containerd. Помимо аналога действий, присущих docker cli (наподобие create, exec, images и тд), есть и более интересные. К примеру, containerd знает о существовании таких сущностей, как кубовые поды (runp, rmp, pods, stopp, inspectp). Попробую вкратце упомянуть некоторые интересные вещи. Если вдруг containerd демон запущен, а crictl ругается что не может найти его, укажите сокет напрямую, например:
crictl --runtime-endpoint /var/run/containerd/containerd.sock
Начнем с info:
root@kube03a:~# crictl info 2d538b1bdc00a | jq -r '.status'
Результат
{
"conditions": [
{
"type": "RuntimeReady",
"status": true,
"reason": "",
"message": ""
},
{
"type": "NetworkReady",
"status": true,
"reason": "",
"message": ""
}
]
}
crictl inspect и inspectp выведет крайне много интересной информации. Описывать все это бессмыслено, да и все вполне очевидно. Например перечисляются маунты:
crictl inspect 2d538b1bdc00a | jq -r '.info.runtimeSpec.mounts[]'
...где сможем видеть сгенерированный resolv.conf
...
{
"destination": "/etc/resolv.conf",
"type": "bind",
"source": "/var/lib/containerd/io.containerd.grpc.v1.cri/sandboxes/aae43202632ad129b71f6672c3ca089e76a399d6234d89cc08751b85645f31c6/resolv.conf",
"options": [
"rbind",
"rprivate",
"rw"
]
}
...
Или сетевые устройства в поде:
crictl inspectp aae43202632ad | jq -r '.info.cniResult.Interfaces'
Результат
{
"cnio0": {
"IPConfigs": null,
"Mac": "3e:44:1a:e2:03:f0",
"Sandbox": ""
},
"eth0": {
"IPConfigs": [
{
"IP": "10.150.21.7",
"Gateway": "10.150.21.1"
}
],
"Mac": "5a:fe:ec:a0:c2:59",
"Sandbox": "/var/run/netns/cni-6070de8e-4e69-99c0-e619-63535af42ce5"
},
"lo": {
"IPConfigs": [
{
"IP": "127.0.0.1",
"Gateway": ""
},
{
"IP": "::1",
"Gateway": ""
}
],
"Mac": "00:00:00:00:00:00",
"Sandbox": "/var/run/netns/cni-6070de8e-4e69-99c0-e619-63535af42ce5"
},
"veth335fa7aa": {
"IPConfigs": null,
"Mac": "de:30:14:fa:26:57",
"Sandbox": ""
}
}
Из этого вывода или с помощью команды:
crictl inspectp aae43202632ad | jq -r '.info.runtimeSpec.linux.namespaces'
вы сможете обнаружить имя изолированного сетевого немспейса (это уже совсем-совсем другой немспейс)
...
{
"type": "network",
"path": "/var/run/netns/cni-6070de8e-4e69-99c0-e619-63535af42ce5"
}
...
Вбиваем
ip netns exec cni-6070de8e-4e69-99c0-e619-63535af42ce5 ip a show type veth
и получаем параметры сети в испектируемом поде.
Возвращаемся к crictl.
crictl stats -a вернет нам табличку с потребляемыми ресурсами (cpu, disk, mem, inodes), а флаг -o json вернет нам все еще и в json виде, на случай если вы вдруг что-то мониторите.
К слову, crictl imagefsinfo вернет вам что-то вроде:
{
"status": {
"timestamp": "1626124762748935841",
"fsId": {
"mountpoint": "/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs"
},
"usedBytes": {
"value": "1969491968"
},
"inodesUsed": {
"value": "77458"
}
}
}
Еще мы можем, например, посмотреть на процесс внутри контейнера:
root@kube03a:~# cat "/proc/$(crictl inspect 2d538b1bdc00a | jq -r '.info.pid')/cmdline"
...вернет:
nginx: master process nginx -g daemon off;
А в корневой каталог попасть через /proc/$PID/root/
root@kube03a:~# cat "/proc/$(crictl inspect 2d538b1bdc00a | jq -r '.info.pid')/root/etc/hostname"
nginx-7848d4b86f-xztfp
Мы видим что все, что было в inpect в списке для монтирования, на этом этапе уже на своем месте.
Можем еще получить, например, id контейнера:
сrictl inspect 2d538b1bdc00a | jq -r '.status.id'
2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644
Через этот id мы можем найти каталог с его конфигами:
root@kube03a:~# ls /var/run/containerd/io.containerd.runtime.v1.linux/k8s.io/$(crictl inspect 2d538b1bdc00a | jq -r '.status.id')
address config.json init.pid log.json rootfs shim.pid
init.pid содержит уже известный нам pid процесса в контейнере, а shim.pid - pid родительского containerd-shim. В каталоге rootfs содержится собранный из снапшотов (слоев) overlayfs запущенного контейнера, но без дополнительных монтирований.
Если посмотреть на cgroups, то тут есть два варианта, в зависимости от выбранного драйвера cgroups. Если выбран драйвер systemd, то путь в cgroups_v1 будет примерно следующий:
root@kube03a:~# cat /sys/fs/cgroup/pids/system.slice/containerd.service/kubepods-besteffort-pod$(crictl inspectp aae43202632ad | jq -r '.status.metadata.uid' | sed 's/-/_/g').slice:cri-containerd:$(crictl inspect 2d538b1bdc00a | jq -r '.status.id')/cgroup.procs
28627
28664
28665
по человечески:
cat /sys/fs/cgroup/pids/system.slice/containerd.service/kubepods-besteffort-podc7205bb2_8c97_4f79_b4c9_915e402cc7d3.slice:cri-containerd:2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644/cgroup.procs
crictl inspectp aae43202632ad | jq -r '.status.metadata.uid' - вернет нам uid пода, а crictl inspect 2d538b1bdc00a | jq -r '.status.id' - уже известный нам id контейнера. По аналогии можно обратиться к другим cgroups директориям.
Если же у вас драйвером выбран cgroups:
cat /sys/fs/cgroup/pids/kubepods/pod7d5e31f8-8797-457d-aaf2-f55464d338c6/eb2c3ad61742de7ed7a8758cc563a1470b969632f857429787668e1f354e357a/cgroup.procs
В реалтайме вы можете посмотреть cgroups через systemd-cgtop -m. Тут ведь все любят systemd, так?
Дошли наконец-таки до ctr
Для начала можно посмотреть доступные встроенные плагины.
ctr plugins ls - здесь можно посмотреть доступные снапшоттеры, которые составляют из слоев докер-образа конечный образ. Есть поддержа ZFS и BTRFS.
Далее смотрим доступные немспейсы containerd:
ctr namespaces ls
По умолчанию доступен немспейс "k8s.io". В дальнейших командах необходимо его явно указать: ctr --namespace=k8s.io containers ls
Так же можно посмотреть images (образы), events (отлов событий), content (бинарные данные из образов), snapshots (слои из образов), leases (аренда каких-либо ресурсов, подробней ), tasks (запущенные в контейнерах процессы).
Из необычного, вы можете взаимодействовать напрямую с shim или установить бинари и библиотеки из образа через crt install (это, видимо, для особо прогрессивных).
Напоследок ссылка на описание запуска контейнера через crictl для дебага.
Источник статьи: https://habr.com/ru/post/568274/
После скачивания архива из релиза containerd мы получаем набор бинарей:
- containerd
- containerd-shim
- containerd-shim-runc-v1
- containerd-shim-runc-v2
- crictl
- ctr
Пример конфига containerd, а также здесь есть более подробное описание всей структуры конфига. В частности, описано как настроить insecure registry
Пример
[plugins]
[plugins.cri.containerd]
snapshotter = "overlayfs"
[plugins.cri.registry.mirrors."local.insecure-registry.io"]
endpoint = [" http://registry.com:5000"]
Kubelet взаимодействует с containerd через сокет, расположение которого указывается через аргумент:
--container-runtime-endpoint=unix:///var/run/containerd/containerd.sock
Сontainerd, получив спеки от кубелета, запускает контейнеры через прослойку - containerd-shim, который уже в свою очередь выполняет бинарь рантайма с нужными параметрами. Эталонной реализацией считается runc.
В данный момент есть две версии api, которое использует containerd-shim. На данный момент актуальной является v2. (Прошу понять и простить за то, что примеры будут с v1). Подробнее описано здесь.
Сontainerd-shim позволяет не привязывать процессы, запущенные в контейнере к демону containerd, что есть весьма хорошо, на случай если вы вдруг решили, например, добавить внезапно "insecure registry" или другой параметр в конфиге и, вследствие этого, понадобилось перезапустить демон containerd. Если посмотреть на список процессов, то можно увидеть что изолированные процессы являются дочерними по отношению к containerd-shim, который в свою очередь выглядит примерно следующим образом:
containerd-shim -namespace k8s.io -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/k8s.io/2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd
-namespace в данному случае - это не тот, немспейс, который в кубе. Это изолированный раздел в рамках самого containerd. Для kubelet'а по умолчанию создается немспейс k8s, но вы можете создать другой, если вдруг нашли оркестратор получше или запускаете что-то руками.
-workdir определяет рабочую директорию для процесса, как ни странно.
-address и -containerd-binary указывают на сокет и бинарь containerd (а точнее, containerd-shim стучится в аргумент "containerd publish"), для того, чтобы уведомлять о состоянии контейнера в основной демон. Именно из-за этого, в случае рестарта containerd, шимы оперативно сообщат о своем состоянии и вы сможете наблюдать актуальную картину запущенных контейнеров без запуска всего с нуля для приведения к тому состоянию, которое от него требует kubelet.
Собственно, запуск контейнеров осуществляется не самим containerd, а через исполняемый файл рантайма, коих в наше время больше, чем кажется. Эталонным в наше время, как уже было отмечено, является runc, который и занимается, собственно, изоляцией или "контейнеризацией". Запускать контейнеры можно и напрямую через него (runc --help), однако при использовании containerd, runc list нам ничего не покажет. Это потому, что директория с информацией о запущенных контейнерах хранится в другом месте, в частности контейнеры бьются на каталоги соответствующие немспейсам containerd, например для куба это:
runc --root /run/containerd/runc/k8s.io/ list
Можете посмотреть состояние какого-нибудь контейнера, например:
root@kube03a:~# runc --root /run/containerd/runc/k8s.io/ state 2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644
Результат
{
"ociVersion": "1.0.2-dev",
"id": "2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644",
"pid": 28627,
"status": "running",
"bundle": "/run/containerd/io.containerd.runtime.v1.linux/k8s.io/2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644",
"rootfs": "/run/containerd/io.containerd.runtime.v1.linux/k8s.io/2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644/rootfs",
"created": "2021-07-05T02:22:28.018197224Z",
"annotations": {
"io.kubernetes.cri.container-name": "nginx",
"io.kubernetes.cri.container-type": "container",
"io.kubernetes.cri.image-name": "docker.io/library/nginx:latest",
"io.kubernetes.cri.sandbox-id": "aae43202632ad129b71f6672c3ca089e76a399d6234d89cc08751b85645f31c6",
"io.kubernetes.cri.sandbox-name": "nginx-7848d4b86f-xztfp",
"io.kubernetes.cri.sandbox-namespace": "default"
},
"owner": ""
}
Но runc, за счет своей низкоуровневости, не самое лучшее место для просмотра состояния контейнеров. Containerd распологает двумя утилитами для взаимодействия пользователя с ним: crictl и ctr.
crictl является основной утилитой для взаимодействия с containerd. Помимо аналога действий, присущих docker cli (наподобие create, exec, images и тд), есть и более интересные. К примеру, containerd знает о существовании таких сущностей, как кубовые поды (runp, rmp, pods, stopp, inspectp). Попробую вкратце упомянуть некоторые интересные вещи. Если вдруг containerd демон запущен, а crictl ругается что не может найти его, укажите сокет напрямую, например:
crictl --runtime-endpoint /var/run/containerd/containerd.sock
Начнем с info:
root@kube03a:~# crictl info 2d538b1bdc00a | jq -r '.status'
Результат
{
"conditions": [
{
"type": "RuntimeReady",
"status": true,
"reason": "",
"message": ""
},
{
"type": "NetworkReady",
"status": true,
"reason": "",
"message": ""
}
]
}
crictl inspect и inspectp выведет крайне много интересной информации. Описывать все это бессмыслено, да и все вполне очевидно. Например перечисляются маунты:
crictl inspect 2d538b1bdc00a | jq -r '.info.runtimeSpec.mounts[]'
...где сможем видеть сгенерированный resolv.conf
...
{
"destination": "/etc/resolv.conf",
"type": "bind",
"source": "/var/lib/containerd/io.containerd.grpc.v1.cri/sandboxes/aae43202632ad129b71f6672c3ca089e76a399d6234d89cc08751b85645f31c6/resolv.conf",
"options": [
"rbind",
"rprivate",
"rw"
]
}
...
Или сетевые устройства в поде:
crictl inspectp aae43202632ad | jq -r '.info.cniResult.Interfaces'
Результат
{
"cnio0": {
"IPConfigs": null,
"Mac": "3e:44:1a:e2:03:f0",
"Sandbox": ""
},
"eth0": {
"IPConfigs": [
{
"IP": "10.150.21.7",
"Gateway": "10.150.21.1"
}
],
"Mac": "5a:fe:ec:a0:c2:59",
"Sandbox": "/var/run/netns/cni-6070de8e-4e69-99c0-e619-63535af42ce5"
},
"lo": {
"IPConfigs": [
{
"IP": "127.0.0.1",
"Gateway": ""
},
{
"IP": "::1",
"Gateway": ""
}
],
"Mac": "00:00:00:00:00:00",
"Sandbox": "/var/run/netns/cni-6070de8e-4e69-99c0-e619-63535af42ce5"
},
"veth335fa7aa": {
"IPConfigs": null,
"Mac": "de:30:14:fa:26:57",
"Sandbox": ""
}
}
Из этого вывода или с помощью команды:
crictl inspectp aae43202632ad | jq -r '.info.runtimeSpec.linux.namespaces'
вы сможете обнаружить имя изолированного сетевого немспейса (это уже совсем-совсем другой немспейс)
...
{
"type": "network",
"path": "/var/run/netns/cni-6070de8e-4e69-99c0-e619-63535af42ce5"
}
...
Вбиваем
ip netns exec cni-6070de8e-4e69-99c0-e619-63535af42ce5 ip a show type veth
и получаем параметры сети в испектируемом поде.
Возвращаемся к crictl.
crictl stats -a вернет нам табличку с потребляемыми ресурсами (cpu, disk, mem, inodes), а флаг -o json вернет нам все еще и в json виде, на случай если вы вдруг что-то мониторите.
К слову, crictl imagefsinfo вернет вам что-то вроде:
{
"status": {
"timestamp": "1626124762748935841",
"fsId": {
"mountpoint": "/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs"
},
"usedBytes": {
"value": "1969491968"
},
"inodesUsed": {
"value": "77458"
}
}
}
Еще мы можем, например, посмотреть на процесс внутри контейнера:
root@kube03a:~# cat "/proc/$(crictl inspect 2d538b1bdc00a | jq -r '.info.pid')/cmdline"
...вернет:
nginx: master process nginx -g daemon off;
А в корневой каталог попасть через /proc/$PID/root/
root@kube03a:~# cat "/proc/$(crictl inspect 2d538b1bdc00a | jq -r '.info.pid')/root/etc/hostname"
nginx-7848d4b86f-xztfp
Мы видим что все, что было в inpect в списке для монтирования, на этом этапе уже на своем месте.
Можем еще получить, например, id контейнера:
сrictl inspect 2d538b1bdc00a | jq -r '.status.id'
2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644
Через этот id мы можем найти каталог с его конфигами:
root@kube03a:~# ls /var/run/containerd/io.containerd.runtime.v1.linux/k8s.io/$(crictl inspect 2d538b1bdc00a | jq -r '.status.id')
address config.json init.pid log.json rootfs shim.pid
init.pid содержит уже известный нам pid процесса в контейнере, а shim.pid - pid родительского containerd-shim. В каталоге rootfs содержится собранный из снапшотов (слоев) overlayfs запущенного контейнера, но без дополнительных монтирований.
Если посмотреть на cgroups, то тут есть два варианта, в зависимости от выбранного драйвера cgroups. Если выбран драйвер systemd, то путь в cgroups_v1 будет примерно следующий:
root@kube03a:~# cat /sys/fs/cgroup/pids/system.slice/containerd.service/kubepods-besteffort-pod$(crictl inspectp aae43202632ad | jq -r '.status.metadata.uid' | sed 's/-/_/g').slice:cri-containerd:$(crictl inspect 2d538b1bdc00a | jq -r '.status.id')/cgroup.procs
28627
28664
28665
по человечески:
cat /sys/fs/cgroup/pids/system.slice/containerd.service/kubepods-besteffort-podc7205bb2_8c97_4f79_b4c9_915e402cc7d3.slice:cri-containerd:2d538b1bdc00a5f6251c9f47babca6163794a065133bcd2a0a0264a37a533644/cgroup.procs
crictl inspectp aae43202632ad | jq -r '.status.metadata.uid' - вернет нам uid пода, а crictl inspect 2d538b1bdc00a | jq -r '.status.id' - уже известный нам id контейнера. По аналогии можно обратиться к другим cgroups директориям.
Если же у вас драйвером выбран cgroups:
cat /sys/fs/cgroup/pids/kubepods/pod7d5e31f8-8797-457d-aaf2-f55464d338c6/eb2c3ad61742de7ed7a8758cc563a1470b969632f857429787668e1f354e357a/cgroup.procs
В реалтайме вы можете посмотреть cgroups через systemd-cgtop -m. Тут ведь все любят systemd, так?
Дошли наконец-таки до ctr
Для начала можно посмотреть доступные встроенные плагины.
ctr plugins ls - здесь можно посмотреть доступные снапшоттеры, которые составляют из слоев докер-образа конечный образ. Есть поддержа ZFS и BTRFS.
Далее смотрим доступные немспейсы containerd:
ctr namespaces ls
По умолчанию доступен немспейс "k8s.io". В дальнейших командах необходимо его явно указать: ctr --namespace=k8s.io containers ls
Так же можно посмотреть images (образы), events (отлов событий), content (бинарные данные из образов), snapshots (слои из образов), leases (аренда каких-либо ресурсов, подробней ), tasks (запущенные в контейнерах процессы).
Из необычного, вы можете взаимодействовать напрямую с shim или установить бинари и библиотеки из образа через crt install (это, видимо, для особо прогрессивных).
Напоследок ссылка на описание запуска контейнера через crictl для дебага.
Источник статьи: https://habr.com/ru/post/568274/