Модуль istio: примеры

Circuit Breaker

Для выявления проблемных эндпоинтов используются настройки outlierDetection в custom resource DestinationRule. Более подробно алгоритм Outlier Detection описан в документации Envoy.

Пример:

1apiVersion: networking.istio.io/v1beta1
2kind: DestinationRule
3metadata:
4  name: reviews-cb-policy
5spec:
6  host: reviews.prod.svc.cluster.local
7  trafficPolicy:
8    connectionPool:
9      tcp:
10        maxConnections: 100 # Максимальное число коннектов в сторону host, суммарно для всех эндпоинтов.
11      http:
12        maxRequestsPerConnection: 10 # Каждые 10 запросов коннект будет пересоздаваться.
13    outlierDetection:
14      consecutive5xxErrors: 7 # Допустимо 7 ошибок (включая пятисотые, TCP-таймауты и HTTP-таймауты)
15      interval: 5m            # в течение пяти минут,
16      baseEjectionTime: 15m   # после которых эндпоинт будет исключен из балансировки на 15 минут.

А также для настройки HTTP-таймаутов используется ресурс VirtualService. Эти таймауты также учитываются при подсчете статистики ошибок на эндпоинтах.

Пример:

1apiVersion: networking.istio.io/v1beta1
2kind: VirtualService
3metadata:
4  name: my-productpage-rule
5  namespace: myns
6spec:
7  hosts:
8  - productpage
9  http:
10  - timeout: 5s
11    route:
12    - destination:
13        host: productpage

Балансировка gRPC

Важно! Чтобы балансировка gRPC-сервисов заработала автоматически, присвойте name с префиксом или значением grpc для порта в соответствующем Service.

Locality Failover

При необходимости ознакомьтесь с основной документацией.

Istio позволяет настроить приоритетный географический фейловер между эндпоинтами. Для определения зоны Istio использует лейблы узлов с соответствующей иерархией:

• topology.istio.io/subzone;
• topology.kubernetes.io/zone;
• topology.kubernetes.io/region.

Это полезно для межкластерного фейловера при использовании совместно с мультикластером.

Важно! Для включения Locality Failover используется ресурс DestinationRule, в котором также необходимо настроить outlierDetection.

Пример:

1apiVersion: networking.istio.io/v1beta1
2kind: DestinationRule
3metadata:
4  name: helloworld
5spec:
6  host: helloworld
7  trafficPolicy:
8    loadBalancer:
9      localityLbSetting:
10        enabled: true # Включили LF.
11    outlierDetection: # outlierDetection включить обязательно.
12      consecutive5xxErrors: 1
13      interval: 1s
14      baseEjectionTime: 1m

Retry

С помощью ресурса VirtualService можно настроить Retry для запросов.

Внимание! По умолчанию при возникновении ошибок все запросы (включая POST-запросы) выполняются повторно до трех раз.

Пример:

1apiVersion: networking.istio.io/v1beta1
2kind: VirtualService
3metadata:
4  name: ratings-route
5spec:
6  hosts:
7  - ratings.prod.svc.cluster.local
8  http:
9  - route:
10    - destination:
11        host: ratings.prod.svc.cluster.local
12    retries:
13      attempts: 3
14      perTryTimeout: 2s
15      retryOn: gateway-error,connect-failure,refused-stream

Canary

Важно! Istio отвечает лишь за гибкую маршрутизацию запросов, которая опирается на спецзаголовки запросов (например, cookie) или просто на случайность. За настройку этой маршрутизации и «переключение» между канареечными версиями отвечает CI/CD-система.

Подразумевается, что в одном namespace выкачено два Deployment с разными версиями приложения. У подов разных версий разные лейблы (version: v1 и version: v2).

Требуется настроить два custom resource:

• DestinationRule с описанием, как идентифицировать разные версии вашего приложения (subset’ы);
• VirtualService с описанием, как распределять трафик между разными версиями приложения.

Пример:

1apiVersion: networking.istio.io/v1beta1
2kind: DestinationRule
3metadata:
4  name: productpage-canary
5spec:
6  host: productpage
7  # subset'ы доступны только при обращении к хосту через VirtualService из пода под управлением Istio.
8  # Эти subset'ы должны быть указаны в маршрутах.
9  subsets:
10  - name: v1
11    labels:
12      version: v1
13  - name: v2
14    labels:
15      version: v2

Распределение по наличию cookie

1apiVersion: networking.istio.io/v1beta1
2kind: VirtualService
3metadata:
4  name: productpage-canary
5spec:
6  hosts:
7  - productpage
8  http:
9  - match:
10    - headers:
11       cookie:
12         regex: "^(.*;?)?(canary=yes)(;.*)?"
13    route:
14    - destination:
15        host: productpage
16        subset: v2 # Ссылка на subset из DestinationRule.
17  - route:
18    - destination:
19        host: productpage
20        subset: v1

Распределение по вероятности

1apiVersion: networking.istio.io/v1beta1
2kind: VirtualService
3metadata:
4  name: productpage-canary
5spec:
6  hosts:
7  - productpage
8  http:
9  - route:
10    - destination:
11        host: productpage
12        subset: v1 # Ссылка на subset из DestinationRule.
13      weight: 90 # Процент трафика, который получат поды с лейблом version: v1.
14  - route:
15    - destination:
16        host: productpage
17        subset: v2
18      weight: 10

Ingress для публикации приложений

Istio Ingress Gateway

Пример:

1apiVersion: deckhouse.io/v1alpha1
2kind: IngressIstioController
3metadata:
4 name: main
5spec:
6  # ingressGatewayClass содержит значение селектора меток, используемое при создании ресурса Gateway.
7  ingressGatewayClass: istio-hp
8  inlet: HostPort
9  hostPort:
10    httpPort: 80
11    httpsPort: 443
12  nodeSelector:
13    node-role/frontend: ''
14  tolerations:
15    - effect: NoExecute
16      key: dedicated
17      operator: Equal
18      value: frontend
19  resourcesRequests:
20    mode: VPA

1apiVersion: v1
2kind: Secret
3metadata:
4  name: app-tls-secert
5  namespace: d8-ingress-istio # Обратите внимание, что namespace не является app-ns.
6type: kubernetes.io/tls
7data:
8  tls.crt: |
9    <tls.crt data>
10  tls.key: |
11    <tls.key data>

1apiVersion: networking.istio.io/v1beta1
2kind: Gateway
3metadata:
4  name: gateway-app
5  namespace: app-ns
6spec:
7  selector:
8    # Селектор меток для использования Istio Ingress Gateway main-hp.
9    istio.deckhouse.io/ingress-gateway-class: istio-hp
10  servers:
11    - port:
12        # Стандартный шаблон для использования протокола HTTP.
13        number: 80
14        name: http
15        protocol: HTTP
16      hosts:
17        - app.example.com
18    - port:
19        # Стандартный шаблон для использования протокола HTTPS.
20        number: 443
21        name: https
22        protocol: HTTPS
23      tls:
24        mode: SIMPLE
25        # Secret с сертификатом и ключем, который должен быть создан в d8-ingress-istio namespace.
26        # Поддерживаемые форматы Secret'ов можно посмотреть по ссылке https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/#key-formats.
27        credentialName: app-tls-secrets
28      hosts:
29        - app.example.com

1apiVersion: networking.istio.io/v1alpha3
2kind: VirtualService
3metadata:
4  name: vs-app
5  namespace: app-ns
6spec:
7  gateways:
8    - gateway-app
9  hosts:
10    - app.example.com
11  http:
12    - route:
13        - destination:
14            host: app-svc

NGINX Ingress

Для работы с NGINX Ingress требуется подготовить:

• Ingress-контроллер, добавив к нему sidecar от Istio. В нашем случае включить параметр enableIstioSidecar у custom resource IngressNginxController модуля ingress-nginx.
• Ingress-ресурс, который ссылается на Service. Обязательные аннотации для Ingress-ресурса:
  • nginx.ingress.kubernetes.io/service-upstream: "true" — с этой аннотацией Ingress-контроллер будет отправлять запросы на ClusterIP сервиса (из диапазона Service CIDR) вместо того, чтобы слать их напрямую в поды приложения. Sidecar-контейнер istio-proxy перехватывает трафик только в сторону диапазона Service CIDR, остальные запросы отправляются напрямую;
  • nginx.ingress.kubernetes.io/upstream-vhost: myservice.myns.svc — с данной аннотацией sidecar сможет идентифицировать прикладной сервис, для которого предназначен запрос.

Примеры:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: productpage
5  namespace: bookinfo
6  annotations:
7    # Просим nginx проксировать трафик на ClusterIP вместо собственных IP подов.
8    nginx.ingress.kubernetes.io/service-upstream: "true"
9    # В Istio вся маршрутизация осуществляется на основе `Host:` заголовка запросов.
10    # Чтобы не сообщать Istio о существовании внешнего домена `productpage.example.com`,
11    # мы просто используем внутренний домен, о котором Istio осведомлен.
12    nginx.ingress.kubernetes.io/upstream-vhost: productpage.bookinfo.svc
13spec:
14  rules:
15    - host: productpage.example.com
16      http:
17        paths:
18        - path: /
19          pathType: Prefix
20          backend:
21            service:
22              name: productpage
23              port:
24                number: 9080

1apiVersion: v1
2kind: Service
3metadata:
4  name: productpage
5  namespace: bookinfo
6spec:
7  ports:
8  - name: http
9    port: 9080
10  selector:
11    app: productpage
12  type: ClusterIP

Примеры настройки авторизации

Алгоритм принятия решения

Важно! Как только для приложения создается AuthorizationPolicy, начинает работать следующий алгоритм принятия решения о судьбе запроса:

• Если запрос попадает под политику DENY — запретить запрос.
• Если для данного приложения нет политик ALLOW — разрешить запрос.
• Если запрос попадает под политику ALLOW — разрешить запрос.
• Все остальные запросы — запретить.

Иными словами, если вы явно что-то запретили, работает только ваш запрет. Если же вы что-то явно разрешили, теперь разрешены только явно одобренные запросы (запреты никуда не исчезают и имеют приоритет).

Важно! Для работы политик, основанных на высокоуровневых параметрах, таких как namespace или principal, необходимо, чтобы все вовлеченные сервисы работали под управлением Istio. Также между приложениями должен быть организован Mutual TLS.

Примеры:

• Запретим POST-запросы для приложения myapp. Отныне, так как для приложения появилась политика, согласно алгоритму выше будут запрещены только POST-запросы к приложению.

  1apiVersion: security.istio.io/v1beta1
  2kind: AuthorizationPolicy
  3metadata:
  4  name: deny-post-requests
  5  namespace: foo
  6spec:
  7  selector:
  8    matchLabels:
  9      app: myapp
  10  action: DENY
  11  rules:
  12  - to:
  13    - operation:
  14        methods: ["POST"]
  

• Здесь для приложения создана политика ALLOW. При ней будут разрешены только запросы из NS bar, остальные запрещены.

  1apiVersion: security.istio.io/v1beta1
  2kind: AuthorizationPolicy
  3metadata:
  4  name: deny-all
  5  namespace: foo
  6spec:
  7  selector:
  8    matchLabels:
  9      app: myapp
  10  action: ALLOW # default, можно не указывать.
  11  rules:
  12  - from:
  13    - source:
  14        namespaces: ["bar"]
  

• Здесь для приложения создана политика ALLOW. При этом она не имеет ни одного правила, и поэтому ни один запрос под нее не попадет, но она таки есть. Поэтому, согласно алгоритму, раз что-то разрешено, то все остальное запрещено. В данном случае все остальное — это вообще все запросы.

  1apiVersion: security.istio.io/v1beta1
  2kind: AuthorizationPolicy
  3metadata:
  4  name: deny-all
  5  namespace: foo
  6spec:
  7  selector:
  8    matchLabels:
  9      app: myapp
  10  action: ALLOW # default, можно не указывать.
  11  rules: []
  

• Здесь для приложения созданы политика ALLOW (это default) и одно пустое правило. Под это правило попадает любой запрос и автоматически получает добро.

  1apiVersion: security.istio.io/v1beta1
  2kind: AuthorizationPolicy
  3metadata:
  4  name: allow-all
  5  namespace: foo
  6spec:
  7  selector:
  8    matchLabels:
  9      app: myapp
  10  rules:
  11  - {}
  

Запретить вообще все в рамках namespace foo

Два способа:

• Запретить явно. Здесь мы создаем политику DENY с единственным универсальным фильтром {}, под который попадают все запросы:

  1apiVersion: security.istio.io/v1beta1
  2kind: AuthorizationPolicy
  3metadata:
  4  name: deny-all
  5  namespace: foo
  6spec:
  7  action: DENY
  8  rules:
  9  - {}
  

• Неявно. Здесь мы создаем политику ALLOW (по умолчанию), но не создаем ни одного фильтра, так что ни один запрос под нее не попадет и будет автоматически запрещен.

  1apiVersion: security.istio.io/v1beta1
  2kind: AuthorizationPolicy
  3metadata:
  4  name: deny-all
  5  namespace: foo
  6spec: {}
  

Запретить доступ только из namespace foo

1apiVersion: security.istio.io/v1beta1
2kind: AuthorizationPolicy
3metadata:
4 name: deny-from-ns-foo
5 namespace: myns
6spec:
7 action: DENY
8 rules:
9 - from:
10   - source:
11       namespaces: ["foo"]

Разрешить запросы только в рамках нашего namespace foo

1apiVersion: security.istio.io/v1beta1
2kind: AuthorizationPolicy
3metadata:
4 name: allow-intra-namespace-only
5 namespace: foo
6spec:
7 action: ALLOW
8 rules:
9 - from:
10   - source:
11       namespaces: ["foo"]

Разрешить из любого места в нашем кластере

1apiVersion: security.istio.io/v1beta1
2kind: AuthorizationPolicy
3metadata:
4 name: allow-all-from-my-cluster
5 namespace: myns
6spec:
7 action: ALLOW
8 rules:
9 - from:
10   - source:
11       principals: ["mycluster.local/*"]

Разрешить любые запросы только кластеров foo или bar

1apiVersion: security.istio.io/v1beta1
2kind: AuthorizationPolicy
3metadata:
4 name: allow-all-from-foo-or-bar-clusters-to-ns-baz
5 namespace: baz
6spec:
7 action: ALLOW
8 rules:
9 - from:
10   - source:
11       principals: ["foo.local/*", "bar.local/*"]

Разрешить любые запросы только кластеров foo или bar, при этом из namespace baz

1apiVersion: security.istio.io/v1beta1
2kind: AuthorizationPolicy
3metadata:
4 name: allow-all-from-foo-or-bar-clusters-to-ns-baz
5 namespace: baz
6spec:
7 action: ALLOW
8 rules:
9 - from:
10   - source: # Правила ниже логически перемножаются.
11       namespaces: ["baz"]
12       principals: ["foo.local/*", "bar.local/*"]

Разрешить из любого кластера (по mTLS)

Важно! Если есть запрещающие правила, у них будет приоритет. Смотри алгоритм.

Пример:

1apiVersion: security.istio.io/v1beta1
2kind: AuthorizationPolicy
3metadata:
4 name: allow-all-from-any-cluster-with-mtls
5 namespace: myns
6spec:
7 action: ALLOW
8 rules:
9 - from:
10   - source:
11       principals: ["*"] # To set mTLS mandatory.

Разрешить вообще откуда угодно (в том числе без mTLS)

1apiVersion: security.istio.io/v1beta1
2kind: AuthorizationPolicy
3metadata:
4 name: allow-all-from-any
5 namespace: myns
6spec:
7 action: ALLOW
8 rules: [{}]

Устройство федерации из двух кластеров с помощью custom resource IstioFederation

Доступно только в редакции Enterprise Edition.

Cluster A:

1apiVersion: deckhouse.io/v1alpha1
2kind: IstioFederation
3metadata:
4  name: cluster-b
5spec:
6  metadataEndpoint: https://istio.k8s-b.example.com/metadata/
7  trustDomain: cluster-b.local

Cluster B:

1apiVersion: deckhouse.io/v1alpha1
2kind: IstioFederation
3metadata:
4  name: cluster-a
5spec:
6  metadataEndpoint: https://istio.k8s-a.example.com/metadata/
7  trustDomain: cluster-a.local

Устройство мультикластера из двух кластеров с помощью ресурса IstioMulticluster

Доступно только в редакции Enterprise Edition.

Cluster A:

1apiVersion: deckhouse.io/v1alpha1
2kind: IstioMulticluster
3metadata:
4  name: cluster-b
5spec:
6  metadataEndpoint: https://istio.k8s-b.example.com/metadata/

Cluster B:

1apiVersion: deckhouse.io/v1alpha1
2kind: IstioMulticluster
3metadata:
4  name: cluster-a
5spec:
6  metadataEndpoint: https://istio.k8s-a.example.com/metadata/

Управление поведением data plane

[экспериментальная функция] Предотвратить завершение работы istio-proxy до завершения соединений основного приложения

По умолчанию в процессе остановки пода все контейнеры, включая istio-proxy, получают сигнал SIGTERM одновременно. Но некоторым приложениям для правильного завершения работы необходимо время и иногда дополнительная сетевая активность. Это невозможно, если istio-proxy завершился раньше. Решение — добавить в istio-proxy preStop-хук для оценки активности прикладных контейнеров, а единственный доступный метод — это выявление сетевых сокетов приложения, и если таковых нет, тогда можно останавливать контейнер. Аннотация ниже добавляет описанный выше preStop-хук в контейнер istio-proxy прикладного пода: inject.istio.io/templates: sidecar,d8-hold-istio-proxy-termination-until-application-stops.

Обновление Istio

Обновление control plane Istio

• Deckhouse позволяет инсталлировать несколько версий control plane одновременно:
  • Одна глобальная, обслуживает namespace’ы или поды без явного указания версии (label у namespace istio-injection: enabled). Настраивается параметром globalVersion.
  • Остальные — дополнительные, обслуживают namespace’ы или поды с явным указанием версии (label у namespace или пода istio.io/rev: v1x19). Настраиваются параметром additionalVersions.
• Istio заявляет обратную совместимость между data plane и control plane в диапазоне двух минорных версий:
• Алгоритм обновления (для примера, на версию 1.19):
  • Добавить желаемую версию в параметр модуля additionalVersions (additionalVersions: ["1.19"]).
  • Дождаться появления соответствующего пода istiod-v1x19-xxx-yyy в namespace d8-istio.
  • Для каждого прикладного namespace, где включен istio:
    • поменять label istio-injection: enabled на istio.io/rev: v1x19;
    • по очереди пересоздать поды в namespace, параллельно контролируя работоспособность приложения.
  • Поменять настройку globalVersion на 1.19 и удалить additionalVersions.
  • Убедиться, что старый под istiod удалился.
  • Поменять лейблы прикладных namespace на istio-injection: enabled.

Чтобы найти все поды под управлением старой ревизии Istio, выполните:

1kubectl get pods -A -o json | jq --arg revision "v1x16" \
2  '.items[] | select(.metadata.annotations."sidecar.istio.io/status" // "{}" | fromjson |
3   .revision == $revision) | .metadata.namespace + "/" + .metadata.name'

Автоматическое обновление data plane Istio

Доступно только в редакции Enterprise Edition.

Для автоматизации обновления istio-sidecar’ов установите лейбл istio.deckhouse.io/auto-upgrade="true" на Namespace либо на отдельный ресурс — Deployment, DaemonSet или StatefulSet.