Уровень инфраструктуры, который позволяет вам управлять связью между микросервисами вашего приложения, — это сервисная сетка. По мере того, как все больше разработчиков работают с микросервисами, за счет объединения общих задач управления и администрирования в распределенной среде разрабатываются сервисные сетки, которые упрощают и делают работу более эффективной.

Чтобы узнать больше об Istio, вы можете прочитать эту статью Сетка сервисов Istio, чтобы понять основную терминологию. В этом руководстве объясняется, как установить и настроить Istio. Давайте начнем.

Установка Истио

Получите последнюю версию Istio:

curl -L https://istio.io/downloadIstio | sh -

Извлеките архив и экспортируйте каталог bin в путь среды.

Это также установит istioctl, инструмент командной строки для управления сервисной сеткой Istio.

Профили конфигурации

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

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

istioctl install --set profile=demo

Настройка конфигов

Бегать:

istioctl profile dump default

чтобы увидеть различные конфигурации. Мы можем изменить эти флаги с помощью команд istioctl и — установить флаг.

В целях разработки мы можем включить/изменить следующие флаги:

istioctl install --set addonComponents.kiali.enabled=true \ --set components.telemetry.enabled=true \ --set components.citadel.enabled=true \ --set values.global.proxy.privileged=true \ --set addonComponents.tracing.enabled=true \ --set values.pilot.traceSampling=100.0 \ --set values.global.proxy.tracer=datadog

Значение пути флага --set — это путь YAML, который вы можете увидеть в команде дампа профиля.

При изменении любой конфигурации обязательно передайте все предыдущие флаги с новыми. Например, если в первый раз вы включили установку istioctl — установите addonComponents.kiali.enabled=true, а теперь, допустим, хотите включить цитадель, то вам нужно передать оба флага следующим образом: установка istioctl — установить addonComponents.kiali.enabled =true — установить component.telemetry.enabled=true. Если вы не добавите какую-либо ранее включенную переменную, конфигурация вернется к значениям по умолчанию. Один из способов сохранить дамп в файле и применить istioctl или использовать диаграммы управления для Istio.

Впрыск коляски

Чтобы Istio работал правильно, для сервисов должен быть включен прокси-сервер Envoy. По умолчанию плоскость управления Istio не разрешает использование каких-либо дополнительных компонентов для каких-либо служб. Чтобы включить sidecar, мы должны добавить метки на уровне пространства имен.

kubectl label namespace dsl-test istio-injection=enabled

Вам необходимо иметь эту метку, даже если вы не хотите добавлять сопутствующую информацию ко всем своим службам.

Вам нужно перезапустить поды.

Для сервисов, которым не требуется sidecar, нам нужно добавить следующую аннотацию в шаблон развертывания:

# Pod Annotations podAnnotations: sidecar.istio.io/inject: "false"

Настройка служб

Для демонстрации возьмем два демо-сервиса demo-1 и demo-2, и настроим оба сервиса с помощью Istio, и попробуем вызвать сервис demo-2 из demo-1. Убедитесь, что в demo-1 есть переменная env, которую мы настроим с внутренним URL-адресом DNS demo-2. Язык программирования для двух сервисов здесь не имеет значения.

Для конфигурации службы требуются VirtualService, DestinationRule, PeerAuthentication и, при необходимости, конфигурация шлюза.

Шлюз

apiVersion: networking.istio.io/v1alpha3 
kind: Gateway 
metadata: 
	name: demo-1
spec: 
	selector: 
		istio: ingressgateway 
	servers: 
	- port: 
		number: 80 
		name: http 
		protocol: HTTP 
	- hosts: 
		- "demo-1.example.com"

Шлюз используется, когда мы хотим получить доступ к услугам из общедоступной сети.

Здесь мы используем шлюз по умолчанию, предоставленный Istio. Мы также можем создать несколько шлюзов и назначить здесь правильное имя.

Приведенная выше конфигурация шлюза обеспечивает связь как по HTTP, так и по HTTPS. В случае HTTPS мы должны предоставить секрет, содержащий сертификаты CA и ключ.

spec:
	servers: 
	- port: 
		number: 443
		name: http 
		protocol: HTTP
	  tls: 
		mode: SIMPLE 
		credentialName: div4-dev-certs
	  hosts: 
		- "demo-1.example.com"

Мы можем применить тот же шлюз для демо-2. Нам просто нужно обновить имена хостов и метаданных. Так как мы будем делать демо-2 внутри демо-1, здесь нет необходимости во внешнем шлюзе для демо-2.

Виртуальные услуги

---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: demo-1
spec:
  hosts:
  - "demo-1.test.svc.cluster.local"
  - "demo-1.example.com"
  gateways:
    - demo-1
  http:
  - route:
    - destination:
        host: demo-1.test.svc.cluster.local
        port:
          number: 80

spec.hosts: указывает URL-адрес, который будет использовать вызывающая сторона службы. Здесь dsl-es.pbdp.svc.cluster.local будет использоваться внутренними службами. Конечная точка demo-1.example.com будет общедоступна и должна соответствовать значению spec.servers.hosts в конфигурации шлюза.

spec.gateways: чтобы шлюзы, настроенные выше, могли получить доступ к службе, нам нужно определить здесь имя метаданных шлюза.

http.route.destination.host: это значение должно быть фактическим полным доменным именем службы.

Правило назначения

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

---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: demo-1
spec:
  host: "demo-1.test.svc.cluster.local"
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
    tls:
      mode: ISTIO_MUTUAL

spec.host: указывает полное доменное имя службы.

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

spec.trafficPolicy.tls.mode: режим ISTIO_MUTUAL — это режим TLS, в котором мы будем использовать сертификаты, сгенерированные Istio.

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

PeerAuthentication

Эта конфигурация определяет, как будут подключаться другие службы.

---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: demo-1
spec:
  selector:
    matchLabels:
      app: demo-1
  mtls:
    mode: STRICT

spec.selector.matchLabels.app: укажите метку развертывания, к которой будет применяться эта конфигурация.

spec.mtls.mode: режим TLS. STRICT, являющийся соединением, всегда будет взаимным tls.

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

Примените ту же конфигурацию для virutalservice, адресата и одноранговой аутентификации, заменив demo-1 на demo-2, предполагая, что обе службы находятся в одном пространстве имен.

kubectl apply -f <file>.yaml -n test

Доступ к объектам:

kubectl get virtualservices -n pbdp
kubectl get gateways -n pbdp
kubectl get destinationrule -n pbdp
kubectl get peerauthentication -n pbdp

Теперь обновите env для demo-2 с помощью demo-2.test.svc.cluster.local в сервисе demo-1.

Первоначально опубликовано на https://www.loginradius.com.