ProHoster > Blog > Bestjoer > Hoe kinne jo Istio útfiere mei Kubernetes yn produksje. Diel 1

Hoe kinne jo Istio útfiere mei Kubernetes yn produksje. Diel 1

wat Istio? Dit is it saneamde Service-mesh, in technology dy't in laach fan abstraksje oer it netwurk tafoeget. Wy ûnderskeppe it hiele of in part fan it ferkear yn it kluster en fiere dêr in bepaalde set fan operaasjes mei út. Hokker? Bygelyks, wy dogge tûke routing, of wy implementearje de circuit breaker oanpak, wy kinne organisearje "kanaryske ynset", foar in part oerskeakelje ferkear nei in nije ferzje fan de tsjinst, of wy kinne beheine eksterne ynteraksjes en kontrolearje alle reizen fan it kluster nei de kluster eksterne netwurk. It is mooglik om beliedsregels yn te stellen om reizen te kontrolearjen tusken ferskate mikrotsjinsten. Uteinlik kinne wy ​​​​de heule netwurkynteraksjekaart krije en de unifoarme kolleksje fan metriken folslein transparant meitsje foar applikaasjes.

Jo kinne lêze oer it meganisme fan wurk yn offisjele dokumintaasje. Istio is in echt krêftich ark wêrmei jo in protte taken en problemen kinne oplosse. Yn dit artikel wol ik de wichtichste fragen beäntwurdzje dy't normaal ûntsteane as jo begjinne mei Istio. Dit sil jo helpe om it rapper te behanneljen.

Hoe kinne jo Istio útfiere mei Kubernetes yn produksje. Diel 1

Hoe't it wurket

Istio bestiet út twa haadgebieten - it kontrôlefleanmasine en it gegevensfleantúch. De kontrôle fleanmasine befettet de wichtichste komponinten dy't soargje foar de juste wurking fan 'e rest. Yn 'e hjoeddeistige ferzje (1.0) hat it kontrôlefleanmasine trije haadkomponinten: Pilot, Mixer, Citadel. Wy sille Citadel net beskôgje, it is nedich om sertifikaten te generearjen om ûnderlinge TLS tusken tsjinsten te garandearjen. Litte wy in tichterby besjen op it apparaat en doel fan Pilot en Mixer.

Hoe kinne jo Istio útfiere mei Kubernetes yn produksje. Diel 1

Pilot is de wichtichste kontrôle komponint dat distribuearret alle ynformaasje oer wat wy hawwe yn it kluster - tsjinsten, harren einpunten en routing regels (Bygelyks, regels foar Kanaryske ynset of circuit breaker regels).

Mixer is in opsjonele komponint foar kontrôleflak dy't de mooglikheid biedt om metriken, logs en alle ynformaasje oer netwurkynteraksje te sammeljen. Hy kontrolearret ek neilibjen fan beliedsregels en neilibjen fan taryfgrinzen.

It gegevensfleantúch wurdt ymplementearre mei help fan sidecar proxy-kontainers. Krêftich wurdt standert brûkt. envoy proxy. It kin wurde ferfongen troch in oare ymplemintaasje, lykas nginx (nginmesh).

Om Istio folslein transparant te wurkjen foar applikaasjes, is d'r in automatysk ynjeksjesysteem. De lêste ymplemintaasje is geskikt foar Kubernetes 1.9+ ferzjes (mutational admission webhook). Foar Kubernetes ferzjes 1.7, 1.8 is it mooglik om de Initializer te brûken.

Sidecar-konteners binne ferbûn mei Pilot mei it GRPC-protokol, wêrtroch jo it push-model kinne optimalisearje foar feroaringen dy't yn it kluster foarkomme. GRPC is brûkt yn Envoy sûnt ferzje 1.6, yn Istio is it brûkt sûnt ferzje 0.8 en is in pilot-agint - in golang wrapper oer envoy dy't startopsjes konfigurearret.

Pilot en Mixer binne folslein steatleaze komponinten, alle steat wurdt bewarre yn it ûnthâld. De konfiguraasje foar harren is ynsteld yn 'e foarm fan Kubernetes Custom Resources, dy't wurde opslein yn etcd.
Istio-agent krijt it adres fan 'e Pilot en iepenet der in GRPC-stream nei.

Lykas ik sei, implementeart Istio alle funksjonaliteit folslein transparant foar applikaasjes. Litte wy sjen hoe. It algoritme is dit:

  1. It ynsetten fan in nije ferzje fan 'e tsjinst.
  2. Ofhinklik fan 'e oanpak foar ynjeksje fan sidecar-container, wurde de istio-init-container en de istio-agent-container (envoy) tafoege op it poadium fan it tapassen fan de konfiguraasje, of se kinne al mei de hân ynfoege wurde yn' e beskriuwing fan 'e Kubernetes Pod-entiteit.
  3. De istio-init container is in skript dat de iptables regels tapast op de pod. D'r binne twa opsjes foar it konfigurearjen fan ferkear om yn in kontener foar istio-agent te ferpakken: brûk iptables trochferwizingsregels, of TPROXY. Op it stuit fan skriuwen is de standertoanpak mei trochferwizingsregels. Yn istio-init is it mooglik om te konfigurearjen hokker ferkear moat wurde ûnderskept en stjoerd nei istio-agent. Bygelyks, om alle ynkommende en alle útgeande ferkear te ûnderskeppen, moatte jo de parameters ynstelle -i и -b yn betsjutting *. Jo kinne spesifike havens opjaan om te ûnderskeppen. Om in spesifyk subnet net te ûnderskeppen, kinne jo it opjaan mei de flagge -x.
  4. Nei't de init-konteners binne útfierd, wurde de wichtichste lansearre, ynklusyf de pilot-agint (gezant). It ferbynt mei de al ynset Pilot fia GRPC en ûntfangt ynformaasje oer alle besteande tsjinsten en rûtebelied yn it kluster. Neffens de ûntfongen gegevens konfigurearret hy de klusters en jout se direkt oan 'e einpunten fan ús applikaasjes yn it Kubernetes-kluster. It is ek nedich om in wichtich punt op te merken: envoy konfigurearret harkers dynamysk (IP, poarte pearen) dat it begjint te harkjen. Dêrom, as fersiken yn 'e pod komme, wurde omlaat mei de omlieding iptables regels yn' e sidecar, envoy kin al mei súkses ferwurkje dizze ferbinings en begripe wêr't fierder proxy it ferkear. Ek op dit poadium wurdt ynformaasje stjoerd nei de Mixer, dy't wy letter sille sjen, en tracing-spans wurde stjoerd.

As gefolch krije wy in hiele netwurk fan envoy proxy-tsjinners dy't wy fan ien punt kinne konfigurearje (Pilot). Alle ynkommende en útgeande oanfragen geane fia gesant. Boppedat wurdt allinich TCP-ferkear ûnderskept. Dit betsjut dat Kubernetes-tsjinst IP wurdt oplost mei kube-dns oer UDP sûnder te feroarjen. Dan, nei it beslút, wurdt it útgeande fersyk ûnderskept en ferwurke troch gesant, dy't al beslút nei hokker einpunt it fersyk stjoerd wurde moat (of net ferstjoerd, yn it gefal fan tagongsbelied of de circuit breaker fan it algoritme).

Wy hawwe Pilot útfûn, no moatte wy begripe hoe't Mixer wurket en wêrom it nedich is. Jo kinne dêr de offisjele dokumintaasje foar lêze hjir.

Mixer yn syn hjoeddeistige foarm bestiet út twa komponinten: istio-telemetry, istio-belied (foar ferzje 0.8 wie it ien istio-mixer-komponint). Beide binne mixers, elk fan dat is ferantwurdlik foar syn eigen taak. Istio telemetry ûntfangt ynformaasje oer wa giet wêr en mei hokker parameters út sidecar Meld containers fia GRPC. Istio-belied akseptearret Kontrolearje fersiken om te kontrolearjen dat beliedsregels tefreden binne. Poilicy-kontrôles wurde fansels net útfierd foar elke oanfraach, mar wurde foar in bepaalde tiid op 'e kliïnt (yn 'e sydspan) yn 'e cache bewarre. Rapport sjeks wurde ferstjoerd as batch fersiken. Litte wy sjen hoe te konfigurearjen en hokker parameters moatte wurde ferstjoerd in bytsje letter.

De Mixer soe in heul beskikber komponint wêze dat soarget foar ûnûnderbrutsen wurk oan 'e gearstalling en ferwurking fan telemetrygegevens. It systeem wurdt krigen as gefolch as in multi-level buffer. Yn earste ynstânsje wurde gegevens buffered oan de sidecar kant fan konteners, dan oan de mixer kant, en dan stjoerd nei de saneamde mixer backends. As gefolch, as ien fan 'e systeemkomponinten mislearret, groeit de buffer en wurdt nei it systeem restaurearre. Mixer-backends binne einpunten foar it ferstjoeren fan telemetrygegevens: statsd, newrelic, ensfh. Jo kinne jo eigen backend skriuwe, it is frij simpel, en wy sille sjen hoe't jo it dwaan.

Hoe kinne jo Istio útfiere mei Kubernetes yn produksje. Diel 1

Om gearfetsje, it skema foar it wurkjen mei istio-telemetry is as folget.

  1. Tsjinst 1 stjoert in fersyk nei tsjinst 2.
  2. By it ferlitten fan tsjinst 1 wurdt it fersyk ferpakt yn in eigen sydspan.
  3. Sidecar gesant kontrolearret hoe't it fersyk giet nei tsjinst 2 en taret de nedige ynformaasje.
  4. Stjoert it dan nei istio-telemetry mei in rapportfersyk.
  5. Istio-telemetry bepaalt oft dit Rapport nei de backends stjoerd wurde moat, nei hokker en hokker gegevens stjoerd wurde moatte.
  6. Istio-telemetry stjoert rapportgegevens nei de efterkant as nedich.

Litte wy no sjen hoe't jo Istio kinne ynsette yn it systeem, besteande allinich út 'e haadkomponinten (Pilot en sidecar-envoy).

Litte wy earst nei de haadkonfiguraasje (mesh) sjen dy't Pilot lêst:

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

Alle haadkontrôlekomponinten (kontrôlefleantúch) sille lizze yn it nammeromte istio-systeem yn Kubernetes.

Op syn minst moatte wy allinich Pilot ynsette. Dêrfoar brûke wy sa'n konfiguraasje.

En wy sille de ynjeksje sidecar fan 'e kontener manuell konfigurearje.

Ynit 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

En 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

Om alles mei súkses te begjinnen, moatte jo in ServiceAccount, ClusterRole, ClusterRoleBinding, CRD foar Pilot oanmeitsje, wêrfan de beskriuwingen te finen binne hjir.

As resultaat moat de tsjinst wêryn wy sidecar mei gesant ynjeksje mei súkses begjinne, alle ûntdekking fan 'e pilot ûntfange en fersiken ferwurkje.

It is wichtich om te begripen dat alle komponinten fan it kontrôlefleantúch steatleaze applikaasjes binne en sûnder problemen horizontaal kinne wurde skalearre. Alle gegevens wurde opslein yn etcd yn 'e foarm fan oanpaste beskriuwingen fan Kubernetes-boarnen.

Ek Istio (noch eksperiminteel) hat de mooglikheid om te rinnen bûten it kluster en de mooglikheid om te sjen en fumble tsjinst ûntdekking tusken ferskate Kubernetes klusters. Jo kinne hjir mear oer lêze hjir.

Foar in multi-cluster ynstallaasje, wês bewust fan de folgjende beheiningen:

  1. Pod CIDR en Service CIDR moatte unyk wêze yn alle klusters en moatte net oerlappe.
  2. Alle CIDR Pods moatte tagonklik wêze fan alle CIDR Pods tusken klusters.
  3. Alle Kubernetes API-tsjinners moatte foar elkoar tagonklik wêze.

Dit is de earste ynformaasje om jo te helpen te begjinnen mei Istio. Dochs binne der noch in protte falkûlen. Bygelyks, skaaimerken fan routing ekstern ferkear (bûten it kluster), oanpakken foar debuggen sidecars, profilearring, opsetten fan in mixer en it skriuwen fan in oanpaste mixer backend, it opsetten fan in tracing meganisme en syn operaasje mei help fan envoy.
Dit alles sille wy beskôgje yn 'e folgjende publikaasjes. Stel jo fragen, ik sil besykje se te dekken.

Boarne: www.habr.com

Add a comment