Mops DevOps - Kubernetes Docker

Контейнеры в одном инструменте, виртуалки — в другом, частное облако — вообще отдельная история со своей командой и своим бюджетом. На практике границы между ними давно стёрлись. Монолиты работают в виртуальных машинах, микросервисы — в контейнерах, часть инфраструктуры — на собственном железе, часть — в облаке. Каждый кусок требует своего набора инструментов и своих правил доступа. Deckhouse Platform собирает всё это под одним управлением. Контейнеры, виртуальные машины, ML-нагрузки и управляемые сервисы работают на любой инфраструктуре, без привязки к одному провайдеру. Сейчас так работают 1300+ кластеров в 260+ компаниях. На консультации с инженерами Deckhouse разберите, какие из ваших сценариев платформа закрывает уже сейчас 👈

VictoriaLogs в Kubernetes: от установки до практического применения Руководство по развёртыванию и использованию VictoriaLogs в Kubernetes. Документ фокусируется на практических шагах: установка через Helm, интеграция с cert-manager и Ingress, генерация логов, примеры запросов в LogsQL и интеграция с экосистемой наблюдаемости. 👉 Ссылка скрыта #VictoriaLogs

Grafana Operator — дорога к IAC или путь в никуда? Услышав про Grafana Operator, я, окрыленный надеждами, пошел к нему за решением. Но у Grafana Operator оказалось свое представление о деплое, о провижининге и о том, как он вообще должен работать. 👉 Ссылка скрыта #grafana

Прощай, Ingress. Здравствуй, Gateway API Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes. Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress. Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой. 👉 Ссылка скрыта #kubernetes

Братцы! С Новым годом! Пусть праздники пройдут без инцидентов! Набирайтесь сил!!! 🎄🎄🎄

Перенос кластера kubernetes на другие ip адреса Предположим, вам необходимо мигрировать ваш кластер k8s в другой vlan или просто сменить ip адреса. Насколько это необходимо каждый решает сам. Будем считать, что перенос нагрузки ямлами на другой кластер затруднён или у кластера специфические настройки. В качестве начальных условий: кластер on prem с root доступом на узлы, установлен через kubeadm или kubespray, в качестве cni calico. В нашем случае под ногами ubuntu в качестве системы. Если у вас кластер установлен the hard way , то статья вам не нужна, вы сами всё умеете. 👉 Ссылка скрыта #kubernetes

Архитектурный квиз: костыль или элегантное решение? Отказоустойчивый и масштабируемый энтерпрайз невозможно спроектировать по книжкам. Одно и то же решение может фигурировать и в best, и в bad practice — и, что забавно, иногда переходит из одного списка в другой. Ещё недавно монолиты считались злом, а теперь снова в моде. Хотите посмотреть, как знакомые паттерны ведут себя в реальном контексте? Чтобы показать это на практике, я собрала три инженерных кейса. Каждый оформлен в формате детективного квиза: роль, фабула, вопросы на размышление, разбор и выводы. Попробуйте разобраться в проблеме, пройти тест и определить: где костыль, где инженерный компромисс, а где — настоящая best practice. 👉 Ссылка скрыта

Сравнение числа ошибок в коде, написанном людьми и AI Исследователи из компании CodeRabbit проанализировали 470 pull-запросов (350 - созданные AI, 150 - написанные вручную) в открытых проектах на GitHub и пришли к выводу, что в изменениях, сгенерированных AI-ассистентами, присутствует в 1.7 раза больше значительных дефектов и в 1.4 раза больше критических проблем, чем во вручную написанном коде. В среднем в сгенерированных через AI pull-запросах присутствовало 10.83 проблем, в то время как в созданных вручную изменениях данный показатель составил 6.45. 👉 Ссылка скрыта #ai

Не runc’ом единым: интересные среды запуска контейнеров Существует множество сред для запуска контейнеров; среди распространенных можно выделить runc и kata. Мы в Beeline Cloud решили поговорить не только о широко известных, но и о набирающих свою аудиторию рантаймах. В подборке: проект, который окрестили «Docker’ом на диете»; система, заточенная под unikernel; среда для работы на устройствах с ограничениями по памяти и не только. Все они имеют лицензию Apache-2.0. 👉 Ссылка скрыта #containers