Какую функцию выполняет ReplicaSet?

Функция ReplicaSet (RS) в Kubernetes заключается в обеспечении стабильного количества экземпляров подов в кластере. RS является основным компонентом Kubernetes, который используется для развертывания Stateless-приложений. Он обеспечивает непрерывную доступность приложения, автоматически запуская новые экземпляры подов в случае их выхода из строя. Без использования RS такие поды пришлось бы запускать вручную, что затруднило бы поддержание доступности приложения для пользователей.

Что такое пространство имен (namespaces)? Почему не стоит использовать одно namespace для всех приложений?

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

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

Еще один случай, когда несколько пространств имен могут пригодиться, — это ситуация, когда несколько команд работают с одним кластером.

📲 Мы в MAX

#devops #девопс

Подпишись 👉@i_DevOps

Furiko

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

Furiko состоит из следующих компонентов:

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

- CronJob Controller: надёжный планировщик повторяющихся заданий с CRON-подобной семантикой.

- Web UI: удобный пользовательский интерфейс для управления заданиями и их выполнениями.

- CLI: утилита командной строки для взаимодействия с заданиями Furiko.

https://github.com/furiko-io/furiko

📲 Мы в MAX

#devops #девопс

Подпишись 👉@i_DevOps

Устранение проблем с отсутствующими логами Kubernetes в Elasticsearch

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

Я исследовал случай отсутствующих логов Kubernetes в Elasticsearch, который в моем случае агрегирует логи для подов Kubernetes. У меня стандартная настройка Elasticsearch и Fluentd, и время от времени в Elasticsearch появляется пропуск, когда в течение нескольких секунд нет логов.

https://povilasv.me/troubleshooting-missing-kubernetes-logs-in-elasticsearch/

📲 Мы в MAX

#devops #девопс

Подпишись 👉@i_DevOps

📲 Мы в MAX

#devops #девопс

Подпишись 👉@i_DevOps

🛠 Git Cheat Sheet: 12 команд, которые должен знать каждый DevOps

📂 Начало работы

• git init - создаем новый репозиторий. Помните, что это просто создает скрытую папку .git.
• git remote - связываем локальный код с удаленным сервером (GitHub/GitLab).
• Совет: Используйте git remote -v, чтобы проверить, куда вы пушите код.



🔄 Основной цикл (Commit & Sync)

• git add - добавляем изменения в индекс (staging).
• git commit - фиксируем изменения. Пишите осмысленные сообщения! "Fixed bug" - плохо, "Fix: update nginx config for timeout issue" - хорошо.
• git push / git pull - отправка и получение изменений.
• Важно: git pull - это на самом деле fetch + merge.



🌿 Ветвление и слияние

• git branch - работа с ветками. В DevOps мы часто используем feature-branches.
• git checkout - переключение между ветками. (Кстати, в новых версиях Git для этого чаще используют git switch).
• git merge - объединение веток.

🔍 Диагностика и откат

• git status - ваша любимая команда. Показывает, что происходит прямо сейчас.
• git fetch - забирает данные из репозитория, но не меняет ваш локальный код. Безопасный способ проверить обновления.
• git reset - откат изменений.
• ⚠️ Осторожнее с флагом --hard, он удаляет изменения безвозвратно!



💡Лайфхак: Вместо того чтобы вручную проверять статус в каждом проекте, настройте себе алиасы в .bashrc или .zshrc. Например:
alias gs='git status'
alias gl='git log --oneline --graph --all'

#git #devops #cheatsheet #programming #automation


📲 Мы в MAX

Подпишись 👉@i_DevOps

Deckhouse Prom++: мы добавили плюсы к Prometheus и сократили потребление памяти в 7,8 раза

Хотя Prometheus и стал стандартом мониторинга для микросервисов в Kubernetes, он потребляет слишком много ресурсов. А что, если мы скажем, что добавили пару плюсов к Prometheus и получили почти бесплатный мониторинг?

Prometheus для хранения 1 миллиона метрик, собираемых раз в 30 секунд на протяжении 2 часов, требуются 500 МБ на диске и 5 ГБ памяти. Нам показалось, что это слишком много. Вместо этого хотелось получить «бесплатный» мониторинг, который не будет требовать значительных затрат на инфраструктуру.

Больше двух лет мы работали над этой задачей. Её результатом стал Deckhouse Prom++. Это Open Source-система мониторинга, которой в среднем требуется в 7,8 раза меньше памяти и в 2,2 раза меньше ресурсов CPU, чем Prometheus v2.53. И здесь ещё есть пространство для оптимизации.

В статье мы расскажем, как появилась идея Deckhouse Prom++, что уже получилось оптимизировать, какие результаты показывает наше решение по сравнению с Prometheus и VictoriaMetrics, а также о ближайших планах.

https://habr.com/ru/companies/flant/articles/878282/

📲 Мы в MAX

Подпишись 👉@i_DevOps

MLOps — дитя DevOps и ML

Один ML-проект в проде вам или два другому? Внедрение машинного обучения в производственную среду остаётся одной из главных проблем индустрии. По статистике, 80% ML-проектов никогда не доходят до продакшена. Однако хитрые опсы и тут решили выделиться, и в результате появился MLOps — методология, которая поможет вам сократить путь от эксперимента до деплоя с месяцев до дней. В этой статье мы пройдёмся по верхам MLOps и посмотрим на фундаментальные принципы и конкретные инструменты.

https://habr.com/ru/companies/ruvds/articles/990814/

📲 Мы в MAX

Подпишись 👉@i_DevOps

🧪 K8E — это форк проекта K3s, предназначенный для локального тестирования.
Он не требует root-доступа и не использует systemd.
Также вы можете легко собрать и запустить его без сетевого подключения (air-gap режим).

Основные особенности:
- Без root-доступа
- Без systemd
- Один бинарник
- Простой запуск кластера: k8e server &
- Не требует внешней сети
- Поддерживает полностью автономную сборку

Если вы когда-либо хотели поднять Kubernetes-кластер за пару секунд и без привилегий — этот инструмент идеально подойдёт для тестов и локальной разработки.

https://github.com/xiaods/k8e

📲 Мы в MAX

Подпишись 👉@i_DevOps

Собрал основные концепции Docker в одну диаграмму


📲 Мы в MAX

Подпишись 👉@i_DevOps

Zed — это высокопроизводительный текстовый редактор, ориентированный на разработчиков. Он написан на Rust и использует пользовательский движок рендеринга на базе GPU для достижения минимальных задержек. Архитектура Zed основана на многопоточности и асинхронности, что позволяет редактору эффективно использовать ресурсы современных многоядерных систем.

Редактор также разрабатывается с упором на совместную работу в реальном времени: Zed предлагает встроенные функции для коллаборации между разработчиками — от редактирования кода до видеозвонков. Это делает его особенно удобным для удалённых команд.

Среди особенностей:
- Мгновенный отклик и плавная анимация благодаря GPU-рендерингу
- Полноценная поддержка нескольких курсоров и мощное автодополнение
- Интеграция с языковыми серверами (LSP)
- Глубокая коллаборативность: совместное редактирование, общие терминалы, голос и видео

https://github.com/zed-industries/zed

📲 Мы в MAX

Подпишись 👉@i_DevOps

Путь в DevOps: полное руководство для новичков с НУЛЯ

00:00 - Вступление
00:14 - Всевозможные компетенции DevOps Инженера
00:44 - Кому проще стать DevOps Инженером
02:29 - Что учить по минимуму и в каком порядке
10:27 - 1. Основы Networking TCP/IP
11:46 - 2. Администрирование Windows
12:38 - 3. Основы Linux
13:28 - 4. Ansible
13:56 - 5. Git
14:26 - 6. GitHub
14:52 - 7. CI/CD: GitHub Actions, GitLab CI/CD
15:29 - 8. Docker + DockerHub
16:16 - 9. Kubernetes + Helm + ArgoCD
17:04 - 10. AWS: Amazon Web Services
19:12 - 10. GCP: Google Cloud Platform
20:27 - 10. Azure: Microsoft Azure
21:38 - 11. Terraform + Terragrunt
22:42 - 12. Python
23:09 - Как стать профессиональным DevOps Ннженером
24:37 - Девопс это хорошее будущее вашей карьеры

источник

📲 Мы в MAX

Подпишись 👉@i_DevOps

🛠Построение CI/CD-фреймворка MLOps уровня Enterprise (MLflow + Kubeflow)

Разработка MLOps-фреймворка в масштабах предприятия — непростая задача. Она требует интеграции множества компонентов: обработки данных, экспериментов, мониторинга и CI/CD. В этом посте рассказывается, как объединить MLflow, Kubeflow, Seldon Core, GitHub Actions и другие инструменты для построения полноценного MLOps-пайплайна.

Архитектура

Архитектура построена на:

- MLflow — для логирования и управления экспериментами
- Kubeflow Pipelines — для оркестрации пайплайнов
- Seldon Core — для деплоя моделей в Kubernetes
- MinIO — объектное хранилище для артефактов
- GitHub Actions — для CI/CD
- Prometheus + Grafana — мониторинг моделей

Компоненты развернуты в Kubernetes-кластере с использованием Helm.

Поток разработки

1. Подготовка данных — скрипты ETL обрабатывают сырые данные и сохраняют в MinIO.
2. Обучение модели — тренинг происходит в Kubeflow, результаты логируются в MLflow.
3. Тестирование и валидация — автоматизированные проверки модели.
4. CI/CD — GitHub Actions запускает пайплайны при изменении кода или модели.
5. Деплой — модель деплоится через Seldon Core, становится доступной по REST/gRPC.
6. Мониторинг — метрики поступают в Prometheus и отображаются в Grafana.

Преимущества подхода

- Реплицируемость и трассировка экспериментов
- Централизованное хранилище артефактов
- Автоматизация развёртывания моделей
- Мониторинг производительности и дрифта

Заключение

Такой фреймворк обеспечивает устойчивую MLOps-инфраструктуру, подходящую как для небольших команд, так и для крупных корпораций. Он позволяет быстрее и безопаснее доставлять ML-модели в продакшен.

https://rkmaven.medium.com/building-an-enterprise-level-mlops-ci-cd-framework-mlflow-kubeflow-fb1cdd1f74fc

📲 Мы в MAX

Подпишись 👉@i_DevOps

💡 Лучшие практики работы с Helm: что нужно знать

Если вы используете Helm для управления приложениями в Kubernetes, крайне важно следовать ряду проверенных практик, чтобы обеспечить поддержку, масштабируемость и безопасность ваших чартов.

📦 1. Структура директорий чарта
Соблюдайте стандартную структуру чарта Helm:

mychart/
  charts/
  templates/
  values.yaml
  Chart.yaml
  README.md

Избегайте добавления нестандартных файлов и директорий. Это сделает чарты переносимыми и читаемыми.

🧩 2. Разделяйте общие шаблоны
Используйте _helpers.tpl для определения общих шаблонов, таких как аннотации, метки и имена ресурсов. Это снижает дублирование и упрощает сопровождение:

{{/* Генерация полного имени */}}
{{- define "mychart.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

⚙️ 3. Используйте параметры в values.yaml
Делайте чарты гибкими, передавая конфигурации через values.yaml. Никогда не хардкодьте значения в шаблонах.

🧪 4. Валидация values.yaml
Добавляйте проверку обязательных значений с помощью required:

{{ required "Variable mychart.image.repository is required" .Values.image.repository }}

🔍 5. Используйте шаблоны if/else разумно
Старайтесь не перегружать шаблоны логикой. Разделяйте шаблоны на несколько файлов, если они становятся слишком сложными.

🗃️ 6. Не добавляйте чарт в шаблон напрямую
Вместо включения зависимостей в директорию charts/, указывайте их в Chart.yaml и используйте helm dependency update.

🛑 7. Не хардкодьте версии образов
Передавайте версию через values.yaml. Это повышает гибкость CI/CD:

image:
  repository: nginx
  tag: "1.21.1"

🔒 8. Управление чувствительными данными
Не храните пароли и токены в values.yaml. Используйте секреты Kubernetes или инструменты типа Sealed Secrets или External Secrets.

🔁 9. Helm hooks
Helm предоставляет хуки для выполнения задач до/после установки. Используйте их, например, для миграций БД. Пример:

annotations:
  "helm.sh/hook": pre-install

🧹 10. Чистка старых релизов
Используйте helm uninstall и регулярно проверяйте статус релизов с помощью helm list. Это помогает избегать конфликта имён и мусора.

🧪 11. Тестирование чарта
Добавляйте unit-тесты с помощью helm unittest и не забывайте про проверку синтаксиса:

helm lint .

🔄 12. Автоматизация через CI/CD
Интегрируйте Helm в пайплайны CI/CD для установки и обновления чартов — например, с помощью GitLab CI, GitHub Actions, ArgoCD или Flux.


Придерживайтесь этих рекомендаций — и работа с Helm станет надёжной, устойчивой и более предсказуемой. Это особенно важно при масштабировании инфраструктуры и работе в команде.

📲 Мы в MAX

Подпишись 👉@i_DevOps