Как да стартирате Istio с помощта на Kubernetes в производството. Част 1

Какво е Истио? Това е така наречената Service mesh, технология, която добавя слой на абстракция в мрежата. Ние прихващаме целия или част от трафика в клъстера и извършваме определен набор от операции с него. Кое? Например, ние правим интелигентно маршрутизиране или прилагаме подхода на прекъсвача, можем да организираме „канарско внедряване“, частично превключвайки трафика към нова версия на услугата, или можем да ограничим външните взаимодействия и да контролираме всички пътувания от клъстера до външна мрежа. Възможно е да зададете правила за правила за контрол на пътуванията между различни микроуслуги. И накрая, можем да получим цялата карта на мрежовото взаимодействие и да направим обединената колекция от показатели напълно прозрачна за приложенията.

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

Принцип на действие

Istio се състои от две основни области - контролна равнина и равнина на данни. Контролната равнина съдържа основните компоненти, които осигуряват правилната работа на останалите. В текущата версия (1.0) контролната равнина има три основни компонента: пилот, миксер, цитадела. Няма да разглеждаме Citadel, той е необходим за генериране на сертификати, за да се осигури взаимен TLS между услугите. Нека разгледаме по-отблизо устройството и предназначението на Pilot и Mixer.

Pilot е основният контролен компонент, който разпространява цялата информация за това, което имаме в клъстера - услуги, техните крайни точки и правила за маршрутизиране (например правила за внедряване на Canary или правила за прекъсвачи).

Mixer е незадължителен компонент на контролна равнина, който предоставя възможност за събиране на показатели, регистрационни файлове и всякаква информация за мрежовото взаимодействие. Той също така следи спазването на правилата на Политиката и спазването на лимитите на тарифите.

Равнината на данни е реализирана с помощта на странични прокси контейнери. По подразбиране се използва Мощен. пратеник пълномощник. Тя може да бъде заменена от друга реализация, като nginx (nginmesh).

За да работи Istio напълно прозрачно за приложенията, има автоматична система за инжектиране. Най-новата реализация е подходяща за версии на Kubernetes 1.9+ (уеб кукичка за мутационен достъп). За Kubernetes версии 1.7, 1.8 е възможно да използвате Initializer.

Контейнерите Sidecar са свързани към Pilot с помощта на GRPC протокола, който ви позволява да оптимизирате push модела за промени, настъпващи в клъстера. GRPC се използва в Envoy от версия 1.6, в Istio се използва от версия 0.8 и е пилотен агент - golang обвивка над envoy, която конфигурира опциите за стартиране.

Pilot и Mixer са напълно компоненти без състояние, цялото състояние се съхранява в паметта. Конфигурацията за тях е зададена под формата на персонализирани ресурси на Kubernetes, които се съхраняват в etcd.
Istio-agent получава адреса на пилота и отваря GRPC поток към него.

Както казах, Istio реализира цялата функционалност, напълно прозрачна за приложенията. Да видим как. Алгоритъмът е следният:

1. Внедряване на нова версия на услугата.
2. В зависимост от подхода за инжектиране на контейнер с кош, контейнерът istio-init и контейнерът istio-agent (пратеник) се добавят на етапа на прилагане на конфигурацията или вече могат да бъдат вмъкнати ръчно в описанието на обекта Kubernetes Pod.
3. Контейнерът istio-init е скрипт, който прилага правилата на iptables към pod. Има две опции за конфигуриране на трафика да бъде обвит в контейнер на istio-agent: използване на правила за пренасочване на iptables или TPROXY. Към момента на писане подходът по подразбиране е с правила за пренасочване. В istio-init е възможно да се конфигурира кой трафик да бъде прихванат и изпратен до istio-agent. Например, за да прихванете целия входящ и изходящ трафик, трябва да зададете параметрите -i и -b в смисъл *. Можете да посочите конкретни портове за прихващане. За да не прихващате конкретна подмрежа, можете да я посочите с помощта на флага -x.
4. След изпълнението на init контейнерите се стартират основните, включително пилотния агент (пратеник). Той се свързва с вече внедрения Pilot чрез GRPC и получава информация за всички съществуващи услуги и политики за маршрутизиране в клъстера. Според получените данни той конфигурира клъстерите и ги присвоява директно към крайните точки на нашите приложения в клъстера Kubernetes. Също така е необходимо да се отбележи важен момент: envoy динамично конфигурира слушателите (IP, двойки портове), които започва да слуша. Следователно, когато заявките влязат в pod, се пренасочват с помощта на правилата за iptables за пренасочване в помощната кола, envoy вече може успешно да обработва тези връзки и да разбере къде да проксиира трафика допълнително. Също така на този етап се изпраща информация към миксера, който ще разгледаме по-късно, и се изпращат проследяващи участъци.

В резултат на това получаваме цяла мрежа от прокси сървъри envoy, които можем да конфигурираме от една точка (Pilot). Всички входящи и изходящи заявки минават през envoy. Освен това се прихваща само TCP трафик. Това означава, че IP на услугата Kubernetes се разрешава с помощта на kube-dns през UDP без промяна. След това, след разрешаването, изходящата заявка се прихваща и обработва от пратеник, който вече решава към коя крайна точка трябва да бъде изпратена заявката (или не изпратена, в случай на политики за достъп или прекъсвач на веригата на алгоритъма).

Разбрахме Pilot, сега трябва да разберем как работи Mixer и защо е необходим. Можете да прочетете официалната документация за него тук.

Миксерът в сегашната си форма се състои от два компонента: istio-telemetry, istio-policy (преди версия 0.8 беше един компонент istio-mixer). И двата са миксери, всеки от които отговаря за собствената си задача. Istio telemetry получава информация за това кой къде отива и с какви параметри от контейнерите за отчети с кош чрез GRPC. Istio-policy приема заявки за проверка, за да провери дали правилата на политиката са изпълнени. Проверките на правилата, разбира се, не се извършват за всяка заявка, но се кешират на клиента (в страничната кола) за определено време. Отчетните проверки се изпращат като пакетни заявки. Нека да видим как да конфигурираме и какви параметри трябва да бъдат изпратени малко по-късно.

Предполага се, че Mixer е високодостъпен компонент, който осигурява непрекъсната работа по сглобяването и обработката на телеметрични данни. В резултат системата се получава като многостепенен буфер. Първоначално данните се буферират от страната на коша на контейнерите, след това от страната на миксера и след това се изпращат до така наречените задни части на миксера. В резултат на това, ако някой от системните компоненти се повреди, буферът нараства и се измива след възстановяване на системата. Бекендовете на миксера са крайни точки за изпращане на телеметрични данни: statsd, newrelic и др. Можете да напишете свой собствен бекенд, това е доста просто и ще видим как да го направим.

За да обобщим, схемата за работа с istio-телеметрия е следната.

1. Услуга 1 изпраща заявка до услуга 2.
2. При напускане на услуга 1, заявката се опакова в собствената си кош.
3. Sidecar envoy следи как заявката отива към услуга 2 и подготвя необходимата информация.
4. След това го изпраща до istio-telemetry с помощта на заявка за отчет.
5. Istio-telemetry определя дали този отчет трябва да бъде изпратен до задните части, към кои и какви данни трябва да бъдат изпратени.
6. Istio-telemetry изпраща отчетни данни към бекенда, ако е необходимо.

Сега нека видим как да разположим Istio в системата, състояща се само от основните компоненти (Pilot и sidecar envoy).

Първо, нека да разгледаме основната конфигурация (мрежа), която Pilot чете:

apiVersion: v1
kind: ConfigMap
metadata:
  name: istio
  namespace: istio-system
  labels:
    app: istio
    service: istio
data:
  mesh: |-

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

Всички основни контролни компоненти (контролна равнина) ще бъдат разположени в пространството от имена istio-system в Kubernetes.

Като минимум трябва само да внедрим Pilot. За това използваме такава конфигурация.

И ние ще конфигурираме ръчно инжектиращия кош на контейнера.

Начален контейнер:

initContainers:
 - name: istio-init
   args:
   - -p
   - "15001"
   - -u
   - "1337"
   - -m
   - REDIRECT
   - -i
   - '*'
   - -b
   - '*'
   - -d
   - ""
   image: istio/proxy_init:1.0.0
   imagePullPolicy: IfNotPresent
   resources:
     limits:
       memory: 128Mi
   securityContext:
     capabilities:
       add:
       - NET_ADMIN

И кош:

       name: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           service-name 
           --drainDuration 
           45s 
           --parentShutdownDuration 
           1m0s 
           --discoveryAddress 
           istio-pilot.istio-system:15007 
           --discoveryRefreshDelay 
           1s 
           --connectTimeout 
           10s 
           --proxyAdminPort 
           "15000" 
           --controlPlaneAuthPolicy 
           NONE
         env:
         - name: POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: POD_NAMESPACE
           valueFrom:
             fieldRef:
               fieldPath: metadata.namespace
         - name: INSTANCE_IP
           valueFrom:
             fieldRef:
               fieldPath: status.podIP
         - name: ISTIO_META_POD_NAME
           valueFrom:
             fieldRef:
               fieldPath: metadata.name
         - name: ISTIO_META_INTERCEPTION_MODE
           value: REDIRECT
         image: istio/proxyv2:1.0.0
         imagePullPolicy: IfNotPresent
         resources:
           requests:
             cpu: 100m
             memory: 128Mi
           limits:
             memory: 2048Mi
         securityContext:
           privileged: false
           readOnlyRootFilesystem: true
           runAsUser: 1337
         volumeMounts:
         - mountPath: /etc/istio/proxy
           name: istio-envoy

За да стартира всичко успешно, трябва да създадете ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, чиито описания можете да намерите тук.

В резултат на това услугата, в която инжектираме sidecar с envoy, трябва да стартира успешно, да получава всички открития от пилота и да обработва заявки.

Важно е да се разбере, че всички компоненти на контролната равнина са приложения без състояние и могат да бъдат хоризонтално мащабирани без проблеми. Всички данни се съхраняват в etcd под формата на персонализирани описания на ресурсите на Kubernetes.

Също така, Istio (все още е експериментален) има способността да работи извън клъстера и способността да наблюдава и бърка откриването на услуги между няколко клъстера Kubernetes. Можете да прочетете повече за това тук.

За инсталация с няколко клъстера имайте предвид следните ограничения:

1. Pod CIDR и Service CIDR трябва да бъдат уникални във всички клъстери и не трябва да се припокриват.
2. Всички CIDR подове трябва да са достъпни от всички CIDR подове между клъстери.
3. Всички API сървъри на Kubernetes трябва да са достъпни един за друг.

Това е първоначалната информация, която ще ви помогне да започнете с Istio. Все още обаче има много подводни камъни. Например функции за маршрутизиране на външен трафик (извън клъстера), подходи за отстраняване на грешки в странични коли, профилиране, настройка на миксер и писане на потребителски бекенд на миксер, настройка на механизъм за проследяване и неговата работа с помощта на envoy.
Всичко това ще разгледаме в следващите публикации. Задавайте въпросите си, ще се опитам да ги покрия.

Източник: www.habr.com