🥇Ako spustiť Istio pomocou Kubernetes v produkcii. Časť 1

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

O mechanizme fungovania si môžete prečítať v oficiálnej dokumentácii. Istio je naozaj mocný nástroj, ktorý dokáže vyriešiť množstvo úloh a problémov. V tomto článku by som chcel odpovedať na základné otázky, ktoré sa zvyčajne objavujú na začiatku práce s Istio. Pomôže vám to rýchlejšie sa zorientovať.

Princíp fungovania

Istio sa skladá z dvoch hlavných zón - control plane a data plane. Control plane obsahuje hlavné komponenty, ktoré zabezpečujú správnu činnosť ďalších. V aktuálnej verzii (1.0) má control plane tri hlavné komponenty: Pilot, Mixer, Citadel. Citadel nebudeme rozoberať, je potrebný na generovanie certifikátov na zabezpečenie vzájomného TLS medzi službami. Poďme sa podrobnejšie pozrieť na štruktúru a účel Pilot a Mixer.

Pilot je hlavný správcovský komponent, ktorý šíri všetky informácie o tom, čo máme v klastre – služby, ich koncové body a routing pravidlá (napríklad pravidlá pre Canary deployment alebo pravidlá circuit breaker).

Mixer je voliteľný komponent control plane, ktorý ponúka možnosť zberu metrik, logov a akýchkoľvek informácií o sieťovej interakcii. Rovnako monitoruje dodržiavanie pravidiel Policy a dodržiavanie limitov počtu požiadaviek.

Data plane je implementovaný pomocou sidecar kontajnerov-proxy. Predvoleným proxy-serverom je výkonný proxy server envoy. Môže byť nahradený inou implementáciou, napríklad nginx (nginmesh).

Aby Istio fungoval úplne transparentne pre aplikácie, existuje systém automatického injektovania. Posledná implementácia vyhovuje verziám Kubernetes 1.9+ (mutational admission webhook). Pre verzie Kubernetes 1.7 a 1.8 je možné použiť Initializer.

Sidecar kontajnery sa spájajú s Pilotom prostredníctvom protokolu GRPC, ktorý umožňuje optimalizáciu modelu pushovania zmien prebiehajúcich v klastre. GRPC sa začal používať v Envoy od verzie 1.6, v Istio sa používa od verzie 0.8 a predstavuje pilot-agent — obal na golang nad envoy, ktorý konfiguruje spúšťacie parametre.

Pilot a Mixer sú úplne stateless komponenty, všetko stavové informácie uchovávajú v pamäti. Konfigurácia pre nich sa určuje vo forme Kubernetes Custom Resources, ktoré sa ukladajú v etcd.
Istio-agent získa adresu Pilota a otvorí GRPC stream k nemu.

Ako som už povedal, Istio realizuje všetku funkcionalitu úplne transparentne pre aplikácie. Pozrime sa, ako. Algoritmus je nasledujúci:

Nasadíme novú verziu služby.
V závislosti od prístupu injectingu sa na fáze uplatnenia konfigurácie pridávajú istio-init kontajner a istio-agent kontajner (envoy), alebo môžu byť už manuálne vložené do popisu Pod entity Kubernetes.
istio-init kontajner predstavuje skript, ktorý aplikuje pravidlá iptables pre pod. Existujú dva varianty nastavenia obalovania trafficu do istio-agent kontajnera: používať redirect pravidlá iptables, alebo TPROXY. V čase písania článku sa predvolene používa prístup s redirect pravidlami. V istio-init je možnosť nastaviť, aký konkrétny traffic je potrebné zachytiť a nasmerovať do istio-agent. Napríklad, ak chcete zachytiť celý prichádzajúci a celý odchádzajúci traffic, je potrebné nastaviť parametre -i a -b na hodnotu *. Môžete uviesť konkrétne porty, ktoré je potrebné zachytiť. Aby ste nezachytávali určitú podsiete, môžete ju uviesť pomocou príznaku -x.
Po vykonaní init kontajnerov sa spustia hlavné, vrátane pilot-agent (envoy). Ten sa pripojí k už nasadenému Pilot cez GRPC a získava informácie o všetkých existujúcich službách a routing politikách v klastri. Na základe získaných údajov konfiguruje clustery a zapisuje im priamo endpointy našich aplikácií v Kubernetes klastri. Tiež je potrebné poznamenať dôležitý moment: envoy dynamicky konfiguruje listeners (páry IP, port), ktoré začína počúvať. Preto, keď sa požiadavky dostanú do podu, sú preposielané pomocou redirect iptables pravidiel do sidecar, envoy už úspešne môže spracovávať tieto spojenia a chápať, kam je potrebné ďalej proxy trafik. Taktiež v tomto štádiu dochádza k odoslaniu informácií do Mixeru, ktorý preskúmame neskôr, a k odoslaniu sledovania spanov.

Na konci dostaneme celú sieť envoy proxy serverov, ktoré môžeme nastavovať z jedného bodu (Pilot). Všetky inbound a outbound požiadavky prechádzajú cez envoy. Práve, zachytáva sa iba TCP traffic. To znamená, že Kubernetes service IP sa rieši pomocou kube-dns cez UDP bez zmien. Potom už po vyriešení dochádza k zachyteniu odchádzajúcej požiadavky a spracovaniu envoyom, ktorý už rozhoduje, na ktorý endpoint je potrebné požiadavku odoslať (alebo neodoslať, v prípade prístupových politík alebo aktivácie circuit breaker algoritmu).

S Pilotom sme sa vysporiadali, teraz treba pochopiť, ako funguje Mixer a prečo je potrebný. Oficiálnu dokumentáciu k nemu si môžete prečítať tu.

Mixer v súčasnej podobe pozostáva z dvoch komponentov: istio-telemetry a istio-policy (do verzie 0.8 to bol jeden komponent istio-mixer). Oba predstavujú mixer, pričom každý z nich plní svoju úlohu. Istio telemetry prijíma prostredníctvom GRPC od sidecar kontajnerov Report informácie o tom, kto kam ide a s akými parametrami. Istio-policy prijíma Check požiadavky na overenie splnenia pravidiel politiky. Kontroly politiky sa samozrejme nevykonávajú na každú požiadavku, ale ukladajú sa na strane klienta (v sidecar) na určitý čas. Report kontroly sa odosielajú dávkovými požiadavkami. Ako nastaviť a aké presné parametre je potrebné odosielať, si ukážeme neskôr.

Mixer sa predpokladá ako vysoko dostupná zložka, ktorá zabezpečuje plynulú prevádzku pri zbieraní a spracovaní telemetrických údajov. Systém v konečnom dôsledku funguje ako viacúrovňový buffer. Údaje sa zpočiatku ukladajú na strane sidecar kontajnerov, potom na strane mixeru a následne sa odosielajú do takzvaných mixer backendov. Nakoniec, ak niektorá z komponentov systému zlyhá, buffer sa zväčšuje a po obnovení systému sa vyprázdňuje. Mixer backendy predstavujú koncové body na odosielanie telemetrických údajov: statsd, newrelic a pod. Je možné napísať vlastný backend, čo je dosť jednoduché, a ukážeme si, ako to urobiť.

Ak by sme to zhrnuli, schéma práce s istio-telemetry je takáto.

Služba 1 posiela požiadavku na službu 2.
Pri odchode zo služby 1 sa požiadavka zabalí do jej vlastného sidecaru.
Sidecar envoy sleduje, ako prebieha požiadavka na službu 2 a pripravuje potrebné informácie.
Následne ich odosiela do istio-telemetry prostredníctvom Report požiadavky.
Istio-telemetry určuje, či je potrebné odoslať tento Report do backendov, ktoré konkrétne a aké údaje je potrebné poslať.
Istio-telemetry odosiela Report údaje do backendu, ak je to potrebné.

Teraz sa pozrime, ako rozvinúť v systéme Istio, ktorý sa skladá len z hlavných komponentov (Pilot a sidecar envoy).

Najprv sa pozrime na základnú konfiguráciu (mesh), ktorú číta Pilot:

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

    # zatiaľ neaktivujeme odosielanie tracing informácií (pilot nastaví envoye tak, že odosielanie nebude prebiehať)
    enableTracing: false

    # zatiaľ neuvádzame mixer endpointy, aby sidecar kontajnery neodosielali informácie tam
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # nastavujeme časový interval, s ktorým bude envoy opätovne žiadať Pilot (to je pre starú verziu envoy proxy)
    rdsRefreshDelay: 5s

    # defaultná konfigurácia pre envoy sidecar
    defaultConfig:
      # analogicky ako rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # ponechávame predvolené (cesta k konfigurácii a bináru envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # predvolené meno spusteného sidecar kontajnera (používa sa, napríklad, v názvoch služieb pri odosielaní tracing spanov)
      serviceCluster: istio-proxy

      # čas, ktorý bude čakať envoy predtým, než nútene ukončí všetky vytvorené spojenia
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # predvolene sa používajú REDIRECT pravidlá iptables. Môžete zmeniť na TPROXY.
      #interceptionMode: REDIRECT

      # Port, na ktorom sa spustí admin panel každého sidecar kontajnera (envoy)
      proxyAdminPort: 15000

      # adresa, na ktorú sa budú odosielať trace podľa zipkin protokolu (na začiatku sme odosielanie vypli, preto sa toto pole teraz nebude používať)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd adresa na odosielanie metrik envoy kontajnerov (vypíname)
      # statsdUdpAddress: aggregator:8126

      # vypíname podporu možnosti Mutual TLS
      controlPlaneAuthPolicy: NONE

      # adresa, na ktorej bude počúvať istio-pilot, aby informoval o objavovaní služieb všetky sidecar kontajnery
      discoveryAddress: istio-pilot.istio-system:15007

Všetky hlavné komponenty správy (control plane) umiestnime do namespacu istio-system v Kubernetes.

Minimálne potrebujeme nasadiť iba Pilot. Na to využijeme takúto konfiguráciu.

A manuálne nastavíme injekciu sidecar kontajnera.

Init kontajner:

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

A 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

Aby sa všetko úspešne spustilo, je potrebné vytvoriť ServiceAccount, ClusterRole, ClusterRoleBinding a CRD pre Pilot, ktorých popisy nájdete. tu.

Služba, do ktorej injektujeme sidecar s envoy, by mala úspešne nabehnúť, získať celý discovery z pilota a spracovávať požiadavky.

Je dôležité pochopiť, že všetky komponenty control plane sú aplikácie bez stavu a je možné ich bez problémov horizontálne škálovať. Všetky údaje sú uložené v etcd vo forme prispôsobených popisov zdrojov Kubernetes.

Istio (zatiaľ experimentálne) tiež umožňuje spustenie mimo klaster a zdieľanie služby discovery medzi viacerými Kubernetes klastrami. Viac informácií si môžete prečítať. tu.

Pri multi-klastrovom nasadení je potrebné zohľadniť nasledujúce obmedzenia:

Pod CIDR a Service CIDR musia byť jedinečné vo všetkých klastroch a nesmú sa prekryť.
Všetky Pod CIDR musia byť prístupné z akýchkoľvek Pod CIDR medzi klastrami.
Všetky Kubernetes API servery musia byť navzájom prístupné.

Toto sú základné informácie, ktoré vám pomôžu začať pracovať s Istio. Existuje však ešte množstvo úskalí. Napríklad, špecifiká routovania vonkajšieho prenosu (mimo klaster), prístupy k ladení sidecar-ov, profilovanie, konfigurácia mixer a písanie vlastného mixer backendu, nastavenie sledovacieho mechanizmu a jeho fungovanie pomocou envoy.
Všetko toto si podrobne prejdeme v nasledujúcich publikáciách. Kládite vaše otázky, pokúsim sa ich objasniť.

Zdroj: habr.com

Ako spustiť Istio s využitím Kubernetes v produkcii. Časť 1

Princíp fungovania