Er is veel veranderd door de komst van containers en de container platformen. We kunnen het platform in zijn geheel als een nieuwe computer beschouwen, met Kubernetes als operating system. Net als ieder operating system, is er hier ook een API. Dus waarom gebruiken wij dit niet in onze applicaties?
Met behulp van een simpele praktische use-case zien we hoe deze nieuwe Kubernetes uitbreiding in Java geïmplementeerd wordt. Binnen dit artikel worden diverse Kubernetes concepten genoemd. Deze worden hier niet nader uitgelegd. Meer informatie over deze concepten is terug te vinden in de officiële Kubernetes documentatie.
De Kubernetes API
De basis van Kubernetes is eenvoudig. Er is een centrale key-value store (etcd) waarin definities worden opgeslagen van de componenten die op het platform aanwezig moeten zijn. Vervolgens zijn er een aantal services die deze store actief monitoren. Deze services zorgen ervoor dat de componenten, zoals gedefinieerd, in de daadwerkelijke staat beschikbaar zijn op het platform. Met andere woorden, als er in etcd staat dat er 10 replicas van een container moeten draaien, is er een service in het platform die continu probeert dit component in deze staat te krijgen.
Deze API is in principe een gewone REST API en kan door iedereen worden gebruikt. Elke resource kan met een aantal standaard calls worden opgevraagd of aangepast. Ook kan er een Watch worden gedaan op een type resource. In dat geval blijft de connectie open en stuurt de Kubernetes API alle ‘add’, ‘update’ en ‘delete’ events die op dit type resource plaatsvinden direct door. Dit laatste is de basis die wordt gebruikt door de control services van Kubernetes om zo het cluster in de gewenste staat te houden.
De API is verder ook uit te breiden met eigen resources. Het enige wat er moet worden gedaan is een definitie aanmaken (custom resource definition, of in het kort CRD). Deze resource wordt daarna hetzelfde behandeld als iedere andere resource. Alle standaard API calls werken ook op de nieuw aangemaakte resource. Een praktisch gevolg is dat kubectl deze resource ook direct kent en het ook mogelijk wordt om bijvoorbeeld een ‘kubectl get’ te doen op deze resources.
Maar hoe kan deze API onze applicaties verrijken? Een populaire toepassing is het maken van operators. Een operator is een type service die verantwoordelijk is voor een aantal operationele taken. Bijvoorbeeld het installeren van een complexe applicatie op het cluster (denk bijvoorbeeld aan een database cluster).
Echter is een operator niet de enige toepassing die mogelijk is. Denk bijvoorbeeld aan een notificatie in een applicatie. Een melding als er groot onderhoud wordt gepleegd, of als er een storing gaande is. We kunnen de Kubernetes API uitbreiden met een custom resource die een melding beschrijft. Wanneer de storing gaande is, maken we de CRD aan en als de storing voorbij is, halen we de notificatie weer weg.
De applicatie kijkt net als Kubernetes of er een notificatie resource aanwezig is. Indien aanwezig laat hij een notificatie banner zien. Als de resource wordt veranderd of verwijderd, past de applicatie deze ook live aan bij de gebruiker.
Een praktisch voorbeeld
Laten we de banner use-case uitwerken en een service bouwen die op basis van een eigen gemaakte ‘Broadcast’ CRD en een websocket een bericht toont op een webpagina. Voordat we hier mee beginnen, moeten we eerst onze omgeving opzetten. Als je geen toegang hebt tot een Kubernetes cluster is Minikube een goed alternatief. Minikube installeert een mini Kubernetes cluster lokaal op je pc die je kan gebruiken om je applicatie te testen.
Met een draaiende Kubernetes kunnen we onze eigen resource gaan toevoegen. Er zijn gelijk een aantal dingen die we moeten configureren. Onder andere de namen waarmee deze resource te benaderen is. Er kunnen verschillende versies van een resource bestaan, waarvoor we voor iedere versie een schema moeten configureren.
1apiVersion: apiextensions.k8s.io/v1
2kind: CustomResourceDefinition
3metadata:
4 name: broadcasts.crddemo.joyrex2001.com
5spec:
6 group: crddemo.joyrex2001.com
7 scope: Namespaced
8names:
9 kind: Broadcast
10 plural: broadcasts
11 singular: broadcast
12versions:
13- name: v1
14 storage: true
15 served: true
16 schema:
17 openAPIV3Schema:
18 type: object
19 x-kubernetes-preserve-unknown-fields: true
Met de CRD in het systeem, kunnen we nu een broadcast met kleur en tekst toevoegen. In onze CRD hebben we validatie uitgezet en hebben de gezegd dat Kubernetes instanties van onze resource zonder modificaties moet opslaan. Dit is handig voor development, omdat we dan niet genoodzaakt zijn om al onze velden vooraf te bedenken.
1apiVersion: crddemo.joyrex2001.com/v1
2kind: Broadcast
3metadata:
4 name: "hello"
5spec:
6 message: "Hello world!"
7 color: "blue"
Nadat we deze resource hebben toegevoegd met kubectl apply -f hello.yaml, is deze ook beschikbaar via de gebruikelijke kubectl commandos. We kunnen bijvoorbeeld alle Broadcast resources opvragen met kubectl get broadcasts. Als we live veranderingen willen zien, kunnen we kubectl get broadcasts -w doen.
Als we willen dat Kubernetes vooraf controleert of de resource aan bepaalde voorwaarden voldoet, kunnen we onze CRD strikter maken. We laten Kubernetes alleen resources accepteren die velden bevatten die in ons schema zijn gedefinieerd. Eventueel kan er volgens de OpenAPI standaard extra validatie worden toegevoegd. Ook kunnen we alternatieve kortere namen configureren voor onze resource.
1apiVersion: apiextensions.k8s.io/v1
2kind: CustomResourceDefinition
3metadata:
4 name: broadcasts.crddemo.joyrex2001.com
5spec:
6 group: crddemo.joyrex2001.com
7 scope: Namespaced
8 names:
9 plural: broadcasts
10 singular: broadcast
11 kind: Broadcast
12 shortNames:
13 - brc
14versions:
15- name: v1
16 storage: true
17 served: true
18 schema: openAPIV3Schema:
19 type: object
20 properties:
21 spec:
22 type: object
23 properties:
24 message:
25 type: string
26 color:
27 type: string
Nu we begrijpen hoe we resources kunnen definiëren en kunnen gebruiken, wordt het hoog tijd om ze te gaan gebruiken. Ik kies in mijn voorbeeld voor Quarkus in combinatie met de fabric8 Kubernetes client. Het voordeel van Quarkus is de snelheid waarmee applicaties worden opgestart en de lagere memory footprint. Deze twee aspecten maken dit framework erg geschikt voor container toepassingen.
We hebben natuurlijk ook wat classes nodig die de CRD implementeren. In principe hebben we er twee nodig; één om een enkele instantie te beschrijven en één om een lijst van meerdere instanties te omschrijven. Elke Kubernetes resource heeft ook een ‘metadata’ sectie, waarin onder andere de unieke naam of eventuele annotaties en labels worden toegevoegd. Dit moeten we dus ook in onze classes toevoegen.
1public class Broadcast extends CustomResource {
2 private static final long serialVersionUID = 1L;
3 private BroadcastSpec spec;
4 public BroadcastSpec getSpec() { return this.spec; }
5 public void setSpec(BroadcastSpec spec) { this.spec = spec; }
6}
7
8public class BroadcastSpec {
9 private String message;
10 public String getMessage() { return this.message; }
11 public void setMessage(String message) { this.message = message; }
12
13private String color;
14 public String getColor() { return this.color; }
15 public void setColor(String color) { this.color = color; }
16}
17
18public class BroadcastList extends CustomResourceList<Broadcast> {
19 private static final long serialVersionUID = 1L;
20}
Bij de fabric8 Kubernetes client kunnen we kiezen uit een Watcher, of een Informer implementatie. Het verschil is dat de Watch implementatie de verantwoordelijkheid voor foutafhandeling en het in stand houden van de http connectie, bij de gebruiker van de API ligt. De Informer implementatie neemt deze verantwoordelijkheid over en is ook efficiënte door het cachen van resources.
Om onze informer te gebruiken, moeten we er voor zorgen dat deze wordt gestart wanneer de service begint. Vervolgens initialiseren we een informer voor onze CRD. In dit geval zeggen we dat er 1 keer per minuut een reconciliation moet worden gedaan. Dit betekent dat er elke minuut ook een volledige status van de resources wordt gestuurd, om te voorkomen dat er events verloren gaan, omdat er toevallig een connectie probleem was tijdens het real-time watchen.
1public class Main {
2 @Inject
3 KubernetesClient client;
4
5 void onStart(@Observes StartupEvent ev) {
6
7 final CustomResourceDefinitionContext crd =
8 new CustomResourceDefinitionContext.Builder()
9 .withVersion("v1")
10 .withScope("Namespaced")
11 .withGroup("crddemo.joyrex2001.com")
12 .withPlural("broadcasts")
13 .build();
14
15 final SharedInformerFactory factory = client.informers();
16 final SharedIndexInformer<Broadcast> informer =
17 sharedInformerFactory.sharedIndexInformerForCustomResource(
18 crd, Broadcast.class, BroadcastList.class, 1 * 60 * 1000);
19
20 informer.addEventHandler(handler);
21 factory.startAllRegisteredInformers();
22 }
23}
Om te reageren op de events die de informer stuurt, moeten we ook een ResourceEventHandler schrijven. Hier gebeurt het echte werk en krijgen we drie verschillende events; add, update en delete.
1public class EventHandler implements ResourceEventHandler<Broadcast> {
2
3 @Override
4 public void onAdd(final Broadcast broadcast) {
5 websocket.addBroadcast(broadcast.getSpec());
6 }
7
8 @Override
9 public void onUpdate(Broadcast oldb, Broadcast newb) {
10 if(!oldb.getMetadata().getResourceVersion()
11 .equals(newb.getMetadata().getResourceVersion()) )
12 {
13 websocket.deleteBroadcast(oldb.getSpec());
14 websocket.addBroadcast(newb.getSpec());
15 }
16 }
17
18 @Override
19 public void onDelete(Broadcast broadcast,
20 boolean deletedFinalStateUnknown) {
21 websocket.deleteBroadcast(broadcast.getSpec());
22 }
23}
Bij het onUpdate event krijgen we de vorig bekende versie van onze resource en de nieuwe versie van de resource binnen. Deze kunnen gelijk zijn en om die reden vergelijken we de versie van de resource of deze inderdaad is veranderd.
De onDelete methode krijgt ook een deletedFinalStateUnknown mee. Deze geeft aan of het geleverde CRD object de state beschrijft tijdens het delete event. Het kan gebeuren dat het daadwerkelijke delete event is gemist door de cliënt, maar dat bij de reconciliation is gebleken dat het object niet meer bestaat. In dat geval geeft het de laatst bekende versie van het object, wat kan verschillen met de versie tijdens het delete event.
Onze informer implementatie roept vervolgens code aan om de broadcasts middels een websocket naar de eindgebruiker te sturen. Mocht je nieuwsgierig zijn naar deze implementatie, kan je naar de repository op GitHub gaan waar dit voorbeeld in zijn geheel is uitgewerkt.
Verdere toepassingen
Dit was natuurlijk een makkelijk voorbeeld. Als onze business logica verder gaat dan alleen een banner afbeelden, bijvoorbeeld wanneer er integraties aan te pas komen, kan er ook meer misgaan. Er komt dan al snel een behoefte voor een retry-mechaniek. De fabric8 client helpt ons hier niet heel veel mee en moeten we een retry zelf moeten. Heel moeilijk is dit ook niet, de fabric8 library vuurt regelmatig ‘updated’ events af, ook al is de resourceVersion niet gewijzigd. Dit kan gebruikt worden voor een retry-implementatie.
Een ander veel voorkomend probleem, is dat sommige resources maar precies een keer verwerkt moeten of zelfs kunnen worden. Als er meerdere replicas draaien, weten deze services niet van elkaar wie welke resource heeft verwerkt. Om dit makkelijker te maken, heeft de fabric8 Kubernetes client leader-election support. Het is dan aan de service zelf of alleen de leader de resource verwerkt, of deze via een ander mechanisme distribueert.
Met dit artikel hebben we gezien dat het niet moeilijk is om een Java applicatie nog meer cloud native te maken door gebruik te maken van de Kubernetes API. Kubernetes is ons nieuwe operating systeem, dus laten we die optimaal gebruiken! CRD’s en de Kubernetes API zijn een mooi stukje gereedschap om bij ons te dragen in het oplossen van onze dagelijkse problemen.
Dit artikel is geschreven door Vincent van Dam en is eerder gepubliceerd in het Java Magazine! Wil je het Java Magazine ook thuis ontvangen? Word lid van de NLJUG!
Vincent van Dam
