🥇Distribution av applikationer på flera Kubernetes-kluster med Helm

Hur Dailymotion använder Kubernetes: distribution av applikationer

Vi på Dailymotion började använda Kubernetes i produktion för tre år sedan. Men att distribuera applikationer på flera kluster är en utmaning, så under de senaste åren har vi försökt förbättra våra verktyg och arbetsflöden.

Hur det började

Här berättar vi hur vi distribuerar våra applikationer på flera Kubernetes-kluster runt om i världen.

För att distribuera flera Kubernetes-objekt samtidigt använder vi Helm, och alla våra chartar lagras i ett enda git-repositorium. För att distribuera en fullständig applikationsstack bestående av flera tjänster, använder vi en så kallad övergripande chart. I grund och botten är det en chart som deklarerar beroenden och gör det möjligt att initiera API:er och deras tjänster med ett enda kommando.

Vi har också skrivit ett litet Python-skript ovanpå Helm för att göra kontroller, skapa chartar, lägga till hemligheter och distribuera applikationer. Alla dessa uppgifter utförs på en central CI-plattform med hjälp av en docker-image.

Låt oss gå till kärnan.

Obs. När du läser detta har den första releasekandidaten för Helm 3 redan tillkännagivits. Huvudversionen innehåller en hel uppsättning förbättringar som syftar till att lösa vissa problem vi har stött på tidigare.

Utvecklingsarbetsflöde för chartar

För applikationer använder vi grenar, och vi bestämde oss för att tillämpa denna metod även på chartarna.

Grenen dev används för att skapa chartar som kommer att testas på utvecklingskluster.
När en pull-begäran överförs till master, de testas i staging.
Slutligen skapar vi en pull-begäran för att överföra ändringar till grenen prod och tillämpa dem i produktion.

Varje miljö har sitt eget privata repositorium som lagrar våra chartar, och vi använder Chartmuseum med mycket användbara API:er. På så sätt säkerställer vi strikt isolering mellan miljöerna och testning av chartarna under verkliga förhållanden innan vi använder dem i produktion.

Repositorier för chartar i olika miljöer

Det är värt att notera att när utvecklare skickar en dev-gren, skickas versionen av deras chart automatiskt till dev Chartmuseum. Således använder alla utvecklare ett gemensamt dev-repositorium, och det är viktigt att noggrant ange sin chart-version för att inte av misstag använda någon annans ändringar.

Dessutom kontrollerar vårt lilla Python-skript Kubernetes-objekt mot specifikationerna för Kubernetes OpenAPI med hjälp av Kubeval, innan de publiceras i Chartmuseum.

Översikt över arbetsflödet för chartutveckling

Inställning av pipeline-uppgifter enligt specifikationen gazr.io för kvalitetskontroll (lint, enhetstest).
Skicka dockerbilden med Python-verktyg som distribuerar våra applikationer.
Konfigurera miljön efter grenens namn.
Kontrollera Kubernetes yaml-filer med hjälp av Kubeval.
Automatisk ökning av versionen på chartet och dess föräldrarchart (de chart som beror på det ändrade chartet).
Skicka chartet till Chartmuseum som motsvarar dess miljö

Hantera skillnader mellan kluster

Federering av kluster

Det var en tid när vi använde federering av Kubernetes-kluster, där man kunde deklarera Kubernetes-objekt från en API-slutpunkt. Men det uppstod problem. Till exempel kunde vissa Kubernetes-objekt inte skapas vid federationsslutpunkten, vilket gjorde det svårt att underhålla sammanställda objekt och andra objekt för individuella kluster.

För att lösa problemet började vi hantera kluster oberoende, vilket avsevärt förenklade processen (vi använde den första versionen av federation; i den andra kunde något ha ändrats).

Geodistribuerad plattform

Nu är vår plattform distribuerad över 6 regioner — 3 lokalt och 3 i molnet.

Distribuerad distribution

Globala värden för Helm

4 globala värden för Helm gör det möjligt att definiera skillnader mellan kluster. För alla våra chart finns det minimivärden som standard.

global:
  cloud: True
  env: staging
  region: us-central1
  clusterName: staging-us-central1

Globala värden

Dessa värden hjälper till att definiera kontexten för våra applikationer och används för olika uppgifter: övervakning, spårning, loggning, externa anrop, automatisering och så vidare.

"cloud": vi har en hybrid Kubernetes-plattform. Till exempel distribueras vårt API i GCP-zoner och i våra datacenter.
"env": vissa värden kan variera för icke-produktionsmiljöer. Till exempel resursdefinitioner och konfigurationer för automatisk skalning.
"region": denna information hjälper till att definiera klustrets läge och kan användas för att fastställa närmaste slutpunkter för externa tjänster.
"clusterName": om och när vi vill definiera ett värde för ett enskilt kluster.

Här är ett konkret exempel:

{{
/* Returnerar Horizontal Pod Autoscaler-replikat för GraphQL*/}}
{{- definiera "graphql.hpaReplicas" -}}
{{- om eq .Values.global.env "prod" }}
{{- om eq .Values.global.region "europe-west1" }}
minReplicas: 40
{{- annars }}
minReplicas: 150
{{- slut }}
maxReplicas: 1400
{{- annars }}
minReplicas: 4
maxReplicas: 20
{{- slut }}
{{- slut -}}

Exempel på en Helm-mall

Denna logik definieras i en hjälpmall för att inte överbelasta Kubernetes YAML.

Applikationsdeklaration

Våra distributionsverktyg baseras på flera YAML-filer. Nedan är ett exempel på hur vi deklarerar en tjänst och dess skalningstopologi (antal replikat) i klustret.

releases:
  - foo.world

foo.world:                # Namn på releasen
  services:               # Lista över dailymotion's appar/projekt
    foobar:
      chart_name: foo-foobar
      repo: git@github.com:dailymotion/foobar
      contexts:
        prod-europe-west1:
          deployments:
            - name: foo-bar-baz
              replicas: 18
            - name: another-deployment
              replicas: 3

Tjänstedeklaration

Detta är en översikt av alla steg som definierar vår distributionsarbetsflöde. Det sista steget distribuerar applikationen samtidigt i flera arbetskluster.

Distributionssteg i Jenkins

Och hemligheterna?

Vad gäller säkerhet så följer vi alla hemligheter från olika platser och lagrar dem i ett unikt förråd Vault i Paris.

Våra distributionsverktyg hämtar hemligheternas värden från Vault och, när det är dags för distribution, infogar dem i Helm.

För detta har vi definierat en mappning mellan hemligheterna i Vault och de hemligheter som våra applikationer behöver:

hemligheter:                                                                                                                                                                                                        
     - secret_id: "stack1-app1-password"                                                                                                                                                                                  
       kontexter:                                                                                                                                                                                                   
         - namn: "default"                                                                                                                                                                                         
           vaultPath: "\/kv\/dev\/stack1\/app1\/test"                                                                                                                                                               
           vaultKey: "password"                                                                                                                                                                                    
         - namn: "cluster1"                                                                                                                                                                           
           vaultPath: "\/kv\/dev\/stack1\/app1\/test"                                                                                                                                                               
           vaultKey: "password"

Vi har fastställt allmänna regler som måste följas vid inspelning av hemligheter i Vault.
Om hemligheten hör till en viss kontext eller kluster, måste en specifik post läggas till. (Här har kontexten cluster1 sitt eget värde för hemligheten stack-app1-password).
Annars används värdet standard.
För varje punkt i denna lista i Kubernetes-hemligheten infogas ett nyckel-värde-par. Därför är mallen för hemligheten i våra diagram mycket enkel.

apiVersion: v1
data:
{{- range $key,$value := .Values.secrets }}
  {{ $key }}: {{ $value | b64enc | quote }}
{{ end }}
kind: Secret
metadata:
  name: "{{ .Chart.Name }}"
  labels:
    chartVersion: "{{ .Chart.Version }}"
    tillerVersion: "{{ .Capabilities.TillerVersion.SemVer }}"
typ: Opaque

Problem och begränsningar

Arbeta med flera lager

Just nu delar vi utvecklingen av diagram och applikationer. Det innebär att utvecklarna måste arbeta i två git-repositorier: ett för applikationen och ett annat för att definiera dess distribution i Kubernetes. 2 git-repositorier innebär 2 arbetsflöden, och det är lätt för en nybörjare att bli förvirrad.

Att hantera generiska diagram är besvärligt

Som redan nämnts är generiska diagram mycket användbara för att definiera beroenden och snabbt distribuera flera applikationer. Men vi använder --reuse-values, för att undvika att skicka vidare alla värden varje gång vi distribuerar en applikation som ingår i det generiska diagrammet.

I den kontinuerliga leveransprocessen har vi bara två värden som ändras regelbundet: antalet repliker och bildtaggen (version). Andra, mer stabila värden ändras manuellt, vilket är ganska svårt. Dessutom kan ett enda fel i distributionen av en generell chart leda till allvarliga fel, som vi har sett av egen erfarenhet.

Uppdatering av flera konfigurationsfiler

När en utvecklare lägger till en ny applikation måste han ändra flera filer: applikationsdeklarationen, listan över hemligheter och lägga till applikationen i beroendena om den ingår i den generella charten.

Jenkins-behörigheter är för omfattande i Vault

Nu har vi en AppRole, som läser alla hemligheter från Vault.

Rollback-processen är inte automatiserad

För rollback måste man köra kommandot på flera kluster, vilket kan leda till fel. Vi utför denna operation manuellt för att säkerställa att rätt versionsidentifierare anges.

Vi rör oss mot GitOps

Vårt mål

Vi vill föra tillbaka charten till applikationsrepositoryt som den distribuerar.

Arbetsflödet kommer att vara detsamma som för utveckling. Till exempel, när en gren skickas till master, kommer distributionen att starta automatiskt. Den huvudsakliga skillnaden mellan detta tillvägagångssätt och det nuvarande arbetsflödet är att allt kommer att hanteras i git (själva applikationen och hur den distribueras i Kubernetes).

Det finns flera fördelar:

Mycket mer begripligt för utvecklaren. Det är enklare att lära sig tillämpa ändringar i den lokala charten.
Definitionen av distributionen av tjänsten kan anges där där koden för tjänsten.
Hantering av borttagning av generella charts. Tjänsten kommer att ha sin egen Helm-release. Detta kommer att möjliggöra hantering av applikationens livscykel (rollback, uppgradering) på den minsta nivån, så att andra tjänster inte påverkas.
Fördelar med git för hantering av charts: ändringsåterkallelse, revisionslogg osv. Om en ändring av charten måste återkallas kan detta göras med hjälp av git. Distributionen startar automatiskt.
Man kan överväga att förbättra utvecklingsarbetsflödet med hjälp av sådana verktyg som Skaffold, där utvecklare kan testa ändringar i en kontext som liknar produktionsmiljön.

Tvåstegs migrering

Våra utvecklare har använt denna arbetsprocess i 2 år, så vi behöver en så smidig migrering som möjligt. Därför beslutade vi att lägga till ett mellanliggande steg på vägen mot målet.
Det första steget är enkelt:

Vi behåller en liknande struktur för att konfigurera distributionen av applikationer, men i ett objekt med namnet DailymotionRelease.

apiVersion: "v1"
kind: "DailymotionRelease"
metadata:
  name: "app1.ns1"
  environment: "dev"
  branch: "mybranch"
spec:
  slack_channel: "#admin"
  chart_name: "app1"
  scaling:
    - context: "dev-us-central1-0"
      replicas:
        - name: "hermes"
          count: 2
    - context: "dev-europe-west1-0"
      replicas:
        - name: "app1-deploy"
          count: 2
  secrets:
    - secret_id: "app1"
      contexts:
        - name: "default"
          vaultPath: "\/kv\/dev\/ns1\/app1\/test"
          vaultKey: "password"
        - name: "dev-europe-west1-0"
          vaultPath: "\/kv\/dev\/ns1\/app1\/test"
          vaultKey: "password"

1 release per applikation (utan allmänna diagram).
Diagram i applikations Git-förvaret.

Vi har pratat med alla utvecklare, så migrationsprocessen har redan påbörjats. Det första steget kontrolleras fortfarande med hjälp av CI-plattformen. Snart kommer jag att skriva ett inlägg om det andra steget: hur vi gick över till arbetsprocessen GitOps med Flux. Jag kommer att berätta hur vi konfigurerade allt och vilka svårigheter vi stötte på (flera förvar, hemligheter osv.). Håll dig uppdaterad.

Här har vi försökt beskriva våra framsteg inom distributionsprocessen av applikationer de senaste åren, vilket har lett till tankar om GitOps-ansatsen. Vi har ännu inte nått målet och kommer att rapportera om resultaten, men vi är nu övertygade om att vi gjorde rätt när vi beslutade att förenkla allt och anpassa det till utvecklarnas vanor.

Källa: habr.com