Niet te missen: keynote sessies
De keynotes van woensdag richten zich onder meer op Kubernetes op de lange termijn hebben draaien en versnellen voor een duurzame toekomst.
De donderdag keynotes stonden in het teken van updates, API’s en de developer experience.
Keynotes op vrijdag eindigden KubeCon over communities achter open source projecten ondersteunen en veiligheid schalen. Een sessie over de grenzen van cloud native verkennen besloot de keynotes op vrijdag.
From Kubernetes to PaaS to … Err, What’s Next? van Daniel Bryant
Van Kubernetes naar Platform as a Service voor developers naar … wat is de volgende stap? Volgens Daniel zijn dat, wat hij noemt, paved roads, paden die door anderen al getest, geprobeerd en versterkt zijn. Paden waardoor het voor developers makkelijker is om hun code te shippen en runnen. Voor Kubernetes geldt dat je als developer de volledige lifecycle moet beheersen: code, ship, run. Daniel stelt juist een shift-left voor, dat developers meer kunnen focussen op ontwikkelen en bouwen en minder op deployen en releasen. Met een paved road kan het voor developers makkelijker zijn om hun code naar de juiste omgeving of naar productie te brengen. En het CNCF ecocysteem kan een prima fundament daarvoor vormen, met bijvoorbeeld GitLab als source control, ArgoCD voor continuous delivery en Datadog als observability tool. Drie lessen van Daniel als je hiermee aan de slag gaat:
- behandel deze paden, deze platformen, als een product;
- er is geen goede developer experience zonder user experience;
- en focus op workflow en tooling die je onderling gebruikt (interops).
The Hitchhiker’s Guide to Pod Security van Lachlan Evenson
In deze sessie kwam Pod Security, de vervanger van PodSecurityPolicy, aan bod. PodSecurityPolicy is deprecated en zal uit versie 1.25 verdwijnen (1.25 verschijnt naar verwachting eind augustus 2022). Pod Security is al standaard te gebruiken vanaf versie 1.23. Deze feature heeft ook een built-in admission controller (beta in versie 1.23). Het grote verschil: PSA is een validating admission controller en ondersteunt geen muterende resources zoals PodSecurityPolicy dat wel doet.
Multi-cluster Failover Using Linkerd van Charles Pretzer
In Linkerd zit sinds kort de feature voor multi-cluster failover, of automated failover. Deze functionaliteit geeft Linkerd de mogelijkheid om automatisch alle verkeer van een falende of niet-bereikbare service te redirecten naar een of meerdere replica’s van die services, zelfs als die op een ander cluster staan. De tool bracht al eerder mogelijkheden voor cross-cluster communicatie, waar nu automatisering aan is toegevoegd. Binnen Kubernetes kun je voorwaarden configureren van wanneer Linkerd bij falen van services het verkeer redirect naar een replica.
Autoscaling Kubernetes Deployments: A (Mostly) Practical Guide van Natalie Serrino
Een van de fantastische mogelijkheden van Kubernetes is autoscaling. K8s wijst op metrics bepaalde resources toe aan pods, nodes en clusters om verkeer en requests aan te blijven kunnen. Maar op welke manier bepaal je wanneer wat toegewezen mag worden? Willekeurig instellen? Copy-paste van een vorige iteratie? Of reactie iteratie, dus aanpassen op het moment dat er een incident is geweest? Met autoscaling in K8s kun je deze vragen aanpakken.
Maar eerst: autoscaling kan in Kubernetes op drie manieren. Cluster Autoscaler past het aantal nodes van een cluster aan. Vertical Pod Autoscaler past de resources requests en limieten van een container aan. Met Horizontal Pod Autoscaler (HPA) past Kubernetes het aantal replicas van een applicatie aan. Vooral HPA zorgt voor schaalbaarheid van je applicatie, doordat het het aantal instances aanpast in plaats van de resources voor één container. Deze sessie focust zich daarop.
Ook bij HPA geldt: ga je ermee aan de slag, bedenk dan goed welke metrics je wilt gebruiken. Metrics kunnen bijvoorbeeld zijn: resource metrics die gelimiteerd zijn tot CPU en memory gebruik; latentie of queue depth; en het aantal bezoekers op de website. Na configuratie checkt HPA deze metrics standaard elke 15 seconden. Om dat te doen, is HPA afhankelijk van de Metrics Server. Deze geeft data over resource gebruik mee, zoals CPU- en geheugengebruik. Via Metrics Server kan HPA ook toegang krijgen tot custom metrics van externe bronnen, zoals het aantal actieve sessies op een load balancer als indicatie van het verkeer.
Getting the Optimal Service Efficiency That Autoscalers Won’t Give You van Mauro Pessina
Over autoscaling gesproken, in deze sessie kwam aan bod dat autoscalers niet altijd even goed zijn in optimale service efficiëntie. Configuraties voor resource requests en limieten kunnen impact op performance hebben. Deze uitdagingen komen daarbij kijken:
- Resource requests hebben invloed op de cluster capaciteit;
- Resource limieten hebben grote invloed op de performance en stabiliteit van je applicatie;
- CPU limieten kunnen zelfs de gehele service beïnvloeden en verstoren, zelfs als de gebruikte CPU minder is dan de ingestelde limieten;
- Het stellen van resource requests en limieten is wel vereist voor stabiliteit van je Kubernetes-omgeving;
- Vertical Pod Autoscaler gaat niet over service betrouwbaarheid;
- En Horizontal Pod Autoscaler vermenigvuldigt zich niet altijd even efficiënt.
Er kwam een onderzoek met testing met AI aan bod, waarbij de focus lag op cloud-kosten optimaliseren en tegelijk de prestaties van de applicatie hoog houden.
