Engineer Insights | Kubernetes v1.36 onder de loep met Martijn

Bij HybrIT geloven we dat je pas écht waarde levert als je vooroploopt in de techniek. In onze gloednieuwe rubriek 'Engineer Insights' vragen we een van onze Engineers naar de scherpste randjes van een actueel tech-topic.  

Kubernetes v1.36 is live. Bij HybrIT zitten we er direct bovenop om te zorgen dat de infrastructuren van onze klanten stabiel, veilig en toekomstbestendig blijven. Vandaag trappen we af met Martijn, Senior Platform Engineer. In dit interview legt hij de impact van deze release bloot en beantwoordt hij 5 cruciale vragen over wat deze update concreet betekent voor overheden en complexe enterprise-omgevingen. Van het opruimen van legacy AppArmor-annotaties tot de stabiele integratie van user-namespaces: dit is wat je vandaag nog moet weten.  

1. In v1.36 worden de oude AppArmor-annotations definitief verwijderd. Hoeveel legacy-code moeten wij (of onze klanten) de komende tijd gaan opruimen om klaar te zijn voor deze upgrade?

Martijn:

AppArmor is al een tijdje (sinds versie 1.31) onderdeel van het securityContext-block van pods. Voorheen, toen deze functionaliteit nog in bèta was, moest je AppArmor configureren door middel van het zetten van annotaties. Deze functionaliteit verdwijnt dus.

Het is belangrijk om, voordat je gaat upgraden en je dit nog niet gedaan had, alle AppArmor-configuraties door middel van annotaties om te schrijven naar een securityContext-definitie. Anders verliest een applicatie zijn AppArmor-profiel na deze update, waardoor er sluipend een stukje security kan verdwijnen. Het is vrij simpel:

YAML

apiVersion: v1
kind: Pod
metadata:
  name: hello-apparmor
spec:
  securityContext:
    appArmorProfile:
      type: Localhost
      localhostProfile: k8s-apparmor-example-deny-write
  containers:
  - name: hello
    image: busybox:1.28
    command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

2. User-namespaces integratie is in v1.36 eindelijk stabiel (GA), waardoor root-rechten in een container veiliger zijn op de host. Gaan we dit bij onze enterprise- en overheidsklanten direct als standaard invoeren, of is de praktijk weerbarstiger?

Martijn:

Container-escapes en het comprimeren van de host-omgeving is HET veiligheidsaspect waar Kubernetes mee te maken heeft en welke de meeste impact heeft. Kubernetes kent veel knopjes die container-escapes kunnen belemmeren of voorkomen. Zonder al te veel in details te treden, komt er nu een belangrijk knopje bij.

Per default draaien helaas veel pods in de praktijk als root binnen de container(s). Voorheen betekende dat het root user-id (0) binnen de container ook het root user-id (0) op de host-omgeving was. Ondanks dat de container-runtime hier nog een hoop security bovenop zet, zoals Seccomp en het beperken van de capabilities van de container, zit hier een risico. Mochten deze security-maatregelen falen, dan kan een aanvaller vanuit een gecompromitteerde container veel schade aanbrengen aan de host-omgeving.

De user-namespaces integratie vanuit Kubernetes doet het her-mappen van de user-id van de container naar een niet-root user-id op de host-omgeving. Hierdoor ben je alleen root binnen de eigen container-namespace. Het is vrij triviaal om dit aan te zetten en dit zal standaard meegenomen worden in de beveiligingsmaatregelen van Kubernetes-teams, naast de bestaande maatregelen.

3. Er zit veel vernieuwing in v1.36 rondom Dynamic Resource Allocation (DRA) voor GPU's en AI-workloads. Merken we bij onze klanten al écht de vraag naar deze specifieke AI-infrastructuur op Kubernetes, of is het nu nog vooral een tech-hype?

Martijn:

Het schedulen van pods ging van oudsher om CPU en geheugen. Gespecialiseerde hardware zoals GPU's ging via de oude Device Plugin API, en dat was vrij houtje-touwtje: je vroeg simpelweg een heel getal aan GPU's aan, zonder veel verfijning.

DRA draait dat om: een workload beschrijft wát voor device het nodig heeft (bijvoorbeeld een GPU met minimaal zoveel geheugen) en laat de scheduler de beste match bepalen. Sinds versie 1.36 is hier dus ook ondersteuning voor GPU's, wat het draaien van een eigen ML/AI-workload net weer wat makkelijker maakt.

Of het een hype is? Voor veel teams is het draaien van eigen GPU-clusters een operationeel zware en dure bezigheid. Klanten die iets met AI willen doen, zullen zich eerst afvragen of ze beter af zijn met het afnemen van een managed AI-inference dienst. De klanten waar ik momenteel voor werk, zijn zelf nog niet bezig met het inrichten van een eigen AI-infrastructuur.

4. OCI Artifact Volumes zijn nu stabiel, waardoor je bestanden en configuraties rechtstreeks vanuit een registry kunt mounten in plaats van ze in een image te bakken. Waarvoor zou je als team dit eigenlijk willen gebruiken?

Martijn:

Deze functionaliteit laat je een OCI-image of -artifact uit een registry rechtstreeks als volume mounten in een pod, zonder dat je die content in je applicatie-image hoeft te bakken. Het mooie hieraan is dat je je data en configuratie loskoppelt van je applicatie, waardoor je beide onafhankelijk van elkaar kunt versioneren en updaten.

In de praktijk komt dit op een aantal plekken goed van pas. De meest interessante op dit moment zijn AI/ML-workloads: model-gewichten zijn al snel vele gigabytes groot. Door die als los OCI-artifact te versioneren en te mounten, hoef je je inference-image niet steeds opnieuw te bouwen en te pushen zodra er een nieuw model is. Voor klanten die ML/AI toepassen is dit zeer zeker relevant om te gaan gebruiken.

5. Kubernetes v1.36 is net uit. Als je nu op een project zit, wanneer adviseer jij de klant dan om daadwerkelijk de overstap te maken? Wacht je op OpenShift/Managed Cloud updates, of ga je direct testen?

Martijn:

 Bijblijven is altijd belangrijk. Als team hebben wij veel aandacht besteed aan ons LCM (Life Cycle Management) proces en zorgen we ervoor dat we nooit meer dan twee Kubernetes-versies achterlopen.

Ook sparren met experts die de techniek écht doorgronden?

Of je nu voor een uitdaging staat binnen een complexe enterprise-omgeving of de security-architectuur van een overheidsorganisatie naar een Cloud Native niveau wilt tillen: onze Code.Creators staan voor je klaar.  

• Voor organisaties: Sparren over Kubernetes v1.36 of cloud-native infrastructuur? Neem direct contact op via info@hybrit.nl of bel +31 (0)30 227 3197.  

• Voor ambitieuze engineers: Ben jij een medior of senior DevOps Engineer en wil je werken in een team waar kennisdeling en technologische vooruitgang écht op één staan? Bekijk direct onze DevOps vacature en groei door tot een absolute autoriteit in je vakgebied!