Блог

У меня есть контейнер nginx, который обрабатывает html-контент и маршрутизацию трафика через виртуальный сервис.

У меня есть отдельный контейнер nginx для обслуживания, который я хочу отобразить (когда я выполняю обслуживание), и в этом случае я хочу, чтобы весь трафик направлялся в этот контейнер обслуживания, а не в обычный, указанный в первом абзаце. Я действительно не хочу настраивать/исправлять исходные маршруты трафика, поэтому ищу способ переопределить какое-либо правило маршрутизации трафика.

Из того, что я прочитал, порядок правил основан на дате создания, так что это мне не очень помогло.

Поэтому, если у кого-нибудь есть какие-либо идеи, как я могу заставить весь трафик перенаправляться на конкретную службу «обслуживания», я был бы очень признателен за ваши мысли.

Я бы рекомендовал установить метку версии и работать с ней.

Сначала создайте a DestinationRule , чтобы определить ваши различные версии и то, как они идентифицируются (по меткам).

 apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: nginx-versions
spec:
  host: nginx.default.svc.cluster.local
  subsets:
  - name: maintenance
    labels:
      version: maintenance
  - name: v1
    labels:
      version: v1
 

Затем настройте свой маршрут в поле VirtualService указать v1 .

 apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: nginx-route
spec:
  hosts:
  - example.com
  gateways:
  - mygateway
  http:
  - name: nginx-route
    match:
    - uri:
        prefix: "/nginx"
    route:
    - destination:
        host: nginx.default.svc.cluster.local
        subset: v1
 

Теперь вам нужен один Service и два Deployment s.

Селектор в службе должен соответствовать обоим развертываниям. При обычной настройке kubernetes это означало бы, что трафик будет перенаправляться между всеми рабочими нагрузками обоих развертываний. Но из-за istio и настройки версии трафик будет отправляться только в текущую настроенную версию.

Развертывание с версией обслуживания version: maintenance должно быть помечено, и фактическая версия должна быть помечена version: v1 .

 apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
  app: nginx
spec:
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-maintenance
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
        version: maintenance
    spec:
      containers:
      - image: nginx-maintenance
[...]
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-v1
spec:
  replicas: 5
  template:
    metadata:
      labels:
        app: nginx
        version: v1
    spec:
      containers:
      - image: nginx-v1
[...]
 

Если вы хотите, чтобы трафик направлялся в версию обслуживания, просто измените инструкцию subset в VirtalService и примените ее повторно.

Если вы хотите, чтобы по какой-то причине трафик внутри кластера всегда отправлялся в вашу v1 версию, вам нужен другой VirtualService , который использовал mesh шлюз. В противном случае внутренний трафик кластера будет разделен между всей рабочей нагрузкой (v1 и обслуживанием). В качестве альтернативы вы можете добавить сетевой шлюз и хост в виртуальную службу сверху, но внутренний трафик кластера всегда будет вести себя как внешний трафик.

 apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: nginx-route-in-cluster
spec:
  hosts:
  - nginx.default.svc.cluster.local
  gateways:
  - mesh
  http:
  - name: nginx-route
    match:
    - uri:
        prefix: "/nginx"
    route:
    - destination:
        host: nginx.default.svc.cluster.local
        subset: v1
 

Кроме того, вы даже можете использовать больше версий и тестировать обновления, отправляя только часть своего трафика в новую версию.

Чтобы лучше понять и получить дополнительные идеи об управлении версиями с помощью istio, пожалуйста, обратитесь к этой статье (на самом деле она довольно старая, но концепция все еще актуальна).