ProHoster > Log > administrasjon > Hvordan kjøre Istio ved å bruke Kubernetes i produksjon. Del 1

Hvordan kjøre Istio ved å bruke Kubernetes i produksjon. Del 1

Hva er Samme? Dette er det såkalte Service mesh, en teknologi som legger til et lag med abstraksjon over nettverket. Vi fanger opp hele eller deler av trafikken i klyngen og utfører et bestemt sett med operasjoner med den. Hvilken? For eksempel gjør vi smart ruting, eller vi implementerer strømbrytertilnærmingen, vi kan organisere "kanarie-utplassering", delvis bytte trafikk til en ny versjon av tjenesten, eller vi kan begrense eksterne interaksjoner og kontrollere alle turer fra klyngen til klyngen. eksternt nettverk. Det er mulig å sette policyregler for å kontrollere reiser mellom ulike mikrotjenester. Til slutt kan vi få hele nettverksinteraksjonskartet og gjøre den enhetlige samlingen av beregninger helt gjennomsiktig for applikasjoner.

Du kan lese om arbeidsmekanismen i offisiell dokumentasjon. Istio er et virkelig kraftig verktøy som lar deg løse mange oppgaver og problemer. I denne artikkelen vil jeg gjerne svare på de viktigste spørsmålene som vanligvis dukker opp når du kommer i gang med Istio. Dette vil hjelpe deg å håndtere det raskere.

Hvordan kjøre Istio ved å bruke Kubernetes i produksjon. Del 1

Prinsippet om drift

Istio består av to hovedområder - kontrollplanet og dataplanet. Kontrollplanet inneholder hovedkomponentene som sikrer riktig drift av resten. I gjeldende versjon (1.0) har kontrollplanet tre hovedkomponenter: Pilot, Mixer, Citadel. Vi vil ikke vurdere Citadel, det er nødvendig å generere sertifikater for å sikre gjensidig TLS mellom tjenester. La oss se nærmere på enheten og formålet med Pilot og Mixer.

Hvordan kjøre Istio ved å bruke Kubernetes i produksjon. Del 1

Pilot er hovedkontrollkomponenten som distribuerer all informasjon om hva vi har i klyngen - tjenester, deres endepunkter og rutingregler (for eksempel regler for Canary-distribusjon eller strømbryterregler).

Mixer er en valgfri kontrollplankomponent som gir muligheten til å samle inn beregninger, logger og all informasjon om nettverksinteraksjon. Han overvåker også overholdelse av retningslinjer og overholdelse av takstgrenser.

Dataplanet implementeres ved hjelp av sidevogn proxy-beholdere. Kraftig brukes som standard. utsendings fullmektig. Den kan erstattes av en annen implementering, for eksempel nginx (nginmesh).

For at Istio skal fungere helt transparent for applikasjoner, er det et automatisk injeksjonssystem. Den nyeste implementeringen er egnet for Kubernetes 1.9+ versjoner (mutasjonsadmission webhook). For Kubernetes versjoner 1.7, 1.8 er det mulig å bruke Initializer.

Sidevognscontainere kobles til Pilot ved hjelp av GRPC-protokollen, som lar deg optimere push-modellen for endringer som skjer i klyngen. GRPC har blitt brukt i Envoy siden versjon 1.6, i Istio har det vært brukt siden versjon 0.8 og er en pilot-agent - en golang wrapper over envoy som konfigurerer lanseringsalternativer.

Pilot og mikser er fullstendig statsløse komponenter, all tilstand lagres i minnet. Konfigurasjonen for dem er satt i form av Kubernetes Custom Resources, som er lagret i etcd.
Istio-agent får pilotens adresse og åpner en GRPC-strøm til den.

Som sagt implementerer Istio all funksjonalitet helt gjennomsiktig for applikasjoner. La oss se hvordan. Algoritmen er denne:

  1. Implementerer en ny versjon av tjenesten.
  2. Avhengig av tilnærmingen til injeksjon av sidevognbeholdere, legges istio-init-beholderen og istio-agentbeholderen (utsending) til på tidspunktet for bruk av konfigurasjonen, eller de kan allerede settes inn manuelt i beskrivelsen av Kubernetes Pod-enheten.
  3. Istio-init-beholderen er et skript som bruker iptables-reglene på poden. Det er to alternativer for å konfigurere trafikk til å pakkes inn i en istio-agentbeholder: bruk iptables omdirigeringsregler, eller TPROXY. I skrivende stund er standardtilnærmingen med omdirigeringsregler. I istio-init er det mulig å konfigurere hvilken trafikk som skal fanges opp og sendes til istio-agent. For eksempel, for å fange opp all innkommende og all utgående trafikk, må du angi parameterne -i и -b til mening *. Du kan spesifisere spesifikke porter som skal avskjæres. For ikke å avskjære et spesifikt subnett, kan du spesifisere det ved å bruke flagget -x.
  4. Etter at init-beholderne er utført, lanseres de viktigste, inkludert pilot-agenten (utsending). Den kobles til den allerede utplasserte piloten via GRPC og mottar informasjon om alle eksisterende tjenester og rutingpolicyer i klyngen. I henhold til dataene som er mottatt, konfigurerer han klyngene og tildeler dem direkte til endepunktene til applikasjonene våre i Kubernetes-klyngen. Det er også nødvendig å merke seg et viktig poeng: envoy konfigurerer dynamisk lyttere (IP, portpar) som den begynner å lytte til. Derfor, når forespørsler kommer inn i poden, blir omdirigert ved hjelp av omdirigerings-iptables-reglene i sidevognen, kan envoy allerede behandle disse forbindelsene og forstå hvor trafikken skal sendes videre. Også på dette stadiet sendes informasjon til mikseren, som vi skal se på senere, og sporingsspenn sendes.

Som et resultat får vi et helt nettverk av envoy proxy-servere som vi kan konfigurere fra ett punkt (Pilot). Alle innkommende og utgående forespørsler går gjennom envoy. Dessuten er det kun TCP-trafikk som blir fanget opp. Dette betyr at Kubernetes tjeneste IP løses ved hjelp av kube-dns over UDP uten å endres. Deretter, etter vedtaket, blir den utgående forespørselen fanget opp og behandlet av utsending, som allerede bestemmer hvilket endepunkt forespørselen skal sendes til (eller ikke sendes, i tilfelle tilgangspolicyer eller kretsbryteren til algoritmen).

Vi fant ut Pilot, nå må vi forstå hvordan Mixer fungerer og hvorfor det er nødvendig. Du kan lese den offisielle dokumentasjonen for det her.

Mixer i sin nåværende form består av to komponenter: istio-telemetri, istio-policy (før versjon 0.8 var det en istio-mixer-komponent). Begge er miksere, som hver er ansvarlig for sin egen oppgave. Istio telemetri mottar informasjon om hvem som går hvor og med hvilke parametere fra sidevogn Rapport containere via GRPC. Istio-policy aksepterer sjekkforespørsler for å bekrefte at policyreglene er oppfylt. Poilicy-sjekker utføres selvfølgelig ikke for hver forespørsel, men bufres på klienten (i sidevognen) i en viss tid. Rapportsjekker sendes som batchforespørsler. La oss se hvordan du konfigurerer og hvilke parametere som skal sendes litt senere.

Mikseren er ment å være en høyst tilgjengelig komponent som sikrer uavbrutt arbeid med sammenstilling og behandling av telemetridata. Systemet oppnås som et resultat som en multi-level buffer. Til å begynne med bufres data på sidevognsiden av containere, deretter på blandersiden og sendes deretter til de såkalte mixer-backends. Som et resultat, hvis noen av systemkomponentene svikter, vokser bufferen og tømmes etter at systemet er gjenopprettet. Mixer-backends er endepunkter for å sende telemetridata: statsd, newrelic, etc. Du kan skrive din egen backend, det er ganske enkelt, og vi skal se hvordan du gjør det.

Hvordan kjøre Istio ved å bruke Kubernetes i produksjon. Del 1

For å oppsummere er opplegget for arbeid med istio-telemetri som følger.

  1. Tjeneste 1 sender en forespørsel til tjeneste 2.
  2. Ved avgang av tjeneste 1 pakkes forespørselen inn i egen sidevogn.
  3. Sidecar envoy overvåker hvordan forespørselen går til tjeneste 2 og forbereder nødvendig informasjon.
  4. Sender den deretter til istio-telemetri ved hjelp av en rapportforespørsel.
  5. Istio-telemetri bestemmer om denne rapporten skal sendes til backends, til hvilke og hvilke data som skal sendes.
  6. Istio-telemetri sender rapportdata til backend om nødvendig.

La oss nå se hvordan du distribuerer Istio i systemet, som kun består av hovedkomponentene (pilot og sidevognsutsending).

La oss først se på hovedkonfigurasjonen (mesh) som Pilot leser:

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 hovedkontrollkomponentene (kontrollplanet) vil bli plassert i navneområdet istio-systemet i Kubernetes.

Som et minimum trenger vi bare å distribuere Pilot. Til dette bruker vi en slik konfigurasjon.

Og vi vil manuelt konfigurere injeksjonssidevognen til beholderen.

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

Og sidevogn:

       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

For at alt skal starte på en vellykket måte, må du opprette en ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, hvis beskrivelser kan finnes her.

Som et resultat bør tjenesten som vi injiserer sidevogn med envoy i, starte vellykket, motta all oppdagelse fra piloten og behandle forespørsler.

Det er viktig å forstå at alle kontrollplankomponenter er statsløse applikasjoner og kan skaleres horisontalt uten problemer. Alle data lagres i etcd i form av tilpassede beskrivelser av Kubernetes-ressurser.

Dessuten har Istio (fortsatt eksperimentell) muligheten til å kjøre utenfor klyngen og muligheten til å se på og famle tjenesteoppdagelser mellom flere Kubernetes-klynger. Du kan lese mer om dette her.

For en flerklyngeinstallasjon, vær oppmerksom på følgende begrensninger:

  1. Pod CIDR og Service CIDR må være unike på tvers av alle klynger og må ikke overlappe.
  2. Alle CIDR Pods må være tilgjengelige fra alle CIDR Pods mellom klynger.
  3. Alle Kubernetes API-servere må være tilgjengelige for hverandre.

Dette er den første informasjonen for å hjelpe deg med å komme i gang med Istio. Imidlertid er det fortsatt mange fallgruver. For eksempel funksjoner for å rute ekstern trafikk (utenfor klyngen), tilnærminger til feilsøking av sidevogner, profilering, sette opp en mikser og skrive en tilpasset mikser-backend, sette opp en sporingsmekanisme og dens drift ved hjelp av envoy.
Alt dette vil vi vurdere i de følgende publikasjonene. Still spørsmålene dine, jeg skal prøve å dekke dem.

Kilde: www.habr.com

Legg til en kommentar