Si të aktivizoni Istio duke përdorur Kubernetes në produksion. Pjesa 1

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

Mund të lexoni për mekanizmin e funksionimit në dokumenti zyrtar. Istio është një instrument vërtet i fuqishëm që lejon zgjidhjen e shumë problemeve dhe detyrave. Në këtë artikull do të dëshiroja të përgjigjem në pyetjet kryesore që zakonisht shfaqen në fillim të punës me Istio. Kjo do t'ju ndihmojë të kuptoni 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ë funksionimin e drejtë të të tjerëve. Në versionin aktual (1.0) control plane ka tre komponentë kryesorë: Pilot, Mixer, Citadel. Ne nuk do të shqyrtojmë Citadel, pasi ai është i nevojshëm për të krijuar çertifikata për të siguruar funksionimin e mutual TLS midis shërbimeve. Le të shikojmë më në detaje strukturën dhe qëllimin e Pilot dhe Mixer.

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

Mixer është një komponent opsional i control plane, i cili ofron mundësinë për mbledhjen e metrikave, logëve dhe çdo informacioni mbi ndërveprimin në rrjet. Ai gjithashtu mbikëqyr përmbushjen e rregullave të Politikës dhe respektimin e limiteve të normave.

Data plane realizohet përmes kontejnerëve sidecar-proxy. Si parazgjedhje përdoret serveri proxy envoy. Ai mund të zëvendësohet me një implementim tjetër, si 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 injectimi. Implementimi më i fundit përshtatet për versionet Kubernetes 1.9+ (mutational admission webhook). Për versionet e Kubernetes 1.7, 1.8 ka mundësinë të përdorim Initializer.

Kontejnerët sidecar lidhen me Pilot përmes protokollit GRPC, i cili lejon optimizimin e modelit të përditësimit të ndryshimeve që ndodhin në klaster. GRPC filloi të përdoret në Envoy nga versioni 1.6, në Istio përdoret nga versioni 0.8 dhe përbën pilot-agent — një mbështjellës mbi golang mbi envoy që konfiguron parametrat e ekzekutimit.

Pilot dhe Mixer janë plotësisht komponentë stateless, të gjitha gjendjet i mbajnë në memorie. Konfigurimi për ta përcaktohet në formën e Burimeve të Personalizuara të Kubernetes, të cilat ruhen në etcd.
Istio-agent merr adresën e Pilot dhe hap një stream GRPC për të.

Siç e thashë, Istio realizon të gjitha funksionalitetet plotësisht në mënyrë transparente për aplikacionet. Le të kuptojmë se si. Algoritmi është i tillë:

1. Deployojmë një version të ri të shërbimit.
2. Në përputhje me qasjen e injectimit, kontejnerët sidecar janë të shtuar me kontejnerin istio-init dhe kontejnerin istio-agent (envoy) në fazën e aplikimit të konfigurimit, ose ata mund të jenë tashmë të futur manualisht në përshkrimin e entitetit Pod të Kubernetes.
3. Kontejneri istio-init përfaqëson një skript, i cili aplikon rregullat e iptables për podin. Ka dy mundësi për konfigurimin e mbështjelljes së trafikut në kontejnerin istio-agent: përdorimi i rregullave të redirect të iptables, ose TPROXY. Në momentin kur po shkruaj artikullin, si parazgjedhje përdoret qasja me rregullat e redirect. Në istio-init ka mundësinë të konfigurosh se cili trafikun duhet të kapet dhe drejtohet në istio-agent. Për shembull, për të kapur të gjithë trafikun hyrës dhe të gjithë trafikun dalës, duhet të vendosen parametrat -i dhe -b në vlerë *. Mund të specifikoni porte specifike që duhet të kapen. Për të mos kapur një nëndegë të caktuar, mund ta specifikoni atë me anë të flagut -x.
4. Pas ekzekutimit të kontejnerëve init, nisën ato kryesorë, dhe përfshirë pilot-agent (envoy). Ai lidhet me Pilotin e dekretuar 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 klasterët dhe shkruan menjëherë endpointët e aplikacioneve tona në klasterin Kubernetes. Gjithashtu, duhet theksuar një pikë e rëndësishme: envoy dinamikisht konfiguron listeners (çifte IP, port), që fillon të dëgjojë. Prandaj, kur kërkesat hyjnë në pod, ato redirektohen përmes rregullave të iptables në sidecar, envoy tani mund të përpunojë këto lidhje dhe të kuptojë se ku duhet të prokurohet trafiku më tutje. Në këtë fazë ndodh gjithashtu dërgimi i informacionit në Mixer, të cilin do ta shqyrtojmë më vonë, dhe dërgimi i span-ev tracing.

Si rezultat, ne marrim një rrjet të tërë serverësh proxy envoy, të cilët mund t'i konfigurojmë nga një pikë (Pilot). Të gjitha kërkesat hyrëse dhe dalëse kalojnë përmes envoy. Në fakt, vetëm trafiku TCP kapet. Kjo do të thotë se IP e shërbimit Kubernetes zgjidhet përmes kube-dns sipas UDP pa ndryshime. Më pas, pas zgjidhjes ndodh kapja e kërkesave dalëse dhe përpunimi nga envoy, i cili tashmë vendos se në cilin endpoint duhet të dërgohet kërkesa (ose të mos dërgohet, në rastin e politikave të aksesit ose nëse ka ndodhur algoritmi i circuit breaker).

Pas kuptimit të Pilot, tani duhet të kuptojmë se si funksionon Mixer dhe përse është e nevojshme. Mund të lexoni dokumentacionin zyrtar rreth saj. këtu.

Mixer në formën e tanishme përbëhet nga dy komponente: istio-telemetry dhe istio-policy (para versionit 0.8, ishte një komponent i vetëm, istio-mixer). Të dyja përfaqësojnë mixer, secila me detyrën e saj. Istio telemetry merr përmes GRPC nga konteinerët sidecar informacionin se kush po shkon ku dhe me cilat parametra. Istio-policy merr kërkesat Check për të verifikuar përmbushjen e rregullave të Policy. Kontrollimi i politikës nuk bëhet për çdo kërkesë, por ruhet në klient (në sidecar) për një kohë të caktuar. Raportet dërgohen në grupe. Si ta konfigurojmë dhe cilat parametra të veçanta duhet të dërgojmë do ta shqyrtojmë më vonë.

Mixer parashikohet si një komponent me disponibilitet të lartë, i cili ofron funksionimin pa ndërprerje për mbledhjen dhe përpunimin e të dhënave të telemetry. Sistemii përcaktohet si një buffer me shumë nivele. Fillimisht, të dhënat ruhen në anën e konteinerëve sidecar, pastaj në anën e mixer dhe më pas dërgohen në atë që quhen mixer backend. Në përfundim, nëse ndonjë nga komponentët e sistemit dështon, bufferi rritet dhe pas rindërtimit të sistemit, ai shfryhet. Mixer backend përfaqësojnë piketat finale për dërgimin e të dhënave mbi telemetri: statsd, newrelic dhe të tjerë. Mund të shkruani backend tuaj, është mjaft e thjeshtë dhe do ta shohim se si ta bëjmë këtë.

Nëse përmbledhim, skema e punës me istio-telemetry është si më poshtë.

1. Shërbimi 1 dërgon një kërkesë në shërbimin 2.
2. Pasi del nga shërbimi 1, kërkesa mbështillet në sidecar-in e tij.
3. Sidecar envoy monitoron se si kalon kërkesa në shërbimin 2 dhe përgatit informacionin e nevojshëm.
4. Pastaj e dërgon atë në istio-telemetry përmes kërkesës Report.
5. Istio-telemetry përcakton nëse duhet të dërgojë këtë Report në backend, në cilat saktësisht dhe çfarë të dhënash duhet të dërgohen.
6. Istio-telemetry dërgon të dhënat e Report në backend nëse është e nevojshme.

Tani le të shohim se si të implementojmë në sistemin Istio, i përbërë vetëm nga komponentët bazë (Pilot dhe sidecar envoy).

Fillimisht, le të shohim konfigurimin bazë (mesh) që lexon Pilot:

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

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

    # për momentin nuk tregojmë endpoint-in e mixer-it, që të mos dërgohen informacionet nga konteinerët sidecar atje
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # vendosim një interval, me të cilin envoy do të pyesë Pilot-in (kjo është për versionin e vjetër të envoy proxy)
    rdsRefreshDelay: 5s

    # konfigurimi default për envoy sidecar
    defaultConfig:
      # ngjashëm me rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # lëmë të gjitha siç është (rruga drejt konfigurimit dhe binarit të envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

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

      # koha që do të presë envoy deri sa të përfundojë të gjitha lidhjet e vendosura
      drainDuration: 45s
      parentShutdownDuration: 1m0s

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

      # Porti, në të cilin do të nisë paneli administrativ i çdo konteineri sidecar (envoy)
      proxyAdminPort: 15000

      # adresa, në të cilën do të dërgohen trace-t sipas protokollit zipkin (në fillim e çaktivizuam dërgimin vetë, kështu që kjo fushë tani nuk do të përdoret)
      zipkinAddress: tracing-collector.tracing:9411

      # adresa statsd për dërgimin e metrikave të konteinerëve envoy (e ç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 informacionin mbi zbulimin e shërbimit të gjithë konteinerëve sidecar
      discoveryAddress: istio-pilot.istio-system:15007

Të gjithë komponentët kryesorë të kontrollit (control plane) do t’i vendosim në namespace istio-system në Kubernetes.

Minimalisht, ne duhet të implementojmë vetëm Pilot. Për këtë do të përdorim të tillë konfigurimi.

Dhe do ta konfigurojmë manualisht injektimin e konteinerit sidecar.

Konteineri inicial:

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:

       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

Për të siguruar një fillim të suksesshëm, është e nevojshme të krijoni një ServiceAccount, ClusterRole, ClusterRoleBinding, dhe CRD për Pilot, për të cilat mund të gjeni përshkrime këtu.

Si rezultat, shërbimi në të cilin ne inject'ojmë sidecar me envoy duhet të startup me sukses, të marrë të gjithë zbulimin nga piloti dhe të përpunojë kërkesat.

Është e rëndësishme të kuptoni se të gjitha komponentët e planeve të kontrollit janë aplikacione pa shtet dhe mund të përshkallëzohen horizontalisht pa probleme. Të gjitha të dhënat ruhen në etcd në formën e përshkrimeve të personalizuara të burimeve Kubernetes.

Gjithashtu, Istio (aktualisht eksperimentohet) ka mundësinë e ekzekutimit jashtë klasterit dhe mundësinë për të parë dhe ndarë zbulimin e shërbimeve midis disa klasterëve Kubernetes. Më shumë për këtë mund të lexoni këtu.

Në instalimin me shumë klasterë, duhet të merret parasysh mirëkëto kufizime:

1. Pod CIDR dhe Service CIDR duhet të jenë unike në të gjitha klasterët dhe nuk duhet të përfshijnë njëri-tjetrin.
2. Të gjitha Pod CIDR duhet të jenë të aksesueshme nga çdo Pod CIDR midis klasterëve.
3. Të gjithë serverët API të Kubernetes duhet të jenë të aksesueshëm për njëri-tjetrin.

Këto janë informacionet fillestare që do t'ju ndihmojnë të filloni punën me Istio. Megjithatë, ka akoma shumë pengesa. Për shembull, veçoritë e rrugëtimit të trafikut të jashtëm (jashtë klasterit), qasjet në debug të sidecar-ëve, profilizimi, konfigurimi i mixer dhe krijimi i një backend të personalizuar të mixer, konfigurimi i mekanizmit të gjurmimit dhe funksionimi i tij me ndihmën e envoy.
Të gjitha këto do t'i shqyrtojmë në publikimet e ardhshme. Bëni pyetjet tuaja, do të mundohem t'i sqaroj.

Burimi: habr.com