У попередньому пості ми розглядали основи Istio, включаючи його архітектуру. Ми зосередилися на DestinationRules та їхніх можливостях, а також на VirtualServices.
Ви можете прочитати це тут: Огляд основ управління трафіком в Istio.
Сьогодні ми обговоримо Ingress та Egress трафік за допомогою Gateways, а також розглянемо кілька сценаріїв.
Gateways: теорія
При встановленні контрольної панелі Istio ми можемо вибрати, чи встановлювати Ingress або Egress Gateways. Є кілька способів це зробити, наприклад, через CLI:
istioctl install --set profile=demo
Задавши параметр profile, ми можемо визначити, яку установку контрольної панелі ми хочемо виконати. Профіль за замовчуванням включає istio-ingressgateway, а Demo профіль включає як ingress, так і egress gateways.
Ми також можемо розгорнути шлюзи за допомогою ресурсу IstioOperator наступним чином:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
name: myoperator
spec:
profile: demo
components:
egressGateways:
- name: istio-egressgateway
enabled: false
ingressGateways:
- name: istio-ingressgateway
enabled: false
- name: app-gateway
enabled: true
namespace: my-app
label:
appgateway: my-app
- name: internal-gateway
enabled: true
namespace: internal
label:
gatewayType: internal
У цьому коді ми вимикаємо за замовчуванням istio-ingressgateway та istio-egressgateway для профілю Demo і створюємо два нові ingress шлюзи, звані app-gateway та internal-gateway.
Крім того, ми можемо задати мітки для цих шлюзів і визначити простір імен, в якому вони будуть розгорнуті.
Ми також можемо встановлювати деякі специфікації Kubernetes, такі як affinity, tolerations, envs, кількість реплік для розгортання... Вся інформація доступна тут.
Ми поговорили про те, як розгортати шлюзи, а тепер що ж таке ці шлюзи?
Шлюзи Istio — це фактично проксі Envoy (так, ті самі, що працюють як sidecars), але розміщені на межі mesh. Це означає, що шлюзи є проксі Envoy, через які проходить весь вхідний і вихідний трафік mesh... або, принаймні, для цього вони і призначені.
Ці проксі Envoy розгортаються як контейнери (pods), керовані розгортанням:
Розгортання контрольної панелі Istio
Важливо зазначити, що оскільки шлюзи є просто проксі Envoy, вони не додають жодних функцій безпеки до вашої системи за замовчуванням.
А ось найважливіша частина: для налаштування цих шлюзів ми використовуємо Gateway CRD, який фактично є набором конфігурацій, які застосовуються до шлюзів.
Gateways: сценарії
Тепер, коли ви знаєте, що таке шлюз, давайте розглянемо кілька прикладів.
За замовчуванням весь вхідний/вихідний трафік mesh не проходить через шлюзи. Нам потрібно встановити правила, щоб трафік проходив через них. Це робиться за допомогою VirtualServices.
HTTP Ingress
Основний випадок, коли ми хочемо, щоб наш сервіс був доступний ззовні mesh. Нам потрібен шлюз для того, щоб відкрити наш сервіс через ingress-gateway, і VirtualService, щоб маршрутизувати трафік від ingress-gateway до нашого реального сервісу.
apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
name: httpbin-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "httpbin.example.com"
Ми вибираємо за допомогою поля spec.selector шлюз, для якого хочемо застосувати цю конфігурацію. Потім задаємо порт і хост, на який шлюз має слухати.
У випадку, коли такі середовища чи навантаження повинні бути автоматично створені, представлення їх у програмно відтворюваному вигляді є, звісно, необхідним.
- Пакетні навантаження: Подібно до тестових навантажень, обмежені за часом пакетні навантаження часто потребують програмного відтворення досить часто, наприклад, коли доступні нові вхідні дані.
- Кілька регіонів: Операційні середовища можуть охоплювати кілька регіонів, і деякі чи всі інфраструктурні компоненти та навантаження повинні бути відтворені в кожному регіоні, хоча часто з деякими відмінностями в ємності та/або конфігураціях юрисдикцій (наприклад, мова, юридичні вимоги, суверенітет даних).
- Реплікація: Деякі компоненти інфраструктури та/або навантаження можуть потребувати реплікації для масштабу чи надійності (наприклад, використовуючи count у Terraform), хоча масштабування через IaC зазвичай виключає динамічне авто-масштабування.
- Багато подібних компонентів: Адаптація коду генерації конфігурацій для подібних випадків використання може бути здійснена або шляхом копіювання/вставлення без змін, або шляхом додавання більше параметрів до коду генерації конфігурацій, щоб зробити його достатньо гнучким для підтримки нових випадків. Це дозволяє зменшити кількість спроб і помилок при створенні робочої конфігурації.
- Флоти: Генерація десятків, сотень або тисяч варіантів відрізняється від генерації кількох і є достатньо важливою для того, щоб обговорити це як окрему схему використання. Розгортання та подальше управління флотом стає значним викликом. Один із випадків використання — це край роздрібної торгівлі, де кожен розгорнутий варіант працює в кожному магазині роздрібної торгівлі, як це зроблено у Target та Chick-fil-A. Інший — це архітектура багатоклієнтного (так званого ізольованого) середовища, де ізольований варіант системи запускається для кожного клієнта сервісу.
- Самообслуговування для команд: Забезпечення самообслуговування командами розробників є основною метою каталогів шаблонів на порталах розробників і внутрішніх платформ. Це зменшує потребу подавати заявку до центральних команд IT, інфраструктури чи платформи для надання ресурсів від їх імені, а також може знизити час, що витрачається на очікування ресурсів, приховану IT та конфігурації, що порушують правила.
- Публічні готові пакети: Публічні Helm charts і Terraform модулі є прикладами готових пакетів, призначених для того, щоб полегшити користувачам початок роботи, генеруючи робочі конфігурації. Реальна зручність використання може бути зменшена великою кількістю параметрів (Terraform приклад, Helm приклад), щоб врахувати широкий спектр застосувань. Хоча багато вхідних параметрів часто мають значення за замовчуванням, може бути складно зрозуміти, які наслідки мають зміни значень, а сам код генерації може замаскувати конфігурацію.
Звісно, є й інші способи досягнення генерації варіантів конфігурацій, наприклад, за допомогою скриптів, використовуючи імперативні інструменти або прямі виклики API, але IaC був створений, щоб це зробити простіше. Це здійснюється шляхом винесення загальних функцій, таких як оркестрація викликів API, про яку я згадував раніше.
Хоча IaC і полегшує генерацію варіантів конфігурацій, я не сказав би, що це робить її легкою. Варто розглянути альтернативні рішення цієї проблеми.
Хоча Kustomize і не робить кожен випадок використання простішим, він показує, що альтернативні підходи існують. Для подолання фундаментальних недоліків IaC потрібен суттєво інший підхід.
Чи використовуєте ви IaC для генерації варіантів для мети, відмінної від тих, що я перелічив вище? Чи використовували ви підхід, відмінний від IaC, для генерації варіантів конфігурацій для інфраструктури та/або навантажень? Чи хочете ви, щоб існували інші засоби для генерації варіантів? Якщо так, то чому? Як ви вважаєте, яка основна здатність IaC, чи є їх більше ніж одна?
Не соромтеся відповісти тут або надіслати мені повідомлення на LinkedIn, X/Twitter, чи Bluesky, де я планую кроспостити це.
Якщо вам це було цікаво, можливо, вас зацікавлять інші пости в моїй серії про Інфраструктуру як код та декларативну конфігурацію або в моїй серії про Kubernetes.
Перекладено з: Variant generation is the primary capability of Infrastructure as Code