{"id":70954,"date":"2020-02-23T00:58:17","date_gmt":"2020-02-22T21:58:17","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ustrojstvo-helm-i-ego-podvodnye-kamni"},"modified":"2020-03-03T16:14:40","modified_gmt":"2020-03-03T13:14:40","slug":"ustrojstvo-helm-i-ego-podvodnye-kamni","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ustrojstvo-helm-i-ego-podvodnye-kamni","title":{"rendered":"Helm-apparaat en de valkuilen ervan","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/b825bfb312b883f5f9c1535036f0c6e8.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/www.artstation.com\/artwork\/YaabJq\">Typhon vrachtvervoerder concept, Anton Swanepoel<\/a><\/noindex><\/p>\n<p>Mijn naam is Dmitry Sugrobov, ik ben ontwikkelaar bij \u2018Leroy Merlin\u2019. In dit artikel zal ik uitleggen waarom Helm nodig is, hoe het het werk met Kubernetes vereenvoudigt, wat er is veranderd in de derde versie en hoe je met zijn hulp applicaties in productie kunt bijwerken zonder downtime.<\/p>\n<p>Dit is een samenvatting op basis van een presentatie op de conferentie <noindex><a rel=\"nofollow\" href=\"https:\/\/corp.mail.ru\/ru\/press\/events\/at-kubernetes-conference\/\">@Kubernetes Conferentie<\/a><\/noindex> by <noindex><a rel=\"nofollow\" href=\"https:\/\/mcs.mail.ru\">Mail.ru Cloud Solutions<\/a><\/noindex> \u2014 als je niet wilt lezen, bekijk dan de video.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"w1PhTe9gnOI\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/w1PhTe9gnOI\/hqdefault.jpg\" alt=\"Video afspelen\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h2>Waarom we Kubernetes in productie gebruiken<\/h2>\n<p>\n\u2018Leroy Merlin\u2019 is de marktleider in de DIY-retailsector in Rusland en Europa. Ons bedrijf heeft meer dan honderd ontwikkelaars, 33.000 interne medewerkers en een enorm aantal mensen die onze hypermarkten en website bezoeken. Om iedereen gelukkig te maken, hebben we besloten standaardbenaderingen in de industrie te volgen. We ontwikkelen nieuwe applicaties met gebruik van microservicesarchitectuur; voor isolatie van omgevingen en correcte levering maken we gebruik van containers; en voor orkestratie gebruiken we Kubernetes. De kosten van het gebruik van orkestrators dalen snel: het aantal ingenieurs dat deze technologie beheerst, groeit, en er komen providers op de markt die Kubernetes als service aanbieden.<\/p>\n<p>Alles wat Kubernetes doet, kan natuurlijk op andere manieren worden gedaan, bijvoorbeeld door een of andere Jenkins en docker-compose vol te stoppen met scripts, maar waarom het leven moeilijker maken als er een kant-en-klaar en betrouwbaar oplossing is? Daarom zijn we naar Kubernetes gegaan en gebruiken het nu al een jaar in productie. Op dit moment hebben we vierentwintig Kubernetes-clusters, waarvan de oudste meer dan een jaar oud is en waarin ongeveer tweehonderd pods draaien.<\/p>\n<h2>De vloek van het grote aantal YAML-bestanden in Kubernetes<\/h2>\n<p>\nOm een microservice in Kubernetes te starten, cre\u00ebren we minstens vijf YAML-bestanden: voor Deployment, Service, Ingress, ConfigMap, Secrets \u2014 en we sturen deze naar het cluster. Voor de volgende applicatie schrijven we hetzelfde pakket aan YAML-bestanden, voor de derde weer een set en zo verder. Het aantal documenten vermenigvuldigd met het aantal omgevingen leidt al snel tot honderden bestanden, en dit zonder rekening te houden met dynamische omgevingen.<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/c46c3f5ae49cbefa4851cbb388bfd051.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nAdam Reese, core maintainer van Helm, introduceerde het concept \u2018<noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/cZ1S2Gp47ng?t=323\">De ontwikkelingscyclus in Kubernetes<\/a><\/noindex>\u2019, die er als volgt uitziet:<\/p>\n<ol>\n<li>Kopieer YAML \u2014 kopieer het YAML-bestand.<\/li>\n<li>Plak YAML \u2014 plak het.<\/li>\n<li>Herstel inspringingen \u2014 corrigeer de inspringingen.<\/li>\n<li>Herhaal \u2014 herhaal opnieuw.<\/li>\n<\/ol>\n<p>\nDe methode werkt, maar je moet vaak YAML-bestanden kopi\u00ebren. Om deze cyclus te veranderen, is Helm bedacht.<\/p>\n<h3>Wat is Helm<\/h3>\n<p>\nTen eerste, Helm \u2014<strong> pakketbeheerder<\/strong>, die helpt om de juiste programma's te vinden en te installeren. Voor de installatie van bijvoorbeeld MongoDB is het niet nodig om naar de offici\u00eble website te gaan en de binaries te downloaden, het volstaat om de opdracht uit te voeren <code>helm install stable\/mongodb<\/code>.<\/p>\n<p>Ten tweede, Helm \u2014 <strong>sjabloon motor<\/strong>, helpt om bestanden te parametriseren. Laten we teruggaan naar de situatie met YAML-bestanden in Kubernetes. Het is eenvoudiger om hetzelfde YAML-bestand te schrijven, enkele placeholders toe te voegen, waarin Helm waarden zal invullen. Dit betekent dat in plaats van een grote set YAML-bestanden er een set sjablonen is, waarin op het juiste moment de juiste waarden worden ingevuld.<\/p>\n<p>Ten derde, Helm \u2014 <strong>de meester van implementatie<\/strong>. Hiermee kunnen applicaties worden ge\u00efnstalleerd, teruggedraaid en ge\u00fcpdatet. Laten we eens kijken hoe dit werkt.<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/8b517dbcf503ced229569fe3726418c8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h3>Hoe Helm gebruiken voor het implementeren van eigen applicaties<\/h3>\n<p>\nWe installeren de Helm-client op de computer, volgens de offici\u00eble <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/intro\/install\/\">handleiding,<\/a><\/noindex>. Vervolgens maken we een set YAML-bestanden aan. In plaats van specifieke waarden op te geven, laten we placeholders achter die Helm in de toekomst met informatie zal vullen. Deze set bestanden wordt een Helm chart genoemd. Deze kunnen op drie manieren naar de Helm-consoleclient worden gestuurd:<\/p>\n<ul>\n<li>geef de map met sjablonen op;<\/li>\n<li>verpak het in een .tar-archief en wijs ernaar;<\/li>\n<li>plaats het sjabloon in een externe repository en voeg een link naar de repository toe in de Helm-client.<\/li>\n<\/ul>\n<p>\nDaarnaast is er een bestand met waarden nodig \u2014 values.yaml. Gegevens daaruit worden in de sjabloon ingevuld. Laten we dat ook maken.<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/c0fe24cc8186640147f95ce201794d96.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIn de tweede versie van Helm is er een aanvullende serverapplicatie \u2014 Tiller. Het hangt buiten Kubernetes en wacht op verzoeken van de Helm-client, en bij een oproep vult het de benodigde waarden in de sjabloon en stuurt dit naar Kubernetes.<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/6b821a0bb4680829d5ce9982d2bb4c55.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nHelm 3 is eenvoudiger: in plaats van sjablonen op de server te verwerken, wordt de informatie nu volledig aan de kant van de Helm-client verwerkt en direct naar de Kubernetes API gestuurd. Deze vereenvoudiging verhoogt de veiligheid van de cluster en vergemakkelijkt de uitrol.<\/p>\n<p><strong>Hoe dit alles werkt<\/strong><\/p>\n<p>We voeren de opdracht uit <code>helm install<\/code>. We geven de naam van de applicatierelease op, geven het pad naar values.yaml op. Tot slot geven we de repository op waar de chart zich bevindt en de naam van de chart. In dit voorbeeld zijn dat \u00ablmru\u00bb en \u00abbestchart\u00bb respectievelijk.<\/p>\n<pre><code class=\"plaintext\">helm install --name bestapp --values values.yaml lmru\/bestchart\n<\/code><\/pre>\n<p>\nDe opdracht kan slechts \u00e9\u00e9n keer worden uitgevoerd, bij herhaalde uitvoering in plaats van <code>install<\/code> moet <code>upgrade<\/code>. Voor de eenvoud kan in plaats van twee opdrachten de opdracht <code>upgrade<\/code> met een extra sleutel <code>--install<\/code>Bij de eerste uitvoering zal Helm een commando verzenden om de release te installeren, en zal het in de toekomst updates uitvoeren.<\/p>\n<pre><code class=\"plaintext\">helm upgrade --install bestapp --values values.yaml lmru\/bestchart\n<\/code><\/pre>\n<p><\/p>\n<h2>Valstrikken bij het implementeren van nieuwe versies van applicaties met Helm<\/h2>\n<p>\n<i>Op dit punt in het verhaal speel ik met de zaal in 'Wie wil een miljoenair worden', en we ontdekken hoe we Helm kunnen laten upgraden naar de nieuwe versie van de applicatie. <\/i><noindex><a rel=\"nofollow\" href=\"https:\/\/youtu.be\/w1PhTe9gnOI?list=PLQzTaxmOHjnv0tP_HDxsIvcuac2kkIJTQ&amp;t=778\"><i>Bekijk video<\/i><\/a><\/noindex>.<\/p>\n<p>Toen ik de werking van Helm bestudeerde, was ik verrast door het vreemde gedrag bij het proberen om versies van draaiende applicaties te upgraden. De code van de applicatie was bijgewerkt, het nieuwe beeld was naar de Docker Registry ge\u00fcpload, ik verzond de implementatieopdracht \u2013 en er gebeurde niets. Hieronder staan een paar minder succesvolle manieren om applicaties te upgraden. Door elk van hen nader te bestuderen, begin je de interne werking van de tool en de redenen voor dit niet-evidente gedrag te begrijpen.<\/p>\n<p><strong>Methode 1. Geen informatie wijzigen sinds de laatste uitvoering<\/strong><\/p>\n<p>Zoals het zegt <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/intro\/using_helm\/#helm-upgrade-and-helm-rollback-upgrading-a-release-and-recovering-on-failure\">offici\u00eble website<\/a><\/noindex> Helm, \"Kubernetes charts kunnen groot en complex zijn, daarom probeert Helm niet onnodig iets te veranderen.\" Dus, als je de laatste versie van de applicatie image in de Docker Registry bijwerkt en het commando uitvoert <code>helm upgrade<\/code>, zal er niets gebeuren. Helm denkt dat er niets is veranderd en er hoeft geen commando naar Kubernetes gestuurd te worden om de applicatie bij te werken.<\/p>\n<blockquote><p>Hier en verder wordt de tag latest uitsluitend als voorbeeld weergegeven. Bij het opgeven van deze tag zal Kubernetes elke keer de image van de Docker Registry downloaden, ongeacht de imagePullPolicy. Het gebruik van latest in productie is ongewenst en kan bijwerkingen veroorzaken.<\/p><\/blockquote>\n<p>\n<strong>Methode 2. LABEL in de image bijwerken<\/strong><\/p>\n<p>Zoals vermeld in hetzelfde <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/intro\/using_helm\/#helm-upgrade-and-helm-rollback-upgrading-a-release-and-recovering-on-failure\">de documentatie<\/a><\/noindex>, \"Helm zal de applicatie alleen bijwerken als deze is veranderd sinds de laatste release.\" Een logische optie hiervoor zou zijn om het LABEL in de Docker image bij te werken. Echter, Helm kijkt niet naar de applicatie-images en heeft geen idee van eventuele veranderingen daarin. Daarom, bij het bijwerken van labels in de image, zal Helm daar niet van op de hoogte zijn, en zal er geen update-opdracht naar Kubernetes worden verzonden.<\/p>\n<p><strong>Methode 3. Een sleutel gebruiken <code>--force<\/code><\/strong><\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/4888cddfb7698b7044ab31b6f6070063.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nLaten we de handleidingen raadplegen en naar de juiste sleutel zoeken. De sleutel die het beste past bij de context is <code>--force<\/code>. Ondanks de voor de hand liggende naam, wijkt het gedrag af van wat men verwacht. In plaats van een geforceerde update van de applicatie, is de werkelijke functie het herstel van een release die zich in de status FAILED bevindt. Als deze vlag niet wordt gebruikt, moeten de commando's opeenvolgend worden uitgevoerd. <code>helm delete &amp;&amp; helm install --replace<\/code>. In plaats daarvan wordt aanbevolen deze vlag te gebruiken <code>--force<\/code>, die de opeenvolgende uitvoering van deze commando's automatiseert. Meer informatie hierover is te vinden in deze <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\/pull\/3597\">pull request.<\/a><\/noindex>. Om Helm te instrueren de versie van de applicatie daadwerkelijk bij te werken, is deze vlag helaas niet geschikt.<\/p>\n<p><strong>Methode 4. Labels rechtstreeks in Kubernetes wijzigen<\/strong><\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/0a35e7aaa7479685f07dd5b935c95eb1.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nHet direct updaten van een label in de cluster met behulp van het commando <code>kubectl edit<\/code> \u2014 is geen goed idee. Deze actie zal leiden tot inconsistentie in de informatie tussen de actieve applicatie en wat aanvankelijk is verzonden voor de deployment. Het gedrag van Helm tijdens de deployment verschilt in dit geval van zijn versie: Helm 2 zal niets doen, terwijl Helm 3 een nieuwe versie van de applicatie zal deployen. Om de reden hiervoor te begrijpen, moet men weten hoe Helm werkt.<\/p>\n<h3>Hoe Helm werkt<\/h3>\n<p>\nOm te bepalen of de applicatie sinds de laatste release is gewijzigd, kan Helm gebruikmaken van:<\/p>\n<ul>\n<li>de actieve applicatie in Kubernetes;<\/li>\n<li>een nieuwe values.yaml en de actuele chart;<\/li>\n<li>interne informatie van Helm over de releases.<\/li>\n<\/ul>\n<p><b class=\"spoiler_title\">Voor de nieuwsgierigen: waar slaat Helm interne informatie over releases op?<\/b>Door het commando <code>helm history<\/code>, krijgen we alle informatie over de versies die met Helm zijn ge\u00efnstalleerd.<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/0bf3afeb9c4947220474af648a1fa1ad.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nEr is ook gedetailleerde informatie over de verzonden sjablonen en waarden. We kunnen deze opvragen:<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/858560c0f4adf7375060cec339df7574.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nIn de tweede versie van Helm bevindt deze informatie zich in dezelfde namespace waar Tiller draait (standaard \u2014 kube-system), in een ConfigMap gemarkeerd met het label \"OWNER=TILLER\":<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/ba665a079ccddeb4ca7049822c42a498.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nMet de komst van de derde versie van Helm is de informatie verhuisd naar geheimen, en wel naar dezelfde namespace waar de applicatie draait. Dit maakt het mogelijk om meerdere applicaties met dezelfde naam voor een release tegelijk in verschillende namespaces uit te voeren. In de tweede versie was dit een grote hoofdpijn, omdat namespaces ge\u00efsoleerd zijn, maar invloed op elkaar kunnen hebben.<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/b9b82b7c86320a0e3642e4265a1f0241.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>\nIn de tweede Helm, wanneer hij probeert te begrijpen of er een update nodig is, gebruikt hij alleen twee informatiebronnen: wat hem nu is verstrekt, en de interne informatie over de releases die in de ConfigMap is opgeslagen.<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/0550ba5f6ce7be1e7f666dfc65e639ad.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nDe derde Helm gebruikt een driewegsamenvoegstrategie: naast de bestaande informatie houdt hij ook rekening met de applicatie die momenteel draait in Kubernetes.<\/p>\n<p><img decoding=\"async\" alt=\"Helm-apparaat en de valkuilen ervan\" src=\"\/wp-content\/uploads\/2020\/02\/252085adb83e097e01b4a0655706ede5.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nOm deze reden zal de oude versie van Helm niets doen, omdat deze geen informatie over de applicatie in de cluster meeneemt, terwijl Helm 3 de wijzigingen zal ontvangen en de nieuwe applicatie zal implementeren.<\/p>\n<p><strong>Methode 5. Gebruik de sleutel \u2014recreate-pods<\/strong><\/p>\n<p>Met de sleutel <code>--recreate-pods<\/code> kan worden bereikt wat oorspronkelijk met de sleutel bedoeld was. <code>--force<\/code>Containers worden opnieuw gestart en, volgens het beleid imagePullPolicy: Always voor de tag latest (zie de voetnoot hierboven), zal Kubernetes de nieuwe versie van de afbeelding downloaden en starten. Dit zal echter niet op de beste manier gebeuren: zonder rekening te houden met StrategyType van de uitrol, worden alle oude instanties van de applicatie abrupt uitgeschakeld en zullen nieuwe worden gestart. Tijdens de herstart zal het systeem niet functioneren en zullen gebruikers hinder ondervinden.<\/p>\n<p>In Kubernetes bestond een vergelijkbaar probleem ook een lange tijd. En nu, vier jaar na de ontdekking <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/kubernetes\/kubernetes\/issues\/13488\">Probleem<\/a><\/noindex>, is het probleem opgelost en vanaf versie 1.15 van Kubernetes is het mogelijk om een rolling-restart van pods uit te voeren.<\/p>\n<p>Helm schakelt gewoon alle applicaties uit en start nieuwe containers daarnaast. Dit mag niet in productie worden gedaan om downtime van de applicatie te vermijden. Dit moet alleen worden gedaan voor ontwikkelingsdoeleinden en mag alleen in stage-omgevingen worden uitgevoerd.<\/p>\n<h2>Hoe update je de versie van de applicatie met Helm?<\/h2>\n<p>\nWe zullen waarden wijzigen die naar Helm worden verzonden. Dit zijn meestal waarden die vervangen worden voor de tag van de afbeelding. In het geval van latest, dat vaak wordt gebruikt voor onproductieve omgevingen, fungeert de annotatie als wijzigbare informatie, wat nutteloos is voor Kubernetes maar een signaal naar Helm zal zijn dat de applicatie moet worden bijgewerkt. Mogelijke waarden voor de annotatie zijn:<\/p>\n<ol>\n<li><strong>Willekeurige waarde<\/strong> met behulp van de standaardfunctie \u2014 <code>{{ randAlphaNum 6 }}<\/code>. <br \/>\nEr is een nuance: na elke implementatie met behulp van een chart met deze variabele, zal de waarde van de annotatie uniek zijn, en Helm zal aannemen dat er veranderingen zijn. Dit betekent dat we de applicatie altijd opnieuw zullen starten, zelfs als we de versie niet hebben veranderd. Dit is niet kritiek, omdat er geen downtime zal zijn, maar het is toch vervelend.<\/li>\n<li>De huidige <strong>datum en tijd invoegen<\/strong> \u2014 <code>{{ .Release.Date }}<\/code>. <br \/>\nDeze optie is vergelijkbaar met een willekeurige waarde met een constant unieke variabele.<\/li>\n<li>Een juiste manier is om te gebruiken <strong>controleer eenheden<\/strong>. Dit is de SHA van het beeld of de SHA van de laatste commit in git \u2014 <code>{{ .Values.sha }}<\/code>. <br \/>\nDeze moeten worden berekend en naar de Helm-client aan de oproepzijde worden verzonden, bijvoorbeeld in Jenkins. Als de applicatie verandert, verandert de controle-eenheid ook. Dit betekent dat Helm de applicatie alleen zal bijwerken wanneer dat nodig is.<\/li>\n<\/ol>\n<p><\/p>\n<h2>Laten we onze pogingen samenvatten<\/h2>\n<p><\/p>\n<ul>\n<li>Helm brengt veranderingen op de minst ingrijpende manier aan, zodat elke wijziging op het niveau van de applicatie-beeld in de Docker Registry niet leidt tot een update: na het uitvoeren van de opdracht gebeurt er niets.<\/li>\n<li>Sleutel <code>--force<\/code> wordt gebruikt om probleemrelease te herstellen en is niet gerelateerd aan gedwongen updates.<\/li>\n<li>Sleutel <code>--recreate-pods<\/code> dwingt de applicaties bij te werken, maar doet dit op een destructieve manier: het schakelt alle containers abrupt uit. Dit zal de gebruikers schaden; zo moet je niet in productie omgaan.<\/li>\n<li>Wijzigingen rechtstreeks in de Kubernetes-cluster aanbrengen met de opdracht <code>kubectl edit<\/code> is niet nodig: we verstoren de consistentie en het gedrag varieert afhankelijk van de versie van Helm.<\/li>\n<li>Met de uitgave van de nieuwe versie van Helm zijn er veel nuances ontstaan. Problemen in de Helm-repository zijn in begrijpelijke taal beschreven en zullen helpen de details te begrijpen.<\/li>\n<li>Het toevoegen van een wijzigbare annotatie aan de chart maakt deze flexibeler. Hierdoor kan de applicatie correct worden uitgerold zonder downtime.<\/li>\n<\/ul>\n<p>\nEen gedachte uit de categorie 'wereldwijde vrede', die in alle levenssferen werkt: lees de handleiding voor gebruik, niet erna. Alleen met volledige informatie kun je betrouwbare systemen bouwen en gebruikers gelukkig maken.<\/p>\n<p><strong>Andere links over het onderwerp:<\/strong><\/p>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/453734\/\">Introductie tot <i>Helm<\/i> 3<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/\">Offici\u00eble site van Helm<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/helm\/helm\">Helm-repository op GitHub<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/425343\/\">25 nuttige Kubernetes-tools: implementatie en beheer<\/a><\/noindex><\/li>\n<\/ol>\n<p>\nDeze presentatie werd voor het eerst gegeven op <noindex><a rel=\"nofollow\" href=\"https:\/\/corp.mail.ru\/ru\/press\/events\/at-kubernetes-conference\/\">@Kubernetes Conferentie<\/a><\/noindex> door Mail.ru Cloud Solutions. Bekijk <noindex><a rel=\"nofollow\" href=\"https:\/\/www.youtube.com\/playlist?list=PLQzTaxmOHjnv0tP_HDxsIvcuac2kkIJTQ\">video's<\/a><\/noindex> andere presentaties en abonneer je op evenementaankondigingen in Telegram <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/k8s_mail\">Rondom Kubernetes bij Mail.ru Group<\/a><\/noindex>.<br \/>\n<br \/>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/mailru\/blog\/488192\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Typhon freight hauler concept, Anton Swanepoel \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0414\u043c\u0438\u0442\u0440\u0438\u0439 \u0421\u0443\u0433\u0440\u043e\u0431\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u00ab\u041b\u0435\u0440\u0443\u0430 \u041c\u0435\u0440\u043b\u0435\u043d\u00bb. \u0412 \u0441\u0442\u0430\u0442\u044c\u0435 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0443, \u0437\u0430\u0447\u0435\u043c \u043d\u0443\u0436\u0435\u043d Helm, \u043a\u0430\u043a \u043e\u043d \u0443\u043f\u0440\u043e\u0449\u0430\u0435\u0442 \u0440\u0430\u0431\u043e\u0442\u0443 \u0441 Kubernetes, \u0447\u0442\u043e \u043f\u043e\u043c\u0435\u043d\u044f\u043b\u043e\u0441\u044c \u0432 \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u0432\u0435\u0440\u0441\u0438\u0438 \u0438 \u043a\u0430\u043a \u0441 \u0435\u0433\u043e \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u043e\u0431\u043d\u043e\u0432\u043b\u044f\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435 \u0431\u0435\u0437 \u043f\u0440\u043e\u0441\u0442\u043e\u044f. \u042d\u0442\u043e \u043a\u043e\u043d\u0441\u043f\u0435\u043a\u0442 \u043f\u043e \u043c\u043e\u0442\u0438\u0432\u0430\u043c \u0432\u044b\u0441\u0442\u0443\u043f\u043b\u0435\u043d\u0438\u044f \u043d\u0430 \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u0438 @Kubernetes Conference by Mail.ru Cloud [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":70955,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-70954","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ustrojstvo-helm-i-ego-podvodnye-kamni\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0423\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u043e Helm \u0438 \u0435\u0433\u043e \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0435 \u043a\u0430\u043c\u043d\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ustrojstvo-helm-i-ego-podvodnye-kamni\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-22T21:58:17+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-03T13:14:40+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Structuur van Helm en zijn valkuilen | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ustrojstvo-helm-i-ego-podvodnye-kamni","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0423\u0441\u0442\u0440\u043e\u0439\u0441\u0442\u0432\u043e Helm \u0438 \u0435\u0433\u043e \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0435 \u043a\u0430\u043c\u043d\u0438 | ProHoster","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ustrojstvo-helm-i-ego-podvodnye-kamni","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-02-22T21:58:17+00:00","article:modified_time":"2020-03-03T13:14:40+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"70954","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:11:23","updated":"2022-09-30 13:54:53","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/70954","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=70954"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/70954\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/70955"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=70954"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=70954"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=70954"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}