Helm: Informationen erhalten

Erstellt am 24. Aug. 2017  ·  4Kommentare  ·  Quelle: helm/helm

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!

questiosupport

Alle 4 Kommentare

@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!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen