🥇Hogyan indítsuk el az Istio-t Kubernetes használatával a production-ben. 1. rész

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

A működési mechanizmusról itt olvashat. hivatalos dokumentációban. Az Istio valóban egy erőteljes eszköz, amely számos feladat és probléma megoldására alkalmas. Ebben a cikkben szeretnék válaszolni a legfontosabb kérdésekre, amelyek általában felmerülnek az Istio használatának kezdetén. Ez segíthet gyorsabban eligibilizálni.

A működés elve

Az Istio két fő zónából áll - control plane és data plane. A control plane tartalmazza azokat az alapvető összetevőket, amelyek biztosítják a többi megfelelő működését. A jelenlegi verzióban (1.0) a control plane három fő összetevőből áll: Pilot, Mixer, Citadel. A Citadel nem kerül részletezésre, ez a szolgáltatások közötti mutual TLS működéséhez szükséges bizonyítványok generálására szolgál. Nézzük meg részletesebben a Pilot és a Mixer felépítését és célját.

A Pilot a fő irányító összetevő, amely terjeszti az összes információt arról, ami a klaszterben található - szolgáltatások, azok végpontjai és irányítási szabályok (például a Canary deployment vagy a circuit breaker szabályok).

A Mixer egy opcionális összetevő a control plane-ben, amely lehetőséget ad a metrikák, naplózás és a hálózati interakciókról szóló információk gyűjtésére. Emellett figyel a Policy szabályok betartására és a rate limit-ek betartására is.

A data plane sidecar proxy tartályokon keresztül valósul meg. Alapértelmezés szerint egy erős proxy szerver, az envoy. Ez egy másik megoldásra is cserélhető, például nginx-re (nginmesh).

Ahhoz, hogy az Istio teljesen átláthatóan működjön a alkalmazások számára, van egy automatikus injektáló rendszer. Az utolsó megoldás a Kubernetes 1.9+ verziókhoz illeszkedik (mutational admission webhook). A Kubernetes 1.7 és 1.8 verziói esetében Initializer használható.

A Sidecar tartályok GRPC protokollon keresztül kapcsolódnak a Pilot-hoz, amely lehetővé teszi a klaszterben bekövetkező változások push modeljének optimalizálását. A GRPC az Envoy-ban kezdett használódni 1.6 verziótól, az Istio-ban pedig 0.8 verziótól használják, és a pilot-agent-et jelenti - a golang wrapper-t az envoy körül, amely beállítja a paramétereket.

A Pilot és a Mixer teljesen stateless komponensek, minden állapotot a memóriában tárolnak. A konfigurációjuk Kubernetes Custom Resources formájában van megadva, amelyeket az etcd-ben tárolnak.
Az Istio-agent megkapja a Pilot címét, és megnyit egy GRPC stream-et hozzá.

Ahogy már mondtam, az Istio teljes mértékben átláthatóan valósítja meg a funkciókat az alkalmazások számára. Nézzük meg, hogyan. Az algoritmus a következő:

Telepítjük a szolgáltatás új verzióját.
A sidecar konténer injektálási megközelítésétől függően az istio-init konténer és az istio-agent konténer (envoy) a konfiguráció alkalmazásának szakaszában kerül hozzáadásra, vagy már manuálisan beilleszthetők a Kubernetes Pod entitás leírásába.
Az istio-init konténer egy olyan szkript, amely alkalmazza az iptables szabályokat a pod számára. Két lehetőség van a forgalom irányításának beállítására az istio-agent konténerbe: használni az iptables átirányító szabályokat, vagy TPROXY. A cikk írásakor alapértelmezés szerint az átirányító szabályok megközelítése van használatban. Az istio-init lehetőséget biztosít arra, hogy beállítsuk, milyen forgalmat kell elkapni és irányítani az istio-agent-be. Például, ha el akarjuk kapni az összes bejövő és kimenő forgalmat, be kell állítanunk a paramétereket -i és -b az értékre *. Megadhatók konkrét portok, amelyeket el kell kapni. Annak érdekében, hogy egy adott alhálózatot ne kapjunk el, azt a flag segítségével lehet megadni -x.
Az init konténerek futtatása után elindulnak a fő konténerek, és ezek között a pilot-agent (envoy) is. Ez a már telepített Pilot-hoz csatlakozik GRPC-n keresztül, és információt kap az összes létező szolgáltatásról és a clusteren belüli routing politikákról. Az így kapott adatok alapján konfigurálja a cluster-öket és közvetlenül beállítja az alkalmazásaink végpontjait a Kubernetes clusteren. Fontos megjegyezni egy szempontot: az envoy dinamikusan állítja be a hallgatókat (IP, port párok), amelyeket elkezd figyelni. Így, amikor a kérések beérkeznek a podba, az iptables átirányító szabályok segítségével a sidecar-ba irányítódnak, az envoy már sikeresen feldolgozhatja ezeket a kapcsolatokat, és megértheti, hová kell továbbítani a forgalmat. Ezen a ponton információt küldünk a Mixer-nek, amelyet később megvizsgálunk, valamint nyomkövetési spans-t küldünk.

Végül egy egész envoy proxy-szerver hálózatot kapunk, amelyet egyetlen pontból (Pilot) tudunk konfigurálni. Minden bejövő és kimenő kérés az envoy-n keresztül halad. Ráadásul csak a TCP forgalmat interceptáljuk. Ez azt jelenti, hogy a Kubernetes szolgáltatás IP-je a kube-dns segítségével UDP-n keresztül oldódik fel anélkül, hogy változna. Azután az árnyékolás után a kimenő kérés elkapása és az envoy általi feldolgozás történik, amely már eldönti, hogy melyik végpont felé küldje a kérést (vagy nem küldi el, a hozzáférési politikák vagy a circuit breaker algoritmus működése esetén).

A Pilot után most meg kell értenünk, hogyan működik a Mixer és mire van szükség. Az erről szóló hivatalos dokumentációt el lehet olvasni itt.

A Mixer jelenlegi formájában két komponensből áll: istio-telemetry és istio-policy (a 0.8-as verzió előtt ez egyetlen komponens volt az istio-mixer). Mindkettő mixer, mindegyik a saját feladatáért felelős. Az Istio telemetry a sidecar konténerektől GRPC-n keresztül fogadja a Report információt arról, hogy ki hová megy és milyen paraméterekkel. Az Istio-policy Check kéréseket fogad a Policy szabályok betartásának ellenőrzésére. A Policy ellenőrzés természetesen nem minden kérésnél történik, hanem a kliensnél (a sidecar-ban) egy bizonyos időre cache-elve van. A Report ellenőrzéseket batch kérésként küldik el. Hogyan kell konfigurálni és milyen pontos paramétereket kell küldeni, azt majd később megnézzük.

A Mixert úgy tervezték, mint egy magas rendelkezésre állású komponenst, amely biztosítja a telemetriai adatok összegyűjtésének és feldolgozásának folyamatos működését. A rendszer így egy többszintű puffert kap. Eredetileg az adatok a sidecar konténerek oldalán kerülnek pufferezésre, majd a Mixer oldalán, és végül a úgynevezett mixer backend-ekbe küldik azokat. Végül, ha a rendszer egyik komponense meghibásodik, a puffer növekszik, és a rendszer helyreállása után kiürül. A Mixer backend-ek a telemetriai adatok küldési végpontjait képviselik: statsd, newrelic stb. Írhatsz saját backend-et, ez elég egyszerű, és meglátjuk, hogyan kell ezt megtenni.

Összefoglalva, az istio-telemetry munkafolyamata a következő.

A szolgáltatás 1 kérést küld a szolgáltatás 2-nek.
A szolgáltatás 1-ből való kilépéskor a kérést a saját sidecar-jébe csomagolja.
A sidecar envoy figyelemmel kíséri, hogyan halad a kérés a szolgáltatás 2 felé, és előkészíti a szükséges információt.
Ezután elküldi azt az istio-telemetry számára egy Report kérés segítségével.
Az istio-telemetry meghatározza, hogy szükséges-e ezt a Reportot a backend-eknek küldeni, melyek a megfelelőek és milyen adatokat kell küldeni.
Az Istio-telemetry jelentéseket küld a backendbe, ha szükséges.

Most nézzük meg, hogyan lehet telepíteni az Istio rendszert, amely csak a fő összetevőkből (Pilot és sidecar envoy) áll.

Először nézzük meg a fő konfigurációt (mesh), amelyet a Pilot olvas:

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

    # egyelőre nem kapcsoljuk be a tracing információk küldését (a pilot úgy konfigurálja az envoyokat, hogy a küldés ne történjen meg)
    enableTracing: false

    # egyelőre nem adjuk meg a mixer végpontokat, hogy a sidecar tárolók ne küldjenek információt oda
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # beállítjuk az időintervallumot, amellyel az envoy újra megkérdezi a Pilotot (ez régi verziójú envoy proxyhoz van)
    rdsRefreshDelay: 5s

    # alapértelmezett konfiguráció az envoy sidecarhoz
    defaultConfig:
      # hasonlóan mint az rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # alapértelmezett (a konfiguráció és az envoy bináris elérési útja)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # alapértelmezett név a futó sidecar tárolónak (például a service nevekben a tracing spanok küldésekor használatos)
      serviceCluster: istio-proxy

      # az az idő, ameddig az envoy várni fog, mielőtt kényszerítve bezárja az összes létesített kapcsolatot
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # alapértelmezés szerint REDIRECT iptables szabályokat használunk. Átállítható TPROXY-ra.
      #interceptionMode: REDIRECT

      # A port, ahol az admin panel fut minden sidecar tárolón (envoy)
      proxyAdminPort: 15000

      # az az cím, ahová a zipkin protokollal küldjük a trace-eket (kezdetben lekapcsoltuk a küldést, ezért ez a mező most nem lesz használva)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd cím a metrics envoy tárolók küldésére (lekapcsolva)
      # statsdUdpAddress: aggregator:8126

      # lekapcsoljuk a Mutual TLS opció támogatását
      controlPlaneAuthPolicy: NONE

      # az a cím, ahol az istio-pilot hallgat, hogy információt adjon a service discovery-ról minden sidecar tárolónak
      discoveryAddress: istio-pilot.istio-system:15007

Az összes fő vezérlőkomponenst (control plane) az istio-system namespace-ben helyezzük el a Kubernetesben.

Minimum szükséges telepítenünk csak a Pilotot. Ehhez használni fogjuk ilyen konfigurációt.

És manuálisan beállítjuk a sidecar tároló injektálását.

Init tároló:

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

És 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

Ahhoz, hogy minden sikeresen elinduljon, létre kell hozni egy ServiceAccount-ot, ClusterRole-t, ClusterRoleBinding-et, majd a Pilot CRD-t, amelyek leírását megtalálhatjuk. itt.

Ennek eredményeként a szolgáltatás, amelybe injectáljuk a sidecart az envoy-jal, sikeresen elindul, megkapja az összes felfedezési adatot a pilotból, és feldolgozza a kéréseket.

Fontos megérteni, hogy a control plane összes komponense stateless alkalmazások, és problémamentesen horizontálisan skálázhatók. Minden adat az etcd-ben helyezkedik el egyedi Kubernetes erőforrás leírások formájában.

Az Istio-nak (jelenleg kísérleti állapotban) van lehetősége a klaszteren kívüli futásra és lehetőség arra, hogy nézzen és ossza meg a szolgáltatás felfedezést több Kubernetes klaszter között. Többet olvashat erről. itt.

Több klaszteres telepítésnél figyelembe kell venni a következő korlátozásokat:

A Pod CIDR és a Service CIDR egyedinek kell lennie az összes klaszter között, és nem ütközhetnek.
Minden Pod CIDR-nek elérhetőnek kell lennie minden Pod CIDR között a klaszterek között.
Minden Kubernetes API szervernek elérhetőnek kell lennie egymás számára.

Ezek az alapvető információk segítenek Önnek elkezdeni dolgozni az Istio-val. Azonban számos buktató is vár Önre. Például a külső forgalom irányításának sajátosságai (a klaszteren kívül), a sidecar-ok hibakeresésének megközelítései, profilképzés, a mixer beállítása és a testreszabott mixer backend írása, a tracing mechanizmus beállítása és az envoy segítségével való működése.
Mind ezt a következő publikációkban meg fogjuk vizsgálni. Kérjük, tegye fel kérdéseit, megpróbálom azokat megválaszolni.

Forrás: habr.com

Hogyan indítsuk el az Istio-t Kubernetes-ben a production környezetben. 1. rész

A működés elve