Hvordan man starter Istio ved hjælp af Kubernetes i produktion. Del 1

Hvad er Istio? Это так называемый Service mesh, технология, которая добавляет уровень абстракции над сетью. Мы перехватываем весь или часть трафика в кластере и производим определенный набор операций с ним. Какой именно? Например, делаем умный роутинг, или реализуем подход circuit breaker, можем организовывать «canary deployment», частично переключая трафик на новую версию сервиса, а можем ограничивать внешние взаимодействия и контролировать все походы из кластера во внешнюю сеть. Есть возможность задавать policy правила для контроля походов между разными микросервисами. Наконец, мы можем получить всю карту взаимодействия по сети и сделать унифицированный сбор метрик полностью прозрачно для приложений.

Du kan læse om mekanismen bag arbejdet i den officielle dokumentation. Istio er et virkelig kraftfuldt værktøj, der kan løse mange opgaver og problemer. I denne artikel vil jeg gerne besvare de vigtigste spørgsmål, der ofte opstår i starten af arbejdet med Istio. Det vil hjælpe dig med at forstå det hurtigere.

Arbejdets princip

Istio består af to hovedområder — kontrolplanet og dataplanet. Kontrolplanet indeholder de vigtigste komponenter, der sikrer korrekt drift af de øvrige. I den nuværende version (1.0) har kontrolplanet tre hovedkomponenter: Pilot, Mixer, Citadel. Citadel vil vi ikke behandle, det er nødvendigt for at generere certifikater til sikring af mutual TLS mellem tjenester.

Pilot er den primære styringskomponent, der distribuerer al information om, hvad vi har i klyngen – tjenester, deres endpoints og routingregler (for eksempel regler for Canary deployment eller circuit breaker-regler).

Mixer er en valgfri komponent i kontrolplanet, der giver mulighed for indsamling af målinger, logs og enhver information om netværksinteraktion. Den holder også øje med overholdelsen af politikregler og overholdelsen af rate limits.

Dataplanet implementeres ved hjælp af sidecar proxy-containere. Standard bruges en kraftfuld proxy-server envoy. Den kan erstattes af en anden implementering, for eksempel nginx (nginmesh).

For at Istio skal fungere helt gennemsigtigt for applikationer, findes der et system til automatisk injektion. Den seneste implementering er velegnet til versioner af Kubernetes 1.9+ (mutational admission webhook). For Kubernetes versioner 1.7, 1.8 er der mulighed for at bruge Initializer.

Sidecar-containere tilsluttes til Pilot via GRPC-protokollen, som muliggør optimering af model for push af ændringer, der sker i klyngen. GRPC blev brugt i Envoy fra version 1.6, i Istio er det anvendt fra version 0.8 og repræsenterer pilot-agent — en wrapper på golang oven på envoy, der konfigurerer opstartparametre.

Pilot og Mixer er fuldstændig stateless komponenter, alt deres tilstand opbevares i hukommelsen. Konfigurationen for dem angives i form af Kubernetes Custom Resources, som gemmes i etcd.
Istio-agenten får adressen til Pilot og åbner en GRPC-strøm til den.

Som jeg allerede har sagt, implementerer Istio al funktionalitet helt gennemsigtigt for applikationer. Lad os finde ud af hvordan. Algoritmen er sådan:

1. Vi deployerer en ny version af tjenesten.
2. Afhængigt af tilgangen til injecting af sidecar containeren tilføjes istio-init containeren og istio-agent containeren (envoy) på tidspunktet for anvendelse af konfigurationen, eller de kan allerede være manuelt indsat i beskrivelsen af Pod enheden i Kubernetes.
3. istio-init containeren er et script, der anvender iptables regler for pod'en. Der er to muligheder for at konfigurere indpakningen af trafikken til istio-agent containeren: bruge redirect iptables regler, eller TPROXY. På tidspunktet for skrivningen af artiklen anvendes redirect regler som standard. I istio-init er der mulighed for at konfigurere, hvilken trafik der skal fanges og dirigeres til istio-agent. For eksempel, for at fange al indgående og al udgående trafik, skal parametre indstilles -i og -b til værdien *. Man kan angive specifikke porte, der skal fanges. For at undgå at fange en bestemt subnet kan den angives ved hjælp af flaget -x.
4. Efter udførelsen af init containerne startes de primære, herunder pilot-agent (envoy). Den tilslutter sig allerede implementeret Pilot via GRPC og modtager information om alle eksisterende tjenester og routing politikker i klyngen. Baseret på de modtagne data konfigurerer den klynger og angiver direkte endpoints for vores applikationer i Kubernetes klyngen. Det er også vigtigt at bemærke et væsentligt punkt: envoy konfigurerer dynamisk lyttere (par af IP, port), som den begynder at lytte til. Derfor, når anmodningerne kommer ind i pod'en, omdirigeres de ved hjælp af redirect iptables regler til sidecar'en, og envoy kan allerede succesfuldt håndtere disse forbindelser og forstå, hvor trafikken skal sendes videre. På dette trin sker der også en sending af information til Mixer, som vi vil se nærmere på senere, og sending af tracing spans.

Som et resultat får vi et helt netværk af envoy proxy-servere, som vi kan konfigurere fra et centralt punkt (Pilot). Alle inbound og outbound anmodninger passerer gennem envoy. Desuden fanges kun TCP trafik. Det betyder, at Kubernetes service IP'en opløses ved hjælp af kube-dns over UDP uden ændringer. Derefter, efter opløsningen, sker der en indfangning af den udgående anmodning og behandling af envoy'en, som allerede beslutter, hvilken endpoint anmodningen skal sendes til (eller ikke sendes, i tilfælde af adgangspolitikker eller circuit breaker algoritmen aktiveres).

Nu hvor vi har forstået Pilot, skal vi nu forstå, hvordan Mixer fungerer, og hvorfor det er nødvendigt. Den officielle dokumentation for det kan læses her.

Mixer i sin nuværende form består af to komponenter: istio-telemetry, istio-policy (indtil version 0.8 var det én komponent, istio-mixer). Begge repræsenterer mixer, hvor hver især har sin egen opgave. Istio telemetry modtager via GRPC fra sidecar-containere Report information om, hvem der går hvor hen, og med hvilke parametre. Istio-policy modtager Check-forespørgsler for at kontrollere opfyldelsen af politikregler. Policy-tjek udføres selvfølgelig ikke på hver forespørgsel, men caches på klienten (i sidecar) i en bestemt tidsperiode. Report-tjek sendes i batch-forespørgsler. Hvordan man konfigurerer og hvilke specifikke parametre der skal sendes, ser vi lidt senere.

Mixer er designet som en højtilgængelig komponent, der sikrer en uafbrudt drift i indsamlingen og behandlingen af telemetry-data. Systemet ender derfor som en flerlagspuffer. Oprindeligt buffes data på siden af sidecar-containere, derefter på siden af mixer, og sendes så til de såkaldte mixer-backend'er. Så hvis en af systemets komponenter fejler, vokser pufferen, og efter systemets genopretning tømmes den. Mixer-backend'er repræsenterer slutpunkterne for sending af telemetry-data: statsd, newrelic osv. Man kan skrive sin egen backend, det er relativt enkelt, og vi ser på, hvordan man gør dette.

Sammenfattende er arbejdsordenen med istio-telemetry som følger.

1. Service 1 sender en forespørgsel til service 2.
2. Ved udgang fra service 1 pakkes forespørgslen ind i dens egen sidecar.
3. Sidecar envoy holder øje med, hvordan forespørgslen forløber til service 2 og forbereder de nødvendige oplysninger.
4. Derefter sender den disse oplysninger til istio-telemetry via en Report-forespørgsel.
5. Istio-telemetry bestemmer, om denne Report skal sendes til backend'er, til hvilke specifikt, og hvilke data der skal sendes.
6. Istio-telemetry sender Report-data til backend, hvis det er nødvendigt.

Lad os nu se, hvordan man implementerer et system i Istio, der kun består af de grundlæggende komponenter (Pilot og sidecar envoy).

Først ser vi på den grundlæggende konfiguration (mesh), som Pilot læser:

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

    # Vi aktiverer stadig ikke sendning af tracing information (pilot konfigurerer envoy'erne således, at der ikke vil blive sendt indhold)
    enableTracing: false

    # Vi angiver stadig ikke mixer endpoint’ene, så sidecar containere ikke sender information dertil
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # Vi angiver den tidsperiode, hvor envoy vil spørge Pilot igen (dette er for den gamle version af envoy proxy)
    rdsRefreshDelay: 5s

    # default konfiguration for envoy sidecar
    defaultConfig:
      # ligesom rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # vi efterlader som standard (stien til konfigurationen og binæren for envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # standardnavn for den kørende sidecar container (bruges f.eks. i servicenavne ved sending af tracing span'ene)
      serviceCluster: istio-proxy

      # tiden, som envoy venter, før den tvangsmæssigt afslutter alle etablerede forbindelser
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # som standard bruges REDIRECT regler iptables. Kan ændres til TPROXY.
      #interceptionMode: REDIRECT

      # Porten, hvor adminpanelet for hver sidecar container (envoy) vil blive kørt
      proxyAdminPort: 15000

      # adressen, hvor tracing vil blive sendt via zipkin protokollen (til at begynde med har vi slået selve afsendelsen fra, så dette felt vil ikke blive brugt nu)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd adresse til at sende metrics fra envoy containere (slukket)
      # statsdUdpAddress: aggregator:8126

      # slukker for understøttelse af Mutual TLS optionen
      controlPlaneAuthPolicy: NONE

      # adressen, hvor istio-pilot vil lytte for at informere om service discovery til alle sidecar containere
      discoveryAddress: istio-pilot.istio-system:15007

Vi placerer alle hovedkomponenter til kontrolplanen i namespace istio-system i Kubernetes.

Minimum kræver vi kun at implementere Pilot. Til dette vil vi bruge denne konfiguration.

Og vi konfigurerer manuelt injecting sidecar containeren.

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 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

For everything to start successfully, a ServiceAccount, ClusterRole, ClusterRoleBinding, and CRD for Pilot need to be created, the descriptions of which can be found her.

As a result, the service into which we inject the sidecar with envoy should successfully start, receive all discovery from the pilot, and handle requests.

It is important to understand that all components of the control plane are stateless applications and can be easily scaled horizontally. All data is stored in etcd as custom Kubernetes resource descriptions.

Istio also has the option (currently experimental) to run outside the cluster and the ability to view and share service discovery between multiple Kubernetes clusters. More details can be found her.

When performing a multi-cluster installation, the following limitations should be considered:

1. Pod CIDR and Service CIDR must be unique across all clusters and must not overlap.
2. All Pod CIDRs must be accessible from any Pod CIDRs between clusters.
3. All Kubernetes API servers must be accessible to one another.

These are initial insights that will help you get started with Istio. However, there are still many pitfalls. For example, the peculiarities of routing external traffic (out of the cluster), approaches to debugging sidecars, profiling, configuring the mixer and writing a custom mixer backend, setting up tracing mechanisms, and how they work with envoy.
Vi vil dække alt dette i de kommende artikler. Stil dine spørgsmål, så vil jeg gøre mit bedste for at besvare dem.

Kilde: habr.com