Organisering av deployment i flera k8s-miljöer med hjälp av helmfile

Helmfile — en wrapper för helm, som gör det möjligt att beskriva flera helm-releaser på ett ställe, parametrera deras diagram för flera miljöer samt ange ordningen för deras distribution.

Man kan läsa om helmfile och exempel på dess användning i readme och best practices guide.

Vi kommer att bekanta oss med icke-uppenbara sätt att beskriva releaser i helmfile.

Anta att vi har en grupp helm-diagram (till exempel postgres och en viss backend-applikation) och flera miljöer (flera kubernetes-kluster, flera namespace, eller både och). Vi tar helmfile, läser dokumentationen och börjar beskriva våra miljöer och releaser:

    .
    ├── envs
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    └── helmfile.yaml

helmfile.yaml

environments:
  devel:
  production:

releases:
  - name: postgres
    labels:
      app: postgres
    wait: true
    chart: stable/postgresql
    version: 8.4.0
    values:
      - envs/{{ .Environment.Name }}/values/postgres.yaml
  - name: backend
    labels:
      app: backend
    wait: true
    chart: private-helm-repo/backend
    version: 1.0.5
    needs:
      - postgres
    values:
      - envs/{{ .Environment.Name }}/values/backend.yaml

Vi har fått 2 miljöer: devel, production — i varje finns sina egna värden för helm-diagram av releaser. Vi kommer att distribuera i dem så här:

helmfile -n  -e  apply

Olika versioner av helm-diagram i olika miljöer.

Vad gör vi om vi behöver rulla ut olika versioner av backend i olika miljöer? Hur parametriserar vi versionen av releasen? Här kommer värden från miljön till hjälp, som är tillgängliga genom {{ .Values }}

helmfile.yaml

environments:
  devel:
+   values:
+   - charts:
+       versions:
+         backend: 1.1.0
  production:
+   values:
+   - charts:
+       versions:
+         backend: 1.0.5
...
  - name: backend
    labels:
      app: backend
    wait: true
    chart: private-helm-repo/backend
-   version: 1.0.5
+   version: {{ .Values.charts.versions.backend }}
...

Olika uppsättningar av applikationer i olika miljöer.

Bra, men vad händer om vi inte behöver rulla ut postgres, eftersom vi vet att vi inte ska ha en databas i k8s och för produktion har vi ett utmärkt separat postgres-kluster? För att lösa detta problem har vi etiketter (labels). production helmfile -n -e devel apply helmfile -n -e production -l app=backend apply

helmfile -n  -e devel apply
helmfile -n  -e production -l app=backend apply

Det är bra, men personligen skulle jag föredra att beskriva vilka applikationer som ska dras upp i miljön, inte med hjälp av startargument, utan i beskrivningen av själva miljöerna. Vad ska man göra? Man kan placera releasebeskrivningarna i en separat mapp, i miljöbeskrivningen skapa en lista över nödvändiga releaser och "koppla" bara de relevanta releaserna genom att ignorera de andra.

    .
    ├── envs
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
+   ├── releases
+   │   ├── backend.yaml
+   │   └── postgres.yaml
    └── helmfile.yaml

helmfile.yaml

  environments:
    devel:
      values:
      - charts:
          versions:
            backend: 1.1.0
      - apps:
        - postgres
        - backend

    production:
      values:
      - charts:
          versions:
            backend: 1.0.5
      - apps:
        - backend

- releases:
-    - name: postgres
-      labels:
-        app: postgres
-      wait: true
-      chart: stable/postgresql
-      version: 8.4.0
-      values:
-        - envs/{{ .Environment.Name }}/values/postgres.yaml
-    - name: backend
-      labels:
-        app: backend
-      wait: true
-      chart: private-helm-repo/backend
-     version: {{ .Values.charts.versions.backend }}
-     needs:
-       - postgres
-     values:
-       - envs/{{ .Environment.Name }}/values/backend.yaml
+ ---
+ bases:
+ {{- range .Values.apps }}
+   - releases/{{ . }}.yaml
+ {{- end }}

releases/postgres.yaml

releases:
  - name: postgres
    labels:
      app: postgres
    wait: true
    chart: stable/postgresql
    version: 8.4.0
    values:
      - envs/{{ .Environment.Name }}/values/postgres.yaml

releases/backend.yaml

releases:
  - name: backend
    labels:
      app: backend
    wait: true
    chart: private-helm-repo/backend
    version: {{ .Values.charts.versions.backend }}
    needs:
      - postgres
    values:
      - envs/{{ .Environment.Name }}/values/backend.yaml

Anteckning

När du använder bases: det är nödvändigt att använda yaml-separatorn ---, så att man kan mallifiera releases (och andra delar, som helmDefaults) med värden från environments

I så fall kommer release postgres inte ens att ingå i beskrivningen för produktion. Mycket praktiskt!

Överskrivbara globala värden för releaser

Självklart är det bra att man kan ställa in värden för helm-charts för varje miljö, men vad händer om vi har beskrivningar för flera miljöer och vi vill, till exempel, sätta samma värde för alla affinity, men inte vill konfigurera det som standard i själva chartsen som förvaras i repos.

I så fall skulle vi kunna ställa in två filer med values för varje release: en med standardvärden som definierar värdena för själva chartet, och den andra med värden för miljön, som i sin tur kommer att åsidosätta standardvärdena.

    .
    ├── envs
+   │   ├── default
+   │   │   └── values
+   │   │       ├── backend.yaml
+   │   │       └── postgres.yaml
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    ├── releases
    │   ├── backend.yaml
    │   └── postgres.yaml
    └── helmfile.yaml

releases/backend.yaml

releases:
  - name: backend
    labels:
      app: backend
    wait: true
    chart: private-helm-repo/backend
    version: {{ .Values.charts.versions.backend }}
    needs:
      - postgres
    values:
+     - envs/default/values/backend.yaml
      - envs/{{ .Environment.Name }}/values/backend.yaml

envs/default/values/backend.yaml

affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 1
      podAffinityTerm:
        labelSelector:
          matchExpressions:
          - key: app.kubernetes.io/name
            operator: In
            values:
            - backend
        topologyKey: "kubernetes.io/hostname"

Definition av globala värden för helm-diagram för alla versioner på miljönivå

Anta att vi har flera ingångar i flera versioner - vi skulle kunna definiera dem manuellt för varje diagram hosts:, men i vårt fall är domänen densamma, så varför inte extrahera den till en global variabel och bara sätta in dess värde i diagrammen? För detta måste de värdefiler vi vill parametriseras ha tillägget .gotmpl, så att helmfile vet att den ska köra den genom mallmotorn.

    .
    ├── envs
    │   ├── default
    │   │   └── values
-   │   │       ├── backend.yaml
-   │   │       ├── postgres.yaml
+   │   │       ├── backend.yaml.gotmpl
+   │   │       └── postgres.yaml.gotmpl
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    ├── releases
    │   ├── backend.yaml
    │   └── postgres.yaml
    └── helmfile.yaml

helmfile.yaml

  environments:
    devel:
      values:
      - charts:
          versions:
            backend: 1.1.0
      - apps:
        - postgres
        - backend
+     - global:
+         ingressDomain: k8s.devel.domain

    production:
      values:
      - charts:
          versions:
            backend: 1.0.5
      - apps:
        - backend
+     - global:
+         ingressDomain: production.domain
  ---
  bases:
  {{- range .Values.apps }}
    - releases/{{ . }}.yaml
  {{- end }}

envs/default/values/backend.yaml.gotmpl

ingress:
  enabled: true
  paths:
    - /api
  hosts:
    - {{ .Values.global.ingressDomain }}

envs/default/values/postgres.yaml.gotmpl

ingress:
  enabled: true
  paths:
    - /
  hosts:
    - postgres.{{ .Values.global.ingressDomain }}

Anteckning

Det är uppenbart att ingress i Postgres-diagrammet är något mycket tvivelaktigt, så det tas med i artikeln bara som ett sfäriskt exempel i vakuum, för att undvika att introducera en ny release bara för att beskriva ingress.

Insättning av hemligheter (secrets) från miljövariabler.

På liknande sätt som ovan kan man också införa krypterade med hjälp av helm secrets värden. Istället för att skapa en egen fil för varje release där man definierar krypterade värden för diagrammet, kan vi helt enkelt definiera värden i den release-specifika default.yaml.gotmpl som hämtas från variabler som anges på miljönivå. Värden som vi inte behöver dölja för någon kan redan överstyra i release-värdena för specifik miljö.

    .
    ├── envs
    │   ├── default
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   ├── devel
    │   │   ├── values
    │   │   │   ├── backend.yaml
    │   │   │   └── postgres.yaml
+   │   │   └── secrets.yaml
    │   └── production
    │       ├── values
    │       │   ├── backend.yaml
    │       │   └── postgres.yaml
+   │       └── secrets.yaml
    ├── releases
    │   ├── backend.yaml
    │   └── postgres.yaml
    └── helmfile.yaml

helmfile.yaml

  environments:
    devel:
      values:
      - charts:
          versions:
            backend: 1.1.0
      - apps:
        - postgres
        - backend
      - global:
          ingressDomain: k8s.devel.domain
+     secrets:
+       - envs/devel/secrets.yaml

    production:
      values:
      - charts:
          versions:
            backend: 1.0.5
      - apps:
        - backend
      - global:
          ingressDomain: production.domain
+     secrets:
+       - envs/production/secrets.yaml
  ---
  bases:
  {{- range .Values.apps }}
    - releases/{{ . }}.yaml
  {{- end }}

envs/devel/secrets.yaml

secrets:
    elastic:
        password: ENC[AES256_GCM,data:hjCB,iv:Z1P6/6xBJgJoKLJ0UUVfqZ80o4L84jvZfM+uH9gBelc=,tag:dGqQlCZnLdRAGoJSj63rBQ==,type:int]
...

envs/production/secrets.yaml

secrets:
    elastic:
        password: ENC[AES256_GCM,data:ZB/VpTFk8f0=,iv:EA//oT1Cb5wNFigTDOz3nA80qD9UwTjK5cpUwLnEXjs=,tag:hMdIUaqLRA8zuFBd82bz6A==,type:str]
...

envs/default/values/backend.yaml.gotmpl

elasticsearch:
  host: elasticsearch
  port: 9200
  password: {{ .Values | getOrNil "secrets.elastic.password" | default "password" }}

envs/devel/values/backend.yaml

elasticsearch:
  host: elastic-0.devel.domain

envs/production/values/backend.yaml

elasticsearch:
  host: elastic-0.production.domain

Anteckning

Förresten, getOrNil — en särskild funktion för Go-mallar i helmfile, som, även om .Values.secrets inte finns, inte genererar ett fel, utan tillåter att använda funktionen default för att införa ett standardvärde.

Slutsats

De beskrivna sakerna verkar ganska uppenbara, men information om att enkelt beskriva deployment i flera miljöer med hjälp av helmfile är mycket begränsad, och jag älskar IaC (Infrastructure-as-Code) och vill ha en tydlig beskrivning av deploymentens tillstånd.

Sammanfattningsvis vill jag lägga till att variabler för standardmiljön i sin tur kan parameteriseras med variabler från operativsystemets miljö för en viss runner, från vilken deployment kommer att startas, och på så sätt få dynamiska miljöer.

helmfile.yaml

environments:
  default:
    values:
    - global:
        clusterDomain: {{ env "CLUSTER_DOMAIN" | default "cluster.local" }}
        ingressDomain: {{ env "INGRESS_DOMAIN" }}

Källa: habr.com