Блог компании nixys

Использование 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

Canary Deployment

Надеемся, что вы читали первую часть, где мы кратко объясняли что такое Canary deployments и показывали как его реализовать при помощи стандартных ресурсов Kubernetes.

Istio

И мы предполагаем, что читая эту статью, вы уже знаете что такое Istio. Если нет, то вы можете почитать о нем здесь.

Приложение для тестов

Каждый под содержит два контейнера: наше приложение и istio-proxy.

Мы будем использовать простое тестовое приложение с подами frontend-nginx и backend на python. Под с nginx будет просто перенаправлять каждый запрос на под с backend и работать как прокси. Детали можно посмотреть подробнее в следующих yamls:

• frontend.yaml
• backend.yaml
• istio.yaml

Запуск тестового приложения самостоятельно

Если вы хотите последовать моему примеру и использовать данное тестовое приложение самостоятельно, см. readme проекта.

Начальный Deployment

При запуске первого Deployment видим, что поды нашего приложения имеют всего по 2 контейнера, то есть Istio sidecar пока только внедряется:

И также видим Istio Gateway Loadbalancer в namespace istio-system:

Создание трафика

Мы будем использовать следующий IP, что бы сгенерировать трафик, который будет принят frontend подами и перенаправлен на backend поды:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Мы так же добавим frontend.istio-test в наш hosts файл.

Просмотр Mesh через Kiali

Мы установили тестовое приложение и Istio вместе с Tracing, Grafana, Prometheus и Kiali (подробнее см. readme проекта). Следовательно, мы можем использовать Kiali через:

istioctl dashboard kiali # admin:admin

Kiali визуализирует текущий трафик через Mesh

Как мы видим, 100% трафика попадает на frontend service, затем на под фронтенда с label v1, так как мы используем простой nginx-прокси, который перенаправляет запросы на backend service, который в свою очередь перенаправляет их на backend поды с label v1.

Kiali работает отлично вместе с Istio и предоставляет коробочное решение для визуализации Mesh. Просто прекрасно.

Canary Deployment

Наш бекенд уже имеет два k8s deployments, один для v1 и один для v2. Теперь нам нужно просто сказать Istio перенаправлять определенный процент запросов на v2.

Шаг 1: 10%

И все что нам нужно сделать это отрегулировать вес VirtualService в istio.yaml:

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: backend  namespace: defaultspec:  gateways: []  hosts:  - "backend.default.svc.cluster.local"  http:  - match:    - {}    route:    - destination:        host: backend.default.svc.cluster.local        subset: v1        port:          number: 80      weight: 90    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 10

Мы видим, что 10% запросов перенаправлено на v2.

Шаг 2: 50%

И теперь достаточно просто увеличить его до 50%:

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: backend  namespace: defaultspec:...    - destination:        host: backend.default.svc.cluster.local        subset: v1        port:          number: 80      weight: 50    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 50

Шаг 3: 100%

Теперь Canary deployment может считаться завершенным и весь трафик перенаправляется на v2:

Тестирование Canary вручную

Допустим, сейчас мы отправляем на бэкэнд v2 10% от всех запросов. Что, если мы хотим вручную протестировать v2, чтобы убедиться, что все работает как мы ожидаем?

Мы можем добавить специальное соответствующее правило, основанное на HTTP заголовках:

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: backend  namespace: defaultspec:  gateways: []  hosts:  - "backend.default.svc.cluster.local"  http:  - match:    - headers:        canary:          exact: "canary-tester"    route:    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 100  - match:    - {}    route:    - destination:        host: backend.default.svc.cluster.local        subset: v1        port:          number: 80      weight: 90    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 10

Теперь используя curl мы можем принудительно запросить v2 отправив заголовок:

Запросы без заголовка все еще будут управляться соотношением 1/10:

Canary для двух зависимых версий

Теперь мы рассмотрим вариант, где у нас есть версия v2 и для frontend и для backend. Для обоих мы указали, что 10% трафика должно идти к v2:

Мы видим, что frontend v1 и v2 оба пересылают трафик в соотношении 1/10 на backend v1 и v2.

А что если бы мы нам было нужно пересылать трафик с frontend-v2 только на backend-v2, потому что он не совместим с v1? Для этого мы установим 1/10 соотношение для frontend, который контролирует какой трафик попадает на backend-v2 используя согласование по sourceLabels :

apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: backend  namespace: defaultspec:  gateways: []  hosts:  - "backend.default.svc.cluster.local"  http:...  - match:    - sourceLabels:        app: frontend        version: v2    route:    - destination:        host: backend.default.svc.cluster.local        subset: v2        port:          number: 80      weight: 100

В результате получаем то, что нужно:

Отличия от ручного Canary подхода

В первой части мы выполняли Canary deployment вручную, также используя два k8s deployments. Там мы управляли соотношением запросов, изменяя количество реплик. Такой подход работает, но имеет серьезные недостатки.

Istio дает возможность определять соотношение запросов вне зависимости от количества реплик. Это значит, к примеру, что мы можем использовать HPAs (Horizontal Pod Autoscalers горизонтальное масштабирование подов) и его не нужно настраивать в соответствии с текущем состоянием Canary деплоя.

Итог

Istio работает отлично и используя его вместе с Kiali получаем очень мощную комбинацию. Следующий в моем списке интересов это комбинация Spinnaker с Istio для автоматизации и Canary-аналитики.

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

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

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

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

Порядок авторизации обычно выглядит следующим образом:

1. Пользователь заходит в приложение или на сайт, доступ к которому он хочет получить, то есть к провайдеру услуг.
2. Провайдер услуг отправляет токен, содержащий информацию о пользователе (такую как email адрес) системе SSO (так же известной, как система управления доступами), как часть запроса на аутентификацию пользователя.
3. В первую очередь система управления доступами проверяет был ли пользователь аутентифицирован до этого момента. Если да, она предоставляет пользователю доступ к приложению провайдера услуг, сразу приступая к шагу 5.
4. Если пользователь не авторизовался, ему будет необходимо это сделать, предоставив идентификационные данные, требуемые системой управления доступами. Это может быть просто логин и пароль или же другие виды аутентификации, например одноразовый пароль (OTP One-Time Password).
5. Как только система управления доступами одобрит идентификационные данные, она вернет токен провайдеру услуг, подтверждая успешную аутентификацию.
6. Этот токен проходит сквозь браузер пользователя провайдеру услуг.
7. Токен, полученный провайдером услуг, подтверждается согласно доверительным отношениям, установленным между провайдером услуг и системой управления доступами во время первоначальной настройки.
8. Пользователю предоставляется доступ к провайдеру услуг.

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

Что такое токен в контексте SSO?

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

Является ли технология SSO безопасной?

Ответом на этот вопрос будет "в зависимости от ситуации".

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

SSO также сокращает количество времени, потраченного на восстановление пароля с помощью службы поддержки. Администраторы могут централизованно контролировать такие факторы, как сложность пароля и многофакторную аутентификацию (MFA). Администраторы также могут быстрее отозвать привилегии на вход в систему, если пользователь покинул организацию.

Однако, у SSO есть некоторые недостатки. Например, вероятно, вам захочется, чтобы определенные приложения оставались заблокированы/менее открыты к доступу. По этой причине важно выбрать то решение SSO, которое, к примеру, даст вам возможность запросить дополнительный фактор проверки аутентификации прежде, чем пользователь авторизуется или оградит пользователей от доступа к определенным приложениям пока не обеспечено безопасное соединение.

Как внедрить SSO?

Особенности внедрения SSO могут отличаться с учетом того, с каким именно решением SSO вы работаете. Но вне зависимости от способа, вам нужно точно знать какие цели вы преследуете. Убедитесь, что вы ответили на следующие вопросы:

• С какими типами пользователей вы работаете и какие у них требования?
• Вы ищете локальное или облачное решение?
• Возможен ли дальнейший рост выбранной программной платформы вместе с вашей компанией и ее запросами?
• Какие функции вам необходимы, чтобы убедиться в том, что процесс авторизации проходят только проверенные пользователи? MFA, Adaptive Authentication, Device Trust, IP Address Whitelisting, и т.д?
• С какими системами вам необходимо интегрироваться?
• Нужен ли вам доступ к программному интерфейсу приложения (API)?

Что отличает настоящую SSO от хранилища или менеджера паролей?

Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On что означает такой же/одинаковый вход, а не единый вход (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.

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

В чем разница между программным обеспечением единого входа и решением SSO?

Изучая доступные варианты единого входа, вы можете увидеть, что их иногда называют программным обеспечением единого входа, а не решением единого входа или провайдером единого входа. Часто разница состоит лишь в том, как позиционируют себя компании. Фрагмент программного обеспечения предполагает локальную установку. Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.

Бывают ли разные типы SSO?

Когда мы говорим о едином входе (SSO), используется множество терминов:

• Federated Identity Management (FIM)
• OAuth (OAuth 2.0 в настоящее время)
• OpenID Connect (OIDC)
• Security Access Markup Language (SAML)
• Same Sign On (SSO)

На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) это характеристика/фича, доступная внутри архитектуры FIM.

OAuth 2.0 это особая программная платформа, которая также может считаться частью архитектуры FIM. OAuth фокусируется на доверительных отношениях, предоставляя доменам идентификационную информацию пользователя.

OpenID Connect (OIDC) это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.

Security Access Markup Language (SAML) это открытый стандарт, который также разработан для обеспечения функциональности SSO.

Система Same Sign On, которую часто обозначают, как SSO, на самом деле, не похожа Single Sign-on, т.к не предполагает наличие доверительных отношений между сторонами, которые проходят аутентификацию. Она более привязана к идентификационным данным, которые дублируются и передаются в другие системы когда это необходимо. Это не так безопасно, как любое из решений единого входа.

Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Access Protocol (LDAP).

Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos. Таким образом, пользователи, относящиеся к ADDS могут аутентифицироваться с их устройств и получить доступ к другим системам, интегрированным с ADDS. Это и есть форма SSO.

Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.

Протокол LDAP (Lightweight Directory Service Protocol) это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации. Но он часто применяется как часть процесса аутентификации и контроля доступа. Например, прежде, чем пользователь получит доступ к определенному ресурсу, LDAP сможет запросить информацию о пользователе и группах, в которых он состоит, чтобы удостовериться, что у пользователя есть доступ к данному ресурсу. LDAP платформа на подобие OpenLDAP обеспечивает аутентификацию с помощью аутентификационных протоколов (например, Simple Authentication и Security Layer SASL).

Как работает система единого входа как услуга?

SSO функционирует также, как и многие другие приложения, работающие через интернет. Подобные OneLogin платформы, функционирующие через облако, можно отнести к категории решений единого входа Software as a Service (SaaS).

Что такое App-to-App (приложение-приложение) SSO?

В заключение, возможно вы слышали о App-to-App SSO. Пока еще такой подход не является стандартным. Такое понятие больше используется SAPCloud для обозначения процесса передачи идентификационных данных пользователя из одного приложения в любое из других, состоящих в их экосистеме. В какой-то степени такой метод присущ OAuth 2.0, но хочется снова подчеркнуть, что это не стандартный протокол или метод. В настоящее время он является характерным только для SAPCloud.

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

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

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

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

Проблема дублирования документов

В наших проектах Fluentd развернут как DaemonSet (автоматически запускается в одном экземпляре на каждом узле кластера Kubernetes) и отслеживает stdout логи контейнеров в /var/log/containers. После сбора и обработки логи в виде JSON-документов поступают в ElasticSearch, поднятый в кластерном либо standalone виде, в зависимости от масштабов проекта и требований к производительности и отказоустойчивости. В качестве графического интерфейса используется Kibana.

При использовании Fluentd с буферизирующим плагином на выходе мы столкнулись с ситуацией, когда некоторые документы в ElasticSearch имеют полностью одинаковое содержание и отличаются лишь идентификатором. Убедиться, что это именно повтор сообщения можно на примере лога Nginx. В файле лога данное сообщение существует в единственном экземпляре:

127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -

Однако, в ElasticSearch существует несколько документов, содержащих данное сообщение:

{  "_index": "test-custom-prod-example-2020.01.02",  "_type": "_doc",  "_id": "HgGl_nIBR8C-2_33RlQV",  "_version": 1,  "_score": 0,  "_source": {    "service": "test-custom-prod-example",    "container_name": "nginx",    "namespace": "test-prod",    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] \"GET / HTTP/1.1\" 200 777 \"-\" \"Opera/12.0\" -",    "tag": "custom-log"  }}{  "_index": "test-custom-prod-example-2020.01.02",  "_type": "_doc",  "_id": "IgGm_nIBR8C-2_33e2ST",  "_version": 1,  "_score": 0,  "_source": {    "service": "test-custom-prod-example",    "container_name": "nginx",    "namespace": "test-prod",    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] \"GET / HTTP/1.1\" 200 777 \"-\" \"Opera/12.0\" -",    "tag": "custom-log"  }}

Притом, повторов может быть больше двух.

Во время фиксации данной проблемы в логах Fluentd можно наблюдать большое количество предупреждений следующего содержания:

2020-01-16 01:46:46 +0000 [warn]: [test-prod] failed to flush the buffer. retry_time=4 next_retry_seconds=2020-01-16 01:46:53 +0000 chunk="59c37fc3fb320608692c352802b973ce" error_class=Fluent::Plugin::ElasticsearchOutput::RecoverableRequestFailure error="could not push logs to Elasticsearch cluster ({:host=>\"elasticsearch\", :port=>9200, :scheme=>\"http\", :user=>\"elastic\", :password=>\"obfuscated\"}): read timeout reached"

Данные предупреждения возникают когда ElasticSearch не может вернуть ответ на запрос за установленное параметром request_timeout время, из-за чего пересылаемый фрагмент буфера не может быть очищен. После этого Fluentd пытается отправить фрагмент буфера в ElasticSearch повторно и через произвольное число попыток операция завершается успешно:

2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fc3fb320608692c352802b973ce" 2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fad241ab300518b936e27200747" 2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fc11f7ab707ca5de72a88321cc2" 2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fb5adb70c06e649d8c108318c9b" 2020-01-16 01:47:15 +0000 [warn]: [kube-system] retry succeeded. chunk_id="59c37f63a9046e6dff7e9987729be66f"

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

В Kibana это выглядит так:

Решение проблемы

Существует несколько вариантов решения данной проблемы. Один из них встроенный в плагин fluent-plugin-elasticsearch механизм генерации уникального хеша для каждого документа. Если использовать данный механизм, ElasticSearch будет распознавать повторы на стадии пересылки и не допускать дублирования документов. Но нельзя не учитывать, что данный способ решения проблемы борется со следствием и не устраняет ошибку с нехваткой тайм-аута, поэтому мы отказались от его применения.

Мы используем буферизирующий плагин на выходе Fluentd, чтобы не допустить потери логов в случае кратковременных неполадок с сетью или возросшей интенсивности записи логов. Если по какой-либо причине ElasticSearch не может мгновенно записать документ в индекс, документ попадает в очередь, которая хранится на диске. Поэтому, в нашем случае, чтобы устранить источник проблемы, которая приводит к возникновению описанной выше ошибки, необходимо задать корректные значения параметров буферизации, при которых выходной буфер Fluentd будет достаточного объема и при этом успевать очищаться за отведенное время.

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

На момент фиксации проблемы конфигурация выглядела следующим образом:

 <buffer>        @type file        path /var/log/fluentd-buffers/kubernetes.test.buffer        flush_mode interval        retry_type exponential_backoff        flush_thread_count 2        flush_interval 5s        retry_forever        retry_max_interval 30        chunk_limit_size 8M        queue_limit_length 8        overflow_action block      </buffer>

В ходе решения проблемы вручную подбирались значения следующих параметров:
chunk_limit_size размер чанков, на которые разбиваются сообщения в буфере.

• flush_interval интервал времени, через который происходит очистка буфера.
• queue_limit_length максимальное количество чанков в очереди.
• request_timeout время, на которое устанавливается соединение между Fluentd и ElasticSearch.

Общий размер буфера можно вычислить, перемножив параметры queue_limit_length и chunk_limit_size, что можно толковать как максимальное количество чанков в очереди, каждый из которых имеет заданный объем. При недостаточном размере буфера в логах будет появляться следующее предупреждение:

2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:block

Оно означает, что буфер не успевает очиститься за отведенное время и данные, которые поступают в заполненный буфер, блокируются, что приведет к потере части логов.

Увеличить буфер можно двумя способами: увеличив либо размер каждого чанка в очереди, либо количество чанков, которые могут находиться в очереди.

Если установить размер чанка chunk_limit_size более 32 мегабайт, то ElasticSeacrh не примет его, так как входящий пакет получится слишком большим. Поэтому, если необходимо увеличить буфер дополнительно, лучше увеличивать максимальную длину очереди queue_limit_length.

Когда буфер перестанет переполняться и останется только сообщение о нехватке тайм-аута, можно приступить к увеличению параметра request_timeout. Однако, при установке значения больше 20 секунд, в логах Fluentd начнут появляться следующие предупреждения:

2020-01-21 09:55:33 +0000 [warn]: [test-dev] buffer flush took longer time than slow_flush_log_threshold: elapsed_time=20.85753920301795 slow_flush_log_threshold=20.0 plugin_id="postgresql-dev" 

Данное сообщение никак не влияет на работу системы и означает, что время очистки буфера заняло больше, чем установлено параметром slow_flush_log_threshold. Это отладочная информация и мы используем её при подборе значения параметра request_timeout.

Обобщенный алгоритм подбора выглядит следующим образом:

1. Установить значение request_timeout гарантированно большим, чем необходимо (сотни секунд). На время настройки основным критерием правильности установки данного параметра будет являться исчезновение предупреждений у нехватке тайм-аута.
2. Дождаться сообщений о превышении порога slow_flush_log_threshold. В тексте предупреждения в поле elapsed_time будет написано реальное время очистки буфера.
3. Установить значение request_timeout больше, чем максимальное значение elapsed_time, полученное за период наблюдения. Мы рассчитываем значение request_timeout как elapsed_time + 50%.
4. Чтобы убрать из лога предупреждения о долгой очистке буфера, можно поднять значение slow_flush_log_threshold. Мы рассчитываем данное значение как elapsed_time + 25%.

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

В таблице ниже показано, как изменяется количество ошибок за сутки, приводящих к дублированию сообщений, в процессе подбора значений описанных выше параметров:

Стоит дополнительно отметить, что полученные настройки могут потерять свою актуальность в процессе роста проекта и, соответственно, увеличения количества логов. Первичным признаком нехватки установленного тайм-аута является возвращение в лог Fluentd сообщений о долгой очистке буфера, то есть превышение порога slow_flush_log_threshold. С этого момента есть ещё небольшой запас до превышения параметра request_timeout, поэтому необходимо своевременно отреагировать на данные сообщения и повторно выполнить процесс подбора оптимальных настроек, описанный выше.

Заключение

Тонкая настройка выходного буфера Fluentd является одним из главных этапов настройки EFK стека, определяющим стабильность его работы и корректность размещения документов в индексах. Ориентируясь на описанный алгоритм настройки, можно быть уверенным, что все логи будут записаны в индекс ElasticSearch в правильном порядке, без повторений и потерь.

Также читайте другие статьи в нашем блоге:

• Подружили Go и Zabbix 5.0
• Обновление Kubernetes-кластера без простоя
• Kubernetes: почему так важно настроить управление ресурсами системы?
• Три простых приема для уменьшения Docker-образов
• Резервное копирование большого количества разнородных web-проектов

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

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

• (эта статья)
• Canary Deployment при помощи ArgoCI
• Canary Deployment при помощи Istio
• Canary Deployment при помощи Jenkins-X Istio Flagger

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

https://www.norberteder.com/canary-deployment/

Canary Deployment

При Canary-стратегии обновления сначала применяются только для части пользователей. Через мониторинг, данные с логов, ручное тестирование или другие каналы обратной связи релиз тестируется перед его применением для всех пользователей.

Kubernetes Deployment (rolling update)

Стратегия по умолчанию для Kubernetes Deployment это rolling-update, где запускается определенное количество подов с новыми версиями образов. Если они создались без проблем, поды со старыми версиями образов завершаются, а новые поды создаются параллельно.

GitOps

Мы используем GitOps в этом примере, так как мы:

• используем Git как единый источник истины
• используем Git Operations для сборки и деплоя (никаких команд, кроме git tag/merge не нужно)

Пример

Возьмем хорошую практику иметь один репозиторий для кода приложений и один для инфраструктуры.

Репозиторий для приложений

Это очень простая API на Python+Flask, возвращающая ответ в виде JSON. Мы соберем пакет через GitlabCI и запушим результат в Gitlab Registry. В регистри у нас есть две разные версии релизов:

• wuestkamp/k8s-deployment-example-app:v1
• wuestkamp/k8s-deployment-example-app:v2

Единственная разница между ними это изменение возвращаемого JSON-файла. Мы используем это приложение для максимально простой визуализации того, с какой версией мы общаемся.

Инфраструктурный репозиторий

В этой репе мы будем деплоить через GitlabCI в Kubernetes, .gitlab-ci.yml выглядит следующим образом:

image: traherom/kustomize-dockerbefore_script:   - printenv   - kubectl versionstages: - deploydeploy test:   stage: deploy   before_script:     - echo $KUBECONFIG   script:     - kubectl get all     - kubectl apply -f i/k8s   only:     - master

Для его запуска самостоятельно вам понадобится кластер, можно использовать Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-bgcloud compute firewall-rules create incoming-80 --allow tcp:80

Вам нужно сделать форк https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure и создать переменную KUBECONFIG в GitlabCI, которая будет содержать конфиг для доступа kubectl к вашему кластеру.

О том, как получить учетные данные для кластера (Gcloud) можно почитать вот тут.

Инфраструктурный Yaml

В инфраструктурном репозитории у нас есть service:

apiVersion: v1kind: Servicemetadata: labels:   id: app name: appspec: ports: - port: 80   protocol: TCP   targetPort: 5000 selector:   id: app type: LoadBalancer

И deployment в deploy.yaml:

apiVersion: apps/v1kind: Deploymentmetadata: name: appspec: replicas: 10 selector:   matchLabels:     id: app     type: main template:   metadata:     labels:       id: app       type: main   spec:     containers:     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1       name: app       resources:         limits:           cpu: 100m           memory: 100Mi

И другой deployment в deploy-canary.yaml:

kind: Deploymentmetadata: name: app-canaryspec: replicas: 0 selector:   matchLabels:     id: app     type: canary template:   metadata:     labels:       id: app       type: canary   spec:     containers:     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2       name: app       resources:         limits:           cpu: 100m           memory: 100Mi

Заметьте, что app-deploy пока не имеет определенных реплик.

Выполнение начального деплоя

Для запуска начального deployment вы можете запустить пайплайн GitlabCI вручную в мастер-ветке. После этого kubectl дожен вывести следующее:

Мы видим app deployment c 10 репликами и app-canary с 0. Так же есть LoadBalancer с которого мы можем обращаться через curl по External IP:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

Мы видим, что наше тестовое приложение возвращает только v1.

Выполнение Canary деплоя

Шаг 1: выпустить новую версию для части пользователей

Мы установили количество реплик в 1 в файле deploy-canary.yaml и образ новой версии:

kind: Deploymentmetadata: name: app-canaryspec: replicas: 1 selector:   matchLabels:     id: app     type: canary template:   metadata:     labels:       id: app       type: canary   spec:     containers:     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2       name: app       resources:         limits:           cpu: 100m           memory: 100Mi

В файле deploy.yaml мы изменили количество реплик до 9:

kind: Deploymentmetadata: name: appspec: replicas: 9 selector:   matchLabels:     id: app...

Мы пушим эти изменения в репозиторий, из которого запустится деплой (через GitlabCI) и видим в итоге:

Наш Service будет указывать на оба деплоя, так как у обоих есть селектор app. Из-за случайного распределения по умолчанию в Kubernetes мы должны увидеть разные ответы на ~ 10% запросов:

Текущее состояние нашего приложения (GitOps, взятый с Git как с Single Source Of Truth) это наличие двух deployments c активными репликами, по одному для каждой версии.

~10% пользователей знакомятся с новой версией и ненамеренно тестируют ее. Теперь настало время проверить наличие ошибок в логах и данных мониторинга для поиска проблем.

Шаг 2: выпустить новую версию для всех пользователей

Мы решили, что все прошло хорошо и теперь нам нужно развернуть новую версию на всех пользователей. Для этого мы просто обновляем deploy.yaml устанавливая новую версию образа и количество реплик, равное 10. В deploy-canary.yaml мы устанавливаем количество реплик равное обратно 0. После деплоя результат будет следующим:

Подводя итог

Для меня запуск деплоя вручную таким образом помогает понять как легко он может быть настроен при помощи k8s. Так как Kubernetes позволяет обновлять все через API, эти шаги можно автоматизировать через скрипты.

Еще одна вещь, которую нужно реализовать это точка входа тестировщика (LoadBalancer или через Ingress), через которую можно получить доступ только к новой версии. Она может быть использована для просмотра вручную.

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

Также читайте другие статьи в нашем блоге:

• К чему привела миграция с ClickHouse без авторизации на ClickHouse с авторизацией
• Cборка динамических модулей для Nginx
• Апдейт nxs-build-tools помощника в сборке deb и rpm пакетов
• Введение в Hashicorp Consuls Kubernetes Авторизацию
• С чем нам пришлось столкнуться при использовании утилиты Csync2
• Telegram-бот для Redmine. Как упростить жизнь себе и людям