Мы будем использовать k8s-нативный контроллер развертывания Argo Rollouts и GitlabCI для запуска Canary деплоя в Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Статьи этого цикла

1. Canary Deployment в Kubernetes #1: Gitlab CI
2. (Эта статья)
3. Canary Deployment using Istio
4. Canary Deployment с Jenkins-X, Istio и Flagger

Мы будем использовать Gitlab CI и ручной GitOps для внедрения и использования Canary-деплоя в Kubernetes

---

Статьи из этого цикла:

1. (эта статья)
2. Canary Deployment при помощи ArgoCI
3. Canary Deployment при помощи Istio
4. Canary Deployment с Jenkins-X, Istio и Flagger

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

Доброго времени суток, читатель!

22 апреля в GitLab выпустили релиз 12.10 и сообщили о том, что теперь CI-процесс может авторизовываться в Hashicorp's Vault через JSON Web Token (JWT), и для авторизации нет необходимости хранить токен для доступа к нужным policy в переменных окружения (или где-либо ещё).

Данная фича показалась нам полезной, поэтому предлагаем перевод соотвествующего туториала из официальной документации GitLab:

В наше время невозможно представить проект на базе Kubernetes без стека ELK, с помощью которого сохраняются логи как приложений, так и системных компонентов кластера. В своей практике мы используем стек EFK с Fluentd вместо Logstash.

Fluentd — это современный универсальный коллектор логов, набирающий всё большую популярность и присоединившийся к Cloud Native Computing Foundation, из-за чего вектор его разработки ориентирован на использование совместно с Kubernetes.

Факт использования Fluentd вместо Logstash не изменяет общую суть программного комплекса, однако, для Fluentd характерны свои специфические нюансы, следующие из его многофункциональности.

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

Csync2 — достаточно старая утилита, которая предназначена для синхронизации файлов между серверами. Она позволяет настроить синхронизацию файлов по приоритетам, либо по последней модификации в файле (проверяются не сами изменения в файле, а дата его модификации). Также данная утилита позволяет настроить выполнения какого-либо действия при изменении определённого файла. Например при изменении конфигурации nginx, выполнить перечитывание конфигурации. Мы начали её использовать достаточно давно на небольших проектах (кластер минимум из 3-х серверов) и всё было хорошо до того момента, пока эти маленькие кластера не начали развиваться, а именно:

1. Заметно увеличился объем файлов, которые необходимо синхронизировать между серверами.
2. Увеличилась интенсивность добавления этих файлов.

Сегодня мы поделимся нашим опытом использования такой утилиты как csync2 и о том, какие проблемы могут возникнуть при ее использовании.

Kube-scheduler является неотъемлемым компонентом Kubernetes, который отвечает за планирование подов по нодам в соответствии с заданными политиками. Зачастую, в процессе эксплуатации Kubernetes-кластера нам не приходится задумываться о том, по каким именно политикам происходит планирование подов, так как набор политик дефолтного kube-scheduler’a подходит для большинства повседневных задач. Однако встречаются ситуации, когда нам важно тонко управлять процессом распределения подов, и для выполнения этой задачи есть два пути:

Сетевой плагин Calico предоставляет широкий набор сетевых политик с унифицированным синтаксисом для защиты хостов на железе, виртуальных машин и pod’ов. Эти политики могут применяться в рамках namespace или быть глобальными сетевыми политиками, применимыми к host endpoint (для защиты приложений, работающих непосредственно на хосте — хостом может быть непосредственно сервер или виртуальная машина) или к workload endpoint (для защиты приложений, работающих в контейнерах или виртуальных машинах, размещенных на хосте). Политики Calico позволяют применить меры безопасности для различных точек пути пакетов с помощью таких параметров, как preDNAT, untracked и applyOnForward. Понимание того, как эти опции работают, может помочь повысить безопасность и производительность системы в целом. В этой статье объясняется суть данных параметров политик Calico (preDNAT, unraracked и applyOnForward), применяемых к host endpoints, с акцентом том, что происходит в путях обработки пакетов (цепочек iptabels).

Практически каждый инженер, практикующий DevOps, в какой-то момент сталкивается с задачей настройки правил доступа для своих проектов. В данной статье мы рассмотрим примеры настройки сетевых политик Kubernetes-кластера, в котором используется плагин Calico и осветим некоторые интересные моменты. Предполагаем, что у вас уже имеется кластер k8s, где в качестве сетевого плагина используется Calico.

Отслеживание соединений (“conntrack”) является основной функцией сетевого стека ядра Linux. Она позволяет ядру отслеживать все логические сетевые соединения или потоки и тем самым идентифицировать все пакеты, которые составляют каждый поток, чтобы их можно было последовательно обрабатывать вместе.

От переводчика: при разработке ПО у программистов, какого бы уровня они ни были, нередко возникает желание реализовать тот или иной фрагмент программы более красиво и удобно. Когда, глядя на код, интуитивно чувствуешь: этот кусок точно можно сделать изящнее, начинаешь либо вспоминать best practice для решения таких задач, либо искать их в инете, либо придумывать своё решение. Недавно я сам столкнулся с подобной ситуацией и нашёл, казалось бы, очевидное решение, но, тем не менее, ранее я им не пользовался. Вот им бы хотелось поделиться с сообществом в представленном ниже переводе очень небольшой статьи.

Защита pod’а от выселения при помощи Pod Disruption Budgets в Kubernetes

Это четвертая и заключительная часть нашего пути (прим. пер. — ссылка на первую статью) для достижения нулевого времени простоя при обновлении Kubernetes-кластера. В предыдущих двух частях мы фокусировались на том, как корректно выключить существующие pod’ы в кластере. Мы описали как использовать хуки preStop для корректного выключения pod’ов и почему важно добавлять задержку в процесс удаления, чтобы подождать, пока процесс удаления pod’а применится для всего кластера. Это поможет в отключении одного pod’а, но не защитит нас от выключения настолько большого количества pod’ов, что наш сервис не сможет функционировать. В этой статье мы будем использовать PodDisruptionBudgets (или PDB), для уменьшения этого риска.

Задержка выключения pod’а в Kubernetes

Это третья часть нашего пути (прим. пер. — ссылка на первую статью) к достижению нулевого времени простоя при обновлении Kubernetes-кластера. Во второй части мы сокращали время простоя, которое возникло из-за принудительного завершения работающих в pod’ах приложений, завершая их корректно при помощи lifecycle hooks. Однако, мы так же узнали, что pod может продолжать принимать трафик после того, как приложение в нем начало завершение работы. То есть клиент может получить ошибку, потому что его запрос будет направлен на pod, который больше не может обслуживать трафик. В идеале, мы бы хотели, чтобы pod’ы перестали принимать трафик сразу после начала выселения. Чтобы уменьшить риск простоя, нам сначала нужно понять, почему это происходит.

Корректное завершение работы контейнеров в 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) и, конечно, с авторизацией.

Вот что было дальше.