🥇 Hur man kör Istio med Kubernetes i produktion. Del 1

Vad är Samma? Detta är det så kallade Service mesh, en teknik som lägger till ett lager av abstraktion över nätverket. Vi avlyssnar hela eller delar av trafiken i klustret och utför en viss uppsättning operationer med den. Vilken? Till exempel gör vi smart routing, eller så implementerar vi kretsbrytarmetoden, vi kan organisera "kanarie-utbyggnad", delvis byta trafik till en ny version av tjänsten, eller så kan vi begränsa extern interaktion och kontrollera alla resor från klustret till klustret. externt nätverk. Det är möjligt att sätta policyregler för att kontrollera resor mellan olika mikrotjänster. Slutligen kan vi få hela nätverksinteraktionskartan och göra den enhetliga samlingen av mätvärden helt transparent för applikationer.

Du kan läsa om arbetsmekanismen i officiell dokumentation. Istio är ett riktigt kraftfullt verktyg som låter dig lösa många uppgifter och problem. I den här artikeln skulle jag vilja svara på de viktigaste frågorna som brukar dyka upp när man kommer igång med Istio. Detta kommer att hjälpa dig att hantera det snabbare.

Funktionsprincip

Istio består av två huvudområden - kontrollplanet och dataplanet. Kontrollplanet innehåller huvudkomponenterna som säkerställer att resten fungerar korrekt. I den nuvarande versionen (1.0) har kontrollplanet tre huvudkomponenter: Pilot, Mixer, Citadel. Vi kommer inte att överväga Citadel, det behövs för att generera certifikat för att säkerställa ömsesidig TLS mellan tjänster. Låt oss ta en närmare titt på enheten och syftet med Pilot och Mixer.

Pilot är huvudkontrollkomponenten som distribuerar all information om vad vi har i klustret - tjänster, deras ändpunkter och routingregler (till exempel regler för Canary-utbyggnad eller regler för strömbrytare).

Mixer är en valfri kontrollplanskomponent som ger möjlighet att samla in mätvärden, loggar och all information om nätverksinteraktion. Han övervakar också efterlevnaden av policyregler och efterlevnaden av räntegränser.

Dataplanet implementeras med hjälp av sidovagnsproxycontainrar. Powerful används som standard. sändebudsfullmakt. Den kan ersättas av en annan implementering, till exempel nginx (nginmesh).

För att Istio ska fungera helt transparent för applikationer finns ett automatiskt insprutningssystem. Den senaste implementeringen är lämplig för Kubernetes 1.9+ versioner (mutationsadmission webhook). För Kubernetes version 1.7, 1.8 är det möjligt att använda Initializer.

Sidovagnscontainrar är anslutna till Pilot med GRPC-protokollet, vilket gör att du kan optimera push-modellen för förändringar som sker i klustret. GRPC har använts i Envoy sedan version 1.6, i Istio har det använts sedan version 0.8 och är en pilotagent - en golang-omslag över envoy som konfigurerar startalternativ.

Pilot och Mixer är helt tillståndslösa komponenter, alla tillstånd sparas i minnet. Konfigurationen för dem ställs in i form av Kubernetes Custom Resources, som lagras i etcd.
Istio-agent får pilotens adress och öppnar en GRPC-ström till den.

Som sagt implementerar Istio all funktionalitet helt transparent för applikationer. Låt oss se hur. Algoritmen är denna:

Implementerar en ny version av tjänsten.
Beroende på tillvägagångssättet för insprutning av sidovagnscontainer, läggs istio-init-behållaren och istio-agent-behållaren (envoy) till när konfigurationen tillämpas, eller så kan de redan infogas manuellt i beskrivningen av Kubernetes Pod-entiteten.
istio-init-behållaren är ett skript som tillämpar iptables-reglerna på podden. Det finns två alternativ för att konfigurera trafik så att den lindas i en istio-agentbehållare: använd iptables omdirigeringsregler, eller TPROXY. I skrivande stund är standardmetoden med omdirigeringsregler. I istio-init är det möjligt att konfigurera vilken trafik som ska avlyssnas och skickas till istio-agent. Till exempel, för att fånga upp all inkommande och all utgående trafik måste du ställa in parametrarna -i и -b till mening *. Du kan ange specifika portar att avlyssna. För att inte fånga upp ett specifikt undernät kan du ange det med flaggan -x.
Efter att init-behållarna har körts, startas de viktigaste, inklusive pilotagenten (sände). Den ansluter till den redan utplacerade piloten via GRPC och tar emot information om alla befintliga tjänster och routingpolicyer i klustret. Enligt mottagna data konfigurerar han klustren och tilldelar dem direkt till slutpunkterna för våra applikationer i Kubernetes-klustret. Det är också nödvändigt att notera en viktig punkt: envoy konfigurerar dynamiskt lyssnare (IP, portpar) som den börjar lyssna på. Därför, när förfrågningar kommer in i podden, omdirigeras med hjälp av reglerna för omdirigering av iptables i sidovagnen, kan envoy redan framgångsrikt bearbeta dessa anslutningar och förstå var trafiken ska skickas vidare. Även i detta skede skickas information till mixern, som vi kommer att titta på senare, och spårningsspann skickas.

Som ett resultat får vi ett helt nätverk av envoy-proxyservrar som vi kan konfigurera från en punkt (Pilot). Alla inkommande och utgående förfrågningar går via envoy. Dessutom avlyssnas endast TCP-trafik. Detta innebär att Kubernetes tjänst IP löses med kube-dns över UDP utan att ändras. Sedan, efter beslutet, fångas den utgående begäran upp och bearbetas av envoy, som redan beslutar vilken slutpunkt begäran ska skickas till (eller inte skickas, i fallet med åtkomstpolicyer eller algoritmens strömbrytare).

Vi kom på Pilot, nu måste vi förstå hur Mixer fungerar och varför det behövs. Du kan läsa den officiella dokumentationen för det här.

Mixer i sin nuvarande form består av två komponenter: istio-telemetri, istio-policy (före version 0.8 var det en istio-mixer-komponent). Båda är blandare, som var och en ansvarar för sin egen uppgift. Istio telemetri får information om vem som går vart och med vilka parametrar från sidovagnsrapportcontainrar via GRPC. Istio-policy accepterar Check-förfrågningar för att verifiera att policyreglerna är uppfyllda. Poilicy-kontroller utförs naturligtvis inte för varje förfrågan, utan cachelagras på klienten (i sidvagnen) under en viss tid. Rapportkontroller skickas som batchförfrågningar. Låt oss se hur man konfigurerar och vilka parametrar som ska skickas lite senare.

Mixern är tänkt att vara en mycket tillgänglig komponent som säkerställer ett oavbrutet arbete med sammansättning och bearbetning av telemetridata. Systemet erhålls som ett resultat som en flernivåbuffert. Initialt buffras data på sidovagnssidan av containrar, sedan på mixersidan och skickas sedan till de så kallade mixerbackends. Som ett resultat, om någon av systemkomponenterna misslyckas, växer bufferten och töms efter att systemet har återställts. Mixerbackends är slutpunkter för att skicka telemetridata: statsd, newrelic, etc. Du kan skriva din egen backend, det är ganska enkelt, och vi får se hur du gör det.

För att sammanfatta är schemat för att arbeta med istio-telemetri som följer.

Tjänst 1 skickar en förfrågan till tjänst 2.
Vid avgång från tjänst 1 är förfrågan inslagen i egen sidvagn.
Sidecar envoy övervakar hur förfrågan går till tjänst 2 och förbereder nödvändig information.
Skickar den sedan till istio-telemetri med en rapportförfrågan.
Istio-telemetri avgör om denna rapport ska skickas till backends, till vilken och vilken data som ska skickas.
Istio-telemetri skickar rapportdata till backend om det behövs.

Låt oss nu se hur man distribuerar Istio i systemet, som endast består av huvudkomponenterna (pilot och sidovagnssände).

Låt oss först titta på huvudkonfigurationen (mesh) som Pilot läser:

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

Alla huvudkontrollkomponenter (kontrollplan) kommer att finnas i namnutrymmet istio-system i Kubernetes.

Som ett minimum behöver vi bara distribuera Pilot. För detta använder vi en sådan konfiguration.

Och vi kommer att manuellt konfigurera behållarens injicerande sidovagn.

Init behållare:

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

Och sidvagn:

       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

För att allt ska starta framgångsrikt måste du skapa ett ServiceAccount, ClusterRole, ClusterRoleBinding, CRD for Pilot, vars beskrivningar kan hittas här.

Som ett resultat bör tjänsten som vi injicerar sidovagn med envoy i starta framgångsrikt, ta emot all upptäckt från piloten och processförfrågningar.

Det är viktigt att förstå att alla styrplanskomponenter är tillståndslösa applikationer och kan skalas horisontellt utan problem. All data lagras i etcd i form av anpassade beskrivningar av Kubernetes-resurser.

Dessutom har Istio (fortfarande experimentell) förmågan att köra utanför klustret och förmågan att titta på och fumla tjänsteupptäckt mellan flera Kubernetes-kluster. Du kan läsa mer om detta här.

För en installation med flera kluster, var medveten om följande begränsningar:

Pod CIDR och Service CIDR måste vara unika för alla kluster och får inte överlappa varandra.
Alla CIDR Pods måste vara tillgängliga från alla CIDR Pods mellan kluster.
Alla Kubernetes API-servrar måste vara tillgängliga för varandra.

Detta är den första informationen som hjälper dig att komma igång med Istio. Men det finns fortfarande många fallgropar. Till exempel funktioner för att dirigera extern trafik (utanför klustret), metoder för att felsöka sidvagnar, profilering, ställa in en mixer och skriva en anpassad mixer-backend, ställa in en spårningsmekanism och dess funktion med hjälp av envoy.
Allt detta kommer vi att överväga i följande publikationer. Ställ dina frågor, jag ska försöka täcka dem.

Källa: will.com

Hur man kör Istio med Kubernetes i produktion. Del 1

Funktionsprincip

Lägg en kommentar Avbryt svar