🥇Jak spustit Istio pomocí Kubernetes v produkci. Část 1

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

O mechanismu fungování si můžete přečíst na oficiální dokumentaci. Istio je opravdu silný nástroj, který řeší mnoho úkolů a problémů. V tomto článku bych chtěl odpovědět na hlavní otázky, které obvykle vyvstávají na začátku práce s Istio. Pomůže vám to rychleji se s ním seznámit.

Princip práce

Istio se skládá ze dvou hlavních zón — control plane a data plane. Control plane obsahuje hlavní komponenty, které zajišťují správnou funkčnost ostatních. V aktuální verzi (1.0) má control plane tři hlavní komponenty: Pilot, Mixer a Citadel. Citadel nebudeme zmiňovat, slouží pro generaci certifikátů k zajištění fungování vzájemného TLS mezi službami. Pojďme se podívat podrobněji na strukturu a účel Pilot a Mixer.

Pilot je hlavní kontrolní komponenta, která šíří všechny informace o tom, co máme v clusteru – služby, jejich endpointy a pravidla routování (například pravidla pro Canary deployment nebo pravidla circuit breaker).

Mixer je volitelná komponenta control plane, která poskytuje možnosti sběru metrik, logů a jakýchkoli informací o síťové interakci. Také sleduje dodržování pravidel Policy a dodržování rate limitů.

Data plane je realizováno pomocí sidecar kontajnerů-proxy. Výchozí konfigurací je výkonný proxy server envoy. Může být nahrazen jinou implementací, například nginx (nginmesh).

Aby Istio fungovalo zcela transparentně pro aplikace, existuje systém automatického injekce. Poslední implementace je vhodná pro verze Kubernetes 1.9+ (mutational admission webhook). Pro verze Kubernetes 1.7 a 1.8 existuje možnost použít Initializer.

Sidecar kontejnery se spojují s Pilotem prostřednictvím protokolu GRPC, který umožňuje optimalizaci modelu pushování změn, které se v clusterech odehrávají. GRPC se začalo používat v Envoy od verze 1.6, v Istio se používá od verze 0.8 a představuje pilot-agent — obálku v golangu nad envoy, která konfiguruje parametry spuštění.

Pilot a Mixer jsou zcela stateless komponenty, všechna data uchovávají v paměti. Konfigurace pro ně je zadávána ve formě Kubernetes Custom Resources, které se ukládají do etcd.
Istio-agent získává adresu Pilota a otevírá GRPC stream k němu.

Jak jsem již uvedl, Istio realizuje veškerou funkčnost zcela transparentně pro aplikace. Pojďme se podívat, jak. Algoritmus je následující:

Deployujeme novou verzi služby.
V závislosti na přístupu k injektování kontejneru sidecar jsou během aplikace konfigurace přidány kontejner istio-init a kontejner istio-agent (envoy), nebo mohou být již ručně vloženy do popisu entity Pod v Kubernetes.
Kontejner istio-init představuje skript, který aplikuje pravidla iptables pro pod. Existují dvě možnosti pro nastavení obalování provozu do kontejneru istio-agent: použít pravidla přesměrování iptables, nebo TPROXY. K okamžiku psaní článku je ve výchozím nastavení používán přístup s pravidly přesměrování. V istio-init je možné nastavit, jaký konkrétní provoz má být odchytáván a směrován do istio-agent. Například, aby bylo možné odchytit celý příchozí a odchozí provoz, je potřeba nastavit parametry -i a -b na hodnotu *. Můžete také specifikovat konkrétní porty, které by měly být odchytávány. Pokud nechcete odchytávat určitou podsíť, můžete ji uvést pomocí příznaku -x.
Po vykonání init kontejnerů se spouští hlavní kontejnery, včetně pilot-agent (envoy). Ten se připojuje k již nasazenému Pilotovi přes GRPC a získává informace o všech existujících službách a pravidlech směrování v clusterech. Na základě těchto údajů konfiguruje clustery a zapisuje do nich přímo endpointy našich aplikací v Kubernetes clusteru. Je také důležité poznamenat, že envoy dynamicky nastavuje listenery (páry IP, port), které začne naslouchat. Proto, když požadavky vstupují do podu, jsou přesměrovány pomocí pravidel přesměrování iptables do sidecaru, envoy je již úspěšně schopen zpracovávat tato spojení a chápat, kam je třeba dále směrovat provoz. Také v této fázi dochází k odeslání informací do Mixera, který probereme později, a k odeslání tracing spanů.

Nakonec získáme celou síť proxy serverů envoy, které můžeme konfigurovat z jednoho místa (Pilot). Všechny příchozí a odchozí požadavky procházejí přes envoy. Přitom je odchytáván pouze TCP provoz. To znamená, že Kubernetes service IP je resolvována pomocí kube-dns přes UDP bez změny. Poté, co dojde k resolvování, je proveden odchyt odchozího požadavku a zpracovává ho envoy, který již rozhoduje, na který endpoint má požadavek odeslat (nebo neodeslat, v případě přístupových politik nebo aktivace algoritmu circuit breaker).

S Pilotem jsme se seznámili, nyní je potřeba pochopit, jak Mixer funguje a proč je potřeba. Oficiální dokumentaci k němu si můžete přečíst. tady.

Mixer v současné podobě představuje dva komponenty: istio-telemetry a istio-policy (do verze 0.8 to byl jeden komponent istio-mixer). Oba představují mixer, přičemž každý z nich se zodpovídá za svou úlohu. Istio telemetry přijímá přes GRPC od sidecar kontejnerů Report informace o tom, kdo kam jde a s jakými parametry. Istio-policy přijímá Check dotazy pro ověření splnění pravidel Policy. Kontroly Policy se samozřejmě neprovádějí na každý dotaz, ale ukládají se na klientovi (v sidecar) na určitou dobu. Report kontroly se odesílají v dávkách. Jak nastavit a jaké konkrétní parametry je třeba posílat, podíváme se později.

Mixer je navržen jako vysoce dostupná komponenta, která zajištuje nepřetržitou práci při sběru a zpracování telemetry dat. Systém tak funguje jako vícestupňový buffer. Nejprve se data ukládají na straně sidecar kontejnerů, poté na straně mixer a poté se odesílají do tzv. mixer backendů. Pokud nějaká komponenta systému selže, buffer se zvětšuje a po obnovení systému se vyprázdní. Mixer backendy představují koncové body pro odesílání dat o telemetrii: statsd, newrelic atd. Lze napsat vlastní backend, což je poměrně jednoduché, a my se podíváme, jak na to.

Pokud shrneme, schéma práce s istio-telemetry je následující.

Služba 1 posílá dotaz do služby 2.
Při opuštění služby 1 je dotaz zabalen do jeho vlastního sidecaru.
Sidecar envoy sleduje, jak dotaz prochází do služby 2, a připravuje potřebné informace.
Poté je odesílá do istio-telemetry pomocí Report požadavku.
Istio-telemetry určuje, zda je třeba tento Report odeslat do backendů, do kterých a jaká data je třeba posílat.
Istio-telemetry odesílá Report data do backendu, pokud je to nutné.

Nyní se podívejme, jak nasadit systém Istio, složený pouze z hlavních komponent (Pilot a sidecar envoy).

Nejprve se podíváme na hlavní konfiguraci (mesh), kterou Pilot čte:

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

    # prozatím nezapínáme odesílání tracing informací (pilot nastaví envoye tak, že odesílání nebude probíhat)
    enableTracing: false

    # prozatím neuvádíme mixer endpointy, aby sidecar kontejnery neposílaly informace tam
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # nastavujeme časový interval, s kterým bude envoy opětovně dotazovat Pilota (to je pro starou verzi envoy proxy)
    rdsRefreshDelay: 5s

    # výchozí konfigurace pro envoy sidecar
    defaultConfig:
      # analogicky jako rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # ponecháváme podle defaultu (cesta k konfiguraci a binárnímu souboru envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # výchozí název spuštěného sidecar kontejneru (používá se například v názvech služeb při odesílání tracing spanů)
      serviceCluster: istio-proxy

      # čas, který bude envoy čekat před tím, než násilně ukončí všechna navázaná spojení
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # podle defaultu se používají pravidla REDIRECT iptables. Můžete změnit na TPROXY.
      #interceptionMode: REDIRECT

      # Port, na kterém bude spuštěna administrátorská panel pro každý sidecar kontejner (envoy)
      proxyAdminPort: 15000

      # adresa, na kterou budou odesílány trace podle zipkin protokolu (na začátku jsme odesílání vypnuli, takže toto pole nyní nebude používáno)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd adresa pro odesílání metrik envoy kontejnerů (vypínáme)
      # statsdUdpAddress: aggregator:8126

      # vypínáme podporu možnosti Mutual TLS
      controlPlaneAuthPolicy: NONE

      # adresa, na které bude poslouchat istio-pilot, aby mohl informovat všechny sidecar kontejnery o objevování služeb
      discoveryAddress: istio-pilot.istio-system:15007

Všechny hlavní komponenty řídícího prostoru (control plane) umístíme do namespace istio-system v Kubernetes.

Minimálně potřebujeme nasadit pouze Pilota. K tomu využijeme takovou konfiguraci.

A nastavíme ručně injecting sidecar kontejneru.

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

A sidecar:

       název: 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 se vše úspěšně spustilo, je nutné vytvořit ServiceAccount, ClusterRole, ClusterRoleBinding a CRD pro Pilot, jejichž popisy lze nalézt. tady.

V důsledku toho by služba, do které injikujeme sidecar s envoy, měla úspěšně běžet, získat všechny informace o objevech z pilota a zpracovávat požadavky.

Je důležité pochopit, že všechny komponenty control plane jsou stateless aplikace a mohou být bez problémů horizontálně škálovány. Všechna data jsou uložena v etcd ve formě vlastních popisů zdrojů Kubernetes.

Istio také (zatím experimentálně) umožňuje spuštění mimo cluster a možnost sledovat a sdílet objevování služeb mezi několika Kubernetes clustery. Podrobnosti si můžete přečíst. tady.

Při vícero clustrové instalaci je třeba vzít v úvahu následující omezení:

Pod CIDR a Service CIDR musí být jedinečné pro všechny clustery a nesmí se překrývat.
Všechny Pod CIDR musí být přístupné z jakýchkoliv Pod CIDR mezi clustery.
Všechny servery API Kubernetes musí být navzájem přístupné.

To jsou základní informace, které vám pomohou začít pracovat s Istio. Existuje však ještě řada problémů, například detaily směrování externího provozu (ven z clusteru), přístupy k ladění sidecar, profilování, nastavení mixeru a psaní vlastního backendu mixeru, nastavení mechanismu sledování a jeho práce pomocí envoy.
To vše prozkoumáme v následujících publikacích. Ptej se na své otázky, pokusím se je osvětlit.

Zdroj: habr.com