Как видно, requests игнорируются на этапе перехода к низкоуровневой спецификации — для них нет соответствующих сущностей ядра.
В прошлом разделе показано, что у requests нет пары в ядре Linux. Это не требуется, так как requests только сообщают планировщику о потребности контейнера (и управляющего им пода) в ресурсах.
Это не так. В cgroup контейнера есть параметр, который зависит от его requests.cpu – cpu.weight. Этот параметр отвечает за общий "вес" процессов в контейнере, который включается в игру, когда на ноде близкое к 100% потребление CPU, и планировщику linux нужно определить какому контейнеру (процессу в контейнере) сколько процессорного времени должно доставаться.
Наличие этого параметра так же означает, что даже при отсутствии лимитов на CPU у подов на ноде, в случае появления шумного соседа, забирающего себе всё CPU ноды, другие контейнеры, требующие в это время CPU, как минимум не будут получать его меньше, чем прописано в их requests.cpu. По крайней мере так должно быть и у меня в своё время не получилось добиться ситуации, в которой контейнер при "борьбе за cpu" получал бы его меньше, чем прописано в его реквестах :).
Вот тут можно почитать про это, но советую после статьи самому на тестовом кластере поэкспериментировать.
route_localnet=1 разрешает маршрутизацию пакетов, адресованных loopback интерфейсу (127.0.0.0/8). Например, в статье это используется для того, чтобы была возможность перенаправлять пакеты с 127.0.0.1:8000 на 10.100.0.2:8000.
iptables -t nat -A OUTPUT -p tcp -m addrtype --dst-type LOCAL -m tcp --dport 8000 -j DNAT --to-destination 10.100.0.2:8000
По поводу запрета стучаться одним контейнерам в другие. Во-первых, нужно убедиться, что они находятся в разных docker сетях. Во-вторых, добавить правила в firewall, запрещающие получение пакетов на хосте с bridge интерфейса (или со всех адресов подсети этого интерфейса) нужной вам докер сети по портам 80-8080. Пример:
Ценность HashiCorp Vault в том, что он позволяет централизовано хранить секреты и удобно управлять доступом к ним. И соответственно позволяет минимизировать появление таких ситуаций, когда секреты лежат в plain text'е, например, в каком-нибудь гит репозитории.
В случае с OTP ключами к ssh, Vault это не единственное решение, и не факт, что самое эффективное, но в случае если вы, к примеру, уже в инфраструктуре своего проекта храните секреты в кластере HashiCorp Vault (что сейчас совсем не редкость), то при необходимости внедрения системы одноразовых паролей для ваших машин, вам будет легче использовать Vault.
По поводу кражи токенов. Токен может утечь куда-нибудь, да. Для борьбы с такими ситуациями токену можно задать время жизни и кол-во использований. И в случае, если уже понятная утечка, то инвалидировать его.
В открытом виде генерацию OTP через API Vault лучше не отдавать сотрудникам на пользование. Лучше такое прятать за внутренний корпоративный сервис, где ты уже под своей корп учёткой запрашиваешь генерацию OTP к нужной машине. Соответственно access-token к vault'у хранится у сервиса.
Лично я предполагаю, что подобный генератор OTP для ssh будет полезен для автоматизации каких-либо работ на удалённых хостах, когда worker'у нужно один раз к чему-то подключиться, выполнить свои действия и потухнуть.
Это не так. В cgroup контейнера есть параметр, который зависит от его
requests.cpu–cpu.weight. Этот параметр отвечает за общий "вес" процессов в контейнере, который включается в игру, когда на ноде близкое к 100% потребление CPU, и планировщику linux нужно определить какому контейнеру (процессу в контейнере) сколько процессорного времени должно доставаться.Наличие этого параметра так же означает, что даже при отсутствии лимитов на CPU у подов на ноде, в случае появления шумного соседа, забирающего себе всё CPU ноды, другие контейнеры, требующие в это время CPU, как минимум не будут получать его меньше, чем прописано в их
requests.cpu. По крайней мере так должно быть и у меня в своё время не получилось добиться ситуации, в которой контейнер при "борьбе за cpu" получал бы его меньше, чем прописано в его реквестах :).Вот тут можно почитать про это, но советую после статьи самому на тестовом кластере поэкспериментировать.
route_localnet=1разрешает маршрутизацию пакетов, адресованных loopback интерфейсу (127.0.0.0/8). Например, в статье это используется для того, чтобы была возможность перенаправлять пакеты с 127.0.0.1:8000 на 10.100.0.2:8000.По поводу запрета стучаться одним контейнерам в другие. Во-первых, нужно убедиться, что они находятся в разных docker сетях. Во-вторых, добавить правила в firewall, запрещающие получение пакетов на хосте с
bridgeинтерфейса (или со всех адресов подсети этого интерфейса) нужной вам докер сети по портам 80-8080. Пример:UPD: так как контейнеры за NAT, достаточно указать адрес маршрутизатора, то-есть адрес их
bridgeинтерфейса. Обновлённый пример:Один из вариантов использования, описанный в статье, это сетевая изоляция процессов) Решать, кто может им отправлять пакеты, и кому они могут.
Ценность HashiCorp Vault в том, что он позволяет централизовано хранить секреты и удобно управлять доступом к ним. И соответственно позволяет минимизировать появление таких ситуаций, когда секреты лежат в plain text'е, например, в каком-нибудь гит репозитории.
В случае с OTP ключами к ssh, Vault это не единственное решение, и не факт, что самое эффективное, но в случае если вы, к примеру, уже в инфраструктуре своего проекта храните секреты в кластере HashiCorp Vault (что сейчас совсем не редкость), то при необходимости внедрения системы одноразовых паролей для ваших машин, вам будет легче использовать Vault.
По поводу кражи токенов. Токен может утечь куда-нибудь, да. Для борьбы с такими ситуациями токену можно задать время жизни и кол-во использований. И в случае, если уже понятная утечка, то инвалидировать его.
В открытом виде генерацию OTP через API Vault лучше не отдавать сотрудникам на пользование. Лучше такое прятать за внутренний корпоративный сервис, где ты уже под своей корп учёткой запрашиваешь генерацию OTP к нужной машине. Соответственно access-token к vault'у хранится у сервиса.
Лично я предполагаю, что подобный генератор OTP для ssh будет полезен для автоматизации каких-либо работ на удалённых хостах, когда worker'у нужно один раз к чему-то подключиться, выполнить свои действия и потухнуть.
С clap и anyhow это я уже смухлевал) Там по сути жизненно необходим только parking_lot был
Хотелось по минимуму пользоваться сторонними библиотеками, и больше использовать функционал, который Rust предоставляет из коробки)