Ontdek de magie van service mesh architectuur en zie hoe het jouw gedistribueerde systemen superkracht geeft.
Duik diep in Istio, de ster van service meshes, en leer hoe het jouw Kubernetes-cluster tot in de perfectie orkestreert.
Monolithische applicaties zijn geëvolueerd naar kleinere, onafhankelijke services. Deze verschuiving werd populair met cloud-native computing en microservices-architectuur. Tools zoals Docker en Kubernetes versnelden deze trend.
Microservices op platforms zoals Kubernetes bieden tal van voordelen, maar introduceren ook complexiteit. Het beheren van communicatie tussen deze gedistribueerde services vereist zorgvuldige overweging van ontdekking, routering, retries en failover.
Extra uitdagingen zijn veiligheid en observatie.
Het bouwen van communicatiemogelijkheden in elke service kost veel tijd, vooral naarmate het servicelandschap uitbreidt. Hier komt de service mesh om de hoek kijken. Het beheert alle service-tot-service communicatie binnen een gedistribueerd systeem.
Een service mesh bereikt dit door gebruik te maken van netwerkproxies. Verzoeken tussen services worden door deze proxies geleid, die zich buiten de services bevinden in de infrastructuurlaag:
Deze proxies vormen een mesh-netwerk voor de services, vandaar de naam. Een service mesh beheert elk aspect van service-tot-service communicatie, waardoor het de acht denkfouten van gedistribueerd computeren kan aanpakken.
Ontketen het volledige potentieel van je services met een service mesh! Ontdek hoe deze magische tool je applicatielandschap kan transformeren.
Laten we de magie opsplitsen in drie kernvaardigheden: verkeerswizardry, ijzersterke beveiliging en kristalheldere zichtbaarheid.
Een service mesh is je ultieme verkeersagent, die service-interacties met precisie aanstuurt. Geniet van dynamische routering, slimme ontdekking en waanzinnige functies zoals verkeersschaduwing en -splitsing voor naadloze canary-releases en A/B-testexperimenten.
Zeg vaarwel tegen onbetrouwbare verbindingen! Een service mesh wikkelt je services in een warme deken van betrouwbaarheid, met retries, time-outs, snelheidslimitering en circuit-breakers om je apps te beschermen tegen chaos.
Bescherm je services met een ondoordringbaar fort! Een service mesh versleutelt alle communicatie met robuuste MTLS, verifieert identiteiten met strikte authenticatie en handhaaft toegangsregels voor ultieme bescherming.
Ontdek verborgen beveiligingssuperkrachten! Isoleer services, volg elke beweging voor auditing en creëer een beveiligde perimeter rond je applicatie met een service mesh.
Navigeer met gemak door de complexiteit van je gedistribueerde systeem! Een service mesh biedt ongeëvenaarde zichtbaarheid in de interne werking van je applicatie via gedistribueerde tracing.
Ontdek waardevolle inzichten met een schat aan statistieken, logs en prestatiegegevens. Optimaliseer je services en los problemen op als een pro met een service mesh.
Istio, een open-source service mesh bedacht door IBM, Google en Lyft, verbetert onzichtbaar gedistribueerde applicaties met verkeersbeheer, beveiliging en prestatie-inzichten.
Flexibel inzetbaar on-premise, in de cloud, binnen Kubernetes of op virtuele machines, schittert Istio met microservices op Kubernetes. Hoewel platformonafhankelijk, past het perfect in containeromgevingen.
De kern van Istio bestaat uit Envoy-proxies die als sidecars naast elke microservice worden ingezet:
Dit proxynetwerk vormt Istio's datavlak, aangestuurd door het controlevlak:
Het controlevlak, het meesterbrein van Istio, geeft Envoy-proxies mogelijkheden voor ontdekking, configuratie en certificaatbeheer.
Ontketen Istio's potentieel met een veelheid aan onderling verbonden microservices, waar sidecar-proxies een robuuste service mesh-infrastructuur weven:
De aanpasbaarheid van Istio schittert door de naadloze integratie met externe log-, telemetrie- en beleidssystemen.
De architectuur van Istio is een dynamisch duo: het datavlak en het controlevlak. Samen orkestreren ze de magie achter de capaciteiten van Istio. Laten we duiken in de kerncomponenten die dit uitzonderlijke platform aandrijven.
Maak je klaar om de gedetailleerde onderdelen van Istio's kerncomponenten te verkennen.
Istio's datavlak is in feite een versterkte versie van de Envoy-proxy. Deze open-source wonder beheert netwerkcomplexiteit, zodat applicaties zich kunnen richten op hun kerntaken. Applicaties communiceren naadloos, zonder kennis van de complexe netwerkstructuur.
Envoy staat centraal als een netwerkwizard die opereert op lagen 3 en 4 van het OSI-model. Het beheert verbindingen met behulp van een ketting van aanpasbare netwerkfilters. Daarnaast beheert Envoy het HTTP-verkeer met finesse op laag 7 en ondersteunt het HTTP/2 en gRPC protocollen.
Veel van Istio's opvallende functies zijn eigenlijk superkrachten die zijn geërfd van de ingebouwde mogelijkheden van Envoy:
De ware potentie van Envoy komt naar voren wanneer het wordt gecombineerd met Istio. De uitbreidbaarheid van Envoy, aangedreven door WebAssembly, is een game-changer voor aangepaste beleidsafdwinging en telemetrie. Bovendien opent Istio's Proxy-Wasm API de deuren voor nog meer aanpassingen van Envoy.
Maak kennis met istiod, de dirigent van het controlevlak van Istio. Deze maestro zet high-level routeringsregels en verkeersbeheerinstructies om in Envoy-vriendelijke configuraties en verspreidt ze moeiteloos naar sidecars.
Herinner je Istio's eerdere architectuur met zijn afzonderlijke componenten? Welnu, om dingen te vereenvoudigen zijn deze componenten samengevoegd in het verenigde istiod. Maar maak je geen zorgen, de kernfunctionaliteiten blijven intact.
Istiod gebruikt dezelfde code en API's als zijn voorgangers. Pilot, bijvoorbeeld, blijft de dirigent van serviceontdekking en vertaalt platform-specifieke details naar een universele taal die sidecars begrijpen. Deze flexibiliteit stelt Istio in staat om te harmoniseren met diverse omgevingen zoals Kubernetes en virtuele machines.
Istiod neemt ook de verantwoordelijkheid voor beveiliging en zorgt voor robuuste authenticatie tussen services en eindgebruikers met zijn ingebouwde identiteits- en referentiebeheersysteem. Handhaaf gedetailleerde beveiligingsbeleid op basis van service-identiteit met gemak. Bovendien fungeert istiod als een vertrouwde Certificate Authority (CA), die certificaten uitgeeft voor het beveiligen van de communicatie tussen services via mutual TLS (MTLS).
We hebben de typische functies van een service mesh verkend en Istio's architectuur en kerncomponenten ontleed. Nu gaan we ontdekken hoe Istio deze functies levert met behulp van zijn kerncomponenten.
We zullen dezelfde functiecategorieën opnieuw bekijken.
Istio's verkeersbeheer API biedt gedetailleerde controle over het verkeer binnen de service mesh. Pas verkeersconfiguraties aan met behulp van deze API's en definieer API-resources met Kubernetes custom resource definitions (CRD's). Belangrijke API-resources voor verkeersroutering zijn virtual services en bestemmingregels:
Een virtual service bepaalt hoe verzoeken worden gerouteerd naar een service binnen de Istio-mesh. Het bestaat uit een of meer routeringsregels die achtereenvolgens worden geëvalueerd. Na virtual service-routing worden bestemmingregels toegepast om het verkeer naar een bestemming te beheersen, zoals het groeperen van service-instanties op basis van versie.
De basis van Istio's beveiliging is sterke identiteiten voor elke service. Istio-agenten naast elke Envoy-proxy werken samen met istiod om het roteren van sleutels en certificaten te automatiseren:
Istio ondersteunt twee typen authenticatie: peer-authenticatie en verzoekauthenticatie. Peer-authenticatie beveiligt service-tot-service communicatie met Istio's mutual TLS-oplossing. Verzoekauthenticatie verwerkt eindgebruikerauthenticatie via JSON Web Token (JWT) validatie met een aangepaste authenticatieprovider of OpenID Connect (OIDC) provider.
Istio handhaaft service-toegangscontrole door autorisatiebeleid toe te passen. Deze beleidslijnen regelen inkomend verkeer in de Envoy-proxy, waardoor toegangscontrole mogelijk is op mesh-, namespace- en serviceniveau.
Istio genereert uitgebreide telemetrie, waaronder statistieken, gedistribueerde traces en toegangslogs, voor alle servicecommunicatie binnen de mesh. Deze telemetrie omvat proxy-niveau, servicegerichte en controlevlak-statistieken.
Vroeger was Mixer het centrale onderdeel in Istio's telemet rie-architectuur. Echter, Telemetry v2 vervangt de functies van Mixer met Envoy-proxy plugins:
Istio creëert gedistribueerde traces via Envoy-proxies en ondersteunt verschillende tracing-backends zoals Zipkin, Jaeger, Lightstep en Datadog. De sample rate voor trace-generatie is configureerbaar. Bovendien genereert Istio toegangslogs voor serviceverkeer in aanpasbare formaten.
Genoeg achtergrondinformatie, laten we Istio in actie zien! We installeren Istio op een Kubernetes-cluster en gebruiken een eenvoudige microservices-app om de kracht ervan te demonstreren.
Istio kan op verschillende manieren worden geïnstalleerd, maar het downloaden en uitpakken van de laatste release voor je besturingssysteem (zoals Windows) is het eenvoudigst. Het uitgepakte pakket bevat de istioctl-client in de bin-map. Gebruik istioctl om Istio op je Kubernetes-cluster te installeren:
istioctl install --set profile=demo -y
Dit installeert de Istio-componenten op het standaard Kubernetes-cluster met behulp van het demo-profiel. Vervang 'demo' door een ander vendorspecifiek profiel indien nodig.
Vertel Istio vervolgens om Envoy-sidecar proxies automatisch in te voegen bij het implementeren van apps op dit Kubernetes-cluster:
kubectl label namespace default istio-injection=enabled
We gebruiken hier kubectl, ervan uitgaande dat je een Kubernetes-cluster (zoals Minikube) en de Kubernetes CLI kubectl hebt ingesteld.
Stel je een eenvoudige online bestelapplicatie voor deze demo voor. Het bestaat uit drie microservices die samenwerken om bestellingen af te handelen:
We gaan niet in op de details van microservices, maar ze zijn gemakkelijk te creëren met Spring Boot en REST API's. Cruciaal is dat je Docker-afbeeldingen voor deze microservices maakt om ze op Kubernetes te implementeren.
Het implementeren van gecontaineriseerde workloads op Kubernetes-clusters zoals Minikube is eenvoudig. Gebruik Deployment- en Service-resources om de workload te declareren en te benaderen. Definieer ze meestal in een YAML-bestand:
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
Dit is een basis Deployment- en Servicedefinitie voor de order-service. Maak vergelijkbare YAML-bestanden voor de voorraadservice en verzendservice.
Implementeer deze resources eenvoudig met kubectl:
kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml
Aangezien we de automatische injectie van Envoy-sidecar proxies voor de standaard namespace hebben ingeschakeld, is alles geregeld. Of injecteer handmatig Envoy-sidecar proxies met behulp van istioctl's kube-inject opdracht.
Istio beheert voornamelijk mesh-verkeer. Standaard wordt verkeer van of naar buiten de mesh geblokkeerd. Istio gebruikt gateways om inkomend en uitgaand mesh-verkeer te beheren, waardoor je nauwkeurige controle hebt over wat binnenkomt of vertrekt. Istio biedt vooraf geconfigureerde gateway-proxy implementaties: istio-ingressgateway en istio-egressgateway.
Maak een Gateway en Virtual Service voor je app aan:
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
We gebruiken hier de standaard Istio-ingresscontroller. Bovendien hebben we een virtual service gedefinieerd om verzoeken naar de boekingsservice te routeren.
Je kunt ook een egress-gateway definiëren voor uitgaand mesh-verkeer.
We hebben een eenvoudige app op Kubernetes met Istio geïmplementeerd. Laten we de krachtige functies van Istio verkennen en zien hoe ze onze applicatie kunnen verbeteren.
Stel je voor dat je meerdere versies van een microservice zoals de verzendservice implementeert. Je wilt nieuwe functies geleidelijk introduceren zonder alle gebruikers te beïnvloeden. Verzoekroutering stelt je in staat dit te doen door een deel van het verkeer naar de nieuwste versie te leiden.
Gebruik virtual service-routeringsregels om dit te bereiken.
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
Routeringsregels kunnen ook verkeer filteren op basis van headers of andere attributen. Het veld bestemming specificeert de doelservice voor overeenkomende verzoeken.
Voorkom cascaderende fouten met circuit breakers. Dit patroon detecteert fouten en stopt tijdelijk het verkeer naar falende services, waardoor de algehele gezondheid van je applicatie wordt beschermd.
Istio's DestinationRule stelt je in staat circuit breaking gedrag voor services zoals voorraadservice te configureren.
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
Door het maximale aantal verbindingen, wachtende verzoeken en verzoeken per verbinding te beperken, kun je verkeer effectief beheren en overbelasting voorkomen.
Mutual TLS zorgt voor veilige communicatie tussen services door te eisen dat beide partijen zich authentiseren. Istio schakelt automatisch mutual TLS in voor services die zijn proxies gebruiken.
Hoewel Istio mutual TLS afdwingt tussen geproxiede services, kan verkeer in platte tekst nog steeds services bereiken zonder proxies. Gebruik PeerAuthentication beleid om mutual TLS af te dwingen in je hele mesh.
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
name: "default"
namespace: "istio-system"
spec:
mtls:
mode: STRICT
Je kunt mutual TLS toepassen op mesh-, namespace- of serviceniveau. Service-specifieke beleidslijnen overschrijven namespace-brede instellingen.
JSON Web Tokens (JWT) zijn een standaard voor het veilig overbrengen van gebruikersinformatie. Ze worden veel gebruikt voor authenticatie en autorisatie.
Istio's AuthorizationPolicy stelt je in staat de toegang tot services zoals boekingsservice te beheren op basis van JWT-claims.
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]"]
Vereis geldige JWT's met specifieke claims voor geautoriseerde toegang. Istio creëert een requestPrincipal attribuut uit de issuer- en subject-claims van de JWT.
Istio vereenvoudigt het beheren van veelvoorkomende uitdagingen in gedistribueerde microservice-architecturen. De complexiteit kan echter extra overhead toevoegen aan implementaties. Net als elk gereedschap is Istio geen magische oplossing en vereist het zorgvuldige overweging.
Hoewel service meshes voordelen bieden, overweeg deze nadelen:
Service meshes bieden voordelen, maar een zorgvuldige evaluatie van de complexiteit van je applicatie is cruciaal. Weeg de voordelen af tegen de toegevoegde complexiteit.
Istio is een populaire service mesh, ondersteund door industriële leiders, maar het is niet de enige optie. Hier is een kort overzicht van Linkerd en Consul.
Linkerd is een Kubernetes-native, open-source service mesh die aan populariteit wint. Het is een CNCF-incubatieproject en werkt op dezelfde manier als Istio, met behulp van TCP-proxies. Linkerd's op Rust-gebaseerde micro-proxy wordt Linkerd-proxy genoemd.
Linkerd is over het algemeen eenvoudiger dan Istio vanwege zijn focus op Kubernetes. Hoewel het functiepakket nauw aansluit bij dat van Istio, is de kernarchitectuur vergelijkbaar. Linkerd bestaat uit een gebruikersinterface, datavlak en controlevlak.
Consul is een open-source service mesh van HashiCorp die integreert met andere HashiCorp-infrastructuurtools. Het datavlak van Consul ondersteunt zowel proxy- als native integratiemodellen. Het biedt een ingebouwde proxy, maar kan ook werken met Envoy.
Consul opereert buiten Kubernetes en ondersteunt platforms zoals Nomad. Het gebruikt agents op elke node voor gezondheidscontroles en communiceert met Consul-servers voor gegevensopslag en replicatie. Hoewel het standaard functies van een service mesh biedt, is Consul complexer te implementeren en beheren.
Deze tutorial heeft de basisprincipes van service mesh-architectuur en Istio's krachtige capaciteiten verkend. We hebben de kernstructuur, componenten en praktische toepassingen van Istio uitgediept. Aan het einde zou je een solide begrip moeten hebben van hoe je Istio kunt installeren en gebruiken voor veelvoorkomende scenario's.
Klantenfeedback
De volgende beoordelingen zijn verzameld op onze website.
Heb je Vragen? Vind Antwoorden Hier!
Onze Meest Gestelde Vragen