Установка и использование Linkerd с помощью Kubernetes

Автор выбрал Tech Education Fund для получения пожертвования в рамках программы Write for DOnations.

Введение

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

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

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

В качестве альтернативы вы можете изучить предлагаемую DigitalOcean возможность быстрой установки Linkerd/Kubernetes.

Предварительные требования

• Кластер Kubernetes 1.12+. В этом обучающем модуле будет использоваться кластер DigitalOcean Kubernetes с тремя узлами, но вы можете создать кластер с помощью другого метода.

• Инструмент командной строки kubectl, установленный на сервере разработки и настроенный для подключения к вашему кластеру. Дополнительную информацию об установке kubectl можно найти в официальной документации.

Шаг 1 — Развертывание приложения

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

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

Вначале сохраните файл манифеста на локальном компьютере:

curl https://run.linkerd.io/emojivoto.yml --output manifest.yaml

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

Чтобы лучше понять, что делает этот файл, посмотрите его содержимое с помощью команды cat или откройте его в предпочитаемом редакторе:

cat manifest.yaml | less

Используйте клавишу пробел для прокрутки страниц с директивами. Вы увидите, что manifest.yaml создает пространство имен Kubernetes с именем emojivoto, где будет запускаться все связанное с этим приложением, а также пару развертываний и служб Kubernetes.

Затем примените этот манифест в своем кластере Kubernetes:

kubectl apply -f manifest.yaml

Мы снова используем команду kubectl apply с флагом -f, чтобы назначить файл, который мы хотим применить.

Эта команда выводит список всех созданных ресурсов.

Output
namespace/emojivoto created
serviceaccount/emoji created
serviceaccount/voting created
serviceaccount/web created
service/emoji-svc created
service/voting-svc created
service/web-svc created
deployment.apps/emoji created
deployment.apps/vote-bot created
deployment.apps/voting created
deployment.apps/web created

Теперь проверьте работу служб.

kubectl -n emojivoto get pods

Мы используем команду kubectl для вывода всех подов, работающих в вашем кластере, и добавляем флаг -n, чтобы указать желаемые пространства имен. Мы укажем пространство имен emojivoto, поскольку все перечисленные службы будут работать в нем.

Когда вы увидите, что все поды находятся в состоянии Running (Работает), можете продолжать:

Output
NAME                        READY   STATUS    RESTARTS   AGE
emoji-566954596f-cw75b      1/1     Running   0          24s
vote-bot-85c5f5699f-7dw5c   1/1     Running   0          24s
voting-756995b6fc-czf8z     1/1     Running   0          24s
web-7f7b69d467-2546n        1/1     Running   0          23s

Чтобы увидеть запущенное приложение в браузере, используйте встроенную функцию kubectl для переадресации локальных запросов на удаленный кластер:

kubectl -n emojivoto port-forward svc/web-svc 8080:80

Здесь мы снова используем kubectl в пространствах имен emojivoto, но теперь используем подкоманду port-forward для переадресации всех локальных запросов на порту 8080 службе Kubernetes web-svc на порту 80. Это удобный способ доступа к приложению без подходящего балансировщика нагрузки.

Откройте адрес http://localhost:8080, и вы увидите приложение emojivoto.

Нажмите CTRL + C в своем терминале. Мы запустили приложение в кластере и теперь можем установить Linkerd и посмотреть на его работу.

Шаг 2 — Установка Linkerd

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

Вначале установим интерфейс командной строки с помощью скрипта, предоставленного командой Linkerd:

curl https://run.linkerd.io/install | sh

Здесь мы используем curl для загрузки установочного скрипта и перенаправляем вывод в sh, где скрипт автоматически выполняется. Также можно загрузить интерфейс командной строки напрямую со страницы релизов Linkerd.

Если вы используете скрипт, он установит Linkerd в каталог ~/.linkerd2/bin. Проверьте работу интерфейса командной строки:

~/.linkerd2/bin/linkerd version

Команда выведет примерно следующее:

Output
Client version: stable-2.7.1
Server version: unavailable

Чтобы упростить запуск интерфейса командной строки, добавьте этот каталог в переменную $PATH:

export PATH=$PATH:$HOME/.linkerd2/bin

Теперь вы можете напрямую запускать такие команды, как показанная выше:

linkerd version

В заключение установим Linkerd в кластер Kubernetes. Команда linkerd install используется для генерирования всех необходимых манифестов yaml для запуска Linkerd, но эти манифесты не будут использоваться для вашего кластера. Запустите эту команду для проверки ее вывода:

linkerd install

Вы увидите длинный список всех манифестов yaml для ресурсов, которые Linkerd требуется запустить. Чтобы применить эти манифесты на своем кластере, выполните следующую команду:

linkerd install | kubectl apply -f -

При запуске команды linkerd install будут выведены все манифесты, которые вы видели ранее. Затем | передает вывод в команду kubectl apply, которая применяет их напрямую.

После запуска этой команды kubectl apply выведет список всех созданных ресурсов.

Чтобы убедиться, что в кластере запущено все необходимое, выполните команду linkerd check:

linkerd check

На кластере будет проведено несколько проверок для подтверждения запуска всех необходимых компонентов:

Output
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API

[...]

control-plane-version
---------------------
√ control plane is up-to-date
√ control plane and cli versions match

Status check results are √

В заключение запустите эту команду, чтобы открыть встроенную панель управления Linkerd в браузере (помните, что нужно использовать флаг --address 0.0.0.0, если вы запускаете команду не с локального компьютера):

linkerd dashboard

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

linkerd stat deployments -n linkerd

В этой команде вы указываете, что хотите посмотреть статистику развертываний в пространстве имен linkerd. Это собственные компоненты Linkerd и, что интересно, вы можете отслеживать их с помощью Linkerd. Вы можете посмотреть такие параметры как количество запросов в секунду (RPS), процент успешных запросов, время задержки и т. д. В столбце Meshed показано, сколько подов было вставлено Linkerd:

Output
NAME                     MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
linkerd-controller          1/1   100.00%   0.4rps           1ms          87ms          98ms          5
linkerd-destination         1/1   100.00%   0.3rps           1ms           2ms           2ms         13
linkerd-grafana             1/1   100.00%   0.3rps           2ms           3ms           3ms          2
linkerd-identity            1/1   100.00%   0.3rps           1ms           2ms           2ms         10
linkerd-prometheus          1/1   100.00%   0.7rps          35ms         155ms         191ms          9
linkerd-proxy-injector      1/1   100.00%   0.3rps           2ms           3ms           3ms          2
linkerd-sp-validator        1/1   100.00%   0.3rps           1ms           5ms           5ms          2
linkerd-tap                 1/1   100.00%   0.3rps           1ms           4ms           4ms          6
linkerd-web                 1/1   100.00%   0.3rps           1ms           2ms           2ms          2

Теперь попробуйте запустить эту команду в своем пространстве имен emojivoto:

linkerd stat deployments -n emojivoto

Хотя вы увидите четыре службы, никакие ранее показанные статистические данные не будут доступны для этих развертываний, а в столбце Meshed будет значение 0/1:

Output
NAME       MESHED   SUCCESS   RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
emoji         0/1         -     -             -             -             -          -
vote-bot      0/1         -     -             -             -             -          -
voting        0/1         -     -             -             -             -          -
web           0/1         -     -             -             -             -          -

Такой вывод означает, что вы еще не вставили Linkerd в приложение. Мы сделаем это на следующем шаге.

Шаг 3 — Вставка Linkerd в приложение

Мы запустили Linkerd в нашем кластере и теперь можем вставить его в наше приложение emojivoto.

Linkerd работает через контейнер sidecar в подах Kubernetes. Это означает, что мы вставим контейнер linkerd proxy в каждый выполняемый под. Каждый запрос, отправляемый или принимаемый подами будет проходить через этот компактный прокси-контейнер, который собирает данные о параметрах (процент успешных запросов, количество запросов в секунду, время задержки и т. д.) и принудительно внедряет политики (таймауты, повторы и т. д.).

Вы можете вставить прокси-контейнер Linkerd вручную с помощью следующей команды:

kubectl get deployments -n emojivoto -o yaml | linkerd inject - | kubectl apply -f -

В этой команде мы сначала используем kubectl get для получения всех развертываний Kubernetes в пространстве имен emojivoto, а затем указываем, что хотим получить вывод в формате yaml. Затем мы отправляем вывод в команду linkerd inject. Эта команда считывает файл yaml с запущенными манифестами и добавляет в него прокси-контейнер linkerd для каждого развертывания.

В заключение мы получаем измененный манифест и применяем его к нашему кластеру с помощью команды kubectl apply.

После выполнения этой команды вы увидите сообщение об успешной вставке всех четырех служб emojivoto (emoji, vote-bot, voting и web).

Если теперь вы попробуете получить статистику emojivoto, вы увидите, что все развертывания указаны в столбце Meshed, и через несколько секунд вы увидите те же параметры, которые отображались для пространства имен linkerd:

linkerd stat deployments -n emojivoto

Здесь вы видите статистические параметры всех четырех служб, составляющих приложение emojivoto с указанием процента успешных запросов, количества запросов в секунду и времени задержки, и при этом вам не потребовалось писать или изменять код приложения.

Output
NAME       MESHED   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99   TCP_CONN
emoji         1/1   100.00%   1.9rps           1ms           2ms           2ms          2
vote-bot      1/1         -        -             -             -             -          -
voting        1/1    85.96%   0.9rps           1ms           1ms           1ms          2
web           1/1    93.04%   1.9rps           8ms          27ms          29ms          2

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

Теперь посмотрим, как можно передать Linkerd дополнительную информацию о службах для настройки их поведения.

Шаг 4 — Определение профиля службы

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

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

Вот пример манифеста профиля службы:

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: my-service.my-namespace.svc.cluster.local
spec:
  routes:
  - name: My Route Name
    isRetryable: true # Define it's safe to retry this route
    timeout: 100ms # Define a timeout for this route
    condition:
      method: GET
      pathRegex: /my/route/path

Профиль службы описывает список маршрутов и определяет поведение при запросах, соответствующих заданному условию. В этом примере мы указываем, что каждый запрос GET, отправляемый на путь /my/route/path, будет истекать по таймауту через 100 мс, и что в этом случае возможен повторный запрос.

Создадим профиль для одной из ваших служб. Возьмем в качестве примера службу voting-svc и для начала используем интерфейс командной строки Linkerd для проверки маршрутов, определенных для этой службы:

linkerd routes svc/voting-svc -n emojivoto

Здесь мы используем команду linkerd routes для перечисления всех маршрутов службы voting-svc в пространстве имен emojiovoto:

Output
ROUTE          SERVICE   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
[DEFAULT]   voting-svc    83.05%   1.0rps           1ms           1ms           2ms

Вы увидите только один маршрут, [DEFAULT]. Здесь группируются все запросы до определения профиля службы.

Теперь откройте nano или другой предпочитаемый редактор для создания файла service-profile.yaml:

nano service-profile.yaml

Добавьте в файл следующее определение профиля службы:

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: voting-svc.emojivoto.svc.cluster.local
  namespace: emojivoto
spec:
  routes:
  - name: VoteDoughnut
    isRetryable: true
    timeout: 100ms
    condition:
      method: POST
      pathRegex: /emojivoto.v1.VotingService/VoteDoughnut

Сохраните файл и закройте редактор.

Здесь мы декларируем профиль службы voting-svc в пространстве имен emojivoto. Мы определили маршрут VoteDoughnut, который будет соответствовать любому запросу POST к /emojivoto.v1. Путь VotingService/VoteDoughnut. Если выполнение запроса, соответствующего этим критериям, займет более 100 мс, Linkerd отменит его, и клиент получит сообщение об ошибке 504. Также мы указываем Linkerd, что в случае неудачи можно отправить повторный запрос.

Примените этот файл к своему кластеру:

kubectl apply -f service-profile.yaml

Через несколько секунд снова проверьте маршруты этой службы:

linkerd routes svc/voting-svc -n emojivoto

Вы увидите маршрут VoteDoughnut, который мы только что задали:

Output
ROUTE             SERVICE   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
VoteDoughnut   voting-svc     0.00%   0.2rps           1ms           1ms           1ms
[DEFAULT]      voting-svc   100.00%   0.8rps           1ms           4ms           4ms

Также вы увидите некоторые статистические показатели, такие как процент успешных запросов, количество запросов в секунду и время задержки для этого конкретного маршрута. Обратите внимание, что конечная точка VoteDoughnut целенаправленно настроена для вывода ошибки, и что она выводит процент успешных запросов 0%, в то время как для маршрута [DEFAULT] выводится значение 100%.

Итак, мы передали Linkerd немного информации о нашей службе, получили статистические данные по маршруту и внедрили политики таймаута и повтора.

Заключение

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

Если вы хотите узнать больше о Linkerd, воспользуйтесь полезной страницей документации, где можно найти инструкции по защите служб, настройке распределенной трассировки, автоматическому выпуску canary и т. д.

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