проблемы с diskpressure и владением файлами в containerd - PullRequest
Новая
       12

проблемы с diskpressure и владением файлами в containerd

0 голосов
/ 25 декабря 2018

Я не смог найти информацию о 3 проблемах, с которыми я столкнулся в контейнере.Надеюсь на более глубокое понимание операций в контейнерах.

Приходится продолжать перестраивать мою среду kubernetes из-за проблем (на первый взгляд), связанных с контейнерами, в основном из-за дискового давления.Такое ощущение, что исполняемые файлы-контейнеры и связанные с ними владельцы сокетов играют свою роль.Справочник /var/lib/containerd/io.containerd.content.v1.content пополняется со временем.Я заканчиваю тем, что удаляю снимки, капли и т. Д. Из этого места.Иногда это помогает мне двигаться вперед, но часто стручки заканчиваются в состоянии «Выселены» или «Инициированы» на неопределенный срокМне не хватает критических знаний о kubernetes GC, необходимых владениях контейнерных файлов.

Немного информации из среды виртуальных машин на голом железе: 

$ uname -a
Linux node1.home 4.4.0-131-generic #157-Ubuntu SMP Thu Jul 12 15:51:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ free -m
              total        used        free      shared  buff/cache   available
Mem:           3951         772        1649          40        1529        2899
Swap:           974           0         974
$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.5G     0  1.5G   0% /dev
tmpfs           301M   32M  270M  11% /run
/dev/sda1        14G  4.8G  8.3G  37% /
tmpfs           1.5G     0  1.5G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           1.5G     0  1.5G   0% /sys/fs/cgroup
tmpfs           301M     0  301M   0% /run/user/1000
shm              64M     0   64M   0% /run/containerd/io.containerd.grpc.v1.cri/sandboxes/7a8ff8ecad13bd7b8bc6547dcfb330e53b073029cfb46ee4e5169a3da721f234/shm
overlay          14G  4.8G  8.3G  37% /run/containerd/io.containerd.runtime.v1.linux/k8s.io/7a8ff8ecad13bd7b8bc6547dcfb330e53b073029cfb46ee4e5169a3da721f234/rootfs
overlay          14G  4.8G  8.3G  37% /run/containerd/io.containerd.runtime.v1.linux/k8s.io/8a84f4e50b272d39785f575003c53c013363d2428f4e177c244ebbbddc6a266e/rootfs
shm              64M     0   64M   0% /run/containerd/io.containerd.grpc.v1.cri/sandboxes/9a86d1816db9679b3927bde048d4054e6d8780084fe406576622c48d814e4128/shm
overlay          14G  4.8G  8.3G  37% /run/containerd/io.containerd.runtime.v1.linux/k8s.io/9a86d1816db9679b3927bde048d4054e6d8780084fe406576622c48d814e4128/rootfs

контейнерный исполняемый файл и владения сокетами выглядят так: 

$ ls -l /usr/local/bin/
total 384020
-rwxr-xr-x 1 2000 2000  38133944 Apr 24  2018 containerd
-rwxr-xr-x 1 2000 2000   3539296 Apr 24  2018 containerd-release
-rwxr-xr-x 1 2000 2000   4185920 Apr 24  2018 containerd-shim
-rwxr-xr-x 1 2000 2000  17395032 Apr 24  2018 containerd-stress
-rwxr-xr-x 1 node node  28466436 Jul 13 12:09 crictl
-rwxr-xr-x 1 2000 2000  20919672 Apr 24  2018 ctr
-rwxrwxr-x 1 node node  55400930 Jul 18 03:13 kubectl
-rwxrwxr-x 1 node node 163031056 Jul 18 03:13 kubelet
-rwxrwxr-x 1 node node  52059570 Jul 18 03:13 kube-proxy
-rwxrwxr-x 1 node node  10087904 Nov 21 10:37 runc

$ sudo ls -l /var/run/containerd
total 0
srw-rw---- 1 root root  0 Dec 23 14:56 containerd.sock
drwxr-xr-x 4 root root 80 Dec 23 15:11 io.containerd.grpc.v1.cri
drwx--x--x 3 root root 60 Dec 23 15:09 io.containerd.runtime.v1.linux
drwx------ 3 root root 60 Dec 23 15:09 runc

Вопрос 1: Я сменил владельца, например, как показано ниже, чтобы иметь возможность извлекать изображения.Каков наилучший способ владения файлами в этом каталоге? 

$ sudo chown $(whoami):$(whoami) /var/run/containerd/containerd.sock
$ sudo chown -R $(whoami):$(whoami) /var/run/containerd/io.containerd.grpc.v1.cri
$ sudo chown -R $(whoami):$(whoami) /var/run/containerd/io.containerd.runtime.v1.linux
$ sudo chown -R $(whoami):$(whoami) /var/run/containerd/runc

Вопрос 2. Со временем kubelet не может принимать модули из-за дискового давления.

Failed to admit pod weave-net-94zht_kube-system(45c32573-0848-11e9-a03e-0800277b3732) - node has conditions: [DiskPressure]

В результате я удаляю самые большие из /var/lib/containerd/io.containerd.content.v1.content.Я уверен, что это не правильный подход.Как я могу убедиться, что containerd удаляет изображения при удалении связанных модулей? 

root@node1:/var/lib/containerd# du -H . | sort -nr | head
7998792 .
5924044 ./io.containerd.content.v1.content
5225584 ./io.containerd.content.v1.content/ingest
3619228 ./io.containerd.content.v1.content/ingest/bb03e51f0e1aef32213993dbc9658a8e69d30a74c8528816bd2d1842ee247c7c
2072468 ./io.containerd.snapshotter.v1.overlayfs
2072292 ./io.containerd.snapshotter.v1.overlayfs/snapshots
698456  ./io.containerd.content.v1.content/blobs
698452  ./io.containerd.content.v1.content/blobs/sha256
600768  ./io.containerd.content.v1.content/ingest/f8a0f55edab797342b0ddbdc5b82409eb54c3451f7bc3b9fe7dbbd656ffdf8ae
354008  ./io.containerd.snapshotter.v1.overlayfs/snapshots/89

Вопрос3: Когда я запускаю докер-контейнер, я получаю этот вывод при попытке docker image ls.Владельцы файлов будут играть роль здесь?Обратите внимание, containerd - это среда выполнения на хост-компьютере. 

$ kubectl exec -it dock -c docker -- sh
/workspace # docker container ls
Get http://%2Fvar%2Frun%2Fdocker.sock/v1.37/containers/json: net/http: HTTP/1.x transport connection broken: malformed HTTP response "\x00\x00\x00\x04\x00\x00\x00\x00\x00".
* Are you trying to connect to a TLS-enabled daemon without TLS?

Думаю, у меня есть права на mountpaths 

...
    - name: docker-socket
      mountPath: /var/run/docker.sock
...
  volumes:
  - name: docker-socket
    hostPath:
      path: /var/run/containerd/containerd.sock
      type: Socket
...
...