Waar moet je beginnen?
Voor ops trek ik altijd graag de vergelijking met de meer traditionele on-premises oplossingen. Ja, er is meer aan de hand, maar dit helpt wel met de basiskennis.
In de meeste omgevingen stromen de gegevens/verbindingen van de Ingress naar een Service en van de Service naar de Pods. Klinkt ingewikkeld? Dat hoeft niet. Laten we dit voor het gemak vertalen naar een meer traditionele omgeving.
Ingress – Dit kan de router of firewall zijn die je voorheen gebruikte.
Service – Laten we dit je loadbalancer noemen voor high available workloads in de backend
Pods – Binnen de Pod draait je container(s).
Namespaces – De kamer/ruimte waar je hardware in staat.
Namespaces
Laten we beginnen met namespaces. Ik neem aan dat je jouw Azure Kubernetes Cluster up en running hebt. Standaard heb je een standaard namespace en een kube-system namespace. Als je iets uitrolt zonder op een namespace te targeten zal je standaard namespace gebruikt worden.
De kube-system namespace wordt gebruikt voor objecten die door het Kubernetes systeem zelf zijn gemaakt. In principe zijn dat de dingen die je nodig hebt om Kubernetes draaiende te houden. Extra diensten die je toevoegt (zoals monitoring met Azure Monitor, service meshes, ingress controllers) zullen ook worden ingezet in de kube-system namespaces.
Ik wil graag verwijzen naar namespaces als de ‘resource group’ (of server room in onze analogie) waar je je spullen inzet. Om duidelijk te zijn: namespaces zijn geen veiligheidsgrens. In plaats daarvan zijn ze een manier om jouw resources logisch te organiseren. Ze hebben wel beperkingen en zijn geïsoleerd van elkaar in termen van functionaliteit.
Bijvoorbeeld: een TLS geheim (je certificaat) beschikbaar hebben in één namespace maakt het niet automatisch beschikbaar in andere name spaces. Dan is de grote vraag: wanneer gebruik ik een nieuwe namespace? En zoals voor de meeste dingen is het antwoord: dat hangt ervan af.
Het hangt ervan af hoe jouw oplossing eruit ziet, hoe je update scenario’s er uit zien en de technologieën die gebruikt zijn. In het algemeen kun je zeggen dat alles met dezelfde levens cyclus in dezelfde namespace wordt geplaatst. Laten we zeggen dat je een team hebt dat met een set van 5 microservices werkt en een ander team dat met een andere set van 5 microserviecs werkt. Om de dingen logisch gescheiden te houden zouden ze in twee verschillende namespaces werken. En ja, services in verschillende namespaces kunnen met elkaar communiceren als je dat toe laat, maar dat doen ze standaard niet.
Waar je over het algemeen geen namespaces voor zou gebruiken, is de implementatie van een volgende versie van jouw oplossing. Je kunt jouw nieuwe versie gewoon in dezelfde namespace implementeren en gebruik maken van de middelen die er al zijn (volume claims, secrets etc) zonder ze opnieuw te moeten maken in een nieuwe namespace. Een manier om ze te scheiden vanuit een beheerperspectief (en routing, maar daar komen we verder in het artikel op terug) zou het gebruik van labels zijn. Het is niet nodig om hiervoor een nieuwe namespace aan te maken 😊.
Samenvattend: Namespaces zijn een geweldige manier om jouw middelen te organiseren zoals je dat zelf wilt. Maar zorg ervoor dat je niet met honderden namespaces komt, want dan zal het het tegenovergestelde effect hebben.
Ingress
Dit is waar de dingen ingewikkeld gaan worden. De ingress kan gezien worden als het eerste toegangspunt tot jouw oplossing (jouw router). Het concept van Ingress bestaat uit twee delen: De Ingress controller en de Ingress Roles. Laten we eerst eens kijken naar de Controller. Deze bepaalt in principe de functionaliteiten die je zult hebben. In onze analogie noemen we dit jouw Router hardware.
De grote vraag is: welke functionaliteiten heb je nodig? Heb je TLS termination nodig? Heb je een service mesh nodig, of gebruik je een specifieke technologie voor de routering van het verkeer? Om te bepalen welke controller het beste voor je werkt is er een geweldig document dat de voor-en nadelen van elke controller op een rijtje zet (Kubernetes Ingress Controllers – Google Spreadsheets).
Enkele populaire gebruikte controllers die wij veel bij onze klanten tegenkomen zijn: Nginx, Istio en Azure Application Gateway. Voor elke valt wat te zeggen; zoek de Ingress-controller die het beste bij jou en jouw behoeften past!
Als je de controller eenmaal hebt ingesteld, kun je de Ingress regels maken. Dit zijn aparte resources in Kubernetes en kunnen worden vergeleken met traditionele routing-/firewall regels. Laten we eens kijken naar het volgende voorbeeld. Er wordt een Ingress regel voor een Nginx Ingress Controller gemaakt, deze voert TLS beëindiging uit voor het domein ‘demoaks1.cloudadventures.org’ en gebruikt het ‘cloud adventures’ secret dat de certificaten voor dat domein bevat. Het stuurt vervolgens al het verkeer naar de server ‘aspnetapp’. (Later meer over deze service).
Een voorbeeld van een Ingress Rule:
Als je een nieuwe regel of domein toevoegt, hoef je alleen maar een andere regel toe te voegen die vergelijkbaar is met:
Het begint al wat minder ingewikkeld te worden, nietwaar?
Services
We hebben het net al kort over services gehad. Services kunnen worden gezien als Load Balancers als je wilt. Het zal het betrouwbare eindpunt van jouw pods zijn. In het vorige voorbeeld van Ingress Rules zagen we dat de regel niet naar één specifieke Pod wijst, maar naar een Service. De Service werkt als een soort loadbalancer tussen de buitenwereld en de Pods. Een Service heeft een privé IP adres en kan ook een publiek IP adres hebben. Over het algemeen wordt echter geadviseerd om je Service niet te voorzien van een publiek IP adres, maar deze te ontsluiten met behulp van een Ingress Rule.
De Service is op zoek naar een specifiek label op de Pods om te bepalen of het deel uitmaakt van de werklast waar je verkeer naartoe wilt sturen. Als de labels overeenkomen, zal de Service in principe de loadbalance en het verkeer naar de beschikbare Pod’(s) sturen. In het volgende voorbeeld hebben we de YAML-definitie van een service. De service heet ‘aspnetapp’ en in dit voorbeeld hebben de Pods een label met ‘app”aspnetapp’.
Dit betekent dat het niet uitmaakt hoeveel replica’s (kopieën) van je workload oproept, de service zal het zien en leidt er verkeer naartoe.
Pods
Het laatste onderwerp dat we in dit artikel bespreken zijn Pods. Pods zijn de kleinste entiteiten die je kunt beheren op Kubernetes. Een Pod kan één of meerdere containers bevatten. Uiteindelijk zal een Pod tijdens een deployment een node worden toegewezen. Op deze node (virtual machine) zal de pod opstarten.
Als je workload uit meerdere Pods bestaat, houd er dan rekening mee dat deze pods allemaal op verschillende knooppunten (virtuele machines) kunnen draaien. Dit is waar de keuze van het aantal containers dat je gaat draaien in een enkele Pod belangrijk wordt. Over het algemeen zal je 1 container per pod draaien. Maar in tightly-coupled scenario’s waar 2 containers echt afhankelijk zijn van elkaar zou je beide containers in een enkele pod kunnen configureren, zodat ze altijd op dezelfde node draaien en zo dicht mogelijk bij elkaar staan. Omdat Services op zoek gaan naar een bijpassend label, moeten Pods een label hebben dat overeenkomt met het label waar de service naar kijkt.
In het volgende voorbeeld hebben we een Pod die een enkele container bevat (aspnetapp-image) en gelabeld is met ‘app:aspnetapp’. Hiermee is de configuratie van Ingress naar Service naar Pod afgrond. Als we nu het aantal pods zouden verhogen (omdat we onze oplossing moeten schalen) zouden we de ‘replica’s’ verhogen en er zullen meer pods worden aangemaakt. We kunnen dit doen zonder dat we onze service moeten her configureren omdat de onderstaande Pod-definitie zal blijven bestaan. Het enige dat zal veranderen is de hoeveelheid pods. Zolang je maar voorzichtig bent met het opschalen van je labels zal het geen uitdaging meer zijn!
Samenvatting
In dit voorbeeld van Ingress, Services en Pods hebben we het volgende scenario:
De Ingress Controller accepteert de verbindingen, en de Ingress Rules zorgen voor het certificaat en de afhandeling van de beëindiging van TLS. De Ingress Rule zorgt ervoor dat het verkeer voor de URI naar de juiste Service wordt gestuurd en dat Service labels gebruikt worden om het verkeer naar de juiste pods te leiden. Voor een update-scenario zou dit betekenen dat je een compleet nieuwe versie van je applicatie kunt implementeren, een nieuwe service kunt aanmaken en als je tevreden bent met het resultaat, de Ingress Rule kunt wijzigen om naar je nieuwe service en nieuwe pods te verwijzen. Best cool toch?
Natuurlijk komt er veel meer bij kijken, maar het begrijpen van deze concepten zal je zeker helpen bij je eerste implementaties.
Dit artikel is onderdeel van een reeks
Lees in dit vervolg artikel alles over Monitoren en managen van AKS clusters.
Vorige artikelen teruglezen? Klik hier:
1. De evolutie van AKS
2. Hybride deployments met Kubernetes
3. Microservices op AKS
4. Update scenario's AKS
5. Linux vs. Windows containers
6. Security op AKS
Wil je niets missen? Schrijf je dan hier in voor onze Intercept Insights. Dan houden we je op de hoogte van de laatste nieuwsberichten.
Bezoek onze AKS workshop
Leer nog meer over AKS door onze interactieve AKS workshop. In 1.5 uur ontvang jij de voordelen en de best practices om jouw omgeving efficiënter te maken. Middels veelvoorkomende AKS uitdagingen ben jij klaar voor AKS. Klik hier voor data en meld je aan!
