Проверка орфографии и пунктуации онлайн, проверить текст на грамотность и ошибки

Сервис Istio.com предназначен для онлайн-проверки орфографии и пунктуации текста. Это бесплатный сайт, направленный на поиск ошибок и опечаток.

Какие ошибки распознает сервис?

Для Istio.com разработан алгоритм, распознающий разные виды ошибок. Среди них:

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

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

Работать с сайтом можно без регистрации и авторизации.

На каком языке проводится проверка?

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

Сервис предоставляет бесплатную проверку орфографии. Лимитов на количество текстов в сутки нет.

Поиск и исправление ошибок

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

Онлайн-проверка пунктуации позволяет увидеть синтаксические проблемы. Сервис поможет правильно расставить знаки препинания, заглавные буквы после точек. Также после анализа можно увидеть дубль запятых, скобок, точек и других знаков.

Как пользоваться сервисом?

Сервис проверки грамотности работает в режиме онлайн. Пользователю нужно следовать следующему алгоритму:

1. В поле вставить текст, который нужно проверить на ошибки и опечатки.
2. Нажать на кнопку «Проверить текст» или «Орфография», если нужно проверить другой текст или повторить.
3. В течение пяти секунд результат будет готов.
4. Все найденные опечатки, грамматические и пунктуационные недочеты будут подсвечены красным цветом.
5. Исправить ошибки можно сразу во встроенном редакторе. Нужно на проблемное слово нажать правой кнопкой мыши, из появившегося перечня выбрать подходящий вариант.

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

Istio.com — Инструкция по пользованию сервисом

Toggle nav

В основном работа идет со списком слов из которых были отброшены стопслова, или как их еще называют водные. Понятие стоп-слов у нас несколько шире чем у поисковых систем. Мы отбрасываем все слова длиной в 1-2 символа, все вводные слова, все оценочные эпитеты и прочие слова которые обычно не несут смысловой нагрузки, а лишь помогают воспринять текст или оценивают те или иные его качества.

Пример текста из одних стоп-слов:
Любимый мой! Я хочу сказать тебе, что ты у меня самый любимый! Ты самое лучшее, что было у меня. Я никогда не смогу сказать тебе об этом, однако, это на самом деле так. Ты действительно лучший из всех. На самом деле я больше не могу без тебя. Когда ты наконец поймешь это? Неужели я так и буду без тебя? Я так не смогу! Когда я думаю о тебе то я понимаю, что ты идеальный! Ты нужен мне. Я хочу чтобы ты был моим! Ведь ты же знаешь, что только я смогу быть верной тебе. Я предлагаю тебе как можно быстрее прийти ко мне и стать моим. Я вся твоя, и я не знаю как я смогу без тебя. Мне нужен ты, и больше никто мне не нужен. Лучше меня не будет, чем я буду без тебя.

Пример текста, в котором нет стоп-слов:
Дьяченко Максим Игоревич. Место жительства — город Одесса. Образование — Одесская Национальная Морская Академия. Специализация — программирование, интернет-технологии, электронная коммерция, руководство проектами. Эксцентричен, хитер, вспыльчив, коммуникабелен. Предпочитает носить одежду светлых тонов. Любвеобилен. Холост. Злоупотребляет интернетом. Знак зодиака — весы. Интеллект выше среднего. Характер тяжелый. Знание иностранных языков — английский, французский. Интересуется психологией. Чувство стиля отсутствует. Эксплуатирует чужой труд. Занудный, скучный, наглый, темпераментный.

Водность это процент отброшенных слов. Нормальное значение 30-60% помогает немного представить себе качество текста… Если водность слишком маленькая, то текст трудно читается — если большая, то он кажется слишком уж малосодержательным. Чтобы лучше понять разницу посмотрите на примеры выше. В них водность рана 100% и 0% соответственно. Лично я пользуюсь этим параметром чисто интуитивно..

Словарь текста это количество РАЗНЫХ слов в тексте.

Обезвоженный словарь это количество РАЗНЫХ слов в тексте за вычетом стоп-слов.

В списке наиболее употребляемых слов указано сколько раз это слово употребляется в тексте и процент от ОБЕЗВОЖЕННОГО СЛОВАРЯ.

Назад к микросервисам вместе с Istio. Часть 1 / Флант corporate blog / Habr

Прим. перев.: Service mesh’и определённо стали актуальным решением в современной инфраструктуре для приложений, следующих микросервисной архитектуре. Хотя Istio может быть на слуху у многих DevOps-инженеров, это довольно новый продукт, который, будучи комплексным в смысле предоставляемых возможностей, может потребовать значительного времени для знакомства. Немецкий инженер Rinor Maloku, отвечающий за облачные вычисления для крупных клиентов в телекоммуникационной компании Orange Networks, написал замечательный цикл материалов, что позволяют достаточно быстро и глубоко погрузиться в Istio. Начинает же он свой рассказ с того, что вообще умеет Istio и как на это можно быстро посмотреть собственными глазами.

Istio — Open Source-проект, разработанный при сотрудничестве команд из Google, IBM и Lyft. Он решает сложности, возникающие в приложениях, основанных на микросервисах, например, такие как:

• Управление трафиком: таймауты, повторные попытки, балансировка нагрузки;
• Безопасность: аутентификация и авторизация конечного пользователя;
• Наблюдаемость: трассировка, мониторинг, логирование.

Все они могут быть решены на уровне приложения, однако после этого ваши сервисы перестанут быть «микро». Все дополнительные усилия по решению этих проблем — лишний расход ресурсов компании, которые могли бы использоваться непосредственно для бизнес-ценностей. Рассмотрим пример:

Менеджер проектов: Как долго добавлять возможность обратной связи?
Разработчик: Два спринта.

МП: Что?.. Это ведь всего лишь CRUD!
Р: Сделать CRUD — простая часть задачи, но нам ещё потребуется аутентифицировать и авторизовывать пользователей и сервисы. Поскольку сеть ненадёжна, понадобится реализовать повторные запросы, а также паттерн circuit breaker в клиентах. Ещё, чтобы убедиться, что вся система не упала, понадобятся таймауты и bulkheads (подробнее об обоих упомянутых паттернах см. дальше в статье — прим. перев.), а для того, чтобы обнаруживать проблемы, потребуется мониторинг, трассировка, […]

МП: Ох, давайте тогда просто вставим эту фичу в сервис Product.

Думаю, идея понятна: объём шагов и усилий, которые требуются для добавления одного сервиса, огромен. В этой статье мы рассмотрим, как Istio устраняет все упомянутые выше сложности (не являющиеся целевыми для бизнес-логики) из сервисов.

Примечание: Статья предполагает, что у вас есть практические знания по Kubernetes. В ином случае рекомендую прочитать моё введение в Kubernetes и только после этого продолжить чтение данного материала.

Идея Istio

В мире без Istio один сервис делает прямые запросы к другому, а в случае сбоя сервис должен сам обработать его: предпринять новую попытку, предусмотреть таймаут, открыть circuit breaker и т.п.

Сетевой трафик в Kubernetes

Istio же предлагает специализированное решение, полностью отделённое от сервисов и функционирующее путём вмешательства в сетевое взаимодействие. И таким образом оно реализует:

• Отказоустойчивость: опираясь на код статуса в ответе, оно понимает, произошёл ли сбой в запросе, и выполняет его повторно.
• Канареечные выкаты: перенаправляет на новую версию сервиса лишь фиксированное процентом число запросов.
• Мониторинг и метрики: за какое время сервис ответил?
• Трассировка и наблюдаемость: добавляет специальные заголовки в каждый запрос и выполняет их трассировку в кластере.
• Безопасность: извлекает JWT-токен, аутентифицирует и авторизует пользователей.

Это лишь некоторые из возможностей (действительно лишь некоторые!), чтобы заинтриговать вас. А теперь давайте погрузимся в технические подробности!

Архитектура Istio

Istio перехватывает весь сетевой трафик и применяет к нему набор правил, вставляя в каждый pod умный прокси в виде sidecar-контейнера. Прокси, которые активируют все возможности, образуют собой Data Plane, и они могут динамически настраиваться с помощью Control Plane.

Data Plane

Вставляемые в pod’ы прокси позволяют Istio с лёгкостью добиться соответствия нужным нам требованиям. Например, проверим функции повторных попыток и circuit breaker.

Как retries и circuit breaking реализованы в Envoy

Подытожим:

1. Envoy (речь про прокси, находящийся в sidecar-контейнере, который распространяется и как отдельный продукт — прим. перев.) отправляет запрос первому экземпляру сервиса B и происходит сбой.
2. Envoy Sidecar предпринимает повторную попытку (retry). (1)
3. Запрос со сбоем возвращается вызвавшему его прокси.
4. Так открывается Circuit Breaker и происходит вызов следующего сервиса для последующих запросов. (2)

Это означает, что вам не придётся использовать очередную библиотеку Retry, не придётся делать свою реализацию Circuit Breaking и Service Discovery на языке программирования X, Y или Z. Всё это и многое другое доступно из коробки в Istio и не требует никаких изменений в коде.

Отлично! Теперь вы можете захотеть отправиться в вояж с Istio, но всё ещё есть какие-то сомнения, открытые вопросы. Если это универсальное решение на все случаи в жизни, то у вас возникает закономерное подозрение: ведь все такие решения в действительности оказываются не подходящими ни для какого случая.

И вот наконец вы спросите: «Оно настраивается?»

Теперь вы готовы к морскому путешествию — и давайте же познакомимся с Control Plane.

Control Plane

Он состоит из трёх компонентов: Pilot, Mixer и Citadel, — которые совместными усилиями настраивают Envoy’и для маршрутизации трафика, применяют политики и собирают телеметрические данные. Схематично всё это выглядит так:

Взаимодействие Control Plane с Data Plane

Envoy’и (т.е. data plane) сконфигурированы с помощью Kubernetes CRD (Custom Resource Definitions), определёнными Istio и специально предназначенными для этой цели. Для вас это означает, что они представляются очередным ресурсом в Kubernetes со знакомым синтаксисом. После создания этот ресурс будет подобран control plane’ом и применён к Envoy’ям.

Отношение сервисов к Istio

Мы описали отношение Istio к сервисам, но не обратное: как же сервисы относятся к Istio?

Честно говоря, о присутствии Istio сервисам известно так же хорошо, как рыбам — о воде, когда они спрашивают себя: «Что вообще такое вода?».

Иллюстрация Victoria Dimitrakopoulos: — Как вам вода? — Что вообще такое вода?

Таким образом, вы можете взять рабочий кластер и после деплоя компонентов Istio сервисы, находящиеся в нём, продолжат работать, а после устранения этих компонентов — снова всё будет хорошо. Понятное дело, что при этом вы потеряете возможности, предоставляемые Istio.

Достаточно теории — давайте перенесём это знание в практику!

Istio на практике

Istio требует кластера Kubernetes, в котором как минимум доступны 4 vCPU и 8 Гб RAM. Чтобы быстро поднять кластер и следовать инструкциям из статьи, рекомендую воспользоваться Google Cloud Platform, которая предлагает новым пользователям бесплатные $300.

После создания кластера и настройки доступа к Kubernetes через консольную утилиту можно установить Istio через пакетный менеджер Helm.

Установка Helm

Установите клиент Helm на своём компьютере, как рассказывают в официальной документации. Его мы будем использовать для генерации шаблонов для установки Istio в следующем разделе.

Установка Istio

Скачайте ресурсы Istio из последнего релиза (оригинальная авторская ссылка на версию 1.0.5 изменена на актуальную, т.е. 1.0.6 — прим. перев.), извлеките содержимое в одну директорию, которую я буду в дальнейшем называть [istio-resources].

Для простоты идентификации ресурсов Istio создайте в кластере K8s пространство имён istio-system:

$ kubectl create namespace istio-system

Завершите установку, перейдя в каталог [istio-resources] и выполнив команду:

$ helm template install/kubernetes/helm/istio \
  --set global.mtls.enabled=false \
  --set tracing.enabled=true \
  --set kiali.enabled=true \
  --set grafana.enabled=true \
  --namespace istio-system > istio.yaml

Эта команда выведет ключевые компоненты Istio в файл istio.yaml. Мы изменили стандартный шаблон под себя, указав следующие параметры:

• global.mtls.enabled установлено в false (т.е. mTLS-аутентификация отключена — прим перев.), чтобы упростить наш процесс знакомства;
• tracing.enabled включает трассировку запросов с помощью Jaeger;
• kiali.enabled устанавливает Kiali в кластер для визуализации сервисов и трафика;
• grafana.enabled устанавливает Grafana для визуализации собранных метрик.

Применим сгенерированные ресурсы командой:

$ kubectl apply -f istio.yaml

Установка Istio в кластер завершена! Дождитесь, пока все pod’ы в пространстве имён istio-system окажутся в состоянии Running или Completed, выполнив команду ниже:

$ kubectl get pods -n istio-system

Теперь мы готовы продолжить в следующем разделе, где поднимем и запустим приложение.

Архитектура приложения Sentiment Analysis

Воспользуемся примером микросервисного приложения Sentiment Analysis, использованного в уже упомянутой статье-введении в Kubernetes. Оно достаточно сложное, чтобы показать возможности Istio на практике.

Приложение состоит из четырёх микросервисов:

1. Сервис SA-Frontend, который обслуживает фронтенд приложения на Reactjs;
2. Сервис SA-WebApp, который обслуживает запросы Sentiment Analysis;
3. Сервис SA-Logic, который выполняет сам сентимент-анализ;
4. Сервис SA-Feedback, который получает от пользователей обратную связь о точности проведённого анализа.

На этой схеме помимо сервисов мы видим также Ingress Controller, который в Kubernetes маршрутизирует входящие запросы на соответствующие сервисы. В Istio используется схожая концепция в рамках Ingress Gateway, подробности о котором последуют.

Запуск приложения с прокси от Istio

Для дальнейших операций, упоминаемых в статье, склонируйте себе репозиторий istio-mastery. В нём содержатся приложение и манифесты для Kubernetes и Istio.

Вставка sidecar’ов

Вставка может быть произведена автоматически или вручную. Для автоматической вставки sidecar-контейнеров потребуется выставить пространству имён лейбл istio-injection=enabled, что делается следующей командой:

$ kubectl label namespace default istio-injection=enabled
namespace/default labeled

Теперь каждый pod, который будет разворачиваться в пространстве имён по умолчанию (default) получит свой sidecar-контейнер. Чтобы убедиться в этом, давайте задеплоим тестовое приложение, перейдя в корневой каталог репозитория [istio-mastery] и выполнив следующую команду:

$ kubectl apply -f resource-manifests/kube
persistentvolumeclaim/sqlite-pvc created
deployment.extensions/sa-feedback created
service/sa-feedback created
deployment.extensions/sa-frontend created
service/sa-frontend created
deployment.extensions/sa-logic created
service/sa-logic created
deployment.extensions/sa-web-app created
service/sa-web-app created

Развернув сервисы, проверим, что у pod’ов по два контейнера (с самим сервисом и его sidecar’ом), выполнив команду kubectl get pods и убедившись, что под столбцом READY указано значение 2/2, символизирующее, что оба контейнера запущены:

$ kubectl get pods
NAME                           READY     STATUS    RESTARTS   AGE
sa-feedback-55f5dc4d9c-c9wfv   2/2       Running   0          12m
sa-frontend-558f8986-hhkj9     2/2       Running   0          12m
sa-logic-568498cb4d-2sjwj      2/2       Running   0          12m
sa-logic-568498cb4d-p4f8c      2/2       Running   0          12m
sa-web-app-599cf47c7c-s7cvd    2/2       Running   0          12m

Визуально это представляется так:

Прокси Envoy в одном из pod’ов

Теперь, когда приложение поднято и функционирует, нам потребуется разрешить входящему трафику приходить в приложение.

Ingress Gateway

Лучшая практика добиться этого (разрешить трафик в кластере) — через Ingress Gateway в Istio, что располагается у «границы» кластера и позволяет включать для входящего трафика такие функции Istio, как маршрутизация, балансировка нагрузки, безопасность и мониторинг.

Компонент Ingress Gateway и сервис, который пробрасывает его вовне, были установлены в кластер во время инсталляции Istio. Чтобы узнать внешний IP-адрес сервиса, выполните:

$ kubectl get svc -n istio-system -l istio=ingressgateway
NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP
istio-ingressgateway   LoadBalancer   10.0.132.127   13.93.30.120

Мы будем обращаться к приложению по этому IP и дальше (я буду ссылаться на него как EXTERNAL-IP), поэтому для удобства запишем значение в переменную:

$ EXTERNAL_IP=$(kubectl get svc -n istio-system \
  -l app=istio-ingressgateway \
  -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

Если попробуете сейчас зайти на этот IP через браузер, то получите ошибку Service Unavailable, т.к. по умолчанию Istio блокирует весь входящий трафик, пока не определён Gateway.

Ресурс Gateway

Gateway — это CRD (Custom Resource Definition) в Kubernetes, определяемый после установки Istio в кластере и активирующий возможность указывать порты, протокол и хосты, для которых мы хотим разрешить входящий трафик.

В нашем случае мы хотим разрешить HTTP-трафик на 80-й порт для всех хостов. Задача реализуется следующим определением (http-gateway.yaml):

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

Такая конфигурация не нуждается в объяснениях за исключением селектора istio: ingressgateway. С помощью этого селектора мы можем указать, к какому Ingress Gateway применить конфигурацию. В нашем случае таковым является контроллер Ingress Gateway, что был по умолчанию установлен в Istio.

Конфигурация применяется вызовом следующей команды:

$ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created

Теперь шлюз разрешает доступ к порту 80, но не имеет представления о том, куда маршрутизировать запросы. Для этого понадобятся Virtual Services.

Ресурс VirtualService

VirtualService указывает Ingress Gateway’ю, как маршрутизировать запросы, которые разрешены внутри кластера.

Запросы к нашему приложению, приходящие через http-gateway, должны быть отправлены в сервисы sa-frontend, sa-web-app и sa-feedback:

Маршруты, которые необходимо настроить с VirtualServices

Рассмотрим запросы, которые должны направляться на SA-Frontend:

• Точное совпадение по пути / должно отправляться в SA-Frontend для получения index.html;
• Пути с префиксом /static/* должны отправляться в SA-Frontend для получения статических файлов, используемых во фронтенде, таких как CSS и JavaScript;
• Пути, попадающие под регулярное выражение '^.*\.(ico|png|jpg)$', должны отправляться в SA-Frontend, т.к. это картинки, отображаемые на странице.

Реализация достигается следующей конфигурацией (sa-virtualservice-external.yaml):

kind: VirtualService
metadata:
  name: sa-external-services
spec:
  hosts:
  - "*"
  gateways:
  - http-gateway                      # 1
  http:
  - match:
    - uri:
        exact: /
    - uri:
        exact: /callback
    - uri:
        prefix: /static
    - uri:
        regex: '^.*\.(ico|png|jpg)$'
    route:
    - destination:
        host: sa-frontend             # 2
        port:
number: 80

Важные моменты:

1. Этот VirtualService относится к запросам, приходящим через http-gateway;
2. В destination определяется сервис, куда отправляются запросы.

Примечание: Конфигурация выше хранится в файле sa-virtualservice-external.yaml, который также содержит настройки для маршрутизации в SA-WebApp и SA-Feedback, но был сокращён здесь в статье для лаконичности.

Применим VirtualService вызовом:

$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services created

Примечание: Когда мы применяем ресурсы Istio, Kubernetes API Server создаёт событие, которое получает Istio Control Plane, и уже после этого новая конфигурация применяется к прокси-серверам Envoy каждого pod’а. А контроллер Ingress Gateway представляется очередным Envoy, сконфигурированным в Control Plane. Всё это на схеме выглядит так:

Конфигурация Istio-IngressGateway для маршрутизации запросов

Приложение Sentiment Analysis стало доступным по http://{EXTERNAL-IP}/. Не переживайте, если вы получаете статус Not Found: иногда требуется чуть больше времени для того, чтобы конфигурация вступила в силу и кэши Envoy обновились.

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

Kiali : наблюдаемость

Чтобы попасть в административный интерфейс Kiali, выполните следующую команду:

$ kubectl port-forward \
    $(kubectl get pod -n istio-system -l app=kiali \
    -o jsonpath='{.items[0].metadata.name}') \
    -n istio-system 20001

… и откройте http://localhost:20001/, залогинившись под admin/admin. Здесь вы найдете множество полезных возможностей, например, для проверки конфигурации компонентов Istio, визуализации сервисов по информации, собранной при перехвате сетевых запросов, получения ответов на вопросы «Кто к кому обращается?», «У какой версии сервиса возникают сбои?» и т.п. В общем, изучите возможности Kiali перед тем, как двигаться дальше — к визуализации метрик с Grafana.

Grafana: визуализация метрик

Собранные в Istio метрики попадают в Prometheus и визуализируются с Grafana. Чтобы попасть в административный интерфейс Grafana, выполните команду ниже, после чего откройте http://localhost:3000/:

$ kubectl -n istio-system port-forward \
    $(kubectl -n istio-system get pod -l app=grafana \
    -o jsonpath={.items[0].metadata.name}) 3000

Кликнув на меню Home слева сверху и выбрав Istio Service Dashboard в левом верхнем углу, начните с сервиса sa-web-app, чтобы посмотреть на собранные метрики:

Здесь нас ждёт пустое и совершенно скучное представление — руководство никогда такое не одобрит. Давайте же создадим небольшую нагрузку следующей командой:

$ while true; do \
    curl -i http://$EXTERNAL_IP/sentiment \
    -H "Content-type: application/json" \
    -d '{"sentence": "I love yogobella"}'; \
    sleep .8; done

Вот теперь у нас гораздо более симпатичные графики, а в дополнение к ним — замечательные инструменты Prometheus для мониторинга и Grafana для визуализации метрик, что позволят нам узнать о производительности, состоянии здоровья, улучшениях/деградации в работе сервисов на протяжении времени.

Наконец, посмотрим на трассировку запросов в сервисах.

Jaeger : трассировка

Трассировка нам потребуется, потому что чем больше у нас сервисов, тем сложнее добраться до причины сбоя. Посмотрим на простой случай из картинки ниже:

Типовой пример случайного неудачного запроса

Запрос приходит, падает — в чём же причина? Первый сервис? Или второй? Исключения есть в обоих — давайте посмотрим на логи каждого. Как часто вы ловили себя за таким занятием? Наша работа больше похожа на детективов программного обеспечения, а не разработчиков…

Это широко распространённая проблема в микросервисах и решается она распределёнными системами трассировки, в которых сервисы передают друг другу уникальный заголовок, после чего эта информация перенаправляется в систему трассировки, где она сопоставляется с данными запроса. Вот иллюстрация:

Для идентификации запроса используется TraceId

В Istio используется Jaeger Tracer, который реализует независимый от вендоров фреймворк OpenTracing API. Получить доступ к пользовательского интерфейсу Jaeger можно следующей командой:

$ kubectl port-forward -n istio-system \
    $(kubectl get pod -n istio-system -l app=jaeger \
    -o jsonpath='{.items[0].metadata.name}') 16686

Теперь зайдите на http://localhost:16686/ и выберите сервис sa-web-app. Если сервис не показан в выпадающем меню — проявите/сгенерируйте активность на странице и обновите интерфейс. После этого нажмите на кнопку Find Traces, которая покажет самые последние трейсы — выберите любой — покажется детализированная информация по всем трейсам:

Этот трейс показывает:

1. Запрос приходит в istio-ingressgateway (это первое взаимодействие с одним из сервисов, и для запроса генерируется Trace ID), после чего шлюз направляет запрос в сервис sa-web-app.
2. В сервисе sa-web-app запрос подхватывается Envoy sidecar’ом, создаётся «ребёнок» в span’е (поэтому мы видим его в трейсах) и перенаправляется в контейнер sa-web-app. (Span — логическая единица работы в Jaeger, имеющая название, время начало операции и её продолжительность. Span’ы могут быть вложенными и упорядоченными. Ориентированный ациклический граф из span’ов образует trace. — прим. перев.)
3. Здесь запрос обрабатывается методом sentimentAnalysis. Эти трейсы уже сгенерированы приложением, т.е. для них потребовались изменения в коде.
4. С этого момента инициируется POST-запрос в sa-logic. Trace ID должен быть проброшен из sa-web-app.
5. …

Примечание: На 4 шаге приложение должно увидеть заголовки, сгенерированные Istio, и передать их в последующие запросы, как показано на изображении ниже:

(A) За проброс заголовков отвечает Istio; (B) За заголовки отвечают сервисы

Istio делает основную работу, т.к. генерирует заголовки для входящих запросов, создаёт новые span’ы в каждом sidecare’е и пробрасывает их. Однако без работы с заголовками внутри сервисов полный путь трассировки запроса будет утерян.

Необходимо учитывать (пробрасывать) следующие заголовки:

x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-context

Это несложная задача, однако для упрощения её реализации уже существует множество библиотек — например, в сервисе sa-web-app клиент RestTemplate пробрасывает эти заголовки, если просто добавить библиотеки Jaeger и OpenTracing в его зависимости.

Заметьте, что приложение Sentiment Analysis демонстрирует реализации на Flask, Spring и ASP.NET Core.

Теперь, когда стало ясно, что мы получаем из коробки (или почти «из коробки»), рассмотрим вопросы тонко настраиваемой маршрутизации, управления сетевым трафиком, безопасности и т.п.!

Прим. перев.: об этом читайте в следующей части материалов по Istio от Rinor Maloku, переводы которых последуют в нашем блоге в ближайшее время. UPDATE (14 марта): Вторая часть уже опубликована.

P.S. от переводчика

Читайте также в нашем блоге:

Управление микросервисами с помощью Kubernetes и Istio / JUG Ru Group corporate blog / Habr

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

В основе статьи — доклад Крейга Бокса на нашей прошлогодней конференции DevOops 2017. Видео и перевод доклада — под катом.

Крейг Бокс (Craig Box, Твиттер) — DevRel из Google, отвечающий за направление микросервисов и инструменты Kubernetes и Istio. Его нынешний рассказ — про управление микросервисами на этих платформах.

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

На высоком уровне мы рассматриваем сеть как трубу, которая просто перемещает биты. Мы не хотим беспокоиться о них или, например, о MAC-адресах в приложениях, но стремимся думать о сервисах и связях, которые им необходимы. Если посмотреть с точки зрения OSI, то у нас есть сеть третьего уровня (с функциями определения маршрута и логической адресации), но мы-то хотим думать в терминах седьмого (с функцией доступа к сетевым службам).

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

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

Service Mesh — это слой, который позволяет нам решать вышеуказанные проблемы в среде микрообслуживания.

Монолит и микросервисы: плюсы и минусы

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

Ведь здорово: весь код у нас на как ладони. Почему бы и дальше не использовать этот подход?
Да потому что у монолита есть свои проблемы. Главная трудность в том, что если мы захотим пересобрать это приложение, то должны повторно развернуть каждый модуль, даже если ничего не изменилось. Мы вынуждены создавать приложение на одном и том же языке или на совместимых языках, даже если над ним работают разные команды. Фактически отдельные части не могут быть протестированы независимо друг от друга. Пора это менять, пришло время микросервисов.

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

Что получилось в итоге?

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

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

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

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

Что можно предпринять?

Есть несколько вариантов. Мы можем взять наше приложение и сказать, что если RPC не работает с первого раза, то следует попробовать еще раз, а затем еще и еще. Немного подождать и снова попробовать или добавить Jitter. Также мы можем добавить entry — exit traces чтобы сказать, что произошел запуск и завершение вызова, что для меня приравнивается к отладке. Можно добавить инфраструктуру для обеспечения проверки подлинности соединений и научить все наши приложения работать с TLS-шифрованием. Нам придется взять на себя бремя содержания отдельных команд и постоянно держать в голове различные проблемы, которые могут возникнуть в SSL-библиотеках.

Поддержание согласованности на различных платформах — это неблагодарная задача. Хотелось бы, чтобы пространство между приложениями стало разумным, чтобы появилась возможность отслеживания. Также нам нужна возможность изменения конфигурации во время выполнения, чтобы не перекомпилировать или не перезапускать приложения для перенастройки. Вот эти хотелки и реализует Service Mesh.

Istio

Поговорим о Istio.

Istio — это полноценный framework для подключения, управления и мониторинга микросервисной архитектуры. Istio создан для работы поверх Kubernetes. Сам он не развертывает программное обеспечение и не заботится о том, чтобы сделать его доступным на машинах, которые мы используем для этой цели с контейнерами в Kubernetes.

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

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

Чтобы принимать оплату от пользователя, у нас есть отдельный платежный микросервис, вызывающий внешний API, который находится за пределами кластера.

Для обработки входа пользователей в систему у нас предусмотрен микросервис аутентификации, и у него есть состояния, сохраненные опять-таки за пределами нашего кластера в базе данных Cloud SQL.

Что делает Istio? Istio улучшает Kubernetes. Вы устанавливаете его с помощью альфа-функции в Kubernetes под названием Инициализатор. При развертывании программного обеспечения kubernetes заметит его и спросит, хотим ли мы изменить и добавить еще один контейнер внутри каждого kubernetes. Этот контейнер будет обрабатывать пути и маршрутизации, знать обо всех изменениях приложения.

Вот так схема выглядит с Istio.

У нас есть внешние машины, которые обеспечивают входящий и исходящий прокси для трафика в конкретном сервисе. Мы можем разгрузить функции, о которых уже говорили. Нам не нужно учить приложение, как выполнять телеметрию или трассировку с помощью TLS. Зато можем добавить внутрь другие вещи: автоматическое прерывание, ограничение скорости, canary release.

Весь трафик теперь будет проходить через прокси-серверы на внешних машинах, а не напрямую к сервисам. Kubernetes делает все на том же IP-адресе. Мы сможем перехватить трафик, который пошел бы на front или end сервисы.

Внешний прокси, который использует Istio, называется Envoy.

Envoy на самом деле старше Istio, он был разработан в LYFT. Работает в продакшн более года, запуская всю инфраструктуру микросервисов. Мы выбрали Envoy для проекта Istio в сотрудничестве с сообществом. Таким образом, Google, IBM и LYFT — это три компании, которые до сих пор над ним работают.

Envoy написан на C++ версии 11. Был в продакшн более 18 месяцев, прежде чем стать проектом с открытым исходным кодом. Он не займет много ресурсов, когда вы подключите его к вашим сервисам.

Вот несколько вещей, которые умеет Envoy. Это создание прокси-сервера для HTTP, включая HTTP/2 и протоколов, основанных на нем, таких как gRPC. Он также может выполнять переадресацию другим протоколам на двоичном уровне. Envoy контролирует вашу зону инфраструктуры, так что вы можете сделать свою часть автономной. Он может обрабатывать большое количество сетевых соединений с повторами запросов и ожиданием. Вы можете установить определенное количество попыток подключения к серверу, прежде чем прекратить обращение и передать своим серверам информацию о том, что сервис не отвечает.

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

Команда Istio внесла большой вклад в платформу UpStream Envoy Platform. Например, оповещение об ошибке injection. Мы сделали так, чтобы можно было видеть, как приложение ведет себя в случае превышения количества запросов на объект, завершившихся неудачей. А также реализовали функции графического отображения и разделения трафика, чтобы обрабатывать случаи, когда используется canary-развертывание.

На рисунке показано, как выглядит архитектура системы Istio. Мы возьмем лишь два микросервиса, которые упоминали ранее. В конечном счете, на схеме все очень похоже на программно-определяемую сеть. Со стороны прокси-сервера Envoy, который мы развернули вместе с приложениями, происходит перенос трафика с помощью IP-таблиц в пространстве имен. Контрольная панель отвечает за управление консолью, но она не обрабатывает трафик сама.
У нас есть три компонента. Pilot, который создает конфигурацию, смотрит на правила, которые можно изменить с помощью API для контрольной панели Istio, и затем обновляет Envoy так, чтобы он вел себя как сервис обнаружения кластера. Istio-Auth служит центром сертификации и передает TLS сертификаты на прокси-серверы. Приложению не требуется наличие SSL, они могут соединяться по HTTP, и прокси будут обрабатывать все это за вас.

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

Преимущества Istio

Итак, давайте поговорим подробнее о пяти вещах, которые мы получим от Istio. В первую очередь рассмотрим управление трафиком. Мы можем отделить контроль трафика от масштабирования инфраструктуры, поэтому ранее мы могли бы сделать что-то вроде 20 экземпляров приложения и 19 из них будет на старой версии, а один на новой, то есть 5% трафика будет приходиться на новую версию. С Istio мы можем развернуть любое количество экземпляров, которое нам нужно, и при этом указать, какой процент трафика нужно отправить на новые версии. Простое правило разделения.

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

Например, мы можем сказать, что любой траффик с iPhone подчиняется другому правилу, и мы собираемся направить определенную долю трафика на новую версию, которую хотим протестировать для определенного устройства. Внутренний вызывающий микросервис может определить, к какой конкретной версии ему нужно подключиться, а вы можете перевести его на другую версию, например, 2.0.

Второе преимущество — это прозрачность. Когда у вас есть представление внутри кластера, вы можете понять как оно сделано. Нам не нужно в процессе разработки создавать инструментарий для метрик. Метрики уже есть в каждом компоненте.

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

Так выглядит панель инструментов Istio, созданная с помощью сервиса Prometheus. Не забудьте его развернуть внутри кластера.

В примере на скриншоте показан ряд отслеживаемых параметров, характерных для всего кластера. Можно вывести и более интересные вещи, например, какой процент приложений дает более 500 ошибок, что подразумевает отказ. Время ответа агрегируется во всех вызывающих и отвечающих экземплярах сервисов внутри кластера, этот функционал не требует настроек. Istio знает, что поддерживает Prometheus, а тот в курсе, какие службы доступны в вашем кластере, поэтому Istio-Mixer может отправлять метрики в Prometheus без дополнительных настроек.
Давайте посмотрим, как это работает. Если вы вызываете конкретную службу, прокси сервис отправляет информацию об этом вызове в Mixer, который фиксирует такие параметры, как ожидание времени ответа, статус кода и IP. Он нормализует их и отправляет на любые серверы, которые вы сконфигурировали. Специально для вывода основных показателей есть сервис Prometheus и адаптеры FLUX DB, но вы также можете написать собственный адаптер и вывести данные в любом формате для любого другого приложения. И вам не придется ничего менять в инфраструктуре, если захотите добавить новую метрику.

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

На уровне приложений беспокоиться о создании трассировки практически не нужно. Envoy сам передает всю необходимую информацию в Mixer, который отправляет ее в трассировку, например, в Zipkin, stackdriver trace от Google или любое другое пользовательское приложение.

Давайте поговорим об отказоустойчивости и эффективности.

Тайм-ауты между вызовами сервисов нужны для проверки работоспособности, в первую очередь, балансировщиков нагрузки. Введем ошибки в эту связь и посмотрим, что произойдет. Рассмотрим пример. Допустим, существует связь между сервисом A и сервисом B. Мы ждем ответ от сервиса видео 100 миллисекунд и даем всего 3 попытки, если результат не получен. По сути мы собираемся занять его на 300 миллисекунд, прежде чем он сообщит о неудачной попытке соединения.

Далее, например, наш сервис кино должен посмотреть рейтинг фильма через другой микросервис. У рейтинга таймаут составляет 200 миллисекунд и дается две попытки вызова. Вызов службы видео может привести к тому, что вы будете ждать 400 миллисекунд в случае, если рейтинг звездности вне доступа. Но, мы помним, по истечении 300 мс сервис кино сообщит, что он нерабочий, и мы никогда не узнаем реальную причину сбоя. Использование тайм-аутов и  тестирование того, что происходит в этих случаях — отличный способ найти в вашей архитектуре микросервисов всякие хитроумные баги.

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

Мы выполняем TLS-offloading, поэтому используем в Envoy современный хорошо допиленный SSL, с которым можно не волноваться о уязвимостях.

Еще одно преимущество Istio — безопасность.

Какие базовые средства безопасности есть в Istio? Сервис Istio-Auth работает в нескольких направлениях. Используется общедоступный фреймворк и набор стандартов идентификации для сервисов SPIFFE. Если мы говорим о потоке трафика, то у нас есть центр сертификации Istio, который выдает сертификаты для учетных записей служб, которые мы запускаем внутри кластера. Эти сертификаты соответствуют стандарту SPIFFE и распространяются Envoy, используя механизм защиты kubernetes. Envoy использует ключи для двусторонней аутентификации TLS. Таким образом, приложения бэкенда получают идентификаторы, на основе которых уже можно организовать политику.

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

Наконец, применение политик. Mixer является точкой интеграции с инфраструктурными бэкэндами, которые вы можете расширить с помощью Service Mesh. Cервисы могут легко перемещаться внутри кластера, быть развернуты в нескольких средах, в облаке или локально. Все сконструировано для оперативного контроля вызовов, которые идут через Envoy. Мы можем разрешать и запрещать конкретные вызовы, ставить предварительные условия для пропуска вызовов, ограничивать их скорость и количество. Например, вы разрешаете к какой-то своей службе 20 бесплатных запросов в день. Если пользователь сделал 20 запросов, последующие не обрабатываются.

Предварительные условия могут включать в себя такие вещи, как, например, прохождение сервером проверки подлинности, ICL и его присутствие в белом списке. Управление квотами может использоваться в тех случаях, когда требуется, чтобы все, кто использует сервис, имели одинаковую скорость доступа. Наконец, Mixer собирает результаты обработки запросов и ответов, годные для телеметрии. Это позволяет производителям и пользователям смотреть на эту телеметрию с помощью сервисов.

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

Как начать работать с Istio

Istio поддерживает предыдущие версии kubernetes, но новая функция инициализатора, о которой я рассказывал, находится в версиях 1.7 и выше. Это альфа-функция в kubernetes. Я рекомендую использовать Google Container Engine Alpha clusters. У нас есть кластеры, которые вы можете включить на определенное количество дней и при этом использовать все продакшн возможности в них.

Прежде всего Istio — это проект с открытым исходным кодом на github. Мы только что выпустили версию 0.2. В версии 0.1 можно было управлять объектами в пределах одноименного пространства имен kubernetes. С версии 0.2 мы поддерживаем работу в собственном пространстве имен и кластере kubernetes. Еще мы добавили доступ для возможности управления сервисами, которые запускаются на виртуальных машинах. Вы можете развернуть Envoy на виртуальной машине и обезопасить сервисы, которые работают на ней. В дальнейшем Istio будет поддерживать другие платформы, такие как Cloud Foundry.

Краткое руководство по установке фреймворка находится здесь. Если у вас есть кластер под управлением Google Container Engine на 1.8 с включенными альфа-функциями, то установка Istio — это всего лишь одна команда.

Если вам понравился этот доклад, приходите 14 октября на конференцию DevOops 2018 (Питер): там можно будет не только послушать доклады, но и пообщаться с любым докладчиком в дискуссионной зоне.

Istio.com: cервис SEO анализа текстов

Сервис определяет

• Общее количество слов в тексте
• Количество символов без пробелов
• Количество символов с пробелами
• Водность текста
• Тошноту текста
• Орфографические ошибки

Также

• Выдает статистику по каждому отдельному слову
• Формирует список слов по количеству их употребляемости в тексте
• Формирует два списка слов (со стоп-словами и без стоп-слов)

Отзывы пользователей

Залили новую версию сайта. Часть функций пока отключены. Тестируем.

Mendel

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

Yuran123

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

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

А в остальном, спасибо, очень полезный сервис.
P.S. Вот еще, забыла отметить… Наверно, я много хочу, но если бы была возможность выбора количества отображаемых строк в таблице слов — 10, 20…100 — было бы вообще супер.

Justina_CL

Все на сайте ясно и понятно, только плохо, что сам текст сразу после проверки пропадает, но с этим можно смирится. А что дает регистрация? Что-то меняется или есть какие-то дополнительные плюсы после регистрации?

Nezavi

Вернем при следующих доработках сервиса. Подумаем как лучше реализовать. Многим не нужна форма с текстом большого размера перед статистической таблицей. Раньше была статистика только на 20 самых частотных слов, сейчас добавили листалку под списком (можно просмотреть все слова в тексте). Такой вариант вас не устраивает? На данный момент ничего не дает, необходимости регистрироваться нет. Сделали на перспективу.

Geronimo

 

В принципе можно сделать. Подумаем как лучше.

Mendel

Теоретически, форму с текстом можно и после статистики расположить, или рядом, скажем, справа, слегка уменьшив ширину таблицы. Когда ведется отработки частоты слов, особенно когда их слишком много и все нужно «вписать» в заданные %, удобнее это делать непосредственно в форме. Вот и приходится каждый раз после проверки вызывать текст и растягивать формочку, чтобы улучшить визуализацию. Лень человеческая просит заменить опцию «листать» на обычную прокрутку страницы колесиком мыши, поэтому.

Justina_CL

В новом варианте сайта у меня не работает функция «карты текста», а без этого очень неудобно корректировать водность. Я что-то делаю не так, или отключена сама функция?

Ardat

В данный момент отключена, в ближайшие неделю-две вернем.

Geronimo

В очередной раз тестирую сервис. Для копирайтеров очень удобная функция «водность». Все наглядно и менять можно, как говорится, в режиме реального времени. Спасибо. И, вижу, снова появилась графа «тематика».

Justina_CL

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

Aleksa

 

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

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

Например: в тексте есть слова магазин 6 раз, магазина 2 раза, магазины 1 раз, слово магазин имеет значение 6 раз, добавляю в текст фразу цветочный магазин оптовых цен, еще раз прогоняю, все равно 6, добавляю фразу открытие цветочного магазина остается по прежнему в итого 2 раза. Что это может быть? Почему не воспринимает некоторые слова. Другие слова добавляет. Ничего понять не могу. Будьте любезны раскройте мистическую тайну сегодняшнего дня.

Перезагрузила компьютер и все стало нормально. Причина не известна до сих пор. Может какой глюк был?

Ради бога извините, я не спам. Ситуация не улучшилась. По прежнему Истио не считает все количество одинаковых слов. Фактически по тексту у меня уже 9 слов в одном склонении а он пишет 6. Подскажите,что можно в данном случае сделать? Все понятно. Текст загружается не полностью. Нет нескольких блоков. Что делать?

Елена Воробьёва

Проверил слово «Азалия» — выдало ровно столько раз, сколько оно употреблено в тексте. По остальным моментам потестируем.

Geronimo

Да, согласна в тексте столько сколько есть, но раньше считались все слова на страничке, а сейчас нет и нет целого текстового блока.

Истио я использую для оптимизации готовых страничек сайта на тошноту, плотность ключевых слов. Это самый удобный сервис, который я знаю. pr-cy.ru слишком тяжеловат, выдает плотность шиворот навыворот. Многие слова не делит, пишет в одну строку, даже те которые надо делить, правда в последнее время произошли какие то изменения незначительные. А Истио все делает мгновенно, все как надо.

Им очень удобно контролировать оптимизацию тем на форуме. Все очень быстро, просто, удобно. Для текстов есть масса других сервисов, а для оптимизации страничек (без копирования текстов) нет. Вы конечно можете приводить в пример армию подобных, но я с Вами не соглашусь. Любой человек не владеющий знаниями SEO, может быстро разобраться и простым способом вывести свой сайт в топ. Вся фишка быстро убирать тошноту и регулировать плотность слов на страничке, а не текста. Я даже не представляю себе, как бы я смогла каждый раз текст из форума перетаскивать и обрабатывать в отдельности, а как другие слова на страничке?

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

Елена Воробьёва

Я не понимаю о чем вы говорите. Когда раньше? Никаких изменений уже достаточно давно не делали.

Geronimo

Добрый вечер. Начала пользоваться Истио 3 года назад. Очень нравился, все было понятно и доступно. Год назад, наверное, зайдя на сайт для очередной проверки сео-текста, не могла этого сделать. При вставке статьи, которая хорошо была видна в окошке, появлялась надпись «вставьте текст». Складывалось впечатление, что программа его не видит. Пришлось отказаться от услуг сайта.
Тоже самое происходит и сейчас. Я вставляю текст, прекрасно его вижу, в том числе заголовки, выделенные розовым цветом. Но при нажатии кнопки «анализ» опять появляется надпись «необходимо заполнить поле текст». Что я делаю не так? У других пользователей, как я понимаю, таких проблем нет. Спасибо.

Лана

Лана, здравствуйте. Проверил, нормально работает. Часто у вас такое происходит? Напишите мне пожалуйста в личном сообщении.

Geronimo

Зарегистрировалась на этом сервисе, начала проверять собственные тексты. Очень удобно, сразу понятно, что надо переделывать. Пока еще проверила несколько текстов, думаю пользоваться Istio.com и дальше. Проблем никаких не возникло, о которых пишут в постах выше.

Helen

Лучший онлайн сервис для Cео анализа текста Istio com

В работе копирайтера не обойтись без различных программ, особенно если вы начинающий автор. Проверка на ошибки, частотность вхождений, тавтологические повторы и водность текста – практически под каждую проверку есть отдельные программы. Но есть один сервис для Сео анализа текстов istio com. Это площадка, позволяет проводить комплексный аудит текстов. Посмотрим, на что он способен?

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

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

• Анализ текста.
• Орфография.

Кто-то скажет, что такого добра в инете навалом, но на самом деле, возможности этой программы не так уж и ограниченны. Разберем подробнее, что может эта площадка в плане сео анализа? Для начала кликнем по вкладке – «Анализ текста».

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

• Орфография;
• Выделение ключей;
• Карта;
• Водность;
• Очистить;
• Только текст.

Начнем по порядку, вкладка – орфография

Чтобы узнать, что может эта кнопка, нужно вставить в окно текст. Я возьму любую, из хранившихся у меня статей. Для наглядности, я выбрал работу, про пароизоляцию дома. Само слово «пароизоляция» незнакомо многим сервисам проверки, и даже «Ворд» выделяет его как ошибку. Посмотрим, как проявит себя сео сервис istio com.

Вставив статью в окно, мне даже не пришлось нажимать кнопку – проверить. Программа сразу выделила слово «пароизоляция» как ошибку. Но это не вся проверка. Нажав на кнопку «проверить» программа проанализирует статью полностью и выдаст такой результат.

Как видите, определились еще слова с ошибками. И если слова – «степлером» и «химэлементами» являются незнакомыми для всех сервисов, то в самом низу у меня орфографическая ошибка в слове «перекроются». В моем случае, по смыслу предложения необходимо написать – будет перекрыта. Сейчас я исправлю и проверю еще раз.

Как видите ситуация исправилась.

Сео анализ текста – что может эта программа?

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

Довольно таки подробная таблица. Из основных проверок, сервис выдает такие показатели:

• Длина с пробелами;
• Длина без пробелов;
• Всего слов;
• Водность;
• Тошнота;
• Топ10 слов;
• Словарь;
• Словарь ядра.

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

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

Теперь посмотрим на дополнительные возможности. Над таблицей есть вкладка «со стоп-словами». По умолчанию вы находитесь на вкладке «без стоп-слов». Нажимаем на нее и переходим на другой экран.

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

В принципе, такой же подсчет есть и в Адвего. Давайте сравним таблицы.

Как видим, все сходится, и алгоритм подсчета не подводит ни у одной программы. Есть еще две вкладки «слова», на ней выдается полный список всех слов в тексте, и «анализ позиций». Перейдя по ней, вас перебросит на другой сервис. Копирайтерам это не нужно, администрация сервиса для сео анализа текстов Istio com, таким образом, поддерживает сторонний ресурс, а может это тоже площадка одного хозяина.

Анализ ключевых слов

Теперь, вернемся на страницу с текстом и спустимся вниз. Под окном, где располагается статья, есть вкладка – «выделение ключей» щелкнем по ней. Произойдет перезагрузка страницы, но ничего не изменится, то есть правки будут, в том, что исчезнут подчеркивания ошибок. Чтобы найти ключи, нужно вверху, над окном с текстом ввести то слово, которое вам необходимо найти. Я выделю самое популярное в этой статье слово – материал.

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

Как видите, поиск прошел правильно – 20 вхождений. Теперь прокрутим колесико мыши вниз, и посмотрим, как расположилось слово «материал» в тексте?

Ка видите, все четко и понятно. Все слова подсвечены. Но зачем нам это? А все просто. Таким образом, можно проверять, не расположились ли слова в соседних предложениях. То есть, нас интересует проверка на тавтологию. Конечно, это можно сделать и в «Ворд», но если уж вы будете пользоваться и проверять, например, ошибки в этой программе для сео анализа, то заодно можно и посмотреть есть ли такие недочеты.

Проанализируем водность текста

Что такое вода, можно узнать из статьи по этой ссылке. Ну а мы проверим как программа для сео анализа, выявила 39% водности. Нажимаем на вкладку внизу статьи – «водность текста» и видим что получилось?

Текст запестрел синими выделениями. Вот эти вот предлоги и ненужные слова, которые не учитывает при поиске робот, и определяют количество воды в тексте. Очень удобная вкладка. Если заказчик попросит снизить процент, можно «просветить» файл и, держа его перед глазами, переработать статью, убирая ненужные обороты.

Вот и все возможности сервиса для сео анализа текстов Istio com. Я надеюсь, что вам пригодится эта информация, и программа поможет в продвижении дел в копирайтинге.

Буду рад и признателен, если вы нажмете на кнопочки соцсетей!

Видео по теме

Вам будет интересно

Ликбез по запуску Istio / Блог компании Southbridge / Хабр

Istio Service Mesh

Мы в Namely уже год как юзаем Istio. Он тогда только-только вышел. У нас здорово упала производительность в кластере Kubernetes, мы хотели распределенную трассировку и взяли Istio, чтобы запустить Jaeger и разобраться. Service mesh так здорово вписалась в нашу инфраструктуру, что мы решили вложиться в этот инструмент.

Пришлось помучиться, но мы изучили его вдоль и поперек. Это первый пост из серии, где я расскажу, как Istio интегрируется с Kubernetes и что мы узнали о его работе. Иногда будем забредать в технические дебри, но не сильно далеко. Дальше будут еще посты.

Что такое Istio?

Istio — это инструмент конфигурации service mesh. Он читает состояние кластера Kubernetes и делает обновление до прокси L7 (HTTP и gRPC), которые реализуются как sidecar-ы в подах Kubernetes. Эти sidecar-ы — контейнеры Envoy, которые читают конфигурацию из Istio Pilot API (и сервиса gRPC) и маршрутизируют по ней трафик. С мощным прокси L7 под капотом мы можем использовать метрики, трассировки, логику повтора, размыкатель цепи, балансировку нагрузки и канареечные деплои.

Начнем с начала: Kubernetes

В Kubernetes мы создаем под c помощью деплоя или StatefulSet. Или это может быть просто «ванильный» под без контроллера высокого уровня. Затем Kubernetes изо всех сил поддерживает желаемое состояние — создает поды в кластере на ноде, следит, чтобы они запускались и перезапускались. Когда под создается, Kubernetes проходит по жизненному циклу API, убеждается, что каждый шаг будет успешным, и только потом наконец создает под на кластере.

Этапы жизненного цикла API:

Спасибо Banzai Cloud за крутую картинку.

Один из этапов — модифицирующие вебхуки допуска. Это отдельная часть жизненного цикла в Kubernetes, где ресурсы кастомизируются до коммита в хранилище etcd — источнике истины для конфигурации Kubernetes. И здесь Istio творит свою магию.

Модифицирующие вебхуки допуска

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

Во время установки Istio добавляется istio-sidecar-injector как ресурс конфигурации модифицирующих вебхуков:

$ kubectl get mutatingwebhookconfiguration
NAME                     AGE
istio-sidecar-injector   87d

И конфигурация:

apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app: istio-sidecar-injector
    chart: sidecarInjectorWebhook-1.0.4
    heritage: Tiller
  name: istio-sidecar-injector
webhooks:
- clientConfig:
    caBundle: redacted
    service:
      name: istio-sidecar-injector
      namespace: istio-system
      path: /inject
  failurePolicy: Fail
  name: sidecar-injector.istio.io
  namespaceSelector:
    matchLabels:
      istio-injection: enabled
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods

Тут написано, что Kubernetes должен отправлять все события создания подов в сервис istio-sidecar-injector в неймспейс istio-system, если в неймспейсе есть ярлык istio-injection=enabled. Инжектор включает в PodSpec еще два контейнера: один временный для настройки правил прокси и один — собственно для проксирования. Sidecar-инжектор вставляет эти контейнеры по шаблону из карты конфигурации istio-sidecar-injector. Этот процесс еще называется sidecaring.

Sidecar-поды

Sidecar-ы — это трюки нашего фокусника Istio. Istio так ловко все проворачивает, что со стороны это прямо магия, если не знать деталей. А знать их полезно, если вдруг надо отладить сетевые запросы.

Init- и прокси-контейнеры

В Kubernetes есть временные одноразовые init-контейнеры, которые можно запускать до основных. Они объединяют ресурсы, переносят базы данных или, как в случае с Istio, настраивают правила сети.

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

@jimmysongio нарисовал отличную схему связи между правилами iptables и прокси Envoy:

Трафик Envoy–Envoy

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

Процесс Envoy обнаруживает все маршруты через Envoy v2 API, который реализует Istio.

Envoy и Pilot

У самого Envoy нет никакой логики, чтобы обнаруживать поды и сервисы в кластере. Это плоскость данных и ей нужна плоскость контроля, чтобы руководить. Параметр конфигурации Envoy запрашивает хост или порт сервиса, чтобы получить эту конфигурацию через gRPC API. Istio, через свой сервис Pilot, выполняет требования для gRPC API. Envoy подключается к этому API на основе sidecar-конфигурации, внедренной через модифицирующий вебхук. В API есть все правила трафика, которые нужны Envoy для обнаружения и маршрутизации для кластера. Это и есть service mesh.

Обмен данными «под <-> Pilot»

Pilot подключается к кластеру Kubernetes, читает состояние кластера и ждет обновлений. Он следит за подами, сервисами и конечными точками в кластере Kubernetes, чтобы потом дать нужную конфигурацию всем sidecar-ам Envoy, подключенным к Pilot. Это мост между Kubernetes и Envoy.

Из Pilot в Kubernetes

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

Какая конфигурация отправляется?

Какую конфигурацию получает Envoy от Istio Pilot?

По умолчанию Kubernetes решает ваши сетевые вопросы с помощью sevice (сервис), который управляет endpoint (конечные точки). Список конечных точек можно открыть командой:

kubectl get endpoints

Это список всех IP и портов в кластере и их адресатов (обычно это поды, созданные из деплоя). Istio важно это знать, чтобы настраивать и отправлять данные о маршрутах в Envoy.

Сервисы, прослушиватели и маршруты

Когда вы создаете сервис в кластере Kubernetes, вы включаете ярлыки, по которым будут выбраны все подходящие поды. Когда вы отправляете трафик на IP сервиса, Kubernetes выбирает под для этого трафика. Например, команда

curl my-service.default.svc.cluster.local:3000

сначала найдет виртуальный IP, назначенный сервису my-service в неймспейсе default, и этот IP перешлет трафик в под, который соответствует ярлыку сервиса.

Istio и Envoy слегка меняют эту логику. Istio настраивает Envoy на основе сервисов и конечных точек в кластере Kubernetes и использует умные функции маршрутизации и балансировки нагрузки Envoy, чтобы обойти сервис Kubernetes. Вместо проксирования по одному IP Envoy подключается прямо к IP пода. Для этого Istio сопоставляет конфигурацию Kubernetes с конфигурацией Envoy.

Термины Kubernetes, Istio и Envoy немного отличаются, и не сразу понятно, что с чем едят.

Сервисы

Сервис в Kubernetes сопоставляется с кластером в Envoy. Кластер Envoy содержит список конечных точек, то есть IP (или имена хостов) экземпляров для обработки запросов. Чтобы увидеть список кластеров, настроенных в sidecar-поде Istio, запустите istioctl proxy-config cluster <имя пода>. Эта команда показывает текущее положение дел с точки зрения пода. Вот пример из одной нашей среды:

$ istioctl proxy-config cluster taxparams-6777cf899c-wwhr7 -n applications
SERVICE FQDN                                                              PORT      SUBSET     DIRECTION     TYPE
BlackHoleCluster                                                          -         -          -             STATIC
accounts-grpc-gw.applications.svc.cluster.local                           80        -          outbound      EDS
accounts-grpc-public.applications.svc.cluster.local                       50051     -          outbound      EDS
addressvalidator.applications.svc.cluster.local                           50051     -          outbound      EDS

Все те же сервисы есть в этом пространстве имен:

$ kubectl get services
NAME                                     TYPE           CLUSTER-IP   EXTERNAL-IP        PORT(S)                         
accounts-grpc-gw                         ClusterIP      10.3.0.91    <none>             80/TCP                          
accounts-grpc-public                     ClusterIP      10.3.0.202   <none>             50051/TCP                       
addressvalidator                         ClusterIP      10.3.0.56    <none>             50051/TCP

Как Istio узнает, какой протокол использует сервис? Настраивает протоколы для манифестов сервисов по полю name в записи порта.

$ kubectl get service accounts-grpc-public -o yaml
apiVersion: v1
kind: Service
metadata:
  name: accounts-grpc-public
spec:
  ports:
  - name: grpc
    port: 50051
    protocol: TCP
    targetPort: 50051

Если там grpc или префикс grpc-, Istio настроит для сервиса протокол HTTP2. Мы на горьком опыте узнали, как Istio использует имя порта, когда запороли конфиги прокси, потому что не указали префиксы http или grpc…

Если использовать kubectl и админскую страницу переадресации портов в Envoy, видно, что конечные точки account-grpc-public реализуются Pilot как кластер в Envoy с протоколом HTTP2. Это подтверждает наши предположения:

$ kubectl -n applications port-forward otherpod-dc56885ff-dqc6t 15000:15000 &
$ curl http://localhost:15000/config_dump | yq r -
...
    - cluster:
        circuit_breakers:
          thresholds:
          - {}
        connect_timeout: 1s
        eds_cluster_config:
          eds_config:
            ads: {}
          service_name: outbound|50051||accounts-grpc-public.applications.svc.cluster.local
        http2_protocol_options:
          max_concurrent_streams: 1073741824
        name: outbound|50051||accounts-grpc-public.applications.svc.cluster.local
        type: EDS
...

Порт 15000 — это админская страница Envoy, доступная в каждом sidecar.

Прослушиватели

Прослушиватели узнают конечные точки Kubernetes, чтобы пропускать трафик в поды. У сервиса проверки адреса здесь одна конечная точка:

$ kubectl get ep addressvalidator -o yaml
apiVersion: v1
kind: Endpoints
metadata:
  name: addressvalidator
subsets:
- addresses:
  - ip: 10.2.26.243
    nodeName: ip-10-205-35-230.ec2.internal
    targetRef:
      kind: Pod
      name: addressvalidator-64885ccb76-87l4d
      namespace: applications
  ports:
  - name: grpc
    port: 50051
    protocol: TCP

Поэтому у пода проверки адреса один прослушиватель на порте 50051:

$ kubectl -n applications port-forward addressvalidator-64885ccb76-87l4d 15000:15000 &
$ curl http://localhost:15000/config_dump | yq r -
...
    dynamic_active_listeners:
    - version_info: 2019-01-13T18:39:43Z/651
      listener:
        name: 10.2.26.243_50051
        address:
          socket_address:
            address: 10.2.26.243
            port_value: 50051
        filter_chains:
        - filter_chain_match:
            transport_protocol: raw_buffer
...

Маршруты

В Istio вместо стандартного объекта Kubernetes Ingress берется более абстрактный и эффективный кастомный ресурс — VirtualService. VirtualService сопоставляет маршруты с апстрим-кластерами, привязывая их к шлюзу. Это как использовать Kubernetes Ingress с Ingress-контроллером.

В Namely мы используем Istio Ingress-Gateway для всего внутреннего GRPC-трафика:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: grpc-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - '*'
    port:
      name: http2
      number: 80
      protocol: HTTP2
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: grpc-gateway
spec:
  gateways:
  - grpc-gateway
  hosts:
  - '*'
  http:
  - match:
    - uri:
        prefix: /namely.address_validator.AddressValidator
    retries:
      attempts: 3
      perTryTimeout: 2s
    route:
    - destination:
        host: addressvalidator
        port:
          number: 50051

На первый взгляд в примере ничего не разберешь. Тут не видно, но деплой Istio-IngressGateway записывает, какие конечные точки нужны, на основе селектора istio: ingressgateway. В этом примере IngressGateway направляет трафик для всех доменов через порт 80 по протоколу HTTP2. VirtualService реализует маршруты для этого шлюза, сопоставляет по префиксу /namely.address_validator.AddressValidator и передает в апстрим-сервис addressvalidator через порт 50051 с правилом повтора через две секунды.

Если переадресовать порт пода Istio-IngressGateway и посмотреть конфигурацию Envoy, мы увидим, что делает VirtualService:

$ kubectl -n istio-system port-forward istio-ingressgateway-7477597868-rldb5 15000
...
          - match:
              prefix: /namely.address_validator.AddressValidator
            route:
              cluster: outbound|50051||addressvalidator.applications.svc.cluster.local
              timeout: 0s
              retry_policy:
                retry_on: 5xx,connect-failure,refused-stream
                num_retries: 3
                per_try_timeout: 2s
              max_grpc_timeout: 0s
            decorator:
              operation: addressvalidator.applications.svc.cluster.local:50051/namely.address_validator.AddressValidator*
...

Что мы гуглили, копаясь в Istio

Возникает ошибка 503 или 404

Причины разные, но обычно такие:

• Sidecar-ы приложения не могут связаться с Pilot (проверьте, что Pilot запущен).
• В манифесте сервиса Kubernetes указан неправильный протокол.
• Конфигурация VirtualService/Envoy записывает маршрут не в том апстрим-кластере. Начните с edge-сервиса, где ожидаете входящий трафик, и изучите логи Envoy. Или используйте что-то типа Jaeger, чтобы найти ошибки.

Что означает NR/UH/UF в логах прокси Istio?

• NR — No Route (нет маршрута).
• UH — Upstream Unhealthy (неработоспособный апстрим).
• UF — Upstream Failure (сбой апстрима).

Подробности читайте на сайте Envoy.

По поводу высокой доступности с Istio

• Добавьте NodeAffinity в компоненты Istio для равномерного распределения подов по разным зонам доступности и увеличьте минимальное количество реплик.
• Запустите новую версию Kubernetes с функцией горизонтального автомасштабирования подов (Horizontal Pod Autoscaling). Самые важные поды будут масштабироваться в зависимости от нагрузки.

Почему Cronjob не завершается?

Когда основная рабочая нагрузка выполнена, sidecar-контейнер продолжает работать. Чтобы обойти проблему, отключите sidecar в cronjobs, добавив аннотацию sidecar.istio.io/inject: “false” в PodSpec.

Как установить Istio?

Мы используем Spinnaker для деплоев, но обычно берем последние Helm-чарты, колдуем над ними, используем helm template -f values.yml и коммитим файлы в Github, чтобы посмотреть изменения, прежде чем применить их через kubectl apply -f -. Это для того, чтобы нечаянно не изменить CRD или API в разных версиях.

Спасибо Bobby Tables и Michael Hamrah за помощь в написании поста.