ProHoster > Blog > Administratioun > Wéi lafen Istio mat Kubernetes an der Produktioun. Deel 1

Wéi lafen Istio mat Kubernetes an der Produktioun. Deel 1

wat Istio? Dëst ass de sougenannte Service Mesh, eng Technologie déi eng Abstraktiounschicht iwwer d'Netzwierk bäidréit. Mir interceptéieren de ganzen oder en Deel vum Traffic am Stärekoup a maachen e bestëmmte Set vun Operatiounen domat. Wéi eng? Zum Beispill maache mir Smart Routing, oder mir implementéieren de Circuit Breaker Approche, mir kënnen "Kanaresch Deployment" organiséieren, deelweis de Traffic op eng nei Versioun vum Service wiesselen, oder mir kënnen extern Interaktiounen limitéieren an all Reesen vum Cluster op de Cluster kontrolléieren externen Netzwierk. Et ass méiglech Politikregelen ze setzen fir Reesen tëscht verschiddene Mikroservicer ze kontrolléieren. Endlech kënne mir déi ganz Netzwierkinteraktiounskaart kréien an déi vereenegt Sammlung vu Metriken komplett transparent fir Uwendungen maachen.

Dir kënnt iwwer de Mechanismus vun der Aarbecht liesen offiziell Dokumentatioun. Istio ass e wierklech mächtegt Tool dat Iech erlaabt vill Aufgaben a Probleemer ze léisen. An dësem Artikel wéilt ech d'Haaptfroen beäntweren, déi normalerweis entstinn wann Dir mat Istio unzefänken. Dëst wäert Iech hëllefen et méi séier ze këmmeren.

Wéi lafen Istio mat Kubernetes an der Produktioun. Deel 1

Wéi se funktionéiert

Istio besteet aus zwee Haaptberäicher - d'Kontrollplan an d'Datefliger. De Kontrollebene enthält d'Haaptkomponenten, déi d'korrekt Operatioun vum Rescht garantéieren. An der aktueller Versioun (1.0) der Kontroll Fliger huet dräi Haapt Komponente: Pilot, Mixer, Zitadell. Mir wäerten d'Zitadel net berücksichtegen, et ass néideg fir Certificaten ze generéieren fir géigesäiteg TLS tëscht Servicer ze garantéieren. Loosst eis den Apparat an den Zweck vum Pilot a Mixer méi no kucken.

Wéi lafen Istio mat Kubernetes an der Produktioun. Deel 1

Pilot ass den Haaptkontrollkomponent deen all Informatioun verdeelt iwwer dat wat mir am Cluster hunn - Servicer, hir Endpunkter a Routingregelen (zum Beispill Reegele fir Kanaresch Deployment oder Circuit Breaker Regelen).

Mixer ass en optionalen Kontrollplanekomponent deen d'Fäegkeet bitt Metriken, Logbicher an all Informatioun iwwer Netzwierkinteraktioun ze sammelen. Hien iwwerwaacht och d'Konformitéit mat de Politikregelen an d'Konformitéit mat Tauxlimiten.

Den Datefliger gëtt mat Sidecar Proxy Container implementéiert. Mächteg gëtt als Standard benotzt. Envoy Proxy. Et kann duerch eng aner Implementatioun ersat ginn, sou wéi nginx (nginmesh).

Fir datt Istio komplett transparent fir Uwendungen funktionnéiert, gëtt et en automateschen Injektiounssystem. Déi lescht Implementatioun ass gëeegent fir Kubernetes 1.9+ Versiounen (mutational Admission Webhook). Fir Kubernetes Versiounen 1.7, 1.8 ass et méiglech den Initializer ze benotzen.

Sidecar Container si mam Pilot verbonne mat dem GRPC Protokoll, wat Iech erlaabt de Push Modell fir Ännerungen am Cluster ze optimiséieren. GRPC gouf am Envoy zënter Versioun 1.6 benotzt, an Istio gouf et zënter Versioun 0.8 benotzt an ass e Pilot-Agent - e Golang Wrapper iwwer Envoy deen Startoptiounen konfiguréiert.

Pilot a Mixer si komplett stateless Komponenten, all Staat gëtt an der Erënnerung gehal. D'Konfiguratioun fir si ass a Form vu Kubernetes Custom Ressourcen gesat, déi an etcd gespäichert sinn.
Istio-Agent kritt d'Adress vum Pilot an mécht e GRPC Stream op.

Wéi ech gesot hunn, implementéiert Istio all Funktionalitéit komplett transparent fir Uwendungen. Loosst eis kucken wéi. Den Algorithmus ass dëst:

  1. Eng nei Versioun vum Service z'installéieren.
  2. Ofhängeg vun der Sidecar Container Injektioun Approche, den istio-init Container an den istio-Agent Container (Envoy) ginn op der Bühn vun der Uwendung vun der Konfiguratioun bäigefüügt, oder se kënne scho manuell an d'Beschreiwung vun der Kubernetes Pod Entity agefouert ginn.
  3. Den istio-init Container ass e Skript deen d'iptables Regelen op de Pod applizéiert. Et ginn zwou Méiglechkeeten fir de Traffic ze konfiguréieren deen an engem istio-Agent Container gewéckelt ass: benotzt d'Redirect Reegele vun iptables, oder TPROXY. Zu der Zäit vum Schreiwen ass d'Standard Approche mat Viruleedungsregelen. Am istio-init ass et méiglech ze konfiguréieren wéi ee Verkéier soll ofgefaangen an un den istio-Agent geschéckt ginn. Zum Beispill, fir all erakommen an all erausginn Traffic ze interceptéieren, musst Dir d'Parameteren setzen -i и -b an Bedeitung *. Dir kënnt spezifesch Häfen spezifizéieren fir z'ënnerscheeden. Fir e spezifescht Subnet net z'ënnerscheeden, kënnt Dir et mam Fändel spezifizéieren -x.
  4. Nodeems d'Init Behälter ausgefouert ginn, ginn déi Haapt lancéiert, dorënner de Pilot-Agent (Envoy). Et verbënnt mat dem scho ofgebaute Pilot iwwer GRPC a kritt Informatioun iwwer all existent Servicer a Routing-Politik am Cluster. Laut den erhalenen Donnéeën konfiguréiert hien d'Cluster an verdeelt se direkt un d'Endpunkte vun eisen Uwendungen am Kubernetes Cluster. Et ass och néideg e wichtege Punkt ze notéieren: Envoy konfiguréiert dynamesch Nolauschterer (IP, Portpairen) op déi et ufänkt ze lauschteren. Dofir, wann Ufroen an de Pod erakommen, mat de Redirect iptables Regelen am Sidecar ëmgeleet ginn, kann den Envoy schonn erfollegräich dës Verbindungen veraarbecht a verstoen wou de Verkéier weider Proxy soll ginn. Och op dëser Etapp gëtt d'Informatioun un de Mixer geschéckt, op dee mir spéider kucken, an d'Tracingspann ginn geschéckt.

Als Resultat kréien mir e ganzt Netz vun Envoy Proxy Serveren, déi mir vun engem Punkt konfiguréieren (Pilot). All Inbound an Outbound Ufroe ginn duerch Envoy. Ausserdeem gëtt nëmmen den TCP Traffic ofgefaangen. Dëst bedeit datt Kubernetes Service IP mat Kube-dns iwwer UDP geléist gëtt ouni ze änneren. Dann, no der Entschlossenheet, gëtt déi erausginn Ufro ofgefaangen a veraarbecht vum Envoy, dee schonn entscheet op wéi en Ennpunkt d'Ufro soll geschéckt ginn (oder net geschéckt, am Fall vun Zougangspolitiken oder de Circuit Breaker vum Algorithmus).

Mir hunn de Pilot erausfonnt, elo musse mir verstoen wéi de Mixer funktionnéiert a firwat et gebraucht gëtt. Dir kënnt déi offiziell Dokumentatioun dofir liesen hei.

Mixer a senger aktueller Form besteet aus zwee Komponenten: istio-Telemetrie, istio-Politik (virun Versioun 0.8 war et een istio-Mixer-Komponent). Béid si Mixer, déi jidderee fir seng eegen Aufgab verantwortlech ass. Istio-Telemetrie kritt Informatiounen iwwer wien wou geet a mat wéi enge Parameteren aus Sidecar Bericht Behälter iwwer GRPC. Istio-Politik akzeptéiert Check Ufroe fir z'iwwerpréiwen datt d'Politikregelen zefridden sinn. Poilicy Kontrollen ginn natierlech net fir all Ufro duerchgefouert, mä ginn op de Client (am Sidecar) fir eng gewëssen Zäit cache. Rapport Schecken ginn als Batch Ufroe geschéckt. Loosst eis kucken wéi Dir konfiguréiert a wéi eng Parameteren e bësse méi spéit geschéckt ginn.

De Mixer soll en héich verfügbare Komponent sinn, deen onënnerbrach Aarbecht op der Assemblée an der Veraarbechtung vun Telemetriedaten garantéiert. De System gëtt als Resultat als Multi-Level Puffer kritt. Am Ufank ginn d'Donnéeën op der Sidecar Säit vu Behälter gebuffert, dann op der Mixer Säit, an dann op déi sougenannte Mixer Backends geschéckt. Als Resultat, wann ee vun de Systemkomponente feelt, wiisst de Puffer a gëtt gespullt nodeems de System restauréiert ass. Mixer Backends sinn Endpunkte fir Telemetrie Daten ze schécken: statsd, newrelic, etc. Dir kënnt Ären eegene Backend schreiwen, et ass ganz einfach, a mir wäerte kucken wéi Dir et maacht.

Wéi lafen Istio mat Kubernetes an der Produktioun. Deel 1

Zesummefaassend ass de Schema fir mat Istio-Telemetrie ze schaffen wéi follegt.

  1. Service 1 schéckt eng Demande un Service 2.
  2. Beim Verlassen vum Service 1 gëtt d'Ufro a sengem eegene Sidecar gewéckelt.
  3. Sidecar Envoy iwwerwaacht wéi d'Ufro un de Service 2 geet a preparéiert déi néideg Informatioun.
  4. Schéckt et dann op d'Istio-Telemetrie mat enger Berichtsufro.
  5. Istio-Telemetrie bestëmmt ob dëse Bericht un d'Backends geschéckt soll ginn, op wéi eng a wéi eng Donnéeën geschéckt ginn.
  6. Istio-Telemetrie schéckt Berichtdaten un de Backend wann néideg.

Loosst eis elo kucken wéi Dir Istio am System ofsetzt, besteet nëmmen aus den Haaptkomponenten (Pilot a Sidecar Envoy).

Als éischt kucke mer d'Haaptkonfiguratioun (Mesh) déi de Pilot liest:

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

All d'Haaptsteuerkomponenten (Kontrollplan) wäerten am Nummraum asstio-System zu Kubernetes sinn.

Op e Minimum musse mir nëmmen Pilot ofsetzen. Fir dëst benotze mir esou eng Konfiguratioun.

A mir wäerten d'Injektiounssidecar vum Container manuell konfiguréieren.

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

An 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

Fir datt alles erfollegräich ufänkt, musst Dir e ServiceAccount, ClusterRole, ClusterRoleBinding, CRD fir Pilot erstellen, d'Beschreiwunge vun deem kënne fonnt ginn hei.

Als Resultat soll de Service an deen mir Sidecar mat Envoy sprëtzen erfollegräich starten, all Entdeckung vum Pilot a Prozesserfuerderunge kréien.

Et ass wichteg ze verstoen datt all Kontrollplanekomponente stateless Uwendungen sinn an ouni Probleemer horizontal skaléiert kënne ginn. All Daten ginn an etcd a Form vu personaliséierte Beschreiwunge vu Kubernetes Ressourcen gespäichert.

Och Istio (nach ëmmer experimentell) huet d'Fäegkeet ausserhalb vum Cluster ze lafen an d'Fäegkeet fir Service Entdeckung tëscht verschiddene Kubernetes Cluster ze kucken an ze fummelen. Dir kënnt méi iwwer dëst liesen hei.

Fir eng Multi-Cluster Installatioun, bewosst déi folgend Aschränkungen:

  1. Pod CIDR a Service CIDR mussen eenzegaarteg sinn iwwer all Cluster a däerf net iwwerlappen.
  2. All CIDR Pods musse vun all CIDR Pods tëscht Cluster zougänglech sinn.
  3. All Kubernetes API Server musse fir all aner zougänglech sinn.

Dëst ass déi initial Informatioun fir Iech ze hëllefen mat Istio unzefänken. Et ginn awer nach vill Falen. Zum Beispill, Fonctiounen vun Routing externen Traffic (ausserhalb vum Stärekoup), Approche zu Debugging Sidecars, Profiler, Opriichte vun engem Mixer an Schreiwen vun engem Mooss Mixer Backend, Opstellung vun engem Tracing Mechanismus a seng Operatioun benotzt Envoy.
All dëst wäerte mir an de folgende Publikatiounen betruecht. Stellt Är Froen, ech probéieren se ze decken.

Source: will.com

Setzt e Commentaire