Heaume sans battage médiatique. Look sobre
Helm est un gestionnaire de packages pour Kubernetes.
À première vue, pas mal. Cet outil simplifie considérablement le processus de publication, mais parfois il peut être compliqué, vous ne ferez rien!
Récemment, Helm a été officiellement reconnu comme le meilleur projet @CloudNativeFdn , il est largement utilisé par la communauté. Cela en dit long, mais je voudrais parler brièvement des moments désagréables associés à ce gestionnaire de paquets.
Quelle est la vraie valeur de Helm?
Je ne peux toujours pas répondre à cette question avec confiance. Helm ne fournit aucune fonctionnalité spéciale. Quels sont les avantages de Tiller (côté serveur)?
De nombreux graphiques Helm sont loin d'être parfaits et des efforts supplémentaires sont nécessaires pour les utiliser dans le cluster Kubernetes. Par exemple, ils manquent de RBAC, de limites de ressources et de stratégies réseau. Le simple fait de saisir et d'installer le graphique Helm sous forme binaire - sans penser à la façon dont cela fonctionnera - ne fonctionnera pas.
Il ne suffit pas de louer Helm, en donnant les exemples les plus simples. Vous expliquerez pourquoi il est si bon - en particulier en termes d'un environnement de travail multi-locataire sûr.
Les mots sont vides. Montrez-moi le code!
—Linus Torvalds
Un niveau supplémentaire d'autorisation et de contrôle d'accès
Je me souviens que quelqu'un comparait Tiller à un "énorme serveur sudo". À mon avis, ce n'est que le prochain niveau d'autorisation, qui nécessite en même temps des certificats TLS supplémentaires, mais ne fournit pas de capacités de contrôle d'accès. Pourquoi ne pas utiliser l'API Kubernetes et le modèle de sécurité existant avec prise en charge de l'audit et du RBAC?
Un outil de traitement de modèle surfait?
Le fait est que pour le traitement et l'analyse statique des fichiers de modèle Go, la configuration du fichier values.yaml est values.yaml , puis le manifeste Kubernetes traité est utilisé avec les métadonnées correspondantes stockées dans ConfigMap.
Et vous pouvez utiliser quelques commandes simples:
$ # render go-template files using golang or python script $ kubectl apply --dry-run -f . $ kubectl apply -f .
J'ai remarqué que les développeurs utilisaient généralement un fichier values.yaml par environnement, ou même l'avaient obtenu de values.yaml.tmpl avant utilisation.
Cela n'a aucun sens lorsque vous travaillez avec des secrets Kubernetes, qui sont souvent chiffrés et ont plusieurs versions dans le référentiel. Pour contourner cette limitation, vous devrez utiliser le plugin helm-secrets ou la commande --set key=value . Dans tous les cas, un autre niveau de complexité est ajouté.
Helm comme outil de gestion du cycle de vie de l'infrastructure
Oubliez ça. Ce n'est pas possible, surtout si nous parlons des principaux composants de Kubernetes, tels que kube-dns, le fournisseur CNI, l'autoscaler de cluster, etc. Les cycles de vie de ces composants varient et Helm ne s'y adapte pas.
Mon expérience avec Helm montre que cet outil est idéal pour les déploiements simples sur les ressources de base de Kubernetes, facilement mis en œuvre à partir de zéro et sans processus de publication compliqué.
Malheureusement, avec des déploiements plus complexes et plus fréquents, notamment Namespace, RBAC, NetworkPolicy, ResourceQuota et PodSecurityPolicy, Helm ne peut pas faire face.
Je comprends que les fans de Helm peuvent ne pas aimer mes mots, mais c'est la réalité.
Heaume d'État
Le serveur Tiller stocke les informations dans des fichiers ConfigMap à l'intérieur de Kubernetes. Il n'a pas besoin de sa propre base de données.
Malheureusement, la taille de ConfigMap ne peut pas dépasser 1 Mo en raison des limitations etcd .
J'espère que quelqu'un trouvera un moyen d'améliorer le pilote de stockage ConfigMap pour compresser la version sérialisée avant de passer au stockage. Cependant, je pense que le vrai problème ne peut toujours pas être résolu.
Crashes aléatoires et gestion des erreurs
Pour moi, le plus gros problème de Helm est son insécurité.
Erreur: ÉCHEC DE LA MISE À NIVEAU: "foo" n'a pas de versions déployées
Ceci, à mon humble avis, est l'un des problèmes les plus ennuyeux de Helm.
S'il n'a pas été possible de créer la première version, chaque tentative ultérieure échouera avec une erreur indiquant l'impossibilité de mettre à jour à partir d'un état inconnu.
La demande suivante pour activer les modifications «corrige» l'erreur en ajoutant l'indicateur --force , qui masque simplement le problème en exécutant la helm delete & helm install —replace .
Cependant, dans la plupart des cas, vous devrez effectuer un nettoyage complet de la version.
helm delete --purge $RELEASE_NAME
Erreur: échec de la libération de foo: délai d'attente dépassé pour la condition
Si ServiceAccount est manquant ou que RBAC n'autorise pas la création d'une ressource spécifique, Helm renvoie le message d'erreur suivant:
Error: release foo failed: timed out waiting for the condition
Malheureusement, la cause première de cette erreur n'est pas visible:
kubectl -n foo get events --sort-by='{.lastTimestamp}'
Error creating: pods "foo-5467744958" is forbidden: error looking up service account foo/foo: serviceaccount "foo" not found
Échouer à l'improviste
Dans les cas les plus avancés, Helm lance une erreur sans effectuer aucune action. Par exemple, parfois, il ne met pas à jour les limites de ressources.
helm init exécute tiller avec une copie, pas en configuration HA
Tiller par défaut n'implique pas une haute disponibilité et la demande d'activation des modifications par référence est toujours ouverte.
Un jour, cela entraînera des temps d' arrêt ...
Heaume 3? Des opérateurs? L'avenir?
La prochaine version de Helm ajoutera des fonctionnalités prometteuses:
- architecture à service unique sans séparation entre le client et le serveur. Plus de motoculteur;
- moteur de script Lua intégré;
- Flux de travail DevOps basé sur les demandes d'inclusion et le nouveau projet Helm Controller.
Voir les propositions de projet Helm 3 pour plus d'informations.
J'aime vraiment l'idée d'architecture sans Tiller, mais les scripts basés sur Lua sont dans le doute, car ils peuvent compliquer les graphiques.
J'ai remarqué que récemment, les opérateurs qui sont beaucoup plus adaptés à Kubernetes que les cartes Helm ont gagné en popularité.
J'espère vraiment que la communauté s'occupera bientôt des problèmes de Helm (avec notre aide, bien sûr), mais pour l'instant j'essaierai moi-même d'utiliser cet outil le moins possible.
Comprenez ceci: cet article est mon opinion personnelle, à laquelle je suis arrivé lors de la création d'une plateforme cloud hybride pour les déploiements basés sur Kubernetes.