Налагодження Envoy і Istiod
Istio надає дві дуже корисні команди для діагностики проблем із конфігурацією управління трафіком: команди proxy-status
та proxy-config
. Команда proxy-status
дозволяє отримати огляд вашої мережі та визначити проксі, що спричиняє проблему. Потім команду proxy-config
можна використовувати для перевірки конфігурації Envoy та діагностики проблеми.
Якщо ви хочете спробувати команди, описані нижче, ви можете:
- Мати кластер Kubernetes з встановленим Istio і Bookinfo (як описано в кроках установки5 і кроках установки Bookinfo).
АБО
- Використовувати подібні команди для свого застосунку, що працює в кластері Kubernetes.
Отримання огляду вашої мережі
Команда proxy-status
дозволяє отримати загальну картину вашої мережі. Якщо ви підозрюєте, що один з ваших sidecar-проксі не отримує конфігурацію або знаходиться поза синхронізацією, команда proxy-status
це покаже.
Якщо якийсь проксі відсутній у цьому списку, це означає, що він наразі не підключений до екземпляру Istiod, і тому не отримує конфігурації.
SYNCED
означає, що Envoy підтвердив отримання останньої конфігурації, надісланої Istiod.NOT SENT
означає, що Istiod нічого не надсилав Envoy. Зазвичай це тому, що Istiod не має, що надіслати.STALE
означає, що Istiod надіслав оновлення Envoy, але не отримав підтвердження. Це зазвичай свідчить про проблеми з мережею між Envoy та Istiod або помилки у самому Istio.
Отримання відмінностей між Envoy та Istiod
Команда proxy-status
також може використовуватися для отримання відмінностей між конфігурацією, завантаженою Envoy, та конфігурацією, яку надсилає Istiod, вказавши ідентифікатор проксі. Це допоможе визначити, що саме знаходиться поза синхронізацією та де може бути проблема.
Тут ви можете побачити, що listeners і routes збігаються, але кластери не синхронізовані.
Глибоке занурення у конфігурацію Envoy
Команда proxy-config
використовується для перевірки того, як налаштований конкретний екземпляр Envoy. Це дозволяє точно визначити проблеми, які неможливо виявити, просто переглядаючи конфігурацію Istio та власні ресурси. Щоб отримати базовий огляд кластерів, listeners або routes для конкретного podʼа, використовуйте наступну команду (замінюючи clusters
на listeners
або routes
, якщо це необхідно):
Ця команда виведе список кластерів, які використовуються Envoy у зазначеному podʼі, що допоможе виявити відмінності або проблеми, які можуть спричиняти несправності у маршрутизації трафіку або інших аспектах роботи проксі.
Щоб налагодити Envoy, вам потрібно розуміти, як взаємодіють кластери, слухачі (listeners), маршрути (routes) та точки доступу (endpoints) Envoy. Ми будемо використовувати команду proxy-config
з прапорцем -o json
і фільтрами, щоб відстежити, як Envoy вирішує, куди надсилати запит з podʼа productpage
до podʼа reviews
на reviews:9080
.
Якщо ви запитаєте звіт про слухачів на podʼі, ви помітите, що Istio генерує наступні listeners:
- Слухач на
0.0.0.0:15006
, який отримує весь вхідний трафік до podʼа, і слухач на0.0.0.0:15001
, який отримує весь вихідний трафік з podʼа, а потім передає запит віртуальному слухачу. - Віртуальний слухач на кожну IP-адресу сервісу для не-HTTP вихідного TCP/HTTPS трафіку.
- Віртуальний слухач на IP-адресу podʼа для кожного відкритого порту для вхідного трафіку.
- Віртуальний слухач на
0.0.0.0
для кожного HTTP-порту для вихідного HTTP-трафіку.
Ці слухачі забезпечують передачу трафіку між podʼами в сервісній мережі, керуючи різними типами зʼєднань і трафіком.
- Слухач на
З наведеного вище звіту видно, що кожен sidecar має слухача, привʼязаного до
0.0.0.0:15006
, куди IP tables маршрутизує весь вхідний трафік до podʼа, і слухача, привʼязаного до0.0.0.0:15001
, куди IP tables маршрутизує весь вихідний трафік з podʼа. Слухач на0.0.0.0:15001
передає запит віртуальному слухачу, який найкраще відповідає початковому призначенню запиту, якщо він зможе знайти відповідний. В іншому випадку він надсилає запит доPassthroughCluster
, який безпосередньо зʼєднується з кінцевим призначенням.Наш запит є вихідним HTTP-запитом на порт
9080
, що означає, що він передається до віртуального слухача на0.0.0.0:9080
. Цей слухач потім шукає конфігурацію маршруту у своєму налаштованому RDS (Route Discovery Service). У цьому випадку він буде шукати маршрут9080
в RDS, налаштованому Istiod (через ADS — Aggregated Discovery Service).Конфігурація маршруту для порту
9080
має лише віртуальний хост для кожного сервісу. Оскільки наш запит спрямований до сервісуreviews
, Envoy вибере віртуальний хост, який відповідає домену запиту. Після того, як домен узгоджено, Envoy шукає перший маршрут, який відповідає запиту. У цьому випадку немає жодної складної маршрутизації, тому є лише один маршрут, який відповідає всім запитам. Цей маршрут вказує Envoy на надсилання запиту до кластераoutbound|9080||reviews.default.svc.cluster.local
.Цей кластер налаштований для отримання асоційованих точок доступу від Istiod (через ADS). Тому Envoy використовуватиме поле
serviceName
як ключ для пошуку списку точок доступу та проксіювання запиту до однієї з них.Щоб переглянути точки доступу, які наразі доступні для цього кластера, використовуйте команду
proxy-config endpoints
.
Інспектування конфігурації bootstrap
До цього ми розглядали конфігурацію, отриману (переважно) від Istiod, однак Envoy потребує деякої конфігурації bootstrap, яка включає інформацію, наприклад, де можна знайти Istiod. Щоб переглянути це, використовуйте наступну команду:
Перевірка підключення до Istiod
Перевірка підключення до Istiod є корисним кроком для усунення проблем. Кожен контейнер проксі в сервісній мережі повинен мати змогу спілкуватися з Istiod. Це можна зробити кількома простими кроками:
Створіть под
curl
:Перевірте підключення до Istiod за допомогою
curl
. Наступний приклад викликає API реєстрації v1 з використанням стандартних параметрів конфігурації Istiod і увімкненим взаємним TLS:
Ви повинні отримати відповідь, яка містить версію Istiod.
Яка версія Envoy використовується в Istio?
Щоб дізнатися версію Envoy, використану в розгортанні, ви можете зробити exec
в контейнер і запитати точку доступу server_info
: