Встановлення Gateways

Разом зі створенням сервісної мережі Istio дозволяє вам керувати шлюзами, які є проксі-серверами Envoy, що працюють на периметрі мережі, надаючи детальний контроль над трафіком, що входить та виходить з мережі.

Деякі з вбудованих профілів конфігурації Istio розгортають шлюзи під час установки. Наприклад, виклик istioctl install зі стандартними налаштуваннями розгорне шлюз для вхідного трафіку разом з панеллю управління. Хоча це підходить для оцінки та простих випадків використання, таке налаштування повʼязує шлюз з панеллю управління, що ускладнює управління та оновлення. Для операційних розгортань Istio наполегливо рекомендується розʼєднати ці компоненти для забезпечення їх незалежної роботи.

Слідуйте цій інструкції, щоб окремо розгортати та керувати одним або кількома шлюзами в операційному розгортанні Istio.

Передумови

Для продовження роботи відповідно до цієї інструкції, необхідно, щоб панель управління Istio була встановлена.

Розгортання шлюзу

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

Використання автоінʼєкції для розгортання шлюзів рекомендується, оскільки це дає розробникам повний контроль над розгортанням шлюзу, одночасно спрощуючи операційні процеси. Коли нове оновлення стає доступним або змінюється конфігурація, можна просто перезапустити podʼи шлюзів для їхнього оновлення. Це робить процес управління розгортанням шлюзу таким же, як і управління sidecar.

Для підтримки користувачів, які вже використовують інструменти розгортання, Istio надає кілька різних способів розгортання шлюзу. Кожен метод дасть однаковий результат. Виберіть метод, з яким ви найбільш знайомі.

Усі методи, наведені нижче, використовують інʼєкцію, щоб додати додаткові налаштування podʼу під час виконання. Для підтримки цього, простір імен, в якому розгорнуто шлюз, не повинен мати мітку istio-injection=disabled. Якщо така мітка є, ви побачите, що podʼи не запускаються через спробу витягти образ auto, який є заповнювачем, призначеним для заміни під час створення podʼа.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: ingress
spec:
  profile: empty # Не встановлюйте CRD або панель управління
  components:
    ingressGateways:
    - name: istio-ingressgateway
      namespace: istio-ingress
      enabled: true
      label:
        # Встановіть унікальну мітку для шлюзу. Це необхідно, щоб забезпечити вибір цього робочого навантаження шлюзами.
        istio: ingressgateway
  values:
    gateways:
      istio-ingressgateway:
        # Увімкніть інжекцію шлюзу
        injectionTemplate: gateway

$ kubectl create namespace istio-ingress
$ istioctl install -f ingress.yaml

$ kubectl create namespace istio-ingress
$ helm install istio-ingressgateway istio/gateway -n istio-ingress

apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: istio-ingress
spec:
  type: LoadBalancer
  selector:
    istio: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: istio-ingress
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # Виберіть шаблон інʼєкції шлюзу (замість стандартного шаблону sidecar)
        inject.istio.io/templates: gateway
      labels:
        # Встановіть унікальну мітку для шлюзу. Це необхідно, щоб забезпечити вибір цього робочого навантаження шлюзами
        istio: ingressgateway
        # Увімкніть інʼєкцію шлюзу. Якщо підключаєтеся до панелі управління з revision, замініть на "istio.io/rev: імʼя-ревізії"
        sidecar.istio.io/inject: "true"
    spec:
      # Дозвольте привʼязку до всіх портів (таких як 80 і 443)
      securityContext:
        sysctls:
        - name: net.ipv4.ip_unprivileged_port_start
          value: "0"
      containers:
      - name: istio-proxy
        image: auto # Образ буде автоматично оновлюватися кожного разу під час запуску podʼа.
        # Відкиньте всі привілеї, дозволяючи запуск в якості non-root
        securityContext:
          capabilities:
            drop:
            - ALL
          runAsUser: 1337
          runAsGroup: 1337
---
# Налаштуйте ролі для дозволу читання облікових даних для TLS
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: istio-ingressgateway-sds
  namespace: istio-ingress
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: istio-ingressgateway-sds
  namespace: istio-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default

$ kubectl create namespace istio-ingress
$ kubectl apply -f ingress.yaml

Управління шлюзами

Нижче описано, як керувати шлюзами після їх встановлення. Для отримання додаткової інформації про їх використання, слідуйте рекомендаціям з завдань Ingress та Egress.

Селектори шлюзів

Мітки на podʼах розгортання шлюзу використовуються ресурсами конфігурації Gateway, тому важливо, щоб селектор вашого Gateway відповідав цим міткам.

Наприклад, у наведених вище розгортаннях, мітка istio=ingressgateway встановлена на podʼах шлюзу. Щоб застосувати Gateway до цих розгортань, вам потрібно вибрати ту ж мітку:

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

Топології розгортання шлюзу

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

Спільний шлюз

У цій моделі один централізований шлюз використовується багатьма застосунками, можливо, у багатьох просторах імен. Шлюзи у просторі імен ingress делегують управління маршрутами до простору імен застосунків, але зберігають контроль над конфігурацією TLS.

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

Виділений шлюз для застосунку

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

Якщо перед Istio немає іншого балансувальника навантаження, це, як правило, означає, що кожен застосунок матиме свою власну IP-адресу, що може ускладнити налаштування DNS.

Оновлення шлюзів

Оновлення на місці

Оскільки шлюзи використовують інʼєкцію podʼів, нові podʼи шлюзу, які створюються, автоматично отримують останню конфігурацію, що включає версію.

Щоб застосувати зміни до конфігурації шлюзу, podʼи можна просто перезапустити, використовуючи такі команди, як kubectl rollout restart deployment.

Якщо ви хочете змінити ревізію панелі управління, яку використовує шлюз, ви можете встановити мітку istio.io/rev на розгортанні шлюзу, що також викличе поступове перезапускання.

Канаркове оновлення (розширене)

Якщо ви хочете повільніше контролювати розгортання нової ревізії панелі управління, ви можете запустити кілька версій розгортання шлюзу. Наприклад, якщо ви хочете розгорнути нову ревізію canary, створіть копію свого розгортання шлюзу з встановленою міткою istio.io/rev=canary:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: istio-ingress
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: canary # Встановіть на ревізію панелі управління, яку ви хочете розгорнути
    spec:
      containers:
      - name: istio-proxy
        image: auto

Коли це розгортання буде створено, ви матимете дві версії шлюзу, обидві з яких будуть вибрані тим самим сервісом:

$ kubectl get endpoints -n istio-ingress -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"
NAME                   PODS
istio-ingressgateway   istio-ingressgateway-...,istio-ingressgateway-canary-...

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

Канаркове оновлення із зовнішнім перемиканням трафіку (розширене)

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

Це пропонує точний контроль, але може бути непридатним або занадто складним для налаштування в деяких середовищах.

Очищення

• Очищення Istio ingress шлюзу

  $ istioctl uninstall --istioNamespace istio-ingress -y --purge
  $ kubectl delete ns istio-ingress