На каникулах перенёс в блог архив своего ЖЖ и гуглоплюса

ЖЖ

ЖЖ я завёл (судя по записи «хэхэ, жэжэ») в 2009 году, и активно писал в него несколько лет. Журнал сохранился в неизменном виде до декабря 2020, когда я провёл перенос его в этот блог. В журнале никогда не было особых обсуждений, да и сам я почти никогда ничего не комментировал в других журналах, так как чужие жж читал и читаю через RSS. Но как дневник, прото-иг и заметки использовал его плотно. К слову о комментариях — уже закончив перенос я вспомнил про те немногие комменты, что в моем жж были — и решил ими не заморачиваться. Такой вот чукча читатель и он же чукча-писатель без потребности в обратной связи.

Google+

Несколько лет в 2011-2014 я активно пользовался гуглоплюсом. Люблю тестить новые технологии, плюс идея с геолокацией оказать удивительно ёмкой на применение. Например, было интересно в новом месте посмотреть, кто постит что-то рядом (а вот на этом полустанке между Москвой и Киевом, есть пользователи гуглоплюса?). Ещё я нашел несколько интересных людей просто потому, что они постили из того же утреннего экспресса из Перди в Нерезиновую, что и я (и кстати, которых я благополучно потерял вместе с закрытием гуглоплюса). В московском метро на кольцевой клиент гуглоплюса меня постоянно определял как в Питере — это был забавный телепорт внутри сервиса.

Само закрытие гуглоплюса пару лет назад я как-то прощёлкал — знал о нём, но не придал значения. Когда мысль выдернуть оттуда посты меня всё же посетила — архивы сервиса уже были потёрты. Справедливости ради отмечу, что в процессе переноса (о котором ниже) я всё же столкнулся пару раз с тем что мои картинки по длинным урлам на серверах гугла ещё доступны, то есть удалили — но не всё.

В общем, в плане переноса мне повезло, что после перехода в гуглоплюс я настроил экспорт заметок из него в ЖЖ, поэтому тексты постов сохранились. А картинки, которые погибли вместе с G+, остались в бэкапах на домашнем хранилище (фотки со смартфонов я предусмотрительно синхронизировал на NAS уже в те года).

Таким образом, перед началом переноса у меня был выгруженный из жж архив, заполненный оригинальными записями вперемешку с полуистлевшими репостами из G+, а также архив оригинальных фотографий, павершелл и стойкое нежелание делать много ручной работы — в реальности, совсем без неё не обошлось, и в итоге я фактически открыл и в той или иной мере отредактировал каждый из постов, но основной объем работы по переносу, включая создание записей, правку форматирования, генерацию заголовков постов, выдерг тегов и местоположений, создание URL постов для эгеи, и кучу ещё всего сделали за меня роботы.

Процедура переноса.

Сначала я взял выгрузку актуальной базы из Эгеи и разобрался в её устройстве. Посмотрел как работает с базой Евгений Степанищев. В несколько итераций написал на павершелле парсер, который выдёргивает из поста жж данные — заголовок, тело, дату и теги (настроениями я не пользовался обычно), складывает и переименовывает картинки. Для импортированных из G+ постов сделал парсер отметок геолокации из тела поста. Ну и по мелочи множество всяких замен ссылок на формат эгеи, убирания форматирования и тому подобное. На выходе парсера были команды SQL, которые я копипастил большими кусками (набором постов за месяц сразу) в phpMyAdmin прямо на хостинге, и файлы картинок, которые я вгрузил пачкой по ftp.

В целом работа заняла почти все праздники. Я правил скрипт под менявшиеся несколько раз форматы постов, вгонял их в блог, открывал и редактировал где это было необходимо. Заодно я местами добавил фоток к постам или заменил фотки из жж на оригиналы из архива в бОльших разрешениях, местами добавил комментарии «из 2020», или поменял ссылки наружу на работающие. В целом данные переехали как есть примерно на 70-80%

Изменения в технологиях и головах

По ходу работы подметил много интересного:

• с одной стороны правильно говорят, что информацию из интернета удалить невозможно — разыскивая хоть какие-то дополнительные следы своей страницы в гуглоплюсе я находил репосты, сайты-индексаторы и каталоги, хоть и не нашел в итоге ничего удобоваримого (а в archive.org гуглоплюс не сохранился). С другой стороны, примерно половина ссылок из постов жж на внешние ресурсы, ролики с ютуба и тому подобное не открылись. Какие-то сайты и СМИ просто перестали существовать, какие-то поменяли структуру ресурса (например, мне удалось по не изменившемуся тексту найти новость на сайте мчс от 2012 года, на которую ссылался мой пост). В целом, здесь делаю вывод, что действительно важные вещи стоит либо цитировать в тексте поста полностью, либо выгружать и прикладывать к постам например в pdf (как я и сделал несколько раз в итоге). Что делать с ютубом и прочими большими медиа-штуками пока непонятно.
• технологии развиваются стремительно. В жж в начале 2010-х я часто встраивал в заметки плееры музыки и видео со сторонних сайтов — все эти фреймы и жабаскрипты уже не работают вообще, сервисы переделаны или уничтожены. Собственно, встройку ютуба удалось победить только выпарсив из кода начала десятилетия id роликов и сформировав актуальный линк вручную.
• при этом какие-то вещи остаются на удивление незыблемыми. Живы сайты, куда я 10 лет назад выгружал треки покатушек, живы вручную забитые маршруты на Яндекс картах и на гугле, живы картинки на хостингах, куда не заглядывал 7-8 лет, живы примерно половина роликов ютуба (и некоторые набрали за это время миллионы просмотров)
• я 10 лет назад был значительно резче, злей, радикальней, нетерпимей в мыслях и высказываниях. Удивительно насколько было мне тогда важно, что «в интернете кто-то неправ», или что какая-то технология крива или не работает. Мудрость это или равнодушие сейчас — не знаю. Какие-то тогдашние свои позиции я больше не разделяю, за какие-то высказывания сейчас стыдно, но я решил перенести все посты как есть.
• интересна повторяемость сюжетов и каких-то идей в мыслях, которые забывались и изобретались заново — встретил несколько таких, уже не помня эти их первые (?) инкарнации

Эта работа — часть большого проекта по забираче всего своего у корпораций и сбору персонального цифрового архива. Надеюсь, хватит сил продолжить её дальше, в планах ещё много всего, не переключайтесь!

Теги для импортированных постов:
посты из гуглоплюса
посты из жж

Давным-давно, на заре интернета (модемы, первые порталы, фтп с музыкой и скоростью в 10 мегабайт в час), мы ржали над шуткой

Вопрос в службу техподдержки.: «Я скачал файл из интернета, теперь он мне больше не нужен. Как его закачать обратно?»
Ответ: «Вот из-за таких уродов, как ты, в Интернете скоро совсем файлов не останется.»

Реальность как всегда превзошла все фантазии — прекрасные умные компьютерщики напридумывали сервисов и наделали смартфонов, и все от мала до велика стали жить, общаться и хранить данные в этих ваших интернетах. Теперь никто ничего не скачивает — все генерят контент, шерят, публикуют, лайкают и репостят, смотрят и слушают онлайн, и всё своё существо держат там. Мы резвимся как пятилетки на этой цифровой детской площадке, и не задумываемся, где лежит наше электронное настоящее и прошлое, и какую реальную власть над ним мы имеем. История эта удобная и вполне себе безоблачная — до тех пор пока у тебя не уведут аккаунт от соцсети, или пока, например, администрация ресурса не удалит твою страницу, потому что ты дрянной (по их мнению) президент и позволяешь себе лишнего.

Я какое-то время работаю над идеей забрать свои данные из соцсетей-облаков, чтобы хранить у себя (ну ок, не забрать — но хотя бы получить копию). Оказывается, сделать это непросто, и помогать юзерам никто не горит. Одно время у Яндекс Диска в интерфейсе была кнопка, выгружающая на него фото из других соцсетей, но её давно выпилили. В 2016-17 годах Касперский анонсировали похожий сервис ffforget.me, но так его и не выкатили. А значит, придётся делать всё вручную (максимально автоматизируя, как я это люблю)

Пока результаты исследований о возможности экспорта данных такие:

• вконтакте. Позволяет запросить выгрузку всех данных. Выгрузка представляет собой небольшой архив, внутри набор html страниц со ссылками на оригинальные медиафайлы — то есть все альбомы, вставленные в переписку фото-видео и тому подобное открываются из интернета, полноценной локальной копией это не является. Чтобы перенести инфу в полный оффлайн или на свой ресурс, придётся писать парсеры и выкачивать картинки и видео, от музыки думаю максимум что выйдет — утащить названия треков.

• иг. Позволяет запросить выгрузку всех данных. На выходе страница со ссылками на архивы по 2 ГБ, которые по одному нужно прокликать и скачать за ограниченные несколько дней. Внутри каждого архива — индивидуальный набор данных за определенное время: медиаматериалы, разложенные в папки по месяцам (фото и видео с очищенными метаданными и служебными именами файлов) и отдельные json с текстами постов, временем публикации, локацией в виде текста (без координат). Файлы с метаданными лежат в корне каждого архива и поэтому все архивы в одну папку развернуть нельзя — метаданные затрутся.

• гуглефото. Позволяет запросить выгрузку всех фоток и видео. На выходе страница со ссылками на архивы по 2 ГБ, которые по одному нужно прокликать и скачать за ограниченные несколько дней. Внутри архивов материалы разложены по альбомам как в сервисе (те что вне альбомов — разложены по годам). В файлах сохранены метаданные, плюс к каждому выгружается json. Имена файлов оригинальные как были в устройстве. Можно всё развернуть в одну папку.

• жж. Сервис полумёртвый, все программы-выгружальщики данных устарели и работают через пень колоду. Лучший результат по моему опыту — у https://github.com/ati/ljsm. На выходе набор связанных html страниц с картинками которые можно смотреть оффлайн

• яндекс диск — данные доступны для скачивания через родное приложение, метаданные на месте, имена файлов поменяны на сгенеренные приложением (в формате даты) при начальной загрузке с телефона, например.

• одноклассники, фб — мне неактуально, не изучал

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

Такие дела

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

Куда деваются старые программисты (не всем же уходить в менеджмент)?

Бывают ли пожилые и продуктивные программисты и прочие технари? Мне вот по жизни если и попадались взрослые айтишники, то это как правило были люди с точки зрения квалификации довольно устаревшие и ненавороченные, но может выборка фиговая?

Существует ли, объективно, айтишная чуйка? Я вот во многих случаях, даже не будучи тонким знатоком конкретной технологии, пятой точкой чую кривость, ненадёжность, рискованность, непроработанность куска системы или проекта. Но может это самовнушение?

Как отвечать на эти вопросы непонятно, как оптимально действовать в условиях стремительно пролетающих на календаре лет — тоже. Буду размышлять дальше.

Кстати, на эти размышления меня навёл произошедший только что чуднОй случай: отлаживая скрипт в окне павершелла я нечаянно крутанул скроллик мыши с зажатым ctrl — и о чудо, шрифт увеличился и окно терминала отмасштабировалось!!! Во-первых, я не знал что так можно. Во-вторых, со своим ультрамега опытом начиная от всех этих ваших дос 622, я прекрасно представлял как настраивается через параметры шрифт и размер окна терминала в винде, и никогда бы даже не попробовал менять его таким вебдванольным способом — хотя молодой спец бы так сделал инстинктивно в первую очередь. Получается, опыт тут сыграл как якорь? Но, с другой стороны, я хак вроде запомнил, не брюзжу «вот до чего билгейтсы страну довели», и если что помню, в отличие от всяких сопляков, и дедовский способ. Наверное, всё же интегрально я тут в плюсе. По крайней мере, хочется надеяться.

Будучи Ветераном Этих Ваших Комплюктеров, всегда забивал на приветственные «знаете ли вы» различных программ и систем. Ну во-первых, камон, чему меня человека может научить какая-то там софтина. А во-вторых, мне надо будет — сам в документации посмотрю.

А сегодня вот логинясь по совершенно другим делам в свежий тестовый CentOS 8, зацепился глазом за совет сделать вкл какому-то там «cockpit.socket», загуглил обо что это всё, попробовал — и открылась мне, всезнающему, целая новая непривычная парадигма управления линукс серверами через веб консоль, да ещё и встроенная вот так вот в минимальный дистрибутив.

Век живи, век учись, и тому у кого и как учиться — тоже учись.

Редкий, но противный кейс: есть сервер на Windows — виртуальная машина на платформе VMware, у которого нужно уменьшить размер одного из дисков (и размер соответствующего vmdk файла на хранилище). До кучи — сервер нельзя выключать надолго.

Чаще всего такие ситуации случаются из-за ошибок сайзинга при развёртывании (в том числе, при прогибании на переговорах разработчиков, которым всегда нужно мильён терабайт и триллион ядер этих ваших комплюктеров, чтобы «одинэс быстро работал»), либо когда система выводится из эксплуатации, оставаясь в дремлющем режиме, и потребности в пространстве у неё снижаются, но убивать полностью её пока нельзя.

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

Картина неизвестного художника «Админ накидал на датастор виртуалок с тонкими дисками и ушёл в отпуск»

В операционках Windows отлично работает софтверное зеркалирование, с помощью которого задачу можно решить надёжно, достаточно быстро и без существенных перерывов в работе сервиса (а чаще всего вообще без них).

Сейчас КЭНК-мэн займётся вашими дисками, ребята

Как сжать системный диск

• Сжать раздел стандартными средствами Windows Server до необходимого
• Добавить новый виртуальный диск(и) такого размера как получившийся необходимый размер
• На разделах старого диска (100 мб и системный вместе, остальные если надо — по отдельности) правой кнопкой — добавить зеркало, указать новый диск. Диски преобразуются в динамические и начнётся синхронизация
• В свойствах компьютера установить опции загрузки с вторичного плекса и выбора операционной системы и возможности восстановления при запуске
• Дождаться полной синхронизации зеркальных томов
• Выключить виртуалку. Отключить оригинальные диски от виртуальной машины
• Загрузить сервер, отключить (поломавшееся) зеркалирование

Как сжать несистемный диск

* Сжать раздел стандартными средствами Windows Server до необходимого

• Добавить новый виртуальный диск(и) такого размера как получившийся необходимый размер
• На разделе старого диска правой кнопкой — добавить зеркало, указать новый диск. Диски преобразуются в динамические и начнётся синхронизация
• Дождаться полной синхронизации зеркальных томов
• Отключить (можно на горячую) оригинальные диски от сервера
• Отключить зеркалирование, указав что пропавшего диска в зеркале больше нет и не будет.

Детали и тонкости

Использующие раздел ИС переживают такие операции без проблем, в случае если диск не системный простой сервиса = 0

Иногда всё свободное пространство освободить не получается — диспетчер дисков Windows выдает ошибку «недостаточно свободного места» (There is not enough space available on the disk(s) to complete this operation). Проблема не в месте, а в неперемещаемых файлах, используемых в момент сжатия системой. Решается изучением логов Event Viewer Windows Logs\Application, где видно что именно мешает, и после соответствующих операций (типа временного отключения мешающего файла подкачки на разделе) раздел скорее всего удастся сжать.

Слава Роботам!
КЭНК!

В издательстве BHV вышло второе издание книги Дмитрия Кетова «Внутреннее устройство Linux». Лучше всего отличительную особенность книги сформулировал в предисловии сам автор:

в книге рассматриваются абстрактные концепты внутреннего устройства ОС, иллюстративно подкрепляемые примерами анализа (а иногда и синтеза) ее конкретных компонент и связей между ними.

Именно такого взгляда на Линукс, глубокого и направленного в корень истории того, что в итоге стало важнейшей технологией современности, не хватает многим спецам моего поколения, учившимся работе с системой методом проб и ошибок, ковыряясь с неведомым чудо зверем прямо in the wild.

Прекрасно помню как весной 1999 я обошёл всю Савелу в желании купить видеокарту, которая в том числе будет нормально работать с тогдашним RedHat (купленным на диске в ларьке на территории Академии). Продавцы на мои вопросы делали квадратные глаза, и в итоге карта была взята наобум, и после ночи камлания над конфигами всё-таки завелась в X Window, не очень понятно как.

Помню ещё смешную историю, хоть и не в тему линукса — когда ребята в общаге несколько часов воевали с дровами на притащенный откуда-то матричный принтер с подключением по LPT. Система его упрямо не видела — как оказалось, в тесноте переполненного стола кабель воткнули не в тот системник.

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

Книга на сайте издательства по ссылке https://bhv.ru/product/vnutrennee-ustrojstvo-linux-2-izd/
В Мск с доставкой в пункт СДЕК выходит в смешные $10

На днях все тематические ресурсы выпустили материалы, посвящённые 35-летию выхода первых Windows — с картинками, видео рекламы и сравнениями версий и «воспоминаниями».

Даже не касаясь вопроса возраста авторов статей (и их фактического отсутствия на планете в моменты описываемых ими релизов), хочу отметить фантомность этих воспоминаний для жителей 1/6 части суши. Никакие ранние версии винды в тотальной массе тогдашних комплюктеров никогда не работали, собственно и ПК-комплюктеры в многочисленные бухгалтерии и АСУ московских и подмосковных предприятий в 80-е еще не разместились массово. А когда разместились, всем там правил великий и могучий Лексикон, бухгалтерский софт под DOS, да игрушки под него же.

И даже к 1995, когда топом доступной конфигурации стали AMD 486DX4-120 (а в далёких буржуиниях в ход пошли Пентиумы), когда начала активно развиваться «мультимедия» в виде саундкарт и смешных пластиковых колонок, а мыши были далеко не у всех, Windows 3.11 всё ещё воспринимался больше как «хрень которую надо запустить чтобы порисовать в паинт».

Хороший пример этого: дорвавшись до более-менее актуального железа, и взявшись за своё первое графическое приложение на GW-BASIC с поддержкой мыши (через написанную другом Максом на чудном языке cи минус минус библиотеку), я конечно же запилил клон Paint, назвав проект при этом WinBatos — настолько была жесткая связь в голове «Windows=Paint». И это я уже не был чайником — программировал на ассемблере и всяких паскалях, выигрывал олимпиады по информатике, умел собирать компы и уже два раза успел потерять по 560 мегабайт Гифок Из Фидо при экспериментах с включением LBA на диске.

Тот самый винт со Срамными Картинками

По моим ощущениям, в массе мы догнали компьютерный мир только к началу двухтысячных, а первая действительно популярная винда — 95.

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

alias kgn="kubectl get nodes -o wide"
alias ka="kubectl apply -f"
alias kd="kubectl delete -f"
alias kgp="kubectl get po -o wide -n"
alias kgpa="kubectl get po -A"
alias kgs="kubectl get svc -n"
alias kge="kubectl get ep -n"
alias kgi="kubectl get ing -o wide -n"
alias kns="kubectl run --generator=run-pod/v1 tmp-shell --rm -i --tty --image nicolaka/netshoot -- /bin/bash"

Закончил курс по Кubernetes от DataLine

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

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

Чуть позже у DataLine должна пройти ещё одна часть курса, с глубоким погружением в практику, куда обещают взять лучших по итогам теста. Тест уже сдан вполне успешно, рассчитываю на приглашение.

Огромный плюс курса — предоставляемый преднастроенный кластер, где можно и входящую в состав занятий практику повыполнять, и глубже (дальше) в тему продвинуться. Преподаватели мастеровитые, практики, в теме разбираются, объясняют внятно, проведена большая подготовительная работа — от слайдов и презентаций до манифестов и готовых образов с нужным для занятий функционалом. И это всё ещё плюсом к тому — бесплатно.

Удобно, что лекции пишутся, и есть возможность после сесть и вдумчиво сделать практику — материал непростой, сразу вникнуть удавалось не всегда.

Курс ведут Станислав Миллер и Сергей Старицын (в его лекциях также активное участие принимают коты). Это был уже четвёртый поток, анонсы следующих (и занятий на другие темы) — в телеграм канале Даталайн, отчаянно рекомендую.

Прохожу очень полезный курс о 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