🥇Hoe Istio op te zetten met Kubernetes in productie. Deel 1

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

Over de werking kunt u lezen in de officiële documentatie. Istio is een echt krachtig hulpmiddel dat een groot aantal taken en problemen kan oplossen. In dit artikel wil ik de belangrijkste vragen beantwoorden die meestal aan de orde komen bij het begin van het werken met Istio. Dit zal u helpen er sneller mee aan de slag te gaan.

Werking principe

Istio bestaat uit twee hoofdgebieden - de control plane en de data plane. De control plane bevat de belangrijkste componenten die de correcte werking van de overige onderdelen waarborgen. In de huidige versie (1.0) heeft de control plane drie hoofdcomponenten: Pilot, Mixer, en Citadel. Citadel behandelen we niet, dit is nodig voor het genereren van certificaten om mutual TLS tussen services mogelijk te maken. Laten we dieper ingaan op de structuur en het doel van Pilot en Mixer.

Pilot is de belangrijkste beheerscomponent die alle informatie verspreidt over wat we in de cluster hebben - services, hun endpoints en routingregels (bijvoorbeeld regels voor Canary deployment of circuit breaker-regels).

Mixer is een optionele component van de control plane, die de mogelijkheid biedt om statistieken, logs en andere informatie over netwerkinteracties te verzamelen. Het houdt ook toezicht op de naleving van beleid en de naleving van rate limits.

De data plane wordt geïmplementeerd met sidecar proxy-containers. Standaard wordt een krachtige proxyserver envoygebruikt. Dit kan worden vervangen door een andere implementatie, zoals nginx (nginmesh).

Om ervoor te zorgen dat Istio volledig transparant werkt voor applicaties, is er een automatisch injectiesysteem. De laatste implementatie is geschikt voor Kubernetes-versies 1.9+ (mutational admission webhook). Voor Kubernetes-versies 1.7 en 1.8 is er de mogelijkheid om Initializer te gebruiken.

Sidecar-containers verbinden met Pilot via het GRPC-protocol, dat het push-model van veranderingen in de cluster optimaliseert. GRPC werd voor het eerst gebruikt in Envoy vanaf versie 1.6, in Istio wordt het gebruikt vanaf versie 0.8 en vormt pilot-agent - een wrapper in golang bovenop envoy, die de opstartparameters configureert.

Pilot en Mixer zijn volledig stateless componenten, ze houden alle status in het geheugen. De configuratie voor hen wordt gedefinieerd in de vorm van Kubernetes Custom Resources, die worden opgeslagen in etcd.
Istio-agent ontvangt het adres van Pilot en opent een GRPC-stream naar hem.

Zoals ik al zei, realiseert Istio alle functionaliteit volledig transparant voor applicaties. Laten we eens bekijken hoe. Het algoritme is als volgt:

We implementeren een nieuwe versie van de service.
Afhankelijk van de aanpak voor het injecteren van de sidecar-container worden de istio-init container en istio-agent container (envoy) toegevoegd tijdens de configuratie-toepassing, of ze kunnen al handmatig in de beschrijving van de Kubernetes Pod-entiteit zijn ingevoegd.
De istio-init container bevat een script dat iptables-regels toepast voor de pod. Er zijn twee opties voor het configureren van het omleiden van verkeer naar de istio-agent container: gebruik maken van redirect iptables-regels, of TPROXY. Op het moment van schrijven wordt standaard de aanpak met redirect-regels gebruikt. In istio-init is het mogelijk om in te stellen welk verkeer moet worden onderschept en naar de istio-agent moet worden geleid. Bijvoorbeeld, om al het binnenkomende en uitgaande verkeer te onderscheppen, moeten de parameters worden ingesteld -i en -b op de waarde van *. Specifieke poorten die moeten worden onderschept, kunnen worden opgegeven. Om een bepaald subnet niet te onderscheppen, kan dit worden aangegeven met de vlag -x.
Na het uitvoeren van de init-containers worden de hoofdcontainers gestart, inclusief de pilot-agent (envoy). Deze maakt verbinding met de reeds uitgerolde Pilot via GRPC en ontvangt informatie over alle bestaande services en routingbeleid in de cluster. Op basis van de ontvangen gegevens configureert hij de clusters en schrijft hij de endpoint's van onze applicaties in de Kubernetes-cluster. Ook is het belangrijk om een cruciaal punt op te merken: envoy configureert dynamisch listeners (paren van IP, port) die hij begint te beluisteren. Daarom, wanneer verzoeken de pod binnenkomen, worden ze omgeleid via redirect iptables-regels naar de sidecar, kan envoy deze verbindingen succesvol verwerken en begrijpen waar het verkeer verder moet worden geproxy'd. Ook op dit moment wordt informatie verzonden naar Mixer, dat we later zullen bespreken, en worden tracing spans verzonden.

Uiteindelijk hebben we een geheel netwerk van envoy proxy-servers die we vanuit één punt (Pilot) kunnen configureren. Alle inbound en outbound verzoeken passeren via envoy. Daarbij wordt alleen TCP-verkeer onderschept. Dit betekent dat het Kubernetes service IP zonder verandering via kube-dns wordt opgelost met behulp van UDP. Pas na de resolutie vindt de onderschepping van het uitgaande verzoek plaats en wordt dit door envoy verwerkt, die bepaalt naar welke endpoint het verzoek moet worden gestuurd (of het niet versturen, in het geval van toegangsregels of wanneer de circuit breaker-algoritme wordt geactiveerd).

Nu we Pilot hebben begrepen, moeten we kijken hoe Mixer werkt en waarom het nodig is. De officiële documentatie erover kan worden gelezen. here.

Mixer bestaat momenteel uit twee componenten: istio-telemetry, istio-policy (tot versie 0.8 was het één component, istio-mixer). Beide zijn mixers, elk verantwoordelijk voor een specifieke taak. Istio telemetry ontvangt via GRPC van de sidecar-containers Report-informatie over wie waarheen gaat en met welke parameters. Istio-policy ontvangt Check-verzoeken om te controleren of wordt voldaan aan de beleidsregels. Policy-checks worden natuurlijk niet voor elk verzoek uitgevoerd, maar worden in de cache op de client (in de sidecar) voor een bepaalde tijd opgeslagen. Report-checks worden in batch-verzoeken verzonden. We zullen later bekijken hoe we dit kunnen configureren en welke specifieke parameters moeten worden verzonden.

Mixer wordt voorzien als een hoogbeschikbare component die zorgt voor een ononderbroken werking van de verzameling en verwerking van telemetry-gegevens. Het systeem blijkt uiteindelijk een gelaagde buffer te zijn. Aanvankelijk worden de gegevens in de buffer opgeslagen aan de kant van de sidecar-containers, daarna aan de kant van de mixer en vervolgens verzonden naar de zogenaamde mixer backends. Het resultaat is dat als een van de componenten van het systeem faalt, de buffer groeit en na het herstellen van het systeem wordt deze geleegd. Mixer backends zijn de eindpunten voor het verzenden van telemetry-gegevens: statsd, newrelic, enz. Het is vrij eenvoudig om een eigen backend te schrijven, en we zullen bekijken hoe dat moet.

Samenvattend, het werkingsschema van istio-telemetry is als volgt.

Service 1 verzendt een verzoek naar service 2.
Bij het verlaten van service 1 wordt het verzoek ingekapseld door de sidecar van dezelfde service.
De sidecar envoy houdt bij hoe het verzoek naar service 2 verloopt en bereidt de benodigde informatie voor.
Vervolgens wordt deze informatie verzonden naar istio-telemetry met behulp van een Report-verzoek.
Istio-telemetry bepaalt of dit Report naar de backends moet worden verzonden, naar welke precies en welke gegevens moeten worden verzonden.
Istio-telemetry verzendt rapportgegevens naar de backend indien nodig.

Laten we nu bekijken hoe we de basiscomponenten (Pilot en sidecar envoy) in het systeem Istio kunnen implementeren.

Laten we beginnen met de basisconfiguratie (mesh) die Pilot leest:

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

    # voorlopig schakelen we de verzending van trace-informatie niet in (pilot configureert envoy zodanig dat verzending niet plaatsvindt)
    enableTracing: false

    # voorlopig geven we geen mixer-eindpunten op, zodat sidecar-container geen informatie daarheen verzendt
    #mixerCheckServer: istio-policy.istio-system:15004
    #mixerReportServer: istio-telemetry.istio-system:15004

    # we stellen een tijdsinterval in waarover envoy Pilot opnieuw zal vragen (dit is voor de oude versie van envoy proxy)
    rdsRefreshDelay: 5s

    # standaardconfiguratie voor envoy sidecar
    defaultConfig:
      # gelijk aan rdsRefreshDelay
      discoveryRefreshDelay: 5s

      # we laten het standaard (pad naar de configuratie en het binaire bestand van envoy)
      configPath: "/etc/istio/proxy"
      binaryPath: "/usr/local/bin/envoy"

      # standaard naam van de draaiende sidecar-container (gebruikt bijvoorbeeld in servicenamen bij het verzenden van trace-spans)
      serviceCluster: istio-proxy

      # tijd die envoy wacht voordat hij alle geopende verbindingen geforceerd sluit
      drainDuration: 45s
      parentShutdownDuration: 1m0s

      # standaard worden REDIRECT-regels voor iptables gebruikt. Kan worden gewijzigd in TPROXY.
      #interceptionMode: REDIRECT

      # Poort waarop het beheerpaneel van elke sidecar-container (envoy) wordt uitgevoerd
      proxyAdminPort: 15000

      # adres waarnaar trace-informatie op het zipkin-protocol zal worden verzonden (in het begin hebben we de verzending zelf uitgeschakeld, dus dit veld zal momenteel niet worden gebruikt)
      zipkinAddress: tracing-collector.tracing:9411

      # statsd-adres voor het verzenden van statistieken van de envoy-containers (uitgeschakeld)
      # statsdUdpAddress: aggregator:8126

      # ondersteuning voor de optie Mutual TLS uitschakelen
      controlPlaneAuthPolicy: NONE

      # adres waarop istio-pilot luistert om informatie over service discovery naar alle sidecar-containers te verzenden
      discoveryAddress: istio-pilot.istio-system:15007

Alle belangrijke besturingselementen (control plane) plaatsen we in de namespace istio-system in Kubernetes.

Minimaal moeten we alleen Pilot implementeren. Hiervoor gebruiken we deze configuratie.

En we configureren handmatig het injecteren van de sidecar-container.

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

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 succesvol te laten draaien, moet je een ServiceAccount, ClusterRole, ClusterRoleBinding en CRD voor Pilot aanmaken, waarvan de beschrijvingen te vinden zijn. here.

Uiteindelijk moet de service waar we de sidecar met envoy injecteren succesvol opstarten, alle discovery van de pilot ontvangen en verzoeken verwerken.

Het is belangrijk te begrijpen dat alle componenten van de control plane stateless applicaties zijn en probleemloos horizontaal kunnen worden geschaald. Alle gegevens liggen in etcd in de vorm van aangepaste beschrijvingen van Kubernetes-resources.

Ook heeft Istio (voorlopig experimenteel) de mogelijkheid om buiten een cluster te draaien en om service discovery te bekijken en te delen tussen meerdere Kubernetes-clusters. Meer hierover is te lezen. here.

Bij een multi-cluster installatie moeten de volgende beperkingen worden in acht genomen:

Pod CIDR en Service CIDR moeten uniek zijn tussen alle clusters en mogen niet overlappen.
Alle Pod CIDR moeten toegankelijk zijn vanaf elk Pod CIDR tussen de clusters.
Alle Kubernetes API-servers moeten toegankelijk zijn voor elkaar.

Dit zijn de basisgegevens die u helpen om aan de slag te gaan met Istio. Er zijn echter nog veel valkuilen. Bijvoorbeeld, de nuances van routen voor extern verkeer (buiten de cluster), benaderingen voor het debuggen van sidecars, profilering, configuratie van de mixer en het schrijven van een aangepaste mixer backend, het instellen van de tracing-mechanisme en de werking ervan met envoy.
Dit alles zullen we in volgende publicaties behandelen. Stel gerust uw vragen, ik zal mijn best doen om ze te beantwoorden.

Bron: habr.com

Hoe Istio te starten met Kubernetes in productie. Deel 1

Werking principe