🥇Kuidas käivitada Istio kasutades Kubernetes'i tootmises. Osa 1

Mis see on Istio? Это так называемый Service mesh, технология, которая добавляет уровень абстракции над сетью. Мы перехватываем весь или часть трафика в кластере и производим определенный набор операций с ним. Какой именно? Например, делаем умный роутинг, или реализуем подход circuit breaker, можем организовывать «canary deployment», частично переключая трафик на новую версию сервиса, а можем ограничивать внешние взаимодействия и контролировать все походы из кластера во внешнюю сеть. Есть возможность задавать policy правила для контроля походов между разными микросервисами. Наконец, мы можем получить всю карту взаимодействия по сети и сделать унифицированный сбор метрик полностью прозрачно для приложений.

Mekanismi töö kohta saab lugeda ametlikust dokumentatsioonist. Istio on tõeliselt võimas tööriist, mis suudab lahendada paljusid ülesandeid ja probleeme. Selles artiklis soovin vastata peamistele küsimustele, mis tavaliselt tekivad Istio kasutamise alguses. See aitab teil sellega kiiremini toime tulla.

Töö принцип

Istio koosneb kahest peamisest piirkonnast — juhtimistasandist ja andmetasandist. Juhtimistasand sisaldab endas põhikomponente, mis tagavad teiste korrektselt töö. Praeguses versioonis (1.0) on juhtimistasandast kolm põhikomponenti: Pilot, Mixer, Citadel. Citadelit me ei käsitle, see on vajalik sertifikaatide genereerimiseks, et tagada vastastikuse TLS-i toimimine teenuste vahel. Vaadakem lähemalt Pilot'i ja Mixer'i ülesehitust ja otstarvet.

Pilot on peamine juhtimiskomponent, mis edastab kogu teabe selle kohta, mis meil klastris on – teenused, nende endpoint'id ja marsruutimise reeglid (nt reeglid Canary deployment'i või circuit breaker'i jaoks).

Mixer on valikuline juhtimistasandi komponent, mis võimaldab koguda mõõdikuid, logisid ja kõike teavet võrguinteraktsiooni kohta. Samuti jälgib see poliitikareeglite täitmist ja kiiruspiirangutest kinnipidamist.

Andmetasand rakendatakse sidecar konteinerite-prokside abil. Vaikimisi kasutatakse võimsat proksiserverit envoy. Seda saab asendada muu rakendusega, näiteks nginx (nginmesh).

Et Istio töötaks rakendustele täiesti läbipaistvalt, on olemas automaatse süstimise süsteem. Viimane rakendus sobib Kubernetes'i versioonidele 1.9+ (mutatsiooniline vastuvõtu veebirakendus). Kubernetes'i versioonide 1.7, 1.8 jaoks on võimalik kasutada Initsialiseerijat.

Sidecar konteinerid ühendavad Pilot'iga GRPC protokolli kaudu, mis võimaldab optimeerida muutuste edastamise mudelit, mis toimub klastris. GRPC hakkas olema kasutusel Envoy's alates versioonist 1.6, Istios on see kasutusel alates versioonist 0.8 ja see esindab pilot-agent'i — golang'i ümbrist envoy üle, mis konfigureerib käivitamisparameetreid.

Pilot ja Mixer on täielikult staatusteta komponendid, kõik olekud hoitakse mälus. Nende jaoks on konfiguratsioon määratud Kubernetes'i kohandatud ressurssidena, mis salvestatakse etcd'sse.
Istio-agent saab Pilot'i aadressi ja avab sellele GRPC voog.

Nagu juba ütlesin, rakendab Istio kogu funktsionaalsuse rakendustele täielikult läbipaistvalt. Vaatame, kuidas. Algoritm on järgmine:

Paigaldame teenuse uue versiooni.
Sõltuvalt sidecar konteineri koostamise lähenemisest lisatakse istio-init konteiner ja istio-agent konteiner (envoy) konfiguratsiooni rakendamise etapis, või neid võib juba käsitsi sisestada Kubernetes Pod'i üksuse kirjeldusse.
istio-init konteiner on skript, mis rakendab iptables reeglid pod'i jaoks. On kaks varianti, kuidas seadistada liikluse suunamist istio-agent konteinerisse: kasutada iptables redirect reegleid, või TPROXY. Artikli kirjutamise hetkel kasutatakse vaikimisi lähenemist redirect reeglitega. Istio-init'is on võimalus seadistada, millist liiklust tuleb katkestada ja suunata istio-agent'i. Näiteks, et katkestada kogu sissetulev ja väljaminev liiklus, tuleb seada parameetrid -i ja -b väärtuseks *. Saate määrata konkreetsed pordid, mida tuleb katkestada. Et mitte katkestada teatud alamvõrku, saab seda näidata lipu abil -x.
Pärast init konteinerite täitmist käivitatakse peamised konteinerid, sealhulgas pilot-agent (envoy). See ühendub juba juurutatud Pilotiga GRPC kaudu ja saab teavet kõigi olemasolevate teenuste ja routing poliitikate kohta klasstri sees. Saadud andmete põhjal konfigureerib see klastreid ja määrab neile otsesed endpoint'id meie rakenduste jaoks Kubernetes klasstris. Samuti on oluline märkida, et envoy konfigureerib dünaamiliselt listeners (paarid IP, port), mida ta hakkab kuulama. Seetõttu, kui päringud sisenevad pod'i, suunatakse need iptables redirect reeglite abil sidecar'isse, envoy suudab juba edukalt need ühendused töödelda ja mõista, kuhu liiklus edasi suunata. Samuti toimub sel etapil teabe edastamine Mixer'ile, mida käsitleme hiljem, ja jälgimise span'ide edastamine.

Lõpuks saame terve võrgu envoy proksi-servereid, mida saame seadistada ühest kohast (Pilot). Kõik inbound ja outbound päringud läbivad envoy. Samuti katkestatakse ainult TCP liiklus. See tähendab, et Kubernetes teenuse IP lahendatakse kube-dns abil UDP kaudu ilma muutmisteta. Seejärel toimub pärast lahendamist väljamineva päringu katkestamine ja töötlemine envoy poolt, kes juba otsustab, millisele endpoint'ile päring edastada (või mitte edastada, juurdepääsupoliitikate või circuit breaker algoritmi aktiveerimise korral).

Oleme Pilotiga tutvunud, nüüd on vaja aru saada, kuidas Mixer töötab ja miks seda vaja on. Ametlikku dokumentatsiooni saab lugeda siit.

Mixer hetkel koosneb kahest komponendist: istio-telemetry ja istio-policy (enne versiooni 0.8 oli see üks komponent istio-mixer). Mõlemad on mixer, millest igaühel on oma ülesanne. Istio telemetry võtab GRPC kaudu sidecar konteineritelt Report teavet selle kohta, kuhu keegi läheb ja milliste parameetritega. Istio-policy võtab vastu Check päringud poliitikareeglite täitmise kontrollimiseks. Poliitika kontrollid ei toimu iga päringu puhul, vaid need vahemälustatakse kliendis (sidecar) teatud ajaks. Report kontrollid saadetakse hulgipäringutena. Kuidas seadistada ja milliseid täpseid parameetreid saata vaatame veidi hiljem.

Mixer on kavandatud kui kõrge kättesaadavusega komponent, mis tagab katkestusteta töö telemeetria andmete kogumisel ja töötlemisel. Süsteem kujuneb lõppkokkuvõttes mitmekihiliseks puhviks. Alguses andmed puhverdatakse sidecar konteinerite küljes, seejärel mixeris ja saadetakse siis nn mixer back-end'idele. Lõppkokkuvõttes, kui mõni süsteemi komponent ebaõnnestub, suureneb puhver ja pärast süsteemi taastumist kustutatakse see. Mixer back-end'id on telemeetria andmete saatmiskohad: statsd, newrelic jne. Võib kirjutada oma back-end'i, see on piisavalt lihtne, ja me vaatame, kuidas seda teha.

Kokkuvõttes on istio-telemetry töö skeem järgmine.

Teenuse 1 saadab päringu teenusele 2.
Teenusest 1 lahkudes pakendatakse päring selle enda sidecar'i.
Sidecar envoy jälgib, kuidas päring teenusesse 2 läbib ja valmistab ette vajaliku teabe.
Seejärel saadab ta selle istio-telemetry'ile Report päringuga.
Istio-telemetry määrab, kas see Report saata back-end'idele, millistele ning millised andmed edastada.
Istio-telemetry saadab Report andmed back-end'ile, kui see on vajalik.

Nüüd vaatame, kuidas määrata süsteemi Istio, mis koosneb ainult põhikomponentidest (Pilot ja sidecar envoy).

Esiteks vaatame põhikonfiguratsiooni (mesh), mille Pilot loeb:

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

    # praegu ei lülita jälgimise teavet saatmist sisse (pilot seadistab envoyd nii, et saatmine ei toimu)
    enableTracing: false

    # praegu ei määra mixer endpoint'e, et sidecar konteinerid ei saadaks teavet sinna
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # määrame ajavahemiku, mille jooksul envoy küsib Piloti käest uuesti (see kehtib vana versiooni envoy proxy kohta)
    rdsRefreshDelay: 5s

    # vaikimisi konfiguratsioon envoy sidecar'i jaoks
    defaultConfig:
      # samamoodi nagu rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # jätame vaikimisi (tee konfiguratsiooni ja binary envoy'i jaoks)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # vaikimisi nimi käivitatud sidecar konteinerile (kasutatakse näiteks teenuse nimedes, kui saadame jälgimise span'e)
      serviceCluster: istio-proxy

      # aeg, mille jooksul envoy ootab, enne kui ta sunnib lõpetama kõik avatud ühendused
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # vaikimisi kasutatakse REDIRECT iptables reegleid. Saame muuta TPROXY-ks.
      #interceptionMode: REDIRECT

      # Port, millel käivitatakse iga sidecar konteineri (envoy) haldusteenus
      proxyAdminPort: 15000

      # aadress, kuhu saadetakse jälgimised zipkin protokolli järgi (alguses lülitasime saatmise välja, seega see väli ei kasutata praegu)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd aadress envoy konteinerite mõõdikute saatmiseks (lülitame välja)
      # statsdUdpAddress: aggregator:8126

      # lülitame välja Mutual TLS toe
      controlPlaneAuthPolicy: NONE

      # aadress, kus istio-pilot kuulab, et edastada teenuse avastamise teavet kõigile sidecar konteineritele
      discoveryAddress: istio-pilot.istio-system:15007

Kõik põhikomponendid (control plane) paigutame namespace'i istio-system Kuberneteses.

Minimaalselt peame käivitama ainult Piloti. Selleks kasutame sellist konfiguratsiooni.

Ja seadistame käsitsi sidecar konteineri sisestamise.

Algus konteiner:

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

Ja sidecar:

       nimi: istio-proxy
       args:
         - "bash"
         - "-c"
         - |
           exec /usr/local/bin/pilot-agent proxy sidecar 
           --configPath 
           /etc/istio/proxy 
           --binaryPath 
           /usr/local/bin/envoy 
           --serviceCluster 
           teenus-nimi 
           --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

Selleks, et kõik sujuks, tuleb luua ServiceAccount, ClusterRole, ClusterRoleBinding ja CRD Pilot jaoks, mille kirjeldused on kergesti leitavad siit.

Lõpuks peab teenus, kuhu me inject’ime sidecar koos envoy’ga, edukalt käivituma, saama kogu discovery’st piloodi kaudu ja töötlema päringuid.

Oluline on mõista, et kõik control plane’i komponendid on stateless rakendused ja neid saab probleemideta horisontaalselt skaleerida. Kõik andmed asuvad etcd-s kohandatud Kubernetes'i ressursikirjelduste kujul.

Lisaks on Istio (praegu veel katsetusfaasis) võimalus töötada väljaspool klastri ja jagada teenuse avastust mitme Kubernetes'i klastre vahel. Rohkem teavet selle kohta on saadaval siit.

Mitme klastri installatsiooni puhul tuleb arvesse võtta järgmisi piiranguid:

Pod CIDR ja Service CIDR peavad olema unikaalsed kõikides klastrites ja ei tohi kattuda.
Kõik Pod CIDR-id peavad olema juurdepääsetavad ükskõik millisest Pod CIDR-ist klastrite vahel.
Kõik Kubernetes API serverid peavad olema üksteisega juurdepääsetavad.

Need on algsed teadmised, mis aitavad teil alustada Istio kasutamist. Siiski on veel palju peeneid aspekte. Näiteks välise liikluse marsruutimise eripärad (väljas poole klastrit), sidecar’ide tõrkeotsingu lähenemisviisid, profileerimine, mixeri seadistamine ja kohandatud mixeri taustteenuse loomine, jälgimismekanismi seadistamine ja selle toimimine envoy kaudu.
Kõik seda käsitleme järgmistes publikatsioonides. Esitage oma küsimused, püüan need selgeks teha.

Allikas: habr.com

Kuidas käivitada Istio kasutades Kubernetesit tootmises. Osa 1

Töö принцип