Helm en Kubernetes gebruiken

1. Overzicht

Helm is een pakketbeheerder voor Kubernetes-applicaties. In deze tutorial zullen we de basisprincipes van Helm begrijpen en hoe ze een krachtig hulpmiddel vormen voor het werken met Kubernetes-resources.

Kubernetes is de afgelopen jaren enorm gegroeid, net als het ecosysteem dat het ondersteunt. Onlangs is Helm aangekondigd als een incubatieproject door Cloud Native Computing Foundation (CNCF), dat zijn groeiende populariteit onder Kubernetes-gebruikers laat zien.

2. Achtergrond

Hoewel deze termen tegenwoordig vrij algemeen zijn, vooral onder degenen die met cloudtechnologieën werken, laten we ze snel doornemen voor degenen die het niet weten:

  1. Container: Container verwijst naar virtualisatie op besturingssysteemniveau. Meerdere containers draaien binnen een besturingssysteem in geïsoleerde gebruikersruimtes. Programma's die in een container worden uitgevoerd, hebben alleen toegang tot bronnen die aan de container zijn toegewezen.
  2. Docker: Docker is een populair programma om containers te maken en uit te voeren. Het wordt geleverd met Docker Daemon, het belangrijkste programma voor het beheren van containers. Docker Daemon biedt toegang tot zijn functies via Docker Engine API, die wordt gebruikt door Docker Command-Line Interface (CLI). Raadpleeg dit artikel voor een meer gedetailleerde beschrijving van Docker.
  3. Kubernetes: Kubernetes is een populair containerorkestratieprogramma. Hoewel het is ontworpen om met verschillende containers te werken, wordt Docker het vaakst gebruikt. Het biedt een brede selectie aan functies, waaronder automatisering van implementatie, schaalvergroting en bewerkingen voor een cluster van hosts. Er is een uitstekende dekking van Kubernetes in dit artikel voor verdere referentie.

3. Roerarchitectuur

Helm heeft een vrij eenvoudige architectuur, die bestaat uit een client en een in-clusterserver:

  • Tiller-server: Helm beheert de Kubernetes-applicatie via een component genaamd Tiller Server geïnstalleerd binnen een Kubernates-cluster. Tiller werkt samen met de Kubernetes API-server om Kubernetes-bronnen te installeren, upgraden, opvragen en verwijderen.
  • Helm Klant: Helm biedt een opdrachtregelinterface voor gebruikers om met Helm-grafieken te werken. Helm Client is verantwoordelijk voor de interactie met de Tiller Server om verschillende bewerkingen uit te voeren, zoals installatie-, upgrade- en rollback-grafieken.

4. Roer-diagrammen

Helm beheert Kubernetes-bronpakketten via grafieken.

We zullen meer over grafieken zien terwijl we ze binnenkort maken, maar voor nu is een grafiek niets anders dan een set informatie die nodig is om een ​​Kubernetes-applicatie te maken, gegeven een Kubernetes-cluster:

  • EEN chart is een verzameling bestanden georganiseerd in een specifieke directorystructuur
  • De configuratie-informatie met betrekking tot een diagram wordt beheerd in de configuratie
  • Tenslotte, een lopende instantie van een grafiek met een specifieke configuratie wordt een release genoemd

5. Opstelling

We hebben van tevoren een aantal dingen nodig om onze eerste helmkaart te ontwikkelen.

Ten eerste hebben we een Kubernetes-cluster nodig om met Helm te gaan werken. Voor deze tutorial gebruiken we Minikube, dat een uitstekende manier biedt om lokaal met een Kubernetes-cluster met één knooppunt te werken. Op Windows is het nu mogelijk om Hyper-V te gebruiken als de native Hypervisor om Minikube uit te voeren. Raadpleeg dit artikel voor meer informatie over het instellen van Minikube.

En we hebben een basistoepassing nodig om te beheren binnen het Kubernetes-cluster. Voor deze zelfstudie gebruiken we een eenvoudige Spring Boot-applicatie die is verpakt als een Docker-container. Raadpleeg dit artikel voor een meer gedetailleerde beschrijving van het verpakken van een dergelijke applicatie als een Docker-container.

6. Helm installeren

Er zijn verschillende manieren om Helm te installeren die netjes worden beschreven op de officiële installatiepagina op Helm. De snelste manier om helm op Windows te installeren, is door Chocolaty te gebruiken, een pakketbeheerder voor Windows-platforms.

Met Chocolaty is het een simpele opdracht van één regel om Helm te installeren:

choco installeert kubernetes-helm

Dit installeert de Helm Client lokaal.

Nu moeten we Helm CLI initialiseren, die effectief ook de Tiller Server op een Kubernetes-cluster installeert, zoals geïdentificeerd via de Kubernetes-configuratie. Alstublieft zorg ervoor dat het Kubernetes-cluster actief en toegankelijk is via kubectl voordat Helm wordt geïnitialiseerd:

kubectl cluster-info

En dan kunnen we Helm initialiseren via de Helm CLI zelf:

roer init

7. Ontwikkeling van onze eerste kaart

Nu zijn we klaar om onze eerste Helm-grafiek met sjablonen en waarden te ontwikkelen.

7.1. Een diagram maken

Helm CLI, die we eerder hebben geïnstalleerd, is best handig bij het maken van een diagram:

roer maken hallo-wereld

Houd er rekening mee dat de De naam van de kaart die hier wordt gegeven, is de naam van de map waarin de kaart is gemaakt en opgeslagen.

Laten we snel de directorystructuur bekijken die voor ons is gemaakt:

hello-world / Chart.yaml-waarden. yaml-sjablonen / grafieken / .helmignore

Laten we de relevantie begrijpen van deze bestanden en mappen die voor ons zijn gemaakt:

  • Chart.yaml: Dit is het hoofdbestand dat de beschrijving van onze grafiek bevat
  • waarden.yaml: dit is het bestand dat de standaardwaarden voor onze grafiek bevat
  • Sjablonen: Dit is de directory waarin Kubernetes-resources zijn gedefinieerd als sjablonen
  • grafieken: Dit is een optionele directory die subgrafieken kan bevatten
  • .helmignore: Dit is waar we patronen kunnen definiëren om te negeren bij het verpakken (vergelijkbaar in concept met .gitignore)

7.2. Sjabloon maken

Als we in de sjabloondirectory kijken, zullen we dat opmerken Er zijn al enkele sjablonen voor veelgebruikte Kubernetes-resources gemaakt voor ons:

hallo-world / templates / deployment.yaml service.yaml ingress.yaml ......

Mogelijk hebben we enkele van deze en mogelijk andere bronnen nodig in onze applicatie, die we zelf als sjablonen moeten maken.

Voor deze zelfstudie maken we een implementatie en een service om die implementatie zichtbaar te maken. Houd er rekening mee dat de nadruk hier niet is om Kubernetes in detail te begrijpen. Daarom houden we deze bronnen zo eenvoudig mogelijk.

Laten we het bestand bewerken deployment.yaml binnen in de Sjablonen directory om er uit te zien:

apiVersion: apps / v1 kind: implementatie metadata: name: {{include "hello-world.fullname". }} labels: app.kubernetes.io/name: {{include "hello-world.name". }} helm.sh/chart: {{include "hello-world.chart". }} app.kubernetes.io/instance: {{.Release.Name}} app.kubernetes.io/managed-by: {{.Release.Service}} specificatie: replica's: {{.Values.replicaCount}} selector: matchLabels: app.kubernetes.io/name: {{include "hello-world.name". }} app.kubernetes.io/instance: {{.Release.Name}} sjabloon: metadata: labels: app.kubernetes.io/name: {{include "hello-world.name". }} app.kubernetes.io/instance: {{.Release.Name}} specificatie: containers: - naam: {{.Chart.Name}} afbeelding: "{{.Values.image.repository}}: {{. Values.image.tag}} "imagePullPolicy: {{.Values.image.pullPolicy}} poorten: - naam: http container Poort: 8080 protocol: TCP

Laten we op dezelfde manier het bestand bewerken service.yaml lijken op:

apiVersion: v1 kind: Service metadata: name: {{include "hello-world.fullname". }} labels: app.kubernetes.io/name: {{include "hello-world.name". }} helm.sh/chart: {{include "hello-world.chart". }} app.kubernetes.io/instance: {{.Release.Name}} app.kubernetes.io/managed-by: {{.Release.Service}} specificatie: type: {{.Values.service.type}} poorten: - poort: {{.Values.service.port}} targetPort: http protocol: TCP-naam: http selector: app.kubernetes.io/name: {{include "hello-world.name". }} app.kubernetes.io/instance: {{.Release.Name}}

Nu, met onze kennis van Kubernetes, zien deze sjabloonbestanden er vrij bekend uit, op enkele eigenaardigheden na. Let op het ruime gebruik van tekst tussen dubbele haakjes {{}}. Dit wordt een sjabloonrichtlijn genoemd.

Helm maakt gebruik van de Go-sjabloontaal en breidt die uit naar iets dat Helm-sjabloontaal wordt genoemd. Tijdens de evaluatie wordt elk bestand in de sjabloondirectory verzonden naar de sjabloonweergave-engine. Dit is waar de sjabloonrichtlijn werkelijke waarden in de sjablonen injecteert.

7.3. Waarden bieden

In de vorige subsectie hebben we gezien hoe we de sjabloonrichtlijn in onze sjablonen kunnen gebruiken. Laten we nu eens kijken hoe we waarden kunnen doorgeven aan de sjabloonweergave-engine. We geven doorgaans waarden door via ingebouwde objecten in Helm.

Er zijn veel van dergelijke objecten beschikbaar in Helm, zoals Release, Values, Chart en Files.

We kunnen het bestand gebruiken waarden.yaml in ons diagram om waarden door te geven aan de sjabloonweergave-engine via de ingebouwde objectwaarden. Laten we het waarden.yaml lijken op:

replicaCount: 1 afbeelding: repository: "hallo-wereld" tag: "1.0" pullPolicy: IfNotPresent-service: type: NodePort-poort: 80

Merk echter op hoe deze waarden zijn benaderd binnen sjablonen met behulp van punten die naamruimten van elkaar scheiden. We hebben de afbeeldingsrepository gebruikt en de tag als "hallo-wereld" en "1.0", dit moet overeenkomen met de docker-afbeeldingstag die we hebben gemaakt voor onze Spring Boot-applicatie.

8. Inzicht in roeropdrachten

Nu alles tot nu toe is gedaan, zijn we nu klaar om met onze kaart te spelen. Laten we eens kijken wat de verschillende commando's zijn die beschikbaar zijn in Helm CLI om dit leuk te maken!

8.1. Roer Lint

Ten eerste is dit een eenvoudige opdracht die het pad naar een kaart leidt en een reeks tests uitvoert om ervoor te zorgen dat de kaart goed is gevormd:

helm lint ./hello-world ==> Linting ./hello-world 1 kaart (en) linted, geen fouten

8.2 Roer-sjabloon

We hebben ook dit commando om de sjabloon lokaal te renderen, zonder een Tiller Server, voor snelle feedback:

helm template ./hello-world --- # Bron: hello-world / templates / service.yaml apiVersion: v1 soort: Service metadata: name: release-name-hello-world labels: app.kubernetes.io/name: hallo -world helm.sh/chart: hallo-world-0.1.0 app.kubernetes.io/instance: releasenaam app.kubernetes.io/managed-by: Tiller specificatie: type: NodePort-poorten: - poort: 80 targetPort: http-protocol: TCP-naam: http-selector: app.kubernetes.io/name: hallo-world app.kubernetes.io/instance: release-name --- # Bron: hello-world / templates / deployment.yaml apiVersion: apps / v1 soort: implementatie metadata: naam: release-naam-hello-world labels: app.kubernetes.io/name: hello-world helm.sh/chart: hello-world-0.1.0 app.kubernetes.io/instance: release -name app.kubernetes.io/managed-by: Tiller spec: replica's: 1 selector: matchLabels: app.kubernetes.io/name: hallo-world app.kubernetes.io/instance: release-name sjabloon: metadata: labels: app.kubernetes.io/name: hallo-world app.kubernetes.io/instance: release-name spec: containers: - na me: hallo-wereld afbeelding: "hallo-wereld: 1.0" imagePullPolicy: IfNotPresent poorten: - naam: http containerPort: 8080 protocol: TCP

8.3. Helm installeren

Nadat we hebben gecontroleerd of de grafiek in orde is, kunnen we eindelijk deze opdracht uitvoeren om de grafiek in het Kubernetes-cluster te installeren:

helm install --name hallo-world ./hello-world NAAM: hallo-world LAATST INGESCHAKELD: ma 25 feb 15:29:59 2019 NAMESPACE: standaard STATUS: INGEVOEGDE MIDDELEN: ==> v1 / Service NAAM TYPE CLUSTER-IP EXTERN -IP-POORT (EN) LEEFTIJD hallo-world NodePort 10.110.63.169 80: 30439 / TCP 1s ==> v1 / Implementatie NAAM GEWENSTE HUIDIGE UP-TO-DATE BESCHIKBARE LEEFTIJD hallo-world 1 0 0 0 1s ==> v1 / Pod (gerelateerd) NAAM KLAAR STATUS HERSTART LEEFTIJD hallo-world-7758b9cdf8-cs798 0/1 In afwachting van 0 0s

Merk ten slotte op dat we de uitgave van deze chart de vlag –naam hebben gegeven. De opdracht reageert met de samenvatting van Kubernetes-resources die tijdens het proces zijn gemaakt.

8,4. Helm Get

Nu willen we zien welke grafieken zijn geïnstalleerd als welke release. Met dit commando kunnen we de genoemde releases opvragen:

helm ls --all NAAM HERZIENING BIJGEWERKTE STATUS GRAFIEK APP VERSIE NAMESPACE hallo-world 1 ma 25 feb 15:29:59 2019 GEÏNTEGREERD hallo-world-0.1.0 1.0 standaard

8.5. Roer upgrade

Wat als we onze grafiek hebben aangepast en de bijgewerkte versie moeten installeren? Dit commando helpt ons om een ​​release te upgraden naar een gespecificeerde of huidige versie van de grafiek of configuratie:

helm upgrade hello-world ./hello-world Release "hello-world" is geüpgraded. Gelukkig Helming! LAATST TOEGEPAST: ma 25 feb 15:36:04 2019 NAMESPACE: standaard STATUS: INGEVOEGDE MIDDELEN: ==> v1 / Service NAAM TYPE CLUSTER-IP EXTERNE IP-POORT (EN) LEEFTIJD hallo-world NodePort 10.110.63.169 80: 30439 / TCP 6m5s ==> v1 / Implementatie NAAM GEWENSTE HUIDIGE UP-TO-DATE BESCHIKBARE LEEFTIJD hallo-world 1 1 1 1 6m5s ==> v1 / Pod (gerelateerd) NAAM GEREED STATUS HERSTART LEEFTIJD hello-world-7758b9cdf8-cs798 1/1 Rennen 0 6m4s

8,6. Roer terugdraaien

Het kan altijd gebeuren dat een vrijgave fout is gegaan en moet worden teruggenomen. Dit is de opdracht om een ​​release terug te draaien naar de vorige versie:

helm rollback hallo-world 1 Rollback was een succes! Gelukkig Helming!

8.7. Helm verwijderen

Hoewel het minder waarschijnlijk is, willen we misschien een release volledig verwijderen. We kunnen deze opdracht gebruiken om een ​​release uit Kubernetes te verwijderen:

helm delete --purge hello-world release "hello-world" verwijderd

Dit zijn slechts enkele van de opdrachten die beschikbaar zijn om met grafieken en releases in Helm te werken.

9. Verspreidingsdiagrammen

Hoewel sjablonen een krachtige tool is die Helm naar de wereld van het beheer van Kubernetes-resources brengt, is het niet het enige voordeel van het gebruik van Helm. Zoals we in de vorige sectie hebben gezien, fungeert Helm als pakketbeheerder voor de Kubernetes-applicatie en maakt het installeren, opvragen, upgraden en verwijderen van releases behoorlijk naadloos.

Daarnaast Helm wordt geleverd met opdrachten als onderdeel van de CLI voor het verpakken, publiceren en ophalen van Kubernetes-applicaties als grafieken:

9.1. Helm-pakket

Ten eerste moeten we de grafieken die we hebben gemaakt inpakken om ze te kunnen verspreiden. Dit is de opdracht om archiefbestanden met versiebeheer van de grafiek te maken:

helm pakket ./hello-world Kaart succesvol verpakt en opgeslagen in: \ hello-world \ hello-world-0.1.0.tgz

Merk op dat het een archief op uw computer produceert dat handmatig of via openbare of privé-kaartrepository's kan worden gedistribueerd.

9.2. Helm Repo

Ten slotte hebben we een mechanisme nodig om samen te werken met gedeelde opslagplaatsen. Repo bundelt een aantal opdrachten die we kunnen gebruiken om kaartrepository's toe te voegen, te verwijderen, weer te geven of te indexeren. Laten we eens kijken hoe we ze kunnen gebruiken.

We kunnen een git-repository maken en die gebruiken om te functioneren als onze repository voor grafieken. De enige vereiste is dat het een index.yaml het dossier.

We kunnen creëren index.yaml voor onze repository:

helm repo index mijn-repo / --url //.github.io/my-repo

Dit genereert de index.yaml bestand, dat we samen met de kaartarchieven naar de repository zouden moeten pushen.

Nadat we met succes de kaartrepository hebben gemaakt, kunnen we deze repository op afstand toevoegen:

helm repo add my-repo //my-pages.github.io/my-repo

Nu zouden we de grafieken rechtstreeks vanuit onze repo moeten kunnen installeren:

helm install my-repo / hello-world --name = hallo-world

Er zijn nogal wat utility-opdrachten beschikbaar om met kaartrepository's te werken.

10. Conclusie

Samenvattend hebben we in deze tutorial de kerncomponenten van Helm besproken, een pakketbeheerder voor Kubernetes-applicaties. We begrepen opties om Helm te installeren. Verder hebben we een voorbeelddiagram en sjablonen met waarden gemaakt.

Vervolgens hebben we meerdere opdrachten doorlopen die beschikbaar zijn als onderdeel van Helm CLI om de Kubernetes-applicatie als een Helm-pakket te beheren.

Ten slotte hebben we de opties besproken voor het distribueren van Helm-pakketten via repositories.


$config[zx-auto] not found$config[zx-overlay] not found