Der Artikel ist eine logische Fortsetzung unserer
jüngsten Veröffentlichung zur Geschichte des Paketmanagers für Kubernetes -
Helm . Dieses Mal werden wir uns erneut mit den Problemen des Geräts und der Funktionsweise des aktuellen Helms (
Version 2.x ) sowie den von ihm verwalteten Diagrammen und Repositorys befassen. Anschließend werden wir mit der Installation von Helm im Kubernetes-Cluster und der Verwendung der Diagramme fortfahren.
Eintrag
Helm ist ein Diagrammverwaltungswerkzeug.Das Diagramm beschreibt den erforderlichen Datensatz, um die Anwendung im Kubernetes-Cluster zu instanziieren. Es kann eingebettete Diagramme haben und sowohl zur Beschreibung vollwertiger Dienste, die aus vielen abhängigen Ressourcen bestehen, als auch zur Beschreibung einzelner unabhängiger Komponenten verwendet werden. Zum Beispiel beschreibt das
Stable / Gitlab-Ce- Diagramm eine vollständige Lösung unter
Verwendung der unabhängigen Redis- und Postgresql-Diagramme.
Ein Diagramm kann unbegrenzt oft im selben Cluster festgelegt werden. Daher kann und sollte die Beschreibung der Rollout-Logik der Anwendung in verschiedenen Umgebungen in demselben Diagramm gespeichert werden.
Die Client-Seite von Helm ist dafür verantwortlich, das Diagramm zu erstellen und die
Tiller- Komponente zusammen mit den Benutzerparametern in den Kubernetes-Cluster zu übertragen. Tiller ist wiederum für den Lebenszyklus der Instanz des gestarteten Diagramms Release verantwortlich.
(Nur für den Fall, ich möchte Sie daran erinnern, dass das nächste große Update von Helm - Version 3 - Tiller nicht mehr enthalten wird.)Und jetzt - das Wichtigste zuerst.
Installation und Upgrade
Helm benötigt Kubernetes, um zu arbeiten. Sie können einen lokal installierten
Minikube (siehe auch „ Erste Schritte in Kubernetes mit Minikube “) oder einen anderen verfügbaren Cluster verwenden.
Beginnen wir mit der Installation des Clients: Wählen Sie die
Version aus , laden Sie das Archiv für Ihr System herunter und entpacken Sie es, übertragen Sie die ausführbare Datei ...
$ curl https://storage.googleapis.com/kubernetes-helm/helm-v2.10.0-linux-amd64.tar.gz | tar -zxv $ sudo mv linux-amd64/helm /usr/local/bin/helm
Installieren Sie als Nächstes Tiller im Cluster. Standardmäßig wird Tiller im
kubectl (
kubectl config current-context ) im
kube-system Namespace kube-system Dies kann jedoch mithilfe der entsprechenden Optionen und Umgebungsvariablen geändert werden. Diese werden in der Hilfe beschrieben (
helm init --help ). Lassen Sie uns die Installation abschließen und die erstellten Ressourcen im Cluster betrachten:
$ helm init $HELM_HOME has been configured at /home/habr/.helm. (Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.) Happy Helming! $ kubectl get all --selector=name=tiller --namespace kube-system NAME READY STATUS RESTARTS AGE po/tiller-deploy-df4fdf55d-h5mvh 0/1 Running 0 5s NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE svc/tiller-deploy 10.107.191.68 <none> 44134/TCP 5s NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE deploy/tiller-deploy 1 1 1 0 5s NAME DESIRED CURRENT READY AGE rs/tiller-deploy-df4fdf55d 1 1 0 5s
Jetzt ist Tiller im Cluster installiert und bereit für das Release-Management und die Interaktion mit der Kubernetes-API.
Hinweis : Während der Installation und des Upgrades (Option --upgrade ) von Tiller können Sie ein bestimmtes Image angeben, anstatt standardmäßig die neueste stabile Version zu verwenden. Der Name eines beliebigen Bildes wird durch die Option --tiller-image Option --tiller-image wird beim --canary-image Tiller ein --canary-image verwendet. Auf dem Kanarienvogelbild können Sie Tiller verwenden, dessen Codeversion dem Hauptzweig entspricht.Die Servicedaten werden in einem Cluster in speziellen Ressourcen,
ConfigMaps ,
ConfigMaps , sodass die Deinstallation und Neuinstallation von Tiller nicht zum Verlust von Daten aus zuvor installierten Releases führt.
Diagramm-Repositorys
Diagramm-Repository - Ein HTTP-Server zum Speichern und Verteilen von Diagrammen. Informationen zu Diagrammen im Repository werden in der Datei
index.yaml gespeichert. Es zeigt auch an, von wo jedes Diagramm geladen werden kann. Meistens werden die Diagramme mit der Datei
index.yaml gespeichert, aber nichts hindert sie daran, auf einem anderen Server abgelegt zu werden. Normalerweise hat die Dateistruktur eine flache Form:
. ├── index.yaml ├── artifactory-7.3.0.tgz ├── docker-registry-1.5.2.tgz ... └── wordpress-2.1.10.tgz
Standardmäßig verwendet Helm das
offizielle Kubernetes-Diagramm-Repository . Es enthält sorgfältig gestaltete aktuelle Diagramme zur Lösung vieler angewandter Probleme. Dieses Repository heißt
stabil :
$ helm repo list NAME URL stable https://kubernetes-charts.storage.googleapis.com
Bei Bedarf ist das
Erstellen eines eigenen Repositorys kein Problem. Die Serveranforderungen sind minimal, sodass sie wie die meisten öffentlichen Diagramm-Repositorys auf GitHub-Seiten gehostet werden können. Weitere Informationen zu den Tools und den dazu erforderlichen Schritten finden Sie in der
Dokumentation .
Bei Verwendung von Diagramm-Repositorys können diese hinzugefügt und entfernt werden. Damit die Diagrammversionen auf dem neuesten Stand sind, müssen Sie den Index regelmäßig aktualisieren. Ich werde ein Beispiel für das öffentliche
Bitnami- Repository geben, von dem die meisten Diagramme im offiziellen Helm-Repository verwendet werden:
$ helm repo add bitnami https://charts.bitnami.com/bitnami "bitnami" has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "bitnami" chart repository ...Successfully got an update from the "stable" chart repository Update Complete. Happy Helming! $ helm repo remove bitnami "bitnami" has been removed from your repositories
Weiter -
Durchsuchen Sie die Repositorys. Ein
helm search ohne Argumente zeigt alle verfügbaren Diagramme an:
$ helm search NAME CHART VERSION APP VERSION DESCRIPTION stable/acs-engine-autoscaler 2.2.0 2.1.1 Scales worker nodes within agent pools stable/aerospike 0.1.7 v3.14.1.2 A Helm chart for Aerospike in Kubernetes stable/anchore-engine 0.2.1 0.2.4 Anchore container analysis and policy evaluation engine s... stable/apm-server 0.1.0 6.2.4 The server receives data from the Elastic APM agents and ... stable/ark 1.2.1 0.9.1 A Helm chart for ark stable/artifactory 7.3.0 6.1.0 Universal Repository Manager supporting all major packagi... ... stable/weave-cloud 0.2.2 0.2.0 Weave Cloud is a add-on to Kubernetes which provides Cont... stable/weave-scope 0.9.3 1.6.5 A Helm chart for the Weave Scope cluster visualizer. stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites. stable/xray 0.4.1 2.3.0 Universal component scan for security and license invento... stable/zeppelin 1.0.1 0.7.2 Web-based notebook that enables data-driven, interactive ... stable/zetcd 0.1.9 0.0.3 CoreOS zetcd Helm chart for Kubernetes
Im Feld für optionale
keywords in
Chart.yaml Entwickler Tags an, mit denen die Suche in den Diagramm-Repositorys vereinfacht wird:
$ helm search web NAME CHART VERSION APP VERSION DESCRIPTION stable/cerebro 0.3.1 0.8.1 A Helm chart for Cerebro - a web admin tool that replaces... stable/chronograf 0.4.5 1.3 Open-source web application written in Go and React.js th... stable/jasperreports 2.0.4 7.1.0 The JasperReports server can be used as a stand-alone or ... stable/joomla 2.0.9 3.8.12 PHP content management system (CMS) for publishing web co... stable/kubernetes-dashboard 0.7.2 1.8.3 General-purpose web UI for Kubernetes clusters stable/odoo 2.0.7 11.0.20180815 A suite of web based open source business apps. stable/phabricator 2.1.9 2018.34.0 Collection of open source web applications that help soft... stable/redmine 4.1.0 3.4.6 A flexible project management web application. stable/rethinkdb 0.1.4 0.1.0 The open-source database for the realtime web stable/schema-registry-ui 0.1.0 v0.9.4 This is a web tool for the confluentinc/schema-registry i... stable/superset 0.1.2 0.24.0 Apache Superset (incubating) is a modern, enterprise-read... stable/testlink 2.0.3 1.9.17 Web-based test management system that facilitates softwar... stable/tomcat 0.1.0 7 Deploy a basic tomcat application server with sidecar as ... stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites. ... $ helm search cms blog NAME CHART VERSION APP VERSION DESCRIPTION stable/drupal 1.1.3 8.5.6 One of the most versatile open source content management ... stable/joomla 2.0.9 3.8.12 PHP content management system (CMS) for publishing web co... stable/wordpress 2.1.10 4.9.8 Web publishing platform for building blogs and websites
Hinweis: Bei Verwendung des Befehls helm search kann es zu einem instabilen Betrieb mehrerer Filter kommen: Die Verfügbarkeit des Ergebnisses hängt von der Reihenfolge der Anzeige und der Anzahl der Filter ab.Nachdem sich der Suchkreis auf mehrere Optionen beschränkt hat, können Sie mit dem Befehl
helm inspect eine detailliertere Analyse der Diagramme durchführen. Es zeigt den Inhalt der Diagrammdateien
Chart.yaml ,
values.yaml und
README.md . Jeder Abschnitt kann einzeln mit den entsprechenden Argumenten angezeigt werden:
chart ,
values und
readme .
Im offiziellen Repository sind Diagramme wunderschön dokumentiert und enthalten Verwendungsbeispiele. Einige Diagramme verfügen sogar über vorgefertigte Konfigurationen für die
Produktion . Eine gute
readme wird beispielsweise von
Stable / WordPress bereitgestellt
(für die Ausgabe in der Konsole siehe helm inspect readme stable/wordpress ) .
Suchen ist ein guter Weg, um erschwingliche Pakete zu finden. Nachdem das Paket gefunden wurde, können Sie es verwenden, um die Anwendung im Cluster zu installieren.
Erste Bewerbung
Beispielsweise wird das bereits erwähnte
Stable / WordPress- Diagramm ausgewählt.
Es verwendet die in der Datei
values.yaml beschriebenen Parameter. Sie können die Parameter in einer YAML-Datei überschreiben und diese Datei dann während der Installation übertragen (Optionen
-f ,
--values ). Außerdem können sie direkt in der Befehlszeile überschrieben werden (Optionen
--set ,
--set-string und
--set-file ). Alle Optionen können beliebig oft verwendet werden. Gleichzeitig hat das Überschreiben in der Befehlszeile Vorrang vor Dateien mit Parametern.
Beim Festlegen des Diagramms können Sie den
--name mit der Option
--name oder den von Helm generierten Zufallsnamen verwenden.
Legen Sie das
Konfigurationsdiagramm für die Produktion fest , ändern Sie den Namen des Blogs und deaktivieren Sie das Speichern von WordPress-Daten in
PersistentVolumeClaim (weitere Informationen zum persistenten Speicher finden Sie in der Kubernetes-Dokumentation ) :
$ curl https://raw.githubusercontent.com/helm/charts/master/stable/wordpress/values-production.yaml --output values-production.yaml $ helm install --name habr --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress NAME: habr LAST DEPLOYED: Fri Aug 31 15:17:57 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 0s habr-wordpress Opaque 2 0s ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 0s habr-mariadb 1 0s habr-mariadb-tests 1 0s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 0s habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 0s ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 3 3 0 0s ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 0s ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 0s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-7955b95fd-hh7b9 0/1 ContainerCreating 0 0s habr-wordpress-7955b95fd-tgsxk 0/1 ContainerCreating 0 0s habr-wordpress-7955b95fd-xjz74 0/1 ContainerCreating 0 0s habr-mariadb-0 0/1 ContainerCreating 0 0s NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
Wenn Sie mit einem vollwertigen Cluster arbeiten, können Sie den Empfehlungen aus dem obigen
NOTES- Block folgen. Wenn Sie Minikube haben, öffnen Sie die Site in einem Browser wie folgt:
$ minikube service habr-wordpress Waiting, endpoint for service is not ready yet... Opening kubernetes service default/habr-wordpress in default browser...
Herzlichen Glückwunsch, die Anwendung befindet sich in einem Cluster!
Ein detailliertes Diagramm mit WordPress wurde in der Liste aller Helm-Versionen angezeigt:
$ helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE habr 1 Fri Aug 31 15:17:57 2018 DEPLOYED wordpress-2.1.10 4.9.8 default
Der nächste Schritt besteht darin, unsere Version zu aktualisieren und das Bild mit dem Blog zu ändern. Beispielsweise wird ein anderes Tag aus demselben Docker-Repository (
4.9.8-ol-7 ) verwendet:
$ helm upgrade habr --set "image.tag=4.9.8-ol-7" --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress Release "habr" has been upgraded. Happy Helming! LAST DEPLOYED: Fri Aug 31 15:21:08 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 3m habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 3m ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 4 2 0 3m ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 3m ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 3m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-66f4fd6b74-gqwhh 0/1 Pending 0 0s habr-wordpress-66f4fd6b74-mf6vj 0/1 Pending 0 0s habr-wordpress-7955b95fd-hh7b9 1/1 Running 2 3m habr-wordpress-7955b95fd-tgsxk 1/1 Running 2 3m habr-wordpress-7955b95fd-xjz74 0/1 Terminating 2 3m habr-mariadb-0 1/1 Running 0 3m ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 3m habr-wordpress Opaque 2 3m ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 3m habr-mariadb 1 3m habr-mariadb-tests 1 3m NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
Bitte beachten Sie, dass Tiller
beim Aktualisieren das empfangene Diagramm mit den Parametern mit dem zuletzt gespeicherten vergleicht und die entsprechenden Anforderungen in der Kubernetes-API ausführt und der
aktuelle Status der Release-Ressourcen nicht berücksichtigt wird . Es ist wichtig, diese Funktion zu verstehen und keine Fehler zu machen:
- Das Update unterscheidet sich nicht von der Installation: Der Helm-Client sendet das Pinnen-Diagramm zusammen mit den Parametern. Sie müssen also vorsichtig sein und die Parameter und Dateien mit den Parametern angeben, die während der Installation (oder während des vorherigen Updates) festgelegt wurden und die nicht ignoriert werden sollten. Im obigen Beispiel ist dies
--set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml . - Anwendungen, die mit Helm eingeführt werden, sollten nur mit Helm bedient werden: Manuelle Änderungen, die mit
kubectl werden, werden von Helm nicht berücksichtigt und können zu irreversiblen Konsequenzen führen.
Daher die logische Schlussfolgerung: Der
Prozess sollte automatisiert werden , und Änderungen sollten nur durch Festschreiben an das Git-Repository, Ändern der Diagrammdateien und der CI-Konfigurationsdatei durchgeführt werden.
Der Status von Anwendungsfreigabekomponenten in einem Cluster kann immer wie folgt überprüft werden:
$ helm status habr LAST DEPLOYED: Fri Aug 31 15:21:08 2018 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Secret NAME TYPE DATA AGE habr-mariadb Opaque 2 4m habr-wordpress Opaque 2 4m ==> v1/ConfigMap NAME DATA AGE habr-mariadb-init-scripts 1 4m habr-mariadb 1 4m habr-mariadb-tests 1 4m ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE habr-mariadb ClusterIP 10.111.7.232 <none> 3306/TCP 4m habr-wordpress ClusterIP 10.106.129.88 <none> 80/TCP,443/TCP 4m ==> v1beta1/Deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE habr-wordpress 3 4 2 3 4m ==> v1beta1/StatefulSet NAME DESIRED CURRENT AGE habr-mariadb 1 1 4m ==> v1beta1/Ingress NAME HOSTS ADDRESS PORTS AGE wordpress.local-habr wordpress.local 80, 443 4m ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE habr-wordpress-66f4fd6b74-gqwhh 0/1 Pending 0 1m habr-wordpress-66f4fd6b74-mf6vj 1/1 Running 0 1m habr-wordpress-7955b95fd-hh7b9 1/1 Running 3 4m habr-wordpress-7955b95fd-tgsxk 1/1 Running 3 4m habr-mariadb-0 1/1 Running 1 4m NOTES: 1. Get the WordPress URL: You should be able to access your new WordPress installation through https://wordpress.local/admin 2. Login with the following credentials to see your blog echo Username: user echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
Mit Helm können Sie zu
einer bestimmten Release-Version zurückkehren . Derzeit gibt es zwei Revisionen:
$ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 DEPLOYED wordpress-2.1.10 Upgrade complete
Setzen Sie die Anwendung auf den ursprünglichen Zustand zurück:
$ helm rollback habr 1 Rollback was a success! Happy Helming!
Jetzt wurde der Revisionsverlauf mit einem Datensatz ergänzt:
$ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 SUPERSEDED wordpress-2.1.10 Upgrade complete 3 Fri Aug 31 15:25:06 2018 DEPLOYED wordpress-2.1.10 Rollback to 1
Der Artikel neigt sich dem Ende zu und wird nicht mehr benötigt?
$ helm delete habr release "habr" deleted
Wird es wirklich gelöscht?
Der Befehl entfernt die mit der Version verbundenen Kubernetes-Ressourcen, nicht jedoch die Version selbst . Alle Informationen zur Veröffentlichung bleiben verfügbar, einschließlich des Verlaufs:
$ helm list --all NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE habr 3 Fri Aug 31 15:25:06 2018 DELETED wordpress-2.1.10 4.9.8 default
$ helm history habr REVISION UPDATED STATUS CHART DESCRIPTION 1 Fri Aug 31 15:17:57 2018 SUPERSEDED wordpress-2.1.10 Install complete 2 Fri Aug 31 15:21:08 2018 SUPERSEDED wordpress-2.1.10 Upgrade complete 3 Fri Aug 31 15:25:06 2018 DELETED wordpress-2.1.10 Deletion complete
Hinweis : Wie geplant kann die Remote-Version auf frühere Versionen zurückgesetzt werden. In neueren Versionen funktioniert diese Funktion jedoch nicht. Weitere Informationen finden Sie in Ausgabe 3722 .Verwenden Sie die Option
--purge um die Version vollständig zu entfernen:
$ helm delete --purge habr release "habr" deleted
Zusammenfassen
Dieser Artikel befasst sich mit der grundlegenden Architektur von Helm 2, seinen Komponenten und ihren Funktionen sowie den grundlegenden Grundelementen, Diagrammen, Releases und Diagrammrepositorys. Wir haben Helm im Kubernetes-Cluster installiert und uns ein Bild über den Release-Lebenszyklus und die grundlegenden Befehle für die Arbeit damit gemacht.
Das folgende Material aus dieser Reihe widmet sich dem Thema des
Erstellens eines eigenen Diagramms. Darin werde ich auf die Struktur des Diagramms, die Standardisierungs- und Debugging-Tools eingehen.
AKTUALISIERT : Ein neuer Artikel ist unter
diesem Link verfügbar.
PS