Kubernetes wordt meestal beschreven als een declaratief systeem. Meestal werk je met YAML die bepaalt hoe de eindstatus van het systeem eruit moet zien. Kubernetes ondersteunt echter ook imperatieve API's, waarbij u een opdracht geeft en onmiddellijk een uitvoer krijgt.
In dit artikel zullen we de verschillen tussen deze twee vormen van objectbeheer onderzoeken. De kans is groot dat je beide al hebt gebruikt, zelfs als je de termen niet herkent.
Declaratief versus imperatief: definities
Eerst is het nuttig om de terminologie te onderzoeken.
Iets dat declaratief is, maakt een verklaring van het eindresultaat, waarbij de bedoeling wordt aangegeven, maar niet het proces om het te bereiken. In Kubernetes zegt dit: “Er moet een ReplicaSet zijn met drie pods.”
Een gebiedende wijs werkt als een bevel. Terwijl een declaratief passief is, zijn imperatieven actief en onmiddellijk: “Maak een ReplicaSet met drie pods.”
Het Kubernetes-ecosysteem biedt mechanismen voor interactie met uw cluster in een van deze vormen. Dwingende benaderingen worden verzorgd door CLI-opdrachten en individuele YAML-bestanden. Declaratieve configuratie wordt vergemakkelijkt door gebruik te maken van directory's van bestanden die worden gecombineerd in de uiteindelijke resourcerepresentatie.
Objecten noodzakelijk beheren
Hier is een voorbeeld van het maken van een implementatie verplicht:
kubectl create deployment my-deployment –image my- image:latest
U geeft Kubernetes de opdracht om onmiddellijk een nieuwe implementatie aan uw cluster toe te voegen. De opdracht bevat een enkel werkwoord (creëren) en de naam van het resourcetype waarmee u werkt (implementatie).
Advertentie
U kunt ook een YAML-bestand schrijven en dit verplicht toepassen met het create-commando:
apiVersion: apps/v1 soort: Implementatiespecificatie: replica's: 3 selector: matchLabels: app: voorbeeldsjabloon: metadata: labels: app: voorbeeldspecificatie: # … kubectl create -f deployment.yml
Zoals voorheen 8217; een onmiddellijke opdracht geven via een actief werkwoord. Kubernetes haalt de configuratie uit uw bestand en maakt bijbehorende resources in het cluster. Als u een bron moet bijwerken, moet u uw YAML wijzigen en de opdracht Replace gebruiken om de wijziging door te voeren:
kubectl replace -f deployment.yml
Deze bewerking verwijdert de specificatie van alle bestaande bronnen en vervangt deze door de versie in uw configuratiebestand. Dit wordt overgebracht door de naam van het vervang commando. Dit betekent dat u alle wijzigingen die aan uw live-objecten zijn aangebracht die niet aanwezig zijn in uw YAML, kwijtraakt.
Wanneer Kubernetes imperatieve opdrachten gebruikt, moet het precies worden verteld wat het moet doen. Bijgevolg is er geen manier om selectief alleen de gewijzigde delen van uw YAML toe te passen. Daarvoor moet u overschakelen naar declaratieve bewerkingen.
Declaratief beheer proberen
Declaratief beheer is alleen beschikbaar als u’ opnieuw YAML-configuratiebestanden gebruiken. Er bestaat niet zoiets als een declaratief bevel. Wanneer u declaratieve bewerkingen gebruikt, vertelt u Kubernetes niet wat ze moeten doen door een werkwoord op te geven (creëren/vervangen). In plaats daarvan gebruikt u de enkele toepassingsopdracht en vertrouwt u op Kubernetes om de uit te voeren acties uit te werken.
kubectl apply -f deployment.yml Advertentie
Voortzetting van het implementatievoorbeeld van hierboven, zou het toepassen van de bovenstaande YAML op uw cluster in eerste instantie hetzelfde werken als een dwingende opdracht create. Er zal om te beginnen geen overeenkomende bron bestaan, dus Kubernetes moet een nieuwe maken.
U kunt dan het veld replica's wijzigen in 5 en de opdracht Apply herhalen. Deze keer zal Kubernetes overeenkomen met de bestaande bron, de wijziging in uw YAML detecteren en de implementatie schalen zonder andere velden te beïnvloeden.
Als u de imperatieve benadering gebruikt, moet u de opdracht kubectl scale gebruiken om het aantal replica's van een bestaande implementatie te wijzigen. Als u de YAML die u met kubectl create hebt gebruikt, hebt gewijzigd, moet u kubectl Replace – maar dit zou de volledige specificaties van de implementatie vervangen, in plaats van simpelweg het aantal replica's te schalen.
Declarative vs Imperative: Comparing De afwegingen
Dwingende bewerkingen zijn eenvoudig te begrijpen en te redeneren. Elke actie wordt uitgedrukt als een werkwoord met een duidelijk omschreven gevolg. Om deze reden zullen de meeste mensen hun eerste Kubernetes-interacties beginnen met behulp van imperatieve opdrachten die losjes kunnen worden toegewezen aan andere technologieën zoals Docker.
Declaratief beheer legt de echte kracht van Kubernetes bloot. U geeft aan hoe de uiteindelijke status eruit moet zien en laat Kubernetes de rest doen. Elk commando heeft dezelfde dwingende actie – pas deze set YAML-bestanden toe en breng het cluster voort naar de staat die ze definiëren.
Declaratief beheer is ideaal voor geautomatiseerde implementaties. U hoeft geen tijd te besteden aan het opstellen van een set migratie-instructies elke keer dat u een resource bijwerkt. Pas in plaats daarvan uw YAML aan zodat het correct geconfigureerde objecten zou produceren als ze op dit moment opnieuw zouden worden gemaakt. Kubernetes zal updates van bestaande objecten afhandelen, zodat ze ook overeenkomen met de nieuwe staat.
Advertentie
Declaratieve YAML-bestanden zijn eenvoudig te versie, te beoordelen en samen te voegen als onderdeel van uw broncontrolesysteem. Als je imperatieve commando's gebruikt, heb je geen manier om te volgen hoe je cluster is geëvolueerd en zal het lastiger zijn om terug te gaan naar een eerdere staat. In tegenstelling tot imperatieve bewerkingen, overschrijven declaratieve updates niet het hele object, dus u behoudt wijzigingen die u via andere mechanismen hebt aangebracht, onafhankelijk van uw YAML-bestanden.
Niettemin behoudt noodzakelijk beheer enkele voordelen. Declaratieve configuratie voegt lagen van complexiteit toe en kan moeilijker te debuggen zijn, vooral wanneer Kubernetes een onverwachte manier van handelen selecteert. Elke wijziging resulteert in een samenvoeg- en patchbewerking om uw objecten op één lijn te brengen met uw gewenste staat. Met het imperatiefmodel vraagt u wat u krijgt, tenzij er een fout optreedt.
Zoals altijd wanneer twee benaderingen worden aangeboden, zijn beide strategieën nuttig en moet de keuze van de context afhangen van de context. Voor productieclusters die live-apps hosten met frequente wijzigingen, wilt u waarschijnlijk declaratieve YAML-bestanden met versiebeheer. Als u snel nieuwe containers in een ontwikkelingscluster aan het draaien bent, zullen imperatieve opdrachten tijd besparen en gemakkelijker zijn om mee te werken.
Conclusie
Declaratief en imperatief beheer zijn twee manieren om te communiceren met uw Kubernetes-cluster en de bijbehorende resources. Kubectl heeft ondersteuning voor beide strategieën geïntegreerd, maar de technieken mogen niet per object worden gemengd. Als je een object declaratief maakt, moet het zijn hele leven op die manier worden beheerd – het gebruik van imperatieve commando's kan leiden tot onverwacht gedrag.
Dwingende bewerkingen hebben invloed op levende objecten binnen uw cluster. U definieert een werkwoord, resource en configuratie via opdrachtargumenten en vlaggen. Declaratief beheer is gebaseerd op wijzigingen in lokale configuratiebestanden die Kubectl diffs en toepast op het cluster via patches wanneer u de opdrachten kubectl diff en kubectl apply gebruikt.