⌨️ K8s. Компоненты кластера

k8s в схемах и схемах 1

#k8s

Все думал, с чего начать серию постов о великом и ужасном кубере, как подступится? Решил рассказать о самом популярном оркестраторе контейнеров через схемы. Ну и, разумеется, первый пост об основных компонентах кластера. Это стандартный и довольно частый вопрос на технических собеседованиях вплоть до мидловых позиций.

В схеме, пунктирной линией с серым заполнителем обозначен сам Kubernetes кластер. Внутри — два типа объектов Control Plane и Worker node.

Control Plane

Control Plane отвечает за управление кластером и обеспечение его работы. Он состоит из нескольких компонентов, которые могут работать на одном управляющем узле (master node) или быть распределены между несколькими узлами и реплицированы для обеспечения высокой доступности.

Kubernetes API Server: с ним непосредственно взаимодействуете как пользователь, так и другие компоненты Control Plane, потому что он предоставляет доступ к API Kubernetes, а значит является основным интерфейсом для Control Plane. На схеме занимает центральную позицию, на него указывают большинство стрелок.

Scheduler, компонент, который отслеживает вновь созданные поды без назначенного узла и выбирает узел для их запуска.При принятии решений о планировании учитываются следующие факторы: требования к ресурсам (как со стороны размещаемого пода, так и воркер-ноды или всего кластера), hardware/software/policy ограничения, affinity и anti-affinity спецификации, расположение данных, влияние подов друг на друга (избежание риска конкуренции за ресурсы) и дедлайны.

Controller manager, запускает логические компоненты (контроллеры) которые отслеживают состояние кластера и управляют его объектами чтобы обеспечить их соответствие желаемой конфигурации.

etcd, распределенное хранилище данных, которое постоянно хранит конфигурацию кластера.

Nodes

Рабочие узлы (worker nodes) – это машины, на которых выполняются контейнеризированные приложения.

Kubelet, агент, который обменивается с API сервером и управляет контейнерами на своем узле.

Кube-proxy прокси Kubernetes, он балансирует нагрузку сетевого трафика между компонентами приложения и поддерживает сетевые правил для узлов.

Container runtime: это среда для выполнения контейнеров. Она жёстко не закреплена и может поддерживать контейнерные рантаймы, соответствующие интерфейсу CRI (Container Runtime Interface). Наиболее популярные из них — containerd и CRI-O

⌨️ K8s. Pod

#k8s

Емкое слово pod, означающее в английском то ли стручок бобового растения (см. «шапку поста»), то ли группу (стаю) морских млекопитающих, вроде дельфинов или китов (см. лого Docker), в некоторых плохих переводах неплохих тематических книг обозначается как МОДУЛЬ. Скажите мне, зачем переводить на русский язык технические термины?

Но это тема для отдельного поста.

Нас же интересует, что за сущность такая в Kubernetes pod и какую задачу она решает. Почему вообще оркестратор контейнеров работает не с контейнерами как таковыми, а с pod’ами, которые в свою очередь эти контейнеры содержат?

Неправильный ответ на вопрос, что такое pod, мог бы звучать как-то так:

Под в Kubernetes — это особый контейнер, который может содержать несколько других контейнеров, но обычно содержит только один. Фактически это всё тот же контейнер, только с дополнительной k8s спецификой.

Контейнер — это среда для одного процесса, а pod — среда для контейнеров. Как контейнер обеспечивает изоляцию процесса, так pod обеспечивает изоляцию одного или нескольких контейнеров. При этом pod даёт размещённым внутри него контейнерам общий контекст: снабжает их общими ресурсами и упрощает взаимодействие.

Аналогия, объясняющая pod как «logical host» для приложения, мне нравится. Идея в том, что контейнер предназначен для запуска только одного процесса: каждому процессу — свой контейнер. А значит, для группировки и связывания контейнеров нам необходима конструкция более высокого уровня.

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

В следующих постах попытаемся расширить тему. В частности, попробуем понять, каким контейнерам удобно подобное «внутриподовое» соседство, поговорим о pod lifecycle, о pod статусах и о многом другом, а потом пойдём вверх по иерархии и поймём, что управляет самими pod’ами.

⌨️ Всем привет

Небольшой анонс: завтра выходит публикация Кати👰‍♀️— она получилась классной и интересной. Вам тоже должно понравиться! Тема — одна из самых высокооплачиваемых специальностей в IT.

👰‍♀️ Самая высокооплачиваемая айти-профессия

#рекрутинг

Девопс часто называют одной из самых высокооплачиваемых айти-профессий, и отчасти потому она настолько желанна. Согласно статистике сайта dreamjob, средняя зарплата синьора в России - 350 000 рублей.

Но что, если я скажу, что существует более прибыльное направление, специалистам-джунам которого готовы платить 4-5 тысяч долларов в месяц? Я бы сама не поверила, если бы такая вакансия не пришла мне в работу.

Речь идет о Quantitative Researcher в хэдж-фондах. Это специалисты, близкие по стеку к ML-щикам, которые создают алгоритмы для автоматизированной торговли на фиатных или криптовалютных биржах.


Главным минусом данной профессии является очень сложный отбор: у работодателей в приоритете выпускники математических направлений топ-вузов, в первую очередь МФТИ, МГУ, СПбГУ, НИУ ВШЭ, затем - главные региональные университеты. В том месте, куда нанимала я, также было тестовое задание и целых два технических этапа, на одном из которых кандидатов “прогоняли” по всей вузовской программе, начиная с первого курса.

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

Так как это сложный поиск, такие компании часто обращаются за помощью в найме к кадровым агентствам. Что это значит? Что в некоторых случаях страница на Линкедин может помочь даже джуну без опыта, но с сильным образованием, получить интересное предложение. Не забывайте о профильных социальных сетях, каким бы ни был ваш грейд!

⌨️ Об отношениях с работодателем

#карьера

Всем привет!

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

Начну издалека. Есть такая старая админская максима, звучит она как: «Работает – не трогай». Я не буду объяснять, как это связано с администрированием, думаю, большинство прочитавших этот пост прекрасно её поймут. Зато объясню, как она может быть связана лично с вашей работой.

Итак, по мнению менеджмента компании, которая вас наняла и платит вам зарплату, вы – это то, что не стоит трогать, пока это работает. Если вы выполняете свои обязанности на среднем уровне или выше и это устраивает вашего лида и менеджера, то в большинстве случаев никто не будет вас за это поощрять.

Да, существуют механизмы премий, индексации и performance review, но о них мы поговорим отдельно. Сегодня же я хочу лишь упомянуть контроффер.

Но сначала банальность. Если в течение прошлого года вы не получили прибавку к зарплате, вы обеднели на 10%. Примерно такую инфляцию за 2024 год посчитал ЦБ. Подрос и средний чек в продуктовых магазинах. Поэтому рост вашей зарплаты в рублях должен как минимум покрывать инфляцию – если вы хотите не расти в доходе, а просто поддерживать текущий уровень жизни. 10% в год – это стагнация, уже не рецессия, но еще не рост.

Почему стагнация? Потому что ваш опыт, а значит и ценность как специалиста, растёт. Если растёт опыт, должна расти и оплата труда.

Вы и ваш работодатель (интересы которого представляет менеджер или тимлид) – не враги и не друзья. Ваши отношения – это не отношения носителя и паразита (кто бы кем кого ни считал). Работодатель – это не Атлант, который не только делает мир лучше, но еще и содержит вас. И не эксплуататор-мироед, который ворует прибавочную стоимость, сидя на куче золота. Отношения работника и работодателя – это симбиоз. И мыслить, я думаю, стоит исходя из этого.

Если молчит работодатель, значит, его всё устраивает. Если молчите вы, значит, вас всё устраивает.

Равновесие достигнуто. Даже если работодатель делает вид, что платит вам зарплату, а вы делаете вид, что работаете.

Не знаю, что именно думает ваш работодатель (или его представитель) о вашей эффективности, но уверен: лично вы бы не отказались получать больше, прикладывая те же усилия. А теперь главное – как получить желанную прибавку? Нарушить равновесие в свою пользу.

Сначала просто попросите.

Поговорите с менеджером и попросите прибавку в 15–25%, в зависимости от ситуации. Послушайте, что вам ответят.

Если отказали (или затянули процесс) – начинайте эскалацию.

Приходите снова, но уже с оффером от другой компании. Ничто так не заставляет ценить работника, как перспектива его потери.

Проверено на собственном опыте, на опыте коллег и моих менти. Работаете в офисе, а хотите удаленку? Предложат удаленку. Хотите подработку? Одобрят. Нужно больше денег? Могут предложить план роста. Есть оффер? Попробуют перебить его. А если нет – у вас уже есть куда уйти, где ваш труд ценят больше.

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

Хотите обсудить? Вы знаете, с чего начать!
Если не общались со мной вживую – переходите по ссылке, оставляйте заявку на встречу. Если уже коннектились через Getmentor и у вас есть мой контакт – пишите в личку.

👰‍♀️ Что делать после провального интервью?

#рекрутинг

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

1. Запросите у рекрутера фидбек, чего именно вам не хватило для успешного прохождения интервью. Если вас игнорируют - выдыхайте, как говорится, мусор вынес себя сам. Скорее всего, остальные процессы в компании тоже настроены плохо, и это прекрасно, что вы не будете работать в таком месте.

2. На основании фидбека, а также собственных ощущений, выпишите вопросы, на которых застопорились, и распишите красивые, максимально полные ответы на них.

3. Если у вас есть ментор - разберите эти вопросы с ним.

4. Помните, что любой опыт, даже негативный, очень ценен. Каждое следующее интервью будет даваться легче предыдущего, и работа мечты уже не за горами!

Дайджест#1

#дайджест

Всем привет! Наконец-то пришло время выпустить первый дайджест. Он получился объемным и включает около сорока публикаций, это почти все полноценные посты, вышедшие с момента создания канала.

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

Приятного чтения!

#рекрутинг

👰‍♀️ Как точно НЕ получить работу в айти: 5 простых шагов. Вредные советы

👰‍♀️ Так почему они вредные?

👰‍♀️ Странные вопросы на интервью

👰‍♀️ Лучший запрос самооценки, лучшая обратная связь

👰‍♀️ А нужно ли сопроводительное?

👰‍♀️ Когда сопроводительное действительно нужно?

👰‍♀️Как впечатлить рекрутера своим английским?

⌨️ HR фрустрирует

👰‍♀️ Календарный цикл найма: когда лучше всего искать работу

👰‍♀️ Самая высокооплачиваемая айти-профессия

#process_management

⌨️ Из чего сделаны наши процессы?

⌨️ Внутри процесса (thread inside)

⌨️ Имя отчество (PID PPID)

⌨️ Как они размножаются? fork()/clone() exec()

⌨️ Отцы и дети (parent - child processes)

⌨️ Родился, потерпел и умер: Жизненный цикл процесса

⌨️ Биография. Вспоминаем и делимся

⌨️ STAT Жди, работай, спи

⌨️ Сигналы: 30 способов умереть или быть убитым

#PersonalExperience

👰‍♀️ О моём опыте собеса на сисадмина (начало)

👰‍♀️ О моём опыте собеса на сисадмина (продолжение)

⌨️ Planning poker

⌨️ Когда я смогу закончить учиться?
(1/5) , (2/5) , (3/5) , (4/5) , (5/5) ;

#реальные_вопросы

⌨️ Вопросы с реального собеседования #1

⌨️ Мета вопросов в технических собесах

⌨️ Меняешь права - умножаешь на 2

#мотивация

👰‍♀️ Немного мотивации и добрых слов для джунов, которые ужасно устали от поиска работы 🥹

#docker

⌨️ Меняешь права - умножаешь на 2

⌨️ Контейнеры и Zero Trust. Познаём безопасность, прокачиваем резюме

⌨️ docker.sock

#k8s

⌨️ K8s. Компоненты кластера

⌨️ K8s. Pod

#карьера

⌨️ Не быть джуном

⌨️ Об отношениях с работодателем

#собеседования

⌨️ Немного о чудовищных собеседованиях

#интересное

⌨️ SQL-инъекции: технология древних хакеров, которая до сих пор работает

⌨️ Задачи (1/4)

#PersonalExperience

Всем привет, добро пожаловать во вторник. Сегодня, как и обещал, немного про рабочие будни и задачи.

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

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

Какие задачи интересны лично мне в первую очередь?

Два типа задач.

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

Второй тип — это задачи, которые позволяют улучшить навыки в технологиях, востребованных на рынке труда. Решив такую задачу, понимаешь, что теперь твое время как специалиста стоит дороже. Для меня сейчас это в основном DevSecOps-таски: работа с GitLab CI, Vault, Terraform, Go, K8s и различным прикладным софтом.

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

Но бывают и другие задачи. Они почти не дают профессионального роста, но при этом отнимают кучу времени. Это задачи, над которыми приходится корпеть не только днем, в рабочее время, но и ночью, вместо сна. Однако, выполнив их, ты испытываешь невероятное удовлетворение. Кроме того, подобные задачи в твоем активе — отличный аргумент, чтобы попросить повышение зарплаты.

Что это за задачи и подробности об одной из них — в следующем посте, который выйдет завтра.

⌨️ Задачи (2/4)

#PersonalExperience

Надеюсь ваша среда была легче чем моя.

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

Автоматизация и Infrastructure as Code — основополагающие понятия в нашей профессии, и поэтому мне больно делать что-либо вручную. Повторяя одно и то же действие несколько раз, ты буквально физически чувствуешь, как тупеешь. Особенно если знаешь, как это автоматизировать.

Даже в компаниях, где инфраструктура полностью описана в коде, может существовать неавтоматизированный разрыв между предоставлением сервера под управление и его попаданием в инфраструктуру. Особенно если провайдер не имеет API или сдаёт в аренду выделенные серверы.

Физические выделенные серверы (Dedicated) имеют ряд преимуществ над виртуальными и облачными решениями:

Предсказуемая производительность без влияния "шумных соседей" (noisy neighbors)

Отсутствие оверхеда гипервизора и задержек связанных с шарингом ресурсов.

Стоимость тоже является преимуществом dedicated серверов. Аренда выделенных серверов может оказаться выгоднее, особенно в перспективе.

Недостатков тоже хватает:

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

! Гибкость — если сервер простаивает, его ресурсы нельзя оперативно перераспределить.

Физическая уязвимость — поломка HDD, RAM или другого компонента может привести к простоям.

И именно последний недостаток такого подхода, послужил причиной образования неавтоматизированной лакуны. Перед тем как сервер станет частью твоей инфраструктуры, все его компоненты необходимо проверить. Как это сделать часто указывает скрижаль древних в формате docx. И в первый раз выполнив все предписываемые инструкции я едва не выгорел…

⌨️ Задачи (3/4)

#PersonalExperience

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

Но как получилось, что столь очевидная цель для автоматизации оставалась неотработанной? Дело в нестандартной конфигурации: одни и те же команды утилиты, запущенные на разном железе, показывали если и не разный вывод, то, как минимум, различное расположение ключевых значений (тех, что в итоге оказывались в таблице). Это зависело, например, от производителя. Самый простой пример такой разницы — показания температуры ядер под нагрузкой. lm-sensors, указанная в скрижалях древних, выдавала разный вывод в зависимости от того, был процессор произведён Intel или AMD. Да что там производитель — вывод отличался даже в зависимости от поколения чипа.

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

Пришлось взяться за это. Ситуация осложнялась тем, что первый рабочий прототип утилиты (а это процентов 70 всей работы) я решил написать, не ставя никого в известность, используя только то время, что было выделено под тестирование серверов. Причина банальна: я не сомневался, что автоматизация возможна, и не сомневался в своей компетенции. Я думал о другом — хватит ли мне терпения довести утилиту до состояния, в котором ею сможет пользоваться кто-то, кроме меня. Потому не хотел идти к тимлиду с пустыми руками, имея лишь идею. Хотел оставить себе пути для отступления.

Не буду подробно описывать процесс разработки. Скажу лишь, что писал на Python, взяв за основу библиотеку fabric для основной части утилиты и openpyxl для парсера. Отдельную боль доставило тестирование дисков: пришлось разрабатывать для них отдельную логику, поскольку различались как их количество, так и состояние (диски могли поставляться дата-центром как в RAID, так и без него, с файловой системой нужного формата или без неё). Скрипт должен был, без ручного вмешательства, приводить диски к целевому состоянию.

В итоге мне удалось разработать прототип утилиты для тестирования, а позже довести её до ума. Спустя некоторое время я упаковал её в контейнер и сделал возможность запуска непосредственно из GitLab, соорудив для неё пайплайн.

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

⌨️ Задачи (4/4)

#PersonalExperience

Добро пожаловать в пятницу. Это финальная часть поста, который задумывался как короткий этюд о трудовых буднях DevOps-инженера, но разросся чуть ли не до полноценной статьи. Вспомним, о чем я писал раньше:

Часть 1, в которой я рассказываю о типах рабочих задач и их пользе.

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

Часть 3, в которой я, наконец, описываю задачу и некоторые подробности её решения.

Подведем итоги

Я решил поставленную самому себе задачу. Что получил в качестве награды?

Несколько малосонных ночей породили вполне себе рабочую утилиту для тестирования серверов. Теперь её надо поддерживать, вылавливать баги и, в случае чего, адаптировать под новые конфигурации. И делать это буду в 90% случаев я. Напоминание об ответственности за свои создания.

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

Избавление от ненавистной мне задачи, которая опасно приближала моё выгорание.

Респект и уважение от команды (скорее всего).

Что получила моя команда?

Сокращение количества действий для выполнения типовой и довольно частой задачи процентов на 90-95. Теперь она оценивается минимальным количеством стори-пойнтов. Надеюсь, что я также отсрочил чьё-то выгорание.

Вывод

Задачи, повышающие собственное work quality и work quality твоих коллег, обладают невероятным потенциалом для satisfaction. Если по-русски, то очень приятно видеть пользу от своего труда. Это помогает любить своё дело и видеть в нем смысл.

Любить свою работу полезно, потому что не любить то, чему посвящаешь треть своего времени, чревато негативными последствиями — как физического, так и ментального характера. Осознаю банальность вывода, но к чему пришёл, к тому пришёл.

Поэтому всем интересных задач, а я пошёл писать серию постов на тему K8s 101 и рисовать к ним схемы. Увидимся на следующей неделе!

⌨️ Всем привет!

Завтра обещанный пост на тему K8s 101. Разберу популярный вопрос с собеседований:

«Опишите путь, который проходит Pod от момента деплоя его манифеста до статуса Running».

А прямо сейчас читайте пост Кати 👰‍♀️ о том, что писать в разделе «О себе» в резюме!

👰‍♀️ Что писать в поле “О себе”?

#рекрутинг

Представьте: вы уже вспомнили и красочно расписали весь свой опыт работы, указали полный стек, потратили на резюме немало времени, и вот появляется оно - финальный босс, поле, в которое непонятно, что писать, но и пустой оставлять не хочется. Да, речь о графе “О себе”. Давайте разбираться, чем можно ее заполнить!

1. Самым лучшим решением будет указать телеграм для связи. У многих рекрутеров, в частности, почти во всех агентствах, не оплачена база открытия контактов в Хэдхантере. Вписав телеграм в поле “О себе”, вы будете получать больше предложений пройти интервью.

2. Можно кратко суммировать весь свой опыт. Например “DevOps-инженер с трехлетним опытом работы в интеграторе и продуктовой компании с отличным знанием Kubernetes”.

3. Описать, что вы ищете и в каком направлении хотели бы развиваться. “Рассматриваю предложения с возможностью удаленки из-за пределов РФ и зарплатой в валюте” или “Хотел бы работать в компании, продукт которой полезен людям. Букмекерские конторы и казино не рассматриваю”.

4. Информация о ваших увлечениях вне работы совершенно не обязательна. Но если хочется сделать резюме более живым и человечным - почему бы и нет 🙂