Opmerking. vert.: In de Kubernetes-gemeenschap wint een trend genaamd GitOps duidelijk aan populariteit, zoals we persoonlijk hebben gezien: KubeCon Europe 2019. Deze term was relatief recent door het hoofd van Weaveworks - Alexis Richardson - en betekent het gebruik van tools die bekend zijn bij ontwikkelaars (voornamelijk Git, vandaar de naam) om operationele problemen op te lossen. In het bijzonder hebben we het over de werking van Kubernetes door de configuraties ervan in Git op te slaan en wijzigingen automatisch door te rollen naar het cluster. Matthias Jg vertelt in dit artikel over twee benaderingen van deze uitrol.
Vorig jaar, (in feite gebeurde dit formeel in augustus 2017 - ca. vert.) Er is een nieuwe aanpak voor het implementeren van applicaties in Kubernetes. Het heet GitOps en is gebaseerd op het basisidee dat implementatieversies worden bijgehouden in de beveiligde omgeving van een Git-repository.
De belangrijkste voordelen van deze aanpak zijn als volgt::
- Implementatieversiebeheer en wijzigingsgeschiedenis. De status van het hele cluster wordt opgeslagen in een Git-repository, en implementaties worden alleen bijgewerkt via commits. Bovendien kunnen alle wijzigingen worden gevolgd met behulp van de commitgeschiedenis.
- Terugdraaien met bekende Git-opdrachten... gewoon
git resetstelt u in staat wijzigingen in implementaties opnieuw in te stellen; eerdere staten zijn altijd beschikbaar. - Klaar toegangscontrole. Normaal gesproken bevat een Git-systeem veel gevoelige gegevens, dus besteden de meeste bedrijven speciale aandacht aan de bescherming ervan. Dienovereenkomstig geldt deze bescherming ook voor operaties met inzet.
- Beleid voor implementaties. De meeste Git-systemen ondersteunen standaard beleid per branche. Alleen pull-aanvragen kunnen bijvoorbeeld de master bijwerken, en wijzigingen moeten worden beoordeeld en geaccepteerd door een ander teamlid. Net als bij toegangscontrole is hetzelfde beleid van toepassing op implementatie-updates.
Zoals je kunt zien, zijn er veel voordelen aan de GitOps-methode. Het afgelopen jaar hebben twee benaderingen bijzondere populariteit gewonnen. De één is gebaseerd op push, de ander is gebaseerd op pull. Voordat we ze bekijken, laten we eerst kijken hoe typische Kubernetes-implementaties eruit zien.
Implementatiemethoden
De afgelopen jaren zijn er in Kubernetes verschillende methoden en tools voor implementaties ontwikkeld:
- Gebaseerd op native Kubernetes/Kustomize-sjablonen. Dit is de eenvoudigste manier om applicaties op Kubernetes te implementeren. De ontwikkelaar maakt de basis-YAML-bestanden en past deze toe. Om te voorkomen dat je steeds dezelfde templates moet herschrijven, is Kustomize ontwikkeld (het zet Kubernetes-templates om in modules). Opmerking. vert.: Kustomize is geïntegreerd in kubectl met .
- Helm-grafieken. Met Helm-diagrammen kunt u sets sjablonen maken, containers, zijspannen, enz. initiëren, die worden gebruikt om toepassingen te implementeren met flexibelere aanpassingsopties dan bij een op sjablonen gebaseerde aanpak. Deze methode is gebaseerd op YAML-sjabloonbestanden. Helm vult ze met verschillende parameters en stuurt ze vervolgens naar Tiller, een clustercomponent die ze in het cluster implementeert en updates en rollbacks mogelijk maakt. Het belangrijkste is dat Helm in essentie gewoon de gewenste waarden in de sjablonen invoegt en deze vervolgens op dezelfde manier toepast als bij de traditionele aanpak (lees meer over hoe het allemaal werkt en hoe je het kunt gebruiken in onze — ca. vert.). Er is een grote verscheidenheid aan kant-en-klare Helm-kaarten die een breed scala aan taken bestrijken.
- Alternatieve hulpmiddelen. Er zijn veel alternatieve hulpmiddelen. Wat ze allemaal gemeen hebben, is dat ze sommige sjabloonbestanden omzetten in Kubernetes-leesbare YAML-bestanden en deze vervolgens gebruiken.
In ons werk gebruiken we voortdurend Helm-grafieken voor belangrijke tools (aangezien ze al veel dingen klaar hebben staan, wat het leven veel gemakkelijker maakt) en ‘pure’ Kubernetes YAML-bestanden voor het implementeren van onze eigen applicaties.
Trekken duwen
In een van mijn recente blogposts introduceerde ik de tool , waarmee u sjablonen kunt vastleggen in de Git-repository en de implementatie kunt bijwerken na elke vastlegging of push van de container. Uit mijn ervaring blijkt dat deze tool een van de belangrijkste is bij het promoten van de pull-aanpak, dus ik zal er vaak naar verwijzen. Als je meer wilt weten over hoe je het kunt gebruiken, kun je hier terecht .
NB! Alle voordelen van het gebruik van GitOps blijven voor beide benaderingen hetzelfde.
Op pull gebaseerde aanpak
De pull-aanpak is gebaseerd op het feit dat alle wijzigingen vanuit het cluster worden doorgevoerd. Er is een operator binnen het cluster die regelmatig de bijbehorende Git- en Docker Registry-repository's controleert. Als er wijzigingen in optreden, wordt de status van het cluster intern bijgewerkt. Dit proces wordt over het algemeen als zeer veilig beschouwd, omdat geen enkele externe client toegang heeft tot clusterbeheerdersrechten.
Voors:
- Geen enkele externe client heeft rechten om wijzigingen aan te brengen in het cluster; alle updates worden van binnenuit uitgerold.
- Met sommige hulpprogramma's kunt u ook Helm-diagramupdates synchroniseren en deze aan het cluster koppelen.
- Docker Registry kan worden gescand op nieuwe versies. Als er een nieuwe image beschikbaar is, worden de Git-repository en -implementatie bijgewerkt naar de nieuwe versie.
- Pull-tools kunnen worden gedistribueerd over verschillende naamruimten met verschillende Git-opslagplaatsen en machtigingen. Hierdoor kan een multitenantmodel worden gebruikt. Team A kan bijvoorbeeld naamruimte A gebruiken, team B kan naamruimte B gebruiken en het infrastructuurteam kan de globale ruimte gebruiken.
- In de regel zijn de gereedschappen erg licht van gewicht.
- Gecombineerd met tools zoals operator kunnen geheimen gecodeerd worden opgeslagen in een Git-repository en binnen het cluster worden opgehaald.
- Er is geen verbinding met CD-pijplijnen omdat implementaties binnen het cluster plaatsvinden.
Tegens:
- Het beheren van implementatiegeheimen uit Helm-diagrammen is moeilijker dan gewone, omdat ze eerst moeten worden gegenereerd in de vorm van bijvoorbeeld verzegelde geheimen, vervolgens moeten worden gedecodeerd door een interne operator, en pas daarna beschikbaar komen voor de pull-tool. Vervolgens kunt u de release in Helm uitvoeren met de waarden in de reeds geïmplementeerde geheimen. De eenvoudigste manier is om een geheim te maken met alle Helm-waarden die voor de implementatie worden gebruikt, deze te decoderen en aan Git vast te leggen.
- Wanneer u kiest voor een pull-aanpak, raakt u gebonden aan pull-tools. Dit beperkt de mogelijkheid om het implementatieproces in een cluster aan te passen. Kustomize wordt bijvoorbeeld gecompliceerd door het feit dat het moet worden uitgevoerd voordat de definitieve sjablonen worden vastgelegd in Git. Ik zeg niet dat je geen zelfstandige tools kunt gebruiken, maar ze zijn moeilijker te integreren in je implementatieproces.
Push-gebaseerde aanpak
Bij de push-aanpak lanceert een extern systeem (voornamelijk CD-pijplijnen) implementaties naar het cluster na een commit naar de Git-repository of als de vorige CI-pijplijn succesvol is. Bij deze aanpak heeft het systeem toegang tot het cluster.
Voors:
- De beveiliging wordt bepaald door de Git-repository en de build-pijplijn.
- Het implementeren van Helm-grafieken is eenvoudiger en ondersteunt Helm-plug-ins.
- Geheimen zijn gemakkelijker te beheren omdat geheimen kunnen worden gebruikt in pipelines en ook gecodeerd kunnen worden opgeslagen in Git (afhankelijk van de voorkeuren van de gebruiker).
- Er is geen verbinding met een specifiek gereedschap, omdat elk type kan worden gebruikt.
- Updates van de containerversie kunnen worden geïnitieerd door de build-pijplijn.
Tegens:
- De clustertoegangsgegevens bevinden zich in het buildsysteem.
- Het updaten van implementatiecontainers is nog steeds eenvoudiger met een pull-proces.
- Grote afhankelijkheid van het CD-systeem, aangezien de pijplijnen die we nodig hebben oorspronkelijk geschreven kunnen zijn voor Gitlab Runners, en het team vervolgens besluit om over te stappen naar Azure DevOps of Jenkins... en een groot aantal build-pijplijnen zal moeten migreren.
Resultaten: duwen of trekken?
Zoals meestal het geval is, heeft elke aanpak zijn voor- en nadelen. Sommige taken zijn gemakkelijker uit te voeren met de ene en moeilijker met de andere. In eerste instantie deed ik de implementaties handmatig, maar nadat ik een paar artikelen over Weave Flux tegenkwam, besloot ik GitOps-processen voor alle projecten te implementeren. Voor basissjablonen was dit eenvoudig, maar toen begon ik problemen te ondervinden met Helm-diagrammen. Destijds bood Weave Flux alleen een rudimentaire versie van de Helm Chart Operator aan, maar zelfs nu zijn sommige taken moeilijker vanwege de noodzaak om handmatig geheimen te creëren en deze toe te passen. Je zou kunnen stellen dat de pull-aanpak veel veiliger is omdat de inloggegevens van het cluster niet toegankelijk zijn buiten het cluster, waardoor het zo veel veiliger is dat het de extra moeite waard is.
Na enig nadenken kwam ik tot de onverwachte conclusie dat dit niet zo is. Als we het hebben over componenten die maximale bescherming vereisen, bevat deze lijst geheime opslag, CI/CD-systemen en Git-repository's. De informatie daarin is zeer kwetsbaar en heeft maximale bescherming nodig. Bovendien, als iemand in je Git-repository komt en daar code kan pushen, kan hij of zij alles inzetten wat hij wil (of het nu pull of push is) en de systemen van het cluster infiltreren. De belangrijkste componenten die moeten worden beschermd zijn dus de Git-repository en CI/CD-systemen, en niet de clusterreferenties. Als u goed geconfigureerd beleid en beveiligingscontroles heeft voor dit soort systemen, en clusterreferenties alleen als geheimen in pipelines worden geëxtraheerd, is de extra beveiliging van een pull-aanpak wellicht niet zo waardevol als aanvankelijk werd gedacht.
Dus als de pull-aanpak arbeidsintensiever is en geen veiligheidsvoordeel oplevert, is het dan niet logisch om alleen de push-aanpak te gebruiken? Maar iemand zou kunnen beweren dat je bij de push-aanpak te veel gebonden bent aan het CD-systeem en misschien is het beter om dit niet te doen, zodat het in de toekomst gemakkelijker wordt om migraties uit te voeren.
Naar mijn mening (zoals altijd) moet je gebruiken wat het meest geschikt is voor een bepaald geval of combineren. Persoonlijk gebruik ik beide benaderingen: Weave Flux voor op pull gebaseerde implementaties die grotendeels onze eigen services omvatten, en een push-aanpak met Helm en plug-ins, waardoor het eenvoudig is om Helm-grafieken op het cluster toe te passen en u naadloos geheimen kunt creëren. Ik denk dat er nooit één oplossing zal zijn die geschikt is voor alle gevallen, omdat er altijd veel nuances zijn en deze afhankelijk zijn van de specifieke toepassing. Dat gezegd hebbende, raad ik GitOps ten zeerste aan: het maakt het leven een stuk eenvoudiger en verbetert de veiligheid.
Ik hoop dat mijn ervaring met dit onderwerp u zal helpen beslissen welke methode het meest geschikt is voor uw type implementatie, en ik hoor graag uw mening.
PS Opmerking van de vertaler
Het nadeel van het pull-model is dat het moeilijk is om gerenderde manifesten in Git te plaatsen, maar er is geen nadeel dat de CD-pijplijn in het pull-model gescheiden leeft van de uitrol en in wezen een categoriepijplijn wordt. Continu toepassen. Daarom zullen er nog meer inspanningen nodig zijn om de status van alle implementaties te verzamelen en op de een of andere manier toegang te bieden tot logbestanden/status, bij voorkeur met verwijzing naar het CD-systeem.
In die zin stelt het push-model ons in staat om op zijn minst enkele garanties voor de uitrol te bieden, omdat de levensduur van de pijpleiding gelijk kan worden gemaakt aan de levensduur van de uitrol.
We hebben beide modellen geprobeerd en kwamen tot dezelfde conclusies als de auteur van het artikel:
- Het pull-model is voor ons geschikt om updates van systeemcomponenten op een groot aantal clusters te organiseren (zie. ).
- Het pushmodel op basis van GitLab CI is zeer geschikt voor het uitrollen van applicaties met behulp van Helm-grafieken. Tegelijkertijd wordt met de tool de uitrol van implementaties binnen pijpleidingen gemonitord . Trouwens, in de context van dit project van ons hoorden we de constante “GitOps” toen we de urgente problemen van DevOps-ingenieurs bespraken op onze stand op KubeCon Europe'19.
PPS van vertaler
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Alleen geregistreerde gebruikers kunnen deelnemen aan het onderzoek. , Alsjeblieft.
Maak je gebruik van GitOps?
-
Ja, trekaanpak
-
Ja, duwen
-
Ja, trekken + duwen
-
Ja, nog iets
-
Geen
30 gebruikers hebben gestemd. 10 gebruikers onthielden zich van stemming.
Bron: www.habr.com