Een Helm-release beheren

  • 12 minuten

Functies gebruiken in een Helm-sjabloon

De taal van de Helm-sjabloon definieert functies die u gebruikt om waarden uit het values.yaml-bestand te transformeren. De syntaxis voor een functie volgt de {{ functionName arg1 arg2 ... }} structuur. Laten we eens kijken naar de functie quote als voorbeeld om deze syntaxis in gebruik te zien.

De functie quote verpakt een waarde tussen aanhalingstekens om het gebruik van een stringaan te geven. Stel dat u het volgende values.yaml-bestand definieert:

apiVersion: v2
name: webapp
description: A Helm chart for Kubernetes
ingress:
  enabled: true

U besluit dat u de ingress.enabled-waarde wilt gebruiken als een booleaanse waarde bij het bepalen of een ingangsmanifest moet worden gegenereerd. Als u de enabled-waarde als een Booleaanse waarde wilt gebruiken, verwijst u naar de waarde met behulp van {{ .Values.ingress.enabled }}.

Later besluit u het veld weer te geven als een tekenreeks in het templates/Notes.txt bestand. Omdat YAML-regels voor type-dwang kunnen leiden tot moeilijk te vinden fouten in sjablonen, besluit u richtlijnen te volgen en expliciet te zijn bij het opnemen van tekenreeksen in uw sjablonen. enabled: false is bijvoorbeeld niet gelijk aan enabled: "false".

Als u de waarde als een tekenreeks wilt weergeven, gebruikt u {{ quote .Values.ingress.enabled }} om te verwijzen naar de Booleaanse waarde als een tekenreeks.

Pijplijnen gebruiken in een Helm-sjabloon

U gebruikt pijplijnen wanneer meer dan één functie op een waarde moet reageren. Met een pijplijn kunt u een waarde of het resultaat van een functie verzenden naar een andere functie. U kunt de bovenstaande quote bijvoorbeeld opnieuw schrijven als {{ .Values.ingress.enabled | quote }}. Let op hoe de | aangeeft dat de waarde naar de functie quote wordt verzonden.

Hier volgt nog een voorbeeld. Stel dat u een waarde wilt omzetten naar hoofdletters en deze tussen aanhalingstekens wilt plaatsen. U kunt de verklaring schrijven als {{ .Values.ingress.enabled | upper | quote }}. U ziet hoe de waarde wordt verwerkt door de upper functie en vervolgens de quote functie.

De sjabloontaal bevat meer dan 60 functies waarmee u waarden en objecten in sjablonen kunt weergeven, opzoeken en transformeren.

Conditionele stroomcontrole in een Helmsjabloon gebruiken

Met stroombeheer op basis van voorwaarden kunt u bepalen welke structuur of gegevens zijn opgenomen in het gegenereerde manifestbestand. U kunt bijvoorbeeld verschillende waarden opnemen op basis van het implementatiedoel of besturingselement als er een manifestbestand wordt gegenereerd.

Het if / else blok is een dergelijke controlestroomstructuur en voldoet aan de volgende indeling:

{{ if | pipeline | }}
  # Do something
{{ else if | other pipeline | }}
  # Do something else
{{ else }}
  # Default case
{{ end }}

Stel dat u besluit dat het ingress-manifestbestand voor een chart alleen in specifieke gevallen wordt aangemaakt. In het volgende voorbeeld ziet u hoe u dit kunt doen met behulp van een if-instructie:

{{ if .Values.ingress.enabled }}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{ end }}

Houd er rekening mee dat u tijdelijke aanduidingen kunt gebruiken om metagegevens in de sjabloon in te vullen. Sjabloonbestanden worden sequentieel geparseerd en geëvalueerd door de sjabloontaal van boven naar beneden. In het vorige voorbeeld genereert de sjabloonengine alleen de inhoud van het manifestbestand als de waarde .Values.ingress.enabled is true.

Wanneer de sjabloonengine de instructie verwerkt, wordt de inhoud verwijderd die in de {{ }} syntaxis is gedeclareerd en blijft de resterende witruimte behouden. Deze syntaxis zorgt ervoor dat de sjabloonengine een nieuwe regel voor de if instructieregel bevat. Als u de inhoud van het voorgaande bestand as-islaat, ziet u lege regels in uw YAML en wordt het manifestbestand voor inkomend verkeer gegenereerd.

YAML geeft betekenis aan witruimte. Daarom worden tabs, spatiesen regeltekens als belangrijk beschouwd. U kunt het bestand als volgt herschrijven om het probleem van ongewenste witruimte op te lossen:

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  name: ...
  labels:
    ...
  annotations:
    ...
spec:
  rules:
    ...
{{- end }}

Let op het gebruik van het - teken als onderdeel van het begin {{- en de eindvolgorde van de instructie -}}. Met het - teken wordt de parser geïnstrueerd om spaties te verwijderen. {{- verwijdert witruimte aan het begin van een regel en -}} aan het einde van een regel, inclusief het nieuwe regelteken.

Hoe je een verzameling waarden doorloopt in een Helm-sjabloon

MET YAML kunt u verzamelingen items definiëren en afzonderlijke items gebruiken als waarden in uw sjablonen. Het openen van items in een verzameling is mogelijk met behulp van een indexeerfunctie. De Helm-sjabloontaal ondersteunt echter de iteratie van een verzameling waarden met behulp van de operator range.

Stel dat u in uw values.yaml-bestand een lijst met waarden definieert om extra ingangshosts aan te geven. Hier volgt een voorbeeld van de waarden:

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

U gebruikt de bereikoperator om de sjabloonengine iteraties door te laten voeren over de .Values.ingress.extraHosts. In het volgende codefragment ziet u een verkort voorbeeld met behulp van de operator range:

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1
kind: Ingress
metadata:
  ...
spec:
  rules:
    ...
    {{- range .Values.ingress.extraHosts }}
    - host: {{ .name }}
      http:
        paths:
          - path: {{ .path }}
            ...
    {{- end }}
  ...
{{- end }}

Het bereik van waarden in een Helm-sjabloon beheren

Wanneer u waarden hebt gedefinieerd die verschillende lagen diep zijn gedefinieerd, kan uw syntaxis lang en lastig worden wanneer u deze waarden in een sjabloon op wilt opnemen. Met de actie with kunt u het bereik van variabelen in een sjabloon beperken.

Houd er rekening mee dat de . die in een Helm-sjabloon wordt gebruikt, verwijst naar de huidige scope. De .Values geeft bijvoorbeeld de sjabloonengine de opdracht om het Values-object in de huidige scope te vinden. Stel dat u het values.yaml-bestand van eerder gebruikt om een manifestbestand voor een configuratietoewijzing te maken:

ingress:
  enabled: true
  extraHosts:
    - name: host1.local
      path: /
    - name: host2.local
      path: /
    - name: host3.local
      path: /

In plaats van de padwaarde van elk item te benaderen met behulp van {{ .Values.ingress.extraHosts.path }}, kunt u de actie with gebruiken. In het volgende codefragment ziet u een voorbeeld met behulp van de operator range voor het genereren van een manifestbestand voor een configuratietoewijzing:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  {{ end }}

De {{- with .Values.ingress.extraHosts }} beperkt het bereik van waarden tot de .Values.ingress.extraHosts matrix.

De actie with beperkt het bereik. U hebt geen toegang tot andere objecten vanuit de bovenliggende scope. Stel dat u ook toegang wilt krijgen tot de {{ .Release.Name }} van de grafiek in het codeblok with. Als u toegang wilt krijgen tot bovenliggende objecten, moet u het hoofdbereik aangeven met behulp van het $ teken of de code opnieuw schrijven. Hier ziet u de bijgewerkte code om weer te geven hoe u bovenliggende objecten kunt opnemen met behulp van het $ teken:

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  {{- with .Values.ingress.extraHosts }}
  hostname: {{ .name }}
  path: {{ .path }}
  release: {{ $.Release.Name}}
  {{ end }}

Notitie

Er zijn verschillende constructies beschikbaar in de Helm-sjabloontaal om de stroom te beheren. De samenvattingseenheid van deze module bevat een sectie met koppelingen naar de Helm-documentatie voor meer informatie.

Hoe afhankelijkheden van grafieken in Helm te definiëren

Met een grafiek kan de declaratie van afhankelijkheden de hoofdtoepassing ondersteunen en deel uitmaken van de geïnstalleerde release.

Een diagram laat zien hoe Helm alle subgrafieken als afhankelijkheden van de hoofdgrafiek implementeert in een Kubernetes-cluster.

U kunt een subgrafiek maken met behulp van de opdracht helm create, de locatie van de nieuwe grafiek opgeven in de map /charts of de opdracht helm dependency gebruiken. Houd er rekening mee dat de map /charts subgrafieken kan bevatten die zijn geïmplementeerd als onderdeel van de release van de hoofdgrafiek.

Met de opdracht helm dependency kunt u afhankelijkheden beheren die zijn opgenomen in een Helm-opslagplaats. De opdracht maakt gebruik van metagegevens die zijn gedefinieerd in de sectie dependencies van het waardenbestand van uw grafiek. U geeft de naam, het versienummer en de opslagplaats op van waaruit u het subdiagram wilt installeren. Hier volgt een extract van een values.yaml-bestand met een MongoDB-grafiek die wordt vermeld als een afhankelijkheid:

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes
...
dependencies:
  - name: mongodb
    version: 10.27.2
    repository: https://marketplace.azurecr.io/helm/v1/repo

Zodra de metagegevens van de afhankelijkheid zijn gedefinieerd, voert u de opdracht helm dependency build uit om de in tar verpakte grafiek op te halen. Met de chart build-opdracht wordt de grafiek gedownload in de map charts/.

helm dependency build ./app-chart

Subgrafieken worden afzonderlijk van de hoofdgrafiek beheerd en hebben mogelijk updates nodig wanneer er nieuwe releases beschikbaar komen. De opdracht voor het bijwerken van subgrafieken is helm dependency update. Met deze opdracht worden nieuwe versies van het subdiagram opgehaald tijdens het verwijderen van verouderde pakketten.

helm dependency update ./app-chart

Houd er rekening mee dat een grafiekafhankelijkheid niet beperkt is tot andere toepassingen. U kunt besluiten sjabloonlogica opnieuw te gebruiken in uw grafieken en een afhankelijkheid te maken die specifiek is bedoeld voor het beheren van deze logica als grafiekafhankelijkheid. In de volgende oefening krijgt u een voorbeeld van deze strategie.

Een Helm-release upgraden

Met Helm kunnen bestaande releases worden bijgewerkt als een delta van alle wijzigingen die van toepassing zijn op de grafiek en de bijbehorende afhankelijkheden.

Een diagram laat zien hoe met de Helm-upgradeopdracht een delta wordt gemaakt van alle gewijzigde items in een Helm-grafiek om een release bij te werken en een nieuwe versierevisie te maken op een Kubernetes-cluster.

Stel dat het ontwikkelteam van het voorbeeld webapp in deze les codewijzigingen aanbrengt die alleen van invloed zijn op de functionaliteit van de website. Het team voert de volgende updates uit voor het Chart.yaml-bestand om de nieuwe versie van de toepassing weer te geven:

  • Werkt het containerbeeld van de web-app bij en tagt het als webapp: linux-v2 bij verzending naar het containerregister.
  • Hiermee werkt u de dockerTag waarde bij naar linux-v2 en de waarde van de grafiekversie naar 0.2.0 in het waardenbestand van de grafiek.

Hier volgt een voorbeeld van het bijgewerkte values.yaml-bestand:

apiVersion: v2
name: my-app
description: A Helm chart for Kubernetes

type: application

version: 0.2.0
appVersion: 1.0.0

registry: "my-acr-registry.azurecr.io"
dockerTag: "linux-v2"
pullPolicy: "Always"

In plaats van een huidige release te verwijderen, gebruikt u de opdracht helm upgrade om de bestaande Helm-release bij te werken.

helm upgrade my-app ./app-chart

Houd er rekening mee dat Helm een delta genereert van de wijzigingen die zijn aangebracht in de Helm-grafiek wanneer u een release bijwerkt. Als zodanig wordt met een Helm-upgrade alleen de onderdelen bijgewerkt die zijn geïdentificeerd in de delta. In het voorbeeld wordt alleen de website opnieuw geïmplementeerd.

Zodra de upgrade is voltooid, kunt u de implementatiegeschiedenis van de release bekijken met behulp van de opdracht helm history met de releasenaam.

helm history my-app

De geschiedenisopdracht retourneert verschillende velden die de release beschrijven, zoals wordt weergegeven in de volgende voorbeelduitvoer:

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        deployed        aspnet-core-1.3.18      3.1.19          Install complete

Let op het revision veld in het resultaat. Helm houdt release-informatie bij van alle releases die zijn uitgevoerd voor een Helm-chart. Wanneer u een nieuwe versie van een Helm-grafiek installeert, neemt het aantal revisies met één toe en wordt de nieuwe release-informatie vergeleken met die revisie.

Hier volgt een voorbeeld van dezelfde geschiedenisopdracht die wordt uitgevoerd na een nieuwe versie-installatie van de web-app:

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

Hoe een Helm-release terugdraaien

Helm maakt het mogelijk om een bestaande Helm-release terug te draaien naar een eerder geïnstalleerde release. Vergeet niet dat Helm de informatie over releases van alle releases van een Helm-chart bijhoudt.

U gebruikt de opdracht helm rollback om terug te keren naar een specifieke Helm-releaserevisie. Deze opdracht maakt gebruik van twee parameters. De eerste parameter identificeert de naam van de release en de tweede identificeert het revisienummer van de release.

helm rollback my-app 2

Met de opdracht helm rollback wordt de releaseversie van de app teruggedraaid naar de opgegeven revisie en wordt de releasegeschiedenis van de app bijgewerkt. In een vervolguitvoering van de opdracht helm history wordt het meest recente actieve revisienummer weergegeven als de meest recente releasevermelding.

Stel dat het ontwikkelteam van het voorbeeld webapp in deze les een bug ontdekt in de webtoepassing voor het traceren van drones en moet terugkeren naar een vorige release. In plaats van de huidige release te verwijderen en een eerdere versie te installeren, worden ze teruggedraaid naar de werkende release.

helm rollback my-app 1

Zodra het terugdraaien is voltooid, kunt u de implementatiegeschiedenis bekijken met behulp van de opdracht helm history.

REVISION        UPDATED                         STATUS          CHART                   APP VERSION     DESCRIPTION
1               Mon Oct 11 17:25:33 2021        superseded      aspnet-core-1.3.18      3.1.19          Install complete
2               Mon Oct 11 17:35:13 2021        superseded      aspnet-core-1.3.18      3.1.19          Rolled back to 1
3               Mon Oct 11 17:38:13 2021        deployed        aspnet-core-1.3.18      3.1.19          Upgrade complete

U ziet in het beschrijvingsveld het revisienummer van de terugdraaiactie, zodat u gemakkelijker wijzigingen kunt bijhouden.