Behärska Service Mesh Arkitektur med Istio

1. Introduktion

Avslöja magin i service mesh-arkitekturen och se hur den superladdar dina distribuerade system.

Dyk djupt in i Istio, service mesh-stjärnan, och lär dig hur den perfekt orkestrerar ditt Kubernetes-kluster.

2. Vad är en Service Mesh?

Monolitiska applikationer har utvecklats till mindre, oberoende tjänster. Denna förändring har fått enorm popularitet med molnbaserad databehandling och mikroservicerarkitektur. Verktyg som Docker och Kubernetes har accelererat denna trend.

Mikroservicer på plattformar som Kubernetes erbjuder många fördelar, men de medför också komplexiteter. Att hantera kommunikationen mellan dessa distribuerade tjänster kräver noggrant övervägande av upptäckten, routing, omförsök och failover.

Ytterligare utmaningar inkluderar säkerhet och observabilitet.

Dessa proxies bildar ett meshnätverk för tjänsterna, därav namnet. Service mesh kontrollerar varje aspekt av service-till-service kommunikation, vilket gör det möjligt att ta itu med de åtta illusionerna av distribuerad databehandling.

4. Istio Avslöjad

Istio, en öppen källkods service mesh skapad av IBM, Google och Lyft, förstärker osynligt distribuerade applikationer med trafikhantering, säkerhet och prestandainsikter.

Flexibelt distribuerad på plats, i molnet, inom Kubernetes eller på virtuella maskiner, glänser Istio med mikroservicer på Kubernetes. Även om det är plattformsoberoende är det en naturlig passform för containeriserade miljöer.

I sin kärna distribuerar Istio Envoy-proxies som sidokärnor tillsammans med varje mikroservice:

Detta proxy-nätverk utgör Istios dataplan, orkestrerad av kontrollplanen:

Istios anpassningsförmåga lyser genom sömlös integration med externa loggning-, telemetry- och policysystem.

5. Avslöja Istios Byggstenar

Istios arkitektur är en dynamisk duo: dataplanen och kontrollplanen. Tillsammans orkestrerar de magin bakom Istios kapabiliteter. Låt oss dyka ner i kärnkomponenterna som driver denna exceptionella plattform.

Gör dig redo att utforska de intrikata detaljerna i Istios kärnkomponenter.

5.1. Dataplanen: Envoys Epicentrum

Istios dataplan är i grunden en förstärkt version av Envoy-proxyn. Detta öppen källkods underverk hanterar nätverkskomplexiteter, vilket frigör applikationer för att fokusera på sin kärnverksamhet. Applikationer interagerar sömlöst, okunniga om den komplexa nätverksinfrastrukturen.

I sin kärna är Envoy en nätverkswizard som arbetar på lager 3 och 4 av OSI-modellen. Den hanterar anslutningar skickligt med en kedja av anpassningsbara nätverksfilter. Utöver detta gör Envoys L7-lagerfilter att den kan hantera HTTP-trafik med finess. Och det är inte allt - det är naturligt med HTTP/2 och gRPC-protokoll.

Många av Istios utmärkande funktioner är faktiskt superkrafter som ärvs från Envoys inbyggda förmågor:

• Trafikhantering: Envoy har detaljerad kontroll över HTTP, gRPC, WebSocket och TCP-trafik, som dirigeras med precision.
• Nätverksresiliens: Inbyggda automatiska omförsök, kretsbrytning och felinjektion säkerställer obeveklig nätverkspålitlighet.
• Säkerhet: Skydda din kommunikation med robusta säkerhetspolicys, åtkomstkontroll och hastighetsbegränsning.

Envoys sanna potential lyser när den kombineras med Istio. Dess utvidgningsförmåga, drivs av WebAssembly, är en spelväxlare för anpassad policys genomförande och telemetry. Dessutom öppnar Istios Proxy-Wasm sandbox-API dörrar till ännu fler Envoy-anpassningar.

5.2. Kontrollplanen: Istiods Maestro

Möt istiod, dirigenten av Istios kontrollplansorkester. Denna maestro omvandlar hög-nivå routingregler och trafikhanteringsdirektiv till Envoy-vänliga konfigurationer och distribuerar dem sömlöst till sidokärnorna.

Kommer du ihåg Istios tidigare arkitektur med sina individuella komponenter? För att förenkla saker slogs dessa komponenter ihop till den enade istiod. Men frukta inte, kärnfunktionerna förblir intakta.

I sin kärna använder istiod samma kod och API:er som sina föregångare. Pilot, till exempel, fortsätter att vara dirigenten för serviceupptäckten, som översätter plattformspecifika detaljer till ett universellt språk som sidokärnorna förstår. Denna flexibilitet gör att Istio kan harmonisera med olika miljöer som Kubernetes och virtuella maskiner.

Istiod tar också ansvar för säkerheten, vilket upprättar robust autentisering mellan tjänster och slutanvändare med sitt inbyggda identitets- och certifikathanteringssystem. Genomför detaljerade säkerhetspolicys baserat på tjänstidentitet med lätthet. Dessutom fungerar istiod som en pålitlig certifikatutfärdare (CA), som utfärdar certifikat för att säkra kommunikationen mellan tjänster med hjälp av mutual TLS (MTLS).

6. Hur Istio Fungerar

Vi har utforskat de typiska funktionerna hos en service mesh och dissekerat Istios arkitektur och kärnkomponenter. Låt oss nu avslöja hur Istio levererar dessa funktioner med sina kärnkomponenter.

Vi kommer att återbesöka samma funktionskategorier som vi utforskade tidigare.

6.1. Trafikhantering

Istios trafikhanterings-API erbjuder detaljerad kontroll över service mesh-trafik. Skräddarsy trafikconfigar med hjälp av dessa API:er och definiera API-resurser med Kubernetes anpassade resursdefinitioner (CRD). Nyckel-API-resurser för trafikrouting är virtuella tjänster och destinationsregler:

En virtuell tjänst dikterar hur förfrågningar dirigeras till en tjänst inom Istio-mesh. Den består av en eller flera routingregler som utvärderas sekventiellt. Efter routing av den virtuella tjänsten tillämpas destinationsregler för att kontrollera trafiken till en destination, såsom gruppering av tjänsteinstanser efter version.

6.2. Säkerhet

Istios säkerhetsgrund är starka identiteter för varje tjänst. Istio-agenter bredvid varje Envoy-proxy samarbetar med istiod för att automatisera nyckel- och certifikatsrotation:

Istio stöder två autentiseringstyper: peer-autentisering och begäran-autentisering. Peer-autentisering säkrar service-till-service kommunikation med Istios mutual TLS-lösning. Begäran-autentisering hanterar slutanvändarautentisering genom JSON Web Token (JWT) validering med en anpassad autentiseringsleverantör eller OpenID Connect (OIDC) leverantör.

Istio genomför tjänståtkomstkontroll genom att tillämpa auktoriseringspolicys. Dessa policys reglerar inkommande trafik i Envoy-proxyn, vilket möjliggör åtkomstkontroll på mesh-, namespace- och tjänstenivå.

6.3. Observabilitet

Istio genererar omfattande telemetri, inklusive metrik, distribuerade spår och åtkomstloggar, för all servicekommunikation inom mesh. Denna telemetri omfattar proxy-nivå, service-orienterade och kontrollplan-metrik.

Tidigare var Mixer den centrala komponenten i Istios telemetriarkitektur. Men Telemetri v2 ersätter Mixers funktioner med Envoy-proxy-plugin:

Istio skapar distribuerade spår genom Envoy-proxies och stöder olika spårningsbakgrunder som Zipkin, Jaeger, Lightstep och Datadog. Spårningsgenereringens provtagningsfrekvens är konfigurerbar. Dessutom genererar Istio åtkomstloggar för trafik av tjänster i anpassningsbara format.

7. Dyk in i Istio

Nog med bakgrund, låt oss se Istio i aktion! Vi kommer att installera Istio på ett Kubernetes-kluster och använda en enkel mikroservice-app för att visa dess kraft.

7.1 Installation

Istio installeras på olika sätt, men att ladda ner och extrahera den senaste versionen för ditt operativsystem (som Windows) är enklast. Det extraherade paketet innehåller istioctl-klienten i bin-mappen. Använd istioctl för att installera Istio på ditt Kubernetes-kluster:

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled

Vi använder kubectl här, med antagandet att du har ett Kubernetes-kluster (som Minikube) och Kubernetes CLI kubectl konfigurerat.

7.2 Exempelapplikation

Föreställ dig en enkel online beställningsapp för denna demo. Den består av tre mikroservicer som samarbetar för att uppfylla beställningar:

Vi kommer inte att gå in på detaljerna om mikroservicen, men de är lätta att skapa med Spring Boot och REST API:er. Viktigt är att skapa Docker-bilder för dessa mikroservicer för att distribuera på Kubernetes.

7.3 Distribution

Att distribuera containeriserade arbetsbelastningar på Kubernetes-kluster som Minikube är enkelt. Använd distributions- och servicetjänster för att deklarera och få tillgång till arbetsbelastningen. Vanligtvis definieras de i en YAML-fil:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

Eftersom vi aktiverade automatisk injektion av Envoy sidokärnsproxies för standardnamnområdet, hanteras allt. Eller, injicera manuellt Envoy sidokärnsproxies med hjälp av istioctl's kube-inject kommando.

7.4 Åtkomst till Applikationen

Istio hanterar främst mesh-trafik. Som standard blockeras trafik till eller från utsidan av mesh. Istio använder gateways för att hantera in- och utgående mesh-trafik, vilket ger dig exakt kontroll över vad som kommer in eller lämnar. Istio erbjuder förkonfigurerade gateway-proxydistributioner: istio-ingressgateway och istio-egressgateway.

Skapa en Gateway och Virtuell Tjänst för din app:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

8 Vanliga Istio Användningsfall

Vi har distribuerat en enkel app på Kubernetes med Istio. Låt oss utforska Istios kraftfulla funktioner och se hur de kan förbättra vår applikation.

8.1 Begäran Routing

Föreställ dig att du distribuerar flera versioner av en mikroservice som frakttjänsten. Du vill gradvis införa nya funktioner utan att påverka alla användare. Begärningsrouting låter dig göra detta genom att dirigera en del av trafiken till den senaste versionen.

Använd virtuella tjänstroutingregler för att uppnå detta.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Routingregler kan också filtrera trafik baserat på huvuden eller andra attribut. Destinationsfältet specificerar måltjänsten för matchande förfrågningar.

8.2 Kretsbrytning

Förhindra kaskadfel med kretsbrytare. Detta mönster upptäcker fel och stoppar tillfälligt trafik till tjänster som misslyckas, vilket skyddar din applikations övergripande hälsa.

Istios Destinationsregel låter dig konfigurera kretsbrytningsbeteende för tjänster som lager-tjänsten.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

Genom att begränsa maximala anslutningar, väntande förfrågningar och förfrågningar per anslutning kan du effektivt hantera trafik och förhindra överbelastning.

8.3 Aktivera Mutual TLS

Mutual TLS säkerställer säker kommunikation mellan tjänster genom att kräva att båda parter autentiserar sig. Istio aktiverar automatiskt mutual TLS för tjänster med hjälp av sina proxys.

Medan Istio genomför mutual TLS mellan proxy-tjänster, kan okrypterad trafik fortfarande nå tjänster utan proxys. Använd PeerAuthentication-poliser för att genomdriva mutual TLS över hela ditt mesh.

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

Du kan tillämpa mutual TLS på mesh-, namespace- eller tjänstenivå. Tjänstespecifika policys åsidosätter namespace-omfattande inställningar.

8.4 Åtkomstkontroll med JWT

JSON Web Tokens (JWT) är en standard för att säkert överföra användarinformation. De används ofta för autentisering och auktorisering.

Istios AuthorizationPolicy låter dig kontrollera åtkomst till tjänster som bokningstjänsten baserat på JWT-krav.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["[email protected]/[email protected]"]

Kräv giltiga JWT med specifika krav för auktoriserad åtkomst. Istio skapar en requestPrincipal-attribut från JWT:s utfärdare och ämneskrav.

9. Slutliga Tankar

Istio förenklar hanteringen av vanliga utmaningar i distribuerade mikroservicearkitekturer. Men dess komplexitet kan tillföra overhead till distributioner. Precis som med vilket verktyg som helst är Istio inte en magisk lösning och kräver noggrant övervägande.

9.1. Är en Service Mesh Alltid Nödvändig?

Även om service mesh erbjuder fördelar, överväg dessa nackdelar:

Service mesh erbjuder fördelar, men noggrant utvärdering av din applikations komplexitet är avgörande. Väg fördelarna mot den tillagda komplexiteten.

9.2. Istio Alternativ

Istio är en populär service mesh som stöds av branschledare, men det är inte det enda alternativet. Här är en kort översikt av Linkerd och Consul.

Linkerd är en Kubernetes-nativ, öppen källkod service mesh som växer i popularitet. Det är ett CNCF inkuberingsprojekt och fungerar liknande Istio, med hjälp av TCP-proxys. Linkerds Rust-baserade mikro-proxy kallas Linkerd-proxy.

Linkerd är generellt enklare än Istio på grund av sitt fokus på Kubernetes. Men dess funktionsuppsättning liknar Istios, och dess kärnarkitektur är liknande. Linkerd består av ett användargränssnitt, dataplan och kontrollplan.

Consul är en öppen källkod service mesh från HashiCorp som integreras med andra HashiCorp-infrastrukturverktyg. Consuls dataplan stöder både proxy- och inbyggda integrationsmodeller. Den erbjuder en inbyggd proxy men kan också fungera med Envoy.

Consul fungerar bortom Kubernetes och stöder plattformar som Nomad. Det använder agenter på varje nod för hälsokontroller och kommunicerar med Consul-servrar för datalagring och replikering. Även om det erbjuder standardfunktioner för service mesh är Consul mer komplext att distribuera och hantera.

10. Sammanfattning

Denna handledning har utforskat grunderna i service mesh-arkitektur och Istios kraftfulla kapabiliteter. Vi har dykt ner i Istios kärnstruktur, komponenter och praktiska tillämpningar. I slutet bör du ha en solid förståelse för hur man installerar och använder Istio för vanliga scenarier.