ProHoster > Blog > administrasie > Hoe om Istio te laat loop met Kubernetes in produksie. Deel 1

Hoe om Istio te laat loop met Kubernetes in produksie. Deel 1

Wat is Istio? Dit is die sogenaamde Service mesh, 'n tegnologie wat 'n laag van abstraksie oor die netwerk voeg. Ons onderskep die hele of 'n deel van die verkeer in die groep en voer 'n sekere stel bewerkings daarmee uit. Watter een? Ons doen byvoorbeeld slim roetering, of ons implementeer die stroombrekerbenadering, ons kan "kanarie-ontplooiing" organiseer, verkeer gedeeltelik oorskakel na 'n nuwe weergawe van die diens, of ons kan eksterne interaksies beperk en alle ritte van die groep na die eksterne netwerk. Dit is moontlik om beleidsreëls op te stel om ritte tussen verskillende mikrodienste te beheer. Laastens kan ons die hele netwerkinteraksiekaart kry en die verenigde versameling statistieke heeltemal deursigtig vir toepassings maak.

Jy kan lees oor die meganisme van werk in amptelike dokumentasie. Istio is 'n baie kragtige instrument waarmee u baie take en probleme kan oplos. In hierdie artikel wil ek graag die hoofvrae beantwoord wat gewoonlik ontstaan ​​wanneer u met Istio begin. Dit sal jou help om dit vinniger te hanteer.

Hoe om Istio te laat loop met Kubernetes in produksie. Deel 1

Beginsel van werking

Istio bestaan ​​uit twee hoofareas - die beheervlak en die datavlak. Die beheervlak bevat die hoofkomponente wat die korrekte werking van die res verseker. In die huidige weergawe (1.0) het die beheervliegtuig drie hoofkomponente: Pilot, Mixer, Citadel. Ons sal nie Citadel oorweeg nie, dit is nodig om sertifikate te genereer om wedersydse TLS tussen dienste te verseker. Kom ons kyk van naderby na die toestel en doel van Pilot and Mixer.

Hoe om Istio te laat loop met Kubernetes in produksie. Deel 1

Pilot is die hoofbeheerkomponent wat al die inligting versprei oor wat ons in die groep het - dienste, hul eindpunte en roetereëls (byvoorbeeld reëls vir Kanarie-ontplooiing of stroombrekerreëls).

Menger is 'n opsionele beheervlakkomponent wat die vermoë bied om statistieke, logs en enige inligting oor netwerkinteraksie in te samel. Hy monitor ook die nakoming van beleidsreëls en die nakoming van tarieflimiete.

Die datavlak word geïmplementeer met behulp van sidecar-instaanbedienerhouers. Kragtig word by verstek gebruik. gesant gevolmagtigde. Dit kan vervang word deur 'n ander implementering, soos nginx (nginmesh).

Om Istio heeltemal deursigtig vir toepassings te laat werk, is daar 'n outomatiese inspuitingstelsel. Die nuutste implementering is geskik vir Kubernetes 1.9+ weergawes (mutasie-toelatingswebhaak). Vir Kubernetes weergawes 1.7, 1.8 is dit moontlik om die Inisialiseerder te gebruik.

Syspanhouers word aan Pilot gekoppel deur die GRPC-protokol te gebruik, wat jou toelaat om die stootmodel te optimaliseer vir veranderinge wat in die groepie plaasvind. GRPC word sedert weergawe 1.6 in Envoy gebruik, in Istio is dit sedert weergawe 0.8 gebruik en is 'n loodsagent - 'n golang-omhulsel oor envoy wat bekendstellingsopsies konfigureer.

Pilot en Mixer is heeltemal staatlose komponente, alle toestande word in die geheue gehou. Die konfigurasie vir hulle is ingestel in die vorm van Kubernetes Custom Resources, wat in etcd gestoor word.
Istio-agent kry die vlieënier se adres en maak 'n GRPC-stroom daarvoor oop.

Soos ek gesê het, implementeer Istio alle funksionaliteit heeltemal deursigtig vir toepassings. Kom ons kyk hoe. Die algoritme is dit:

  1. Ontplooi tans 'n nuwe weergawe van die diens.
  2. Afhangende van die syspanhouer-inspuitbenadering, word die istio-init-houer en die istio-agent-houer (gesant) bygevoeg op die stadium van toepassing van die konfigurasie, of hulle kan reeds met die hand in die beskrywing van die Kubernetes Pod-entiteit ingevoeg word.
  3. Die istio-init-houer is 'n skrip wat die iptables-reëls op die peul toepas. Daar is twee opsies om verkeer op te stel om in 'n istio-agent-houer toegedraai te word: gebruik iptables-herleidingreëls, of TPROXY. By die skryf hiervan is die verstekbenadering met herleidingreëls. In istio-init is dit moontlik om op te stel watter verkeer onderskep moet word en na istio-agent gestuur moet word. Byvoorbeeld, om alle inkomende en alle uitgaande verkeer te onderskep, moet jy die parameters stel -i и -b tot betekenis *. Jy kan spesifieke poorte spesifiseer om te onderskep. Om nie 'n spesifieke subnet te onderskep nie, kan jy dit spesifiseer met die vlag -x.
  4. Nadat die inithouers uitgevoer is, word die belangrikstes van stapel gestuur, insluitend die vlieënier-agent (gesant). Dit koppel aan die reeds ontplooide Pilot via GRPC en ontvang inligting oor alle bestaande dienste en roeteringsbeleide in die cluster. Volgens die data wat ontvang is, konfigureer hy die groepe en wys dit direk aan die eindpunte van ons toepassings in die Kubernetes-kluster toe. Dit is ook nodig om op 'n belangrike punt te let: gesant stel luisteraars (IP, poortpare) dinamies op waarna dit begin luister. Daarom, wanneer versoeke die pod binnekom, herlei word deur gebruik te maak van die redirect iptables-reëls in die syspan, kan die gesant reeds hierdie verbindings suksesvol verwerk en verstaan ​​waar om die verkeer verder te proxy. Ook op hierdie stadium word inligting na die menger gestuur, waarna ons later sal kyk, en naspeurspanne word gestuur.

As gevolg hiervan kry ons 'n hele netwerk van gesant-instaanbedieners wat ons vanaf een punt (Pilot) kan konfigureer. Alle inkomende en uitgaande versoeke gaan deur gesant. Boonop word slegs TCP-verkeer onderskep. Dit beteken dat Kubernetes-diens-IP opgelos word met kube-dns oor UDP sonder om te verander. Dan, na die besluit, word die uitgaande versoek onderskep en verwerk deur gesant, wat reeds besluit na watter eindpunt die versoek gestuur moet word (of nie gestuur word nie, in die geval van toegangsbeleide of die stroombreker wat die algoritme aktiveer).

Ons het Pilot uitgepluis, nou moet ons verstaan ​​hoe Mixer werk en hoekom dit nodig is. Jy kan die amptelike dokumentasie daarvoor lees hier.

Menger in sy huidige vorm bestaan ​​uit twee komponente: istio-telemetrie, istio-beleid (voor weergawe 0.8 was dit een istio-menger-komponent). Beide van hulle is mengers, wat elkeen vir sy eie taak verantwoordelik is. Istio-telemetrie ontvang inligting oor wie waarheen gaan en met watter parameters vanaf syspan Rapporteer houers via GRPC. Istio-beleid aanvaar tjekversoeke om te verifieer dat daar aan die beleidsreëls voldoen word. Polisiekontroles word natuurlik nie vir elke versoek uitgevoer nie, maar word vir 'n sekere tyd op die kliënt (in die syspan) gekas. Verslagtjeks word as bondelversoeke gestuur. Kom ons kyk hoe om te konfigureer en watter parameters 'n bietjie later gestuur moet word.

Die menger is veronderstel om 'n hoogs beskikbare komponent te wees wat ononderbroke werk aan die samestelling en verwerking van telemetriedata verseker. Die stelsel word as gevolg daarvan verkry as 'n multi-vlak buffer. Aanvanklik word data aan die syspankant van houers gebuffer, dan aan die mengerkant, en dan na die sogenaamde menger-agterkante gestuur. As gevolg hiervan, as enige van die stelselkomponente misluk, groei die buffer en word dit gespoel nadat die stelsel herstel is. Menger-agtergronde is eindpunte vir die stuur van telemetriedata: statsd, newrelic, ens. Jy kan jou eie backend skryf, dit is redelik eenvoudig, en ons sal sien hoe om dit te doen.

Hoe om Istio te laat loop met Kubernetes in produksie. Deel 1

Om op te som, die skema om met istio-telemetrie te werk is soos volg.

  1. Diens 1 stuur 'n versoek na diens 2.
  2. Wanneer diens 1 verlaat word, word die versoek in sy eie syspan toegedraai.
  3. Sidecar-gesant monitor hoe die versoek na diens 2 gaan en berei die nodige inligting voor.
  4. Stuur dit dan na istio-telemetrie deur 'n Verslagversoek te gebruik.
  5. Istio-telemetrie bepaal of hierdie Verslag na die backends gestuur moet word, na watter en watter data gestuur moet word.
  6. Istio-telemetrie stuur verslagdata na die agterkant indien nodig.

Kom ons kyk nou hoe om Istio in die stelsel te ontplooi, wat slegs uit die hoofkomponente bestaan ​​(vlieënier en syspan gesant).

Kom ons kyk eers na die hoofkonfigurasie (mesh) wat Pilot lees:

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

Al die hoofbeheerkomponente (beheervlak) sal in die naamruimte istio-stelsel in Kubernetes geleë wees.

Op 'n minimum hoef ons net Pilot te ontplooi. Hiervoor gebruik ons so 'n konfigurasie.

En ons sal die inspuitende syspan van die houer handmatig instel.

Init houer:

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

En syspan:

       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

Om alles suksesvol te laat begin, moet jy 'n Diensrekening, ClusterRole, ClusterRoleBinding, CRD vir Pilot skep, waarvan die beskrywings gevind kan word hier.

Gevolglik behoort die diens waarin ons syspan met gesant inspuit, suksesvol te begin, alle ontdekkings van die loods te ontvang en versoeke te verwerk.

Dit is belangrik om te verstaan ​​dat alle beheervlakkomponente staatlose toepassings is en sonder probleme horisontaal geskaal kan word. Alle data word in etcd gestoor in die vorm van pasgemaakte beskrywings van Kubernetes-hulpbronne.

Ook, Istio (nog steeds eksperimenteel) het die vermoë om buite die groepering te hardloop en die vermoë om diensontdekking tussen verskeie Kubernetes-groepe te kyk en te vroetel. Jy kan meer hieroor lees hier.

Vir 'n multi-kluster installasie, wees bewus van die volgende beperkings:

  1. Pod CIDR en Service CIDR moet uniek wees oor alle clusters en moet nie oorvleuel nie.
  2. Alle CIDR-peule moet toeganklik wees vanaf enige CIDR-peule tussen trosse.
  3. Alle Kubernetes API-bedieners moet vir mekaar toeganklik wees.

Dit is die aanvanklike inligting om jou te help om met Istio te begin. Daar is egter nog baie slaggate. Byvoorbeeld, kenmerke van die roetering van eksterne verkeer (buite die groep), benaderings tot ontfouting van syspan, profilering, die opstel van 'n menger en die skryf van 'n pasgemaakte menger-agterkant, die opstel van 'n opsporingsmeganisme en die werking daarvan met behulp van gesant.
Dit alles sal ons in die volgende publikasies oorweeg. Vra jou vrae, ek sal probeer om dit te dek.

Bron: will.com

Voeg 'n opmerking