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

Знаменитый мем «Миграция контейнеров в облако»

Что вообще можно сделать для управления ресурсами

По умолчанию в k8s поды(контейнеры) могут потреблять столько ресурсов, сколько хотят (из физически доступных на ноде). Но можно активировать механизмы k8s, управляющие этим.

k8s здесь может действовать в двух ролях :

• во время работы системы k8s может следить за контейнерами (подами) и карать те, что потребляют ресурсов больше чем обещали максимально потреблять

• на запуске пода (контейнера) k8s может решать, запускать ли объект (и где именно его запускать), исходя из того сколько ресурсов он требует для работы в норме и сколько обещает потреблять в максимальном случае

Что для надо для управления ресурсами

• В правилах системы управления должны быть описаны принципы (политики), по которым системе эти требования и обещания контейнера проверяются на то, подходят они или нет k8s

• свойствах контейнера (пода) должны быть прописаны его потребности при работе в норме (requests), они же минимальные требования для старта. Также в свойствах контейнера (пода) должны быть прописаны его максимально допустимые аппетиты (limits): сколько он обещает пожирать в самом-самом плохом случае. Если контейнер не сообщает свои требования и обещания, но они нужны для работы политик — они будут назначены этими политиками принудительно сверху (сам виноват).

Не даем запущенному пожрать сверх договорённостей

Этот функционал реализуется на основе мониторинга процессов. Здесь необходимы значения максимально допустимых аппетитов (limits) объекта — они должны быть описаны в свойствах, либо должны быть заданы принудительно политиками Limit Ranges (про них чуть дальше).

Если контейнер (под) пережирает сверх обещанного, k8s может тротлить процессор (при нарушении лимитов CPU) или останавливать\перезапускать под, если идет перебор по памяти. Таким образом, гарантируется что контейнер будет во время работы есть от 0 до limits ресурсов процессора и памяти.

Не запускаем объекты, если нам это не подходит

Второй механизм управления работает в момент запуска объекта. В каждом namespace может быть использованы две политики, и при запуске пода(контейнера) будут проверяться его запросы (минимальные и максимальные), а также состояние системы после его запуска, на соответствие этим политикам. Если принято решение что в результате политика(и) не будет нарушена — старт разрешен. Далее соответствие политике не контролируется.

Политика Limit Range. Задает в namespace ограничения на запросы и лимиты подов(контейнеров). Если pod (контейнер) просит (requests) меньше, чем нижний лимит (min limits) политики, или обещает максимальное потребление (limits) больше, чем верхний лимит (max limits) политики — он запущен не будет. Здесь может возникнуть путаница из-за несогласованного использования термина limits, важно не запутаться.

Нюансы:

• Если под не сообщает свой лимит или запрос, они задаются принудительно значениями из политики по умолчанию (default [это шаблон для limits] и DefaultRequest [это шаблонное значение для requests]) — и в дальнейшем эти значения могут влиять на ограничения при работе pod, описанные ранее (с ними будет сравниваться его реальное потребление).

• Limit Range может быть задан для подов или контейнеров. В случае, если Limit Range задан на контейнеры, и хотя бы один контейнер в поде не подходит под значения политики, не стартанёт весь pod.

иллюстрация Limit Range от НИИ Быстрых Иллюстраций

• В отличие от мониторинга уже запущенных контейнеров, здесь принимается решение в том числе на базе минимально запрошенных требований (requests). Это дает k8s возможность распределять ресурсы равномерней а также не запускать объекты, которые уже точно не влазят в мощности инфраструктуры. Следует стараться задавать эти значения, чтобы не оказаться в ситуации когда контейнер запущен в среде с нехваткой ресурсов (не сказал сколько надо — получи минимальный минимум)

Политика Resource Quotas. Задает в namespace максимальный предел ресурсов, которые могут быть запрошены суммарно всеми подами или контейнерами этого namespace, на основании указанных в конфигурации подов(контейнеров) данных (важно, не фактически потребляемых, а именно запрашиваемых в манифесте). Политика не дает зарезервировать больше ресурсов или создать больше сущностей, чем админ готов потратить на все объекты namespace. Нюансы:

• для cpu и ram политика может задавать верхний предел для любых значений — и requests (что фактически значит «не позволить назапускать объектов которые захотят жрать все вместе как мимимум столько то»), и limits (что фактически значит «не позволить назапускать объектов, которые все вместе при фиговом раскладе в максимуме сожрут столько то»).

• также здесь могут быть заданы ограничения для суммарного количества других сущностей в namespace (секреты итп).

Ссылочки

Материалы по теме:
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
https://kubernetes.io/docs/concepts/policy/

Канал DataLine в телеге (где бывают в том числе анонсы их учебных программ) — https://t.me/unidataline

Мне давно не хватало возможности печатать на принтер в кабинете напрямую с телефона и ноута, подключенных в публичный вайфай. Сам принтер сетевой и подключен к локалке, и доступа к нему из беспроводной сети нет. Я пробовал использовать виртуальный принтер Google, но именно с этой железякой он не заработал.

Пару месяцев назад я купил по дешевке на авито пачку б/у Raspberry Pi самой первой модели. Из двух я сделал оверкилльные датчики температуры для контроля работы кондиционеров в серверных помещениях. Оверкильность здесь в том, что целый микрокомпьютер, на порядки более производительный и функциональный, чем некоторые из моих бывших домашних компов, крутит внутри себя актуальную версию крутейшей ОС, только для того чтобы раз в минуту измерять температуру одного чипа и пересылать её по сети. Жестокие, расточительные времена! Ну да ладно.

Третий одноплатник лежал без дела, пока мне не пришлось в очередной раз пересылать почтой документ для распечатывания. Тут и родилась идея сделать из него беспроводной принт-сервер. Первая версия распбери не содержала встроенного вайфай адаптера, и за 2 недели и 232 р из Китая был привезён адаптер на чипе Ralink RT5370 (в интернетах рекомендуется для Raspbian). Далее по первой попавшейся статьи из гугла на железяку за пару часов был установлен CUPS, ну и в итоге всё завелось просто и быстро. Принтер печатает со всех девайсов, и по ethernet и по вайфаю.

Главная, какая-то бытовая магия и особый для меня кайф — смотреть как работает автообнаружение и настройка печати в получившийся принтер на устройствах iOS. Не устаю восхищаться тем, как техника может работать вот так сама по себе, без ручного конфигурирования и прыжков с бубном.

Есть чудесный, удобный, привычный, бесплатный инструмент — программа для просмотра и редактирования изображений FastStone Image Viewer. Оный продукт умеет запоминать базу превьюшек и позволяет дичайше удобно быстро и турбореактивно ходить по хранилищу фоток. Но превьюшки фасстон создает (и пересоздает) при открытии папки, а значит при массовом обновлении коллекции фоток (или например при переустановке системы) придется потерпеть при открытии каждой новой папки. А кнопки «посмотреть всю иерархию папок и построить превью» у него нет, и автоматом, в отличие от почившей Пикасы например, оно это делать не умеет.

В дополнение к вышесказанному есть ленивый программист и павершел.

За 15 минут на коленке, из говна и палок слеплен скрипт, ползающий по файловой системе и запускающий FastStone на просмотр всех папок по очереди — ну а превьюхи при таком раскладе оно уже построит само.
Криво, ресурсоёмко, неоптимально, работает. Приводить код не буду, он тривиален.

С новым годом, человеки!
/ иллюстрация к этому посту лениво найдена в гугле /

Оказалось, при наличии у компа ключа Windows 7, этим ключом можно активировать и 32-разрядную, и 64-разрядную версию винды.

Сегодня допихнул в свой леново +6 гигов оперативки, поставил официальную винду с MSDN 64 разрядную вместо штатной, активировал ключом с брюха бука — полет нормальный. А я уж хотел кряки в интернетах гуглить.