Cet article est la suite logique de notre
récente publication sur l'histoire du gestionnaire de paquets pour Kubernetes -
Helm . Cette fois, nous aborderons à nouveau les problèmes de l'appareil et du fonctionnement de la
version actuelle de Helm (
version 2.x ), ainsi que ses graphiques et référentiels gérés, après quoi nous passerons à la pratique d'installation de Helm dans le cluster Kubernetes et d'utilisation des graphiques.
Entrée
Helm est un outil de gestion des graphiques.Le graphique décrit l'ensemble de données nécessaire pour instancier l'application dans le cluster Kubernetes. Il peut avoir des graphiques intégrés et peut être utilisé à la fois pour décrire des services à part entière, composés de nombreuses ressources dépendantes, et pour décrire des composants indépendants individuels. Par exemple, le graphique
stable / gitlab-ce décrit une solution complète
utilisant les graphiques redis et postgresql indépendants.
Un graphique peut être défini un nombre illimité de fois dans le même cluster. Ainsi, la description de la logique de déploiement de l'application dans différents environnements peut et doit être stockée sur le même graphique.
Le côté client de Helm est responsable de la création du graphique et du transfert du composant
Tiller vers le cluster Kubernetes avec les paramètres utilisateur. À son tour, Tiller est responsable du cycle de vie de l'instance du graphique lancé, version.
(Juste au cas où, laissez-moi vous rappeler que la prochaine mise à jour majeure de Helm - version 3 - n'aura plus Tiller.)Et maintenant - tout d'abord.
Installation et mise à niveau
Helm nécessite que Kubernetes fonctionne. Vous pouvez utiliser un
Minikube installé localement
(voir également « Mise en route dans Kubernetes avec Minikube ») ou tout autre cluster disponible.
Commençons par installer le client: sélectionnez la
version , téléchargez et décompressez l'archive de votre système, transférez le fichier exécutable ...
$ 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
Ensuite, installez Tiller dans le cluster. Par défaut, Tiller est installé dans le
kubectl contexte kubectl (
kubectl config current-context ), dans l'
espace de noms kube-system , mais cela peut être modifié à l'aide des options et variables d'environnement appropriées - elles sont décrites dans l'aide (
helm init --help ). Terminons l'installation et examinons les ressources créées dans le cluster:
$ 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
Maintenant, Tiller est installé dans le cluster et est prêt pour la gestion des versions, l'interaction avec l'API Kubernetes.
Remarque : Pendant l'installation et la mise à niveau (option --upgrade ) de Tiller, vous pouvez spécifier une image spécifique au lieu d'utiliser la dernière version stable par défaut. Le nom d'une image arbitraire est déterminé par l'option --tiller-image , et avec l'option --canary-image , une --canary-image sera utilisée lors du déploiement de Tiller. L'image canari vous permet d'utiliser Tiller, dont la version de code correspond à la branche maître.Les données de service sont stockées dans un cluster dans des ressources spéciales,
ConfigMaps , donc la désinstallation et la réinstallation de Tiller n'entraîne pas la perte de données des versions précédemment installées.
Référentiels de graphiques
Chart Repository - Un serveur HTTP pour stocker et distribuer des graphiques. Les informations sur les graphiques dans le référentiel sont stockées dans le fichier
index.yaml . Il indique également d'où chaque graphique peut être chargé. Le plus souvent, les graphiques sont stockés avec le fichier
index.yaml , mais rien ne les empêche d'être placés sur un autre serveur. Habituellement, la structure du fichier se résume à une forme plate:
. ├── index.yaml ├── artifactory-7.3.0.tgz ├── docker-registry-1.5.2.tgz ... └── wordpress-2.1.10.tgz
Par défaut, Helm utilise le
référentiel de graphiques Kubernetes officiel . Il contient des graphiques actuels soigneusement conçus pour résoudre de nombreux problèmes appliqués. Ce référentiel est appelé
stable :
$ helm repo list NAME URL stable https://kubernetes-charts.storage.googleapis.com
Si nécessaire, la
création de votre propre référentiel ne posera aucun problème. Les exigences du serveur sont minimales, donc, comme la plupart des référentiels de graphiques publics, il peut être hébergé sur des pages GitHub. Vous pouvez en savoir plus sur les outils et les étapes nécessaires à cet effet dans la
documentation .
Lorsque vous utilisez des référentiels de graphiques, ils peuvent être ajoutés et supprimés. Afin de maintenir les versions des graphiques à jour, vous devez mettre à jour périodiquement l'index. Je vais donner un exemple pour le dépôt public
bitnami , dont la plupart des graphiques sont utilisés dans le dépôt officiel Helm:
$ 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
Suivant -
recherchez dans les référentiels. Un appel de
helm search sans arguments affiche tous les graphiques disponibles:
$ 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
Dans le champ de
keywords facultatif de
Chart.yaml développeurs spécifient les balises utilisées pour simplifier la recherche dans les référentiels de graphiques:
$ 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
Remarque: Lorsque vous utilisez la helm search , vous pouvez rencontrer un fonctionnement instable de plusieurs filtres: la disponibilité du résultat dépend de l'ordre d'indication et du nombre de filtres.Une fois le cercle de recherche restreint à plusieurs options, vous pouvez procéder à une analyse plus détaillée des graphiques - à l'aide de la
helm inspect . Il affiche le contenu des fichiers graphiques
Chart.yaml ,
values.yaml et
README.md . Chaque section peut être affichée individuellement avec les arguments correspondants:
chart ,
values et
readme -
readme .
Dans le référentiel officiel, les graphiques sont magnifiquement documentés et contiennent des exemples d'utilisation, et certains graphiques ont même des configurations prêtes à l'emploi pour la
production . Par exemple, un bon
readme est fourni par
stable / wordpress (pour sa sortie dans la console, voir helm inspect readme stable/wordpress ) .
La recherche est un bon moyen de trouver des forfaits abordables. Une fois le package trouvé, vous pouvez l'utiliser pour installer l'application dans le cluster.
Première application
Par exemple, le graphique
stable / wordpress déjà mentionné est sélectionné.
Il utilise les paramètres décrits dans le fichier
values.yaml . Vous pouvez remplacer les paramètres d'un fichier YAML puis transférer ce fichier lors de l'installation (options
-f ,
--values ). De plus, ils peuvent être remplacés directement sur la ligne de commande (options
--set ,
--set-string et
--set-file ). Toutes les options sont disponibles pour être utilisées un nombre arbitraire de fois; en même temps, la substitution sur la ligne de commande est prioritaire sur les fichiers avec paramètres.
Lorsque vous définissez le graphique, vous pouvez définir le nom de la version avec l'option
--name ou utiliser le nom aléatoire généré par Helm.
Définissez le tableau de
configuration pour la production , modifiez le nom du blog, désactivez l'enregistrement des données WordPress dans
PersistentVolumeClaim (pour plus d'informations sur le stockage persistant, consultez la documentation de Kubernetes ) :
$ 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)
Dans le cas de travailler avec un cluster à part entière, vous pouvez suivre les recommandations du bloc
NOTES ci-dessus. Si vous avez Minikube, ouvrez le site dans un navigateur comme suit:
$ minikube service habr-wordpress Waiting, endpoint for service is not ready yet... Opening kubernetes service default/habr-wordpress in default browser...
Félicitations, l'application est dans un cluster!
Un tableau détaillé avec WordPress est apparu dans la liste de toutes les versions de Helm:
$ 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
La prochaine étape consiste à mettre à jour notre version et à changer l'image avec le blog. Par exemple, une autre balise du même référentiel Docker (
4.9.8-ol-7 ) sera utilisée:
$ 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)
Veuillez noter que
lors de la mise à jour Tiller compare le graphique reçu avec les paramètres avec le dernier enregistré et exécute les requêtes correspondantes dans l'API Kubernetes, et l'
état actuel des ressources de publication n'est pas pris en compte . Il est important de comprendre cette fonctionnalité et de ne pas faire d'erreurs:
- La mise à jour n'est pas différente de l'installation: le client Helm envoie le graphique Tiller avec les paramètres, vous devez donc être prudent et n'oubliez pas de spécifier les paramètres et les fichiers avec les paramètres qui ont été définis lors de l'installation (ou lors de la mise à jour précédente) et qui ne doivent pas être ignorés. Dans l'exemple ci-dessus, il s'agit de
--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 . - Les applications déployées à l'aide de Helm doivent uniquement être traitées à l'aide de Helm: les modifications manuelles effectuées à l'aide de
kubectl ne seront pas prises en compte par Helm et peuvent entraîner des conséquences irréversibles.
D'où la conclusion logique: le
processus doit être automatisé , et les modifications doivent être effectuées uniquement en validant le référentiel Git, en modifiant les fichiers de graphique et le fichier de configuration CI.
L'état des composants de version d'application dans un cluster peut toujours être vérifié comme suit:
$ 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)
Helm vous permet de
revenir à une révision de version spécifique . Il existe actuellement deux révisions:
$ 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
Restaurez l'application à son état d'origine:
$ helm rollback habr 1 Rollback was a success! Happy Helming!
Maintenant, l'historique des révisions a été reconstitué avec un enregistrement:
$ 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
L'article touche à sa fin et la sortie n'est plus nécessaire?
$ helm delete habr release "habr" deleted
Est-il vraiment supprimé? ..
La commande supprime les ressources Kubernetes associées à la version, mais pas la version elle-même . Toutes les informations sur la version restent disponibles, y compris son historique:
$ 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
Remarque : Comme prévu, la version à distance peut être restaurée vers les versions précédentes, mais dans les versions récentes, cette fonctionnalité ne fonctionne pas - voir le problème # 3722 pour plus de détails.Pour supprimer complètement la version, utilisez l'option
--purge :
$ helm delete --purge habr release "habr" deleted
Résumer
Cet article décrit l'architecture de base de Helm 2, ses composants et leurs fonctions, ainsi que les primitives de base, les graphiques, les versions et les référentiels de graphiques. Nous avons installé Helm dans le cluster Kubernetes et acquis une compréhension du cycle de vie des versions et des commandes de base pour travailler avec.
Le matériel suivant de cette série sera consacré au sujet de la
création de votre propre graphique - j'y parlerai de la structure du graphique, des outils de normalisation et de débogage.
MISE À JOUR : Un nouvel article est disponible sur
ce lien .
PS