Ми починаємо серію постів, де продемонструємо деякі з безлічі можливостей сервісної сітки Istio Service Mesh у поєднанні з Red Hat OpenShift і Kubernetes.
Частина перша, сьогоднішня:
- Пояснимо концепцію sidecar-контейнерів Kubernetes та сформулюємо лейтмотив цієї серії постів: «Вам не треба нічого міняти у своєму коді».
- Уявімо основну річ Istio - правила маршрутизації. На них будуються всі інші можливості Istio, оскільки саме правила дозволяють направляти трафік до мікросервісів, використовуючи для цього зовнішні коди сервісів файли YAML. Також розглядаємо схему розгортання Canary Deployment. Новорічний бонус – 10 інтерактивних занять з Istio
Частина друга, яка скоро вийде, розповість вам:
- Як Istio реалізує Pool Ejection у поєднанні з Circuit Breaker та продемонструє, як Istio дозволяє прибрати зі схеми балансування непрацюючий або погано працюючий pod.
- А ще ми розглянемо тему Circuit Breaker з першого посту щодо того, як тут можна задіяти Istio. Покажемо, як без найменших змін у коді сервісів маршрутизувати трафік та обробляти мережеві помилки за допомогою конфігураційних файлів YAML та команд терміналу.
Частина третя:
- Розповідь про трасування та моніторинг, які вже вбудовані або легко додаються до Istio. Покажемо, як використовувати такі інструменти, як Prometheus, Jaeger і Grafana у поєднанні з масштабування OpenShift, щоб без зайвих зусиль керувати мікросервісною архітектурою.
- Переходимо від моніторингу та обробки помилок до того, щоб вносити їх у систему навмисно. Інакше кажучи, вчимося робити fault injection без зміни вихідного коду, що дуже важливо з точки зору тестування, оскільки якщо змінювати для цього сам код, то є ризик внести додаткові помилки.
Нарешті, у фінальному пості з Istio Service Mesh:
- Перейдемо на Темну Сторону. Точніше, будемо вчитися використовувати схему Dark Launch, коли код розгортається і тестується прямо на продакшн-даних, але ніяк не торкається роботи системи. Тут дуже доречним є вміння Istio розділяти трафік. А можливість виконувати тестування на живих продакшн-даних, ніяк не впливаючи на роботу бойової системи, – це переконливий спосіб перевірки.
- Відштовхуючись від Dark Launch, покажемо, як використовувати модель Canary Deployment, щоб скоротити ризики та спростити введення в дію нового коду. Сама по собі Canary Deployment – далеко не новина, але Istio дозволяє реалізувати цю схему лише за допомогою нескладних YAML-файлів.
- Насамкінець покажемо, як за допомогою Istio Egress дати доступ до сервісів тим, хто знаходиться поза вашими кластерами, щоб задіяти можливості Istio при роботі з інтернетом.
Отже, помчала ...
Інструментарій моніторингу та управління Istio – все необхідне для координації мікросервісів у сервісній сітці .
Що таке сервісна сітка Istio
Сервісна сітка реалізує для групи сервісів такі функції, як моніторинг трафіку, контроль доступу, виявлення, безпека, стійкість до відмови та інші корисні речі. Istio дозволяє зробити все це без жодних змін у коді самих сервісів. У чому секрет чаклунства? Istio чіпляє до кожного сервісу свій проксі у вигляді sidecar-контейнера (sidecar – мотоциклетна коляска), після чого весь трафік до цього сервісу йде через проксі, який, керуючись заданими політиками, вирішує як, коли і чи взагалі цей трафік повинен дійти до сервісу. Istio також дає можливість реалізувати просунуті техніки DevOps, такі як canary deployments, circuit breakers, fault injection та багато інших.
Як Istio працює з контейнерами та Kubernetes
Сервісна сітка Istio – це sidecar'на реалізація всього того, що потрібно для створення та управління мікросервісами: моніторинг, трасування, circuit breakers, маршрутизація, балансування навантаження, fault injection, повтори, тайм-аути, дзеркаловання, контроль доступу, обмеження швидкості та багато іншого інше. І хоча сьогодні є безліч бібліотек, щоб реалізувати ці функції безпосередньо в коді, з Istio ви можете отримати все те ж саме, нічого не змінюючи у своєму коді.
Згідно з sidecar'ною моделлю, Istio виконується в Linux-контейнері, який розташовується в одному -pod'є з контрольованим сервісом та впроваджує (inject) та отримує (extract) функціональність та інформацію відповідно до заданої конфігурації. Підкреслимо, це ваша власна конфігурація, і вона живе поза вашим кодом. Тому код стає набагато простіше і коротше.
Що ще важливо, операційна складова мікросервісів при цьому виявляється ніяк не пов'язана з самим кодом, а отже, їх експлуатацію можна спокійно передати ІТ-фахівцям. Справді, чому розробник повинен відповідати за circuit breaker'и та fault injection? Реагувати – так, але обробляти їх та створювати? Якщо прибрати все це з коду, програмісти зможуть повністю зосередитися на прикладному функціоналі. Та й сам код стане коротшим і простішим.
Сервісна сітка
Istio, що реалізує функції управління мікросервісами поза їхнім кодом - це і є концепція сервісної сітки Service Mesh. Інакше висловлюючись, це скоординована група з однієї чи кількох бінарників, які утворюють сітку мережевих функцій.
Як Istio працює з мікросервісами
Ось як виглядає робота sidecar-контейенрів із зв'язкою з и з висоти пташиного польоту: запускаєте екземпляр Minishift, створюєте проект для Istio (назвемо його istio-system), встановлюєте та запускаєте всі пов'язані з Istio компоненти. Потім, у міру створення проектів та pod'ів, додаєте конфігураційні відомості у свої deployment''и, і ваші pod'и починають використовувати Istio. Спрощено діаграма виглядає так:
Тепер можна змінювати установки Istio, щоб, наприклад, організувати fault injection, підтримку або інші можливості Istio - і все це абсолютно не чіпаючи код самих програм. Допустимо, ви хочете перенаправити весь веб-трафік від користувачів свого найбільшого клієнта (Foo Corporation) на нову версію сайту. Для цього достатньо створити правило маршрутизації Istio, яке шукатиме @foocorporation.com в ідентифікаторі користувача та виконуватиме відповідне перенаправлення. Для решти користувачів нічого не зміниться. А ви тим часом спокійно тестуватимете нову версію сайту. І зауважте, для цього зовсім не треба залучати розробників.
І чи дорого за це доведеться заплатити?
Не. Istio працює досить швидко, він написаний на і створює зовсім невеликий оверхід. Крім того, можливий програш в онлайн-продуктивності компенсується приростом продуктивності розробників. Принаймні теоретично: не забувайте, що час розробників коштує дорого. Що стосується витрат на ПЗ, то Istio - це софт з відкритим кодом, тому отримати та використовувати його можна безкоштовно.
Освойте самі
Команда Red Hat Developer Experience Team розробила поглиблене практичне по Istio (англійською). Воно працює на Linux, MacOS і Windows, а код представлений у варіантах Java і Node.js.
10 інтерактивних занять з Istio
Блок 1 - Для початківців
Введення в Istio
30 хвилин
Знайомимось із Service Mesh, вчимося встановлювати Istio у Kubernetes кластері OpenShift.
Розгортання мікросервісів у Istio
30 хвилин
Використовуємо Istio, щоб розгорнути три мікросервіси з Spring Boot та Vert.x.
Блок 2 – середній рівень
Моніторинг та трасування в Istio
60 хвилин
Вивчаємо вбудовані засоби моніторингу Istio, метрики, що настроюються, а також OpenTracing через Prometheus і Grafana.
Проста маршрутизація в Istio
60 хвилин
Вчимося керувати маршрутизацією в Istio за допомогою простих правил.
Розширені правила маршрутизації
60 хвилин
Знайомимося з розумною маршрутизацією в Istio, керуванням доступом, балансуванням навантаження та обмеженням швидкості.
Блок 3 – досвідчений користувач
Fault Injection в Istio
60 хвилин
Вивчаємо сценарії обробки відмов у розподілених програмах, створюючи помилки HTTP та мережеві затримки, вчимося застосовувати хаос-інжинірингу для відновлення середовища.
Circuit Breaker в Istio
30 хвилин
Встановлюємо Siege для стрес-тестування сайтів та вчимося забезпечити відмовостійкість бекенду за допомогою повторів, circuit breaker та pool ejection.
Egress та Istio
10 хвилин
Використовуємо маршрути Egress для створення правил взаємодії внутрішніх сервісів із зовнішніми API та сервісами.
Istio та Kiali
15 хвилин
Вчимося використовувати Kiali для отримання загальної картини сервісної сітки та вивчення потоків запитів та даних.
Mutual TLS в Istio
15 хвилин
Створюємо Istio Gateway та VirtualService, потім докладно вивчаємо mutual TLS (mTLS) та його налаштування.
Блок 3.1 - Глибоке занурення: Istio Service Mesh для мікросервісів
Про що книга:
- Що таке сервісна сітка Service Mesh.
- Система Istio та її роль у мікросервісній архітектурі.
- Використання Istio під час вирішення наступних завдань:
- Відмовостійкість;
- Маршрутизація;
- Хаос-тестування;
- Безпека;
- Збір телеметрії засобами трасування, метрик та Grafana.
Серія статей з сервісних сіток та Istio
Спробуйте самі
Ця серія постів не ставить за мету забезпечити глибоке занурення у світ Istio. Ми просто хочемо познайомити вас із самою концепцією і, можливо, надихнути самостійно спробувати Istio. Це можна зробити абсолютно безкоштовно, і Red Hat надає всі необхідні інструменти, щоб почати освоювати OpenShift, Kubernetes, Linux-контейнери та Istio, а саме: , та інші ресурси на нашому . Не варто відкладати, почніть сьогодні!
Правила маршрутизації Istio: надсилаємо сервіс-запити туди, куди потрібно
и чудово справляються з тим, щоб звернення до маршрутизувалися до потрібних pod'ів. У цьому є одна з цілей існування Kubernetes – маршрутизація та балансування навантаження. А якщо вам потрібна більш тонка і витончена маршрутизація? Наприклад, щоб одночасно використовувати дві версії мікросервісу. Як тут допоможуть правила маршрутизації Istio Route Rules?
Правила маршрутизації – це правила, які власне задають вибір маршруту. За будь-якого рівня складності системи загальний принцип роботи цих правил залишається простим: запити маршрутизуються на основі певних параметрів та значень заголовків HTTP.
Подивимося на прикладах:
Kubernetes замовчуванням: тривіальне "50 на 50"
У прикладі ми покажемо, як одночасно використовувати в OpenShift дві версії мікросервісу, назвемо їх v1 і v2. Кожна версія запускається у власному pod'і Kubernetes, і за умовчанням тут працює рівномірно збалансована циклічна маршрутизація (evenly balanced round robin routing). Кожен pod отримує свою частку запитів за кількістю його екземплярів мікросервісу, інакше кажучи, реплік. Istio дозволяє змінювати цей баланс вручну.
Допустимо, ми розгорнули на OpenShift дві версії нашого рекомендаційного сервісу, recommendation-v1 та recommendation-v2.
На рис. 1 видно, що коли кожен сервіс представлений в одному примірнику, запити рівномірно чергуються між ними: 1-2-1-2-… Саме так маршрутизація Kubernetes працює за замовчуванням:
Зважений розподіл між версіями
На рис. 2 показано, що буде, якщо збільшити кількість реплік сервісу v2 з одного до двох (це робиться командою oc scale -replicas=2 deployment/recommendation-v2). Як бачимо, запити між v1 і v2 тепер діляться щодо «один до трьох»: 1-2-2-1-2-2-…:
Ігнор версії за допомогою Istio
Istio дозволяє легко змінити розподіл запитів потрібним чином. Наприклад, надсилати весь трафік тільки на recommendation-v1 за допомогою наступного yaml-файлу Istio:
Тут треба звернути увагу ось на що: pod'и вибираються згідно з мітками. У прикладі використовується мітка v1. Параметр «weight: 100» означає, що 100% трафіку маршрутизуватиметься на всі pod'и сервісу, які мають мітку v1.
Директивний розподіл між версіями (Canary Deployment)
Далі, використовуючи параметр weight, можна спрямовувати трафік до обох pod'ів, ігноруючи кількість екземплярів мікросервісів, запущених у кожному з них. Наприклад, тут ми директивно спрямовуємо 90% трафіку на v1 та 10% – на v2:
Окрема маршрутизація мобільних користувачів
Насамкінець покажемо, як примусово маршрутизувати трафік мобільних користувачів на сервіс v2, а всіх інших – на v1. Для цього ми за допомогою регулярних виразів аналізуємо значення user-agent у заголовку запиту:
Тепер ваша черга
Приклад із регулярними виразами для аналізу заголовків повинен мотивувати вас на пошук власних варіантів застосування правил маршрутизації Istio. Тим більше, що можливості тут відкриваються дуже великі, оскільки значення заголовків можна формувати у вихідному коді додатків.
І пам'ятайте, що Ops, а не Dev
Все, що ми показали в прикладах вище, робиться без найменших змін у вихідному коді, за винятком тих випадків, коли треба формувати спеціальні заголовки запитів. Istio стане в нагоді як розробникам, які, наприклад, зможуть застосовувати його на етапі тестування, так і фахівцям з експлуатації ІТ-систем, яким він сильно допоможе в продакшні.
Тож повторимо лейтмотив цієї серії постів: вам не треба нічого міняти у своєму коді. Не слід збирати нові образи або запускати нові контейнери. Все це реалізується поза кодом.
Увімкніть уяву
Тільки уявіть, які перспективи відкриває аналіз заголовків за допомогою регулярних виразів. Хочете перенаправляти вашого найбільшого клієнта на спеціальну версію своїх ? Легко! Чи потрібна окрема версія для браузера Chrome? Не проблема! Ви можете маршрутизувати трафік практично за будь-якою його характеристикою.
Спробуйте самі
Читати про Istio, Kubernetes і OpenShift – це одне, але чому б не помацати все своїми руками? Команда підготувала докладний посібник (англійською), який допоможе вам максимально швидко освоїти ці технології. Керівництво також 100% open source, тому воно розміщене у відкритому доступі. Файл працює на macOS, Linux і Windows, а вихідний код є у варіантах Java та node.js (скоро будуть версії і іншими мовами). Просто відкрийте у своєму браузері відповідний git-репозиторій .
У наступному пості: відпрацьовуємо проблеми гарно
Сьогодні ви побачили, на що здатні правила маршрутизації Istio. А тепер уявіть все те ж саме, але тільки стосовно обробки помилок. Саме про це ми й розповімо у наступному пості.
Джерело: habr.com