KubeGateway

Это лучшая практика для управления массивными кластерами kubernetes в ByteDance.

Это прокси 7уровня для балансировки нагрузки, специально разработанный и настроенный для потока HTTP2 для kube-apiserver.

Цель - обеспечить гибкие и стабильные решения по управлению потоками для массивных кластеров kubernetes (более 1 000 нод).

https://github.com/kubewharf/kubegateway

👉 @devops_star

В ближайшие три года рост рынка облачных услуг может составить 36%*

10 апреля в 12:00 (мск) приглашаем на вебинар, где вместе с Rebrain покажем, как облачные сервисы Yandex Cloud упрощают работу с Kubernetes®.

Почему это важно?


Kubernetes в топ-3 самых востребованных навыков в IT-вакансиях 2023–2024. Владение этим инструментом открывает новые карьерные возможности, но в процессе работы часто возникают вопросы: какие сервисы использовать, как избежать ошибок и упростить администрирование?

Что разберем на вебинаре?
✅ Как эффективно работать с Yandex Managed Service for Kubernetes®.

✅ Разбор кейсов и практических сценариев.

✅ Типичные ошибки пользователей и их решение (на демо-стенде).

✅ Лайфхаки для работы с облачными сервисами.

Мероприятие бесплатное, с максимально полезным контентом 👉 Регистрируйся и присоединяйся. Если столько инфы на бесплатном вебинаре, представь, что будет на полном кастомном обучении Kubernetes: Yandex Cloud и Rebrain.

* Результаты исследования «Код Безопасности» и Sk Capital

Bridge to Kubernetes

Добро пожаловать в Bridge-To-Kubernetes! Bridge to Kubernetes расширяет периметр Kubernetes до вашего рабочего компьютера, позволяя вам писать, тестировать и отлаживать код микросервисов, будучи подключенным к кластеру Kubernetes вместе с остальными приложениями или сервисами. Вы можете просто запускать свой код на своей рабочей станции, подключенной к кластеру Kubernetes, что позволит вам тестировать изменения в коде в контексте всего приложения.

https://github.com/Azure/Bridge-To-Kubernetes

👉 @devops_star

🎯 7 терминов, которые обязан знать каждый DevOps-инженер

Разбираем базовые, но важные термины, без которых не построить ни CI/CD, ни нормальный пайплайн. Быстро, по делу:

1. CI (Continuous Integration) — практика регулярной интеграции изменений в основную ветку. Позволяет ловить баги на ранней стадии.

2. CD (Continuous Delivery/Deployment) — автоматизация выкладки приложения. Delivery — до стейджа, Deployment — до продакшена.

3. Pipeline — последовательность шагов (сборка, тесты, деплой), описанных в YAML/JSON или через GUI CI/CD-системы.

4. IaC (Infrastructure as Code) — управление инфраструктурой через код (Terraform, Ansible). Хаоса меньше, стабильности больше.

5. Immutable Infrastructure — инфраструктура, которую не меняют "на лету". Если надо — пересоздают. Так проще масштабироваться и откатываться.

6. Artifact — скомпилированный результат (бинарь, Docker-образ, архив), готовый к деплою.

7. Blue-Green Deployment — техника выкладки, при которой старая и новая версии работают параллельно. Помогает откатываться без боли.

👉 @devops_star

CICD Pipeline | DevOps Tutorial with Project | CI CD Pipeline using AWS | DevOps CI CD Project | K8S

00:00:00 Introduction
00:03:06 Let's use Terraform to create an EC2 instance for Jenkins, Docker and SonarQube
00:17:04 Configure Jenkins
00:24:41 Configure SonarQube and Integrate SonarQube with Jenkins
00:30:07 Create Jenkins Pipeline to Build and Push Docker Image to DockerHub
00:41:24 Create EC2 Instance and Setup Prometheus & Grafana
01:06:59 Setup Email Notification Through Jenkins
01:15:09 Create AWS EKS Cluster
01:22:07 Integrate Prometheus with EKS and Import Grafana Monitoring Dashboard for Kubernetes
01:34:14 Configure the Jenkins Pipeline to Deploy Application on AWS EKS(Kubernetes)
01:42:29 Set the Trigger and Verify the CI/CD Pipeline

источник

👉 @devops_star

Kubegres

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

https://github.com/reactive-tech/kubegres

👉 @devops_star

Стек технологий Netflix (CI/CD пайплайн)

Планирование:
Инженеры Netflix используют JIRA для планирования и Confluence для ведения документации.

Разработка:
Основной язык программирования для backend-сервисов — Java, однако для других задач применяются и другие языки.

Сборка:
Основной инструмент сборки — Gradle. Также разрабатываются собственные Gradle-плагины для поддержки различных кейсов.

Упаковка:
Приложения и их зависимости упаковываются в Amazon Machine Image (AMI) для выпуска.

Тестирование:
Тестирование отражает производственную культуру с акцентом на создание инструментов хаоса (chaos engineering).

Деплоймент:
Для канареечных релизов (canary rollout deployment) используется собственный инструмент Netflix — Spinnaker.

Мониторинг:
Метрики мониторинга централизуются в системе Atlas, а для выявления аномалий применяется Kayenta.

Инциденты:
Обработка инцидентов происходит в зависимости от приоритета, с использованием PagerDuty.

👉 @devops_star

В этом репозитории вы найдете Dockerfile для 13 языков программирования

Для каждого образа Docker имеется свой Dockerfile, содержащий набор инструкций, необходимых для его создания. В этом файле указывается, что должно быть в образе, какие команды, зависимости и процессы он будет содержать.

➖ React
➖ NodeJS
➖ Python
➖ Golang
➖ Java Spring Boot
➖ Java Quarkus
➖ ASP .NET Core
➖ Ruby
➖ Rust
➖ PHP Laravel
➖ Dart
➖ R Studio
➖ Contact

https://github.com/hoalongnatsu/Dockerfile

👉 @devops_star

🚀 Ускоряем сборку Docker-образов: multi-stage build в действии

Если ваш Dockerfile тянет десятки зависимостей и билдится по 10 минут — есть способ ускорить и облегчить финальный образ. Используйте multi-stage build.

📦 Пример:

# Stage 1: сборка приложения
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o main .

# Stage 2: финальный минимальный образ
FROM alpine:latest
WORKDIR /app
COPY --from=builder /app/main .
ENTRYPOINT ["./main"]

💡 Что это даёт:

– из финального образа убираем весь build-мусор
– минимальный размер (тут — alpine, всего ~5 MB)
– меньше уязвимостей = безопаснее
– быстрее выкатывать и проще кэшировать

🔥 Best practice:
Разделяй окружение для сборки и запуска. Всё, что не нужно в проде — оставь в первом этапе.

👉 @devops_star

Kubernetes ConfigMap Reload

Инструмент для перезапуска процессов при изменении файлов, смонтированных из ConfigMap или Secret в Kubernetes.

Этот образ может быть использован в качестве побочного контейнера в одном Pod'е с основным приложением. Он следит за изменениями в указанных файлах (например, из ConfigMap или Secret) и отправляет сигнал (по умолчанию SIGHUP) целевому процессу, чтобы тот мог перечитать конфигурацию без перезапуска контейнера.

Пример использования

...
containers:
  - name: your-app
    image: your-app:latest
  - name: configmap-reload
    image: jimmidyson/configmap-reload:latest
    args:
      - --volume-dir=/etc/config
      - --webhook-method=POST
      - --webhook-url=http://127.0.0.1:9090/-/reload
    volumeMounts:
      - name: config
        mountPath: /etc/config
...

https://github.com/jimmidyson/configmap-reload

👉 @devops_star

#vacancy #DevOps #fulltime #вакансия #москва

DevOps

Локация: Москва
ЗП: 200к-350к net
Занятость: Полная, Гибридный формат
Оформление: ТК РФ
Компания: Федеральное Медико-биологическое агентство

ЦСП ФМБА занимается научными исследованиями связанными с геномом человека и анализом полученных данных.
Группа разработки создает внутренние сервисы для автоматизации движения, обработки и распределенного хранения больших объемов данных.

Требования:

•Опыт работы с Kubernetes обязателен
•Уверенные знания Linux, систем виртуализации и контейнеризации
•Опыт реализации CI/CD, большой опыт работы с Ansible и Git
•понимание работы web-серверов, балансировщиков и брокеров сообщений (на примере Nginx, Kafka)
•Понимание работы сетей и распределенных систем
•Опыт настройки и использования систем мониторинга: Zabbix, Grafana, Prometheus, ELK Stack
•Понимание процессов ITSM
•Законченное высшее образование


Чем предстоит заниматься:

•Настройка и последующая поддержка процессов CI/CD внутренних и публичных сервисов в различных окружениях
•Обеспечение непрерывной работоспособности и доступности сервисов
•Мониторинг систем, оптимизация производительности приложений и инфраструктуры, траблшутинг
•Настройка и управление Kubernetes
•Документирование процессов и систем
•Выстраивание процессов работы с командой разработки, командой данных, системными администраторами, Service Desk

Стек:
•Ubuntu, ALT Linux, Oracle
•Git, Gitlab-CI, Ansible, Terraform, Molecule
•Docker, Kubernetes
•Nginx, Haproxy, Traefik, Hashicorp Vault, MinioS3, Harbor, Consul, Postgres, Mariadb, Kafka
•Grafana, ELK, Prometheus, Loki, Victoria Metrics, Zabbix
•Bash, Python

Мы предлагаем:

•Оформление по ТК РФ.
•Работа в команде профессионалов на стыке передовых ИТ и науки. Мы работаем с Big Data и ML, у нас собственный корпоративный ЦОД.
•Только современное оборудование для рабочих мест.
•Прикрепление к корпоративной поликлинике.
•Возможность профессионального роста, обучение.
•График работы 5/2, гибрид, плавающее начало рабочего дня

Резюме отправлять: @ddsh_kl

Автоматическое обновление зависимостей в GitLab-проектах с помощью Renovate

Автоматическое обновление зависимостей становится все более важным аспектом в процессах непрерывной интеграции и непрерывной доставки (CI/CD) в сфере разработки программного обеспечения. В статье описана настройка автоматического обновления зависимостей в GitLab-проектах с помощью Renovate.

https://habr.com/ru/companies/magnit/articles/793470/

👉 @devops_star

🔐 Infisical — открытая платформа для управления секретами​

Infisical — это современный open-source инструмент для безопасного хранения и управления секретами, такими как API-ключи, пароли и конфигурации приложений. Он предлагает централизованное хранилище с удобной панелью управления, поддержкой версионирования, автоматической ротацией и интеграцией с популярными инструментами разработки и CI/CD, включая GitHub Actions, Terraform и Kubernetes.​

Платформа также включает в себя возможности управления внутренним PKI, позволяя создавать и управлять сертификатами X.509, а также автоматизировать их обновление в Kubernetes. Infisical доступен как в виде облачного сервиса, так и для самостоятельного размещения.​

https://github.com/Infisical/infisical

👉 @devops_star

Устанавливаем кластер Kubernetes в LXC-контейнерах Proxmox

Если вы когда-либо разворачивали Kubernetes-кластер на виртуальных машинах (ВМ), то знаете, насколько это может быть ресурсоёмко. Особенно это ощущается на одноплатных компьютерах вроде Orange Pi 5 Plus, даже несмотря на его 16 ГБ оперативной памяти. Для домашнего лабораторного стенда или лёгкой продакшн-инфраструктуры хочется чего-то более лёгкого и быстрого.

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

На практике это означает, что в контейнеры LXC можно «упаковать» больше узлов Kubernetes, чем в ВМ, особенно на ограниченном по ресурсам железе.

https://habr.com/ru/articles/901260/

👉 @devops_star

Создаём виртуальную сеть, как это делает Docker

Как известно, Docker умеет создавать виртуальные сети для безопасного и удобного сетевого взаимодействия внутри контейнеров. В этой статье мы рассмотрим, как именно он это делает на примере базовых манипуляций с сетью в рамках одного хоста с операционной системой Linux.

https://habr.com/ru/articles/794262/

👉 @devops_star

Резервное копирование и восстановление контейнеров с помощью API контрольных точек Kubernetes

В версии Kubernetes v1.25 в качестве альфа-функции был представлен API проверки контейнеров (Container Checkpointing API). Она позволяет создавать резервные копии и восстанавливать контейнеры, запущенные в подсистемах, без их остановки.

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

https://martinheinz.dev/blog/85

👉 @devops_star

DevOps-Bash-tools

Более 1000 сценариев оболочки DevOps и расширенная среда Bash.
Быстрая, продвинутая системная инженерия, автоматизация, API, более короткие CLI и т.д.
Широко используется во многих репозиториях GitHub, десятках сборок DockerHub (Dockerfiles) и 600+ сборках CI.

1000+ DevOps Bash Scripts - AWS, GCP, Kubernetes, Docker, CI/CD, APIs, SQL, PostgreSQL, MySQL, Hive, Impala, Kafka, Hadoop, Jenkins, GitHub, GitLab, BitBucket, Azure DevOps, TeamCity, Spotify, MP3, LDAP, Code/Build Linting, pkg mgmt for Linux, Mac, Python, Perl, Ruby, NodeJS, Golang, Advanced dotfiles: .bashrc, .vimrc, .gitconfig, .screenrc, tmux..

https://github.com/HariSekhon/DevOps-Bash-tools

👉 @devops_star

Строим CI/CD. Что такое Continuous integration, Continuous delivery, Continuous deployment

Что такое Continuous integration, Continuous delivery, Continuous deployment? Непрерывная интеграция, непрерывная доставка и непрерывное развертывание? Эти вопросы часто задают на собеседованиях DevOps. Эта практика применима в SRE. Да и чтобы построить идеальный CI/CD без теории никуда.

00:00 - Continuous integration и Continuous delivery
01:01 - Акции и розыгрыши от FirstVDS
02:53 - О чем CI/CD?
03:19 - Основные принципы CI/CD
04:29 - Этапы разработки CI/CD
05:46 - Чем отличается непрерывная интеграция, непрерывная доставка и непрерывное развертывание?
07:11 - Рассмотрим CI/CD на простом примере

источник

👉 @devops_star

Kubernetes: 5 продакшен-настроек, которые спасут ваши нервы

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

1. Настройте PodDisruptionBudget (PDB)
Без PDB кластер-автоапдейты или масштабирование могут случайно снести все поды вашего сервиса. Обязательно задайте minAvailable или maxUnavailable, чтобы контролировать, сколько подов можно уронить.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: my-app-pdb
spec:
minAvailable: 2
selector:
matchLabels:
app: my-app


2. Лимитируйте ресурсы подов (requests и limits)
Без лимитов одно неудачное приложение может заддосить весь нод. Обязательно указывайте resources в манифестах.

resources:
requests:
cpu: "200m"
memory: "512Mi"
limits:
cpu: "500m"
memory: "1Gi"


3. Включите livenessProbe и readinessProbe
Без них Kubernetes не сможет корректно понимать, когда приложение мертво или еще не готово к трафику. Лишние 10 строк YAML могут спасти тысячи пользователей.

livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 15
timeoutSeconds: 5
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
timeoutSeconds: 3


4. Логируйте правильно
Никогда не пишите логи в файл внутри контейнера! Используйте stdout/stderr, чтобы всё шло через стандартные механизмы логирования кластера (например, через Fluentd или Loki).

5. Сетевые политики (NetworkPolicy)
Открытый по умолчанию трафик внутри кластера — угроза безопасности. Настройте NetworkPolicy, чтобы явно разрешать трафик между подами.

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

👉 @devops_star

Что такое платформенная инженерия: как она связана с DevOps и SRE?

Появление новых ролей и обязанностей в IT и разработке сильно повлияло на работу современных компаний. Одно из направлений, которое с каждым годом становится популярнее, — платформенная инженерия. В этой статье разберемся, что это такое, почему важность ПИ растет и какое отношение она имеет к DevOps и SRE (Site Reliability Engineering).

https://habr.com/ru/companies/agima/articles/793922/

original https://www.harrisonclarke.com/blog/what-is-platform-engineering-how-does-it-compare-with-devops-and-sre

👉 @devops_star

Как мы управляем инфраструктурой на более 1000 серверов при помощи Ansible

Мы системные инженеры X5 Tech — Алексей Кузнецов и Борис Мурашин. У нас за плечами больше 15 лет опыта, в том числе поддержка сервисов Rapida, CyberPlat, TeleTrade, сопровождение стека BigData и внедрение кластеров Hadoop.

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

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

https://habr.com/ru/companies/oleg-bunin/articles/788552/

👉 @devops_star