Meriv çawa Istio bi karanîna Kubernetes di hilberînê de dimeşîne. Beş 1

çi Istio? Ev bi navê tevna Xizmetê ye, teknolojiyek ku qatek abstraksiyonê li ser torê zêde dike. Em hemî an beşek ji seyrûsefera di komê de digirin û bi wê re komek operasyonan pêk tînin. Kîjan? Mînakî, em rêwîtiyek biaqil dikin, an em nêzîkatiya qutkirina çerxerê bicîh dikin, em dikarin "bicihkirina kanaryan" organîze bikin, bi qismî trafîkê biguherînin guhertoyek nû ya karûbarê, an jî em dikarin danûstendinên derveyî sînordar bikin û hemî rêwîtiyên ji komê berbi komê ve kontrol bikin. tora derve. Ji bo kontrolkirina rêwîtiyên di navbera mîkroxizmetên cihêreng de gengaz e ku meriv qaîdeyên polîtîkayê saz bike. Di dawiyê de, em dikarin tevahiya nexşeya danûstendina torê bistînin û berhevoka yekbûyî ya metrîkan ji serîlêdanan re bi tevahî zelal bikin.

Hûn dikarin li ser mekanîzmaya xebatê bixwînin belgeyên fermî. Istio amûrek bi rastî hêzdar e ku dihêle hûn gelek kar û pirsgirêkan çareser bikin. Di vê gotarê de, ez dixwazim bersiva pirsên sereke yên ku bi gelemperî dema ku bi Istio re dest pê dikin çêbibin. Ev ê ji we re bibe alîkar ku hûn zûtir bi wê re mijûl bibin.

Meriv çawa Istio bi karanîna Kubernetes di hilberînê de dimeşîne. Beş 1

Ku çawa dixebite

Istio ji du deverên sereke pêk tê - balafira kontrolê û balafira daneyê. Balafira kontrolê hêmanên sereke hene ku xebata rast a yên mayî misoger dike. Di guhertoya heyî (1.0) de balafira kontrolê sê hêmanên sereke hene: Pilot, Mixer, Citadel. Em ê Citadel-ê nehesibînin, ew hewce ye ku sertîfîkayan biafirînin da ku TLS-ya hevbeş di navbera karûbaran de misoger bike. Ka em ji nêz ve li amûr û armanca Pilot û Mixer mêze bikin.

Meriv çawa Istio bi karanîna Kubernetes di hilberînê de dimeşîne. Beş 1

Pîlot hêmana kontrolê ya sereke ye ku hemî agahdariya li ser tiştê ku me di komê de heye belav dike - karûbar, xalên wan ên paşîn û rêzikên rêvekirinê (mînakî, qaîdeyên ji bo bicîhkirina Canary an qaîdeyên qutkirina çerxê).

Mixer hêmanek firokeya kontrolê ya vebijarkî ye ku şiyana berhevkirina metrîk, têketin, û her agahdariya di derbarê danûstendina torê de peyda dike. Ew di heman demê de lihevhatina bi qaîdeyên Siyasetê û pabendbûna bi sînorên rêjeyê re jî dişopîne.

Balafira daneyê bi karanîna konteynerên proxy-a sidecar tête bicîh kirin. Hêzdar ji hêla xwerû ve tê bikar anîn. nûnerê nûnerê. Ew dikare bi pêkanînek din, wekî nginx (nginmesh) were guheztin.

Ji bo ku Istio ji serlêdanan re bi tevahî zelal bixebite, pergalek derzîlêdanê ya otomatîk heye. Pêkanîna herî dawî ji bo guhertoyên Kubernetes 1.9+ (webhook pejirandina mutasyonel) maqûl e. Ji bo guhertoyên Kubernetes 1.7, 1.8 gengaz e ku meriv Initializer bikar bîne.

Konteynirên Sidecar bi karanîna protokola GRPC ve bi Pilot ve têne girêdan, ku dihêle hûn modela push ji bo guhertinên ku di komê de çêdibin xweşbîn bikin. GRPC ji guhertoya 1.6-ê ve di Envoy de tê bikar anîn, di Istio de ji guhertoya 0.8-ê ve hatî bikar anîn û pîlot-agent e - pêça golangê li ser nûnerê ku vebijarkên destpêkirinê mîheng dike.

Pîlot û Mikser bi tevahî pêkhateyên bêdewlet in, hemî dewlet di bîranînê de têne girtin. Veavakirin ji bo wan di forma Çavkaniyên Xweser ên Kubernetes de, ku di etcd de têne hilanîn, têne danîn.
Istio-agent navnîşana Pîlotê digire û pêvekek GRPC jê re vedike.

Wekî ku min got, Istio hemî fonksiyonê ji serîlêdanan re bi tevahî zelal pêk tîne. Ka em çawa bibînin. Algorîtma ev e:

  1. Dabeşkirina guhertoyek nû ya karûbarê.
  2. Li gorî nêzîkatiya derzîlêdana konteynera alîgir, konteynera istio-init û konteynera istio-agent (qeydkirî) di qonaxa sepandina mîhengê de têne zêdekirin, an jî ew dikarin berê xwe bidin nav danasîna saziya Kubernetes Pod.
  3. Konteynir istio-init skrîptek e ku qaîdeyên iptables li ser podê bicîh tîne. Du vebijark hene ji bo mîhengkirina seyrûseferê ku di konteynerek istio-agentê de were pêçandin: qaîdeyên beralîkirina iptables bikar bînin, an TPROXY. Di dema nivîsandinê de, nêzîkatiya xwerû bi qaîdeyên beralîkirinê re ye. Di istio-init de, mimkun e ku meriv mîheng bike ka kîjan seyrûsefer divê were girtin û ji istio-agent re were şandin. Mînakî, ji bo ku hûn hemî seyrûsefera hatinî û derketinê asteng bikin, hûn hewce ne ku pîvanan saz bikin -i и -b nav wateyê de *. Hûn dikarin benderên taybetî diyar bikin ku bikevin navberê. Ji bo ku hûn binavnetek taybetî negirin, hûn dikarin wê bi karanîna ala diyar bikin -x.
  4. Piştî ku konteynerên destpêkê têne darve kirin, yên sereke têne avêtin, di nav de pîlot-agent (qesir). Ew ji hêla GRPC ve bi Pîlota ku jixwe hatî vedan ve girêdide û di derheqê hemî karûbarên heyî û polîtîkayên rêvekirinê yên di komê de agahdarî distîne. Li gorî daneyên ku hatine wergirtin, ew koman mîheng dike û wan rasterast li dawiya serîlêdanên me yên di koma Kubernetes de vedigire. Di heman demê de pêdivî ye ku meriv xalek girîng jî binihêre: şandî bi dînamîk guhdaran (IP, cotên port) ku dest bi guhdarîkirinê dike mîheng dike. Ji ber vê yekê, gava ku daxwaz dikevin nav podê, bi karanîna qaîdeyên beralîkirina iptables di kêlekê de têne verast kirin, nûner jixwe dikare van girêdanan bi serfirazî bişopîne û fêm bike ku li ku derê bêtir seyrûseferê bike. Di heman demê de di vê qonaxê de, agahdarî ji Mixer re tê şandin, ku em ê paşê lê binihêrin, û şopên şopandinê têne şandin.

Wekî encamek, em tevnek tevnek pêşkêşkerên proxy şandî digirin ku em dikarin ji yek xalê vesaz bikin (Pîlot). Hemî daxwazên hundurîn û derketinê bi nûnerê xwe re derbas dibin. Wekî din, tenê seyrûsefera TCP-ê tê girtin. Ev tê vê wateyê ku IP-ya karûbarê Kubernetes bi karanîna kube-dns-ê li ser UDP bêyî guheztinê tê çareser kirin. Dûv re, piştî çareserkirinê, daxwaza derketinê ji hêla nûnerê ve tê girtin û pêvajoy kirin, ku berê biryar dide ku daxwaz ji kîjan xala dawîn re were şandin (an jî neyê şandin, di doza polîtîkayên gihîştinê an şkandina algorîtmayê de).

Me Pîlot fêhm kir, naha divê em fêm bikin ka Mixer çawa dixebite û çima hewce ye. Hûn dikarin ji bo wê belgeya fermî bixwînin vir.

Mixer di forma xweya heyî de ji du beşan pêk tê: istio-telemetry, istio-polîtîka (berî guhertoya 0.8 ew yek pêkhateyek istio-mixer bû). Her du jî mixer in, ku her yek ji wan berpirsiyariya karê xwe ye. Telemetrîya Istio bi GRPC-ê ji konteynirên raporê yên kêlekê agahdarî distîne ka kî diçe ku derê û bi kîjan parametreyan. Istio-polîtîka daxwazên Check qebûl dike da ku verast bike ku qaîdeyên Siyasetê têr in. Kontrolên siyasetê, bê guman, ji bo her daxwazekê nayên kirin, lê ji bo demek diyarkirî li ser xerîdar (di hêlekê de) têne girtin. Kontrolên raporê wekî daxwazên komê têne şandin. Ka em bibînin ka meriv çawa mîheng dike û kîjan pîvanan divê piçekî paşê bêne şandin.

Tê pêşbînîkirin ku Mixer pêkhateyek pir berdest e ku xebata bênavber li ser kombûn û hilanîna daneyên telemetrî misoger dike. Pergal di encamê de wekî tamponek pir-ast tê wergirtin. Di destpêkê de, dane li aliyê kêleka konteyneran, dûv re li milê mîkserê tê tampon kirin, û dûv re jî ji bo ku jê re tê gotin pişta mîkserê tê şandin. Wekî encamek, heke yek ji hêmanên pergalê têk biçe, tampon mezin dibe û piştî ku pergalê ji nû ve hatî vegerandin tê rijandin. Piştgirên Mixer ji bo şandina daneyên telemetrî xalên dawî ne: statsd, newrelic, hwd. Hûn dikarin paşnavê xwe binivîsin, ew pir hêsan e, û em ê bibînin ka meriv wê çawa bike.

Meriv çawa Istio bi karanîna Kubernetes di hilberînê de dimeşîne. Beş 1

Bi kurtasî, pilana xebata bi istio-telemetryê wiha ye.

  1. Xizmeta 1 daxwazek ji karûbarê 2 re dişîne.
  2. Dema ku dev ji karûbarê 1 berdide, daxwaz di kêleka xwe de tê pêçan.
  3. Nûnerê Sidecar çavdêriyê dike ku çawa daxwaz diçe xizmeta 2 û agahdariya pêwîst amade dike.
  4. Dûv re wê bi karanîna daxwaznameyek Raporê dişîne istio-telemetry.
  5. Istio-telemetry destnîşan dike ka gelo divê ev Rapor ji piştgiran re were şandin, ji kîjan û kîjan daneyan re were şandin.
  6. Ger hewce be, Istio-telemetry daneyên Raporê ji paşîn re dişîne.

Naha em em bibînin ka meriv çawa Istio di pergalê de, ku tenê ji hêmanên sereke (Pîlot û şanderê kêlekê) pêk tê, bicîh dike.

Pêşîn, em li veavakirina sereke (mesh) ku Pîlot dixwîne binêrin:

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

Hemî hêmanên sereke yên kontrolê (balafira kontrolê) dê di nav istio-pergala navan de li Kubernetes bicîh bibin.

Bi kêmanî, em tenê hewce ne ku Pîlot bicîh bikin. Ji bo vê yekê em bikar tînin veavakirineke wisa.

Û bi destan kêleka derzîlêdanê ya konteynerê mîheng bikin.

Konteynera destpêkê:

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

Û kêlekê:

       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

Ji bo ku her tişt bi serfirazî dest pê bike, hûn hewce ne ku ji bo Pilot Hesabek Service, ClusterRole, ClusterRoleBinding, CRD biafirînin, raveyên ku têne dîtin. vir.

Wekî encamek, karûbarê ku em bi şandeyê re tê de vedişêrin divê bi serfirazî dest pê bike, hemî vedîtin ji pîlotê werbigire û daxwazên pêvajoyê werbigire.

Girîng e ku meriv fêhm bike ku hemî hêmanên balafira kontrolê serîlêdanên bêdewlet in û dikarin bê pirsgirêk bi horizontî werin pîvandin. Hemî dane di forma ravekirinên xwerû yên çavkaniyên Kubernetes de di etcd de têne hilanîn.

Di heman demê de, Istio (hîn jî ezmûnî) xwedan şiyana ku li derveyî komê bimeşîne û şiyana temaşekirin û vedîtina karûbarê di navbera çend komikên Kubernetes de heye. Hûn dikarin li ser vê yekê bêtir bixwînin vir.

Ji bo sazkirinek pir-kluster, ji sînorên jêrîn haydar bin:

  1. Pod CIDR û Xizmeta CIDR divê di hemî koman de yekta bin û divê li hev nekin.
  2. Pêdivî ye ku hemî CIDR Pods ji her CIDR Pods di navbera koman de bêne gihîştin.
  3. Pêdivî ye ku hemî serverên API-ê yên Kubernetes ji hevûdu re bigihîjin.

Ev agahdariya destpêkê ye ku ji we re dibe alîkar ku hûn bi Istio re dest pê bikin. Lêbelê, hîn jî gelek xeletî hene. Mînakî, taybetmendiyên rêvekirina seyrûsefera derveyî (li derveyî komê), nêzîkatiyên ji bo rakirina rêgezên kêlekê, profîlkirin, sazkirina mîkserek û nivîsandina paşnavek mîkserê xwerû, sazkirina mekanîzmayek şopandinê û xebata wê bi karanîna şanderê.
Ev hemû em ê di weşanên jêrîn de bifikirin. Pirsên xwe bipirsin, ez ê hewl bidim ku wan veşêrim.

Source: www.habr.com

Add a comment