Интересно, сколько места занимает Docker в вашей системе Linux?

В основном, все образы Docker, контейнеры и другие связанные с ними сущности находятся в каталоге /var/lib/docker.

Вы можете проверить размер этого каталога и получить общее дисковое пространство, используемое Docker:

$ sudo du -sh /var/lib/docker
4.9G	/var/lib/docker

Но это не очень подробно, и вам, возможно, придется углубиться в этот каталог, чтобы увидеть, какой компонент использует какое пространство.

К счастью, Docker предоставил инструменты для получения этой информации в более полезном виде.

Проверка использования дискового пространства Docker

Самый простой, “докеровский” способ узнать, сколько места занимают образы, контейнеры, локальные тома или кэш сборки:

docker system df

При выполнении этой команды (при необходимости используйте sudo) вы получите всю информацию об использовании диска, сгруппированную по компонентам Docker.

$ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          4         4         1.065GB   0B (0%)
Containers      4         4         5.705kB   0B (0%)
Local Volumes   7         7         1.108GB   0B (0%)
Build Cache     0         0         0B        0B

Это определенно лучше, чем смотреть на общий размер /var/lib/docker.

Вы можете увидеть, сколько места занимают образы, контейнеры и тома.

Однако это все еще не дает четкого представления о том, какой образ или том занимает больше места.

На самом деле, это так.

Команда df системы docker имеет опцию verbose -v, которая предоставляет все эти детали.

docker system df -v

Вот подробный вывод:

$ docker system df -v
Images space usage:

REPOSITORY                               TAG       IMAGE ID       CREATED         SIZE      SHARED SIZE   UNIQUE SIZE   CONTAINERS
ghost                                    4.32.0    b40265427368   8 weeks ago     468.8MB   0B            468.8MB       1
jrcs/letsencrypt-nginx-proxy-companion   latest    037cc4751b5a   13 months ago   24.35MB   0B            24.35MB       1
jwilder/nginx-proxy                      latest    509ff2fb81dd   15 months ago   165MB     0B            165MB         1
mariadb                                  10.5.3    f5d2bcaf057b   20 months ago   407MB     0B            407MB         1

Containers space usage:

CONTAINER ID   IMAGE                                    COMMAND                  LOCAL VOLUMES   SIZE      CREATED        STATUS        NAMES
899cc90e85d9   ghost:4.32.0                             "docker-entrypoint.s…"   1               0B        8 weeks ago    Up 8 weeks    ghost_ghost_6
17b58fdafbce   jrcs/letsencrypt-nginx-proxy-companion   "/bin/bash /app/entr…"   4               571B      3 months ago   Up 2 months   letsencrypt-proxy-companion
58f99f46ee03   jwilder/nginx-proxy                      "/app/docker-entrypo…"   5               5.13kB    3 months ago   Up 2 months   jwilder-nginx-proxy
fb907286b60e   mariadb:10.5.3                           "docker-entrypoint.s…"   1               2B        3 months ago   Up 2 months   ghost_db_1

Local Volumes space usage:

VOLUME NAME                      LINKS     SIZE
ghostdb                          1         434.7MB
jwilder-nginx-with-ssl_acme      2         36.09kB
jwilder-nginx-with-ssl_certs     2         25.12kB
jwilder-nginx-with-ssl_dhparam   1         1.525kB
jwilder-nginx-with-ssl_html      2         1.106kB
jwilder-nginx-with-ssl_vhost     2         556B
ghost                            1         674MB

Build cache usage: 0B

CACHE ID   CACHE TYPE   SIZE      CREATED   LAST USED   USAGE     SHARED

Проверка размеров образов docker

Если вы просто хотите посмотреть образы Docker и их размеры, вы также можете использовать эту команду:

docker ps --size

Вы должны увидеть столбец SIZE, добавленный к выводу команды:

$ docker ps --size
CONTAINER ID   IMAGE     COMMAND      CREATED         STATUS         PORTS     NAMES           SIZE
1171dcfb7e06   alpine    "sleep 10"   10 months ago   Up 9 seconds             always-policy   0B (virtual 5.61MB)

Проверка размеров запущенных контейнеров

Аналогично, если вы хотите узнать размер запущенных контейнеров Docker, вы можете использовать команду docker ps:

docker ps --size

Вы должны увидеть столбец SIZE, добавленный к выводу команды:

$ docker ps --size
CONTAINER ID   IMAGE     COMMAND      CREATED         STATUS         PORTS     NAMES           SIZE
1171dcfb7e06   alpine    "sleep 10"   10 months ago   Up 9 seconds             always-policy   0B (virtual 5.61MB)

Вы заметили, как вывод говорит 0B, а затем показывает виртуальный размер 5,61 МБ?

Виртуальный размер включает общий базовый образ.

Давайте вернемся к подходу к Linux более конкретно, на примере образа и контейнера Alpine в качестве практического примера.

Использование стандартных команд Linux для анализа использования дискового пространства Docker

Всякий раз, когда вы используете команду docker pull или запускаете команду docker-compose up -d для подготовки запуска приложений, вот как вы смотрите на использование пространства образа, фактически хранящегося на сервере Ubuntu 20.04:

sudo du -sh /var/lib/docker/overlay2/<hash-named-directory>/

Здесь Overlay2 является драйвером хранилища Docker по умолчанию в Ubuntu.

Вы можете подтвердить это, выполнив команду docker info и поискав Storage Driver:

Storage Driver: overlay2

Если оно отличается от вашего, значит, вы используете другой драйвер хранения для Docker.

Аналогично, расположение каталога будет названо в соответствии с тем же драйвером хранения.

Доступность драйвера хранилища зависит от поддержки ядра.

Использование диска конкретного образа

Если вы ищете местоположение конкретных образов, вы можете использовать команду inspect в Docker для извлеченного образа.

Например, я извлек образ alpine с помощью команды docker pull alpine.

Выполните следующую команду для его проверки:

$ docker inspect alpine

После выполнения команды вы заметите три поля в подразделе Data в разделе GraphDriver:

...
        "GraphDriver": {
            "Data": {
                "MergedDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/merged",
                "UpperDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
                "WorkDir": "/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/work"
            },

...

Исходя из вышеприведенной информации, вы можете видеть, что (упомянутый ранее в синтаксисе команды du) в данном случае равен 64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a525ab9e365e.

Здесь вы можете выполнить следующую команду, чтобы узнать объем пространства, используемого изображением Alpine:

$ sudo du -sh /var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e
6.0M	/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e

Подобно образам, контейнеры также хранятся в одном каталоге на базе драйвера хранилища.

/var/lib/docker/overlay2

Использование диска конкретным контейнером

Если вы ищете местоположение конкретных контейнеров, вы можете снова использовать команду inspect в Docker для запущенного контейнера.

Например, я запустил контейнер alpine с помощью команды docker run -ti -d alpine.

Запустив команду docker ps, вы увидите, что он запущен:

$ docker ps
CONTAINER ID   IMAGE     COMMAND     CREATED         STATUS         PORTS     NAMES
cb341d6a28fa   alpine    "/bin/sh"   6 seconds ago   Up 5 seconds             confident_banzai

Здесь контейнер был произвольно назван confident_banzai.

Давайте проверим его:

$ docker inspect confident_banzai

После выполнения вышеуказанной команды вы заметите все четыре поля, упомянутые ранее в подразделе Data в разделе GraphDriver.

В этих местах данные контейнера физически хранятся на хост-системе, как и в случае с образами:

...
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3-init/diff:/var/lib/docker/overlay2/64c9c0cf8c9cfb0e2168071df0652a317d49f58a68fe86e4a9a9a525ab9e365e/diff",
                "MergedDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/merged",
                "UpperDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/diff",
                "WorkDir": "/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3/work"
            },
            "Name": "overlay2"
        },
...

Теперь вы можете снова использовать команду du:

$ sudo du -sh /var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3
32K	/var/lib/docker/overlay2/d734685e284c92bdcb6063ac292a48813f30f4b0b2dd6fa2882279c569e506a3

Использование диска конкретного тома

В данном случае существует два типа томов.

Первый – это обычные тома Docker, а второй – bind mounts.

Тома Docker

Если вы ищете местоположение определенных томов, вы можете сначала использовать команду docker volume ls и проверить имя или ID тома.

Скажем, например, я запустил контейнер alpine следующей командой с томом:

docker run -ti -d --name alpine-container -v test-data:/var/lib/app/content alpine

Теперь автоматически будет создан том с именем test-data.

Теперь давайте создадим файл test.md в этом месте:

$ docker exec alpine-container sh -c "touch /var/lib/app/content/test.md"

Убедитесь, что файл действительно был создан:

$ docker exec -ti alpine-container sh
/ # ls /var/lib/app/content/
test.md
/ # exit

Когда вы запустите docker volume ls, в списке появится том с именем test-data:

$ docker volume ls
DRIVER    VOLUME NAME
local     d502589845f7ae7775474bc01d8295d9492a6c26db2ee2c941c27f3cac4449d1
local     e71ee3960cfef0a133d323d146a1382f3e25856480a727c037b5c81b5022cb1b
local     test-data

Наконец, вы можете подтвердить фактическое расположение файла на вашей хост-системе:

$ sudo ls -l /var/lib/docker/volumes/test-data/_data
total 0
-rw-r--r-- 1 root root 0 Oct  6 23:20 test.md

Поэтому путь для смонтированного тома всегда находится в каталоге с именем _data внутри соответствующего каталога тома.

Таким образом, вы можете использовать команду du здесь снова для определенных томов!

$ sudo du -sh /var/lib/docker/volumes/test-data/_data
4.0K	/var/lib/docker/volumes/test-data/_data

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

Bind Mounts

Это единственное исключение в Docker, где необходимо использовать подход Linux для мониторинга использования дискового пространства.

В то же время, всегда предпочтительнее сначала остановить работающие контейнеры.

$ mkdir /home/avimanyu/test-data
$ docker run -ti -d --name alpine-container -v /home/avimanyu/test-data:/var/lib/app/content alpine

В этом случае смонтированный том с именем test-data станет доступен на стороне контейнера как /var/lib/app/content.

$ sudo du -sh /home/avimanyu/test-data
4.0K	/home/avimanyu/test-data

То же самое можно проверить и внутри контейнера:

$ sudo docker exec -ti alpine-container sh
/ # du -sh /var/lib/app/content
4.0K	/var/lib/app/content

Как вы можете видеть, оба указанных выше размера одинаковы!

Логи Docker на хосте всегда хранятся в томах.

Используя описанный в этом разделе способ, пользователи также могут сориентироваться и выяснить это, посмотрев на использование дискового пространства томов docker.

Это зависит от приложения и расположения файлов логов в томах приложения.

Бонусные советы

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

sudo du -sh /var/lib/docker/overlay2

Логи Docker на хосте всегда хранятся в томах.

Обычно большой объем Docker, скорее всего, указывает на то, что логи накапливаются и управляются неэффективно.

Используя способ, описанный в разделе “Тома” этой статьи, пользователи также могут сориентироваться и смягчить ситуацию, посмотрев на использование дискового пространства в томах docker.

Это зависит от приложения и расположения файлов журналов в томах приложения.

Резюме

В этом руководстве я использовал общий подход, основанный на Linux, чтобы показать вам, как узнать занятость дискового пространства образов Docker, контейнеров и томов, расположенных на вашем Linux-сервере на уровне хоста.

Вы также узнали, как сделать это предпочтительным (Docker) способом.

Если вы хотите поделиться отзывами, комментариями или предложениями по поводу этого подхода, пожалуйста, оставьте свои мысли в разделе комментариев ниже

Источник: https://itisgood.ru/2022/02/24/kak-proverit-ispolzovanie-diskovogo-prostranstva-obrazov-kontejnerov-i-tomov-docker/

В этом коротком руководстве мы рассмотрим, как удалить удаленные или завершенные поды в кластере Kubernetes.Есть много причин, по которым вы можете обнаружить, что некоторые поды находятся в состоянии Evicted и Terminated.В случае eviction это часто происходит в результате нехватки ресурсов на рабочих нодах или ошибки приложения.Terminated может быть результатом уменьшения масштаба приложения или развертывания новой версии приложения, после которой прекращается работа старых подов.Служба kubelet, которая работает на каждом узле кластера, отвечает за состояние eviction подов.Вы можете получить список подов в пространстве имен, застрявших в состоянии Evicted и Terminated, выполнив следующую команду:

kubectl get pods -n namespace | egrep -i 'Terminated|Evicted'

Как удалить поды в Kubernetes

Вы можете удалить эти поды разными способами.

Использование собственных команд kubectl и Bash

Это команды bash с фильтрацией, которые вы можете запустить для принудительного удаления подов в пространстве имен, которые застряли в завершенном состоянии.

# Определение неймспейса
namespace="mynamespace"

# Получаем поды
epods=$(kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted' | awk '{print $1 }')

# Удаляем их
for i in ${epods[@]}; do
  kubectl delete pod --force=true --wait=false --grace-period=0 $i -n ${namespace}
done

Подтвердите, есть ли еще контейнеры в этом состоянии.

kubectl get pods -n ${namespace} | egrep -i 'Terminated|Evicted'

Удаление всех исключенных и завершенных модулей из всех пространств имен:

kubectl get pods --all-namespaces | egrep -i  'Evicted|Terminated' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod --force=true --wait=false --grace-period=0

Удалите все контейнеры в состоянии ImagePullBackOff из всех пространств имен – Бонус:

kubectl get pods --all-namespaces | grep -E 'ImagePullBackOff|ErrImagePull|Evicted' | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod

Использование фильтров kubectl и jq

Вы также можете отфильтровать вывод команды kubectl и перенаправить в jq для получения определенных столбцов.

Сначала установите команду jq:

--- Ubuntu / Debian ---
$ sudo apt update && sudo apt install jq

--- CentOS/Fedora ---
$ sudo yum -y install epel-release
$ sudo yum -y install jq

--- RHEL ---
wget https://github.com/stedolan/jq/releases/download/jq-1.6/jq-linux64 -O jq
chmod +x jq
sudo mv jq /usr/local/bin

Затем удалите застрявшие поды с помощью команды:

kubectl get pods --all-namespaces -o json | jq '.items[] | select(.status.reason!=null) | select(.status.reason | contains("Evicted")) | "kubectl delete pods (.metadata.name) -n (.metadata.namespace)"' | xargs -n 1 bash -c

Оставайтесь на связи, чтобы прочитать еще больще интересных руководств по контейнерам.