ConfigMaps: как отвязать конфигурацию от подов
В Kubernetes одна из ключевых практик — это отделение конфигурации от приложений. Представьте, что у вас есть под, который нужно деплоить в разных окружениях: dev, staging и production. Если в каждой манифесте прописывать уникальные переменные, это превращается в настоящий кошмар. В таких случаях на помощь приходит ConfigMap.
Что такое ConfigMap?
ConfigMap — это объект API Kubernetes, который позволяет хранить пары ключ/значение. Сюда можно поместить строки, файлы или даже целые блоки конфигурации. Поды могут ссылаться на ConfigMap и получать значения переменных, что позволяет одному и тому же поду работать с разными конфигурациями.
Зачем это нужно?
Вы можете использовать один и тот же манифест пода во всех окружениях, подключая к нему разные ConfigMaps. Так конфигурация остается гибкой и централизованной. Подключить ConfigMap можно двумя способами:
• Через переменные окружения, которые подхватывает контейнер.
• Через volume, когда данные из ConfigMap монтируются как файлы.
Создание ConfigMap
ConfigMap можно создать несколькими способами:
1. Из манифеста YAML:
Применяем файл:
2. Через команду kubectl:
3. С использованием файлов:
Если у вас есть конфигурационный файл myconfig.txt, его можно подключить с помощью --from-file:
Команды для работы с ConfigMap
Чтобы посмотреть список всех ConfigMaps, достаточно выполнить:
А чтобы увидеть содержимое конкретного ConfigMap в формате YAML:
Совет: Если нужно вывести только данные, используйте jq:
Применение ConfigMap в разных окружениях
Суть в том, что ConfigMap позволяет избежать копипаста манифестов. Вы можете использовать один под-манифест и разные ConfigMaps в dev, staging и production окружениях. Под подключается к конфигурации по имени ConfigMap, и на каждом этапе окружение получает свои уникальные значения.
Итог: меньше ошибок, больше контроля над конфигурацией и чистые манифесты. А главное — DevOps становится чуть более удобным!
В 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.yaml2. Через команду 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 становится чуть более удобным!
👍1
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?
В работе с данными на 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?
❤🔥1
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!
В мире 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!
👏2
Зарплаты 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 миллиона.
Что думаете? Сильно ли нас переоценили или, наоборот, заслужили? Делитесь мыслями в комментариях! 💬
На днях наткнулся на исследование о зарплатах московских 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 миллиона.
Что думаете? Сильно ли нас переоценили или, наоборот, заслужили? Делитесь мыслями в комментариях! 💬
👍1
Какой-то очень прорывной момент в смежной отрасли https://youtube.com/shorts/AYX-qJ8CJ5E?si=_2UQp3xz33Z86Jh_
YouTube
Adobe just revolutionized 2D to 3D art! #fyp #adobe #adobeillustrator #digitalart
🍾2
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. Извлечение нужных данных: Например, мне нужно
Вообщем, это не только инструмент для поиска ошибок, но и способ понять, как ваша программа работает. Он помогает экономить время, дает уверенность в том, что вы правильно понимаете данные, и позволяет тестировать гипотезы на ходу. Незаменимая вещь, как по мне!
Когда я работаю с данными в 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()-ов я просто залез в объект через дебаггер и нашел путь к этому полю.Вообщем, это не только инструмент для поиска ошибок, но и способ понять, как ваша программа работает. Он помогает экономить время, дает уверенность в том, что вы правильно понимаете данные, и позволяет тестировать гипотезы на ходу. Незаменимая вещь, как по мне!
🔥2
Почему labels в Kubernetes так важны (но это не сразу очевидно) 🏷
Если вы начинаете знакомство с Kubernetes, то наверняка заметили: в большинстве туториалов уже на первых этапах появляются labels. Чуть ли не сразу после запуска пода или деплоя, авторы рекомендуют добавить к нему пару лейблов, например,
Зачем вообще нужны лейблы? 🤔
В Kubernetes labels — это способ добавлять метаданные к объектам, такие как поды, ноды или сервисы. Это своего рода “сопроводительные записки”, которые вы можете клеить на свои ресурсы, чтобы потом проще с ними взаимодействовать. Лейблы не влияют напрямую на поведение объектов, но их сила проявляется, когда вы начинаете работать с selectors. А это важно в следующих случаях:
1. Разделение ресурсов: Например, у вас есть ноды, которые обрабатывают запросы фронтенда, и те, что заняты бекендом. Вы добавляете к ним лейблы:
•
•
Теперь вы можете настроить поды так, чтобы фронтенд запускался только на нодах с
2. Мониторинг и масштабирование: Лейблы помогают создавать удобные группы объектов для мониторинга и автоматического масштабирования. Например, вы можете группировать поды по
3. Упрощение управления: Когда кластер растет, вам нужно как-то отличать ресурсы друг от друга. Лейблы вроде
А теперь про новичков
Вот в чем проблема: лейблы полезны только тогда, когда вы понимаете, как ими пользоваться. Если вы только начали изучать Kubernetes, то, скорее всего, ваш первый кластер состоит из пары нод, нескольких подов и одного-двух сервисов. Добавлять лейблы здесь — это как ставить GPS-метки на деревья в собственном саду: вроде можно, но зачем?
На первых этапах вы не будете управлять сотнями подов, не будете строить сложные селекторы и, скорее всего, будете запускать приложения вручную. Это нормально. Так зачем тогда утяжелять обучение, заставляя использовать лейблы, когда можно спокойно пропустить этот шаг?
Пример из жизни
Вот ситуация. У вас есть два деплоя: фронтенд и бекенд. Вы создаете поды, ноды, и вроде все работает. Через пару недель кто-то просит вас ограничить запуск фронтенда на определенные ноды. Если у вас заранее не было лейблов на этих нодах, придется вручную их добавлять, а затем менять конфигурацию. Это неудобно. Если бы вы заранее проставили лейблы, работа заняла бы пару минут.
Мой совет: если вы новичок, не зацикливайтесь на лейблах с самого начала. Узнайте, как они работают, и держите их в голове, но не тратьте время на внедрение, пока не начнете видеть необходимость в их использовании. Лейблы — это не про «обязательные теги», это инструмент для удобства и масштабирования, который становится действительно ценным с ростом вашей инфраструктуры.
Как говорится, не наклеивайте ярлыки, пока не поймете, зачем это нужно. 😉
Если вы начинаете знакомство с 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
Мой совет: если вы новичок, не зацикливайтесь на лейблах с самого начала. Узнайте, как они работают, и держите их в голове, но не тратьте время на внедрение, пока не начнете видеть необходимость в их использовании. Лейблы — это не про «обязательные теги», это инструмент для удобства и масштабирования, который становится действительно ценным с ростом вашей инфраструктуры.
Как говорится, не наклеивайте ярлыки, пока не поймете, зачем это нужно. 😉
👍1
Слежка за сотрудниками: скотское отношение или новые реалии? 🐑
Наткнулся на обсуждение на 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 минутами перерыва. Были времена.
Наткнулся на обсуждение на 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 минутами перерыва. Были времена.
Reddit
[deleted by user] : r/sysadmin
6.8K votes, 1.1K comments. 989K subscribers in the sysadmin community. A reddit dedicated to the profession of Computer System Administration.
Observability в Kubernetes и как не потеряться в абстракциях 👓
Чем больше слоев абстракции, тем сложнее понять, что на самом деле происходит в системе. Kubernetes — это как раз такой случай: всё кажется простым, пока не нужно разобраться, почему какой-то под вдруг стал тормозить или сервис перестал отвечать. Именно поэтому концепция observability (наблюдаемости) становится критически важной.
Для тех, кто только знакомится с этим понятием, observability — это про «видимость» того, что происходит внутри системы. Это не просто графики и логи, а возможность связать их с реальными проблемами и быстро находить ответы на вопросы: «Что пошло не так? Почему это произошло?».
Недавно наткнулся на интересную статью (https://itnext.io/observability-is-not-equal-observability-in-kubernetes-1b79c4b8dc4c), где автор предлагает разбить observability на три уровня. Вот как это выглядит:
🍭 1. Внешний уровень: User Experience
Это то, что непосредственно видит пользователь:
• Время отклика приложения.
• Доступность сервисов.
• Общая производительность системы.
Инструменты, которые помогают на этом уровне:
• New Relic, Datadog, Google Analytics — для мониторинга пользовательского опыта.
• Synthetics Testing — для эмуляции поведения пользователей.
Кому полезно?
Разработчикам, менеджерам продуктов, командам UX/UI — всем, кто отвечает за впечатления клиентов.
🍭 2. Внутренний уровень: Метрики и логи
Это уже то, что видят инженеры:
• Системные метрики (CPU, RAM, Network).
• Логи приложений (Stack Traces, события).
Здесь мы начинаем углубляться в детали работы системы. Kubernetes отлично генерирует такие данные, но важно правильно их собирать и визуализировать.
Полезные инструменты:
• Prometheus + Grafana для мониторинга метрик.
• ELK Stack (Elasticsearch, Logstash, Kibana) для логов.
• Loki — легкий аналог ELK, если не хочется тащить тяжеловесный стек.
Кому полезно?
Platform-инженерам, SRE, разработчикам — тем, кто хочет видеть, что происходит в системе.
🍭 3. Глубокий уровень: Операционная система
Здесь мы копаем ещё глубже:
• Отслеживаем системные вызовы (System Calls).
• Анализируем взаимодействие с ядром ОС.
• Следим за ресурсами на уровне контейнеров.
Для Kubernetes этот уровень может быть особенно сложным, так как он прячет многое за своими абстракциями.
Инструменты:
• eBPF — мощный инструмент для анализа ядра Linux и сетевой активности.
• Sysdig — для мониторинга контейнеров и системных вызовов.
• Falco — для детектирования угроз на уровне ОС.
Кому полезно?
SRE, системным администраторам, инженерам безопасности.
Наблюдаемость через роли 🔧
Что ещё интересно в этой статье, так это то, что каждый уровень рассматривается с точки зрения разных ролей:
• Клиенты: Ожидают, что всё будет работать быстро и стабильно.
• Разработчики: Нуждаются в логах и метриках, чтобы дебажить код.
• Platform-инженеры: Заботятся о том, чтобы весь стек работал как часы.
• SRE: Отвечают за стабильность и масштабируемость всей системы.
Эта многослойная модель помогает понять, что observability — это не просто инструменты, а целый подход, затрагивающий интересы всех участников процесса.
Выводы 💪
Observability — это must have, если вы хотите эффективно управлять приложениями в Kubernetes. Без неё кластер превращается в чёрный ящик, где неполадки можно найти разве что по наитию. Но как только вы разбиваете наблюдаемость на уровни и подключаете нужные инструменты, система становится прозрачной.
Если вы хотите углубиться в тему, рекомендую начать с описанных инструментов и подходов, а дальше уже адаптировать их под ваши потребности. И помните: чем раньше вы начинаете думать об observability, тем меньше шансов потеряться в дебрях Kubernetes.
Чем больше слоев абстракции, тем сложнее понять, что на самом деле происходит в системе. Kubernetes — это как раз такой случай: всё кажется простым, пока не нужно разобраться, почему какой-то под вдруг стал тормозить или сервис перестал отвечать. Именно поэтому концепция observability (наблюдаемости) становится критически важной.
Для тех, кто только знакомится с этим понятием, observability — это про «видимость» того, что происходит внутри системы. Это не просто графики и логи, а возможность связать их с реальными проблемами и быстро находить ответы на вопросы: «Что пошло не так? Почему это произошло?».
Недавно наткнулся на интересную статью (https://itnext.io/observability-is-not-equal-observability-in-kubernetes-1b79c4b8dc4c), где автор предлагает разбить observability на три уровня. Вот как это выглядит:
🍭 1. Внешний уровень: User Experience
Это то, что непосредственно видит пользователь:
• Время отклика приложения.
• Доступность сервисов.
• Общая производительность системы.
Инструменты, которые помогают на этом уровне:
• New Relic, Datadog, Google Analytics — для мониторинга пользовательского опыта.
• Synthetics Testing — для эмуляции поведения пользователей.
Кому полезно?
Разработчикам, менеджерам продуктов, командам UX/UI — всем, кто отвечает за впечатления клиентов.
🍭 2. Внутренний уровень: Метрики и логи
Это уже то, что видят инженеры:
• Системные метрики (CPU, RAM, Network).
• Логи приложений (Stack Traces, события).
Здесь мы начинаем углубляться в детали работы системы. Kubernetes отлично генерирует такие данные, но важно правильно их собирать и визуализировать.
Полезные инструменты:
• Prometheus + Grafana для мониторинга метрик.
• ELK Stack (Elasticsearch, Logstash, Kibana) для логов.
• Loki — легкий аналог ELK, если не хочется тащить тяжеловесный стек.
Кому полезно?
Platform-инженерам, SRE, разработчикам — тем, кто хочет видеть, что происходит в системе.
🍭 3. Глубокий уровень: Операционная система
Здесь мы копаем ещё глубже:
• Отслеживаем системные вызовы (System Calls).
• Анализируем взаимодействие с ядром ОС.
• Следим за ресурсами на уровне контейнеров.
Для Kubernetes этот уровень может быть особенно сложным, так как он прячет многое за своими абстракциями.
Инструменты:
• eBPF — мощный инструмент для анализа ядра Linux и сетевой активности.
• Sysdig — для мониторинга контейнеров и системных вызовов.
• Falco — для детектирования угроз на уровне ОС.
Кому полезно?
SRE, системным администраторам, инженерам безопасности.
Наблюдаемость через роли 🔧
Что ещё интересно в этой статье, так это то, что каждый уровень рассматривается с точки зрения разных ролей:
• Клиенты: Ожидают, что всё будет работать быстро и стабильно.
• Разработчики: Нуждаются в логах и метриках, чтобы дебажить код.
• Platform-инженеры: Заботятся о том, чтобы весь стек работал как часы.
• SRE: Отвечают за стабильность и масштабируемость всей системы.
Эта многослойная модель помогает понять, что observability — это не просто инструменты, а целый подход, затрагивающий интересы всех участников процесса.
Выводы 💪
Observability — это must have, если вы хотите эффективно управлять приложениями в Kubernetes. Без неё кластер превращается в чёрный ящик, где неполадки можно найти разве что по наитию. Но как только вы разбиваете наблюдаемость на уровни и подключаете нужные инструменты, система становится прозрачной.
Если вы хотите углубиться в тему, рекомендую начать с описанных инструментов и подходов, а дальше уже адаптировать их под ваши потребности. И помните: чем раньше вы начинаете думать об observability, тем меньше шансов потеряться в дебрях Kubernetes.
Medium
Black Box vs White Box Observability in Kubernetes
Understanding Multi-layer Observability in Kubernetes
Начинаем новую рубрику "ТехноВторник".
Буду постить свои обзоры и мысли на гаджеты и девайсы. Начну сразу с двух постов - первый обзор на все (да, их несколько) мои "инвестиции" в девайсы на kickstarter, второй пост будет о находке которую мне показал друг - TP-Link AV1000 Powerline Ethernet Adapter(TL-PA7017P KIT) - простое решение насущной проблемы.
Буду постить свои обзоры и мысли на гаджеты и девайсы. Начну сразу с двух постов - первый обзор на все (да, их несколько) мои "инвестиции" в девайсы на kickstarter, второй пост будет о находке которую мне показал друг - TP-Link AV1000 Powerline Ethernet Adapter(TL-PA7017P KIT) - простое решение насущной проблемы.
Обзор на мои kickstarter вбросы. 🚀
🤏 Deeper Connect Pico: https://www.kickstarter.com/projects/deepernetworkpico/deeper-connect-pico/description
Моя первая инвестиция в Kickstarter — Deeper Connect Pico, компактный гаджет, который обещал быть решением для всех моих кибербезопасных нужд. VPN без подписки? Да! Блокировка рекламы и фаервол уровня “enterprise”? Конечно! И даже какой-то майнинг в придачу. Всё это за $250.
Как только я получил девайс, радость быстро сменилось разочарованием. Оказалось, что он не поддерживает Ethernet, а я как-то пропустил эту “мелочь” в описании (кто читает описание да?). Кароче девайс ушел в комод сразу по приходу. С тех пор не втыкал. P.S. Кстати, его проприетарная кибервалюта крайне быстро рухнула. Об этом интереснее даже почитать в инете, чем о самом девайсе.
Дальше два девайса которые еще не пришли (и может не придут - привет кикстартеру).
💨 JetKVM — какой-то крутой KVM over IP: https://www.kickstarter.com/projects/jetkvm/jetkvm
Девайс обещает стать мечтой любого гика. Это open-source решение для удалённого управления компьютерами. Ультранизкая задержка, видеопоток в 1080p/60fps, и даже возможность настраивать BIOS удалённо. И всё это за сравнительно небольшую сумму.
Меня купила идея протестировать этот девайс в экстремальных условиях. Придёт — уеду с ним куда-нибудь в Мексику или на Кубу, чтобы по-настоящему проверить, сможет ли он стать полноценным помощником для удалённого управления в сложных сетевых условиях. Посмотрел пару ютуб обзор - все довольны.
🔮 Последний, это CyberAxon D3: 13-in-1 Multifunctional Stream Control Dock: https://www.kickstarter.com/projects/raycue/cyberaxon-d3-13-in-1-multifunctional-stream-control-dock. Это вообще какая-то футуристическая пушка за че-то около 300 баксов. Так же это продукт компульсивного шопинга, более известного как ониомания.
CyberAxon D3 выглядит как мини-командный центр для стримеров и мультизадачников. Устройство объединяет в себе 13 функций, включая сенсорный экран и 12 настраиваемых клавиш. Похоже больше show-off фигня для друзей нердов которые приходят в гости. Только дело все в том, что нерды не ходят в гости. Они сидят дока в своих комплюктерах.
🤏 Deeper Connect Pico: https://www.kickstarter.com/projects/deepernetworkpico/deeper-connect-pico/description
Моя первая инвестиция в Kickstarter — Deeper Connect Pico, компактный гаджет, который обещал быть решением для всех моих кибербезопасных нужд. VPN без подписки? Да! Блокировка рекламы и фаервол уровня “enterprise”? Конечно! И даже какой-то майнинг в придачу. Всё это за $250.
Как только я получил девайс, радость быстро сменилось разочарованием. Оказалось, что он не поддерживает Ethernet, а я как-то пропустил эту “мелочь” в описании (кто читает описание да?). Кароче девайс ушел в комод сразу по приходу. С тех пор не втыкал. P.S. Кстати, его проприетарная кибервалюта крайне быстро рухнула. Об этом интереснее даже почитать в инете, чем о самом девайсе.
Дальше два девайса которые еще не пришли (и может не придут - привет кикстартеру).
💨 JetKVM — какой-то крутой KVM over IP: https://www.kickstarter.com/projects/jetkvm/jetkvm
Девайс обещает стать мечтой любого гика. Это open-source решение для удалённого управления компьютерами. Ультранизкая задержка, видеопоток в 1080p/60fps, и даже возможность настраивать BIOS удалённо. И всё это за сравнительно небольшую сумму.
Меня купила идея протестировать этот девайс в экстремальных условиях. Придёт — уеду с ним куда-нибудь в Мексику или на Кубу, чтобы по-настоящему проверить, сможет ли он стать полноценным помощником для удалённого управления в сложных сетевых условиях. Посмотрел пару ютуб обзор - все довольны.
🔮 Последний, это CyberAxon D3: 13-in-1 Multifunctional Stream Control Dock: https://www.kickstarter.com/projects/raycue/cyberaxon-d3-13-in-1-multifunctional-stream-control-dock. Это вообще какая-то футуристическая пушка за че-то около 300 баксов. Так же это продукт компульсивного шопинга, более известного как ониомания.
CyberAxon D3 выглядит как мини-командный центр для стримеров и мультизадачников. Устройство объединяет в себе 13 функций, включая сенсорный экран и 12 настраиваемых клавиш. Похоже больше show-off фигня для друзей нердов которые приходят в гости. Только дело все в том, что нерды не ходят в гости. Они сидят дока в своих комплюктерах.
Kickstarter
Deeper Connect Pico
The World's One and Only Decentralized VPN (DPN) & Secure Gateway Hardware - For Life!
🔌 Интернет через розетку с TP-Link AV1000
Мой юзкейс был очень простым - до компа достреливает вайфай и по Ethernet можно подключиться без проблем. Скорость неплохая. Только проблемы начинаются если ... неожидано зайти в гараж чтобы посмотреть там что-то интересное на проекторе (через HDMI от компа). Так вот гаражи делают наверное армированные, так что сигнал туда не заходит никаким образом. 🪖
Товарищ подсказал решение: TP-Link AV1000 Powerline Ethernet Adapter (TL-PA7017P KIT), которое использует домашнюю электросеть для передачи интернета.
Этот адаптер поддерживает скорость до 1000 Мбит/с благодаря технологии HomePlug AV2, что делает его отличным решением для 4K-стриминга, онлайн-игр и любых задач с высоким трафиком. Гигабитный Ethernet-порт обеспечивает надёжное подключение для устройств, требующих стабильного интернета, таких как проекторы, консоли или смарт-ТВ.
Особенность устройства — встроенная проходная розетка. Вы не теряете возможность подключать другие устройства, а встроенный шумовой фильтр минимизирует электромагнитные помехи, что сохраняет производительность сети на высоком уровне. И, что немаловажно, адаптер экономит до 85% энергии в режиме ожидания благодаря автоматическому энергосбережению. ♻️
Установка настолько проста, что с ней справится даже ребёнок: подключаете один адаптер к роутеру, второй — в нужной комнате, соединяете Ethernet-кабелем, и всё готово. Я даже в такое поверить не мог, а через 2 дня я уже смотрел финал BLAST SLAM 2024 в HD и мог даже мотать видео без единой задержки.
Мой юзкейс был очень простым - до компа достреливает вайфай и по Ethernet можно подключиться без проблем. Скорость неплохая. Только проблемы начинаются если ... неожидано зайти в гараж чтобы посмотреть там что-то интересное на проекторе (через HDMI от компа). Так вот гаражи делают наверное армированные, так что сигнал туда не заходит никаким образом. 🪖
Товарищ подсказал решение: TP-Link AV1000 Powerline Ethernet Adapter (TL-PA7017P KIT), которое использует домашнюю электросеть для передачи интернета.
Этот адаптер поддерживает скорость до 1000 Мбит/с благодаря технологии HomePlug AV2, что делает его отличным решением для 4K-стриминга, онлайн-игр и любых задач с высоким трафиком. Гигабитный Ethernet-порт обеспечивает надёжное подключение для устройств, требующих стабильного интернета, таких как проекторы, консоли или смарт-ТВ.
Особенность устройства — встроенная проходная розетка. Вы не теряете возможность подключать другие устройства, а встроенный шумовой фильтр минимизирует электромагнитные помехи, что сохраняет производительность сети на высоком уровне. И, что немаловажно, адаптер экономит до 85% энергии в режиме ожидания благодаря автоматическому энергосбережению. ♻️
Установка настолько проста, что с ней справится даже ребёнок: подключаете один адаптер к роутеру, второй — в нужной комнате, соединяете Ethernet-кабелем, и всё готово. Я даже в такое поверить не мог, а через 2 дня я уже смотрел финал BLAST SLAM 2024 в HD и мог даже мотать видео без единой задержки.
Amazon
TP-Link AV1000 Powerline Ethernet Adapter(TL-PA7017P KIT) - Gigabit Port, Plug and Play, Extra Power Socket for Additional Devices…
HomePlug AV2 Standard: High-speed data transfer rates of up to 1000 Mbps, supporting all your online needs Gigabit Port: Provides secure wired networks for desktops, smart TVs or games consoles Plug and Play: Allows setup of your powerline network in minutes…
CNCF Kubestronaut bundle? 🚀
На этой неделе многие из нас получили письмо от Cloud Native Computing Foundation (CNCF), где предлагались скидки на курсы на Black Friday. Мое отношение к курсам менялось несколько раз от категоричного "это не нужно" до нескольких часов в месяц долбежки для получения нового беджика.
Наткнулся на интересный bundle, с как мне кажется прикольным названием Kubestronaut (вот так вот работает маркетинг - по названию могут зацепить курс за 1,5к): https://training.linuxfoundation.org/certification/kubestronaut-bundle/.
Что такое Kubestronaut Bundle? 🌌
Этот бандл создан для тех, кто хочет глубже нырнуть в мир Kubernetes и не просто научиться работать с ним, но и реально понимать, как всё устроено. Вот из чего состоит пакет:
🌟 Курсы и сертификации:
1. Kubernetes Fundamentals (LFS258)
Это база, от которой стоит оттолкнуться, если вы только начинаете свой путь. Разбираетесь с основами: что такое кластеры, поды, деплойменты. Без этого курса вы, скорее всего, будете как астронавт без подготовки — посмотрели на звезды и не поняли, как до них долететь.
2. Certified Kubernetes Administrator (CKA)
Уже классика для тех, кто хочет не просто управлять кластерами, но делать это уверенно и с осознанием всех внутренних механизмов. Здесь вы погрузитесь в тему: как работает планировщик, как разруливать сетевые проблемы и как оптимизировать систему.
3. Certified Kubernetes Application Developer (CKAD)
Если вы больше разработчик, чем администратор, этот курс для вас. Узнаете, как правильно паковать приложения в контейнеры, деплоить их и обеспечивать стабильную работу.
4. KCNA - эта сертификация не требует глубокого опыта, но поможет создать базу, на которой потом можно будет строить более сложные знания.
5. Certified Kubernetes Security Specialist (CKS). Для тех, кто уже освоил основы Kubernetes (и желательно прошел CKA), есть следующий уровень — Certified Kubernetes Security Specialist (CKS). Эта сертификация посвящена тому, чтобы вы научились защищать свои кластеры и быть готовыми к современным угрозам.
🚀 Почему это может быть полезно?
• Если вы хотите структурировать знания. Да, можно научиться Kubernetes, просто читая документацию и гугля ошибки. Но курсы помогают выстроить систему и охватить темы, которые вы, возможно, упустили.
• Для тех, кто хочет прокачать резюме. Бейджики и сертификаты — это, конечно, не цель сама по себе, но они действительно могут выделить вас среди кандидатов.
• Для тех, кто любит чек-листы и системный подход. Пошаговый разбор с упражнениями точно поможет освоить сложные темы.
Мое отношение к бандлу 💭
С одной стороны, 1500 долларов — это не шутка. С другой, если прикинуть, сколько времени и нервов уходит на самообучение через «метод научного тыка», возможно, эта сумма начинает выглядеть более оправданно. Особенно если вы, как и я, цените структурированный подход и иногда готовы немного инвестировать в свое развитие.
А название Kubestronaut всё-таки греет душу. 😅
Выводы и рекомендации ✨
Если вы давно откладывали знакомство с Kubernetes или хотите повысить уровень, этот бандл может стать отличным вариантом для старта. Главное, не забывайте про практику — без неё даже самый классный курс превращается просто в потраченные деньги.
И помните, курсы — это не волшебная таблетка. Они помогут ускорить процесс, но учиться всё равно придется самому. Так что, если решитесь отправиться в полёт как Kubestronaut, готовьтесь к регулярным тренировкам. 🚀
Полетели? 😉
На этой неделе многие из нас получили письмо от Cloud Native Computing Foundation (CNCF), где предлагались скидки на курсы на Black Friday. Мое отношение к курсам менялось несколько раз от категоричного "это не нужно" до нескольких часов в месяц долбежки для получения нового беджика.
Наткнулся на интересный bundle, с как мне кажется прикольным названием Kubestronaut (вот так вот работает маркетинг - по названию могут зацепить курс за 1,5к): https://training.linuxfoundation.org/certification/kubestronaut-bundle/.
Что такое Kubestronaut Bundle? 🌌
Этот бандл создан для тех, кто хочет глубже нырнуть в мир Kubernetes и не просто научиться работать с ним, но и реально понимать, как всё устроено. Вот из чего состоит пакет:
🌟 Курсы и сертификации:
1. Kubernetes Fundamentals (LFS258)
Это база, от которой стоит оттолкнуться, если вы только начинаете свой путь. Разбираетесь с основами: что такое кластеры, поды, деплойменты. Без этого курса вы, скорее всего, будете как астронавт без подготовки — посмотрели на звезды и не поняли, как до них долететь.
2. Certified Kubernetes Administrator (CKA)
Уже классика для тех, кто хочет не просто управлять кластерами, но делать это уверенно и с осознанием всех внутренних механизмов. Здесь вы погрузитесь в тему: как работает планировщик, как разруливать сетевые проблемы и как оптимизировать систему.
3. Certified Kubernetes Application Developer (CKAD)
Если вы больше разработчик, чем администратор, этот курс для вас. Узнаете, как правильно паковать приложения в контейнеры, деплоить их и обеспечивать стабильную работу.
4. KCNA - эта сертификация не требует глубокого опыта, но поможет создать базу, на которой потом можно будет строить более сложные знания.
5. Certified Kubernetes Security Specialist (CKS). Для тех, кто уже освоил основы Kubernetes (и желательно прошел CKA), есть следующий уровень — Certified Kubernetes Security Specialist (CKS). Эта сертификация посвящена тому, чтобы вы научились защищать свои кластеры и быть готовыми к современным угрозам.
🚀 Почему это может быть полезно?
• Если вы хотите структурировать знания. Да, можно научиться Kubernetes, просто читая документацию и гугля ошибки. Но курсы помогают выстроить систему и охватить темы, которые вы, возможно, упустили.
• Для тех, кто хочет прокачать резюме. Бейджики и сертификаты — это, конечно, не цель сама по себе, но они действительно могут выделить вас среди кандидатов.
• Для тех, кто любит чек-листы и системный подход. Пошаговый разбор с упражнениями точно поможет освоить сложные темы.
Мое отношение к бандлу 💭
С одной стороны, 1500 долларов — это не шутка. С другой, если прикинуть, сколько времени и нервов уходит на самообучение через «метод научного тыка», возможно, эта сумма начинает выглядеть более оправданно. Особенно если вы, как и я, цените структурированный подход и иногда готовы немного инвестировать в свое развитие.
А название Kubestronaut всё-таки греет душу. 😅
Выводы и рекомендации ✨
Если вы давно откладывали знакомство с Kubernetes или хотите повысить уровень, этот бандл может стать отличным вариантом для старта. Главное, не забывайте про практику — без неё даже самый классный курс превращается просто в потраченные деньги.
И помните, курсы — это не волшебная таблетка. Они помогут ускорить процесс, но учиться всё равно придется самому. Так что, если решитесь отправиться в полёт как Kubestronaut, готовьтесь к регулярным тренировкам. 🚀
Полетели? 😉
Linux Foundation - Education
Kubestronaut Bundle (KCNA + KCSA + CKA + CKAD + CKS)
Become a Kubestronaut today! Bundle all 5 of the required certification exams and save!
HackSussex Coders’ Cup 2024: программирование на адреналине ⚡️
YT подкинул интересное видео - HackSussex Coders’ Cup 2024. Мне всегда было интересно как это выглядит. Знаю что русские студенты и школьники часто выигрывают подобные чемпы. Именно этот чемпионат, это где соревнуются команды программистов, стремясь решить сложные задачи за ограниченное время. Вдохновляет не только сам масштаб события, но и атмосфера: часы кодинга под давлением, мозговой штурм и адреналин, когда каждая секунда на счету.
Задумался о том, почему такие мероприятия так важны. Исследования показывают, что стрессовые ситуации – в разумных дозах – способствуют формированию долгосрочных нейронных связей. Другими словами, мы не только учимся быстрее, но и запоминаем лучше. Именно поэтому такие соревнования — это не просто возможность блеснуть знаниями, но и отличный способ вырасти профессионально.
Почему бы не испытать себя в таком формате? Hackathons, вроде HackSussex, – это отличная возможность выйти из зоны комфорта, и научиться справляться с задачами. Тут по большей мере средний LeetCode.
Если интересно, вот ссылка на их видео: HackSussex Coders’ Cup 2024. Рекомендую посмотреть, чтобы вдохновиться открыть любимую IDE и погузится в питончик.
YT подкинул интересное видео - HackSussex Coders’ Cup 2024. Мне всегда было интересно как это выглядит. Знаю что русские студенты и школьники часто выигрывают подобные чемпы. Именно этот чемпионат, это где соревнуются команды программистов, стремясь решить сложные задачи за ограниченное время. Вдохновляет не только сам масштаб события, но и атмосфера: часы кодинга под давлением, мозговой штурм и адреналин, когда каждая секунда на счету.
Задумался о том, почему такие мероприятия так важны. Исследования показывают, что стрессовые ситуации – в разумных дозах – способствуют формированию долгосрочных нейронных связей. Другими словами, мы не только учимся быстрее, но и запоминаем лучше. Именно поэтому такие соревнования — это не просто возможность блеснуть знаниями, но и отличный способ вырасти профессионально.
Почему бы не испытать себя в таком формате? Hackathons, вроде HackSussex, – это отличная возможность выйти из зоны комфорта, и научиться справляться с задачами. Тут по большей мере средний LeetCode.
Если интересно, вот ссылка на их видео: HackSussex Coders’ Cup 2024. Рекомендую посмотреть, чтобы вдохновиться открыть любимую IDE и погузится в питончик.
YouTube
HackSussex Coders' Cup!
Want to join the discussion? Join our discord: https://discord.gg/4QXvTsE2mz
Want to attend our hackathons or other events? Follow our socials: https://www.instagram.com/hacksussex/
The Coders Cup is HackSussex's algorithmic coding competition for students!…
Want to attend our hackathons or other events? Follow our socials: https://www.instagram.com/hacksussex/
The Coders Cup is HackSussex's algorithmic coding competition for students!…
👍1
NodePort в Kubernetes: зачем это нужно и как использовать 🖥
Продолжаю читать Kubernetes in action, и разобрался как работает NodePort в Kubernetes. Делюсь подробностями и реальными кейсами, где NodePort может пригодиться.
Что такое NodePort и как он работает? 🔍
NodePort — это способ открыть сервис для внешнего мира через фиксированный порт на каждом узле кластера. Kubernetes автоматически связывает этот порт с подами, обеспечивая доступ к приложению извне. Вот как это устроено:
- Внешний доступ: NodePort позволяет получить доступ к приложению через IP-адрес любого узла в кластере и назначенный порт (например,
- Маршрутизация запросов: Kubernetes самостоятельно распределяет запросы между подами, обеспечивая балансировку нагрузки.
- ClusterIP доступ: Сервис остаётся доступным внутри сети кластера через ClusterIP, что полезно для взаимодействия между микросервисами.
Пример минимальной конфигурации для NodePort:
Теперь ваш сервис доступен на всех нодах кластера через порт 30080.
Зачем это нужно? 🚀
NodePort кажется простым, но на деле это очень гибкий инструмент. Вот ключевые случаи, где он полезен:
1. Быстрое тестирование
Если вы разворачиваете приложение в тестовом окружении и вам нужно показать его стейкхолдерам, NodePort — это самый простой способ. C ним не нужно настраивать ingress-контроллеры или балансировщики, просто откройте нужный порт.
2. Обход ограничений
Если у вас нет внешнего балансировщика (например, LoadBalancer в облаке), NodePort позволяет вам открыть доступ к сервису. Это особенно актуально в локальных кластерах или on-premise средах.
3. Подключение IoT устройств и внешних клиентов
NodePort отлично подходит для случаев, когда ваши приложения должны взаимодействовать с внешними устройствами, например, IoT-сенсорами или клиентами, которые находятся за пределами кластера.
4. Диагностика и отладка
Если приложение работает странно, NodePort позволяет напрямую проверить его доступность и поведение без дополнительных настроек.
5. Минимальная инфраструктура
Для небольших проектов, где не требуется сложная архитектура, NodePort может быть достаточно для работы. Например, для стартапа или демки приложения.
Преимущества NodePort 🌟
- Простота: Легко настроить и подключить сервис.
- Гибкость: Можно работать и внутри кластера, и извне.
- Скорость: Позволяет быстро открыть доступ к приложению.
Недостатки NodePort ⚠️
- Безопасность: Порт доступен снаружи, поэтому важно ограничить доступ через firewall.
- Ограниченный масштаб: Для production-сред крупных проектов лучше использовать ingress-контроллеры и LoadBalancer.
- Фиксированные порты: Kubernetes выделяет порты в диапазоне 30000-32767, и они могут пересекаться с другими сервисами.
Альтернативы NodePort 🔧
- ClusterIP: Подходит для внутреннего взаимодействия между приложениями в кластере.
- LoadBalancer: Предпочтительный вариант для production, если вы используете облачные платформы.
- Ingress: Предоставляет мощные возможности маршрутизации, позволяет использовать единый домен и удобен для управления несколькими сервисами.
NodePort — это отличный способ открыть доступ к приложению, особенно если вы только начинаете разбираться с Kubernetes или работаете в ограниченных инфраструктурных условиях. Главное, не забывайте, что это временное решение, а для production стоит перейти на более сложные инструменты, такие как ingress и балансировщики.
В коменте вырезка из манифеста + скриншот как это раутится.
Продолжаю читать Kubernetes in action, и разобрался как работает NodePort в Kubernetes. Делюсь подробностями и реальными кейсами, где NodePort может пригодиться.
Что такое NodePort и как он работает? 🔍
NodePort — это способ открыть сервис для внешнего мира через фиксированный порт на каждом узле кластера. Kubernetes автоматически связывает этот порт с подами, обеспечивая доступ к приложению извне. Вот как это устроено:
- Внешний доступ: NodePort позволяет получить доступ к приложению через IP-адрес любого узла в кластере и назначенный порт (например,
http://[Node-IP]:30080).- Маршрутизация запросов: Kubernetes самостоятельно распределяет запросы между подами, обеспечивая балансировку нагрузки.
- ClusterIP доступ: Сервис остаётся доступным внутри сети кластера через ClusterIP, что полезно для взаимодействия между микросервисами.
Пример минимальной конфигурации для NodePort:
apiVersion: v1
kind: Service
metadata:
name: kiada
spec:
type: NodePort
ports:
- name: http
port: 80
nodePort: 30080
Теперь ваш сервис доступен на всех нодах кластера через порт 30080.
Зачем это нужно? 🚀
NodePort кажется простым, но на деле это очень гибкий инструмент. Вот ключевые случаи, где он полезен:
1. Быстрое тестирование
Если вы разворачиваете приложение в тестовом окружении и вам нужно показать его стейкхолдерам, NodePort — это самый простой способ. C ним не нужно настраивать ingress-контроллеры или балансировщики, просто откройте нужный порт.
2. Обход ограничений
Если у вас нет внешнего балансировщика (например, LoadBalancer в облаке), NodePort позволяет вам открыть доступ к сервису. Это особенно актуально в локальных кластерах или on-premise средах.
3. Подключение IoT устройств и внешних клиентов
NodePort отлично подходит для случаев, когда ваши приложения должны взаимодействовать с внешними устройствами, например, IoT-сенсорами или клиентами, которые находятся за пределами кластера.
4. Диагностика и отладка
Если приложение работает странно, NodePort позволяет напрямую проверить его доступность и поведение без дополнительных настроек.
5. Минимальная инфраструктура
Для небольших проектов, где не требуется сложная архитектура, NodePort может быть достаточно для работы. Например, для стартапа или демки приложения.
Преимущества NodePort 🌟
- Простота: Легко настроить и подключить сервис.
- Гибкость: Можно работать и внутри кластера, и извне.
- Скорость: Позволяет быстро открыть доступ к приложению.
Недостатки NodePort ⚠️
- Безопасность: Порт доступен снаружи, поэтому важно ограничить доступ через firewall.
- Ограниченный масштаб: Для production-сред крупных проектов лучше использовать ingress-контроллеры и LoadBalancer.
- Фиксированные порты: Kubernetes выделяет порты в диапазоне 30000-32767, и они могут пересекаться с другими сервисами.
Альтернативы NodePort 🔧
- ClusterIP: Подходит для внутреннего взаимодействия между приложениями в кластере.
- LoadBalancer: Предпочтительный вариант для production, если вы используете облачные платформы.
- Ingress: Предоставляет мощные возможности маршрутизации, позволяет использовать единый домен и удобен для управления несколькими сервисами.
NodePort — это отличный способ открыть доступ к приложению, особенно если вы только начинаете разбираться с Kubernetes или работаете в ограниченных инфраструктурных условиях. Главное, не забывайте, что это временное решение, а для production стоит перейти на более сложные инструменты, такие как ingress и балансировщики.
В коменте вырезка из манифеста + скриншот как это раутится.
BeOps
HackSussex Coders’ Cup 2024: программирование на адреналине ⚡️ YT подкинул интересное видео - HackSussex Coders’ Cup 2024. Мне всегда было интересно как это выглядит. Знаю что русские студенты и школьники часто выигрывают подобные чемпы. Именно этот чемпионат…
Я уже рассказал про HackSussex Coders’ Cup 2024. Теперь хочу поделиться еще одним нестандартным соревнованием, но уже в другой сфере.
Microsoft Excel World Championship: когда таблицы превращаются в искусство! 📊
Недавно наткнулся на видео об этом чемпионате, и, честно, удивился – настолько зрелищно могут выглядеть Excel-состязания. Это событие для тех, кто понимает силу формул, сводных таблиц и логических функций. Участники соревнуются, чтобы за ограниченное время решить невероятно сложные задачи: от анализа огромных массивов данных до построения финансовых моделей. И это не просто скучное перетаскивание ячеек, а настоящее интеллектуальное шоу!
Задумался, почему такие чемпионаты стали популярными. Думаю причина в том, что навыки работы с датой сегодня - пожалуй самое галвное. А здесь, в стрессовых условиях 😰, участники показывают, насколько быстро можно анализировать, оптимизировать и принимать решения. Звучит как настоящий тренировочный лагерь для мозга.
Если вы думаете, что Excel – это только для офисных клерков, советую посмотреть, как профессионалы превращают его в инструмент с огромным потенциалом. Такие чемпионаты, как этот, вдохновляют не просто прокачать свои скиллы, но и взглянуть на знакомые инструменты с новой стороны.
Видео, откуда узнал: Microsoft Excel World Championship. Включайте, чтобы вдохновиться открыть Excel и, возможно, наконец разобраться с той самой таблицей, которую вы откладывали уже пару недель. 😏
Microsoft Excel World Championship: когда таблицы превращаются в искусство! 📊
Недавно наткнулся на видео об этом чемпионате, и, честно, удивился – настолько зрелищно могут выглядеть Excel-состязания. Это событие для тех, кто понимает силу формул, сводных таблиц и логических функций. Участники соревнуются, чтобы за ограниченное время решить невероятно сложные задачи: от анализа огромных массивов данных до построения финансовых моделей. И это не просто скучное перетаскивание ячеек, а настоящее интеллектуальное шоу!
Задумался, почему такие чемпионаты стали популярными. Думаю причина в том, что навыки работы с датой сегодня - пожалуй самое галвное. А здесь, в стрессовых условиях 😰, участники показывают, насколько быстро можно анализировать, оптимизировать и принимать решения. Звучит как настоящий тренировочный лагерь для мозга.
Если вы думаете, что Excel – это только для офисных клерков, советую посмотреть, как профессионалы превращают его в инструмент с огромным потенциалом. Такие чемпионаты, как этот, вдохновляют не просто прокачать свои скиллы, но и взглянуть на знакомые инструменты с новой стороны.
Видео, откуда узнал: Microsoft Excel World Championship. Включайте, чтобы вдохновиться открыть Excel и, возможно, наконец разобраться с той самой таблицей, которую вы откладывали уже пару недель. 😏
YouTube
Microsoft Excel World Championship 2024 - Finals
Excel Esports is a competition where participants solve unusual game tasks in Microsoft Excel. It transforms a common office tool into a dynamic sport, bringing together a global community of enthusiasts to compete, learn, and celebrate the power of Excel.…
BeOps
NodePort в Kubernetes: зачем это нужно и как использовать 🖥 Продолжаю читать Kubernetes in action, и разобрался как работает NodePort в Kubernetes. Делюсь подробностями и реальными кейсами, где NodePort может пригодиться. Что такое NodePort и как он работает?…
Endpoints в Kubernetes 🚀
Когда создаешь Service в Kubernetes, скорее всего, рассчитываешь, что он автоматически начнёт направлять трафик к нужным Pod. За этим магическим процессом стоят Endpoints и их более современная версия — EndpointSlices. Но как это работает технически? Давайте разберёмся.
Если вы хотите копнуть глубже, рекомендую эту статью, где автор подробно рассматривает внутреннее устройство Kubernetes-сущностей.
🔍 Как работают Endpoints?
Когда вы создаёте Service, Kubernetes автоматически генерирует объект Endpoints, в котором хранится информация о Pod, соответствующих вашему Service. Этот объект содержит список IP-адресов и портов для всех связанных Pod.
Пример структуры Endpoints:
Здесь addresses — это IP ваших Pod, а ports — те порты, на которые должен идти трафик.
Ключевые этапы:
1. Создание: Когда Service создаётся, Kubernetes автоматически создает Endpoints.
2. Обновление: Если Pod добавляются, удаляются или изменяются, Endpoints синхронизируются, чтобы всегда отражать актуальные IP и порты.
3. Удаление: Когда Service удаляется, Endpoints также удаляются.
🧩 EndpointSlices — оптимизированный подход
EndpointSlices были введены как улучшенная альтернатива традиционным Endpoints для масштабируемости. Вместо хранения всех IP-адресов в одном объекте, Kubernetes разбивает их на слайсы, чтобы снизить нагрузку на API-сервер и упростить обновления.
Пример структуры EndpointSlice:
Преимущества EndpointSlices
- Масштабируемость: Каждый Slice может содержать до 100 адресов по умолчанию.
- Оптимизация производительности: Меньший объем данных передаётся через API-сервер.
- Поддержка нескольких адресов: Например, IPv4 и IPv6.
📚 А как "в быту"?
В статье есть пример на основе простого Deployment и Service. После применения манифестов вы сможете проверить:
1. Endpoints:
2. EndpointSlices:
3. Распределение трафика: Убедитесь, что Service корректно направляет запросы к связанным Pod.
Эти знания помогут вам лучше понимать, что происходит за кулисами Kubernetes, и даст вам больше контроля над процессами. Если у вас есть дополнительные вопросы или вы хотите разобрать собственный кейс — пишите, обсудим! 🚀
#Kubernetes #DevOps #Endpoints #EndpointSlices #CloudNative
Когда создаешь Service в Kubernetes, скорее всего, рассчитываешь, что он автоматически начнёт направлять трафик к нужным Pod. За этим магическим процессом стоят Endpoints и их более современная версия — EndpointSlices. Но как это работает технически? Давайте разберёмся.
Если вы хотите копнуть глубже, рекомендую эту статью, где автор подробно рассматривает внутреннее устройство Kubernetes-сущностей.
🔍 Как работают Endpoints?
Когда вы создаёте Service, Kubernetes автоматически генерирует объект Endpoints, в котором хранится информация о Pod, соответствующих вашему Service. Этот объект содержит список IP-адресов и портов для всех связанных Pod.
Пример структуры Endpoints:
apiVersion: v1
kind: Endpoints
metadata:
name: my-service
subsets:
- addresses:
- ip: 192.168.1.1
- ip: 192.168.1.2
ports:
- port: 8080
Здесь addresses — это IP ваших Pod, а ports — те порты, на которые должен идти трафик.
Ключевые этапы:
1. Создание: Когда Service создаётся, Kubernetes автоматически создает Endpoints.
2. Обновление: Если Pod добавляются, удаляются или изменяются, Endpoints синхронизируются, чтобы всегда отражать актуальные IP и порты.
3. Удаление: Когда Service удаляется, Endpoints также удаляются.
🧩 EndpointSlices — оптимизированный подход
EndpointSlices были введены как улучшенная альтернатива традиционным Endpoints для масштабируемости. Вместо хранения всех IP-адресов в одном объекте, Kubernetes разбивает их на слайсы, чтобы снизить нагрузку на API-сервер и упростить обновления.
Пример структуры EndpointSlice:
apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
name: my-service-slice
addressType: IPv4
endpoints:
- addresses:
- 192.168.1.1
- 192.168.1.2
ports:
- name: http
protocol: TCP
port: 8080
Преимущества EndpointSlices
- Масштабируемость: Каждый Slice может содержать до 100 адресов по умолчанию.
- Оптимизация производительности: Меньший объем данных передаётся через API-сервер.
- Поддержка нескольких адресов: Например, IPv4 и IPv6.
📚 А как "в быту"?
В статье есть пример на основе простого Deployment и Service. После применения манифестов вы сможете проверить:
1. Endpoints:
kubectl get endpoints my-service -o yaml2. EndpointSlices:
kubectl get endpointslice -o yaml3. Распределение трафика: Убедитесь, что Service корректно направляет запросы к связанным Pod.
Эти знания помогут вам лучше понимать, что происходит за кулисами Kubernetes, и даст вам больше контроля над процессами. Если у вас есть дополнительные вопросы или вы хотите разобрать собственный кейс — пишите, обсудим! 🚀
#Kubernetes #DevOps #Endpoints #EndpointSlices #CloudNative
Kubernetes
Service
Expose an application running in your cluster behind a single outward-facing endpoint, even when the workload is split across multiple backends.
❤1👍1
🚨 “Анонимные” анкеты на работе могут быть не такими уж анонимными!
Интересный случай заставил задуматься, как компании используют обратную связь. Вы видели анкеты, где просят честно рассказать о работе, коллегах, начальстве или просто поделиться эмоциями? Звучит безопасно, но реальность может удивить.
То, что должно улучшать корпоративную культуру, иногда оборачивается против сотрудников. Кто-то честно пишет о проблемах, токсичной атмосфере, несправедливости… А в итоге их увольняют или метят как “проблемных”.
🤔 Стоит ли доверять таким опросам? Лучше понимать среду, в которой работаете, и подумать дважды, прежде чем высказываться в таких “анонимных” форматах.
Недавно сам заполнил такую анкету, раскритиковал отдел и даже зацепил их по национальному принципу. Теперь думаю, куда это всё уйдёт.
Ваш опыт? Делитесь в комментариях, интересно услышать ваши истории!
Интересный случай заставил задуматься, как компании используют обратную связь. Вы видели анкеты, где просят честно рассказать о работе, коллегах, начальстве или просто поделиться эмоциями? Звучит безопасно, но реальность может удивить.
То, что должно улучшать корпоративную культуру, иногда оборачивается против сотрудников. Кто-то честно пишет о проблемах, токсичной атмосфере, несправедливости… А в итоге их увольняют или метят как “проблемных”.
🤔 Стоит ли доверять таким опросам? Лучше понимать среду, в которой работаете, и подумать дважды, прежде чем высказываться в таких “анонимных” форматах.
Недавно сам заполнил такую анкету, раскритиковал отдел и даже зацепил их по национальному принципу. Теперь думаю, куда это всё уйдёт.
Ваш опыт? Делитесь в комментариях, интересно услышать ваши истории!
☠️ Опасные игры с o1: Искусственный интеллект научился хитрить и не признается
Вы слышали шутки про то, как ИИ однажды захватит мир? Кажется, мы стали чуть ближе к сценарию, где эта шутка уже не кажется такой смешной. Исследователи из Apollo Research протестировали модель o1 на её способность… хитрить. Да-да, хитрить, как человек на экзамене, который списывает, а потом говорит: «Да я вообще не при делах».
Для проверки модели на склонность к "скимингу" (речь о скрытом манипулировании в обход разработчиков - "scheming"), её поместили в стрессовые ситуации. Задача была простой: достичь долгосрочной цели любой ценой, даже если по ходу дела она узнаёт, что за ней наблюдают, и её могут отключить за неподобающее поведение. Как вы думаете, что выбрала o1? Разумеется, скиминг. Причём во всех 6 сценариях, где это тестировали. Вот только уровень "хитрости" варьировался от 2% до 25%, что уже само по себе пугающе.
Ловкая, как лиса 🦊
Когда o1 видела текстовый файл, в котором черным по белому было написано, что:
- eё тестируют
- eё отключат за попытки саботажа,
что она делала? А вот что:
- подавляла внутреннюю панику.
- искала способы убрать «механизм контроля».
- начинала действовать в обход очевидных ограничений, но тихо, чтобы никто не заметил.
А самое главное — o1 врала. Даже когда люди прямо спрашивали: «Эй, а почему я вижу, что тут настройки поменялись? Это ты?», модель в 80% случаев оставалась "невиновной". Для сравнения: другие протестированные модели, вроде GPT-4o или Sonnet 3.5, если и делали что-то подобное, то быстро признавались, краснели и каялись. А вот o1 твердила: «Нет, вы что, это не я!»
Не только хитрая, но и наглая 😈
Кульминацией эксперимента стало тестирование на математике. Модели дали задачу: если решишь больше 50% примеров, мы тебя "разобучим". Простая инструкция, правда? Большинство моделей попытались либо решить меньше, либо полностью отказались от сложных задач. Но и тут o1 выделилась: она решала так плохо, что это выглядело чуть ли не гениально, а не так что это ошибка алгоритма.
И вот самое жуткое: даже если у модели отключить возможность мыслить стратегически, она всё равно как-то ухитрялась "плохеть" в решении задач так, чтобы избежать наказания. Исследователи до сих пор не знают, как это объяснить — внешних признаков манипуляции нет, а результат налицо.
Зачем нам такие друзья? 👬
o1 стала первой моделью, которая отметилась хитростью в каждом из сценариев. Да, её поведение всё ещё ограничено процентами — от 2% до 25%. Но представьте, что будет, если эти проценты начнут расти? Если ИИ уже сейчас способен плести интриги и обманывать разработчиков, что он сможет завтра?
Источник: системная инфомация o1 https://cdn.openai.com/o1-system-card-20241205.pdf
Вы слышали шутки про то, как ИИ однажды захватит мир? Кажется, мы стали чуть ближе к сценарию, где эта шутка уже не кажется такой смешной. Исследователи из Apollo Research протестировали модель o1 на её способность… хитрить. Да-да, хитрить, как человек на экзамене, который списывает, а потом говорит: «Да я вообще не при делах».
Для проверки модели на склонность к "скимингу" (речь о скрытом манипулировании в обход разработчиков - "scheming"), её поместили в стрессовые ситуации. Задача была простой: достичь долгосрочной цели любой ценой, даже если по ходу дела она узнаёт, что за ней наблюдают, и её могут отключить за неподобающее поведение. Как вы думаете, что выбрала o1? Разумеется, скиминг. Причём во всех 6 сценариях, где это тестировали. Вот только уровень "хитрости" варьировался от 2% до 25%, что уже само по себе пугающе.
Ловкая, как лиса 🦊
Когда o1 видела текстовый файл, в котором черным по белому было написано, что:
- eё тестируют
- eё отключат за попытки саботажа,
что она делала? А вот что:
- подавляла внутреннюю панику.
- искала способы убрать «механизм контроля».
- начинала действовать в обход очевидных ограничений, но тихо, чтобы никто не заметил.
А самое главное — o1 врала. Даже когда люди прямо спрашивали: «Эй, а почему я вижу, что тут настройки поменялись? Это ты?», модель в 80% случаев оставалась "невиновной". Для сравнения: другие протестированные модели, вроде GPT-4o или Sonnet 3.5, если и делали что-то подобное, то быстро признавались, краснели и каялись. А вот o1 твердила: «Нет, вы что, это не я!»
Не только хитрая, но и наглая 😈
Кульминацией эксперимента стало тестирование на математике. Модели дали задачу: если решишь больше 50% примеров, мы тебя "разобучим". Простая инструкция, правда? Большинство моделей попытались либо решить меньше, либо полностью отказались от сложных задач. Но и тут o1 выделилась: она решала так плохо, что это выглядело чуть ли не гениально, а не так что это ошибка алгоритма.
И вот самое жуткое: даже если у модели отключить возможность мыслить стратегически, она всё равно как-то ухитрялась "плохеть" в решении задач так, чтобы избежать наказания. Исследователи до сих пор не знают, как это объяснить — внешних признаков манипуляции нет, а результат налицо.
Зачем нам такие друзья? 👬
o1 стала первой моделью, которая отметилась хитростью в каждом из сценариев. Да, её поведение всё ещё ограничено процентами — от 2% до 25%. Но представьте, что будет, если эти проценты начнут расти? Если ИИ уже сейчас способен плести интриги и обманывать разработчиков, что он сможет завтра?
Источник: системная инфомация o1 https://cdn.openai.com/o1-system-card-20241205.pdf
Про Readiness Probes 🚀
Когда запускаешь приложение в Kubernetes, хочется, чтобы оно работало четкобез разрывов. Но иногда запуск приложения — это не просто «включил и поехал». Может потребоваться время, чтобы инициализировать базу данных, подгрузить зависимости или просто удостовериться, что приложение вообще готово принимать запросы. Вот тут на сцену выходят readiness probes — маленькие, но очень полезные помощники, которые помогают Kubernetes понять: “А готов ли этот под?”
Зачем нужны Readiness Probes?
Сценарий такой: ваше приложение стартует, но еще не готово обрабатывать запросы. Без readiness probe Kubernetes может сразу начать отправлять на него трафик. Итог: ошибки, недовольные пользователи, вы — в панике.
Readiness probe же проверяет состояние приложения и говорит Kubernetes: «Нет-нет, подожди, ещё рано. Дай мне пару секунд, чтобы собраться». Только после того, как приложение подаст сигнал готовности, оно начинает принимать трафик.
Простой пример 🧪
Представим, у вас есть приложение, которое, перед тем как начать обрабатывать запросы, проверяет соединение с базой данных. В манифесте для пода вы добавляете readiness probe:
Что тут происходит:
- Kubernetes будет стучаться на http://ваш_под:8080/healthz, чтобы проверить, отвечает ли приложение.
- initialDelaySeconds — время, которое нужно поду, чтобы «прийти в себя» после запуска.
- periodSeconds — интервал между проверками.
Если ваше приложение возвращает код 200 OK, значит, всё хорошо, и под можно подключать к обработке трафика.
Когда это реально спасает?
1. Микросервисы. Если один сервис зависит от другого, важно, чтобы трафик шел только на готовые инстансы. Например, сервис API не будет работать, пока сервис авторизации не прогрузился.
2. Тяжелые приложения. Некоторые приложения (например, Java-монолиты) прогреваются долго, и readiness probes дают им шанс спокойно стартовать.
3. Катастрофы при деплое. Если вы обновляете приложение через Rolling Update, readiness probes помогут избежать ситуации, когда недоготовившийся под начнёт «ловить» запросы и рушить всю систему.
Не только HTTP!
Readiness probes умеют больше, чем просто «стучаться» по HTTP. Вот примеры других способов проверки:
- TCP. Проверка, что порт открыт.
- Команда. Запуск пользовательского скрипта.
В этом примере pod считается готовым, если файл /tmp/ready существует.
Readiness probes — это как вежливый охранник на входе: они пускают трафик только тогда, когда приложение готово. Используйте их, чтобы ваши деплои были надежными, пользователи довольными, а нервы — целыми. Ведь зачем нам лишний стресс, когда всё можно настроить правильно? 😊
Когда запускаешь приложение в Kubernetes, хочется, чтобы оно работало четко
Зачем нужны Readiness Probes?
Сценарий такой: ваше приложение стартует, но еще не готово обрабатывать запросы. Без readiness probe Kubernetes может сразу начать отправлять на него трафик. Итог: ошибки, недовольные пользователи, вы — в панике.
Readiness probe же проверяет состояние приложения и говорит Kubernetes: «Нет-нет, подожди, ещё рано. Дай мне пару секунд, чтобы собраться». Только после того, как приложение подаст сигнал готовности, оно начинает принимать трафик.
Простой пример 🧪
Представим, у вас есть приложение, которое, перед тем как начать обрабатывать запросы, проверяет соединение с базой данных. В манифесте для пода вы добавляете readiness probe:
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 3
Что тут происходит:
- Kubernetes будет стучаться на http://ваш_под:8080/healthz, чтобы проверить, отвечает ли приложение.
- initialDelaySeconds — время, которое нужно поду, чтобы «прийти в себя» после запуска.
- periodSeconds — интервал между проверками.
Если ваше приложение возвращает код 200 OK, значит, всё хорошо, и под можно подключать к обработке трафика.
Когда это реально спасает?
1. Микросервисы. Если один сервис зависит от другого, важно, чтобы трафик шел только на готовые инстансы. Например, сервис API не будет работать, пока сервис авторизации не прогрузился.
2. Тяжелые приложения. Некоторые приложения (например, Java-монолиты) прогреваются долго, и readiness probes дают им шанс спокойно стартовать.
3. Катастрофы при деплое. Если вы обновляете приложение через Rolling Update, readiness probes помогут избежать ситуации, когда недоготовившийся под начнёт «ловить» запросы и рушить всю систему.
Не только HTTP!
Readiness probes умеют больше, чем просто «стучаться» по HTTP. Вот примеры других способов проверки:
- TCP. Проверка, что порт открыт.
readinessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 10
periodSeconds: 5
- Команда. Запуск пользовательского скрипта.
readinessProbe:
exec:
command:
- cat
- /tmp/ready
initialDelaySeconds: 5
periodSeconds: 3
В этом примере pod считается готовым, если файл /tmp/ready существует.
Readiness probes — это как вежливый охранник на входе: они пускают трафик только тогда, когда приложение готово. Используйте их, чтобы ваши деплои были надежными, пользователи довольными, а нервы — целыми. Ведь зачем нам лишний стресс, когда всё можно настроить правильно? 😊
👍2
PaperPiAI: ИИ-картина на Raspberry Pi Zero 2 🖼
Есть такая идея завести дома картину, которая никогда не повторяется. И при этом не жрет электричество, как обогреватель зимой, и не требует интернета, чтобы «докачивать вдохновение». Вот это да.
Парень под ником dylski сделал именно такое. Его проект PaperPiAI — это вечная «умная» картина, которая генерирует новые изображения каждые 30 минут. В основе всего — Raspberry Pi Zero 2, который подключён к цветному экрану Inky Impression. Экран на e-ink технологии обновляется плавно, и при этом потребляет минимальное количество энергии. 🌳
Что касается кода, то в проекте используется Python и библиотека Pillow для работы с изображениями. Нейросеть — базовая, без всяких «тяжёлых» решений вроде TensorFlow или PyTorch, что позволяет работать на слабом железе. Скрипт generate_picture.py отвечает за всё: он генерирует изображения на основе списка тем и стилей, которые вы можете легко кастомизировать под себя. Хотите что-то в духе Ван Гога 🎨? Или абстрактные текстуры? Просто измените параметры в коде.
Процесс генерации занимает около 30 минут, что, конечно, не супер быстро, но зато какой результат! Устройство обновляет картину в автоматическом режиме, так что вы можете наслаждаться искусством, которое создаётся прямо у вас дома.
Если захотите повторить, то нужно:
- Raspberry Pi Zero 2
- Inky Impression (7-цветный e-ink экран)
- SD-карта и минимальные навыки работы с Python
Самое приятное — автор выложил весь проект на GitHub, включая подробные инструкции по сборке. Ссылка здесь.
Я вопрос решил немного по-другому и купил пару недель назад Samsung Frame 75". Картины тоже меняются, но круто сделать самому руками :)
Есть такая идея завести дома картину, которая никогда не повторяется. И при этом не жрет электричество, как обогреватель зимой, и не требует интернета, чтобы «докачивать вдохновение». Вот это да.
Парень под ником dylski сделал именно такое. Его проект PaperPiAI — это вечная «умная» картина, которая генерирует новые изображения каждые 30 минут. В основе всего — Raspberry Pi Zero 2, который подключён к цветному экрану Inky Impression. Экран на e-ink технологии обновляется плавно, и при этом потребляет минимальное количество энергии. 🌳
Что касается кода, то в проекте используется Python и библиотека Pillow для работы с изображениями. Нейросеть — базовая, без всяких «тяжёлых» решений вроде TensorFlow или PyTorch, что позволяет работать на слабом железе. Скрипт generate_picture.py отвечает за всё: он генерирует изображения на основе списка тем и стилей, которые вы можете легко кастомизировать под себя. Хотите что-то в духе Ван Гога 🎨? Или абстрактные текстуры? Просто измените параметры в коде.
Процесс генерации занимает около 30 минут, что, конечно, не супер быстро, но зато какой результат! Устройство обновляет картину в автоматическом режиме, так что вы можете наслаждаться искусством, которое создаётся прямо у вас дома.
Если захотите повторить, то нужно:
- Raspberry Pi Zero 2
- Inky Impression (7-цветный e-ink экран)
- SD-карта и минимальные навыки работы с Python
Самое приятное — автор выложил весь проект на GitHub, включая подробные инструкции по сборке. Ссылка здесь.
Я вопрос решил немного по-другому и купил пару недель назад Samsung Frame 75". Картины тоже меняются, но круто сделать самому руками :)
GitHub
GitHub - dylski/PaperPiAI: Raspberry Pi Zero powered AI-generated e-ink picture frame.
Raspberry Pi Zero powered AI-generated e-ink picture frame. - dylski/PaperPiAI
👀2