Како покренути Истио користећи Кубернетес у производњи. Део 1

Шта је Истио? Ово је такозвана Сервице месх, технологија која додаје слој апстракције преко мреже. Пресрећемо цео или део саобраћаја у кластеру и са њим обављамо одређени скуп операција. Који? На пример, радимо паметно рутирање, или имплементирамо приступ прекидача, можемо да организујемо „канарску примену“, делимично пребацивање саобраћаја на нову верзију услуге, или можемо да ограничимо спољне интеракције и контролишемо сва путовања од кластера до спољна мрежа. Могуће је поставити правила политике за контролу путовања између различитих микросервиса. Коначно, можемо добити целу мапу мрежних интеракција и учинити јединствену колекцију метрика потпуно транспарентном за апликације.

О механизму рада можете прочитати у званична документација. Истио је заиста моћан алат који вам омогућава да решите многе задатке и проблеме. У овом чланку желео бих да одговорим на главна питања која се обично јављају када почнете да користите Истио. Ово ће вам помоћи да се брже носите са тим.

Принцип рада

Истио се састоји од две главне области - контролне равни и равни података. Контролна раван садржи главне компоненте које обезбеђују исправан рад остатка. У тренутној верзији (1.0) управљачки план има три главне компоненте: пилот, миксер, цитадела. Нећемо разматрати Цитаделу, потребно је генерисати сертификате да би се обезбедио међусобни ТЛС између услуга. Хајде да ближе погледамо уређај и намену Пилота и Миксера.

Пилот је главна контролна компонента која дистрибуира све информације о томе шта имамо у кластеру – услугама, њиховим крајњим тачкама и правилима рутирања (на пример, правила за примену Цанари или правила прекидача).

Миксер је опциона компонента контролне равни која пружа могућност прикупљања метрике, евиденције и свих информација о мрежној интеракцији. Он такође прати усклађеност са правилима Политике и поштовање ограничења стопе.

Раван података се имплементира помоћу бочних прокси контејнера. Поверфул се подразумевано користи. посланик пуномоћник. Може се заменити другом имплементацијом, као што је нгинк (нгинмесх).

Да би Истио радио потпуно транспарентно за апликације, постоји систем за аутоматско убризгавање. Најновија имплементација је погодна за Кубернетес 1.9+ верзије (вебхоок за мутацију). За Кубернетес верзије 1.7, 1.8 могуће је користити иницијализатор.

Контејнери с бочним колима су повезани са Пилотом помоћу ГРПЦ протокола, који вам омогућава да оптимизујете пусх модел за промене које се дешавају у кластеру. ГРПЦ се користи у Енвои-у од верзије 1.6, у Истио-у се користи од верзије 0.8 и представља пилот-агент - голанг омотач преко изасланика који конфигурише опције покретања.

Пилот и миксер су компоненте без држављанства, сва стања се чувају у меморији. Конфигурација за њих је постављена у облику Кубернетес прилагођених ресурса, који се чувају у етцд.
Истио-агент добија адресу пилота и отвара ГРПЦ ток на њу.

Као што сам рекао, Истио имплементира сву функционалност потпуно транспарентну за апликације. Да видимо како. Алгоритам је следећи:

1. Примена нове верзије услуге.
2. У зависности од приступа убризгавању контејнера са бочним колима, истио-инит контејнер и истио-агент контејнер (изасланик) се додају у фази примене конфигурације или се већ могу ручно убацити у опис ентитета Кубернетес Под.
3. Контејнер истио-инит је скрипта која примењује иптаблес правила на под. Постоје две опције за конфигурисање саобраћаја да буде умотан у истио-агент контејнер: користите иптаблес правила за преусмеравање или ТПРОКСИ. У време писања, подразумевани приступ је са правилима преусмеравања. У истио-инит, могуће је конфигурисати који саобраћај треба пресрести и послати истио-агенту. На пример, да бисте пресрели сав долазни и сав одлазни саобраћај, потребно је да подесите параметре -i и -b у смисао *. Можете одредити одређене портове за пресретање. Да не бисте пресрели одређену подмрежу, можете је одредити помоћу заставице -x.
4. Након што се инит контејнери изврше, покрећу се главни, укључујући пилот-агента (изасланика). Повезује се са већ распоређеним Пилотом преко ГРПЦ-а и прима информације о свим постојећим услугама и смерницама за рутирање у кластеру. Према примљеним подацима, он конфигурише кластере и додељује их директно крајњим тачкама наших апликација у Кубернетес кластеру. Такође је потребно напоменути важну тачку: енвои динамички конфигурише слушаоце (ИП, парови портова) које почиње да слуша. Стога, када захтеви уђу у под, преусмеравају се коришћењем правила за преусмеравање иптаблес у приколици, изасланик већ може успешно да обради ове везе и разуме где да даље прокси саобраћај. Такође у овој фази, информације се шаљу у миксер, који ћемо касније погледати, и шаљу се распони праћења.

Као резултат, добијамо читаву мрежу прокси сервера изасланика које можемо да конфигуришемо из једне тачке (Пилот). Сви улазни и одлазни захтеви пролазе преко изасланика. Штавише, пресреће се само ТЦП саобраћај. То значи да се ИП Кубернетес сервиса решава коришћењем кубе-днс-а преко УДП-а без промене. Затим, након решавања, одлазни захтев пресреће и обрађује изасланик, који већ одлучује на коју крајњу тачку захтев треба да се пошаље (или не пошаље, у случају политика приступа или прекидача алгоритма).

Схватили смо Пилот, сада морамо да разумемо како миксер ради и зашто је потребан. Можете прочитати званичну документацију за то овде.

Миксер у свом садашњем облику састоји се од две компоненте: истио-телеметрија, истио-политика (пре верзије 0.8 био је једна компонента истио-миксера). Обојица су миксери, од којих је сваки одговоран за свој задатак. Истио телеметрија прима информације о томе ко где иде и са којим параметрима из контејнера за извештаје са приколицом преко ГРПЦ. Истио-полици прихвата захтеве за проверу да би се потврдило да су правила Политике задовољена. Провере правила се, наравно, не спроводе за сваки захтев, већ се кеширају на клијенту (у приколици) одређено време. Провере извештаја се шаљу као пакетни захтеви. Да видимо како да конфигуришемо и које параметре треба послати мало касније.

Миксер би требало да буде веома доступна компонента која обезбеђује непрекидан рад на састављању и обради телеметријских података. Систем се добија као резултат као бафер на више нивоа. У почетку се подаци баферују на бочној страни контејнера, затим на страни миксера, а затим се шаљу у такозване позадинске стране миксера. Као резултат тога, ако било која од компоненти система поквари, бафер расте и испире се након што се систем врати. Позадине миксера су крајње тачке за слање телеметријских података: статсд, неврелиц, итд. Можете да напишете сопствени бацкенд, прилично је једноставно, а видећемо како да то урадите.

Да резимирамо, шема за рад са истио-телеметријом је следећа.

1. Сервис 1 шаље захтев сервису 2.
2. Приликом напуштања услуге 1, захтев је умотан у сопствену приколицу.
3. Изасланик споредне приколице прати како захтев иде сервису 2 и припрема потребне информације.
4. Затим га шаље истио-телеметрији користећи захтев за извештај.
5. Истио-телеметрија одређује да ли овај извештај треба послати бацкендовима, коме и које податке треба послати.
6. Истио-телеметрија шаље податке извештаја на позадину ако је потребно.

Сада да видимо како да применимо Истио у систему, који се састоји само од главних компоненти (Пилот и изасланик приколице).

Прво, погледајмо главну конфигурацију (мрежу) коју Пилот чита:

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

Све главне контролне компоненте (контролна раван) ће се налазити у именском истио-систему у Кубернетес-у.

У најмању руку, потребно је само да распоредимо Пилот. За ово користимо таква конфигурација.

А ми ћемо ручно конфигурисати бочну приколицу за убризгавање контејнера.

Инит контејнер:

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

Да би све успешно започело потребно је да креирате СервицеАццоунт, ЦлустерРоле, ЦлустерРолеБиндинг, ЦРД за Пилот, чији описи можете пронаћи овде.

Као резултат тога, услуга у коју убацујемо приколицу са изаслаником треба да почне успешно, да прими сва открића од пилота и да обради захтеве.

Важно је разумети да су све компоненте контролне равни апликације без стања и да се могу хоризонтално скалирати без проблема. Сви подаци се чувају у етцд-у у облику прилагођених описа Кубернетес ресурса.

Такође, Истио (још увек експерименталан) има могућност покретања ван кластера и могућност да гледа и петља откривање услуга између неколико Кубернетес кластера. Можете прочитати више о овоме овде.

За инсталацију са више кластера, имајте на уму следећа ограничења:

1. Под ЦИДР и Сервице ЦИДР морају бити јединствени у свим кластерима и не смеју се преклапати.
2. Сви ЦИДР модули морају бити доступни из било којег ЦИДР модула између кластера.
3. Сви Кубернетес АПИ сервери морају бити доступни једни другима.

Ово су почетне информације које ће вам помоћи да почнете да користите Истио. Међутим, и даље постоје многе замке. На пример, карактеристике рутирања екстерног саобраћаја (ван кластера), приступи отклањању грешака споредних кола, профилисање, подешавање миксера и писање прилагођеног миксера позадинског дела, постављање механизма праћења и његово функционисање помоћу енвои-а.
Све ово ћемо размотрити у следећим публикацијама. Поставите своја питања, покушаћу да их покријем.

Извор: ввв.хабр.цом