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

Будучи DevOps инженерами, мы тесно сотрудничаем с разработчиками и используем одни и те же инструменты такие, как: CI-CD, VCS, laC, мониторинг, логирование, оркестрацию контейнеров и т.д. Kubernetes также является одним из таких инструментов, который тоже используется во время разработки, развёртывания и отладки, устранения неполадок и мониторинга приложений. Как все знают, это требование DevOps культуры.

Что такое single sign-on?

Технология единого входа (Single sign-on SSO) — метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных.

Как работает SSO?

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

Kubernetes - это движок оркестрации контейнеров с открытым исходным кодом для автоматического развертывания, масштабирования и управления контейнеризированными приложениями. Под (Pod) – это базовое понятие при проектировании приложений в Kubernetes. Kubernetes оперирует подами, а не контейнерами, при этом поды включают в себя контейнеры. Под может содержать в себе описания одного или нескольких контейнеров, монтируемых разделов, IP-адресов и настроек того, как контейнеры должны работать внутри пода.

Под, содержащий один контейнер, относится к одно-контейнерным подам и это самый распространенный вариант их использования в Kubernetes. Под, который содержит несколько связанных контейнеров, относится к мульти-контейнерным подам. Есть несколько паттернов для мульти-контейнерных подов и один из них — это паттерн sidecar. В этом посте мы на примере проекта детально рассмотрим этот паттерн.

Мы рады объявить о новой интеграции Kubernetes, которая позволяет приложениям без встроенной в HashiCorp Vault нативной логики использовать статические и динамические секреты, получаемые из Vault. Она основана на новом инструменте под названием vault-k8s, который использует Kubernetes Mutating Admission Webhook для перехвата и дополнения специально аннотированной конфигурации подов для инъекции секретов с помощью Init и Sidecar контейнеров.

Приложениям нужно заботиться только о получении секрета по определённому пути в файловой системе, а не об управлении токенами, подключении к внешнему API или другим механизмам прямого взаимодействия с Vault.

Один из самых частых вопросов, которые мне задают как консультанту это: “В чем разница между liveness и readiness пробами?”. Следующий самый частый вопрос: “Какие из них нужны моему приложению?”.

Любой, кто пробовал за Duck Duck Go-ить этот вопрос знает, что на него непросто найти ответ в интернете. В этой статье, надеюсь, я смогу помочь вам ответить на эти вопросы самостоятельно. Я поделюсь своим мнением о том, каким образом лучше использовать liveness и readiness пробы в приложениях развернутых в Red Hat OpenShift. И я предлагаю не строгий алгоритм, а, скорее, общую схему, которую вы можете использовать для принятия своих собственных архитектурных решений.

Понятие DevOps знакомо многим, но в своей практике я часто наблюдаю такую ситуацию, когда соискатель на должность DevOps-инженера в нашу компанию не может ответить на вопрос “А что же такое DevOps?”. В данной статье я хочу упорядочить и структурировать знания и основные понятия DevOps. Ещё раз обозначить какие процессы там существуют, для чего они и с чего начать внедрение DevOps у себя в проекте.

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

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

Использование решения Jenkins X для выполнения Canary деплоя в кластере Kubernetes

В этом цикле:

1. Canary Deployment через GitlabCI + GitOps/Manual Approach
2. Canary Deployment через Argo Rollouts
3. Canary Deployment с Istio
4. (эта статья)

Что мы будем делать здесь?

Мы создадим Jenkins X k8s кластер и тестовое приложение на Python шаг за шагом. Вы можете повторять по примеру, либо просто читать, смотреть иллюстрации и результаты для получения представления о взаимодействии JenkinsX+Flagger+Istio сanary deployment и решить для себя, стоит ли эта связка более глубокого изучения.

Использование Istio+Kiali для запуска и визуализации Canary деплоя

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

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

Мы будем использовать 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 подходит для большинства повседневных задач. Однако встречаются ситуации, когда нам важно тонко управлять процессом распределения подов, и для выполнения этой задачи есть два пути:

Практически каждый инженер, практикующий 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’ы перестали принимать трафик сразу после начала выселения. Чтобы уменьшить риск простоя, нам сначала нужно понять, почему это происходит.