За последние два года микросервисная архитектура стала популярной, и основные интернет-производители уже превратили ее в микросервисы.Хотя стартапы не могут накапливать технологии, они также используют микросервисы с помощью различных инструментов с открытым исходным кодом. В сочетании с расширением возможностей технологии контейнеров Kubernetes добавил еще один огонь, и архитектура микросервисов стала первым выбором для текущего проектирования архитектуры программного обеспечения.
Но получить микросервисы легко, а управлять ими сложно!
Управление микросервисами — головная боль и боль в архитектуре микросервисов. Слово «управление» имеет множество значений, и дать точное определение сложно.Здесь можно перечислить множество синонимов управления, как второклассник: управление, контроль, правила, контроль, надзор, господство, регулирование, правило и т. д. Для микросервисов управление отражается в следующих аспектах:
С точки зрения управления микросервисами, микросервисы на самом деле представляют собой «большую систему», внедрить эту большую систему непросто, тем более, что до сих пор не было особо изящного технического решения. Большинство программ (например:Dubbo,go-kitи т. д.) более или менее навязчивы для логики приложения, так что бизнес-разработчики могут не только сосредоточиться на самом бизнесе, но и позаботиться об этой логике «управления». И на рынке мало фреймворков со встроенной логикой управления микросервисами, и многие языки программирования связаны между собой. В этом случае крупные фабрики в основном выбирают разработку сами или трансформируют их на основе определенного фреймворка.Малые фабрики вообще могут лишь "лоскутить" какие-то "полуфабрикаты" и использовать их вместе.Таким образом, микросервисы прошли несколько этапов. годы.
Рис. 1. Расположение логики управления микросервисами между традиционными микросервисами
Рис. 2. Расположение логики управления микрослужбой после изоляции
Логическая сеть, состоящая из уровня «Логика управления услугами», определяется как сервисная сетка, и каждый микросервис содержит конечную точку сервисной сетки.
Понятие "Service Mesh" еще очень молодо. В Китае это слово переводится как "service mesh" или "service meshing layer". Здесь мы используем английское слово Service Mesh. Вот отрывок из статьи китайского сообщества ServiceMesh под названием «Ежегодная инвентаризация Service Mesh в 2017 г.«В статье о службе Обзор концепции Mesh:
Проект Istio — это последняя реализация концепции Service Mesh, направленная на предоставление услуг на всех основных платформах управления кластерами. Уровень Mesh изначально предназначен для реализации уровня управления услугами в Kubernetes. Он состоит из плоскости управления и плоскости данных (чувствует ли она себя иSDNКонцепция дизайна похожа). Плоскость управления реализована языком Go, включая Pilot, Mixer и Auth; функция плоскости данных временно предоставляется Envoy в виде развертывания Sidecar в Pod. Ниже приведена официальная схема архитектуры:
Рисунок 3: Схема архитектуры Istio (с официального сайта)
Envoy в sidecar проксирует весь входящий и исходящий трафик реального бизнес-контейнера в Pod и обрабатывает этот трафик в соответствии с «логикой управления», установленной плоскостью управления. И все это прозрачно для бизнес-приложений в Pod, и разработчики могут сосредоточиться на бизнес-логике, и им больше не нужно заботиться о логике управления микросервисами. Концепция дизайна Service Mesh, представленная Istio, считается «унифицированной микросервисной структурой» следующего поколения, а некоторые даже считают ее конечной точкой эволюции микросервисной инфраструктуры.
Istio выпустил версию 0.1 24 мая 2017 г. Релизная версия, на данный момент версия Istio обновлена до версии 0.4.0, скорость эволюции довольно высокая, но она все еще не используется в производственной среде, по крайней мере, до выхода версии 1.0. Но для первых пользователей Istio сейчас самое время погрузиться в Istio. В следующей части этой статьи мы познакомим вас с Istio на эмоциональном уровне и приступим к работе.
Примечание. Я также установил версию Istio 0.3.0 на Kubernetes v1.7.3, но при создании компонента будет сообщено о следующей ошибке (эта ошибка может привести к неправильной работе последующего дополнения после установки):
После установки мы увидим следующие Pod и Service, работающие под пространством имен istio-system (поскольку размер образа каждого компонента Istio не маленький, потребуется некоторое время, чтобы статус Pod изменился на Running, подождите терпеливо):
Istio успешно установлен!
Мы видим, что в Service Mesh развернуты два сервиса: server_a и service_b, первый вызывает второй для выполнения определенного дела, а второй вызывает внешние сервисы для завершения бизнес-логики.
Давайте сначала развернем v0.1 версии service_a и service_b:
Если взять в качестве примера развертывание service_a, файл развертывания service_a выглядит следующим образом:
Обратите внимание, что когда мы развертываем service_a, мы не можем напрямую использовать kubectl apply -f svca-v0.1.yaml, но применяем yaml, обработанный istioctl (bin в каталоге установки Istio нужно поместить в PATH) для внедрения в боковой контейнер. Конечно, его также можно настроить на автоматическое внедрение sidecars для каждого модуля, запущенного Kubernetes, но здесь мы не используем автоматическое внедрение. Выполняем следующую команду:
Таким же образом создадим svcb:v0.1:
Мы видим, что Istio вставляет в каждый Pod sidecar-контейнер — это упомянутый выше посланник, но имя контейнера — istio-proxy.
Далее запускаем внешний сервис:
С экспериментальной средой все в порядке. Далее давайте проверим, открыт ли бизнес.
Посетим сервис svca, адрес сервиса svca можно узнать через kubectl get svc:
Просмотрите журналы svca и svcb:
Мы видим, что и service_a, и service_b возвращают журналы ошибок (примечание: метод go http get не возвращает ошибок для ответов, отличных от 2xx, мы осознаем наличие ошибок только тогда, когда видим в ответе код состояния 500). Источником является service_b, потому что он не может подключиться к внешней службе! Так почему я не могу подключиться к внешней службе? Это связано с тем, что по умолчанию службы с поддержкой Istio не могут получить доступ к внешним URL-адресам, поскольку iptables в поде перенаправляют весь исходящий трафик на прокси-сервер Sidecar, который обрабатывает цели доступа только внутри кластера. Итак, на службе Сервис svcb в меше не может получить доступ к внешнему сервису (msgd), нам нужно явно добавить правило egressrule:
Мы создаем EgressRule, который позволяет svcb получать доступ к определенным внешним службам:
Чтобы правило вступило в силу:
На этом этапе, если вы снова попробуете curl svca, мы увидим, что в журнале msgd появляется следующее содержимое:
Это означает, что связь между Svcb и внешней службой открыта!
Давайте сначала развернем svcb:v0.2:
Мы видим, что имя службы осталось прежним, но метка версии стала v0.2.Выполним это развертывание:
На данный момент, согласно методу планирования Kubernetes, два модуля svcb версий 0.1 и 0.2 должны нести трафик в соотношении 1:1. Чтобы легко просматривать распределение трафика, мы увеличиваем количество реплик pod каждой версии svcb до 2 (реплики: 2), так что всего в сервисной сетке будет 4 конечных точки svcb.
Получив доступ к трафику инъекций svca через curl, мы обнаружили, что трафик сконцентрирован на поде svcb:v0.2 и долгое время не менялся. Мы пытаемся сбалансировать трафик 1:1 между svcb:v0.1 и svcb:v0.2 со следующим правилом маршрутизации:
Согласно документации Istio, для вступления этого правила в силу потребуется некоторое время. После этого мы ввели трафик и обнаружили, что трафик переключился на Pod svcb:v0.1, и он долго не менялся, и не балансировался на svcb:v0.2.
Обновим правило маршрута и перережем весь трафик на svcb:v0.2:
Мы обновили правила с помощью команды замены Istio: route-rules-svcb. После обновления трафик инжектится снова, на этот раз трафик концентрируется на поде svcb:v0.2, через некоторое время появляется трафик на другом поде svcb:v0.2. Но трафика на svcb:v0.1 больше нет, переключение прошло успешно.
В балансировке нагрузки Kubernetes Service Kubernetes использует вероятностную переадресацию iptables (случайная —вероятность 0,5), поэтому такая балансировка трафика не является точной.Только после длительного прохождения большого объема трафика можно увидеть распределение трафика и установленные веса аналогичны, и возможно Istio такой же, это только введение, и я не буду копать глубже.
Конечно, «возможности» Istio с точки зрения средств правил маршрутизации намного больше, чем показано в приведенном выше примере.Если вы хотите перечислить их все, длина этой статьи увеличится. Заинтересованные друзья могут перейти к официальной документации.
Введите в браузере сервисный адрес Prometheushttp://10.103.160.37:9090, чтобы получить доступ к Prometheus:
Щелкните пункт меню: статус -> цели, чтобы проверить, является ли состояние каждой цели нормальным:
Если каждая цель находится в рабочем состоянии, как показано на рисунке выше, это означает, что Istio работает нормально. В противном случае обратитесь к содержимому раздела «Устранение неполадок istio», чтобы проверить Istio по отдельности, особенно цель istio-mesh не работает в среде istio-0.3.0+kubernetes 1.7.3.
Браузер вводит сервисный адрес графаны:http://10.105.21.25:3000/, откройте панель графаны:
Переключитесь на Istio Dashboard и отчитывайтесь перед Istio. Service Mesh вводит трафик, и мы увидим следующее изменение панели инструментов:
После успешного создания введите трафик в сеть Service Mesh, а затем получите доступ к ServiceGraph: http://{servicegraph_ip}:8088/dotviz В моей среде схема выглядит следующим образом:
Отношения вызова кажутся немного запутанными из-за того, что метод вызова, который я использую в программе, недостаточно стандартен? :(
Давайте установим аддон Zipkin:
Мы получаем доступ к следующему пользовательскому интерфейсу Zikpin и открываем http://{zipkin_service_ip}:9411 через браузер.
Затем мы вводим некоторый трафик в Service Mesh, а затем выбираем «svcb» в раскрывающемся списке «Имя службы» на домашней странице Zipkin, чтобы найти трассировку:
Мы видим: без каких-либо модификаций svca и svcb мы все еще можем найти связанные с svcb вызовы в Zipkin. Нажмите на одну из трасс, чтобы увидеть подробности:
Конечно, если вы хотите сделать более богатое и мощное отслеживание, вам может потребоваться некоторое сотрудничество в коде приложения.Подробнее см.:Распределенная трассировка с Istio.
Исходный код, задействованный в этой статье, находится вздесьЕго можно скачать, а образ демо-сервиса можно найти по адресумой докер-хабна тяге.
Оригинальная ссылка:Тони Пендулум.com/2018/01/03/…
Но получить микросервисы легко, а управлять ими сложно!
1. «Болевые точки» микросервисов
Единого стандарта для микросервисов не существует, и большинство из них представляет собой вертикальную сегментацию сфер бизнеса.Бизнесы делятся на обязанности согласно определенной гранулярности, и формируется четкий сервисный интерфейс с единой ответственностью, так что каждая часть планируется как микросервис. Схема связи между микросервисами относительно зрелая, и в области открытого исходного кода выбираются схемы RPC или RESTful API, такие как:gRPC,Apache ThriftЖдать. Большинство этих решений ориентированы на то, как данные упаковываются, передаются и распаковываются, и имеют мало общего с управлением услугами.Управление микросервисами — головная боль и боль в архитектуре микросервисов. Слово «управление» имеет множество значений, и дать точное определение сложно.Здесь можно перечислить множество синонимов управления, как второклассник: управление, контроль, правила, контроль, надзор, господство, регулирование, правило и т. д. Для микросервисов управление отражается в следующих аспектах:
- Регистрация и обнаружение службы
- Аутентификация и авторизация
- Контроль масштабирования сервиса
- Обратный прокси и балансировка нагрузки
- управление маршрутизацией
- коммутация трафика
- управление журналом
- Измерение производительности, мониторинг и настройка
- Распределенная трассировка
- Защита от перегрузки
- понижение уровня обслуживания
- Поддержка стратегии развертывания службы и обновления версии
- обработка ошибок
- ...
С точки зрения управления микросервисами, микросервисы на самом деле представляют собой «большую систему», внедрить эту большую систему непросто, тем более, что до сих пор не было особо изящного технического решения. Большинство программ (например:Dubbo,go-kitи т. д.) более или менее навязчивы для логики приложения, так что бизнес-разработчики могут не только сосредоточиться на самом бизнесе, но и позаботиться об этой логике «управления». И на рынке мало фреймворков со встроенной логикой управления микросервисами, и многие языки программирования связаны между собой. В этом случае крупные фабрики в основном выбирают разработку сами или трансформируют их на основе определенного фреймворка.Малые фабрики вообще могут лишь "лоскутить" какие-то "полуфабрикаты" и использовать их вместе.Таким образом, микросервисы прошли несколько этапов. годы.
2. Родился Service Mesh, и Istio несет «евангелие»
Я не знаю, должно ли приложение заботиться о логике реализации базового протокола связи, когда приложение обменивается данными между хостом и хостом в эпоху отсутствия протокола TCP/IP. Однако, подобно идее TCP/IP, после многих лет использования микросервисов люди обнаруживают, что необходимо самостоятельно абстрагировать слой логической сети, который специально используется для «реализации стратегий связи и управления микросервисами». ", так что приложения заботятся только о бизнесе, а все вопросы управления службами решаются на "этом уровне".Рис. 1. Расположение логики управления микросервисами между традиционными микросервисами
Рис. 2. Расположение логики управления микрослужбой после изоляции
Логическая сеть, состоящая из уровня «Логика управления услугами», определяется как сервисная сетка, и каждый микросервис содержит конечную точку сервисной сетки.
Понятие "Service Mesh" еще очень молодо. В Китае это слово переводится как "service mesh" или "service meshing layer". Здесь мы используем английское слово Service Mesh. Вот отрывок из статьи китайского сообщества ServiceMesh под названием «Ежегодная инвентаризация Service Mesh в 2017 г.«В статье о службе Обзор концепции Mesh:
В начале 2016 года «Service Mesh» было просто внутренним словом компании «Буоян», но после этого стало постепенно входить в сообщество:而Service Mesh真正引起大家关注要源于Istio项目的开源发布。 Зачем?个人觉得还是因为“爹好”！ Istio项目由Google、IBM共同合作创建，ЛюфтУчаствовал в проекте Envoy, который будет служить панелью данных для сервисной сетки Istio. Влияние Google и IBM способствовало быстрому распространению концепции Service Mesh, а также заставило всех осознать важность проекта Istio в сфере Service Mesh, поэтому они решили активно поддерживать и интегрировать свои продукты или проекты с проектом Istio.
29 сентября 2016 г. Термин «Service Mesh» впервые был публично использован в SF Microservices. Это знаменует начало термина «Service Mesh» от компании Buoyant для сообщества.
В октябре 2016 года Алекс Леонг начал публиковать серию статей «Сервисная сетка для Kubernetes». Под лозунгом «The Services must Mesh» Буойант и Линкерд начали проповедовать концепцию Service Mesh.
25 апреля 2017 г. Уильям Морган опубликовал запись в блоге «Что такое Service Mesh? И зачем она мне нужна?». Формально дано авторитетное определение Service Mesh.
Проект Istio — это последняя реализация концепции Service Mesh, направленная на предоставление услуг на всех основных платформах управления кластерами. Уровень Mesh изначально предназначен для реализации уровня управления услугами в Kubernetes. Он состоит из плоскости управления и плоскости данных (чувствует ли она себя иSDNКонцепция дизайна похожа). Плоскость управления реализована языком Go, включая Pilot, Mixer и Auth; функция плоскости данных временно предоставляется Envoy в виде развертывания Sidecar в Pod. Ниже приведена официальная схема архитектуры:
Рисунок 3: Схема архитектуры Istio (с официального сайта)
Envoy в sidecar проксирует весь входящий и исходящий трафик реального бизнес-контейнера в Pod и обрабатывает этот трафик в соответствии с «логикой управления», установленной плоскостью управления. И все это прозрачно для бизнес-приложений в Pod, и разработчики могут сосредоточиться на бизнес-логике, и им больше не нужно заботиться о логике управления микросервисами. Концепция дизайна Service Mesh, представленная Istio, считается «унифицированной микросервисной структурой» следующего поколения, а некоторые даже считают ее конечной точкой эволюции микросервисной инфраструктуры.
Istio выпустил версию 0.1 24 мая 2017 г. Релизная версия, на данный момент версия Istio обновлена до версии 0.4.0, скорость эволюции довольно высокая, но она все еще не используется в производственной среде, по крайней мере, до выхода версии 1.0. Но для первых пользователей Istio сейчас самое время погрузиться в Istio. В следующей части этой статьи мы познакомим вас с Istio на эмоциональном уровне и приступим к работе.
3. Установка Истио
В настоящее время Istio лучше всего поддерживает Kubernetes, поэтому наша экспериментальная среда настроена на Kubernetes. Что касается версии, текущая последняя версия Istio:0.4.0, эта версия, как говорят, используется с Kubernetes 1.7.4 и выше без каких-либо сбоев :). Мой кластер Kubernetes — v1.7.6, который как раз соответствует условиям. Вот процесс установки: (ОС на узле — Ubuntu 16.04)# wget -c https://github.com/istio/istio/releases/download/0.4.0/istio-0.4.0-linux.tar.gz
解压后，进入istio-0.4.0目录，
ls -F
bin/ install/ istio.VERSION LICENSE README.md samples/
cat istio.VERSION
DO NOT EDIT THIS FILE MANUALLY instead use
install/updateVersion.sh (see install/README.md)
export CA_HUB="docker.io/istio"
export CA_TAG="0.4.0"
export MIXER_HUB="docker.io/istio"
export MIXER_TAG="0.4.0"
export PILOT_HUB="docker.io/istio"
export PILOT_TAG="0.4.0"
export ISTIOCTL_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/istioctl"
export PROXY_TAG="0.4.0"
export ISTIO_NAMESPACE="istio-system"
export AUTH_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export PILOT_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export PROXY_DEBIAN_URL="https://storage.googleapis.com/istio-release/releases/0.4.0/deb"
export FORTIO_HUB="docker.io/istio"
export FORTIO_TAG="0.4.2"
cd install/kubernetes
我们先不用auth功能，因此使用istio.yaml这个文件进行Istio组件安装：
kubectl apply -f istio.yaml
namespace "istio-system" created
clusterrole "istio-pilot-istio-system" created
clusterrole "istio-initializer-istio-system" created
clusterrole "istio-mixer-istio-system" created
clusterrole "istio-ca-istio-system" created
clusterrole "istio-sidecar-istio-system" created
clusterrolebinding "istio-pilot-admin-role-binding-istio-system" created
clusterrolebinding "istio-initializer-admin-role-binding-istio-system" created
clusterrolebinding "istio-ca-role-binding-istio-system" created
clusterrolebinding "istio-ingress-admin-role-binding-istio-system" created
clusterrolebinding "istio-sidecar-role-binding-istio-system" created
clusterrolebinding "istio-mixer-admin-role-binding-istio-system" created
configmap "istio-mixer" created
service "istio-mixer" created
serviceaccount "istio-mixer-service-account" created
deployment "istio-mixer" created
customresourcedefinition "rules.config.istio.io" created
customresourcedefinition "attributemanifests.config.istio.io" created
... ...
customresourcedefinition "reportnothings.config.istio.io" created
attributemanifest "istioproxy" created
attributemanifest "kubernetes" created
stdio "handler" created
logentry "accesslog" created
rule "stdio" created
metric "requestcount" created
metric "requestduration" created
metric "requestsize" created
metric "responsesize" created
metric "tcpbytesent" created
metric "tcpbytereceived" created
prometheus "handler" created
rule "promhttp" created
rule "promtcp" created
kubernetesenv "handler" created
rule "kubeattrgenrulerule" created
kubernetes "attributes" created
configmap "istio" created
customresourcedefinition "destinationpolicies.config.istio.io" created
customresourcedefinition "egressrules.config.istio.io" created
customresourcedefinition "routerules.config.istio.io" created
service "istio-pilot" created
serviceaccount "istio-pilot-service-account" created
deployment "istio-pilot" created
service "istio-ingress" created
serviceaccount "istio-ingress-service-account" created
deployment "istio-ingress" created
serviceaccount "istio-ca-service-account" created
deployment "istio-ca" created
Примечание. Я также установил версию Istio 0.3.0 на Kubernetes v1.7.3, но при создании компонента будет сообщено о следующей ошибке (эта ошибка может привести к неправильной работе последующего дополнения после установки):
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
unable to recognize "istio.yaml": no matches for config.istio.io/, Kind=metric
После установки мы увидим следующие Pod и Service, работающие под пространством имен istio-system (поскольку размер образа каждого компонента Istio не маленький, потребуется некоторое время, чтобы статус Pod изменился на Running, подождите терпеливо):
# kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
istio-ca-1363003450-jskp5 1/1 Running 0 3d
istio-ingress-1005666339-c7776 1/1 Running 4 3d
istio-mixer-465004155-twhxq 3/3 Running 24 3d
istio-pilot-1861292947-6v37w 2/2 Running 18 3d
kubectl get svc -n istio-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingress 10.98.10.87 <pending> 80:31759/TCP,443:25804/TCP 4d
istio-mixer 10.109.244.155 <none> 9091/TCP,15004/TCP,9093/TCP,9094/TCP,9102/TCP,9125/UDP,42422/TCP 4d
istio-pilot 10.105.80.55 <none> 15003/TCP,443/TCP 4d
Istio успешно установлен!
4. Проверка политики управления услугами
Далее давайте на нескольких примерах проверим возможности Istio в управлении сервисами! (Istio поставляется с несколькими полными примерами, такими как bookinfo, для проверки возможности управления сервисом, но эти примеры здесь использоваться не будут)1. Проверьте среду и топологию
Давайте сначала посмотрим на принципиальную схему среды проверки:Мы видим, что в Service Mesh развернуты два сервиса: server_a и service_b, первый вызывает второй для выполнения определенного дела, а второй вызывает внешние сервисы для завершения бизнес-логики.
- service_a: имитировать платную услугу, после получения запроса клиента выполнить обработку оплаты и отправить результат обработки пользователю через службу уведомлений msg, предоставляемую service_b. Конечная точка этой службы — /pay;
- service_b: имитация службы уведомления.После получения запроса service_a перешлите сообщение во внешнюю службу, чтобы завершить логику уведомления. Конечная точка службы — /notify;
- внешний сервис: вне Service Mesh;
- клиент: Мы используем curl для имитации.
Давайте сначала развернем v0.1 версии service_a и service_b:
Если взять в качестве примера развертывание service_a, файл развертывания service_a выглядит следующим образом:
//svca-v0.1.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: svca
spec:
replicas: 1
template:
metadata:
labels:
app: svca
version: v0.1
spec:
containers:
- name: svca
image: docker.io/bigwhite/istio-demo-svca:v0.1
imagePullPolicy: Always
---
apiVersion: v1
kind: Service
metadata:
name: svca
labels:
app: svca
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
selector:
app: svca
Обратите внимание, что когда мы развертываем service_a, мы не можем напрямую использовать kubectl apply -f svca-v0.1.yaml, но применяем yaml, обработанный istioctl (bin в каталоге установки Istio нужно поместить в PATH) для внедрения в боковой контейнер. Конечно, его также можно настроить на автоматическое внедрение sidecars для каждого модуля, запущенного Kubernetes, но здесь мы не используем автоматическое внедрение. Выполняем следующую команду:
# kubectl apply -f <(istioctl kube-inject -f svca-v0.1.yaml)
deployment "svca" created
service "svca" created
kubectl get pods
NAME READY STATUS RESTARTS AGE
svca-1997590752-tpwjf 2/2 Running 0 2m
Таким же образом создадим svcb:v0.1:
# kubectl apply -f <(istioctl kube-inject -f svcb-v0.1.yaml)
deployment "svcb" created
service "svcb" created
Мы видим, что Istio вставляет в каждый Pod sidecar-контейнер — это упомянутый выше посланник, но имя контейнера — istio-proxy.
Далее запускаем внешний сервис:
# nohup ./msgd > 1.log & 2>&1
[1] 9423
С экспериментальной средой все в порядке. Далее давайте проверим, открыт ли бизнес.
2. Правила выхода
Согласно нашим предыдущим настройкам, мы используем curl для доступа к конечной точке /pay сервиса service_a.Проверим IP и порт сервиса svca:# kubectl get svc
NAME CLUSTER-IP EXTERNAL-IP PORT(S)
svca 10.105.38.238 <none> 80/TCP 9h
svcb 10.105.119.194 <none> 80/TCP 9h
Посетим сервис svca, адрес сервиса svca можно узнать через kubectl get svc:
# curl {svca_ip}/pay
Просмотрите журналы svca и svcb:
//service_a的日志：
service_a:v0.1 is serving the request...
service_a:v0.1 pays ok
&{500 Internal Server Error 500 HTTP/1.1 1 1 map[X-Content-Type-Options:[nosniff] Date:[Tue, 02 Jan 2018 15:41:50 GMT] Content-Length:[66] Content-Type:[text/plain; charset=utf-8]] 0xc420058d40 66 [] false false map[] 0xc4200eaf00 <nil>}
service_a:v0.1 notify customer ok
// service_b的日志：
&{GET /notify?msg=service_a:v0.1-pays-ok HTTP/1.1 1 1 map[User-Agent:[Go-http-client/1.1] Accept-Encoding:[gzip]] {} <nil> 0 [] false svcb map[] map[] <nil> map[] 127.0.0.1:58778 /notify?msg=service_a:v0.1-pays-ok <nil> <nil> <nil> 0xc4200fa3c0}
service_b:v0.1 is serving the request...
service_b:v0.1 send msg error: Get http://10.100.35.27:9997/send?msg=service_a:v0.1-pays-ok: EOF
Мы видим, что и service_a, и service_b возвращают журналы ошибок (примечание: метод go http get не возвращает ошибок для ответов, отличных от 2xx, мы осознаем наличие ошибок только тогда, когда видим в ответе код состояния 500). Источником является service_b, потому что он не может подключиться к внешней службе! Так почему я не могу подключиться к внешней службе? Это связано с тем, что по умолчанию службы с поддержкой Istio не могут получить доступ к внешним URL-адресам, поскольку iptables в поде перенаправляют весь исходящий трафик на прокси-сервер Sidecar, который обрабатывает цели доступа только внутри кластера. Итак, на службе Сервис svcb в меше не может получить доступ к внешнему сервису (msgd), нам нужно явно добавить правило egressrule:
Мы создаем EgressRule, который позволяет svcb получать доступ к определенным внешним службам:
//rules/enable-svcb-engress-rule.yaml
apiVersion: config.istio.io/v1alpha2
kind: EgressRule
metadata:
name: enable-svcb-engress-rule
spec:
destination:
service: 10.100.35.27
ports:
- port: 9997
protocol: http
Чтобы правило вступило в силу:
# istioctl create -f enable-svcb-engress-rule.yaml
Created config egress-rule/default/enable-svcb-engress-rule at revision 30031258
На этом этапе, если вы снова попробуете curl svca, мы увидим, что в журнале msgd появляется следующее содержимое:
2018/01/02 23:58:16 &{GET /send?msg=service_a:v0.1-pays-ok HTTP/1.1 1 1 map[X-Ot-Span-Context:[2157e7ffb8105330;2157e7ffb8105330;0000000000000000] Content-Length:[0] User-Agent:[Go-http-client/1.1] X-Forwarded-Proto:[http] X-Request-Id:[13c3af6e-2f52-993d-905f-aa6aa4b57e2d] X-Envoy-Decorator-Operation:[default-route] X-B3-Spanid:[2157e7ffb8105330] X-B3-Sampled:[1] Accept-Encoding:[gzip] X-B3-Traceid:[2157e7ffb8105330] X-Istio-Attributes:[Ch8KCXNvdXJjZS5pcBISMhAAAAAAAAAAAAAA//8KLgAMCjoKCnNvdXJjZS51aWQSLBIqa3ViZXJuZXRlczovL3N2Y2ItMjAwODk3Mzc2OS1ncTBsaC5kZWZhdWx0]] {} <nil> 0 [] false 10.100.35.27:9997 map[] map[] <nil> map[] 10.100.35.28:38188 /send?msg=service_a:v0.1-pays-ok <nil> <nil> <nil> 0xc4200584c0}
2018/01/02 23:58:16 Msgd is serving the request...
2018/01/02 23:58:16 Msgd recv msg ok, msg= service_a:v0.1-pays-ok
Это означает, что связь между Svcb и внешней службой открыта!
3. Перенести трафик на новую версию svcb:v0.2
У нас часто бывают такие требования.Когда svcb работает в течение определенного периода времени, svcb добавляет новые функции, и версия должна быть обновлена до v0.2.В это время мы развернем svcb:v0.2 и постепенно переключим трафик на v0 .2 .Давайте сначала развернем svcb:v0.2:
// svcb-v0.2.yaml
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: svcb-v0.2
spec:
replicas: 1
template:
metadata:
labels:
app: svcb
version: v0.2
spec:
containers:
- name: svcb
image: docker.io/bigwhite/istio-demo-svcb:v0.2
imagePullPolicy: Always
Мы видим, что имя службы осталось прежним, но метка версии стала v0.2.Выполним это развертывание:
# kubectl apply -f <(istioctl kube-inject -f svcb-v0.2.yaml)
deployment "svcb-v0.2" created
kubectl get pods
NAME READY STATUS RESTARTS AGE
svca-1997590752-pq9zg 2/2 Running 0 9h
svcb-2008973769-gq0lh 2/2 Running 0 9h
svcb-v0.2-3233505404-0g55w 2/2 Running 0 1m
svcb服务下又增加了一个endpoint:
kubectl describe svc/svcb
.... ...
Selector: app=svcb
Type: ClusterIP
IP: 10.105.119.194
Port: <unset> 80/TCP
Endpoints: 10.40.0.28:8080,10.46.0.12:8080
... ...
На данный момент, согласно методу планирования Kubernetes, два модуля svcb версий 0.1 и 0.2 должны нести трафик в соотношении 1:1. Чтобы легко просматривать распределение трафика, мы увеличиваем количество реплик pod каждой версии svcb до 2 (реплики: 2), так что всего в сервисной сетке будет 4 конечных точки svcb.
Получив доступ к трафику инъекций svca через curl, мы обнаружили, что трафик сконцентрирован на поде svcb:v0.2 и долгое время не менялся. Мы пытаемся сбалансировать трафик 1:1 между svcb:v0.1 и svcb:v0.2 со следующим правилом маршрутизации:
// route-rules-svcb-v0.2-50.yaml
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
name: route-rules-svcb
spec:
destination:
name: svcb
precedence: 1
route:
- labels:
version: v0.1
weight: 50
- labels:
version: v0.2
weight: 50
istioctl create -f route-rules-svcb-v0.2-50.yaml
Created config route-rule/default/route-rules-svcb at revision 30080638
Согласно документации Istio, для вступления этого правила в силу потребуется некоторое время. После этого мы ввели трафик и обнаружили, что трафик переключился на Pod svcb:v0.1, и он долго не менялся, и не балансировался на svcb:v0.2.
Обновим правило маршрута и перережем весь трафик на svcb:v0.2:
//route-rules-svcb-v0.2-100.yaml
apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
name: route-rules-svcb
spec:
destination:
name: svcb
precedence: 1
route:
- labels:
version: v0.2
weight: 100
istioctl replace -f route-rules-svcb-v0.2-100.yaml
Updated config route-rule/default/route-rules-svcb to revision 30082944
Мы обновили правила с помощью команды замены Istio: route-rules-svcb. После обновления трафик инжектится снова, на этот раз трафик концентрируется на поде svcb:v0.2, через некоторое время появляется трафик на другом поде svcb:v0.2. Но трафика на svcb:v0.1 больше нет, переключение прошло успешно.
В балансировке нагрузки Kubernetes Service Kubernetes использует вероятностную переадресацию iptables (случайная —вероятность 0,5), поэтому такая балансировка трафика не является точной.Только после длительного прохождения большого объема трафика можно увидеть распределение трафика и установленные веса аналогичны, и возможно Istio такой же, это только введение, и я не буду копать глубже.
Конечно, «возможности» Istio с точки зрения средств правил маршрутизации намного больше, чем показано в приведенном выше примере.Если вы хотите перечислить их все, длина этой статьи увеличится. Заинтересованные друзья могут перейти к официальной документации.
Пять, установка плагина
Мощные возможности Istio по управлению микросервисами также находят свое отражение в интеграции дополнений, таких как Grafana, Prometheus, ServiceGraph, Zipkin и т. д. Приложение может иметь возможности сбора данных, измерения и визуализации, а также возможности распределенного отслеживания сервисов без каких-либо изменений. Мы можем найти установочные файлы этих дополнений в установочном пакете Istio, давайте попробуем их один за другим.1. Прометей и Графана
Сначала установим плагины PROMETHEUS и GRAFANA (расположенные под ISTIO-0.4.0 / Установка / Kubernetes / Addon):# kubectl apply -f prometheus.yaml
configmap "prometheus" created
service "prometheus" created
deployment "prometheus" created
kubectl apply -f grafana.yaml
service "grafana" created
deployment "grafana" created
kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
grafana-3617079618-zpglx 1/1 Running 0 5m
prometheus-168775884-ppfxr 1/1 Running 0 5m
... ...
kubectl get svc -n istio-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
grafana 10.105.21.25 <none> 3000/TCP 16m
prometheus 10.103.160.37 <none> 9090/TCP 16m
... ...
Введите в браузере сервисный адрес Prometheushttp://10.103.160.37:9090, чтобы получить доступ к Prometheus:
Щелкните пункт меню: статус -> цели, чтобы проверить, является ли состояние каждой цели нормальным:
Если каждая цель находится в рабочем состоянии, как показано на рисунке выше, это означает, что Istio работает нормально. В противном случае обратитесь к содержимому раздела «Устранение неполадок istio», чтобы проверить Istio по отдельности, особенно цель istio-mesh не работает в среде istio-0.3.0+kubernetes 1.7.3.
Браузер вводит сервисный адрес графаны:http://10.105.21.25:3000/, откройте панель графаны:
Переключитесь на Istio Dashboard и отчитывайтесь перед Istio. Service Mesh вводит трафик, и мы увидим следующее изменение панели инструментов:
2. График обслуживания
Плагин ServiceGraph используется для просмотра отношения вызова службы Давайте создадим этот компонент:# kubectl apply -f servicegraph.yaml
deployment "servicegraph" created
service "servicegraph" created
kubectl get svc -n istio-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
servicegraph 10.108.245.21 <none> 8088/TCP 52s
... ...
После успешного создания введите трафик в сеть Service Mesh, а затем получите доступ к ServiceGraph: http://{servicegraph_ip}:8088/dotviz В моей среде схема выглядит следующим образом:
Отношения вызова кажутся немного запутанными из-за того, что метод вызова, который я использую в программе, недостаточно стандартен? :(
3. Зипкин
IStio интегрирует zipkin, с помощью zipkin мы можем отслеживать вызовы распределенных служб. Я построил службу распределенных вызовов на основе Jaeger и OpenTraacing, что очень громоздко. И если вы хотите использовать трассировку, вторжение в код приложения необходимо.Давайте установим аддон Zipkin:
# kubectl apply -f zipkin.yaml
deployment "zipkin" created
service "zipkin" created
kubectl get svc -n istio-system
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
zipkin 10.105.7.219 <none> 9411/TCP 1h
Мы получаем доступ к следующему пользовательскому интерфейсу Zikpin и открываем http://{zipkin_service_ip}:9411 через браузер.
Затем мы вводим некоторый трафик в Service Mesh, а затем выбираем «svcb» в раскрывающемся списке «Имя службы» на домашней странице Zipkin, чтобы найти трассировку:
Мы видим: без каких-либо модификаций svca и svcb мы все еще можем найти связанные с svcb вызовы в Zipkin. Нажмите на одну из трасс, чтобы увидеть подробности:
Конечно, если вы хотите сделать более богатое и мощное отслеживание, вам может потребоваться некоторое сотрудничество в коде приложения.Подробнее см.:Распределенная трассировка с Istio.
6. Резюме
Проект Istio родился менее года назад и еще далек от зрелости. Быстрая и активная разработка может привести к значительным изменениям интерфейса и механизмов реализации Istio, поэтому нет гарантии, что содержание этой статьи будет применимо ко всем последующим выпускам Istio.Исходный код, задействованный в этой статье, находится вздесьЕго можно скачать, а образ демо-сервиса можно найти по адресумой докер-хабна тяге.
Оригинальная ссылка:Тони Пендулум.com/2018/01/03/…