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

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

Mehhanismi kohta saab lugeda ametlikus dokumentatsioonis. Istio on tõeliselt võimas tööriist, mis võimaldab lahendada palju ülesandeid ja probleeme. Selles artiklis soovin vastata peamistele küsimustele, mis tavaliselt tekivad Istio kasutamise alguses. See aitab teil sellega kiiremini tutvuda.

Tööprintsiip

Istio koosneb kahest põhiviaalast — control plane ja data plane. Control plane sisaldab põhikomponente, mis tagavad teiste korrektse töö. Praeguses versioonis (1.0) on control plane'il kolm peamist komponenti: Pilot, Mixer, Citadel. Citadel'i me ei käsitle, see on vajalik sertifikaatide genereerimiseks, et tagada mutual TLS tööde korrektne käitamine teenuste vahel. Vaatame lähemalt Piloti ja Mixeri struktuuri ja eesmärke.

Pilot on peamine juhtimiskomponent, mis levitab kogu teabe selle kohta, mis meil klastris on – teenused, nende endpoint'id ja routeerimise reeglid (näiteks Canary deploymenti või circuit breaker'i reeglid).

Mixer on valikuline control plane komponent, mis pakub võimalust koguda mõõdikuid, logisid ja igasugust teavet võrgusuhete kohta. Samuti jälgib see poliitikareeglite järgimist ja kiiruspiiranguid.

Data plane'i rakendatakse sidecar konteinerite-prokside abil. Vaikimisi kasutatakse võimsat proksiserverit envoy. Selle võib asendada muude teostustega, näiteks nginx (nginmesh).

Kuna Istio peab töötama rakendustele täiesti läbipaistvalt, on olemas automaatne injectimise süsteem. Viimane teostus sobib Kubernetes'i versioonidele 1.9+ (mutational admission webhook). Kubernetes'i versioonidele 1.7, 1.8 on olemas võimalus kasutada Initializer'i.

Sidecar konteinerid ühenduvad Pilotiga GRPC protokolli kaudu, mis võimaldab optimeerida muudatuste edastamise mudelit klastris. GRPC hakati Envoy's kasutama alates versioonist 1.6, Istios kasutatakse seda alates versioonist 0.8 ja see esindab pilot-agent’i — golang'i ümbritsemist envoy' üle, mis konfigureerib käivitamisparameetreid.

Pilot ja Mixer on täiesti stateless komponendid, kõik olek on mälus. Nende konfiguratsioon määratakse Kubernetes'i Custom Resources'i kujul, mis salvestatakse etcd's.
Istio-agent saab Pilot'i aadressi ja avab sellele GRPC voogu.

Nagu juba öeldud, rakendab Istio kogu funktsionaalsuse rakendustele täiesti läbipaistvalt. Vaatame, kuidas. Algoritm on järgmine:

Paigaldame teenuse uue versiooni.
Sõltuvalt sidecar konteineri injectimise lähenemisest lisatakse konfigureerimise rakendamise etapis istio-init konteiner ja istio-agent konteiner (envoy), või need võivad juba manualt olla Kubernetese Pod'i kirjelduse sisse pandud.
istio-init konteiner on skript, mis rakendab iptables reeglid poodi. On kaks võimalust liikluse suunamise seadistamiseks istio-agent konteineri, kasutades iptables'i suunamisreegleid, või TPROXY. Käesoleva artikli kirjutamise ajal kasutatakse vaikimisi suunamisreeglite lähenemist. istio-init'is on võimalus määrata, millist liiklust tuleb tabada ja suunata istio-agent'i. Näiteks, et tabada kogu sissetulev ja väljaminev liiklus, tuleb seada parameetrid -i ja -b väärtuse *. Võib määrata konkreetseid porte, mida tuleb tabada. Et mitte tõkestada teatud allvõrku, võib selle määrata lipuga -x.
. Pärast init konteinerite teostamist alustatakse põhikonteinerite, sealhulgas pilot-agent'i (envoy) käivitamist. See ühendub juba juurutatud Pilotiga GRPC kaudu ja saab teavet kõigi olemasolevate teenuste ja routeerimise poliitikate kohta klastris. Saadud andmete põhjal konfigureerib see klastrid ja määrab meie rakenduste endpoint'id Kubernetes'i klastris. Samuti tuleb märkida oluline punkt: envoy konfigureerib dünaamiliselt kuuldud kuulajaid (IP, port) paarides, mida ta hakkab kuulama. Seega, kui päringud siseneb poodi, suunatakse need iptables'i reeglite abil sidecar'i, envoy suudab juba edukalt neid ühendusi töödelda ja mõista, kuhu liiklus edastada. Samuti toimub sel etapil teabe saatmine Mixer'ile, mida vaatame hiljem, ja jälgimise span'ide saatmine.

Lõpptulemusena saame terve võrgustiku envoy proksiserveritest, mida saame ühest punktist (Pilot) seadistada. Kõik sissetulevad ja väljaminevad päringud läbivad envoy. Samuti tabatakse ainult TCP liiklus. See tähendab, et Kubernetes'i teenuse IP lahendatakse kube-dnsiga UDP kaudu muutmata. Seejärel toimub juba pärast lahendust päringu sissetuleku tabamine ja töötlemine envoy poolt, mis juba otsustab, kuhu endpoint'ile päring saata (või mitte saata, juhul kui on juurutatud juurdepääsupoliitika või circuit breaker algoritmi töötamine).

Me ei käsitlenud Pilotit, nüüd peame aru saama, kuidas töötab Mixer ja miks see vajalik on. Lukeda selle kohta ametlikke dokumente saab siin.

Mixer praeguses vormis koosneb kahest komponendist: istio-telemetry, istio-policy (kuni versioonini 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'i teavet selle kohta, kuhu keegi läheb ja milliste parameetritega. Istio-policy võtab Check päringud, et kontrollida, kas poliitika reeglitele vastatakse. Poliitika kontrollimist ei tehta loomulikult iga päringu puhul, vaid see vahemälu salvestatakse kliendipoolses (sidecar) teatud ajaks. Report kontrollid saadetakse partii päringutena. Kuidas seadistada ja millised täpselt parameetrid saata, vaatame natuke hiljem.

Mixer on ette nähtud kui kõrgelt saadaval komponent, mis tagab katkestusteta telestatistika andmete kogumise ja töötlemise. Lõppkokkuvõttes toimib süsteem kui mitme taseme vahemälu. Andmed vahemälu salvestatakse esmalt sidecar konteinerite küljel, seejärel mixeril ja lõpuks saadetakse nõnda nimetatud mixer backend'idesse. Seetõttu, kui mõni süsteemi komponent katkeb, suureneb vahemälu ja pärast süsteemi taastumist tühjendatakse see. Mixer backend’id on lõpupunktid telemeetriateabe saatmiseks: statsd, newrelic jne. Saate kirjutada oma backend'i, see on piisavalt lihtne, ja vaatame, kuidas seda teha.

Kokkuvõtlikult toimib istio-telemetry järgmiselt.

Teenuse 1 saadab päringu teenusele 2.
Väljudes teenusest 1, mähitakse päring tema oma sidecar'isse.
Sidecar envoy jälgib, kuidas päring liigub teenusesse 2 ja valmistab ette vajaliku teabe.
Seejärel saadab ta selle istio-telemetry'le Report päringu kaudu.
Istio-telemetry määrab, kas on vaja see Report saata backend'idesse, millistesse täpselt ja millised andmed tuleb saata.
Istio-telemetry saadab Report andmed backend'isse, kui see on vajalik.

Nüüd vaatame, kuidas süsteemi Istio rakendada, mis koosneb ainult põhilistest komponentidest (Pilot ja sidecar envoy).

Alustame peamise konfiguratsiooni (mesh) vaatamisest, mida Pilot loeb:

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

    # hetkel ei lülita tracing andmete saatmist sisse (pilot seadistab envoy nii, et saatmine ei toimu)
    enableTracing: false

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

    # määrame ajavahemiku, millega envoy küsib Pilotilt (see on vanale versioonile envoy proxy)
    rdsRefreshDelay: 5s

    # vaikimisi konfiguratsioon envoy sidecar'ile
    defaultConfig:
      # samuti nagu rdsRefreshDelay
      discoveryRefreshDelay: 5s

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

      # vaikimisi nimi jooksva sidecar konteineri jaoks (kasutatakse näiteks teenuse nimedes trace'i span'ide saatmisel)
      serviceCluster: istio-proxy

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

      # vaikimisi kasutatakse iptables'i REDIRECT reegleid. Saate muuta TPROXY'ks.
      #interceptionMode: REDIRECT

      # Port, millel töötab iga sidecar konteineri (envoy) admin paneel
      proxyAdminPort: 15000

      # aadress, kuhu saadetakse jälgimisandmed zipkin protokolliga (alguses lülitasime välja jälgimise, seega ei kasutata seda välja praegu)
      zipkinAddress: tracing-collector.tracing:9411

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

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

      # aadress, kus istio-pilot kuulab, et teavitada kõiki sidecar konteinerite teenuse avastamisest
      discoveryAddress: istio-pilot.istio-system:15007

Paigutame kõik põhikomponendid (control plane) Kubernetes'e istio-system nimede ruumi.

Minimaalselt peame rakendama vaid Piloti. Selleks kasutame sellist konfiguratsiooni.

Ja seadistame käsitsi sidecar konteineri süstimise.

Init 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:

       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

Ette, et kõik sujuks, tuleb luua ServiceAccount, ClusterRole, ClusterRoleBinding, CRD Piloti jaoks, nende kirjeldused on saadaval. siin.

Kokkuvõttes peab teenus, kuhu inject’ime sidecar’i koos envoy’ga, edukalt käivituma, saama kogu avastamise teabest Pilodilt ja töötlema päringuid.

Oluline on mõista, et kõik control plane'i komponendid on olekuteta rakendused ja neid saab probleemideta horisontaalselt skaalada. Kõik andmed asuvad etcd-s kohandatud Kubernetes'i ressursi kirjeldustena.

Istio-l on ka võimalus töötada klastrist väljas ning jagada teenuste avastamist mitme Kubernetes'i klastriga. Selle kohta võib lugeda rohkem. siin.

Mitme klastri paigaldamisel tuleks arvesse võtta järgmisi piiranguid:

Pod CIDR ja Service CIDR peavad olema kõigis klastrites unikaalsed ja ei tohi kattuda.
Kõik Pod CIDR-id peavad olema juurdepääsetavad mistahes Pod CIDR-ist klastrite vahel.
Kõik Kubernetes'i API serverid peavad olema omavahel kergesti juurdepääsetavad.

Need on esialgsed teadmised, mis aitavad teil alustada Istio'ga. Siiski on veel palju alaealisi probleeme, nagu välistrafi kiirus, sidecar'ide tõrkeotsing, profileerimine, mixer'i seadistamine ning kohandatud mixer backend'i kirjutamine, jälgimismehanismi seadistamine ja selle töö jaoks envoy.
Kõike seda käsitleme järgmistes väljaannetes. Esitage oma küsimused, üritan neid käsitleda.

Allikas: habr.com

Kuidas käivitada Istio, kasutades Kubernetesit tootmises. Osa 1

Tööprintsiip