Blog overzicht

YAML-objecten in Kubernetes

Kubernetes is een orkestratieplatform dat het beheer van cloudapplicaties vereenvoudigt. De workloads die Kubernetes-clusters uitvoeren, definieer je met Kubernetes objects. Die bestaan uit een API-request dat gevoed wordt door informatie uit een JSON-bestand. Ontwikkelaars definiëren dit bestand bij voorkeur met YAML (meestal in een bestand met de naam ‘manifest’).

Zowel YAML (YAML Ain't Markup Language) als JSON (JavaScript Object Notation) zijn mark-up-languages en horen in het rijtje bij XML en HTML thuis. Ze gebruiken tags en elementen om de betekenis van tekst in eenvoudige tekstbestanden te definiëren. Het acroniem van YAML kan voor verwarring zorgen omdat het ontkent dat het een mark-up-language is. Bij de introductie in 2001 stond YAML voor Yet Another Markup Language. De ontwikkelaars waren bang dat mensen opmaak voor gegevensuitwisseling zouden verwarren met tekstopmaak zoals vormgevers dat toepassen. Daarom werd al in 2002 de betekenis van het acroniem veranderd.

JSON vs. YAML

Hoewel de Kubernetes-API gebruik maakt van JSON, zetten de meeste ontwikkelaars YAML in om objecten te definiëren. JSON is door machines eenvoudiger te interpreteren, daarom heeft dit de voorkeur voor de API. Voor mensen is YAML overzichtelijker. JSON vereist dat iedere string tussen dubbele aanhalingstekens staat en gebruikt accolades, vierkante haken en puntkomma’s om andere datatypen te markeren. Het vergt nogal wat ervaring om JSON-opmaak te lezen. YAML werkt met inspringen (bij voorkeur met spaties) om de structuur van gegevens te definiëren en is daarom beter leesbaar.

YAML is beter leesbaar en kan meer

Het is geen toeval dat YAML beter leesbaar is dan JSON. De opmaak is met dit doel ontwikkeld. Overigens betekent een eenvoudiger leesbare opmaak niet dat YAML minder kan. YAML ondersteunt meer datatypes dan JSON. JSON kan namelijk alleen werken met in de opmaak vastgelegde waarden. JSON werkt met getallen, boolean, null, tekenreeksen, arrays en objects (geneste sleutel-waardeparen). YAML kan, naast deze zes standaard datatypen, alle ingebouwde datatypen van dynamische programmeertalen verwerken.

Kubectl zorgt dat Kubernetes je begrijpt

Voordat de Kubernetes-API met een YAML-object aan de gang kan, moet het bestand eerst geconverteerd worden naar het JSON-formaat. Dat hoef je niet zelf te doen. Als je met kubectl een API-request indient over HTTP dan wordt de inhoud van een manifest-bestand automatisch geconverteerd naar JSON. Dat vereist dat het manifest informatie bevat over de versie van de Kubernetes-API die je gebruikt, aangeeft welk type object je wilt maken, metadata bevat waarmee je het object kunt identificeren en een spec bevat waarin de gewenste staat van het object omschreven wordt.

JSON is beter voor machines

Kubernetes werkt met JSON in plaats van YAML omdat de instructies in deze opmaak makkelijker om te zetten zijn naar acties. Zoveel extra moeite het mensen kost om de opmaak te lezen, zoveel eenvoudiger is dat voor machines. Dat betekent dat instructies sneller te verwerken zijn en minder overhead vragen.

Wat kun je met YAML-objecten?

YAML-objecten (met YAML gedefinieerde Kubernetes objects om heel precies te zijn), kun je voor verschillende doeleinden inzetten.

Kubernetes resources definiëren – omschrijf met YAML de gewenste staat die Pods, Deployments, Services, ConfigMaps en PersistentVolumes in het cluster moeten aannemen.

Configuratiebeheer – met YAML stel je omgevingsvariabelen, configuratievolumes en andere waarden die samenhangen met de configuratie van applicaties en infrastructuur in.

Deployments – specificeer details rondom deployments zoals het aantal replica's van een Pod, de benodigde containerimage en de vereiste netwerkpoorten.

Orkestratie en automatisering – kun je zo complex maken als je maar wilt. Vanuit je configuratiebestand orkestreer je applicaties, zelfs als die uit meerdere onderling verbonden resources bestaan. Je kunt de applicaties ook aansturen in combinatie met automatiseringstools zoals Helm, een package manager waarmee je het beheer van Kubernetes-toepassingen vereenvoudigt.

Declaratieve Configuratie – definieer via YAML objecten met de declaratieve configuratie-aanpak van Kubernetes. Je beschrijft de gewenste staat van het systeem in je manifest en Kubernetes zorgt dat de actuele staat daarmee overeenkomt.

Versiebeheer – realiseer je door je YAML-configuratiebestanden op te slaan in een versiebeheersysteem zoals Git. Dit maakt het gemakkelijk om wijzigingen bij te houden, terug te rollen naar vorige versies van een configuratie, en de configuratie tussen omgevingen te synchroniseren.

Resource-beheer – kun je via YAML uitvoeren door ResourceQuotas en LimitRanges in te stellen en zo gebruik van CPU, geheugen en andere resources in het cluster te beperken.

Netwerkbeleid – is te definiëren vanuit je manifest. Hier stel je in hoe groepen pods met elkaar én met andere netwerkdiensten communiceren.

YAML en DevOps zijn een goede match

Als je op basis van DevOps aan de ontwikkeling van Kubernetes werkt, dan kun je met YAML de samenwerking en continuïteit van ontwikkeling en beheer bevorderen. Door YAML-bestanden als 'blauwdruk' voor applicatie-infrastructuur en -configuraties te gebruiken, kun je ze makkelijker delen, herzien en bijwerken. Omdat je met YAML op een gestandaardiseerde manier werkt, kun je de bestanden met de versiebeheertools bijhouden die je ook voor softwarecode gebruikt. Wijzigingen in YAML-bestanden zijn - net als bij elke andere code – bij te houden, te reviewen en terug te draaien. Dit draagt bij aan de stabiliteit en betrouwbaarheid van de infrastructuur.

Werken met Kubernetes? Gebruik YAML!

Om met Kubernetes te werken zijn YAML-objecten onmisbaar. Met deze mark-up-language (die zichzelf geen mark-up-language noemt) kun je complexe systemen beheren met eenvoudige, leesbare bestanden. Wil jij via YAML direct aan de slag met Kubernetes? Ga hierheen om direct jouw eigen Kubernetes-omgeving op te zetten.


Beoordeel dit artikel

Deel dit artikel

Gerelateerde artikelen

Blog overzicht

Auteur: TIP-redactie

Is de auteursnaam die we gebruiken wanneer een blogpost in teamverband door meerdere TransIP’ers is samengesteld. Denk bijvoorbeeld aan een eventverslag of onze Recommends.