‫Tot nu toe hebben we met Kubernetes niet echt gesproken over
‫opslag of volumes.
‫Je hebt dat behandeld met Docker, en vervolgens
‫met Compose en Swarm en tot op zekere hoogte is het
‫hetzelfde in Kubernetes.
‫Je hebt containers en we gaan ervan uit dat
‫de containers stateloos zijn, wat betekent dat als je
‫de container weggooit, alles erin weggaat.
‫Wanneer je een container vervangt door een update, of je
‫verandert iets en je past het toe met een kubectl-app, verlies je de container, je verliest
‫alles wat erin zit.
‫Het is duidelijk dat Kubernetes, net als de
‫andere orkestrators, een manier moet hebben om
‫persistente gegevens te behouden. Het is zelfs meer dan de volumes zelf.
‫Zelfs de containers en implementaties kunnen in Kubernetes anders zijn met
‫iets dat een StatefulSets wordt genoemd.
‫Dit zijn resources die anders zijn
‫dan implementaties.
‫Ze zijn in feite ontworpen rond databases en dingen die
‫veel meer doorzettingsvermogen vereisen, inclusief dezelfde
‫naam, dezelfde IP-dingen zoals dat.
‫We kregen dat niet per se met Swarm
‫of met Docker.
‫Het had niet echt een manier om die
‫verschillende attributen tussen containers te houden.
‫StatefulSets is een nieuwe functie in Kubernetes
‫die hier nog maar een korte tijd beschikbaar is.
‫Het is waar je naar zou kijken
‫als je databases gaat overwegen of iets dat erg gevoelig is
‫voor veranderingen zoals namen, en IP-adressen, en volumes, en
‫permanente gegevens. Een woord van waarschuwing hier.
‫De reden dat we er niet veel
‫details van zullen bespreken, is omdat ik niet aanraad dat
‫uw eerste implementatie van Kubernetes
‫veel StatefulSets bevat. Idealiter is je eerste inzet van
‫een orchestrator, van welke orchestrator dan ook, of het
‫nu Swarm of Kubernetes is, alleen betrokken bij stateless en weet
‫je, houd het simpel. Misschien doe je gewoon je webfrontends
‫of sommige API's, of sommige worker-functies, of iets waar geen
‫databases bij betrokken zijn. Als u clouddatabases kunt gebruiken,
‫doe dat dan.
‫Ik raad altijd aan om uw databases uit te
‫besteden, tenzij u specifieke vereisten heeft die u niet kunt
‫vermijden om zelf te draaien. Orkestratie was aanvankelijk echt
‫ontworpen rond containers die onveranderlijk, en gedistribueerd en
‫vervangbaar waren.
‫Dit idee van plakkerigheid voor statefulness zal meer werk
‫en complexiteit toevoegen, en veel meer
‫testen voor je. In het ideale geval hoeft u zich
‫hier geen zorgen over te maken.
‫Later, als je eenmaal veel meer op je gemak bent met alle andere
‫dingen rond Kubernetes, dan kun je terugkomen en zeggen:
‫nu wil ik mijn databases overwegen.
‫Het is niet zo dat u databases niet in clusters moet uitvoeren.
‫Het is gewoon meer werk. Het is moeilijker.
‫Databases en permanente opslag zijn altijd moeilijker en gedetailleerder om
‫mee te werken. Daar is mijn professionele tip.
‫Met elke container kun je een volume toevoegen
‫dat erg lijkt op hoe je deed in Swarm
‫en in Docker en Docker Compose. U kunt gewoon een volumeverklaring toevoegen in
‫de sjabloon binnen de specificaties. Als je aan het YAML-bestand denkt,
‫kunnen we er gewoon een volume in plaatsen zoals je zou
‫verwachten, en het exacte formaat en de
‫details staan in de bronnen. In tegenstelling tot Docker en
‫Swarm waar het volume bij een container zit, is het
‫in dit geval technisch gezien bij de pod. Het maakt verbinding met elke container, of slechts één container,
‫in de pod als je dat aangeeft.
‫Je bestuurt het dus op containerniveau, maar de volharding is met
‫het pod-niveau. Er is
‫een nieuwere functie die persistente volumes is.
‫Dat werkt met iets anders dat een claim wordt genoemd.
‫Het interessante idee hiervan is dat je
‫het gebruikt, of je definieert het, buiten
‫de pods. Je creëert in feite
‫die bron op zichzelf, en dan maak je een
‫claim tegen die bron in je pod-specificatie.
‫De reden dat dit interessanter is, is dat aangezien Kubernetes
‫de onderneming overneemt, je vaak mensen hebt die voor
‫de opslag zorgen, vaak opslag van derden, en dat is niet hetzelfde team
‫dat Kubernetes runt.
‫Zij zullen degenen zijn die betrokken zijn bij het beheren en
‫creëren van deze persistente volumes.
‫Dan zijn het de applicatie-implementers die gaan zeggen, hey,
‫ik heb een
‫volume van dit type nodig. Dus ik ga een claim indienen
‫over SSD of we hebben RAM-opslag nodig, of misschien heb ik NFS nodig, of
‫wat dan ook. Die opslag
‫wordt automatisch geleverd omdat het opslagteam deze
‫al in Kubernetes heeft ingesteld.
‫Dat is een beetje het idee rond aanhoudende volumes.
‫Als je tijdelijk wat eenvoudige opslag op een
‫enkele server nodig hebt voor de pod, gebruik dan gewoon
‫het standaardvolume-kenmerk.
‫Een laatste ding hier
‫gaat over het maken van CSI-plug-ins. In de geschiedenis
‫van Kubernetes werd alles wat opslag van derden was,
‫of het nu cloudopslag of opslag van een externe leverancier
‫was, of iets speciaals, al die dingen
‫toegevoegd in de boomstructuur.
‫Dat betekent dat het is toegevoegd aan de binaire bestanden van
‫Kubernetes en is verzonden met Kubernetes.
‫Dat betekent dat Kubernetes werd geleverd met Amazon en Azure-opslag die
‫direct uit de doos is gebouwd.
‫Dat was best handig, maar het voegde
‫zoveel uitdagingen toe.
‫De meeste daarvan hielden verband met het feit
‫dat opslagverkopers nu code aan de kern van uw systeem bijdroegen die
‫u waarschijnlijk niet eens nodig had, omdat u misschien maar één opslagverkoper gebruikt,
‫dus waarom ze allemaal?
‫Bovendien moesten de opslagverkopers hun releasecycli rond de Kubernetes-releasecyclus
‫beheersen, en het was geen erg
‫flexibel model.
‫Dus de industrie kwam samen, en net
‫als met netwerken en met Dockerfiles en afbeeldingen zelf, creëerde
‫het een standaard. Die standaard is de CSI.
‫Dat staat voor Container Storage Interface.
‫Dat gaat nu plug-ins bieden, zodat elke opslagverkoper een plug-in
‫kan maken die je op alle knooppunten zou installeren,
‫en dat zou anders zijn op basis van
‫de plug-in en hun instructies.
‫Vervolgens werken ze op een standaard API die de CSI biedt,
‫zodat al uw containers die
‫plug-in kunnen gebruiken om naar hun opslag te gaan.
‫Dat is een veel beter en flexibeler model.
‫Dat is een beetje de toekomst van Kubernetes, maar
‫het is nog vrij nieuw. Zo vaak in voorbeelden,
‫en zelfs uw opslagleveranciers kunnen aanbevelen, afhankelijk van hun
‫volwassenheid van CSI, dat u hun traditionele plug-in gebruikt, die
‫is ingebouwd in Kubernetes en kant-en-klaar wordt geleverd.