Wanneer een applicatie niet meer reageert, is een van de eerste diagnoses vaak: «Het is een DNS-probleem». Vaak klopt dat ook, maar soms ligt de werkelijke oorzaak bij het Service Discovery-systeem. Hoewel beide mechanismen helpen bij het vinden van middelen in een netwerk, vervullen ze verschillende functies en opereren ze op verschillende niveaus binnen de infrastructuur.
De komst van Kubernetes, Docker, microservices en cloud-native technologieën heeft geleid tot een voortdurende verwevenheid van beide concepten, wat soms verwarring veroorzaakt zelfs bij ervaren systeembeheerders. De werkelijkheid is dat DNS en Service Discovery niet concurreren, maar juist elkaar aanvullen.
De kernpunten van DNS en Service Discovery in 20 seconden
- DNS vertaalt domeinnamen naar IP-adressen om servers te lokaliseren.
- Service Discovery stelt applicaties in staat elkaar automatisch te vinden.
- Cloud-omgevingen veranderen voortdurend van IP-adressen, waardoor traditioneel DNS niet meer volstaat.
- Kubernetes combineert beide mechanismen om een dynamische en veerkrachtige infrastructuur te bieden.
Terwijl het vorige artikel over CDN en caching uitlegde hoe je de toegang tot content versnelt, lossen DNS en Service Discovery een andere uitdaging op: hoe services correct te lokaliseren wanneer de infrastructuur voortdurend verandert.
DNS: het telefoonboek van Internet
Domain Name System (DNS) bestaat sinds de vroege jaren van het Internet en blijft een van de pijlers ervan.
De functie ervan is om gemakkelijk te onthouden namen, zoals:
- google.com
- github.com
- stackoverflow.com
om te zetten in de IP-adressen die computers gebruiken om te communiceren.
Bijvoorbeeld, wanneer een gebruiker typt:
www.voorbeeld.nlvraagt de computer aan de DNS-server naar het bijbehorende IP-adres.
Een mogelijke reactie zou kunnen zijn:
203.0.113.10Vanaf dat moment weet de browser waar de aanvraag naartoe moet.
Dit proces duurt meestal slechts enkele milliseconden en verloopt vrijwel onzichtbaar voor de gebruiker.
Zonder DNS zou je het IP-adres van elke webpagina die je bezoekt, moeten onthouden.
Het probleem: moderne applicaties zijn geen statische servers meer
Vele jaren waren servers nauwelijks veranderlijk.
Een bedrijf zette een fysieke server of virtuele machine op en behield hetzelfde IP-adres maanden of zelfs jaren.
In dat scenario werkte DNS perfect.
Maar de moderne architectuur is compleet anders.
Tegenwoordig bestaat een applicatie uit tientallen of honderden kleine, onafhankelijke services.
Elk ervan kan draaien op:
- Docker-containers
- Kubernetes Pods
- Virtuele machines
- Serverless functies
- Cloud-instanties die automatisch verschijnen en verdwijnen
In deze omgeving veranderen IP-adressen voortdurend.
Hier komt Service Discovery in beeld.
Wat is Service Discovery?
Service Discovery maakt het mogelijk dat een applicatie automatisch een andere applicatie vindt zonder voorafgaande kennis van het IP-adres.
In plaats van te vragen:
Waar is 10.25.17.84?vraagt het systeem:
Waar is Payment Service?Het systeem geeft de op dat moment beschikbare instantie terug.
Zo, als een container verdwijnt en Kubernetes een nieuwe met een compleet ander IP aanmaakt, blijft de rest van de services functioneren zonder dat de configuratie hoeft te worden aangepast.
Applicaties kennen alleen de logische naam van de service.
Het discovery-systeem zorgt voor de rest.
Een eenvoudig voorbeeld
Stel je voor dat je een webwinkel hebt gebaseerd op microservices.
De structuur bestaat uit:
- User Service
- Product Service
- Order Service
- Payment Service
- Notification Service
Wanneer een klant een aankoop doet, moet de orderservice communiceren met de betalingsservice.
Als je meteen een IP-adres zou gebruiken, zou een herstart van de container de communicatie verbreken.
Vorig jaar:
Payment Service
192.168.10.25Na een herstart:
Payment Service
192.168.10.61Het IP-adres is gewijzigd.
Zonder Service Discovery zou je handmatig alle applicaties die deze service gebruiken, moeten bijwerken.
Met Service Discovery vraag je simpelweg:
Waar is Payment Service?Het systeem geeft automatisch de nieuwe locatie terug.
Voor de applicatie verandert er niets.
Kubernetes automatiseert alles
Kubernetes heeft Service Discovery ingebouwd.
Wanneer een Service resource wordt gemaakt, genereert Kubernetes automatisch een intern DNS-naam zoals:
payment-service.default.svc.cluster.localApplicaties kunnen simpelweg verzoeken sturen naar:
http://payment-serviceZe hoeven niet te weten:
- Hoeveel Pods er zijn,
- Welke IP-adressen ze hebben,
- Welke recent opnieuw gestart zijn,
- Welke zijn vervangen.
Kubernetes houdt deze informatie automatisch up-to-date.
Als een Pod uitvalt, wordt het verkeer automatisch doorgestuurd naar een andere beschikbare instantie, zonder dat de client-app moet worden aangepast.
Deze combinatie van intern DNS en Service Discovery is een van de fundamenten van Kubernetes.
DNS en Service Discovery lossen verschillende problemen op
Hoewel beide helpen bij het vinden van middelen, functioneren ze op verschillende niveaus.
| DNS | Service Discovery |
|---|---|
| Lokaleiseert servers. | Lokaleiseert applicaties of services. |
| Vertalen domeinnamen naar IP’s. | Vindt automatisch beschikbare instanties. |
| Voor relatief stabiele infrastructuur. | Ontworpen voor dynamische en cloud-native omgevingen. |
| Gereserveerd voor externe gebruikers en applicaties. | Voor gebruik tussen microservices onderling. |
| Verandert zelden. | Wordt voortdurend bijgewerkt. |
De verschillen kunnen worden samengevat als:
DNS helpt mensen bij het vinden van servers.
Service Discovery helpt applicaties onderling te vinden.
Een praktijkvoorbeeld: Netflix
Wanneer een gebruiker typt:
www.netflix.comis de eerste stap het resolven van dat domein via DNS.
Eenmaal bij de Netflix-infrastructuur begint een volledig ander proces:
- authenticatie,
- profielen,
- aanbevelingen,
- catalogus,
- facturatie,
- streaming,
- monitoring.
Deze interne componenten gebruiken meestal geen publieke namen.
In plaats daarvan maken ze gebruik van Service Discovery-systemen om in realtime beschikbare instanties te vinden.
Voor de gebruiker lijkt alles één enkele applicatie.
Intern kunnen honderden services, verspreid over meerdere datacenters, actief zijn.
Service Discovery vervangt DNS niet
Een veel voorkomende misvatting is dat Kubernetes het DNS-systeem heeft vervangen.
Dat klopt niet.
Wat Kubernetes doet, is DNS gebruiken als mechanisme om een deel van het interne Service Discovery-proces te implementeren.
Beide systemen werken dus samen.
De gebruikelijke flow is:
- De gebruiker gebruikt DNS om de applicatie te vinden.
- Het verzoek komt aan in het cluster.
- Binnen het cluster gebruiken microservices Service Discovery om elkaar te vinden.
- Kubernetes updated automatisch de routes naar nieuwe of verdwijnde instanties.
De cloud-infrastructuur heeft beide nodig
Moderne applicaties draaien niet meer slechts op enkele statische servers.
Automatische schaalbaarheid, continue deployment, containers en orkestratie zorgen dat IP-adressen constant veranderen.
DNS blijft essentieel voor toegang tot applicaties en services vanaf het internet.
Service Discovery zorgt dat die apps blijven functioneren, zelfs als de infrastructuur honderden keren per dag wijzigt.
Daarom integreren tools als Kubernetes, Consul, Istio, Linkerd en AWS Cloud Map geavanceerde service discovery-mechanismen.
Ze vervangen DNS niet.
Ze vullen het aan.
In een moderne cloud-native architectuur zijn beide systemen essentieel voor hoge beschikbaarheid, schaalbaarheid en veerkracht.
Veelgestelde vragen
Zijn DNS en Service Discovery hetzelfde?
Nee. DNS vertaalt domeinnamen naar IP-adressen, terwijl Service Discovery applicaties en microservices automatisch kunnen vinden, ongeacht veranderende locaties.
Waarom gebruikt Kubernetes beide?
Omdat DNS stabiele namen biedt voor toegang, terwijl Kubernetes automatisch bijhoudt welke Pods gezond zijn en achter die namen schuilgaan.
Kan een applicatie alleen met DNS werken?
Ja, vooral in traditionele infrastructuren met weinig IP-wijzigingen. In microservices-architecturen is handmatig beheer veel lastiger door de dynamiek.
Welke andere oplossingen voor Service Discovery bestaan er naast Kubernetes?
Bekende voorbeelden zijn HashiCorp Consul, AWS Cloud Map, Eureka van Netflix, en de ingebouwde systemen in platforms zoals Kubernetes of OpenShift.