Kubernetes *

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

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

Я продолжаю цикл статей по приручению домашнего сервера разработчика, который хочет уметь в DevOps. В первой своей статье я рассказал о развёртывании Xen Project гипервизора и миграции Windows-виртуалок из Hyper-V. Во второй о развёртывании на базе виртуалок этого сервера Kubernetes-кластера. Перед написанием данной я ставил перед собой следующие цели:

1. Развернуть тестовый сайт, состоящий из статических ресурсов и front-end API в vanila Kubernetes-кластере.

2. Обеспечить доступ к этому сайту с использованием NGINX Ingress Controller.

3. Сайт должен быть доступен по HTTPS-протоколу с автоматически обновляемым TLS-сертификатом Let’s Encrypt.

Как известно, системные администраторы делятся на 3 категории - кто еще не делает резервные копии, кто уже делает и кто уверен, что из них можно восстановиться. В нашу эпоху DevOps вопрос автоматизации управления резервным копирования стал еще более актуальным, поскольку каждая система предлагает свой уникальный способ создания (и восстановления) дампа и даже в пределах одной системы может быть множество разных способов хранения данных. В этой статье мы обсудим возможные стратегии и доступные технологические решения для создания резервных копий данных для развертываний в Kubernetes и поговорим о возможностях автоматизации и мониторинга процесса резервного копирования.

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

Это перевод статьи Дмитрия Костика и Миколы Моржан из Percona. С их помощью посмотрим, в какой степени можно автоматизировать горизонтальное масштабирование баз данных MongoDB, MySQL и PostgreSQL в Kubernetes и как это сделать?

В этой статье мы рассмотрим новый экспериментальный режим совместной работы Open Source-утилиты werf и инструмента для непрерывной доставки Argo CD, объединяющий в себе возможности и удобства обоих проектов в рамках одного CI/CD-процесса. Сейчас идет активная разработка этих возможностей werf, но в первом приближении функционал уже доступен и готов к использованию.

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

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

Немецкая компания SUSE известна в Open Source-сообществе своими дистрибутивами Linux. Но этим ее деятельность не ограничивается. В конце прошлого года SUSE представила новый проект с открытым кодом — гиперконвергентное решение Harvester. Как говорит компания, Harvester — это альтернатива существующим гиперконвергентным платформам enterprise-уровня типа VMware vSAN и Nutanix HCI, адаптированная к cloud native-среде, к тому же полностью бесплатная.

В статье сделаем небольшой обзор Harvester: посмотрим на компоненты, возможности, сильные и слабые стороны.

Писать, собирать, агрегировать и сохранять логи для последующего анализа важно: это наиболее подробное представление того, как работает система.

Логи можно собирать и отправлять в централизованную систему по-разному, например используя библиотеки в самом приложении или сторонние агенты вроде Filebeat, Fluent Bit, Vector. Есть множество систем хранения вроде Elasticsearch, Loki, Splunk, файлы на диске или объекты в S3.

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

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

Дано: домашний сервер под управлением Debian 11 с установленным гипервизором Xen.

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

Развёртывание Debian и Xen, а также миграция с Hyper-V на Xen нескольких Windows-виртуальных машин описана в моей статье Миграция домашнего сервера с Hyper-V на Xen Project на Debian. В ней также описана конфигурация моей сети.

В данной статье я исхожу из того, что читатель имеет представление о том, что такое Kubernetes, как он работает, из каких компонентов состоит и знаком с необходимой терминологией. Многие идеи и код я брал из статьи Разворачиваем среду для работы с микросервисами. Часть 1 установка Kubernetes HA на bare metal (Debian), но местами адаптировал под свои нужды и окружение. Задача данной статьи дать читателям готовое решение, требующее минимальных усилий для повторения и, вместе с тем, не требующее дополнительных инструментов (вроде Ansible или Terraform), а также показать новичкам некоторые моменты работы с Linux, Kubernetes и используемыми пакетами. Повествование разбито на несколько шагов, каждый из которых заключается в запуске скрипта и нескольких ручных командах.

Кажется это уже стало традицией: каждый раз, когда я выхожу на новое рабочее место, моя деятельность начинается с бенчмарков различных SDS-решений. Мой приход во «Флант» не стал исключением. Я попал в команду разработки Kubernetes-платформы Deckhouse, где решили развивать возможность запуска виртуальных машин в Kubernetes. Но для этого сначала потребовалось найти простое и надежное хранилище блочного типа, которое можно предложить клиентам платформы.

Я взял несколько свободных решений и протестировал, как они поведут себя в тех или иных условиях. В первую очередь интересовала производительность DRBD в различных конфигурациях и сравнение с Ceph.

Но рынок программно-определяемых хранилищ не стоит на месте и постоянно растёт. Появляются новые амбициозные проекты, включая недавно релизнутый Mayastor и pet-проект моего товарища-соратника Vitastor. Результаты оказались очень интересными.

Продолжаю делиться новостями ченджлогов. В этот раз небольшой апдейт.

В очередном сборнике из недавних кейсов в нашей практике расскажу, как мы продлевали root-сертификаты Let's Encrypt для старой CentOS, боролись с внезапным переключением DNS и Ingress, решали непростую задачу с шардами в Elasticsearch и не только.

Привет, Хабр! Меня зовут Вова, я разрабатываю observability-платформу в Ozon. Как-то раз в наш уголок на 42 этаже заглянули коллеги — и поделились наблюдением. Если открыть рядом графики времён запросов и ответов двух живущих в Kubernetes и общающихся между собой микросервисов, то иногда можно наблюдать большую разницу в высоких квантилях: клиент считает, что один ответ из сотни ему приходит за сто миллисекунд, сервер же говорит, что успевает ответить за десять.

Куда ушло время? Можно ли его вернуть? Под катом расскажу о том, с какими граблями может столкнуться микросервис, живущий в типичной инсталляции Kubernetes.

Привет, Хабр! Сергей Бондарев, архитектор Southbridge и спикер в Слёрме, недавно провёл вебинар «Kubernetes'22: выбор между self-hosted и managed-решением». Сегодня публикуем текстовую версию вебинара.

Этой ночью представят новую версию Kubernetes. Удаление Dockershim — если не самое значимое, то уж точно самое обсуждаемое изменение в релизе 1.24. Также среди интересных нововведений: «мониторинг здоровья» томов; Network Policy Status для оценки состояния подресурсов; набор тестов, с помощью которых определяется готовность Windows-кластеров к production.

В обзоре рассказываем обо всех улучшениях — новых (alpha) и о тех, что перешли на уровень выше (beta, stable).