In een Kubernetes-cluster is de status van je cluster een belangrijk gegeven. De status beschrijft 'hoe het cluster er uit moet zien', bijvoorbeeld welke versie van een container image er gebruikt moet worden of hoeveel resources een Pod tot zijn beschikking heeft. Voor het beschrijven van de gewenste status van een Kubernetes-cluster wordt vaak gebruik gemaakt van semi-permanente entiteiten genaamd Kubernetes-objects.

Een Kubernetes-cluster maakt doorgaans gebruik van meerdere objecten om de status van een cluster te beschrijven. Ieder object zelf beschrijft op zijn beurt de configuratie van een resource. De beschikbare opties om een object te beschrijven vind je per resource in de Kubernetes API-documentatie.

Kubernetes-objects maken (bijna altijd) gebruik van .yaml-files om JSON-data aan de Kubernetes-API door te geven, bijvoorbeeld via Kubectl. Deze JSON-data beschrijft:

• Welke gecontainerizeerde applicaties er uitgevoerd worden, bijvoorbeeld een Apache-container en op welke nodes deze draaien.
• De resources die beschikbaar zijn voor deze applicaties
• De policies die vaststellen hoe deze applicaties zich gedragen, bijvoorbeeld met betrekking tot herstarts, upgrades en fault-tolerance

Door een Kubernetes-object aan te maken, geef je aan Kubernetes aan hoe de workload van je cluster eruit moet zien, oftewel: wat is de gewenste status van je cluster?

Voor het aanmaken, aanpassen of verwijderen van Kubernetes objects gebruik je de Kubernetes API, die je bijvoorbeeld als volgt aanspreekt met Kubectl voor het aanmaken van een Deployment:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

Spec en status

Kubernetes objects beschrijven een object spec en object status. De object spec is simpelweg een omschrijving van hoe je wil dat het object (bijvoorbeeld een Deployment) eruit komt te zien. De object status stelt vast hoe je object er op dit moment uitziet. Zo kun je bijvoorbeeld vaststellen dat jouw applicatie drie replica's moet uitvoeren. Faalt een van die replica's, dan verandert de object status. Je cluster stelt vast dat de status afwijkt van de spec en Kubernetes zal dan een nieuwe replica spawnen om te zorgen dat de spec en status weer overeenkomen.

De opmaak van een Kubernetes object

Kubernetes objects gebruiken .yaml-files om JSON-data aan de Kubernetes API door te geven. Een dergelijke .yaml-file moet in ieder geval de volgende velden bevatten:

• apiVersion: Welke versie van de Kubernetes gebruik je om dit object te maken
• kind: Wat voor soort object je maakt, meestal een Deployment of pod
• metadata: Data waarmee je je object eenvoudig identificeert, bijvoorbeeld de naam, UID, labels, etc.
• spec: De gewenste status van je object. Dit is anders voor ieder Kubernetes object en bevat gelaagde (nested) velden specifiek voor dat object. Onder 'spec' geef je bijvoorbeeld de technische specificaties van de container op, het aantal replica's, etc.

Een voorbeeld van een .yaml-file die de vereiste velden bevat van de object spec voor een Nginx Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Dit is een voorbeeld van de officiële Kubernetes-organisatie en terug te vinden is op https://k8s.io/examples/application/deployment.yaml. Zoals we eerder in dit artikel zagen kun je met kubectl deze .yaml-file eenvoudig gebruiken om een Deployment aan te maken:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

Daarmee zijn we aan het eind gekomen van dit artikel over Kubernetes-objecten. Wil je meer weten over de structuur van een object en hoe je zelf een object aanmaakt? Zie daarover onze handleiding 'Kubernetes (yaml) objects maken'.