ProHoster > Blogi > Haldamine > Kuidas käitada Istiot Kubernetese abil tootmises. 1. osa

Kuidas käitada Istiot Kubernetese abil tootmises. 1. osa

Mis on Istio? See on nn teenindusvõrk, tehnoloogia, mis lisab võrgule abstraktsioonikihi. Peame kinni kogu klastri liikluse või osa sellest ja teostame sellega teatud toiminguid. Milline? Näiteks teeme nutikat marsruutimist või rakendame kaitselülitit, saame korraldada "kanaari juurutamise", lülitades osaliselt liikluse teenuse uuele versioonile või piirame välist suhtlust ja kontrollime kõiki reise klastrist välisvõrk. Erinevate mikroteenuste vaheliste reiside kontrollimiseks on võimalik määrata poliitikareegleid. Lõpuks saame kogu võrgu interaktsiooni kaardi ja muuta ühtse mõõdikute kogu rakendustele täiesti läbipaistvaks.

Töömehhanismi kohta saate lugeda ametlik dokumentatsioon. Istio on tõeliselt võimas tööriist, mis võimaldab lahendada paljusid ülesandeid ja probleeme. Selles artiklis tahaksin vastata peamistele küsimustele, mis tavaliselt Istioga alustades kerkivad. See aitab teil sellega kiiremini toime tulla.

Kuidas käitada Istiot Kubernetese abil tootmises. 1. osa

Tööpõhimõte

Istio koosneb kahest põhialast – juhtimistasandist ja andmetasandist. Juhttasapind sisaldab põhikomponente, mis tagavad ülejäänute õige töö. Praeguses versioonis (1.0) on juhttasandil kolm põhikomponenti: Pilot, Mixer, Citadel. Me ei arvesta Citadeliga, see on vajalik sertifikaatide genereerimiseks, et tagada teenuste vastastikune TLS. Vaatame lähemalt Piloti ja Mikseri seadet ja eesmärki.

Kuidas käitada Istiot Kubernetese abil tootmises. 1. osa

Piloot on peamine juhtimiskomponent, mis levitab kogu teavet selle kohta, mis meil klastris on – teenused, nende lõpp-punktid ja marsruutimisreeglid (näiteks Canary juurutamise reeglid või kaitselüliti reeglid).

Mikser on valikuline juhttasandi komponent, mis võimaldab koguda mõõdikuid, logisid ja mis tahes teavet võrgu suhtluse kohta. Samuti jälgib ta eeskirjade täitmist ja intressimäärade täitmist.

Andmetasandit rakendatakse külgkorvi puhverserveri konteinerite abil. Vaikimisi kasutatakse võimsat. saadiku volinik. Selle saab asendada mõne muu rakendusega, näiteks nginx (nginmesh).

Selleks, et Istio töötaks rakendustele täiesti läbipaistvalt, on olemas automaatne sissepritsesüsteem. Uusim rakendus sobib Kubernetes 1.9+ versioonidele (mutatsioonilise juurdepääsu veebihaak). Kubernetese versioonide 1.7, 1.8 puhul on võimalik kasutada Initializerit.

Külgkorvi konteinerid ühendatakse Pilotiga GRPC-protokolli abil, mis võimaldab optimeerida tõukemudelit klastris toimuvate muudatuste jaoks. GRPC-d on Envoy's kasutatud alates versioonist 1.6, Istios on seda kasutatud alates versioonist 0.8 ja see on pilootagent - golang wrapper over envoy, mis konfigureerib käivitusvalikuid.

Pilot ja Mixer on täiesti olekuta komponendid, kõik olekud hoitakse mällu. Nende konfiguratsioon määratakse Kubernetese kohandatud ressursside kujul, mis on salvestatud kausta etcd.
Istio-agent saab piloodi aadressi ja avab sellele GRPC-voo.

Nagu ma ütlesin, rakendab Istio kõik funktsioonid rakendustele täiesti läbipaistvalt. Vaatame, kuidas. Algoritm on järgmine:

  1. Teenuse uue versiooni juurutamine.
  2. Olenevalt külgkorvi konteineri süstimise lähenemisviisist lisatakse istio-init konteiner ja istio-agendi konteiner (esindaja) konfiguratsiooni rakendamise etapis või saab need juba käsitsi sisestada Kubernetes Podi olemi kirjeldusse.
  3. Konteiner istio-init on skript, mis rakendab kaustale iptablesi reegleid. Liikluse istio-agendi konteinerisse mähimiseks on kaks võimalust: kasutage iptablesi ümbersuunamisreegleid või TPROXY. Kirjutamise ajal kasutati vaikimisi ümbersuunamisreegleid. Istio-initis on võimalik seadistada, milline liiklus tuleb pealtkuulada ja istio-agendile saata. Näiteks kogu sissetuleva ja kogu väljuva liikluse pealtkuulamiseks peate määrama parameetrid -i и -b tähendusse *. Saate määrata konkreetsed pealtkuulatavad pordid. Konkreetse alamvõrgu pealtkuulamiseks saate selle määrata lipu abil -x.
  4. Pärast init-konteinerite käivitamist käivitatakse peamised, sealhulgas piloot-agent (saadik). See loob ühenduse juba juurutatud piloodiga GRPC kaudu ja saab teavet kõigi klastri olemasolevate teenuste ja marsruutimispoliitikate kohta. Vastavalt saadud andmetele konfigureerib ta klastrid ja määrab need otse meie Kubernetese klastris olevate rakenduste lõpp-punktidele. Samuti on vaja märkida üks oluline punkt: envoy konfigureerib dünaamiliselt kuulajad (IP, pordipaarid), mida ta kuulama hakkab. Seega, kui päringud sisenevad kausta ja suunatakse ümber külgkorvi redirect iptablesi reeglite abil, saab saadik neid ühendusi juba edukalt töödelda ja mõista, kuhu liiklust edasi puhverserveerida. Ka selles etapis saadetakse teave mikserile, mida vaatame hiljem, ja saadetakse jälgimisvahemikud.

Selle tulemusena saame terve envoy puhverserverite võrgu, mida saame seadistada ühest punktist (Pilot). Kõik sissetulevad ja väljaminevad taotlused läbivad saadiku. Lisaks püütakse kinni ainult TCP-liiklus. See tähendab, et Kubernetese teenuse IP lahendatakse kube-dnsi abil UDP kaudu ilma muutmata. Seejärel, pärast lahendamist, võtab väljamineva päringu kinni ja töötleb saadik, kes juba otsustab, millisele lõpp-punktile päring saata (või mitte saata, kui tegemist on juurdepääsupoliitika või algoritmi kaitselülitiga).

Me mõtlesime Piloti välja, nüüd peame mõistma, kuidas Mixer töötab ja miks seda vaja on. Saate lugeda selle ametlikku dokumentatsiooni siin.

Mikser koosneb praegusel kujul kahest komponendist: istio-telemeetria, istio-policy (enne versiooni 0.8 oli see üks istio-mikseri komponent). Mõlemad on mikserid, millest igaüks vastutab oma ülesande eest. Istio telemeetria saab GRPC kaudu külgkorvi aruannete konteineritest infot, kes kuhu läheb ja milliste parameetritega. Istio-policy aktsepteerib kontrollitaotlusi, et kontrollida, kas eeskirjareeglid on täidetud. Poliitikakontrolli ei tehta loomulikult iga päringu puhul, vaid see salvestatakse kliendi vahemällu (külgkorvis) teatud ajaks. Aruandekontrollid saadetakse partiipäringutena. Vaatame, kuidas seadistada ja millised parameetrid tuleks saata veidi hiljem.

Mikser peaks olema väga kättesaadav komponent, mis tagab katkematu töö telemeetriaandmete komplekteerimisel ja töötlemisel. Süsteem saadakse selle tulemusena mitmetasandilise puhvrina. Esialgu puhverdatakse andmed konteinerite külgkorvi poolel, seejärel mikseri poolel ja seejärel saadetakse nn mikseri tagaosadesse. Selle tulemusena, kui mõni süsteemikomponentidest ebaõnnestub, suureneb puhver ja seda loputatakse pärast süsteemi taastamist. Mikseri taustaprogrammid on telemeetriaandmete saatmise lõpp-punktid: statsd, newrelic jne. Saate kirjutada oma taustaprogrammi, see on üsna lihtne ja me vaatame, kuidas seda teha.

Kuidas käitada Istiot Kubernetese abil tootmises. 1. osa

Kokkuvõtteks võib öelda, et istio-telemeetriaga töötamise skeem on järgmine.

  1. Teenus 1 saadab päringu teenusele 2.
  2. Teenusest 1 lahkudes mähitakse taotlus oma külgkorvi.
  3. Külgvankri saadik jälgib, kuidas päring läheb teenindusse 2 ja valmistab ette vajaliku teabe.
  4. Seejärel saadab selle aruandepäringu abil istio-telemeetriale.
  5. Istio-telemeetria määrab, kas see Aruanne tuleb saata taustaprogrammidele, kuhu ja milliseid andmeid saata.
  6. Istio-telemeetria saadab vajaduse korral aruande andmed taustaprogrammi.

Nüüd vaatame, kuidas Istio ainult põhikomponentidest (piloot ja külgkorvi saadik) koosnevas süsteemis juurutada.

Kõigepealt vaatame põhikonfiguratsiooni (võrku), mida Pilot loeb:

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

Kõik peamised juhtimiskomponendid (juhttasand) asuvad Kubernetese nimeruumi istiosüsteemis.

Vähemalt peame kasutusele võtma ainult Piloti. Selleks kasutame selline konfiguratsioon.

Ja me konfigureerime konteineri süstimise külgkorvi käsitsi.

Algkonteiner:

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 külgkorv:

       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

Et kõik edukalt käivituda, tuleb luua ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, mille kirjeldused leiate siin.

Selle tulemusel peaks teenus, millesse külgkorvi koos saadikuga sisestame, edukalt käivituma, saama piloodilt kõik avastused ja taotlusi menetlema.

Oluline on mõista, et kõik juhttasandi komponendid on olekuta rakendused ja neid saab probleemideta horisontaalselt skaleerida. Kõik andmed salvestatakse etcd-sse Kubernetese ressursside kohandatud kirjelduste kujul.

Samuti on Istiol (veel katseline) võimalus töötada väljaspool klastrit ning vaadata ja näristada teenuse avastamist mitme Kubernetese klastri vahel. Selle kohta saate rohkem lugeda siin.

Mitme klastriga installimisel pidage meeles järgmisi piiranguid.

  1. Pod CIDR ja teenuse CIDR peavad olema kõigis klastrites ainulaadsed ega tohi kattuda.
  2. Kõikidele CIDR-i moodulitele peab olema juurdepääs klastrite vahel asuvatest CIDR-moodulitest.
  3. Kõik Kubernetes API serverid peavad olema üksteisele juurdepääsetavad.

See on esialgne teave, mis aitab teil Istioga alustada. Siiski on veel palju lõkse. Näiteks välise liikluse marsruutimise funktsioonid (väljaspool klastrit), külgkorvide silumise lähenemisviisid, profileerimine, mikseri seadistamine ja kohandatud mikseri taustaprogrammi kirjutamine, jälgimismehhanismi seadistamine ja selle toimimine saadiku abil.
Seda kõike käsitleme järgmistes väljaannetes. Esitage oma küsimusi, ma püüan neid käsitleda.

Allikas: www.habr.com

Lisa kommentaar