Компания Nixys временно не ведёт блог на Хабре
Корректное завершение работы контейнеров в Kubernetes
Это вторая часть нашего пути (прим. пер. — ссылка на первую статью) к достижению нулевого времени простоя при обновлении Kubernetes-кластера. В первой части мы изложили проблемы и задачи, возникающие при выполнении операции drain для нод в кластере. В этом посте мы расскажем, как решить одну из таких проблем: корректно завершить работу pod’ов.
Процесс обновления для вашего Kubernetes-кластера
В какой-то момент при использовании кластера Kubernetes возникает потребность в обновлении работающих нод. Оно может включать в себя обновления пакетов, обновление ядра или развертывание новых образов виртуальных машин. В терминологии Kubernetes это называется "Voluntary Disruption".
В этой статье подробно объясняется, как решать проблемы, связанные с совместимостью баз данных при деплое. Мы расскажем, что может произойти с вашими приложениями на проде, если вы попытаетесь выполнить деплой без предварительной подготовки. Затем мы пройдемся по этапам жизненного цикла приложения, которые необходимы, чтобы иметь нулевое время простоя (прим. пер.: далее — zero downtime). Результатом наших операций будет применение обратно несовместимого изменения базы данных обратно совместимым способом.
Как правило, всегда возникает необходимость обеспечить выделенный пул ресурсов какому-либо приложению для его корректной и стабильной работы. Но что, если на одних и тех же мощностях работают сразу несколько приложений? Как обеспечить минимально необходимыми ресурсами каждое из них? Каким образом можно ограничить потребление ресурсов? Как грамотно распределить нагрузку между нодами? Как обеспечить работу механизма горизонтального масштабирования в случае роста нагрузки на приложения?
Tekton Pipeline — это новый проект, который позволяет запускать CI/CD pipelines используя Kubernetes-нативный подход. Первоначально Tekton Pipelines это часть проекта “Knative build”. Если вы хотите узнать больше об этом проекте, я настоятельно рекомендую посетить их сайт, который доступен по ссылке здесь.
Недавно мы собирали динамический модуль для Nginx, а когда всё было уже готово, то выяснилось, что наш модуль оказался не совместимым с Nginx, который уже был установлен на сервере. Готового решения возникшей проблемы нам найти не удалось и мы начали бороться с ней самостоятельно. Мы потратили много времени, но получили новый опыт и, самое главное, работающее решение. Которым и хотелось бы поделиться.
Начнём с описания процесса сборки динамического модуля на примере https://github.com/vozlt/nginx-module-vts. А затем покажем какая возникает ошибка и что с ней делать.
Все верно, после релиза Hashicorp Consul 1.5.0 в начале мая 2019 года в Consul можно делать авторизацию приложений и служб, запущенных в Kubernetes, нативно.
В этом руководстве мы шаг за шагом создадим POC (Проверка концепции (Proof of concept, PoC — доказательство [осуществимости] концепции — прим. перев.), продемонстрировав эту новую функцию. От вас ожидаются базовые знания о Kubernetes и Hashicorp’s Consul. И хотя вы можете использовать любую облачную платформу или локальную среду, в этом руководстве мы будем использовать Google’s Cloud Platform.
Давайте начнем с небольшой предыстории. У нас в компании на обслуживании стоит проект, который до недавнего времени находился в стадии тестирования/разработки. На тот момент в нём использовался ClickHouse с 3 шардами по 2 реплики в каждом. Учитывая то, что инфраструктура этого проекта была тестовой и не требовала никакой дополнительной авторизации (ClickHouse был в закрытом сегменте), никто этим вопросом не задавался.
Со временем проект вырос, ClickHouse стал production базой и нами была произведена миграция данных со старой инфраструктуры в новую с 1 шардом, 3 репликами на 3-х разных серверах (ClickHouse размещён в Kubernetes на базе StatefulSets) и, конечно, с авторизацией.
Вот что было дальше.
Прим. перев. — Этой статьёй мы начинаем цикл переводов, посвященных теме Zero Downtime Deployment. Следующие публикации осветят вопросы деплоя новых версий приложения с БД и деплой в Kubernetes.
Несмотря на то, что техническое решение, описываемое ниже достаточно спорно, целью данной статьи является знакомство читателя непосредственно с подходом Blue-Green деплоя, который, кстати, применим не только к приложениям Spring.
Целью Blue-Green деплоя является устранение простоев во время развертывания новой версии приложения.
Простой связан с недоступностью серверов, когда новая версия приложения устанавливается для замены старой. Идея Blue / Green deployment заключается в развертывании новой версии приложения в некоем отдельном месте, где можно проводить тестирование, вплоть до момента принятия окончательного решения о переключении на неё как на основную.
Запуск и визуализация пайплайнов при настройке GitLab CI/CD для нескольких проектов.
Непрерывная интеграция (CI) — это практика автоматизации сборки и тестирования кода до его слияния с основной веткой. Она позволяет разработчикам вливать код довольно часто и рано, снижая при этом риск внесения новых ошибок в главный репозиторий исходного кода.
Не так давно мы запустили Kubernetes 1.9 на AWS с помощью Kops. Вчера, во время плавного выкатывания нового трафика на самый большой из наших Kubernetes кластеров, я начал замечать необычные ошибки разрешения имен DNS, залогированные нашим приложением.
Пакет context в Go полезен при взаимодействиях с API и медленными процессами, особенно в production-grade системах, которые занимаются веб-запросами. С его помощью можно уведомить горутины о необходимости завершить свою работу.
Ниже небольшое руководство, которое поможет использовать этот пакет в ваших проектах, а также расскажет о некоторых лучших практиках и подводных камнях.
(Прим. пер.: Контекст используется во многих пакетах, например, в работе с Docker).
Когда дело доходит до создания Docker-контейнеров, лучше всегда стремиться к минимизации размера образов. Образы, которые используют одни и те же слои и весят меньше — быстрее переносятся и деплоятся.
Но как контролировать размер, когда каждое выполнение оператора RUN создает новый слой? Плюс, еще нужны промежуточные артефакты до создания самого образа...
Не секрет, что у K8S отличное коммьюнити и в целом хорошая документация. В ней можно легко найти ответ на многие вопросы. Но как и любая другая документация, она не может покрывать абсолютно всё. В данной статье я попытаюсь привести подробную инструкцию, как развернуть и настроить Traefik для использования в качестве Ingress-контроллера.
Итак, как наверняка все знают, совсем недавно 1-2 октября в Москве в “Инфопространстве” прошёл DevOpsConfRussia2018. Для тех кто не вкурсе, DevOpsConf — профессиональная конференция по интеграции процессов разработки, тестирования и эксплуатации.
Наша компания также приняла участие в этой конференции. Мы являлись её партнерами, представляя компанию на нашем стенде, а также провели небольшой митап. К слову это было первое наше участие в подобном роде деятельности. Первая конференция, первый митап, первый опыт.
О чём мы рассказывали? Митап был на тему “Бэкапы в Kubernetes”.
Скорее всего услышав это название, многие скажут: “А зачем бэкапить в Kubernetes? Его не нужно бэкапить, он же Stateless”.
Казалось бы, тема избитая – про резервное копирование сказано и написано многое, поэтому нечего изобретать велосипед, просто бери и делай. Тем не менее, каждый раз, когда перед системным администратором web-проекта встает задача настроить бэкапы, для многих она повисает в воздухе большим вопросительным знаком. Как правильно собрать бэкап данных? Где хранить резервные копии? Как обеспечить необходимый уровень ретроспективы хранения копий? Как унифицировать процесс резервного копирования для целого зоопарка различного ПО?
