Het debuggen van applicaties die draaien op Kubernetes kan heel makkelijk zijn, mits je in je containers zelf daar de goede tools voor hebt. Nu gaat er natuurlijk niks boven goede instrumentatie met goede traces, logs, en metrics, maar helaas zijn die niet altijd beschikbaar. Echte debugging tools in je container images (denk aan bijvoorbeeld gdb en vrienden) is vaak niet aan te raden, omdat we vanuit een beveiligings-standpunt dat soort tools niet in onze images willen hebben zitten. Het wordt pas echt leuk als je container images zelfs geen shell erin hebben zitten. Denk hierbij aan de groeiende hoeveelheid “Distroless”-images, maar ook aan images met slechts een enkele, statisch-gelinkte, binary, zoals veel Golang applicaties.

Ze zeiden dat het niet kon. Dat er niet genoeg CPU was, niet genoeg geheugen, niet genoeg I/O. Maar ze hadden het allemaal fout! Na maanden zwoegen over een assembler, wat vieze hacks, en een heleboel optimalisatie is het dan gelukt: HCS heeft Kubernetes geport naar de Commodore 64! Nog lang niet alle resource types worden ondersteund, meer dan 2 à 3 containers draaien (of een grotere container) is nog wat moeizaam, maar het werkt! Nu we de eerste hordes hebben genomen staan de volgende items op onze roadmap voor de eerste release: Ram Expansion Unit (REU) support → Dit zou ervoor moeten zorgen dat we meer en grotere containers kunnen draaien Persistent Storage (Storageclasses, PVs, PVCs). Heeft waarschijnlijk IDE64 support nodig, 1541 en 1571 zijn te langzaam

De meeste Kubernetes gebruikers weten wel hoe ze Environment Variabelen op een container moeten definiëren. Wat niet iedereen weet is dat je naast het hardcoden van deze variabelen ze ook op meerdere manieren uit ConfigMaps en Secrets kunt alten komen, of zelfs uit specifieke velden van je Pod zelf.