Vier vragen, en je leest elke Envoy-mesh
Bijna elke mesh draait op dezelfde motor. Vandaag haal ik hem uit elkaar. Wees niet bang voor de diepte, het zijn precies vier onderdelen.
- Datum
- Onderwerp
- Envoy
- Bronnen
- 3
- Leestijd
- 2 min
- Versie
- Vertaling
Vorige week stond hier: bijna elke mesh draait op dezelfde motor. Vandaag haal ik hem uit elkaar. Wees niet bang voor de diepte, het zijn precies vier onderdelen.
Afbeelding als tekst
Schema in drie lagen: bovenaan de Istio-CRD's Gateway, VirtualService, DestinationRule en ServiceEntry als vertaallaag, in het midden de Envoy-pipeline als vier vragen (Listener, Route, Cluster, Endpoint) van request tot pod-IP. Onderaan de diagnoselaag met de istioctl proxy-config subcommands en de flags NR, UO en UF.
Elke request die door Envoy loopt, beantwoordt achtereenvolgens vier vragen.
Listener: waar komt het verkeer binnen? Poort, protocol, filter chain. Hier valt de beslissing of er überhaupt iemand luistert.
Route: welke regel past? Host, path en headers worden gematcht, de request krijgt zijn bestemming toegewezen.
Cluster: hoe is het doel geconfigureerd? Load balancing, TLS, timeouts, circuit breakers. Het doel als groep, met operationele regels.
Endpoint: welke concrete adressen zijn op dit moment gezond? Pas hier wordt configuratie een echt pakket naar een echt IP.
Dat is de hele motor. Al het andere is vertaling. Een Istio-Gateway schrijft listeners. Een VirtualService schrijft routes. Een DestinationRule schrijft clusters, subsets en circuit breakers incluis. Een ServiceEntry maakt clusters en endpoints aan voor externe doelen.
Wie report #8 heeft gelezen, ziet het nu: istioctl proxy-config vraagt naar listeners, routes, clusters en endpoints, omdat het diagnosepad precies deze vier vragen doorloopt. Daarnaast een vijfde vakje voor certificaten, secrets. Ook de Envoy-flags vallen op hun plek: NR betekent dat vraag twee geen antwoord heeft. UO strandt op vraag drie, daar woont de circuit breaker. UF op vraag vier, het adres antwoordt niet.
En omdat Kuma, Consul en de Istio-distributies op dezelfde motor draaien, lees je hun debug-output met dezelfde vier vragen. Een config_dump uit de Envoy-admin-interface ziet er overal hetzelfde uit.
Voor de organisatie betekent dat: train je team niet op een product, train het op de motor. Product-YAML leer je binnen weken opnieuw. De vier vragen gaan met jullie mee door elke platformbeslissing.
Volgende week wordt het concreet: de verhuizing weg van AWS App Mesh, voordat eind september het licht uitgaat. Als raamwerk dat je kunt meenemen, en met een eerlijk antwoord op de vraag wanneer Istio de juiste bestemming is en wanneer niet.
Welke van de vier vragen heeft jullie bij de laatste debugsessie het antwoord geweigerd?
