Ingress, Services, Pods & Namespaces.

Nadat je de container technologie hebt omarmd en hebt besloten dat Kubernetes gaat gebruiken, moet je aan de bak en je erin gaan verdiepen. Er is namelijk veel te leren, maar een aantal belangrijke concepten zoals Services, Pods, Ingresses en namespaces zijn van cruciaal belang voor je succes.

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!

 

Tags

  • Managed AKS
  • Azure Kubernetes Services
  • Containers

Geschreven door

Wesley Haakman

Wesley Haakman

Lead Azure Architect bij Intercept | Microsoft Azure MVP | CISSP | Spreker

Wellicht ook interessant:

  • 20210621 Intercept Artikel Illustratie Azure SLA

    Duidelijkheid over de Azure SLA

    Elke Azure service heeft een eigen SLA met daaraan verbonden voorwaarden; beperkingen en diensttegoed (service credits). Maar wat betekent dit nu precies? In dit artikel leggen we de verschillende SlA’s uit met de bijbehorende verschillen en wat dit nu betekent voor jouw organisatie.

    • Leesduur 7min
    Meer over Duidelijkheid over de Azure SLA
  • 202011111 Intercept Illustratie Bij Artikel Aks Monitoring A

    AKS monitoring en management

    In dit artikel geven we je op een hoog niveau meer inzicht in de mogelijkheden van het monitoren van (Azure) resources, maar AKS-clusters in het bijzonder.

    • Leesduur 9min
    Meer over AKS monitoring en management
  • Aks Security

    AKS Security

    Iedereen werkt hard aan het nieuwe platform en dan vraagt iemand... "Hoe zit het met de veiligheid?"

    • Leesduur 10min
    Meer over AKS Security
  • Ebook AKS ENG 1

    Het Intercept AKS e-book

    Dit e-book geeft je alle informatie die je moet weten om te beslissen of Azure Kubernetes een goede match met jouw software architectuur is. Leer daarnaast ook van onze best practices omtrent o.a. security, update scenario's en het monitoren en managen van AKS clusters.

    • Leesduur 2min
    Meer over Het Intercept AKS e-book
  • 20201028 Intercept Illustratie Bij Artikel Windows Container

    Windows containers in een Linux wereld

    Een veel voorkomende vraag wanneer iemand op zoek is naar het transformeren/containeriseren van zijn oplossing is; ‘ik draai nu op een Windows systeem: moet ik Windows containers gebruiken of moet ik kiezen voor Linux containers? En dit is inderdaad een hele terechte vraag.

    • Leesduur 8min
    Meer over Windows containers in een Linux wereld
  • Hoofdfoto Artikel AKS Updates

    Update scenario's op AKS

    In dit artikel ga ik het hebben over een heel belangrijk onderwerp: updates. Als ik zeg updates, dan bedoel ik niet alleen Kubernetes updates, maar ook de worker node OS updates. Veel mensen vergeten het patchen van het work OS in de overtuiging dat het door Microsoft wordt geregeld. Dit is niet het geval.

    • Leesduur 8min
    Meer over Update scenario's op AKS
  • Intercept Illustratie Bij Artikel Microservices Def Verkleind

    Microservices op AKS

    Ik hoor en zie online dat veel mensen praten over Microservices en Service Mesch, maar wat is dit? In dit artikel kijken we naar wat Microservices zijn, wat een Service Mesh is en wat je ermee kunt doen en tot slot of je het nu wel echt nodig hebt

    • Leesduur 9min
    Meer over Microservices op AKS
  • Going Hybris

    Hybride deployments met Kubernetes

    Ik hoor en zie online dat veel mensen praten over Microservices en Service Mesch, maar wat is dit? In dit artikel kijken we naar wat Microservices zijn, wat een Service Mesh is en wat je ermee kunt doen en tot slot of je het nu wel echt nodig hebt

    • Leesduur 7min
    Meer over Hybride deployments met Kubernetes
  • 20200819 Intcercept Artikel Illustratie Aks Cluster

    Best practices voor het opzetten van een AKS cluster

    Kubernetes is “hot & happening”, vrijwel iedereen wil er mee aan de slag. Het aanmaken van een AKS-cluster is zo gedaan, maar gaat dat ook zo makkelijk als je Kubernetes echt in productie wilt nemen? In dit artikel geven wij belangrijke tips en best-practices voor het opzetten en gebruiken van een AKS-productie omgeving.

    • Leesduur 6min
    Meer over Best practices voor het opzetten van een AKS cluster
  • 20200819 Intcercept Artikel Illustratie Aks Cluster

    Best practices voor het opzetten van een AKS cluster

    Kubernetes is “hot & happening”, vrijwel iedereen wil er mee aan de slag. Het aanmaken van een AKS-cluster is zo gedaan, maar gaat dat ook zo makkelijk als je Kubernetes echt in productie wilt nemen? In dit artikel geven wij belangrijke tips en best-practices voor het opzetten en gebruiken van een AKS-productie omgeving.

    • Leesduur 6min
    Meer over Best practices voor het opzetten van een AKS cluster