🥇Kako zagnati Istio z uporabo Kubernetes v produkciji. Del 1

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

O mehanizmu delovanja lahko preberete v uradni dokumentaciji. Istio je resnično zmogljivo orodje, ki omogoča reševanje številnih nalog in težav. V tem članku bi rad odgovoril na osnovna vprašanja, ki se običajno pojavijo na začetku dela z Istio. To vam bo pomagalo, da se hitreje spoprijateljite z njim.

Načelo delovanja

Istio se sestoji iz dveh glavnih območij — control plane in data plane. Control plane vsebuje osnovne komponente, ki zagotavljajo pravilno delovanje drugih. V trenutni različici (1.0) control plane vključuje tri glavne komponente: Pilot, Mixer, Citadel. Citadel ne bomo obravnavali, saj je potreben za generiranje certifikatov za zagotavljanje dela mutual TLS med storitvami. Oglejmo si podrobneje strukturo in namen Pilot in Mixer.

Pilot je glavni upravljalski komponent, ki distribuira vse informacije o tem, kar imamo v klasterju – storitve, njihove končne točke in pravila usmerjanja (na primer pravila za Canary deployment ali pravila circuit breaker).

Mixer je opcionalna komponenta control plane, ki omogoča zbiranje metrik, dnevnikov in vseh informacij o mrežnem interakciji. Prav tako spremlja skladnost s pravili politike in omejitvami hitrosti.

Data plane se realizira s sidecar proxy kontejnerji. Privzeto se uporablja zmogljiv proxy strežnik envoy. Lahko ga nadomestimo z drugo implementacijo, na primer nginx (nginmesh).

Da bi Istio deloval popolnoma prozorno za aplikacije, obstaja sistem samodejnega injiciranja. Zadnja implementacija je primerna za verzije Kubernetes 1.9+ (mutational admission webhook). Za različice Kubernetes 1.7 in 1.8 je na voljo možnost uporabe Initializer.

Sidecar kontejnerji se povezujejo s Pilotom prek protokola GRPC, ki omogoča optimizacijo modela potiskanja sprememb, ki se dogajajo v klasterju. GRPC se je začel uporabljati v Envoy od različice 1.6, v Istio pa se uporablja od verzije 0.8 in predstavlja pilot-agent — ovitek v golangu nad envoy, ki konfigurira parametre za zagon.

Pilot in Mixer sta povsem stateless komponenti, vso stanje hranita v spominu. Konfiguracija zanje je določena v obliki Kubernetes Custom Resources, ki se shranjujejo v etcd.
Istio-agent pridobi naslov Pilota in odpre GRPC tok k njemu.

Kot sem že povedal, Istio реализira celotno funkcionalnost popolnoma prozorno za aplikacije. Poglejmo si, kako. Algoritem je takšen:

Depoliramo novo različico storitve.
Odvisno od pristopa k dodajanju sidecar kontejnerja se na stopnji apliciranja konfiguracije dodata istio-init kontejner in istio-agent kontejner (envoy), ali pa sta že ročno vstavljen v opis Pod entitete Kubernetes.
istio-init kontejner je skript, ki uporablja pravila iptables za pod. Obstajata dva načina za nastavitev preusmeritve prometa v istio-agent kontejner: uporabiti pravila preusmeritve iptables, ali TPROXY. Ob času pisanja tega članka se po privzetku uporablja pristop s pravili preusmeritve. V istio-init je mogoče nastaviti, kateri promet je treba ujeti in usmeriti v istio-agent. Na primer, da bi zajeli celoten vhodni in celoten izhodni promet, je treba nastaviti parametre -i in -b na vrednost *. Lahko določite specifične porte, ki jih je treba ujeti. Da bi se izognili zajemanju določenega podomrežja, ga lahko določite s pomočjo zastavice -x.
Po izvedbi init kontejnerjev se zaženejo glavni, vključno s pilot-agent (envoy). Ta se poveže z že razporejenim Pilot preko GRPC in pridobi informacije o vseh obstoječih storitvah in usmerjevalnih politikah v klastru. Na podlagi prejetih podatkov konfigurira klastre in neposredno vpiše endpoint-e naših aplikacij v Kubernetes klastru. Prav tako je treba omeniti pomembno točko: envoy dinamično nastavi poslušalnike (pare IP, port), ki jih začne poslušati. Tako ko vstopajo poizvedbe v pod, jih preusmerijo s pomočjo pravil preusmeritve iptables v sidecar, envoy že uspešno obdeluje te povezave in razume, kam naprej usmeriti promet. Prav tako v tej fazi poteka pošiljanje informacij v Mixer, ki ga bomo obravnavali kasneje, in pošiljanje sledilnih razponov.

Na koncu dobimo celo mrežo envoy proxy strežnikov, ki jih lahko konfiguriramo iz ene točke (Pilot). Vse inbound in outbound zahteve gredo preko envoy. Pri tem se prestreza le TCP promet. To pomeni, da se IP-številka Kubernetes storitev razreši z uporabo kube-dns preko UDP brez sprememb. Šele po razrešitvi pride do prestrezanja odhodne zahteve in obdelave z envoyem, ki nato odloči, na kateri endpoint je treba poslati zahtevo (ali je ne poslati, v primeru pravil dostopa ali aktivacije algoritma circuit breaker).

S Pilotom smo se že seznanili, zdaj moramo razumeti, kako deluje Mixer in zakaj je potreben. Uradno dokumentacijo o tem lahko preberete. tukaj.

Mixer v trenutni obliki predstavlja dva komponenta: istio-telemetry, istio-policy (do različice 0.8 je bila enotni komponent istio-mixer). Obe predstavljata mixer, vsaka od njiju pa je odgovorna za svojo nalogo. Istio telemetry sprejema preko GRPC od sidecar vsebnikov Report informacije o tem, kdo kam gre in s kakšnimi parametri. Istio-policy sprejema Check zahteve za preverjanje skladnosti s pravili politike. Preverjanje pravil politike se seveda ne izvaja za vsako zahtevo, temveč se shranjuje v predpomnilniku na odjemalcu (v sidecar) za določeno obdobje. Check poročila se pošiljajo v serijah. Kako nastaviti in kakšne natančno parametre je treba posredovati, bomo videli malo kasneje.

Mixer se predvideva kot komponenta z visoko razpoložljivostjo, ki zagotavlja nemoteno delovanje pri zbiranju in obdelavi telemetry podatkov. Sistem v končni fazi deluje kot večslojni pomnilnik. Sprva se podatki shranijo na strani sidecar vsebnikov, nato na strani mixerja in nato se pošljejo na tako imenovane mixer backend-e. Na koncu, če kateri koli od komponent sistema odpove, se pomnilnik poveča in po obnovitvi sistema se prazni. Mixer backend-i predstavljajo končne točke za pošiljanje podatkov o telemetriji: statsd, newrelic itd. Lahko napišete svoj backend, to je precej preprosto, in poglejali bomo, kako to storiti.

Če povzamemo, je shema dela z istio-telemetry taka.

Storitev 1 pošlje zahtevo v storitev 2.
Ob izhodu iz storitve 1 se zahteva ovije v njen sidecar.
Sidecar envoy spremlja, kako poteka zahteva v storitev 2 in pripravlja potrebne informacije.
Nato jih pošlje v istio-telemetry s pomočjo Report zahteve.
Istio-telemetry določa, ali je treba poslati to poročilo v backend-e, v katere in katere podatke je treba poslati.
Istio-telemetry pošilja podatke o poročilih v backend, če je to potrebno.

Poglejmo, kako razporediti sistem Istio, ki je sestavljen le iz osnovnih komponent (Pilot in sidecar envoy).

Najprej poglejmo osnovno konfiguracijo (mesh), ki jo bere Pilot:

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

    # zaenkrat ne vključujemo pošiljanja informacij o sledenju (pilot bo nastavil envoyje tako, da pošiljanje ne bo potekalo)
    enableTracing: false

    # zaenkrat ne določamo mixer endpointov, da sidecar kontejnerji ne bodo pošiljali informacij tja
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # nastavimo časovni zamik, s katerim bo envoy ponovno spraševal Pilota (to je za staro različico envoy proxy)
    rdsRefreshDelay: 5s

    # privzeta konfiguracija za envoy sidecar
    defaultConfig:
      # podobno kot rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # pustimo privzeto (pot do konfiguracije in binarne različice envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # privzeto ime zagnanega sidecar kontejnerja (uporablja se, na primer, v imenih storitev pri pošiljanju sledenja spanov)
      serviceCluster: istio-proxy

      # čas, ki ga bo envoy čakal, preden prisilno konča vsa vzpostavljena povezovanja
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # privzeto se uporabljajo REDIRECT pravila iptables. Lahko jih spremenimo v TPROXY.
      #interceptionMode: REDIRECT

      # Prusotnostni port, na katerem bo zagnana administrativna plošča vsakega sidecar kontejnerja (envoy)
      proxyAdminPort: 15000

      # naslov, kjer bodo pošiljali sledi po zipkin protokolu (na začetku smo izklopili samo pošiljanje, zato to polje trenutno ne bo uporabljeno)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd naslov za pošiljanje metrik envoy kontejnerjev (izklopimo)
      # statsdUdpAddress: aggregator:8126

      # izklopimo podporo za možnost Mutual TLS
      controlPlaneAuthPolicy: NONE

      # naslov, na katerem bo istio-pilot poslušal za obvestila o iskanju storitev za vse sidecar kontejnerje
      discoveryAddress: istio-pilot.istio-system:15007

Vse osnovne komponente nadzora (control plane) bomo postavili v namespace istio-system v Kubernetes.

Minimalno moramo razporediti le Pilota. Za to bomo uporabili takšno konfiguracijo.

In ročno nastavimo injecting sidecar kontejnerja.

Init container:

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

И 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

Для того, чтобы все успешно запустилось, нужно создать ServiceAccount, ClusterRole, ClusterRoleBinding и CRD для Pilot, описания которых можно найти tukaj.

В итоге сервис, в который мы inject’им sidecar с envoy, должен успешно запуститься, получить весь discovery от пилота и обрабатывать запросы.

Важно понимать, что все компоненты control plane являются stateless приложениями и могут быть без проблем горизонтально масштабированы. Все данные хранятся в etcd в виде кастомных описаний ресурсов Kubernetes.

Также у Istio (пока что экспериментально) есть возможность запуска вне кластера и возможность видеть и делиться service discovery между несколькими Kubernetes кластерами. Подробнее об этом можно почитать tukaj.

При мультикластерной установке следует учитывать следующие ограничения:

Pod CIDR и Service CIDR должны быть уникальны по всем кластерам и не должны пересекаться.
Все Pod CIDR должны быть доступны от любых Pod CIDR между кластерами.
Все Kubernetes API серверы должны быть доступны друг для друга.

To so osnovne informacije, ki vam bodo pomagale začeti delati z Istio. Vendar pa je še veliko pastmi. Na primer, posebnosti usmerjanja zunanjega prometa (izven gruče), pristopi k odpravljanju napak sidecar-ov, profiliranje, nastavitev mixerja in pisanje po meri mixer backend-a, nastavitev mehanizma sledenja in njegovo delovanje preko envoy-a.
Vse to bomo obravnavali v naslednjih objavah. Postavite svoja vprašanja, trudil se bom, da jih osvetlim.

Izvor: habr.com

Kako pokrenuti Istio koristeći Kubernetes u produkciji. Deo 1

Načelo delovanja