ProHoster > Блог > Administracija > Kako pokrenuti Istio koristeći Kubernetes u produkciji. Dio 1

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

šta Istio? Ovo je takozvana Service mesh, tehnologija koja dodaje sloj apstrakcije preko mreže. Presrećemo sav ili dio prometa u klasteru i s njim izvodimo određeni skup operacija. Koji? Na primjer, radimo pametno usmjeravanje ili implementiramo pristup prekidača, možemo organizirati „kanarsku implementaciju“, djelomično prebacivanje prometa na novu verziju usluge, ili možemo ograničiti vanjske interakcije i kontrolirati sva putovanja od klastera do eksternu mrežu. Moguće je postaviti pravila politike za kontrolu putovanja između različitih mikroservisa. Konačno, možemo dobiti cijelu mapu mrežnih interakcija i učiniti jedinstvenu kolekciju metrika potpuno transparentnom za aplikacije.

O mehanizmu rada možete pročitati u službena dokumentacija. Istio je zaista moćan alat koji vam omogućava da riješite mnoge zadatke i probleme. U ovom članku želio bih odgovoriti na glavna pitanja koja se obično javljaju kada počnete s Istiom. To će vam pomoći da se brže nosite s tim.

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

Kako to radi

Istio se sastoji od dvije glavne oblasti - kontrolne ravni i ravni podataka. Upravljačka ravnina sadrži glavne komponente koje osiguravaju ispravan rad ostalih. U trenutnoj verziji (1.0) upravljački plan ima tri glavne komponente: Pilot, Mixer, Citadel. Citadel nećemo razmatrati, potrebno je generirati certifikate kako bi se osigurao međusobni TLS između servisa. Pogledajmo bliže uređaj i svrhu Pilota i Mixera.

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

Pilot je glavna kontrolna komponenta koja distribuira sve informacije o onome što imamo u klasteru - uslugama, njihovim krajnjim tačkama i pravilima rutiranja (na primjer, pravila za Canary implementaciju ili pravila prekidača).

Mikser je opciona komponenta kontrolne ravni koja pruža mogućnost prikupljanja metrike, evidencije i svih informacija o mrežnoj interakciji. On također prati usklađenost s pravilima Politike i poštivanje ograničenja stope.

Ravan podataka se implementira pomoću proxy kontejnera bočnih kolica. Powerful se koristi po defaultu. punomoćnik izaslanika. Može se zamijeniti drugom implementacijom, kao što je nginx (nginmesh).

Da bi Istio radio potpuno transparentno za aplikacije, postoji sistem automatskog ubrizgavanja. Najnovija implementacija je prikladna za Kubernetes 1.9+ verzije (mutational admission webhook). Za Kubernetes verzije 1.7, 1.8 moguće je koristiti inicijalizator.

Kontejneri s bočnim kolima su povezani s Pilotom pomoću GRPC protokola, koji vam omogućava da optimizirate push model za promjene koje se dešavaju u klasteru. GRPC se koristi u Envoy-u od verzije 1.6, u Istio-u se koristi od verzije 0.8 i predstavlja pilot-agent - golang omotač preko izaslanika koji konfigurira opcije pokretanja.

Pilot i Mixer su komponente bez stanja, sva stanja se čuvaju u memoriji. Konfiguracija za njih je postavljena u obliku Kubernetes prilagođenih resursa, koji su pohranjeni u etcd.
Istio-agent dobija adresu pilota i otvara GRPC tok na nju.

Kao što sam rekao, Istio implementira svu funkcionalnost potpuno transparentno za aplikacije. Da vidimo kako. Algoritam je ovaj:

  1. Uvođenje nove verzije usluge.
  2. Ovisno o pristupu ubrizgavanja bočnog kontejnera, istio-init kontejner i istio-agent kontejner (izaslanik) se dodaju u fazi primjene konfiguracije ili se već mogu ručno umetnuti u opis entiteta Kubernetes Pod.
  3. Kontejner istio-init je skripta koja primjenjuje iptables pravila na pod. Postoje dvije opcije za konfiguriranje prometa koji će biti umotan u istio-agent kontejner: koristite pravila preusmjeravanja iptables ili TPROXY. U vrijeme pisanja, zadani pristup je s pravilima preusmjeravanja. U istio-init, moguće je konfigurirati koji promet treba presresti i poslati istio-agentu. Na primjer, da biste presreli sav dolazni i sav odlazni promet, trebate podesiti parametre -i и -b u značenje *. Možete odrediti određene portove za presretanje. Kako ne biste presreli određenu podmrežu, možete je odrediti pomoću zastavice -x.
  4. Nakon što se init kontejneri izvrše, pokreću se glavni, uključujući pilot-agenta (izaslanika). Povezuje se na već raspoređeni Pilot preko GRPC-a i prima informacije o svim postojećim uslugama i politikama rutiranja u klasteru. Prema primljenim podacima, on konfiguriše klastere i dodeljuje ih direktno krajnjim tačkama naših aplikacija u Kubernetes klasteru. Također je potrebno napomenuti važnu stvar: envoy dinamički konfigurira slušaoce (IP, parovi portova) koje počinje slušati. Stoga, kada zahtjevi uđu u pod, budu preusmjereni korištenjem redirect iptables pravila u sidecaru, izaslanik već može uspješno obraditi ove veze i razumjeti gdje dalje proxy promet. Takođe u ovoj fazi, informacije se šalju u mikser, koji ćemo kasnije pogledati, i šalju se rasponi praćenja.

Kao rezultat, dobijamo čitavu mrežu proxy servera izaslanika koje možemo konfigurisati iz jedne tačke (Pilot). Svi dolazni i odlazni zahtjevi prolaze preko izaslanika. Štaviše, presreće se samo TCP saobraćaj. To znači da se IP Kubernetes servisa rješava korištenjem kube-dns-a preko UDP-a bez promjene. Zatim, nakon rješavanja, odlazni zahtjev presreće i obrađuje izaslanik, koji već odlučuje na koju krajnju tačku zahtjev treba poslati (ili ne poslati, u slučaju politika pristupa ili prekidača algoritma).

Shvatili smo Pilot, sada moramo razumjeti kako Mixer radi i zašto je potreban. Možete pročitati zvaničnu dokumentaciju za to ovdje.

Mikser u svom sadašnjem obliku sastoji se od dvije komponente: istio-telemetrija, istio-policy (prije verzije 0.8 bio je jedna komponenta istio-miksera). Obojica su mikseri, od kojih je svaki odgovoran za svoj zadatak. Istio telemetrija prima informacije o tome ko ide kamo i sa kojim parametrima iz kontejnera za izvještaje bočnih prikolica putem GRPC-a. Istio-policy prihvaća zahtjeve za provjeru kako bi se potvrdilo da su pravila Politike zadovoljena. Provjere pravila se, naravno, ne provode za svaki zahtjev, već se keširaju na klijentu (u sporednoj prikolici) određeno vrijeme. Provjere izvještaja se šalju kao paketni zahtjevi. Da vidimo kako konfigurirati i koje parametre treba poslati malo kasnije.

Mikser bi trebao biti visoko dostupna komponenta koja osigurava neprekidan rad na sastavljanju i obradi telemetrijskih podataka. Sistem se dobija kao rezultat kao bafer na više nivoa. U početku se podaci baferuju na bočnoj strani kontejnera, zatim na strani miksera, a zatim se šalju u takozvane pozadinske strane miksera. Kao rezultat toga, ako bilo koja od komponenti sistema pokvari, bafer raste i ispire se nakon što se sistem vrati. Pozadine miksera su krajnje tačke za slanje telemetrijskih podataka: statsd, newrelic, itd. Možete napisati svoj vlastiti backend, prilično je jednostavan, a mi ćemo vidjeti kako to učiniti.

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

Da rezimiramo, shema za rad sa istio-telemetrijom je sljedeća.

  1. Usluga 1 šalje zahtjev servisu 2.
  2. Prilikom napuštanja usluge 1, zahtjev je umotan u vlastitu prikolicu.
  3. Izaslanik prikolice prati kako zahtjev ide do servisa 2 i priprema potrebne informacije.
  4. Zatim ga šalje istio-telemetriji koristeći zahtjev za izvješće.
  5. Istio-telemetrija određuje da li ovaj Izvještaj treba poslati backend-u, kome i koje podatke treba poslati.
  6. Istio-telemetrija šalje podatke izvještaja backendu ako je potrebno.

Sada da vidimo kako da implementiramo Istio u sistem, koji se sastoji samo od glavnih komponenti (Pilot i izaslanik prikolice).

Prvo, pogledajmo glavnu konfiguraciju (mesh) koju Pilot čita:

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

    # пока что не включаем отправку tracing информации (pilot настроит envoy’и таким образом, что отправка не будет происходить)
    enableTracing: false

    # пока что не указываем mixer endpoint’ы, чтобы sidecar контейнеры не отправляли информацию туда
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # ставим временной промежуток, с которым будет envoy переспрашивать Pilot (это для старой версии envoy proxy)
    rdsRefreshDelay: 5s

    # default конфигурация для envoy sidecar
    defaultConfig:
      # аналогично как rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # оставляем по умолчанию (путь к конфигурации и бинарю envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # дефолтное имя запущенного sidecar контейнера (используется, например, в именах сервиса при отправке tracing span’ов)
      serviceCluster: istio-proxy

      # время, которое будет ждать envoy до того, как он принудительно завершит все установленные соединения
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # по умолчанию используются REDIRECT правила iptables. Можно изменить на TPROXY.
      #interceptionMode: REDIRECT

      # Порт, на котором будет запущена admin панель каждого sidecar контейнера (envoy)
      proxyAdminPort: 15000

      # адрес, по которому будут отправляться trace’ы по zipkin протоколу (в начале мы отключили саму отправку, поэтому это поле сейчас не будет использоваться)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd адрес для отправки метрик envoy контейнеров (отключаем)
      # statsdUdpAddress: aggregator:8126

      # выключаем поддержку опции Mutual TLS
      controlPlaneAuthPolicy: NONE

      # адрес, на котором будет слушать istio-pilot для того, чтобы сообщать информацию о service discovery всем sidecar контейнерам
      discoveryAddress: istio-pilot.istio-system:15007

Sve glavne kontrolne komponente (kontrolna ravan) će se nalaziti u imenskom prostoru istio-sistema u Kubernetesu.

Kao minimum, potrebno je samo da rasporedimo Pilot. Za ovo koristimo takva konfiguracija.

A mi ćemo ručno konfigurirati bočnu prikolicu za ubrizgavanje kontejnera.

Init kontejner:

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

I bočna prikolica:

       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

Da bi sve uspješno započelo potrebno je da kreirate ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot čije opise možete pronaći ovdje.

Kao rezultat toga, usluga u koju ubacujemo sidecar sa izaslanikom trebala bi uspješno započeti, primiti sva otkrića od pilota i obraditi zahtjeve.

Važno je shvatiti da su sve komponente upravljačke ravni aplikacije bez stanja i da se mogu horizontalno skalirati bez problema. Svi podaci se pohranjuju u etcd u obliku prilagođenih opisa Kubernetes resursa.

Također, Istio (još uvijek eksperimentalni) ima mogućnost pokretanja izvan klastera i mogućnost gledanja i petljanja otkrivanja servisa između nekoliko Kubernetes klastera. Možete pročitati više o tome ovdje.

Za instalaciju s više klastera, imajte na umu sljedeća ograničenja:

  1. Pod CIDR i Service CIDR moraju biti jedinstveni u svim klasterima i ne smiju se preklapati.
  2. Svi CIDR moduli moraju biti dostupni iz bilo kojeg CIDR modula između klastera.
  3. Svi Kubernetes API serveri moraju biti dostupni jedni drugima.

Ovo su početne informacije koje će vam pomoći da počnete s Istiom. Međutim, još uvijek postoje mnoge zamke. Na primjer, karakteristike rutiranja vanjskog prometa (izvan klastera), pristupi otklanjanju grešaka sporednih kola, profiliranje, postavljanje miksera i pisanje prilagođenog miksera pozadinskog dijela, postavljanje mehanizma praćenja i njegov rad pomoću envoy-a.
Sve to ćemo razmotriti u sljedećim publikacijama. Postavljajte svoja pitanja, pokušaću da ih pokrijem.

izvor: www.habr.com

Dodajte komentar