⏰ Интересный концепт для прокрастинаторов (точно не про меня)

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

1. YouTube Addiction Rehab

Это расширение для Chrome фильтрует ваши интересы и отсеивает мусорные рекомендации. Цель — оставить в ленте только полезные видео и избавить от «тёмных кроличьих нор», куда YouTube любит затягивать. Отлично подходит для тех, кто хочет осознанно управлять своим временем и не поддаваться на алгоритмические соблазны.

2. BlockTube

Более продвинутое решение для тех, кто хочет вручную настроить свой YouTube. BlockTube даёт возможность:

• Блокировать видео и каналы по названию
• Исключать комментарии на основе ключевых слов или имени автора
• Убирать YouTube Shorts и фильмы
• Прятать просмотренные видео из рекомендаций
• Настраивать фильтры по длительности роликов
• И даже отключать раздражающие всплывающие окна «Видео приостановлено, продолжить просмотр?»

Для правильных пацанов есть поддержка regex📜 и возможность интегрировать JavaScript-функции для кастомной блокировки.

Ссылки на расширения:

• YouTube Addiction Rehab
• BlockTube

В итоге, если YouTube всё-таки затягивает, эти инструменты могут стать отличным решением.

Phase vs Status подов в Kubernetes

При работе с Kubernetes важно понимать, как следить за состоянием и фазами подов. Сегодня разберем, как Kubernetes управляет фазами Pod’ов и состояниями контейнеров - эта инфа точно пригодится для менеджмента нод, ну или просто пройти интервью.

Фазы подов - что происходит от создания до завершения

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

• Pending – под создан, но еще не запущен. Он ожидает, пока его назначат на ноду и загрузят все образы контейнеров.
• Running – Хотя бы один из контейнеров пода успешно запущен.
• Succeeded – Контейнеры выполнили свои задачи и завершились корректно.
• Failed – По крайней мере один контейнер завершился с ошибкой, или под был неправильно сконфигурирован.
• Unknown – Состояние неизвестно, так как нода перестала отвечать API-серверу.

Чтобы посмотреть, в какой фазе находится под:

$ kubectl get po pod -o yaml | grep phase

Или старым дескрайбом

$ kubectl describe po pod

Состояния подов - что происходит внутри

Фазы показывают общий статус пода, но более точная информация содержится в состояниях. Подобно состояниям нод (например, MemoryPressure и DiskPressure), поды имеют собственные статусы.

• PodScheduled – назначен на ноду.
• Initialized – Все init-контейнеры успешно завершили выполнение.
• ContainersReady – Все контейнеры внутри пода готовы.
• Ready – готов обслуживать запросы клиентов.

Каждое из этих состояний может иметь значение True или False в зависимости от текущего статуса пода. Например, если хотя бы один контейнер не готов, состояние ContainersReady будет False. Это позволяет более точно отслеживать проблемы и устранять их.

Пример

Запустим под с помощью манифеста:

$ kubectl apply -f pod.pod.yaml

После этого проверим его статус:

$ kubectl describe po pod

Если вы видите, что контейнеры не готовы или под не стартует, используйте вывод команды describe для диагностики. Например, состояние Initialized: False может указывать на проблемы с init-контейнером.

Понимание фаз и состояний подов помогает не только отслеживать работу, но и траблшутить проблемы. Используйте команды kubectl describe и kubectl get и помните: диагностика – ключ к стабильной инфраструктуре.

🔧 Траблшутинг Kubernetes: как не потеряться в лабиринте

Решение проблем в Kubernetes для меня всегда напоминает блуждание по лабиринту. С его распределённой архитектурой и множеством компонентов, найти и устранить проблему требует целого набора инструментов и методик. Это не просто — но с опытом приходит понимание, как делать это эффективно.

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

Хотя я стараюсь собрать советы из собственного опыта, не забывайте, что официальная документация Kubernetes остаётся основным и самым достоверным источником информации. 📜

🔄 Анализ жизненного цикла подов

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

Этапы жизненного цикла пода
Про фазы пода я писал в предыдущем посте. Напомню просто, чтобы проанализировать состояние подов, используйте команды kubectl get и kubectl describe.

✨Евенты пода

Секция “Events” в выводе команды kubectl describe предоставляет хронологический журнал всех событий которые случились с подом. Это помогает понять, что привело к проблеме и как её устранить. Вот несколько типичных случаев, с которыми я сталкиваюсь:

- "Неназначение" на ноду:: возможно, нехватка ресурсов на Node или проблемы с планировщиком.
- Ошибки при загрузке образов: чаще всего указывают на сетевые проблемы или недоступность контейнерного реестра.
- Сбои контейнера: повторяющиеся падения контейнера можно диагностировать, изучив события перед сбоем.

📝 События и аудит-логи в Kubernetes

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

🔍 Просмотр событий

kubectl get events чтобы просмотреть события в кластере. Вот пример:

LAST SEEN   TYPE      REASON             OBJECT                                   MESSAGE
12s         Normal    Scheduled          pod/web-server-pod                       Successfully assigned default/web-server-pod to node-1
10s         Normal    Pulling            pod/web-server-pod                       Pulling image "nginx:latest"
8s          Normal    Created            pod/web-server-pod                       Created container web-container
7s          Normal    Started            pod/web-server-pod                       Started container web-container
5s          Warning   BackOff            pod/db-server-pod         

Аудит-логи Kubernetes

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

{
    "kind": "Event",
    "apiVersion": "audit.k8s.io/v1",
    "level": "Metadata",
    "auditID": "12345",
    "stage": "ResponseComplete",
    "requestURI": "/api/v1/namespaces/default/pods",
    "verb": "create",
    "user": {
        "username": "admin",
        "groups": ["system:masters"]
    },
    "sourceIPs": ["192.168.1.1"],
    "objectRef": {
        "resource": "pods",
        "namespace": "default",
        "name": "web-server-pod"
    },
    "responseStatus": {
        "metadata": {},
        "code": 201
    },
    "requestReceivedTimestamp": "2024-01-01T12:00:00Z",
    "stageTimestamp": "2024-01-01T12:00:01Z"
}

📊 Дашборды
Когда работаю с кластером, пользуюсь инструментом для мониторинга - Lens. Это удобный GUI для Kubernetes, который помогает отслеживать состояние кластеров, управлять ресурсами и проводить диагностику.
Lens — это кросс-платформенное приложение с открытым исходным кодом, которое позволяет подключаться к Kubernetes-кластерам и управлять ими через визуальный интерфейс. По сути, Lens — это дашборд, который упрощает взаимодействие с Kubernetes, предлагая все возможности kubectl, но с визуализацией и множеством дополнительных функций для удобства. Загрузить приложение можно с официального сайта.


Траблшутинг Kubernetes требует понимания его компонентов и внимательного анализа событий. Используя инструменты, такие как kubectl get, kubectl describe, события, аудит-логи и дашборды можно эффективно находить и решать проблемы. 😵‍💫

System Design интервью: проектировал Instagram📸

Недавно на system design интервью (https://yandex.ru/jobs/pages/devops_cloud) мне выпало задание спроектировать сервис для обмена фотографиями, чем-то напоминающий Instagram. Конечно, я уже где-то такое видел (но, честно говоря, мало что запомнил), и мне почти профессионально удалось проговорить все ключевые моменты дизайна. Потом я поработал над архитектурой, которую можно увидеть на скриншоте — тут уже не так “профессионально”, но всё равно сносно. Давайте погрузимся в детали проектирования и самого интервью.

Основные функции

Начал я с разбора основных сервисов и их функций. Вот ключевые моменты:

- 📤 Загрузка фотографий.
- 🔔Подписки и фолловеры.
- 📜Построение персонализированных лент новостей.

Также важно было учесть масштаб:

- 500M DAU (ежедневно активных пользователей).
- 1B MAU (ежемесячных активных пользователей).
- 2.5B общих пользователей.
- 50B фотографий в системе.
- 50M фотографий загружается каждый день, каждая размером 100 KB.

1. Как грузить фотки?

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

Каждая загруженная фотка попадает в основное хранилище, а для ускорения доступа — кешируется через Redis. Система простая: Redis сидит между базой данных, где хранятся фотографии, и API-шлюзом. Когда пользователь запрашивает фотку, сперва проверяется кеш. Если там её нет — идём в базу данных. Конечно, всё работает на хешах, потому что гонять блобы через сеть в таком объёме — задача почти фантастическая.

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

2. Как организовать шардирование? 🪨

С такими данными игнорировать шардирование просто непрвильно. Поэтому следующий вопрос — как распределить пользователей по шардам? Я использовал хеширование по userId для обычных пользователей, чтобы их данные равномерно распределялись. Это не только облегчает масштабирование, но и позволяет системе дышать спокойно. VIP-пользователи 👑 которые генерируют кучу трафика, были выделены в отдельные шарды. Это не только изолировало их от остальных пользователей, но и снизило нагрузку на общую систему.

3. Лента новостей (Feed)

Теперь самый важный момент — как обеспечить низкую задержку при генерации ленты новостей? Используем асинхронную обработку: при публикации новых фотографий от VIP пользователей фоны ленты не должны тормозить. Для этого была введена система обработки данных с использованием очередей (типа Kafka) которая позволила фоново обновлять ленты пользователей. Кроме того, все непрямые задачи (статистика и маркетинг) тоже вынес в асинхронные процессы, чтобы основной канал оставался чистым, а пользователь всегда получал контент с приоритетом. Аналитические данные мы собираем в фоновом режиме, так что цифры у нас есть, а пользователи счастливы.

4. Fault tolerance и балансировка нагрузки 🤹

Для обеспечения доступности сервиса 24/7 логично было использовать load balancer на входе. Я также предусмотрел развёртывание нескольких дата-центров с асинхронной репликацией данных и добавил CDN. Теперь пользователи из Канады не ждут свои фотки из России как-будто они грузятся по почте.

5. Безопасность и масштабируемость 🔒

Система хранения метаданных (комментарии, лайки, подписки) была спроектирована с использованием PostgreSQL с мастер-слейв репликацией для отказоустойчивости. Кеширование в Redis также ускоряет доступ к часто запрашиваемым данным.

Итоги

Вот ключевые решения, которые я принял:

- Шардирование пользователей с выделением VIP в отдельные шарды.
- Использование CDN для ускорения доставки фотографий.
- Кеширование данных и асинхронная генерация ленты новостей.
- Репликация данных для повышения отказоустойчивости.

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

Как выбирать визы и контракты для работы в США?

Недавно получил письмо от HR, который набирает специалистов из разных областей на контракты в США.
Are you looking for Next opportunity in U.S.A?
Hiring Talent specialized from most of the Technologies like Java,.Net,Devop?s,AWS,Azure,Sharepoint,Mulesoft,Salesforce,Python,BI,MS CRM,RPA,ML etc..
Exclusively working on E3 Visa /TN Visa/E3 Transfer /TN transfer/H1B Transfers/EAD?s/OPT?s/C2C/GC process along with the Project in USA.

Разные визы, условия найма, бесконечные термины и аббревиатуры — кажется, проще стать DevOps, чем разобраться в этих визах. Попробуем прояснить, какие существуют визы и контракты для работы в США, и кому какие могут подойти.

Визы: типы и особенности

1. E-3 Visa 🇦🇺 для граждан Австралии.
Кому подходит: специалистам из Австралии, желающим поработать в США по своей специальности.
Длительность: сначала дается на два года, с возможностью неограниченного продления по два года.
Пример: австралийский инженер или DevOps специалист, работающий в крупной компании, может легко продлевать визу без необходимости возвращения домой.

2. TN Visa 🇲🇽 🇨🇦 для граждан Канады и Мексики.
Кому подходит: подходит для определенных профессий, перечисленных в NAFTA USMCA, и доступна гражданам Канады и Мексики.
Длительность: выдается на три года, с возможностью продления.
Пример: канадский Data Scientist, работающий над крупными аналитическими проектами, может получить TN визу и продлевать ее на протяжении нескольких лет.

3. H-1B Visa 🫅для высококвалифицированных специалистов.
Кому подходит: специалистам в области требующих специальных навыков (смотреть ниже ⬇️︎).
Длительность: обычно действует три года, с возможностью продления до шести лет.
Пример: DevOps инженер из Индии может получить H-1B визу, работая на американскую компанию, с перспективой продления до шести лет.

4. EAD 💼 (Employment Authorization Document) для всех подряд.
Кому подходит: этот документ предоставляет право на работу многим категориям, включая супругов H-1B держателей и участников программы DACA.
Пример: супруг специалиста с H-1B визой может работать в США благодаря EAD, что позволяет семье получать два дохода.

5. OPT 🧑‍🎓 (Optional Practical Training) для студентов.
Кому подходит: выпускникам американских университетов по F-1 визе для получения практического опыта.
Длительность: до 12 месяцев, с возможностью продления на 24 месяца для STEM специальностей.
Пример: выпускник по специальности Data Engineering может работать в США по OPT, а затем попытаться получить H-1B визу.

Типы контрактов: C2C и Green Card Process

1. C2C 🤝 (Corp-to-Corp) контракт между компаниями (смотреть следующий пост об этом виде контракта ⬇️︎).
Кому подходит: подходит для специалистов, работающих на себя и желающих быть гибкими в выборе проектов.
Пример: опытный DevOps специалист (я) с собственным LLC (не я) может заключить контракт C2C с американской компанией, выбирая проекты по своему вкусу.

2. GC Process 🟩 (Green Card Sponsorship) путь к ПМЖ.
Кому подходит: подходит тем, кто планирует оставаться в США на долгий срок.
Пример: специалист, работающий на крупную корпорацию, может пройти процесс получения грин-карты через спонсорство компании и стать постоянным жителем США.

—

Дальше будет про H-1B.

H-1B Visa: а я обладаю "специальными" навыками ❓
Справедливый вопрос: какие навыки считаются “специальными” для IT?
В контексте H-1B, под специальными навыками понимаются те, которые сложно заменить без специальных знаний и обучения. Далее несколько направлений, которые подходят под H-1B, но "уникальность" таких знаний для меня под вопросом.

1. Программирование и разработка ПО — владение языками программирования, такими как Java, Python, C++, JavaScript, Go и другие, часто требуется для разработчиков ПО, мобильных приложений, веб-разработчиков и архитекторов систем. Ну ок.
2. Работа с облачными технологиями — навыки работы с AWS, Microsoft Azure, Google Cloud и другими облачными платформами востребованы для инженеров DevOps, архитекторов облачных решений, специалистов по виртуализации и автоматизации инфраструктуры. Ну да, каждый день я уникален.
3. Инженерия данных и аналитика — включает умения работать с Big Data платформами (например, Hadoop, Apache Spark), а также знание языков SQL, R и Python. Эти навыки требуются для data engineers, data scientists, аналитиков больших данных и специалистов по BI (бизнес-аналитика). Ну таких тоже пруд-пруди.
4. Кибербезопасность — специалисты по информационной безопасности должны обладать знанием сетевой безопасности, управлением рисками, и часто сертификациями, такими как CISSP или CEH, чтобы защищать корпоративные данные и инфраструктуру. Тут могу согласиться, стек серьезный.
5. Машинное обучение и искусственный интеллект — знание алгоритмов, математических методов и таких технологий, как TensorFlow, PyTorch, применяется в роли ML-инженеров, специалистов по ИИ и data scientists. Навык хороший, довольно уникален.
6. Разработка и администрирование баз данных — опыт работы с реляционными и NoSQL базами данных, такими как Oracle, MySQL, MongoDB, востребован для администраторов баз данных и backend-разработчиков. Это спрашивают на базовых джуниор интервью.

Так, H-1B в IT-сфере - в чем подвох?
Для получения H-1B визы, работодатель должен подтвердить ☑️, что должность требует специфических технических знаний. На практике это означает, что компания должна обосновать, что вакансия предназначена для высококвалифицированного специалиста с конкретными навыками. Например, позиции DevOps, разработчиков на Java или аналитиков данных должны попадать под эту категорию, так как их функции требуют детальных технических знаний, понимания инструментов и платформ, а также опыта работы с конкретными языками программирования или технологиями.

Каждый из этих вариантов найма и виз предлагает свою степень гибкости, сроков и условий. Например, если вы хотите на долгий срок обосноваться в США, стоит задуматься о процессе получения грин-карты. Если же вам важна свобода выбора проектов, то C2C — отличное решение, но требует финансовой самостоятельности (или грамотного бухгалтера).
—

Дальше будет про C2C.

Работать по Corp-to-Corp (C2C) в США 👔
Интересный вариант, как мне и другим cold-plunger'ам показался. Выглядит как реальный и гибкий вариант для IT-специалистов, особенно если вы планируете работать как независимый консультант или фрилансер на проекты.
C2C контракт заключается между двумя юридическими лицами. Обычно это означает, что у вас есть зарегистрированная компания (например, LLC в Канаде), и вы заключаете договор с американской компанией на выполнение услуг через ваше юридическое лицо, а не как индивидуальный подрядчик.

Основные преимущества C2C
1. Финансовая гибкость 💸: можно получать более высокий доход, так как у вас нет налогов на заработную плату, и вы сами управляете налоговыми обязательствами своей компании.
2. Контроль над проектами и графиком 🛂: C2C контракты предполагают большую независимость в проектной деятельности, и вы можете работать одновременно с несколькими клиентами.
3. Простота доступа к проектам в США 🗽: Поскольку в C2C вы работаете как компания, а не как физическое лицо, американские компании нередко охотнее заключают такие контракты с международными специалистами.

Как подготовиться к работе по C2C
1. Зарегистрировать компанию (LLC) как отдельное юридическое лицо. Это может быть простая корпорация или LLC в Канаде, которая будет выступать стороной договора с клиентом из США. Регистрация корпорации в Канаде достаточно проста и можно ее сделать онлайн.
2. Открыть банковский счет для бизнеса (после регистрации LLC) - это корпоративный счет в банке, чтобы принимать платежи по контракту, избегая смешивания личных и деловых финансов.
3. Оформить договор с американской компанией: После выбора проекта американская компания оформляет контракт с вашей корпорацией. В контракте указываются все условия, включая сроки проекта, оплату и конкретные обязанности вашей компании.
4. Рассмотрите необходимость рабочей визы или поездок в США: Если проект требует регулярных поездок в США, может понадобиться виза TN или B-1 (Business Visitor). Однако, если работа полностью удаленная, виза может не потребоваться, поскольку все операции осуществляются через вашу канадскую компанию.

C2C налоги и финансовые аспекты
- Налоговые обязательства в Канаде 🏦: Вы платите налоги как канадское юридическое лицо и можете вычитать бизнес-расходы (оборудование, программное обеспечение, аренда офиса и т.д.).
- Отчеты для IRS (США) 📝: Так как вы будете eработать с американскими клиентами, возможно, вам потребуется оформить форму W-8BEN-E для подтверждения статуса иностранного юридического лица. Эта форма помогает избежать двойного налогообложения в США, так как Канада и США имеют налоговое соглашение.

Пример
Представим, что вы DevOps инженер в Канаде с собственной компанией. Американская компания предлагает вам контракт на разработку и поддержку CI/CD процессов в своих проектах. Вы заключаете C2C контракт через свою LLC, работаете удаленно, самостоятельно выписываете инвойсы, получаете оплату на корпоративный счет и оплачиваете налоги по канадскому законодательству.
—-

Подытожим
Каждый из этих вариантов найма и виз предлагает свою степень гибкости, сроков и условий. Например, если вы хотите на долгий срок обосноваться в США, стоит задуматься о процессе получения грин-карты. Если же вам важна свобода выбора проектов, то C2C — отличное решение, но требует финансовой самостоятельности.

Persistent Volumes и Persistent Volume Claims в Kubernetes: что к чему? 📦

Начиная работать с Kubernetes нечасто сразу начинаешь думать о storage layer. В продакшене же, работа с датой да еще и в ключе чтобы она "выживала" после рестарта пода — одна из важнейших задач. Сами контейнеры считаются эфемерными: они могут внезапно удаляться и пересоздаваться, и как только это происходит, данные пропадают. Сейчас расскажу про Persistent Volumes (PV) и Persistent Volume Claims (PVC): чем они отличаются и как использовать их эффективно.

Persistent Volume (PV): Хранилище на уровне кластера
PV — это абстракция в Kubernetes, представляющая собой выделенный участок памяти на уровне кластера, который может быть доступен для ваших hello-worldприложений. Чтобы лучше понять, представьте PV как выделенный диск на сервере. Это не просто “пространство”, а управляемый ресурс, который может существовать независимо от подов. PV описываем в манифесте и он может находиться на локальных или внешних хранилищах, таких как NFS, AWS EBS (или любой другой аналог из соседних облаков💭), или даже сетевые диски.

PV — это, по сути, глобально доступный storage, который можно подключать к подам, когда это нужно. Он может быть read-only (чтобы например хранить шаблоны HTML для веб-приложения или ML-модель которая используется разными подами для инференса) или read-write (тут примеры не нужны).

Persistent Volume Claim (PVC): Запрос на хранение данных
Теперь представьте, что ваше приложение — это под, который хочет получить доступ к данным. Вот тут и нужен PVC. Это запрос, который создается на уровне приложения и связывается с PV, если тот соответствует требованиям (размеру, доступности и т.д.). PVC работает как “запрос на доступ к данным” и позволяет подам подключаться к PV, получая таким образом нужное пространство.

PVC как бы говорит: «Эй, Kubernetes, мне нужно столько-то гигабайт пространства, чтобы хранить мои данные, и вот мои требования к доступу». Kubernetes затем связывает этот запрос с подходящим PV, если таковой доступен.

Как это работает вместе? 🤝
Когда приложение нуждается в persistent хранилище, оно создает PVC, а Kubernetes автоматически подбирает подходящий PV или создаёт новый (если используется Dynamic Provisioning). К примеру, если у вас есть Postgres или MySQL под, которому требуется хранение для баз данных, вы создаете PVC на нужное количество гигабайт, и Kubernetes позаботится о том, чтобы связать его с PV, который соответствует запросу. Это делает систему более гибкой - не нужно вручную добавлять диски для каждого нового пода. PVC позволяет разделять заботы об инфраструктуре (создание PV) и приложения (использование PVC).


Вот пример того, как выглядят PV и PVC в Kubernetes YAML-файлах:

# Persistent Volume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/data/example-pv"

# Persistent Volume Claim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

В этом примере мы сначала создаём PV на 10ГБ и указываем, что его можно использовать только с одним подом (ReadWriteOnce). Далее создается PVC, который «просит» доступ к 10ГБ с такими же параметрами доступа, и Kubernetes связывает их автоматически.

Зачем надо понимать низкоуровневые детали хранения данных в Kubernetes?
Некоторые таксистыспрашивают зачем нужно разбираться в таких вещах, как Persistent Volumes и их конфигурация. Неужели вам, как разработчику, нужно понимать все нюансы инфраструктуры, чтобы просто создать pod, или же это можно оставить на усмотрение DevOps/infrastructure engineer? 🔧
На первый взгляд, кажется, что концепция Kubernetes противоречит самой себе, типа Kubernetes стремится абстрагировать инфраструктуру и предоставить единый интерфейс для разработки и управления приложениями. Но в реальности, многие детали инфраструктуры, такие как NFS-сервер, параметры PV, и тому подобные вещи, приходится указывать прямо в манифесте пода. Это делает под зависимым от конкретной инфраструктуры и снижает его переносимость 🤸. Например, если указать в манифесте пода hostname NFS-сервера, этот под не сможет быть развернут без изменений в другом кластере с другой конфигурацией.

...
  volumes: 
  - name: remote-data 
    nfs:
      server: 1.2.3.4
      path: /some/path 
...

К счастью, Kubernetes предлагает способ, который позволяет разделить ответственность за настройку и использование внешних хранилищ между администраторами и разработчиками. Существуют два ключевых уровня:

1. Низкоуровневая настройка хранилища ▿ это область ответственности администраторов кластера. Они настраивают и управляют конкретными PV, решая, как и где будет храниться информация. В этом случае администраторы создают PV и указывают все необходимые параметры (например, конкретный NFS-сервер или параметры для динамического выделения места).
2. Высокоуровневое определение требований △ то, что делают разработчики. Они не указывают точные настройки хранилища, а лишь описывают, какой объем данных требуется их приложению, и какие условия доступа необходимы. С помощью PVC разработчик может просто запросить хранилище нужного размера, с необходимыми правами доступа, а Kubernetes самостоятельно выберет подходящий PV, связав запрос с доступным ресурсом.

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

Подытожим
• PV — это физическое или виртуальное хранилище на уровне кластера, созданное администратором.
• PVC — это запрос на доступ к хранилищу от приложений.
• Автоматизация: благодаря Dynamic Provisioning Kubernetes может автоматически создавать PV на основе PVC, что сильно упрощает управление хранилищем в масштабах.

GitHub репозиторий: Project Based Learning

👾 Сегодня наткнулся на отличный GitHub репозиторий - Project Based Learning. Это целая куча учебных материалов, ориентированных на изучение программирования через проекты. Как по мне, это самый продуктивный подход: сразу работать над реальными задачами и не застревать на скучной теории (которая забывается с вероятностью 101% если ее не подкреплять практикой).

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

Вот несколько разделов и проектов, которые мне показались интересными:

- Web Scraping 🔧: от простых парсеров сайтов с BeautifulSoup до продвинутых решений с Selenium и Scrapy.
- Web Applications 🌐: проекты по созданию блогов и чатов с Flask и Django, а также микросервисов и API.
- Data Science и Machine Learning 🤖: тут можно погрузиться в анализ данных, написать линейную регрессию с нуля или построить рекомендации.
- OpenCV 👀: для тех, кто хочет освоить обработку изображений, есть проекты для сканирования документов, распознавания лиц и даже детектирования фальшивых новостей.
- Deep Learning 🧠: много примеров работы с нейронными сетями — от построения простых CNN до детекторов объектов и масок.
- Miscellaneous 🔮: тут тоже очень много интересного, например, создание интерпретатора, игры «Жизнь», терминальных игр типа «Змейка», и даже построение блокчейна!

Особо хочу выделить проект для начинающих, который сразу привлек мое внимание: Programming Projects for Advanced Beginners #3a: Tic-Tac-Toe AI (ссылка). Это пошаговое руководство по созданию ИИ для крестиков-ноликов, где объясняется не только код, но и логика создания базового ИИ. Прекрасный проект для прокачки навыков и понимания того, как работает алгоритм принятия решений.

Этот репозиторий — просто находка для тех, кто хочет учиться через практику. Советую всем взглянуть, если хотите прокачать навыки программирования! 🚀

Основные новинки GitHub с конференции Universe 2024: что полезно для DevOps.

GitHub Copilot X выходит на новый уровень 🆙
Те, кто уже поработал с GitHub Copilot, могут ждать нечто большее, чем просто автодополнение. Новые функции Copilot X делают его настоящим «умным помощником». Он теперь поддерживает ChatGPT-стиль общения, может анализировать кодовые базы, отвечать на вопросы по репозиторию и даже генерировать pull request’ы. Теперь не нужно прыгать между документацией и кодом, Copilot X может подсказать решения и поможет разобраться с сложными участками кода. Ускоряем разработку и уменьшаем когнитивную нагрузку (trends).

GitHub Code Search — быстрая навигация по коду 🔎
Новая система поиска в коде на GitHub значительно улучшена, позволяя быстрее находить и ключевые файлы, и определенные функции или методы. Code Search теперь может использовать AI-поддержку для выдачи более релевантных результатов, и это облегчает поиск нужных частей в огромных кодовых базах. Для DevOps это означает ускорение работы с многослойными проектами и, конечно, уменьшение времени на понимание кода.

Actions Importer — миграция на GitHub Actions становится проще 📥
Представили инструмент Actions Importer, который упрощает процесс миграции на GitHub Actions. В одном из сових проектов мы используем GitHub Actions, хорошо что переезжать никуда не надо (полгода назад кстати мигрировали из жиры). Теперь, если у вас были пайплайны на других CI/CD системах, вы можете импортировать их в GitHub практически без боли и адаптации. Actions Importer анализирует конфигурации и предлагает оптимизированные варианты миграции. Ок.

Private Repositories для GitHub Pages📄
Добавили возможность использовать приватные репозитории для GitHub Pages. Это даст возможность командам и организациям размещать документацию, ресурсы и прочий контент только для внутреннего пользования. Я сам лично не пользовался этой фичой но знаю кто плотно на ней сидит. Теперь можно создавать и тестировать конфиденциальные проекты, не опасаясь, что информация станет общедоступной. Отличная новость для тех, кто хочет поддерживать свою внутреннюю документацию и ресурсы в безопасности.

GitHub Enterprise расширяет возможности командной работы 🏦
GitHub Enterprise получил несколько обновлений, направленных на улучшение командной работы. Улучшены инструменты аналитики, безопасности и управления пользователями. Нам не сильно важно.

GitHub в 2024 году продолжает развиваться в сторону умного и автоматизированного инструмента, который понимает разработчика и помогает ему на всех этапах работы с кодом. С такими улучшениями работа становится не только эффективнее, но и, как минимум, интереснее.

Деплоил Grafana через Helm: история о том, как yaml формат почти победил меня (но нет) 🛠

Задача была задеплоить Grafana в Kubernetes с использованием Helm. Казалось бы, задача простая: есть готовый чарт, пара строк в values.yaml, и всё должно взлететь. Но сложности начались сразу после того, как я открыл документацию. Давайте погрузимся в моё путешествие от полного хаоса (несколько дней упорного пересобирания образов и чартов) к долгожданному успеху.

Первая попытка: «Сейчас я с корешом GPT все за 5 минут сделаю»
Начал я уверенно: создал values.yaml, прописал ключевые параметры — админские креды, persistence, ingress и так далее:

grafana:
  enabled: true
  adminUser: admin
  adminPassword: admin_password
  ingress:
    enabled: true
    hosts:
      - grafana.example.com

🚀 helm install, и я уже готов был праздновать победу. Но не тут-то было. В логах kubectl я вижу

  •  Readiness probe failed: connection refused
  •  Invalid username or password

Оказывается, Grafana даже не успела нормально стартовать, а логин с admin:admin_password просто не работал.

Разбор полётов: где мои ENV?
Посмотрев на ENV переменные, я понял, что мои adminUser и adminPassword вообще не применились:

kubectl exec -it <grafana-pod> -- env | grep GF_SECURITY_ADMIN
GF_SECURITY_ADMIN_USER=admin
GF_SECURITY_ADMIN_PASSWORD=random_generated_password

WTF?! Почему вместо моего пароля используется какой-то рандомный? 🙃

Вторая попытка: давайте всё начнем сначала исправим
Решил пересмотреть документацию. Скопировал пример values.yaml, добавил existingSecret:

grafana:
  admin:
    existingSecret: grafana-admin
    userKey: admin-user
    passwordKey: admin-password

Создал секрет:

kubectl create secret generic grafana-admin \
  --from-literal=admin-user=admin \
  --from-literal=admin-password=admin_password

Снова helm upgrade, снова фиаско. Grafana всё ещё брала дефолтный секрет, а мои изменения не применялись. Оказалось, что Helm генерирует свой секрет при деплое, и даже с existingSecret он продолжал перезаписывать мои ENV.

Третья попытка: битва с values.yaml

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

enabled: true
adminUser: admin
adminPassword: admin_password

persistence:
  enabled: true
  size: 10Gi

ingress:
  enabled: true
  hosts:
    - grafana.example.com

Финал: всё заработало! 🎉

После правки структуры и ещё одного перезапуска с корректным values.yaml Grafana наконец-то зажила. Логин заработал, readiness-пробы прошли успешно, а я почувствовал себя настоящим победителем.

Выводы:

1. Внимательно следи за структурой values.yaml! Если параметры не в том месте — Helm их просто игнорирует.
2. Доверяй, но проверяй: после каждого деплоя проверяйте ENV и манифесты.
3. Helm — мощный инструмент, но с ним легко запутаться.

Если бы я сразу всё сделал правильно, сэкономил бы часы на деплой. Но зато теперь у меня есть история, как я поборол Helm и Grafana, а также ещё один кейс для блога 😅

ConfigMaps: как отвязать конфигурацию от подов

В Kubernetes одна из ключевых практик — это отделение конфигурации от приложений. Представьте, что у вас есть под, который нужно деплоить в разных окружениях: dev, staging и production. Если в каждой манифесте прописывать уникальные переменные, это превращается в настоящий кошмар. В таких случаях на помощь приходит ConfigMap.

Что такое ConfigMap?

ConfigMap — это объект API Kubernetes, который позволяет хранить пары ключ/значение. Сюда можно поместить строки, файлы или даже целые блоки конфигурации. Поды могут ссылаться на ConfigMap и получать значения переменных, что позволяет одному и тому же поду работать с разными конфигурациями.

Зачем это нужно?

Вы можете использовать один и тот же манифест пода во всех окружениях, подключая к нему разные ConfigMaps. Так конфигурация остается гибкой и централизованной. Подключить ConfigMap можно двумя способами:
• Через переменные окружения, которые подхватывает контейнер.
• Через volume, когда данные из ConfigMap монтируются как файлы.

Создание ConfigMap

ConfigMap можно создать несколькими способами:
1. Из манифеста YAML:

apiVersion: v1
kind: ConfigMap
metadata:
name: kiada-config
data:
status-message: This status message is set in the kiada-config config map

Применяем файл:

kubectl apply -f cm.kiada-config.yaml


2. Через команду kubectl:

kubectl create configmap kiada-config --from-literal=status-message="This status message is set in the kiada-config config map"


3. С использованием файлов:
Если у вас есть конфигурационный файл myconfig.txt, его можно подключить с помощью --from-file:

kubectl create configmap my-config --from-file=myconfig.txt



Команды для работы с ConfigMap

Чтобы посмотреть список всех ConfigMaps, достаточно выполнить:

kubectl get cm

А чтобы увидеть содержимое конкретного ConfigMap в формате YAML:

kubectl get cm kiada-config -o yaml

Совет: Если нужно вывести только данные, используйте jq:

kubectl get cm kiada-config -o json | jq .data

Применение ConfigMap в разных окружениях

Суть в том, что ConfigMap позволяет избежать копипаста манифестов. Вы можете использовать один под-манифест и разные ConfigMaps в dev, staging и production окружениях. Под подключается к конфигурации по имени ConfigMap, и на каждом этапе окружение получает свои уникальные значения.

Итог: меньше ошибок, больше контроля над конфигурацией и чистые манифесты. А главное — DevOps становится чуть более удобным!

Azure Data Studio: Инструмент для работы с данными в стиле DevOps 🤖

В работе с данными на backend кластерах Kusto и SQL для меня было важно выбрать инструмент, который не только позволяет эффективно взаимодействовать с удалёнными серверами, но и упрощает визуализацию и анализ. Для этого я использую Azure Data Studio — и сегодня хочу рассказать, чем он хорош и где его приходится терпеть.

Что нравится? 👍

1. Jupyter-подобные ноутбуки 🪐
Люблю ноутбуки в стиле Jupyter, и Azure Data Studio в этом плане не разочаровывает. Можно удобно комбинировать код, результаты запросов и визуализацию прямо в одном документе. Это особенно полезно, когда нужно быстро протестировать гипотезы или поделиться результатами с командой. Смотрим скриншоты в коментах.

2. Визуализация данных 💡
Иногда сухие цифры говорят меньше, чем хорошо построенный график. ADS предлагает встроенные инструменты визуализации, что позволяет быстро преобразовывать результаты запросов в наглядные диаграммы. Не надо прыгать в Excel или какие-то внешние тулзы.

3. Подключение к удалённым серверам 🌍
Azure Data Studio отлично работает с удалёнными Kusto и SQL серверами. Настроил соединение — и работай без необходимости вручную переключаться между разными инструментами. Это особенно ценно, если вы в DevOps контексте, где оперативный доступ к данным играет ключевую роль.

Что раздражает? 😠

1. Работа с файлами 📁
Вот тут всё довольно странно. Workflow с файлами в ADS оставляет желать лучшего: сохранение и организация документов кажутся неудобными и недостаточно гибкими. У меня каждый раз ощущение, что это могло быть проще, но почему-то приходится мириться с этим “специфическим” подходом.
2. Интеграция с системой контроля версий (CSV) 🔄
Версии и отслеживание изменений в данных — основа современной разработки. ADS поддерживает интеграцию с Git, но всё это реализовано не самым удобным образом. Например, отсутствуют многие привычные мелочи, которые можно встретить в более зрелых IDE. Это замедляет работу, особенно если приходится часто переключаться между ветками или разбираться с конфликтами.

Итог 📝
Несмотря на мелкие недочёты, Azure Data Studio остаётся одним из моих любимых инструментов для работы с данными. Он делает много вещей правильно: от поддержки ноутбуков до удобного подключения к удалённым серверам. Если вы работаете с большими данными в DevOps или просто хотите упростить анализ информации, рекомендую попробовать. А что вы думаете об Azure Data Studio?

Secrets vs ConfigMaps в Kubernetes: когда что использовать?

В мире Kubernetes, где каждый элемент кластера нацелен на безопасность и масштабируемость, хранение чувствительных данных — отдельный челлендж. Сейчас разберёмся в различиях между ConfigMap и Secret, а также когда лучше использовать каждый из них.

Общие черты ConfigMap и Secret

На первый взгляд, ConfigMap и Secret кажутся схожими: оба ресурса Kubernetes хранят пары ключ-значение, которые можно монтировать в контейнеры или использовать как переменные окружения. Тем не менее, они имеют разные цели и особенности.

Основные различия

• ConfigMap используется для хранения некритичной конфигурации, например, параметров приложения или переменных окружения.
• Secret предназначен для хранения чувствительных данных: паролей, токенов и сертификатов. Эти данные кодируются в формате Base64, что помогает минимизировать риски случайно слить этот секрет.

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

Свойство ConfigMap Secret
data Строковые данные Base64-данные
stringData Нет Есть
immutable Поддерживается Поддерживается
type Нет Может быть указан (например, Opaque)

Типы Secret

Secrets поддерживают несколько встроенных типов, которые оптимизированы под определённые задачи:
• Opaque — универсальный тип для любых данных.
• bootstrap.kubernetes.io/token — токены для начальной настройки кластера.
• kubernetes.io/tls — хранение TLS-сертификатов.
• kubernetes.io/service-account-token — токены для сервисных аккаунтов.

Эти типы помогают Kubernetes понимать, как именно использовать секрет.

Когда что использовать?

• Используйте ConfigMap для конфигурационных данных, которые не содержат критичной информации. Например файл .ENV где хранятся параметры вашего питон аппа.
• Используйте Secret для любого чувствительного контента. Даже если данные кажутся безобидными, лучше перестраховаться и хранить их в Secret.

Как всегда, «простые решения для сложных задач» — ваш путь к мастерству в DevOps!

Зарплаты IT-директоров: сколько стоит управлять технологиями? 💸

На днях наткнулся на исследование о зарплатах московских IT-директоров, и цифры, мягко говоря, впечатляют. Говорим о цифрах от 800 тысяч до 2 миллионов рублей в месяц. Да, в месяц. Для сравнения, средний DevOps-инженер получает 200–400 тысяч рублей, а тут уровень космоса. Разбираемся, почему так дорого.

Почему IT-директора получают миллионы? 🍋

1. Ответственность уровня C-level. 🔑
IT-директор — это не просто технарь с навыками управления. Это стратег, который определяет, куда пойдут технологии компании. Один неверный шаг — и ваш бизнес может отстать на годы. От них требуют не только знания Kubernetes и облаков, но и понимание финансов, маркетинга и корпоративных процессов.

2. Конкуренция за таланты. 🎭
Сегодня IT-директоры нужны всем: от банков до ретейла. Те, кто может одновременно держать в голове стратегию цифровой трансформации, управлять командой и понимать, что такое финтех, стоят на вес золота.

3. Рост технологической сложности. 💻
Управлять IT-инфраструктурой в 2024 году — это уже не про «сервер работает, всё в порядке». Компании переходят на гибридные облака, внедряют AI, работают с миллионами запросов в секунду. И кто-то должен этим всем руководить.

Какие навыки ценят? 🤹
В топе требований:
• Технологическая экспертиза. Микросервисы, облака, безопасность, DevSecOps — всё это обязательно.
• Управление командой. Найти подход к каждому, не забывая про дедлайны и бюджеты.
• Бизнес-ориентированность. IT-директор должен говорить с генеральным директором на одном языке.

Куда катится рынок? 💹
Миллионные зарплаты IT-директоров — это индикатор роста важности технологий в бизнесе. Если раньше IT был вспомогательной функцией, то теперь он — двигатель бизнеса. Без грамотного IT-руководства компания теряет не только деньги, но и место на рынке.

Вывод? Растите навыки и смотрите в сторону менеджмента, если хотите войти в этот элитный клуб. А пока — продолжайте изучать Kubernetes и Terraform. Кто знает, возможно, в будущем кто-то из нас станет тем самым IT-директором с зарплатой в 2 миллиона.

Что думаете? Сильно ли нас переоценили или, наоборот, заслужили? Делитесь мыслями в комментариях! 💬

Какой-то очень прорывной момент в смежной отрасли https://youtube.com/shorts/AYX-qJ8CJ5E?si=_2UQp3xz33Z86Jh_

Debugging в Python: так делают только крутые пограммисты 👨‍💻

Когда я работаю с данными в Python, особенно с ответами от API, постоянно возникает ситуация когда print(response) выводит что-то вроде <Response [200]>. Это, конечно, подтверждает, что запрос был успешным, но я остаюсь в полном неведении что внутри полученного ответа. Вот почему дебагинг в Python — это суперсила, которая позволяет вам увидеть больше, копнуть глубже и контролировать процесс.

Пример из реальной жизни 🌿
На скриншоте (в комменте) я работал с объектом response от библиотеки requests. При вызове print(response) я увидел <Response [200]>. Но это ничего не говорит о содержимом. Чтобы разобраться, что там на самом деле, я использовал дебаггер.

Дебаггер позволяет: 🔍
1. Залезть внутрь объекта: Посмотреть, что лежит в response.content, response.json(), или даже response.headers. Вы не просто видите данные, но можете исследовать их структуру.
2. Исполнять методы во время исполнения программы: Например, я могу выполнить response.json() прямо внутри дебаггера, и он покажет мне содержимое JSON в читаемом формате. Это удобнее, чем разбирать строки руками.
3. Навигация по объектам: Вы можете буквально “прогуляться” по ключам и атрибутам объекта, чтобы найти именно то поле, которое вам нужно.

Почему дебагинг — это must have?

- Экономия времени: Вместо того чтобы гадать, что внутри объекта, вы сразу видите его содержимое.
- Интерактивность: Во время исполнения программы вы можете пробовать различные методы или манипуляции с данными.
- Контекст: Вы видите не только то, что хранится в объекте, но и откуда эти данные пришли, как они были обработаны и что с ними можно сделать дальше.

Вот пример, как я использую дебаггер для работы с response:
1. Включаем дебаггер: Например, в PyCharm, я могу установить точку останова на строке, где получаю response.
2. Открываем объект response:
- Поле content показывает байты.
- Поле json() показывает парсированный объект JSON.
3. Извлечение нужных данных: Например, мне нужно response['choices'][0]['message']['content']. Вместо написания кучи print()-ов я просто залез в объект через дебаггер и нашел путь к этому полю.

Вообщем, это не только инструмент для поиска ошибок, но и способ понять, как ваша программа работает. Он помогает экономить время, дает уверенность в том, что вы правильно понимаете данные, и позволяет тестировать гипотезы на ходу. Незаменимая вещь, как по мне!

Почему labels в Kubernetes так важны (но это не сразу очевидно) 🏷

Если вы начинаете знакомство с Kubernetes, то наверняка заметили: в большинстве туториалов уже на первых этапах появляются labels. Чуть ли не сразу после запуска пода или деплоя, авторы рекомендуют добавить к нему пару лейблов, например, app=frontend или tier=backend. Хотя честно, если вы новичок, вряд ли вы сразу поймете, зачем вам это нужно.

Зачем вообще нужны лейблы? 🤔

В Kubernetes labels — это способ добавлять метаданные к объектам, такие как поды, ноды или сервисы. Это своего рода “сопроводительные записки”, которые вы можете клеить на свои ресурсы, чтобы потом проще с ними взаимодействовать. Лейблы не влияют напрямую на поведение объектов, но их сила проявляется, когда вы начинаете работать с selectors. А это важно в следующих случаях:
1. Разделение ресурсов: Например, у вас есть ноды, которые обрабатывают запросы фронтенда, и те, что заняты бекендом. Вы добавляете к ним лейблы:
• role=frontend
• role=backend
Теперь вы можете настроить поды так, чтобы фронтенд запускался только на нодах с role=frontend, а бекенд — на role=backend. Это обеспечивается с помощью Node Affinity или Node Selector.
2. Мониторинг и масштабирование: Лейблы помогают создавать удобные группы объектов для мониторинга и автоматического масштабирования. Например, вы можете группировать поды по app=payments и отслеживать, как нагружается ваша платежная система.
3. Упрощение управления: Когда кластер растет, вам нужно как-то отличать ресурсы друг от друга. Лейблы вроде environment=prod или environment=dev помогают изолировать окружения.

А теперь про новичков

Вот в чем проблема: лейблы полезны только тогда, когда вы понимаете, как ими пользоваться. Если вы только начали изучать Kubernetes, то, скорее всего, ваш первый кластер состоит из пары нод, нескольких подов и одного-двух сервисов. Добавлять лейблы здесь — это как ставить GPS-метки на деревья в собственном саду: вроде можно, но зачем?

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

Пример из жизни

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

apiVersion: v1
kind: Node
metadata:
  name: node1
  labels:
    role: frontend
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  template:
    spec:
      nodeSelector:
        role: frontend

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

Как говорится, не наклеивайте ярлыки, пока не поймете, зачем это нужно. 😉

Слежка за сотрудниками: скотское отношение или новые реалии? 🐑

Наткнулся на обсуждение на Reddit о системах мониторинга сотрудников. Ребята обсуждают как инструменты, созданные для контроля, превращаются в настоящие механизмы подавления. Я знаю, о чем говорю — у меня есть личный опыт работы в условиях подобного тотального контроля.

Современные системы мониторинга: что они делают? 🔍

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

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

Мой опыт: WorkSmart в компании Crossover 🧑‍🔧

Семь лет назад я работал больше двух лет в Crossover — на тот момент одной из самых высокооплачиваемых IT-компаний, предоставлявшей полный remote-формат (что в те времена было настоящей редкостью). Но удаленка приходила с ценой: строгий контроль.

Как это работало?
1. Таймкарты каждые 10 минут
WorkSmart фиксировала вашу активность, создавая таймкарты. Каждая таймкарта включала:
• Клики и нажатия клавиш.
• Список активных приложений с их классификацией на «полезные» (IDE, браузеры с нужными вкладками) и «неполезные».
• Скриншот рабочего экрана в случайное время.
• Селфи через веб-камеру, чтобы убедиться, что вы действительно сидите перед монитором.
2. Оценка продуктивности
Если система считала, что вы выполняли слишком много «неполезных» действий или ваша активность была низкой, таймкарта аннулировалась. А это значит, что время, потраченное на работу, не засчитывалось.
3. Последствия ошибок
Накопление нескольких аннулированных таймкарт грозило вам увольнением. Сначала выдавали предупреждение, но если ситуация не менялась, компания могла расторгнуть контракт.

Больше об этом можно почитать в любой открытой вакансии, например https://www.crossover.com/jobs/4728/ignitetech/ai-first-site-reliability-engineer - Frequently asked questions - How will my productivity be monitored?

Общая проблема: контроль ради контроля

Из Reddit поста, обсуждающие делают вывод что проблема мониторинга выходит за рамки одной компании. Сегодня многие инструменты предлагают работодателям не просто контроль, а тотальное наблюдение за каждым действием сотрудника. Но что важнее: видеть каждую мелочь или получать качественные результаты?
Часто внедрение таких систем говорит не о проблеме с сотрудниками, а о недостатке доверия или плохо выстроенных процессах внутри компании. Если руководитель не умеет ставить задачи и мотивировать команду, никакая система мониторинга не спасет ситуацию.

Мой опыт
Однажды меня почти уволили из-за того, что система неправильно классифицировала приложения, с которыми я работал. Я тратил время на полезные задачи, но WorkSmart решил иначе. Пришлось объясняться, разбираться и доказывать свою правоту. Это было стрессово и отвлекало от реальной работы.
Мой опыт работы с WorkSmart научил меня важной вещи: продуктивность — это не про скриншоты, клики и селфи. Это про доверие, четкие цели и результаты. Технологии мониторинга могут быть полезными, но только если они помогают, а не подавляют. С другой стороны, как профессиональный "троешник" - меня всегда забавляло обходить эту систему. Очевидно, что она было не без багов. С "ностальгией" вспоминаю свои таймкарты на 12 часов с 20 минутами перерыва. Были времена.