Si si oriento Istio, duke përdorur Kubernetes në prodhim. Pjesa 1

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

Mundësi për të lexuar për mekanizmin e funksionimit në dokumentacionin zyrtar. Istio është një mjet jashtëzakonisht i fuqishëm, i cili lejon zgjidhjen e shumë problemeve dhe sfidave. Në këtë artikull, do të doja të përgjigjem për pyetjet kryesore që zakonisht lindin në fillim të punës me Istio. Kjo do t'ju ndihmojë të orientoheni më shpejt.

Parimi i funksionimit

Istio përbëhet nga dy zona kryesore - control plane dhe data plane. Control plane përmban komponentët kryesorë që sigurojnë punën e duhur të të tjerëve. Në versionin aktual (1.0), control plane ka tre komponente kryesore: Pilot, Mixer, Citadel. Citadel nuk do ta shqyrtojmë, pasi nevojitet për gjenerimin e certifikatave që sigurojnë funksionimin e mutual TLS midis shërbimeve. Le të shohim më në detaje dizajnin dhe qëllimin e Pilot dhe Mixer.

Pilot është komponenti kryesor menaxher, i cili shpërndan të gjitha informacionet në lidhje me atë që kemi në klaster - shërbimet, endpoint-et e tyre dhe rregullat e routing (për shembull, rregullat për Canary deployment ose rregullat circuit breaker).

Mixer është një komponent opsional i control plane, i cili ofron mundësinë e mbledhjes së metrikave, logëve dhe çdo informacioni mbi ndërveprimin rrjetor. Po ashtu, ai monitoron përputhshmërinë me politikat dhe respektimin e kufizimeve të rate limit.

Data plane realizohet përmes kontejnerëve sidecar-proxy. Në mënyrë të paracaktuar, përdoret një server i fuqishëm proxy-server envoy. Ai mund të zëvendësohet me një implementim tjetër, për shembull nginx (nginmesh).

Për të siguruar që Istio funksionon plotësisht në mënyrë transparente për aplikacionet, ekziston një sistem automatik injektimi. Implementimi i fundit është i përshtatshëm për versionet e Kubernetes 1.9+ (mutational admission webhook). Për versionet e Kubernetes 1.7, 1.8 ka mundësinë e përdorimit të Initializer.

Kontejnerët sidecar lidhen me Pilot përmes protokollit GRPC, i cili lejon optimizimin e modelit të dërgimit të ndryshimeve që ndodhin në klaster. GRPC filloi të përdoret në Envoy që nga versioni 1.6, ndërsa në Istio përdoret që nga versioni 0.8 dhe përfaqëson pilot-agent - një mbështjellës në golang mbi envoy, i cili konfiguronte parametrat e nisjes.

Pilot dhe Mixer janë komponente plotësisht stateless, të gjitha gjendjet mbahen në memory. Konfigurimi për ta caktohet në formën e Burimeve të Personalizuara të Kubernetes, të cilat ruhen në etcd.
Istio-agent merr adresën Pilot dhe hap një rrjedhë GRPC drejt tij.

Siç e përmenda, Istio realizon gjithë funksionalitetin plotësisht transparent për aplikacionet. Le të shohim se si. Algoritmi është i tillë:

1. Ne e depolojmë versionin e ri të shërbimit.
2. Në varësi të qasjes së injektimit, kontenierët istio-init dhe istio-agent (envoy) shtohen në fazën e aplikimit të konfiguracionit, ose ata mund të jenë tashmë të vendosur manualisht në përshkrimin e entitetit Pod të Kubernetes.
3. Kontrolli istio-init përfaqëson një skenar që aplikon rregulla iptables për podin. Ka dy opsione për konfigurimin e përmbushjes së trafikut në kontenierin istio-agent: të përdorim rregullat redirect të iptables ose TPROXY. Në momentin e shkruajtjes së këtij artikulli, përdoret si me të drejtë qasja me rregulla redirect. Në istio-init ka mundësinë të përcaktojë se çfarë trafik duhet të kapet dhe të dërgohet në istio-agent. Për shembull, për të kapur të gjithë trafikun e ardhshëm dhe të dalë, duhet të vendosni parametrat -i dhe -b në vlerën *. Mund të specifikoni porte specifike që duhet të kapen. Për të mos kapur një subnet të caktuar, mund ta përcaktoni atë me ndihmën e flags -x.
4. Pas përfundimit të konteinerëve init, nisin ato kryesoret, përfshirë pilot-agent (envoy). Ai lidhet me Pilot-in e vendosur më parë përmes GRPC dhe merr informacion mbi të gjitha shërbimet ekzistuese dhe politikat e routing në klaster. Sipas të dhënave të marra, ai konfiguron clusterët dhe shënon aty endpoint-et e aplikacioneve tona në klasterin Kubernetes. Gjithashtu, është e rëndësishme të theksohet një pikë e rëndësishme: envoy dinamikisht konfiguron listeners (çifte IP, port), të cilat fillon të dëgjojë. Prandaj, kur kërkesat hyjnë në pod, ato redirektohen me ndihmën e rregullave të iptables në sidecar, envoy tashmë mund të përpunojë me sukses këto lidhje dhe të kuptojë se ku duhet të proxy-të trafikun më tej. Në këtë fazë ndodh gjithashtu dërgimi i informacionit në Mixer, të cilin do ta shqyrtojmë më vonë, dhe dërgimi i spaneve të gjurmimit.

Si rezultat, ne marrim një rrjet të tërë të serverëve proxy envoy, të cilët mund t'i konfigurojmë nga një pikë (Pilot). Të gjitha kërkesat inbound dhe outbound kalojnë përmes envoy. Për më tepër, vetëm trafiku TCP kapet. Kjo do të thotë se IP e shërbimit të Kubernetes rezolvohet me ndihmën e kube-dns përmes UDP pa ndryshime. Pastaj, pas rezolutës, ndodh kapja e kërkesës së dalë dhe përpunimi nga envoy, i cili tashmë vendos se në cilin endpoint duhet dërguar kërkesa (ose të mos dërgohet, në rastin e politikave të aksesit ose aktivizimit të algoritmit të circuit breaker).

Tani që e kuptuam Pilotin, duhet të kuptojmë se si funksionon Mixer dhe përse është i nevojshëm. Ju mund ta lexoni dokumentacionin zyrtar për të. këtu.

Mixer në formën aktuale përbëhet nga dy komponentë: istio-telemetry, istio-policy (deri në versionin 0.8 ky ishte një komponent istio-mixer). Të dy përbëjnë mixer, secila prej të cilave përgjigjet për detyrën e saj. Istio telemetry pranon informacion nga kontainerët sidecar përmes GRPC, duke raportuar informacionin se kush po shkon ku dhe me cilat parametra. Istio-policy merr kërkesa Check për të verifikuar përmbushjen e rregullave të Politikës. Kontrolli i Politikës, sigurisht, nuk kryhet për çdo kërkesë, por ruhet në klient (në sidecar) për një kohë të caktuar. Kontrolluesit e Raportit dërgohen me porosi batch. Si të konfigurohet dhe cilat parametra të dërgohen do ta shikojmë më vonë.

Mixer parashikohet si një komponent me disponueshmëri të lartë, i cili siguron vazhdimësinë e operacioneve për mbledhjen dhe përpunimin e të dhënave të telemetry. Sistemi përfundohet në një buffer shumënivelësh. Fillimisht, të dhënat bufferizohen në anën e kontainerëve sidecar, pastaj në anën e mixer dhe më pas dërgohen në atë që quhet mixer backend. Si rezultat, nëse ndonjë nga komponentët e sistemit dështon, bufferi rritet dhe pas rikthimit të sistemit, ajo zbrazet. Mixer backend përbën pika të fundit për dërgimin e të dhënave për telemetry: statsd, newrelic etj. Mund të shkruani backend tuaj, është mjaft e thjeshtë, dhe do ta shqyrtojmë si ta bëjmë.

Nëse përmbledhim, skema e punës me istio-telemetry është kështu.

1. Shërbimi 1 dërgon një kërkesë në shërbimin 2.
2. Kur del nga shërbimi 1, kërkesa paketuar në sidecar e tij.
3. Sidecar envoy monitoron se si kalon kërkesa në shërbimin 2 dhe përgatit informacionin e nevojshëm.
4. Ajo më pas e dërgon atë në istio-telemetry përmes një kërkese Report.
5. Istio-telemetry përcakton nëse duhet të dërgojë këtë Report në backend, në cilat përkatësisht dhe cilat të dhëna duhen dërguar.
6. Istio-telemetry dërgon të dhënat e Report në backend nëse kjo është e nevojshme.

Tani le të shikojmë se si të instalohet në sistemin Istio, që përbëhet vetëm nga komponentët e rëndësishëm (Pilot dhe sidecar envoy).

Fillimisht, le të shikojmë konfigurimin kryesor (mesh), që Pilot e lexon:

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

    # Ndërkohe, nuk do të aktivizojmë dërgimin e informacionit për tracing (pilot do të konfigurojë envoy në mënyrë që dërgimi të mos ndodhë)
    enableTracing: false

    # Ndërkohe, nuk do të shënojmë endpoint-et e mixer-it, në mënyrë që kontejnerët sidecar të mos dërgojnë informacion atje
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # Vendosim një interval kohor, me të cilin envoy do të bëjë përshtypje te Pilot (kjo është për versionin e vjetër të proxy-it envoy)
    rdsRefreshDelay: 5s

    # konfigurimi default për envoy sidecar
    defaultConfig:
      # ashtu si rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # e mbajmë siç është (rruga për konfigurimin dhe ekzekutimin e envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # emri default i kontejnerit sidecar të nisur (përdoret, për shembull, në emrat e shërbimeve gjatë dërgimit të tracing span-ve)
      serviceCluster: istio-proxy

      # koha që do të presë envoy para se të mbyllë të gjitha lidhjet e krijuara
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # për default përdoren rregullat REDIRECT të iptables. Mund të ndryshohet në TPROXY.
      #interceptionMode: REDIRECT

      # Porta, në të cilën do të nisë paneli administrativ i secilit kontejner sidecar (envoy)
      proxyAdminPort: 15000

      # adresa, në të cilën do të dërgohen trace-t sipas protokollit zipkin (në fillim kemi çaktivizuar dërgimin vetë, prandaj ky fushë tani nuk do të përdoret)
      zipkinAddress: tracing-collector.tracing:9411

      # adresa statsd për dërgimin e metricave të kontejnerëve envoy (çaktivizojmë)
      # statsdUdpAddress: aggregator:8126

      # çaktivizojmë mbështetje për opsionin Mutual TLS
      controlPlaneAuthPolicy: NONE

      # adresa, në të cilën do të dëgjojë istio-pilot për të raportuar informacion për discovery-in e shërbimeve të gjithë kontejnerëve sidecar
      discoveryAddress: istio-pilot.istio-system:15007

Të gjithë komponentët kryesorë të menaxhimit (control plane) do të vendosen në namespace istio-system në Kubernetes.

Minimalisht, na nevojitet të nisnim vetëm Pilot-in. Për këtë do të përdorim këtë konfigurim.

Dhe do ta konfigurojmë manualisht injektimin e kontejnerit sidecar.

Kontejneri Init:

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

Dhe sidecar:

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

Për të siguruar një nisje të suksesshme, është e nevojshme të krijoni një ServiceAccount, ClusterRole, ClusterRoleBinding, CRD për Pilot, përshkrimet e të cilave mund të gjenden këtu.

Si rezultat, shërbimi në të cilin ne injektojmë sidecar me envoy, duhet të nisë me sukses, të marrë të gjithë discovery nga piloti dhe të përpunojë kërkesat.

Është e rëndësishme të kuptohet se të gjithë komponentët e control plane janë aplikacione stateless dhe mund të shkallëzohen horizontalisht pa probleme. Të gjitha të dhënat ruhen në etcd në formën e përshkrimeve të personalizuara të burimeve të Kubernetes.

Gjithashtu, Istio (deri tani eksperimental) ka mundësinë e nisjes jashtë klastri dhe mundësinë për të parë dhe ndarë service discovery midis disa klastrave Kubernetes. Më shumë rreth kësaj mund të lexoni këtu.

Në instalimet shumëklashtore duhet të keni parasysh kufizime të mëposhtme:

1. Pod CIDR dhe Service CIDR duhet të jenë të unikë në të gjitha klastrat dhe nuk duhet të mbivendosen.
2. Të gjitha Pod CIDR duhet të jenë të aksesueshme nga çdo Pod CIDR midis klastrave.
3. Të gjithë serverët API të Kubernetes duhet të jenë të aksesueshëm ndaj njëri-tjetrit.

Këto janë informata fillestare që do t'ju ndihmojnë të filloni punën me Istio. Megjithatë, ka ende shumë pengesa. Për shembull, tiparet e routing-ut të trafikut të jashtëm (jashtë klastri), qasjet e debugsimit të sidecar-ëve, profilizimi, konfigurimi i mixer dhe krijimi i një backend të personalizuar për mixer, konfigurimi i mekanizmit të tracing dhe funksionimi i tij me ndihmën e envoy.
Ne do themi këtë në publikimet e tjera. Beni pyetjet tuaja dhe do përpiqem t'i adresoj ato.

Burimi: habr.com