Hallo,
Ich liebe die Grundidee des Helm-Templating wirklich. Also habe ich beschlossen, es für ein Projekt zu verwenden. Aber manche Dinge sind immer noch sehr schwer zu bekommen.
Wo platzieren Sie beispielsweise die analysierten Ergebnisse, nachdem Sie meine Vorlagen analysiert haben? Es ist so wichtig, wenn Sie einen Parser für irgendetwas haben, dass Sie die Ergebnisse anzeigen können, um zu sehen, was der Parser möglicherweise anders gemacht hat als erwartet.
Wo kann ich sehen, welche http-Anfragen der Helm sendet (URL + Text)? Ich habe hier keine Standardinstallation von Kubernetes und muss sicherstellen, dass auch andere den Pinnenservice erreichen können. Vielleicht hilft das Anzeigen einiger http-Antworten auch beim Debuggen.
Was ist der Unterschied zwischen dem Argument --namespace
und der Umgebungsvariablen $TILLER_NAMESPACE
? Aus irgendeinem Grund kann ich Helm nur verwenden, wenn ich die zweite Version mache. Und ich hatte nichts über das Problem zu erzählen. Es war ein dummer Versuch und Irrtum. Wäre wirklich schön, wenn es eine intelligentere Möglichkeit zum Debuggen gäbe.
Und warum entfernt ein helm delete --purge <name>
nicht alles? Zum Beispiel gibt es in meiner Umgebung immer ein Servicekonto, das danach noch existiert.
Vielen Dank!
@erikbgithub Vielen Dank, dass Sie Helm verwenden. Hoffentlich können wir Ihre Probleme lösen. Um die analysierten Ergebnisse der Vorlagen zu sehen, können Sie das Flag --debug
hinzufügen, um die endgültige Ausgabe anzuzeigen. Wenn Sie auch das Flag --dry-run
zusammen mit --debug
hinzufügen, können Sie die Ausgabe sehen, ohne sie tatsächlich zu installieren.
Helm verwendet gRPC nicht REST, sodass Sie keine Anfragen an Tiller sehen können, wie Sie es in herkömmlichen REST-Anwendungen gewohnt sind.
--namespace
weist Helm an, Ihr Diagramm im angegebenen Namespace zu installieren.
TILLER_NAMESPACE bezieht sich auf den Namespace, in dem die Backend-Komponente Tiller installiert ist (standardmäßig "kube-system").
Ich hoffe, das hilft. Bitte lassen Sie uns wissen, wenn Sie weitere Fragen haben.
Hallo jascott1, danke für die Antwort.
Ich bin nicht sicher, ob die Namespace-Frage vollständig ist. Weil ich beides in einer separaten Sitzung mache, nachdem helm init
bereits an einem anderen Tag erfolgreich war.
Beispiel. Nehmen wir an, Sie beginnen den Tag mit einer neuen Bash-Sitzung, in der keine Steuerumgebung festgelegt ist. Pinne ist bereits im Einsatz. Jetzt machst du nur noch ein helm ls --namespace=foobar
und es schlägt fehl. Jetzt setzen Sie export TILLER_NAMESPACE=foobar
und jetzt ist helm ls
ohne Namespace-Flag erfolgreich. Würden Sie zustimmen, dass die Situation nicht durch Ihre Antwort erklärt wird?
Nein, ich kann die Anweisungen von @ jascott1 ganz klar verstehen (aber
helm list
mit --namespace
zeigt Diagramme, die in diesem Namespace veröffentlicht wurden. Es sagt nicht, welcher Namespace-Helm nach Pinne suchen soll.
TILLER_NAMESPACE=foobar helm list
weist das Ruder an, mit der im Namespace foobar
installierten Pinneninstanz zu kommunizieren, um alle in allen Namespaces installierten Releases aufzulisten.
Ich kann die Verwirrung jedoch verstehen. TILLER_NAMESPACE ist hier dokumentiert:
Helm sucht im Namespace
kube-system
nach Tiller, es sei denn,--tiller-namespace
oder$TILLER_NAMESPACE
ist festgelegt.
Hilft das, die Dinge zu klären? Wenn nicht, empfehle ich dringend, einen Blick in den Abschnitt Verwenden des Helms in den Dokumenten zu werfen, um ein klareres Bild zu erhalten.
Ah, jetzt verstehe ich. Vielen Dank!