Opmerking vertaler.: In de Kubernetes-gemeenschap wint een trend genaamd GitOps duidelijk aan populariteit, iets wat wij persoonlijk hebben ervaren, KubeCon Europe 2019 bij te wonen. Deze term is relatief recentelijk door de CEO van Weaveworks — Alexis Richardson — en betekent het gebruik van vertrouwde tools voor ontwikkelaars (vooral Git, waar de naam ook vandaan komt) voor operationele taken. Met name gaat het om het beheren van Kubernetes door zijn configuraties in Git op te slaan en automatische uitrol van wijzigingen naar de cluster te realiseren. Over twee benaderingen van deze uitrol vertelt Matthias Jg in dit artikel.
Vorig jaar (eigenlijk gebeurde dit formeel in augustus 2017 — opmerking van de vertaler) werd er een nieuwe aanpak voor het uitrollen van applicaties in Kubernetes geïntroduceerd. Dit heet GitOps en de basisgedachte is dat versiebeheer van deployments plaatsvindt in een veilige Git-repository.
De belangrijkste voordelen van deze aanpak zijn als volgt:
- Versiebeheer van deployments en wijzigingsgeschiedenis. De status van de hele cluster wordt opgeslagen in de Git-repository, en deployments worden alleen bijgewerkt via commits. Bovendien kunnen alle wijzigingen worden bijgehouden met behulp van de commitgeschiedenis.
- Rollback met behulp van vertrouwde Git-commando's. Een eenvoudige
git resetmaakt het mogelijk om wijzigingen in deployments terug te draaien; eerdere staten zijn altijd beschikbaar. - Klaar toegangsbeheer. Gewoonlijk bevat een Git-systeem veel vertrouwelijke gegevens, dus de meeste bedrijven besteden bijzondere aandacht aan de beveiliging ervan. Dientengevolge is deze beveiliging ook van toepassing op de operaties met deployments.
- Beleid voor deployments. De meeste Git-systemen ondersteunen vanaf het begin beleidsregels voor verschillende takken — bijvoorbeeld alleen pull-requests kunnen de master bijwerken, en wijzigingen moeten door een ander teamlid worden gecontroleerd en goedgekeurd. Net als bij toegangsbeheer worden dezelfde beleidsregels toegepast op de updates van deployments.
Zoals u kunt zien, heeft de GitOps-methode veel voordelen. In het afgelopen jaar zijn twee benaderingen bijzonder populair geworden. De ene is gebaseerd op push, de andere op pull. Voordat we deze bekijken, laten we eerst eens kijken naar hoe typische Kubernetes-deployments eruitzien.
Deploymentmethoden
In de afgelopen jaren zijn er verschillende manieren en tools voor deployments in Kubernetes ontstaan:
- Gebaseerd op de native sjablonen van Kubernetes/KustomizeDit is de eenvoudigste manier om applicaties in Kubernetes te implementeren. De ontwikkelaar maakt basis YAML-bestanden en past deze toe. Om het constante herschrijven van dezelfde sjablonen te vermijden, is Kustomize ontwikkeld (dit verandert Kubernetes-sjablonen in modules). Opmerking vertaler.: Kustomize is geïntegreerd in kubectl met .
- Helm Charts. Helm Charts stellen je in staat om sets van sjablonen, init-containers, sidecars, enz. te creëren, die worden gebruikt voor de implementatie van applicaties met meer flexibele configuratiemogelijkheden dan de sjabloon-gebaseerde benadering. De basis van deze methode zijn getemplate YAML-bestanden. Helm vult deze met verschillende parameters en stuurt ze vervolgens naar Tiller, de clustercomponent die ze in het cluster implementeert en updates en terugrols mogelijk maakt. Het belangrijke is dat Helm in wezen gewoon de benodigde waarden in de sjablonen invoegt en deze vervolgens toepast zoals het bij de traditionele aanpak wordt gedaan. (voor meer informatie over hoe dit allemaal werkt en hoe je het kunt gebruiken, lees onze – opmerking vert.). Er is een grote verscheidenheid aan kant-en-klare Helm-charts die een breed scala aan taken dekken.
- Alternatieve tools. Er zijn tal van alternatieve tools. Wat hen verbindt, is dat ze bepaalde sjabloonbestanden omzetten in begrijpelijke Kubernetes YAML-bestanden en deze vervolgens toepassen.
In ons werk gebruiken we voortdurend Helm-charts voor belangrijke tools (omdat veel al vooraf is voorbereid, wat het leven aanzienlijk vergemakkelijkt) en 'schone' Kubernetes YAML-bestanden voor het implementeren van onze eigen applicaties.
Pull & Push
In een van mijn recente blogberichten heb ik een tool geïntroduceerd , waarmee je sjablonen in een Git-repository kunt committen en de deployment na elke commit of push van de container kunt bijwerken. Mijn ervaring toont aan dat deze tool een van de belangrijkste is bij het bevorderen van de pull-aanpak, dus ik zal er vaak naar verwijzen. Als je meer wilt weten over hoe je het kunt gebruiken, hier is .
NB! Alle voordelen van het gebruik van GitOps blijven behouden voor beide benaderingen.
Pull-gebaseerde aanpak
De pull-benadering is gebaseerd op het feit dat alle wijzigingen van binnenuit het cluster worden toegepast. Binnen het cluster is er een operator die regelmatig de gekoppelde Git- en Docker Registry-repositories controleert. Als er wijzigingen zijn, wordt de status van het cluster van binnenuit bijgewerkt. Deze methode wordt doorgaans als veilig beschouwd, aangezien geen enkele externe klant toegang heeft tot de beheerdersrechten van het cluster.
Voordelen:
- Geen enkele externe klant heeft de rechten om wijzigingen in het cluster aan te brengen; alle updates worden vanuit het cluster doorgevoerd.
- Sommige tools maken het ook mogelijk om updates van Helm-charts te synchroniseren en deze aan het cluster te koppelen.
- Docker Registry kan worden gescand op nieuwe versies. Wanneer er een nieuw beeld verschijnt, worden de Git-repository en de deployment bijgewerkt naar de nieuwe versie.
- Pull-tools kunnen over verschillende namespaces worden verdeeld met verschillende Git-repositories en toegangsrechten. Dit maakt het mogelijk om een multitenant-model toe te passen. Bijvoorbeeld, team A kan namespace A gebruiken, team B namespace B, en het team dat verantwoordelijk is voor de infrastructuur kan de globale namespace gebruiken.
- Over het algemeen zijn tools tamelijk lichtgewicht.
- In combinatie met tools zoals de operator , kunnen geheimen in versleutelde vorm in de Git-repository worden opgeslagen en binnen het cluster worden opgehaald.
- Er is geen verbinding met CD-pijplijnen, aangezien deployments binnen het cluster plaatsvinden.
Nadelen:
- Het beheren van geheimen van deployments uit Helm-charts isComplexer dan gewone geheimen, omdat ze eerst moeten worden gegenereerd in de vorm van bijvoorbeeld sealed secrets, vervolgens door de interne operator moeten worden ontsleuteld, waarna ze beschikbaar worden voor de pull-tool. Daarna kan een release in Helm worden gestart met de waarden in de al uitgerolde geheimen. De eenvoudigste manier is om een geheim te creëren met alle Helm-waarden die voor de deployment worden gebruikt, deze te ontsleutelen en in Git te committen.
- Bij het toepassen van de pull-aanpak ben je gebonden aan tools die opereren met pulls. Dit beperkt de mogelijkheid om het deploymentproces in een cluster aan te passen. Bijvoorbeeld, werken met Kustomize wordt gecompliceerd doordat het vóór het aanleveren van de uiteindelijke sjablonen in Git moet worden uitgevoerd. Ik zeg niet dat je afzonderlijke tools niet kunt gebruiken, maar ze zijn moeilijker te integreren in het deploymentproces.
Push-gebaseerde aanpak
Bij de push-aanpak start een extern systeem (voornamelijk CD-pijplijnen) de deployments in het cluster na een commit in de Git-repository of na een succesvolle uitvoering van de vorige CI-pijplijn. In deze aanpak heeft het systeem toegang tot het cluster.
Voordelen:
- Beveiliging wordt bepaald door de Git-repository en de build-pijplijn.
- Het is eenvoudiger om Helm-charts te deployen, er is ondersteuning voor Helm-plugins.
- Het beheren van geheimen is gemakkelijker, omdat geheimen in pijplijnen kunnen worden toegepast en ook in Git versleuteld kunnen worden opgeslagen (afhankelijk van de voorkeur van de gebruiker).
- Geen binding aan een specifieke tool, omdat elk type kan worden gebruikt.
- Versie-updates van containers kunnen worden geïnitieerd door de build-pijplijn.
Nadelen:
- Gegevens voor toegang tot het cluster bevinden zich binnen het build-systeem.
- Het updaten van containers deployments blijft eenvoudiger met een pull-proces.
- Sterke afhankelijkheid van het CD-systeem, aangezien de benodigde pijplijnen mogelijk aanvankelijk zijn geschreven voor GitLab Runners, en het team besluit misschien over te schakelen naar Azure DevOps of Jenkins… en er moet een migratie van een groot aantal build-pijplijnen plaatsvinden.
Conclusie: Push of Pull?
Zoals gewoonlijk heeft elke benadering zijn eigen voor- en nadelen. Sommige taken zijn gemakkelijker uit te voeren met de ene methode en moeilijker met de andere. In het begin maakte ik deployments handmatig, maar nadat ik verschillende artikelen over Weave Flux had gelezen, besloot ik GitOps-processen voor alle projecten in te voeren. Voor de basis sjablonen bleek dit eenvoudig te zijn, maar daarna kwam ik moeilijkheden tegen bij het werken met Helm charts. In die tijd bood Weave Flux alleen een vroege versie van de Helm Chart Operator aan, maar zelfs nu zijn sommige taken moeilijker door de noodzaak om handmatig geheimen te creëren en die toe te passen. Je zou kunnen zeggen dat de pull-benadering veel veiliger is, aangezien de clusterreferenties niet buiten het cluster toegankelijk zijn, en dat verhoogt de veiligheid zo veel dat het de extra moeite waard is.
Na wat na te denken, kwam ik tot een onverwachte conclusie dat dit niet het geval is. Wat betreft de componenten die maximale bescherming vereisen, omvat een dergelijke lijst geheimopslag en CI/CD-systemen, Git-repositories. Informatie daarin is zeer kwetsbaar en heeft maximale bescherming nodig. Bovendien, als iemand toegang krijgt tot je Git-repository en code kan pushen, kan hij alles uitrollen wat hij wil (onafhankelijk van de gekozen methode, of het nu pull of push is) en zich binnendringen in de cluster systemen. Dus de belangrijkste componenten die bescherming vereisen zijn de Git-repository en CI/CD-systemen, niet de clusterreferenties. Als je goed ingestelde beveiligingsmaatregelen en -policies hebt voor dergelijke systemen, en als clusterreferenties alleen als geheimen in pipelines worden onttrokken, kan de extra veiligheid van de pull-benadering minder waardevol blijken te zijn dan aanvankelijk gedacht.
Dus, als de pull-benadering arbeidsintensiever is en geen beveiligingsvoordeel biedt, is het dan niet logisch om alleen de push-benadering te gebruiken? Maar iemand zou kunnen beweren dat je bij de push-benadering te afhankelijk bent van het CD-systeem en dat het misschien beter is om dat niet te doen, zodat het in de toekomst gemakkelijker is om migraties uit te voeren.
Naar mijn mening (zoals altijd) moet je gebruiken wat het beste past bij de specifieke situatie of een combinatie maken. Persoonlijk gebruik ik beide benaderingen: Weave Flux voor deploys op basis van pull, die voornamelijk onze eigen services omvatten, en de push-aanpak met Helm en plugins, die het toepassen van Helm-charts op de cluster vereenvoudigt en het mogelijk maakt om zonder problemen geheimen te genereren. Ik denk niet dat er ooit een enkele oplossing zal zijn die voor alle situaties geschikt is, omdat er altijd veel nuances zijn die afhangen van het specifieke gebruiksgeval. Desondanks raad ik GitOps ten zeerste aan — het maakt het leven veel eenvoudiger en verhoogt de beveiliging.
Ik hoop dat mijn ervaring op dit gebied helpt om te bepalen welke methode het beste past voor jouw type deploys, en ik zou graag jouw mening horen.
P.S. Opmerking van de vertaler
Een nadeel van het pull-model is dat het moeilijk is om gerenderde manifesten in Git op te slaan, maar er is geen nadeel dat de CD-pipeline in het pull-model apart van de rollout leeft en in wezen een pipeline van de categorie Continuous Apply. Daarom zijn er nog meer inspanningen nodig om de status van alle deploys te verzamelen en op een of andere manier toegang te geven tot logs/status, bij voorkeur met een koppeling naar het CD-systeem.
In dit opzicht biedt het push-model enige garanties voor de rollout, omdat de levensduur van de pipeline gelijk kan worden gemaakt aan de levensduur van de rollout.
We hebben beide modellen uitgeprobeerd en kwamen tot dezelfde conclusies als de auteur van het artikel:
- Het pull-model is geschikt voor het organiseren van updates van systeemcomponenten op een groot aantal clusters (zie ).
- Het push-model op basis van GitLab CI is goed geschikt voor het uitrollen van toepassingen met behulp van Helm-charts. Daarbij wordt de rollout van deploys binnen de pipelines gevolgd met behulp van de tool . Trouwens, in de context van dit project hoorden we voortdurend "GitOps" toen we de dringende problemen van DevOps-engineers op ons stand op KubeCon Europe'19 bespraken.
P.P.S. van de vertaler
Lees ook op onze blog:
- «»;
- «»;
- «»;
- «».
Alleen geregistreerde gebruikers kunnen deelnemen aan de enquête. , alstublieft.
Gebruik jij GitOps?
Ja, de pull-aanpak
Ja, push
Ja, pull + push
Ja, iets anders
No
30 gebruikers hebben gestemd. 10 gebruikers hebben zich onthouden.
Bron: habr.com
