🥇Helms struktur och fallgropar

Typhon frakttransportkoncept, Anton Swanepoel

Jag heter Dmitrij Sugrobov, jag är utvecklare på "Leroy Merlin". I artikeln kommer jag att berätta varför Helm behövs, hur det förenklar arbetet med Kubernetes, vad som har förändrats i den tredje versionen och hur man uppdaterar applikationer i produktion utan driftstopp.

Detta är en sammanfattning baserad på en presentation på konferensen @Kubernetes Conference by Mail.ru Cloud Solutions — om du inte vill läsa, titta på videon.

Varför vi använder Kubernetes i produktion

"Leroy Merlin" är en ledare på DIY-retailmarknaden i Ryssland och Europa. I vårt företag arbetar över hundra utvecklare, 33 000 interna anställda och ett stort antal människor besöker våra varuhus och webbplats. För att göra alla glada beslutade vi att följa standardmetoder inom branschen. Vi utvecklar nya applikationer med mikrotjänstarkitektur; för att isolera miljöer och säkerställa korrekt leverans använder vi containrar; och för orkestrering använder vi Kubernetes. Kostnaden för att använda orkestratorer blir snabbt billigare: antalet ingenjörer som behärskar tekniken ökar på marknaden och leverantörer erbjuder Kubernetes som en tjänst.

Allt som Kubernetes gör kan självklart göras på andra sätt, till exempel genom att kladda med skript i någon Jenkins och docker-compose, men varför komplicera livet när det finns en färdig och pålitlig lösning? Därför har vi valt Kubernetes och har använt det i produktion i ett år nu. Nu har vi tjugofyra Kubernetes-kluster, det äldsta av dem är över ett år gammalt och har cirka tvåhundra pods.

Förbannelsen med ett stort antal YAML-filer i Kubernetes

För att starta en mikrotjänst i Kubernetes kommer vi att skapa minst fem YAML-filer: för Deployment, Service, Ingress, ConfigMap, Secrets — och skicka dem till klustret. För nästa applikation skriver vi samma uppsättning YAML-filer, med den tredje — ytterligare en och så vidare. Multiplicera antalet dokument med antalet miljöer, så får vi hundratals filer, och detta tar inte ens hänsyn till dynamiska miljöer.

Adam Reese, huvudansvarig för Helm, introducerade begreppet "Utvecklingscykeln i Kubernetes" som ser ut så här:

Kopiera YAML — kopiera YAML-filen.
Klistra in YAML — klistra in den.
Fixera indrag — fixa indragen.
Upprepa — upprepa igen.

Detta alternativ fungerar, men man måste ofta kopiera YAML-filer flera gånger. För att förändra denna cykel uppfanns Helm.

Vad är Helm

Först och främst är Helm — paketchef, som hjälper till att hitta och installera nödvändiga program. För att installera till exempel MongoDB måste man inte gå till den officiella webbplatsen och ladda ner binärfiler, det räcker att köra kommandot helm install stable/mongodb.

För det andra, Helm — en mallmotor, hjälper till att parametrera filer. Låt oss återgå till situationen med YAML-filer i Kubernetes. Det är enklare att skriva samma YAML-fil, lägga till några platshållare, där Helm sätter in värden. Det betyder att istället för en stor uppsättning YAML-filer kommer det att finnas en uppsättning mallar, där de nödvändiga värdena kommer att sättas in vid rätt tidpunkt.

För det tredje, Helm — mästare vid distribution. Med hjälp av det kan man installera, återställa och uppdatera applikationer. Låt oss gå igenom hur man gör detta.

Hur man använder Helm för att distribuera sina egna applikationer

Vi installerar Helm-klienten på datorn, enligt den officiella instruktionerna. Sedan skapar vi en uppsättning YAML-filer. Istället för att ange specifika värden lämnar vi platshållare som Helm senare kommer att fylla med information. En uppsättning sådana filer kallas för en Helm-diagram. Den kan skickas till Helm-konsolklienten på tre sätt:

ange mappen med mallar;
paketera den i en .tar-arkiv och ange den;
placera mallen i ett fjärrrepo och lägga till en länk till repositoriet i Helm-klienten.

Även en fil med värden behövs — values.yaml. Data därifrån kommer att sättas in i mallen. Låt oss skapa den också.

I den andra versionen av Helm finns det en tilläggstjänst — Tiller. Den finns utanför Kubernetes och väntar på förfrågningar från Helm-klienten, och när den anropas sätter den in nödvändiga värden i mallen och skickar dem till Kubernetes.

Helm 3 är enklare: istället för att bearbeta mallarna på servern, behandlas informationen nu helt och hållet på sidan av Helm-klienten och skickas direkt till Kubernetes API. Denna förenkling förbättrar säkerheten för klustret och förenklar distributionsschemat.

Hur detta fungerar

Kör kommandot helm install. Ange namnet på applikationens release, ge sökvägen till values.yaml. I slutet anger vi repo där diagrammet ligger och namnet på diagrammet. I exemplet är detta «lmru» och «bestchart» respektive.

helm install --name bestapp --values values.yaml lmru/bestchart

Utförandet av kommandot är möjligt endast en gång, vid upprepning av kommandot istället för install måste du använda upgrade. För enkelhetens skull kan man istället för två kommandon köra kommandot upgrade med en extra nyckel --install. Vid första körningen skickar Helm en kommando för att installera releasen, och kommer att uppdatera den i framtiden.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

Fallgropar vid deployment av nya versioner av applikationen med Helm

Vid den här punkt i berättelsen spelar jag med publiken i "Vem vill bli miljonär?", och vi tar reda på hur man får Helm att uppdatera applikationens version. Se videon.

När jag studerade hur Helm fungerar, blev jag förvånad över det märkliga beteendet vid försök att uppdatera versioner av körda applikationer. Applikationens kod uppdaterades, en ny bild laddades upp i Docker-registret, jag skickade ett kommando för deployment – och ingenting hände. Här är några inte helt lyckade sätt att uppdatera applikationer. Genom att studera varje metod mer ingående börjar man förstå verktygets inre funktion och orsakerna till detta inte så uppenbara beteende.

Metod 1. Ändra inte informationen sedan senaste körningen

Som det står den officiella webbplatsen Helm, "Kubernetes charts kan vara stora och komplexa, så Helm försöker helst att inte röra saker för mycket". Därför, om man uppdaterar latest-versionen av applikationens bild i Docker-registret och utför kommandot helm upgrade, så kommer ingenting att hända. Helm kommer att tro att ingenting har förändrats och behöver ingen kommando för att uppdatera applikationen i Kubernetes.

Här och framåt visas taggen latest endast som ett exempel. Vid angivande av denna tagg kommer Kubernetes att ladda ner bilden från Docker-registret varje gång, oavsett imagePullPolicy. Användning av latest i produktion är inte rekommenderat och ger biverkningar.

Metod 2. Uppdatera LABEL i bilden

Som det står i samma dokumentationen, "Helm kommer att uppdatera applikationen endast om den har förändrats sedan senaste releasen". En logisk åtgärd för detta skulle vara att uppdatera LABEL-taggen i själva Docker-bilden. Men Helm kollar inte i applikationernas bilder och har ingen aning om några förändringar i dem. Därför, vid uppdatering av etiketter i bilden, får Helm inte veta om dem och kommandot för att uppdatera applikationen i Kubernetes kommer inte att skickas.

Metod 3. Använd nyckeln --force

Låt oss kolla manualerna och leta efter rätt nyckel. Den nyckel som passar bäst i betydelse --force. Trots det talande namnet, skiljer sig beteendet från förväntningarna. Istället för att tvinga fram en uppdatering av appen, är dess verkliga syfte att återställa en release som är i status FAILED. Om denna flagga inte används, måste kommandona utföras sekventiellt. helm delete && helm install --replace. Istället föreslås det att använda flaggan --force, som automatiserar sekventiell körning av dessa kommandon. Mer information finns i denna pull request.. För att få Helm att faktiskt uppdatera appversionen, kommer tyvärr denna flagga inte att fungera.

Metod 4. Ändra labels direkt i Kubernetes.

Uppdatering av label direkt i klustret med kommandot kubectl edit. — är en dålig idé. Denna åtgärd kommer att leda till inkonsekvens i informationen mellan den körande appen och vad som ursprungligen skickades för distribution. Helm's beteende vid distribution i detta fall skiljer sig från dess version: Helm 2 kommer inte att göra något, medan Helm 3 kommer att distribuera en ny version av appen. För att förstå orsaken, behöver man förstå hur Helm fungerar.

Hur Helm fungerar.

För att avgöra om appen har ändrats sedan den senaste releasen, kan Helm använda sig av:

den körande appen i Kubernetes;
en ny values.yaml och aktuell chart;
intern information om releases från Helm.

För de mest nyfikna: var lagrar Helm intern information om releases?Genom att köra kommandot helm history,får vi all information om versioner installerade med hjälp av Helm.

Det finns också detaljerad information om de skickade mallarna och värdena. Vi kan begära det:

I den andra versionen av Helm ligger denna information i samma namespace där Tiller kör, vilket som standard är kube-system, i en ConfigMap märkt med labeln "OWNER=TILLER":

Vid övergången till den tredje versionen av Helm flyttades informationen till hemligheter, i samma namespace där appen körs. Detta gjorde det möjligt att köra flera appar samtidigt i olika namespaces med samma release-namn. I den andra versionen var detta en stor huvudvärk, eftersom namespaces var isolerade men kunde påverka varandra.

Andra Helm, när den försöker förstå om en uppdatering behövs, använder endast två informationskällor: det som gavs nu och den interna informationen om releases, som ligger i ConfigMap.

Den tredje Helm använder en trevägsfusionsstrategi: utöver den information som beaktas, tar den också hänsyn till applikationen som körs just nu i Kubernetes.

Av denna anledning kommer den gamla versionen av Helm inte att göra något, eftersom den inte beaktar informationen från applikationen i klustret, medan Helm 3 kommer att ta emot ändringar och skicka en ny applikation för distribution.

Metod 5. Använda nyckeln —recreate-pods

Med hjälp av nyckeln --recreate-pods kan man uppnå det som ursprungligen var tänkt att uppnås med nyckeln --force. Kontainrarna kommer att startas om och, enligt policyn imagePullPolicy: Always för taggen latest (angivet ovan), kommer Kubernetes att ladda ner och starta den nya versionen av bilden. Det kommer att göras på ett mindre optimalt sätt: utan att ta hänsyn till StrategyType för distributionen, kommer alla gamla instanser av applikationen plötsligt att stängas av och nya sättas igång. Under omstarten kommer systemet att vara nere, vilket innebär att användarna kommer att drabbas.

I Kubernetes har ett liknande problem också funnits under en lång tid. Och nu, fyra år efter att det öppnades Issue, har problemet åtgärdats, och från och med version 1.15 av Kubernetes finns det möjlighet till rolling-restart av pods.

Helm stänger helt enkelt av alla applikationer och startar nya containrar bredvid dem. Så här får man inte göra i produktion för att undvika driftstopp av applikationen. Detta behövs endast för utvecklingssyften och kan endast utföras i stage-miljöer.

Hur uppdaterar man en applikationsversion med hjälp av Helm?

Vi kommer att ändra de värden som skickas till Helm. Som regel är detta värden som ersätter taggen för bilden. I fallet med latest, som ofta används för icke-produktiva miljöer, fungerar en annotation som den föränderliga informationen, vilken är värdelös för Kubernetes men signalerar till Helm att applikationen behöver uppdateras. Alternativ för att fylla i värdet på annoteringen:

Slumptal med hjälp av standardfunktionen — {{ randAlphaNum 6 }}.
Det finns en detalj: efter varje distribution med en chart med en sådan variabel, kommer värdet av annoteringen att vara unikt, och Helm kommer att tro att det finns ändringar. Det gör att vi alltid kommer att starta om applikationen, även om vi inte har ändrat dess version. Det är inte kritiskt, eftersom det inte kommer att bli något driftstopp, men det är ändå obehagligt.
Infoga nuvarande datum och tid — {{ .Release.Date }}.
Alternativet liknar slumptalet med en ständigt unik variabel.
Ett mer korrekt sätt är att använda kontrollsummor. Det är SHA av bilden eller SHA av den senaste commit i git — {{ .Values.sha }}.
Dessa måste beräknas och skickas till Helm-klienten på anropande sida, till exempel i Jenkins. Om applikationen har ändrats, så ändras även kontrollsumman. Därför kommer Helm att uppdatera applikationen endast när det behövs.

Sammanfatta våra försök

Helm gör ändringar på det minst invasiva sättet, så varje ändring på nivå av applikationsbild i Docker Registry kommer inte att leda till en uppdatering: efter att kommandot har körts kommer ingenting att hända.
Nyckeln --force används för att återställa problematiska releaser och har ingen koppling till tvingad uppdatering.
Nyckeln --recreate-pods tvingar uppdateringar av applikationer, men gör det på ett grymt sätt: det stänger abrupt av alla containrar. Användarna kommer att drabbas, så detta bör undvikas i produktion.
Direkt göra förändringar i Kubernetes-klustret med kommandot kubectl edit. bör inte göras: vi skulle störa konsistensen, och beteendet kommer att variera beroende på versionen av Helm.
Med den nya versionen av Helm har det dykt upp många nyanser. Issues i Helm-förvaret är beskrivna på ett begripligt språk, de kommer att hjälpa till att förstå detaljerna.
Att lägga till en ändringsbar annotation i chartet gör det mer flexibelt. Detta gör att applikationen kan rullas ut korrekt utan driftstopp.

En tanke från kategorin "fred i hela världen", som fungerar i alla livets sfärer: läs instruktionen före användning, inte efter. Endast med fullständig information kan man bygga pålitliga system och göra användarna nöjda.

Andra länkar i temat:

Denna presentation hördes först på @Kubernetes Conference av Mail.ru Cloud Solutions. Se video andra föreläsningar och följ anmälningarna till evenemang på Telegram Runt Kubernetes i Mail.ru Group.

Källa: habr.com