Дослідження Istio: Міць Service Mesh у Kubernetes

текст перекладу
Більшість yaml файлів були взяті з репозиторію на GitHub, наданого за посиланням https://github.com/aboullaite/service-mesh, перегляньте його і не забудьте підтримати.

Особлива подяка пану Driss Allaki за керівництво на нашому шляху до вивчення Istio.

Ось вихідний код для проекту: github link

Service mesh — Istio:

У сучасному світі більшість додатків побудовані з використанням мікросервісів — невеликих, незалежних сервісів, які працюють разом для створення більшої системи. Хоча мікросервіси надають багато переваг, вони також створюють певні виклики:

• Як забезпечити безпечну комунікацію між сервісами?
• Як моніторити та контролювати трафік між сервісами?
• Як переконатися, що наша система надійна та масштабована?

Саме тут і з’являється Service Mesh. Service mesh — це шар, який керує комунікацією між мікросервісами, спрощуючи обробку безпеки, контролю трафіку та моніторингу. Замість того, щоб додавати цю логіку до кожного сервісу, service mesh займається цим автоматично.

Чому Istio?

Istio — одна з найбільш популярних рішень для service mesh. Він допомагає розробникам:

✅ Управляти трафіком — контролювати, як запити передаються між сервісами.
✅ Покращити безпеку — шифрувати трафік і обробляти автентифікацію.
✅ Додавати спостережуваність — моніторинг і трасування поведінки сервісів.

У цьому блозі ми розглянемо як працює Istio, його основні функції та як налаштувати його в Kubernetes. Незалежно від того, чи ви новачок у service mesh чи хочете підвищити свої навички, цей посібник допоможе вам почати роботу з Istio. 🚀

Щоб зрозуміти та експериментувати з Istio, нам спочатку потрібен додаток на основі мікросервісів, який ми можемо розгорнути і керувати за допомогою service mesh. Для цього блогу ми будемо використовувати Систему управління гаражем, реальний приклад, що складається з кількох мікросервісів, які працюють разом.

Оскільки наш фокус тут на Istio та як він покращує комунікацію між мікросервісами, ми не будемо занурюватися глибоко в архітектуру мікросервісів. Однак, якщо вам цікаво дізнатися більше про проектування та впровадження мікросервісів, ми вже розглядали це в попередньому блозі. Ви можете ознайомитися з ним за посиланням: https://medium.com/@blogs4devs/hello-2230d29c939c

Тепер давайте поглянемо на архітектуру нашого додатку та на те, як його сервіси взаємодіють перед інтеграцією Istio.

Архітектура

Ця архітектура описує систему управління гаражем на основі мікросервісів, де кожен сервіс відповідає за конкретну частину системи.

Client Service управляє інформацією про клієнтів, використовуючи REST API для взаємодії з базою даних MySQL для зберігання даних. Vehicle Service робить те ж саме для записів про транспортні засоби, також використовуючи REST та MySQL. Maintenance Service обробляє завдання обслуговування та операційні завдання, зокрема відправку електронних листів клієнтам через сторонній сервіс електронної пошти, який працює у фоновому режимі для уникнення затримок. Invoice Service відрізняється тим, що використовує MongoDB, яка краще підходить для зберігання гнучких і складних даних. Він також використовує GraphQL, дозволяючи користувачам запитувати лише необхідні дані, що робить доступ до даних швидшим та ефективнішим. CDC (Change Data Capture) Service підтримує узгодженість даних, збираючи оновлення з Client, Vehicle і Maintenance сервісів і зберігаючи їх у базі даних MongoDB для рахунків. Це зменшує необхідність прямої комунікації між сервісами та забезпечує безперебійну роботу навіть у разі тимчасової недоступності одного з сервісів.
текст перекладу
Для комунікації між сервісами система використовує OpenFeign для виконання REST викликів, що забезпечує швидку та точну роботу, наприклад, перевірку ідентифікаторів клієнтів при створенні запису транспортного засобу.

Щоб уникнути повторюваного коду, використовується Common/Nexus Service для спільного використання загальних компонентів, таких як моделі даних і утиліти, зберігаються в репозиторії Nexus для легкого доступу, навіть у контейнеризованих середовищах.

Нарешті, Gateway Service виступає як центральна точка входу, направляючи запити до правильного сервісу, балансуючи навантаження і пропонуючи єдиний інтерфейс Swagger для зручного вивчення всіх сервісів.

Розгортання

Для розгортання додатку ми будемо використовувати Kubernetes (K8s) для ефективної оркестрації контейнерів і управління ними.

Ми почнемо з створення простору імен для нашого проекту:

Пояснимо пізніше, чому ми використовували injection Istio.

Оскільки однакова робота буде виконуватися на всіх сервісах, ми розглянемо приклад client-service.

Давайте почнемо з розгортання client service:

Цей маніфест Kubernetes для розгортання налаштовує client-service в просторі імен garage-ns. Він створює одну репліку пода, що запускає Spring Boot додаток, використовуючи контейнерний образ vinesen1/microservice-project-client-service:v5 і відкриває порт 8080. Змінні середовища для підключення до бази даних динамічно налаштовуються: URL і ім'я користувача отримуються з ConfigMap (client-config), а пароль безпечно надається через Secret (client-secret). Ці налаштування забезпечують модульне і безпечне управління конфігурацією та чутливими даними. Мітки, такі як app: client-service і version: v1, використовуються для ідентифікації пода і організації.

Цей Kubernetes ConfigMap, названий client-config і розташований в просторі імен garage-ns, надає неконфіденційні конфігураційні дані для мікросервісу client-service. Він визначає ім'я користувача бази даних (MYSQLUSER), назву бази даних (MYSQLDATABASECLIENT) і JDBC URL (MYSQLURL), який використовується для підключення до MySQL сервісу mysql-client-service на порту 3306. URL включає параметри для створення бази даних, якщо вона не існує, вимикання SSL, налаштування часового поясу сервера на UTC і дозвіл на отримання публічних ключів для безпечних підключень. Цей ConfigMap спрощує управління конфігурацією, виводячи ці налаштування за межі коду, дозволяючи динамічні оновлення без необхідності змінювати сам код.

А ось і секрет, що містить пароль mysql і закодований у форматі base64.

Цей Kubernetes Service, названий client-service і розташований в просторі імен garage-ns, визначає headless сервіс для мікросервісу client-service. Він зв'язує порт 8080 на сервісі з портом 8080 на цільових подах і використовує селектор з міткою app: client-service для ідентифікації пов'язаних подів. Налаштування clusterIP: None робить сервіс headless, дозволяючи пряме спілкування між подами.

Ця конфігурація Kubernetes налаштовує базу даних MySQL за допомогою StatefulSet і headless Service, обидва з назвою mysql-client-service, в просторі імен garage-ns. StatefulSet забезпечує єдиний MySQL под (replicas: 1) з постійним сховищем, використовуючи PersistentVolumeClaim (mysql-client-data) розміром 1Gi, змонтований в /var/lib/mysql. Под використовує образ MySQL (mysql:latest) і налаштовується за допомогою змінних середовища для користувача бази даних, назви, кореневого пароля та пароля користувача, отриманих з ConfigMap (client-config) і Secret (client-secret).
текст перекладу
Ассоційований headless Service (clusterIP: None) відкриває MySQL на порту 3306 і дозволяє безпосереднє спілкування між подами, що робить його придатним для додатків, які потребують прямого доступу до бази даних, таких як мікросервіс client-service.

Ось виведення:

Можливо, ви запитаєте, чому ми маємо два поди; ми дізнаємося відповідь пізніше, але на даний момент скажемо, що у нас є pod для клієнтського сервісу, а також інший корисний pod, який ми використовуватимемо пізніше.

Ось також наш MySQL statefulset.

Що стосується сервісів:

Ту ж саму роботу виконуємо для інших сервісів:

Як ви бачите, це фронтенд, подібний до інших сервісів.

Тепер саме час побачити всі поди та сервіси, що працюють:

Як бачите, все працює як очікувалось.

Тепер можемо точно сказати, що наш кластер Kubernetes працює як очікується, але зачекайте, ми ще не закінчили, зараз потрібно пояснити додаткові контейнери, присутні на поді.

Service Mesh

Що таке service mesh?

Service Mesh — це інфраструктурний шар, який управляє комунікацією між сервісами в архітектурах мікросервісів, пропонуючи такі можливості, як маршрутизація трафіку, балансування навантаження, відкриття сервісів і безпека через взаємне TLS (mTLS). Він покращує спостережуваність завдяки метрикам, логуванню та розподіленому трасуванню, одночасно підвищуючи стійкість за допомогою таких механізмів, як повторні спроби, переведення на резервні сервіси та автоматичне відключення. Service mesh, такі як Istio, Linkerd або Consul Connect, використовують легкі проксі-сервіси sidecar (наприклад, Envoy), що розгортаються поруч із кожним сервісом для обробки мережевого трафіку прозоро, дозволяючи реалізувати розширену функціональність без необхідності змінювати код додатка. Це особливо корисно в масштабних і складних системах, де управління комунікацією між сервісами вручну є неефективним.

Існує багато типів service mesh, але для нашого проекту ми будемо використовувати Istio.

Спочатку ми увімкнемо Istio в нашому кластері, активувавши його в просторі імен:

Тепер давайте перевіримо деякі поди та побачимо, який ще под був доданий:

Як ви бачите, у нас є pod для клієнтського сервісу, а також два інших контейнери:

• Istio init: Контейнер istio-init відповідає за налаштування мережевого середовища для активації можливостей Istio. Коли pod з ін’єкцією Istio запускається, контейнер istio-init спочатку запускається як init контейнер. Він змінює конфігурацію мережі пода так, щоб весь трафік (вхідний і вихідний) маршрутизувався через контейнер istio-proxy sidecar.

Init контейнери спеціально призначені для одноразових налаштувань, які необхідно виконати перед тим, як основні контейнери додатка стартують.
текст перекладу
Після виконання своєї задачі контейнер istio-init завершує свою роботу і не зберігається, не працюючи поряд з основними контейнерами.

• Istio-proxy: Контейнер istio-proxy є проксі-сервером Envoy, який виступає як data plane в Istio. Він обробляє маршрутизацію трафіку, балансування навантаження, безпеку (наприклад, взаємне TLS) і спостережуваність для додатка.

Це поєднання дозволяє Istio безперешкодно інтегрувати розширені мережеві функції у ваші додатки без необхідності змінювати код додатка.

Але як вони додаються?

Ну, для кожного сервісу ми визначаємо конфігурацію, що містить правило призначення (destination rule) і віртуальний сервіс (virtual service).

• Destination rule: визначає політики, які застосовуються до трафіку для конкретного сервісу після того, як трафік був маршрутизований за допомогою Virtual Service.
• Virtual Service: визначає, як запити маршрутизуються до сервісу. Він виступає як “віртуальна кінцева точка” для сервісу, дозволяючи детально налаштовувати маршрутизацію трафіку.

Ось конфігурації для клієнтського сервісу:

Представлені конфігурації Istio VirtualService і DestinationRule керують маршрутизацією трафіку і політиками для клієнтського сервісу в просторі імен garage-ns. VirtualService вказує, що всі HTTP-запити до хоста client-service повинні бути маршрутизовані до конкретної підмножини під назвою v1 цього самого сервісу. DestinationRule доповнює це, визначаючи підмножину v1, яка ідентифікується за допомогою міток version: v1 і name: client-service. Така конфігурація забезпечує направлення запитів до конкретної версії сервісу, дозволяючи мати кращий контроль, наприклад, для розгортання і тестування нових версій (наприклад, канарійні деплойменти). Комбінація цих двох ресурсів дозволяє динамічно управляти трафіком і забезпечувати політики для підмножин сервісів.

Після застосування цих конфігурацій до всіх подів нашого кластера ми можемо перевірити віртуальні сервіси Istio

Існує ще один компонент, який потрібно додати — це шлюз Istio.

Istio Gateway — це спеціальний тип Envoy proxy, налаштований для управління вхідним і вихідним трафіком для сервісів в service mesh. Він виступає як точка входу або виходу для mesh, забезпечуючи централізовану точку для контролю трафіку, який заходить або виходить з Kubernetes-кластера. Шлюзи часто використовуються для управління трафіком, що надходить від зовнішніх клієнтів, таких як браузери або API, і маршрутизації його до відповідних сервісів в mesh.

У нашому випадку ось конфігурація для шлюзу Istio:

Конфігурація Istio Gateway налаштовує вхідний шлюз під назвою garage-gateway в просторі імен garage-ns. Вона використовує селектор istio: ingressgateway для напрямку трафіку до сервісу шлюза Istio, який управляє вхідним трафіком до кластера. Шлюз прослуховує порт 80 за допомогою протоколу HTTP і приймає трафік для будь-якого хоста, що позначено за допомогою підстановочних символів "*". Це означає, що він оброблятиме весь вхідний HTTP трафік, незалежно від запитуваного домену. Ця конфігурація шлюза зазвичай використовується для маршрутизації зовнішнього трафіку в mesh.

Тепер ми використаємо VirtualService для налаштування правил маршрутизації для вхідного трафіку, який надходить до шлюзу Istio. VirtualService направляє запити на основі їх префіксів URI до відповідних сервісів у mesh. Наприклад, трафік з префіксом /ui маршрутизується до фронтенду на порт 8080, а весь інший трафік — до gateway-service на порт 8999.
текст перекладу
Ця конфігурація гарантує, що запити ефективно маршрутизуються до їхніх призначених точок, забезпечуючи безперебійну комунікацію між сервісами та оптимізуючи управління трафіком в кластері.

Для вхідного шлюзу ми можемо знайти його в просторі імен Istio.

Що стосується шлюзу:

Управління трафіком

Управління трафіком є однією з ключових функцій Istio, що дозволяє контролювати, як запити проходять між мікросервісами. Це допомагає оптимізувати продуктивність, забезпечити надійність і дозволяє впроваджувати стратегії безперебійного розгортання. Дві популярні стратегії розгортання, які підтримує Istio, — це Canary Deployments та Blue-Green Deployments.

a- Canary деплойменти

Canary deployment — це стратегія поетапного розгортання, коли нова версія сервісу спочатку відкривається для невеликої частини трафіку, що дозволяє на ранніх етапах виявити проблеми перед повним переходом на нову версію.

Ми вирішили обробляти управління трафіком на фронтенді. Спочатку ми розгорнули дві версії.

Ми додали сервіс, щоб покрити всі поди фронтенду, тож кожен запит, надісланий до фронтенду, проходить через цей сервіс.

Тепер для canary деплойменту додається нове правило DestinationRule, яке визначає підмножини для обох версій, v1 і v2, та додається VirtualService, щоб керувати трафіком. 80% трафіку буде перенаправлено до першої версії (v1), а 20% до другої версії (v2).

b-Blue-Green деплойменти

Blue-Green Deployment — це стратегія для зменшення часу простою та мінімізації ризику помилок під час розгортання нової версії програми. Основна ідея полягає в тому, щоб мати дві середовища, які часто називають “синім” і “зеленим”, де одне середовище активно (синє), а інше (зелене) знаходиться в режимі очікування. Після тестування нової версії в зеленому середовищі можна переключити трафік на зелене середовище, зробивши його активним. Якщо виникне проблема, можна легко повернути трафік назад до синього середовища.

Для кожної версії фронтенду ми повинні налаштувати як DestinationRule, так і VirtualService.

Для версії 1:

Для версії 2:

Тепер ми можемо легко переключатися між двома версіями, просто застосовуючи YAML-конфігурацію потрібної версії.

Спостережуваність

Спостережуваність є критично важливою в архітектурі мікросервісів для ефективного моніторингу, аналізу та виправлення помилок додатків. Istio надає потужні інструменти для візуалізації, моніторингу та трасування, щоб отримати уявлення про поведінку сервісів і їх взаємодії.

a- Візуалізація мікросервісів

Щоб візуалізувати мікросервіси та їх зв'язки, ми використовуємо цікаву програму під назвою KIALI.

Kiali — це інструмент з відкритим кодом для спостережуваності та управління, спеціально розроблений для service meshes, таких як ті, що реалізуються за допомогою Istio.
текст перекладу
Ця конфігурація забезпечує ефективне маршрутизування запитів до їх призначених точок, дозволяючи безперебійну комунікацію між сервісами та оптимізуючи управління трафіком всередині кластера.

Для вхідного шлюзу ми можемо знайти його в просторі імен Istio.

Що стосується шлюзу:

Управління трафіком

Управління трафіком є однією з ключових функцій Istio, що дозволяє контролювати, як запити проходять між мікросервісами. Це допомагає оптимізувати продуктивність, забезпечити надійність і дозволяє впроваджувати стратегії безперебійного розгортання. Дві популярні стратегії розгортання, які підтримує Istio, — це Canary Deployments та Blue-Green Deployments.

a- Canary деплойменти

Canary deployment — це стратегія поетапного розгортання, коли нова версія сервісу спочатку відкривається для невеликої частини трафіку, що дозволяє на ранніх етапах виявити проблеми перед повним переходом на нову версію.

Ми вирішили обробляти управління трафіком на фронтенді. Спочатку ми розгорнули дві версії.

Ми додали сервіс, щоб покрити всі поди фронтенду, тож кожен запит, надісланий до фронтенду, проходить через цей сервіс.

Тепер для canary деплойменту додається нове правило DestinationRule, яке визначає підмножини для обох версій, v1 і v2, та додається VirtualService, щоб керувати трафіком. 80% трафіку буде перенаправлено до першої версії (v1), а 20% до другої версії (v2).

b-Blue-Green деплойменти

Blue-Green Deployment — це стратегія для зменшення часу простою та мінімізації ризику помилок під час розгортання нової версії програми. Основна ідея полягає в тому, щоб мати дві середовища, які часто називають “синім” і “зеленим”, де одне середовище активно (синє), а інше (зелене) знаходиться в режимі очікування. Після тестування нової версії в зеленому середовищі можна переключити трафік на зелене середовище, зробивши його активним. Якщо виникне проблема, можна легко повернути трафік назад до синього середовища.

Для кожної версії фронтенду ми повинні налаштувати як DestinationRule, так і VirtualService.

Для версії 1:

Для версії 2:

Тепер ми можемо легко переключатися між двома версіями, просто застосовуючи YAML-конфігурацію потрібної версії.

Спостережуваність

Спостережуваність є критично важливою в архітектурі мікросервісів для ефективного моніторингу, аналізу та виправлення помилок додатків. Istio надає потужні інструменти для візуалізації, моніторингу та трасування, щоб отримати уявлення про поведінку сервісів і їх взаємодії.

a- Візуалізація мікросервісів

Щоб візуалізувати мікросервіси та їх зв'язки, ми використовуємо цікаву програму під назвою KIALI.

Kiali — це інструмент з відкритим кодом для спостережуваності та управління, спеціально розроблений для service meshes, таких як ті, що реалізуються за допомогою Istio.
текст перекладу
З mTLS (Mutual Transport Layer Security) і клієнт, і сервер презентують та перевіряють цифрові сертифікати під час процесу TLS-рукопожаття.

Для mTLS це може бути здійснено завдяки ISTIO, і конкретно ми повинні додати деякі специфічні налаштування.

В Istio Peer Authentication і Destination Rules працюють разом для забезпечення безпечної комунікації між сервісами за допомогою mutual TLS (mTLS). Peer Authentication визначає, як сервіс обробляє вхідний трафік, вказуючи режими mTLS, такі як STRICT (вимагає mTLS), PERMISSIVE (дозволяє як mTLS, так і відкритий текст), або DISABLE. Наприклад, ресурс PeerAuthentication у режимі STRICT гарантує, що всі вхідні з’єднання до сервісу повинні використовувати mTLS, що забезпечує безпечну та зашифровану комунікацію.

З іншого боку, Destination Rules налаштовують політики для вихідного трафіку з сервісу, такі як балансування навантаження та налаштування mTLS. Вони гарантують, що трафік до конкретного сервісу буде зашифрований і аутентифікований за допомогою mTLS, керованого Istio. Наприклад, DestinationRule з режимом ISTIO_MUTUAL гарантує, що комунікація до певного сервісу буде захищена за допомогою mTLS. Разом Peer Authentication застосовує mTLS для вхідного трафіку, а Destination Rules застосовують mTLS для вихідного трафіку, забезпечуючи кінцеву безпеку в інтерфейсах сервісів.

Розглянемо приклад сервісу клієнта.

Цей Istio DestinationRule визначає налаштування для маршрутизації трафіку та політики для сервісу клієнта в просторі імен garage-ns. Хост вказує на сервіс (client-service), до якого застосовується правило. Трафік політики вимагає mTLS (Mutual TLS) у режимі ISTIO_MUTUAL, що забезпечує безпечну та аутентифіковану комунікацію між сервісами в мережі. Підмножини визначають специфічні версії сервісу або групи на основі міток; тут підмножина, названа v1, відповідає подам з мітками version: v1 та name: client-service. Ця конфігурація дозволяє більш точний контроль за маршрутизацією трафіку та безпечною комунікацією між версіями сервісів.

Цей ресурс PeerAuthentication налаштовує mTLS (Mutual TLS) для безпечної комунікації в просторі імен garage-ns, специфічно для подів клієнт-сервісу, позначених мітками name: client-service і version: v1. Селектор забезпечує, що ця політика застосовується лише до подів з цими мітками. Поле mTLS встановлює режим STRICT, що означає, що всі вхідні з’єднання до вибраних подів повинні використовувати mTLS. Це забезпечує безпечну та аутентифіковану комунікацію, гарантуючи, що тільки довірені клієнти в межах мережі можуть підключатися до цих подів.

Ця конфігурація застосовується до всіх сервісів без винятку.

Наприкінці ми можемо перевірити, що mTLS увімкнено в нашому кластері, як можна побачити на Kiali.

Тепер ось тестовий випадок, де ми вимкнули mTLS для client-service і намагаємося додати транспортний засіб. Зазвичай, у vehicle-service увімкнено mTLS, тому коли він відправляє REST API запит до client-service для перевірки існування клієнта, запит не буде успішним. Ця поведінка демонструється на Kiali.

Спочатку додамо наступну конфігурацію:

Ця конфігурація вимикає mTLS для client-service в просторі імен garage-ns. Ресурс PeerAuthentication встановлює mtls.mode: DISABLE для подів з мітками name: client-service, дозволяючи комунікацію в текстовому вигляді без необхідності в mTLS для вхідного трафіку. DestinationRule вказує на той самий сервіс (client-service) і гарантує, що вихідний трафік до цього сервісу також буде використовувати комунікацію в текстовому вигляді, встановлюючи tls.mode: DISABLE.
текст перекладу
Крім того, підмножини визначають підмножину під назвою v1 для маршрутизації трафіку безпосередньо до подів, помічених міткою version: v1, що дає точний контроль над маршрутизацією трафіку, при цьому mTLS вимкнено для вхідного та вихідного трафіку до сервісу клієнта. Тепер надішлемо запит до сервісу клієнта. У цій конфігурації ми спробували вимкнути mTLS на сервісі клієнта, щоб подивитися, чи виникнуть помилки, і ось що ми знайшли:

На стороні Kiali:

Давайте подивимось журнали з боку сервісу транспортних засобів:

Як ви можете побачити з журналів, сервіс недоступний, що означає, що сервіс клієнта недосяжний, mTLS працює правильно.

Circuit Breaker

Ця конфігурація складається з DestinationRule для управління маршрутизацією трафіку та стійкістю для сервісів у мережі. DestinationRule застосовується до gateway-service і визначає політики трафіку для забезпечення стабільності та відмовостійкості. Він використовує політику підключення до пула, що обмежує TCP-з'єднання до одного (maxConnections:1) та обмежує HTTP-запити з максимальним значенням одного очікуючого запиту (http1MaxPendingRequests:1) і одним запитом на з'єднання (maxRequestsPerConnection:1). Крім того, політика виявлення відмов викидає несправні кінцеві точки після однієї послідовної помилки (consecutiveErrors:1) та моніторить кінцеві точки через інтервали в одну секунду (interval:1s). Якщо кінцева точка викинута, вона залишається недоступною протягом базового часу в три хвилини (baseEjectionTime:3m), і до 100% кінцевих точок можуть бути викинуті (maxEjectionPercent:100). Разом ці налаштування забезпечують точну маршрутизацію для сервісів та підвищують стійкість gateway-service шляхом швидкого виявлення та ізоляції проблемних екземплярів.

Висновок:

Цей проект показує, як Kubernetes та Istio разом створюють масштабовану та безпечну архітектуру мікросервісів. Kubernetes управляє розгортанням та масштабуванням сервісів, в той час як Istio покращує управління трафіком, безпеку та спостережуваність. Завдяки цим інструментам ми забезпечили плавні оновлення, покращену надійність і створили систему, готову до майбутнього зростання.

Це завершує нашу подорож. Слідкуйте за нашим наступним блогом — незабаром!

Перекладено з: Exploring Istio: The Power of Service Mesh in Kubernetes