[Перевод] Service mesh для микросервисов. Часть II, основы работы с Istio26.11.2019 00:33

Перевод статьи подготовлен специально для студентов курса «Инфраструктурная платформа на основе Kubernetes».

d6g2qaeltsohyfyjlpyt-cxkwsg.png

Настройка базового микросервиса в Kubernetes обманчиво проста. В одной из последних статей мы рассказали, как легко начать работать с контейнерами. Мы скомпоновали простой образ Docker, развернули его с помощью Kubernetes и выполнили запрос приложения. Это было нетрудно, но в жизни облачные архитектуры, как правило, сложнее. Они включают десятки и даже сотни сервисов с базами данных, аутентификацией и другими нужными в реальности элементами.

Администрировать их порой — сплошная головная боль. В этой статье мы расскажем об Istio — инструменте для service mesh (эту архитектуру мы рассматривали ранее), который выводит управление крупными облачными развертываниями на новый уровень.

Микросервисы дают вам широкие возможности масштабирования, а service mesh дополняет их преимуществами централизации, типичными для монолитных сред (например, журналами и контролем версий). Подробнее об особенностях и преимуществах service mesh мы писали в предыдущей статье из этой серии.

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

Два основных архитектурных термина в Istio — плоскость данных (data plane) и плоскость управления (control plane). Плоскость данных работает с данными, которые перемещаются в приложении, передаются различным экземплярам сервисов и обрабатываются самими сервисами. Для ее реализации используется главным образом sidecar-прокси. На уровне управления определяется порядок инстанцирования сервисов, место хранения данных телеметрии и информации о сервисах. К основным элементам плоскости управления относятся Pilot и Mixer. Давайте разберемся, как это все работает.

Sidecar-прокси выполняется вместе с подом, который определяет ваш сервис в Kubernetes. Он добавляется к основным компонентам сервиса и работает с трафиком, который направляется в этот сервис. Вы можете добавить sidecar-прокси к существующему определению сервиса в поде: в сервис просто добавятся строки, определяющие sidecar-прокси, и он начнет работать.

no4fyi_fg7dhczaztu9obkmc4zo.png

Взамен вы получите целый список преимуществ, которые лежат в основе облачной mesh-сети Istio. Sidecar-прокси перехватывает трафик, поступающий в сервис, и позволяет осуществлять его интеллектуальную маршрутизацию. Речь идет и о простых задачах, таких как балансировка нагрузки или обработка прерываний TLS, которые заметно ускоряют работу, и о более сложных процессах, таких как контроль версий, поэтапное развертывание новой версии сервиса и сбор показателей использования ресурсов. Sidecar-прокси позволяет добавлять все эти возможности в существующую архитектуру микросервисов без реорганизации всей системы.

Как только проясняется первоначальное предназначение sidecar-прокси, становятся очевидными преимущества Istio и облачных service mesh в целом. Фактически все sidecar-прокси архитектуры в совокупности, функционируя как унифицированные связующие элементы между подами сервисов, пропускают через себя весь трафик, проходящий через приложение. Это значит, что при необходимости усилить защиту они выступают в роли единого расположения, где можно добавлять процессы аутентификации и протокол HTTPS между сервисами, вести журнал событий для проверки на наличие аномалий и развертывать средства управления трафиком и фильтрации для проверки подлинности.

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

Помимо плоскости данных Istio включает плоскость управления. Она играет роль контроллера для всех sidecar-прокси, выполняемых в приложении, и центрального репозитория для всей информации (такой как записи журналов и сведения о версиях), который воспринимается сервисами в сети как единый источник достоверных данных.

g5dvmrzvakflmlntpjlfftikkiw.png

При работе с Istio основным способом взаимодействия с плоскостью управления является Kubernetes. После установки пакетов Istio и добавления определений можно использовать для доступа к плоскости управления команды kubectl, которые управляют состоянием системы. Например, процесс обновления пода до новой версии с помощью kubectl начинается с обновления переменных локальной плоскости управления.

Это проще всего увидеть, воспользовавшись командой get-svc в составе kubectl — вы получите список сервисов, связанных с конкретной библиотекой. Чтобы проверить, какие компоненты Istio выполняются, можно воспользоваться следующей командой: 

kubectl get svc -n istio-system

Отобразится список основных элементов плоскости управления Istio, выполняемых в фоновом режиме. Возможно, некоторые из них вам уже знакомы, например Citadel — сервис, который управляет защитой трафика между сервисами.

Давайте посмотрим, какие возможности Istio поддерживает по умолчанию. Мы установим плоскость управления Istio для администрирования базового API HTTP, который был описан в предыдущей статье. Этот сервис API был определен в Kubernetes и реализован как одиночный под Kubernetes с выполняемым в нем API.

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

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

kubectl apply -f install/kubernetes/helm/istio/templates/crds.yaml

Затем активируйте установку Istio, выбрав способ аутентификации. Я буду использовать доступную по умолчанию взаимную HTTPS-аутентификацию, которая отлично подходит для проведения демонстраций и начала работы. Чтобы добавить service mesh в существующий проект, нужно еще немного разобраться с доступными опциями. На данном этапе можно выполнить следующую команду: 

kubectl apply -f install/kubernetes/istio-demo-auth.yaml

После этого вы сможете продолжить. Вам нужно будет добавить структуру Istio в поды, которые были созданы ранее, а для новых подов — добавлять Istio как зависимость.

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

helloworld.yaml

apiVersion: v1
kind: Service
metadata:
   name: helloworld
spec:
   type: ClusterIP
   ports:
      - port: 80
      targetPort: 8080
   selector:
       app: helloworld
---
apiVersion: apps/v1
kind: Deployment
metadata:
   name: helloworld-v1
spec:
   replicas: 1
   selector:
      matchLabels:
         app: helloworld
   template:
      metadata:
      labels:
         app: helloworld
         version: v1
      spec:
         containers:
          - name: helloworld-kubernetes -             image: haseebm/helloworld-kubernetes
            ports:
             - containerPort: 8080
---
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
   name: helloworld-gateway
spec:
   selector:
      istio: ingressgateway # use istio default controller
   servers:
    - port:
         number: 80
         name: http
         protocol: HTTP
   hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
   name: helloworld
spec:
   hosts:
    - "*"
   gateways:
    - helloworld-gateway
   http:
      route:
       - destination:
           host: helloworld
           port:
              number: 80

Istio задействует образец sidecar-прокси, чтобы разместить контейнер sidecar-прокси Istio в одном поде с контейнером приложения helloworld.

$ kubectl apply -f <(istioctl kube-inject -f helloworld.yaml)
service/helloworld created
deployment.extensions/helloworld-v1 created
gateway.networking.istio.io/helloworld-gateway created
virtualservice.networking.istio.io/helloworld created

Проверьте, чтобы поды и сервис выполнялись: 

$ kubectl get pod,svc | grep helloworld
pod/helloworld-v1-1cbca3f8d5-achr2  2/2        Running
service/helloworld           ClusterIP       10.160.58.61

Теперь проверьте трафик для приложения helloworld: 

$ curl a2******.ap-southeast-1.elb.amazonaws.com/api/hello

Hello world v1

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

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

Асад Файзи (Asad Faizi),
учредитель и исполнительный директор, CloudPlex.io, Inc
asad@cloudplex.io
www.cloudplex.io

© Habrahabr.ru