Distributed Systems

Netwerkbeheer loskoppelen van Applicatiecode

In een groot Kubernetes-cluster met honderden microservices die continu data naar elkaar sturen, rijzen al snel twee gigantische vragen: *Hoe garanderen we dat al dit onderlinge netwerkverkeer versleuteld is (Zero Trust)?* en *Hoe sturen we heel subtiel 5% van het verkeer door naar een nieuwe test-versie van onze service zonder de gebruikers te storen (Canary Deployments)?* Vroeger moesten developers al deze logica — retries, timeouts, encryptie en routing — in hun eigen Java- of Go-code programmeren. Dit leidde tot enorme duplicatie en kwetsbare applicaties. De moderne cloud-native oplossing hiervoor is een **Service Mesh**.

De Sidecar Proxy Architectuur

Een Service Mesh is een dedicated infrastructuurlaag die bovenop je Kubernetes-cluster wordt geplaatst. Het bestaat uit twee onderdelen:

• The Data Plane: Dit is de collectie van ‘Sidecar Proxies’ (meestal gebaseerd op Envoy) die automatisch als een vederlicht achtergrondproces *naast* elke microservice in dezelfde Kubernetes Pod worden geïnjecteerd. Alle inkomende en uitgaande netwerkpakketjes van de applicatie worden onderschept en verwerkt door deze proxy.
• The Control Plane: Het centrale brein dat de configuraties, beveiligingscertificaten en routeringsregels pusht naar al die duizende sidecar proxies in het cluster.
• Mutual TLS (mTLS) Out-of-the-Box: Een van de krachtigste voordelen van een Service Mesh is dat het automatisch **mTLS** afhandelt tussen al je microservices. Niet alleen wordt alle netwerkcommunicatie over het interne cluster-netwerk versleuteld, maar beide services verifiëren ook cryptografisch elkaars identiteit. Je applicatie-code hoeft hier absoluut niets voor te doen; het gebeurt volledig transparant op netwerkniveau.

Traffic Shifting en Canary Deployments

Omdat de Service Mesh al het verkeer beheert, kun je geavanceerde routeringsregels instellen zonder de code aan te passen. Wil je een nieuwe versie van de betalingsservice uitrollen? Je configureert de Service Mesh control plane om exact 95% van het verkeer naar v1 te sturen, en 5% naar v2 (**Traffic Shifting** / Canary Deployment). Je monitort via distributed tracing of v2 errors geeft; zo ja, dan draai je de kraan direct dicht met één simpele configuratiewijziging.

Istio vs. Linkerd: De Keuze in de Markt

De twee grootste spelers in de Service Mesh wereld zijn **Istio** en **Linkerd**:

• Istio: De absolute reus met een ongekende hoeveelheid features (uitgebreide security policies, telemetry, egress gateways, WebAssembly extensies). Het is echter berucht om zijn complexiteit en hogere geheugenverbruik.
• Linkerd: Ontworpen vanuit het principe van ‘Ultra-lightweight en Simplicity’. Linkerd gebruikt geschreven Rust-proxy’s die extreem weinig geheugen verbruiken en supersnel opstarten, zonder de overweldigende complexiteit van Istio.

Het kiezen van de juiste Service Mesh hangt af van de omvang en enterprise-eisen van je organisatie. Lees meer over beveiliging en infrastructuur op AG Connect.

 

Volgende: Chaos Engineering: Het Proactief Stukmaken van Productieomgevingen
Kennisbank overzicht