Недавно я столкнулся с необычным поведением, пытаясь решить необычную проблему.
У меня был модуль, запускающий контейнер, который должен был быть привилегированным. Кроме того, у меня был другой двоичный файл, запущенный в контейнере коляски, который при изменении файла отправляет SIGHUP процессу, выполняющемуся в привилегированном контейнере. Контейнер коляски не был привилегирован, но имел возможность SYS_PTRACE.
ПРИМЕЧАНИЕ: модуль имел shareProcessNamespace: true в своей спецификации (https://v1 -13.docs.kubernetes.io / docs / tasks / configure-pod-container / share-process-namespace / )
Заметив, что что-то работает не так, как ожидалось (процесс в главном контейнере, похоже, не получил SIGHUP, когда должен), я вошел в контейнер с коляской и попытался вручную отправить SIGHUP процессу в основной контейнер, используя kill -1 <pid>. Я получил «отказано в разрешении».
Примерно через 6 часов отладки я наконец понял, что это происходит, потому что главный контейнер привилегирован, а контейнер с коляской - нет. Установка privileged: true на контейнере коляски решила проблему, но у меня все еще остаются вопросы:
Просмотр ls /proc/<pid> привилегированного контейнера показал те же разрешения, что и для непривилегированного контейнера, так почему же проблема «отказано в разрешении»?
Даже когда контейнер с коляской не был привилегирован, у него не было проблем с отправкой SIGHUP в основной контейнер , когда я запускал его в мини-кубе . Зачем? Это как-то связано с операционной системой хоста или используемой средой выполнения контейнера?
Есть ли другой способ, кроме настройки контейнера-коляски, чтобы он также имел право посылать сигналы из непривилегированного контейнера в привилегированный контейнер?