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