Helm: Scoping gibt Namen für Namespaces frei

Ich bin mir nicht sicher, ob ich dich verstehe. Sie möchten in mehreren Namespaces bereitstellen, während Sie nur einen Releasenamen haben?

@21stio Genau. aus den Kubernetes-Dokumenten:

Kubernetes unterstützt mehrere virtuelle Cluster, die von demselben physischen Cluster unterstützt werden. Diese virtuellen Cluster werden Namespaces genannt.

und

Namespaces bieten einen Bereich für Namen. Namen von Ressourcen müssen innerhalb eines Namespace eindeutig sein, jedoch nicht über Namespaces hinweg.

Ich persönlich kann mir keinen guten Grund vorstellen, warum helm dieses Konzept von Namespaces nicht respektieren würde.

Ich stimme zu. Alle meine Namespaces haben die Form ${site}-${environment} , aber meine Releases sind ${site}-${environment}-${description} . Wobei site internal oder www und environment dev , staging oder team-a , team-b und description könnten etwa nginx , migrations , cache usw. sein.

Aber das ${site}-${environment} ist extrem überflüssig:

NAMESPACE                    NAME
www-dev                     www-dev-redis-1234567890-cj241
www-dev                     www-dev-proxy-1234567890-kfd44
www-staging                 www-staging-redis-1234567890-cj241
www-staging                 www-staging-proxy-9876543210-kfd44
internal-team-b             internal-team-b-redis-1234567890-cj241
internal-team-b             internal-team-b-nginx-1234567890-cj241

Ist das, was ich am Ende habe, aber ich würde es vorziehen, wenn die Schoten nur redis-1234567890.. oder proxy-9876543210..

Ich verwende meinen Release-Namen in meiner Diagrammvorlage, daher enthalten alle meine Service- und Pod-Namen all diese zusätzlichen Dinge. Ich übergebe den Namespace bereits an die Vorlagen, also könnte ich ihn, wenn ich wollte, problemlos in den Namen aufnehmen, aber so wie er jetzt ist, ist er Teil aller meiner Ressourcennamen, indem ich das Standard-Helm-Gerüst verwende.

K8s Namespaces sind für uns bereits Namespaces, ich mag es wirklich nicht, all meinen Dingen den Namespace voranzustellen, wenn Namespaces entworfen sind, um Konflikte zu vermeiden.

Explizit, es wäre wirklich schön, wenn ich die gleichen Dinge tun könnte, die ich mit Diensten und anderen nativen k8-Typen mit Helmdiagrammen in Bezug auf den Namensraum tun könnte.

Zum Beispiel möchte ich in der Lage sein, Folgendes zu tun:

helm install --namespace abc --name redis stable/redis
helm install --namespace def --name redis stable/redis

@Janpot @bcorijn Die oben

Was ist mit Ressourcen von Drittanbietern, die keinen Namespace haben? Oder RBACs, bei denen "Namespace" ein Richtlinienattribut ist, kein Standort (https://kubernetes.io/docs/admin/authorization/)?

Ich weiß, dass ich es an anderer Stelle mehrmals gesagt habe, aber unser ultimatives Ziel ist es, die Bereitstellung von Ressourcen in mehreren Namespaces aus demselben Diagramm zu ermöglichen. (Anwendungsfall: Eine App verfügt über eine Steuerungsebene und eine Datenebene, die Sie jeweils in separaten Namespaces bereitstellen möchten, um Sicherheitsgrenzen zu schaffen.)

Wenn wir ein Release an einen Namespace binden, verlieren wir die Fähigkeit:

1. Namespaces direkt verwalten
2. RBACs und Dienstkonten verwalten
3. Verwalten von TPRs (und allen anderen Objekten ohne Namensraum)
4. Unterstützen Sie schließlich Multi-Namespace-Diagramme.

Ich verstehe, dass dies das Benennungsproblem für Sie etwas schwieriger macht, aber es ermöglicht Helm, mit einer viel breiteren Palette von Kubernetes-Ressourcen zu arbeiten.

Wäre es möglich, sowohl Namespace- als auch Nicht-Namespace-Releases zu unterstützen?

@technosophos Zusammenfassend gibt es zwei Haupttreiber:
1) Verwalten von Ressourcen ohne Namespace
2) Zukünftige Pläne, die Installation von Diagrammen im Namensraum zuzulassen

Ich verstehe Ihren Standpunkt, aber ich bin mir nicht sicher, ob dies ein Grund ist, an der aktuellen Implementierung festzuhalten, da ich den Eindruck habe, dass Sie es auch etwas forcieren müssen, um diese Bedenken auszuräumen?

Damit Multi-Namespace-Diagramme gut/nativ funktionieren, benötigen Sie höchstwahrscheinlich eine gründliche Überarbeitung des Namespace-Systems, da das aktuelle Konzept, dass Helm Releases in einen Namespace einfügt, nicht funktioniert? _EDIT: Habe gerade festgestellt, dass ein Multi-Namespace-Diagramm, wenn Releases tatsächlich Namespaces haben, nur ein Umbrella-Diagramm sein könnte, das zwei Releases mit einem anderen Namespace enthält?_

Zum Verwalten von Ressourcen ohne Namespace; Ich habe keine persönliche Erfahrung damit, daher ist es etwas schwer zu beurteilen, aber ich habe wieder das Gefühl, dass dies Helm zu einer nicht ganz perfekten Arbeitsweise zwingt, da ein Release, das Namespaces, RBAC oder TPRs verwaltet, einen Namespace haben wird aber einfach ignorieren?
Vielleicht übersehe ich einfach etwas, weil ich keine Erfahrung mit ihnen habe, aber würde das Nichtbeachten der Namen und das Ignorieren des Namespace nicht das gleiche Endergebnis haben, würde es dem Benutzer nur mehr Verantwortung auferlegen, zu überprüfen, ob seine Release-Namen und -Selektoren korrekt sind richtig/einzigartig im Umgang mit diesen Ressourcen. (was ich zustimme, liegt in der Verantwortung)

Es ist also vielleicht nicht der richtige Weg, Veröffentlichungen nur auf den Umfang zu beschränken, aber es lohnt sich, noch einmal einen Blick auf die Art und Weise zu werfen, wie sie in Helm gehandhabt werden und in Zukunft gehandhabt werden? Beide Optionen, wie @Janpot erwähnt, könnten funktionieren, "globale" Releases und Namespace-Releases?
Meine _sehr persönliche_ Meinung ist auch, dass die Bereitstellung auf die oben beschriebene Weise von @kylebyerly-hp, @chancez und mir viel häufiger vorkommt als die beiden Anwendungsfälle, die diese Arbeitsweise verhindern.

Lassen Sie mich zunächst den Hauptpunkt wiederholen: Helm-Diagramme arbeiten auf globaler Ebene, nicht auf Namespace-Ebene. Ihre Namen sind daher weltweit einzigartig.

Was wir bei Diagrammen mit mehreren Namespaces beheben müssen, ist die Fähigkeit von Tiller, über Namespaces hinweg abzufragen. (Sie können jetzt Charts mit mehreren Namespaces _installieren_. Sie können sie nur nicht zuverlässig aktualisieren oder löschen, weil Tiller sie nicht zuverlässig abfragen kann).

Bei Elementen ohne Namensraum würden die Dinge sehr kompliziert. Wir hätten Namespace-Releases, die Dinge ohne Namespace verwalten, die sich wiederum auf andere Namespaces auswirken könnten. Sehen Sie sich an, wie RBACs und TPRs funktionieren. Dies sind keine Dinge, die Helm einfach nicht unterstützen kann, und das "Fälschen" eines Namespace würde mehr Probleme verursachen, als es wert ist, insbesondere bei RBACs.

Ich habe immer noch keinen guten Grund gesehen, einen Release-Namen zu benennen. Ihre anfänglichen Beschwerden basieren auf einem Missverständnis, dass alle (wichtigen) Dinge in Kubernetes einem Namensraum zugeordnet sind. Aber wichtige Dinge wie TPRs und RBACs sind es nicht. Der Großteil der anderen Beschwerden scheint sich eher auf die Tatsache zu beziehen, dass die von ihnen verwendeten _ad-hoc_-Namensschemata bei Helm "nicht schön" sind. Dies zu umgehen, indem eine RIESIGE kompatibilitätsbrechende Änderung erstellt wird, die Releases falsch als "in einem Namespace" darstellt, scheint der falsche Ansatz zu sein.

@technosophos

Sie können jetzt tatsächlich Diagramme mit mehreren Namespaces installieren

Wie? Wo sollte der Begriff zu Namespaces in die Konfiguration eingefügt werden?

Planen Sie, Multi-Namespace-Releases offiziell zu unterstützen?

Wir planen nicht, Releases mit mehreren Namespaces bis Helm 3.0 vollständig zu unterstützen, da dies die Abwärtskompatibilität beeinträchtigt und eine umfassende Überarbeitung eines Großteils des Kubernetes-Codes von Helm/Tiller erfordert.

Leider ist es für uns ein Deal-Breaker, mehrere Namespaces mit helm nicht bereitzustellen und zu verwalten.

Unser Plan war es, ein Dachdiagramm zu erstellen, das alle unsere Apps (zB kleinere Diagramme) als Abhängigkeiten enthält. Alle unsere Apps leben in ihren eigenen Namespaces, dies war beabsichtigt (in Zukunft möchten wir RBAC pro Namespace haben). Mit einem Umbrella-Diagramm könnten wir ganze Cluster verschiedener Microservices gleichzeitig installieren und aktualisieren, wenn nur ein values.yml , was wirklich praktisch wäre.

@technosophos , danke. Beachten Sie die Tatsache, dass die Unterstützung für das oben Genannte nicht bald eintreffen wird, zumindest nicht vor Helm 3.0.

Gibt es eine allgemeine Vorstellung davon, was genau in Helm/Tiller umgestaltet werden muss, um mehrere Namespaces zu unterstützen? Oder ist 3.0 zu weit weg?

Wir haben den Helm name eher als UUID behandelt, indem wir --name-template und einen einfachen, aber zufälligen Namen generiert haben. Ich kann nicht sagen, dass ich dies der Respektierung des Namespace selbst vorziehe, aber ich sehe beide Punkte und für uns wird dies mit minimalem Overhead ausreichen.

zB https://github.com/kubernetes/helm/pull/1015#issuecomment -237309305

> helm install --namespace www-dev --name-template "{{randAlpha 6 | lower}}" stable/redis

> kubectl --namespace www-dev get pods
NAME                                    READY     STATUS    RESTARTS   AGE
uvtiwh-redis-4101942544-qdvtw           1/1       Running   0          14m

> helm list --namespace www-dev
NAME    REVISION        UPDATED    STATUS          CHART                   NAMESPACE
uvtiwh  1               ...        DEPLOYED        redis-0.8.0             www-dev

@icereval wie finden Sie den Namen für redis (uvtiwh) in Ihren Apps, um sich damit zu verbinden?

Ein Muster, das ich in Erwägung ziehe, in unseren Clustern zu verwenden, ist:

• Eine Tiller-Instanz in kube-system , die von Cluster-Administratoren verwendet wird
• Eine Tiller-Instanz pro Namespace mit eingeschränkteren RBAC-Berechtigungen zur Verwendung durch das Entwicklerteam, das diesen Namespace besitzt

Das Designprinzip "Helm-Releasenamen sind global eindeutig" bereitet Soft-Multi-Tenant-Bereitstellungen wie unserer Kopfschmerzen, daher bin ich daran interessiert, mehr über den empfohlenen Ansatz zu erfahren!

Ich war sehr enttäuscht, als ich herausfand, dass Helm sich nicht an das Konzept hält, Releases anhand ihres Namens und Namensraums zu identifizieren. Meiner Meinung nach folgt dies nicht den Designprinzipien von Kubernetes, bei denen Ressourcen innerhalb ihres jeweiligen Namensraums eindeutig sind (mit Ausnahme einiger globaler Ressourcen).

Wie andere Poster in diesem Thread kommentiert haben, haben wir mehrere Namespaces mit Umgebungssuffixen für verschiedene Anwendungsgruppen. Wir haben Hunderte von verschiedenen Bereitstellungen in jeweils drei oder vier Umgebungen. Wir verlassen uns stark auf die eindeutigen DNS-Namen in Namespaces, damit wir auf Dienste mit demselben Namen in verschiedenen Namespaces verweisen können. z.B. Auf unseren Redis-Service kann über tcp://redis in beiden Namespaces a-test und a-prod zugegriffen werden, wobei beide Namespaces eine bereitgestellte Version von Redis haben.

Dies als Diskussionspunkt für Ruder 3 anvisieren. Es scheint, dass die Nachfrage dafür riesig ist.

Gegenteil:

So ziemlich alle unsere Diagrammbäume stellen Artefakte in mehreren Namespaces bereit, die entlang der Persistenz-/API-/Level7-ALB(+statisch)-Linien aufgeteilt sind. Von diesem Standpunkt aus LIEBE es die Tatsache, dass Helm-Release-Namen global sind.

Gefunden, dass die Option --namespace in helm vom Standpunkt der Zusammenstellung von mehrschichtigen Anwendungen halb nutzlos ist, wobei Basisschichten durch rot/blau eingesetzte obere Schichten wiederverwendet werden können. Anstatt {{ .Release.Name }} -derived strings in die Namen der Artefakte einzufügen, erstellen wir für jede Bereitstellung einen neuen Namespace. Dies ermöglicht es uns, deterministisch gebildete Dienst-URLs durch die verketteten Konfigurationen zu verbreiten ( same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ).

Da automatisch generierte Release-Namen sowieso Quatsch sind - keine Treue zu dem, was hinter diesem Ding in helm list , überschreiben wir --name hart mit einer Zeichenfolge, die aus dem Produkt-/Stack-Namen und dem monoton ansteigenden Release abgeleitet ist / build version ( "appname-v20171103xyz" ) Würde gerne den Wert von --name-template irgendwo im Diagramm definieren und einfach den Diagrammnamen + Datum/Uhrzeit abgeleiteten oder expliziten Build-ID-Wert verwenden.

Beispiel

Basis-Persistenzschicht

apiVersion: v1
kind: Service
metadata:
  name: redis
  namespace: {{ .Values.global.product }}-persistence-{{ .Values.global.tier }}
  labels:
    app: redis
    chart: "{{ .Chart.Name }}-{{ .Chart.Version }}"
    release: "{{ .Release.Name }}"
    heritage: "{{ .Release.Service }}"
...

Von einem anderen Namespace wie folgt konsumiert:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: {{ .Values.global.product }}
  namespace: {{ .Release.Name }}
  labels:
    app: {{ .Values.global.product }}
    chart: {{ .Chart.Name }}-{{ .Chart.Version | replace "+" "_" }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
...
          env:
            - name: REDIS_SERVER_HOSTNAME
----->      value: "redis.{{ .Values.global.product }}-persistence-{{ .Values.global.tier }}.svc.cluster.local"

Die obigen 2 Vorlagen sind Teile von 2 separaten Diagrammen (Persistenzdiagramm und API-Diagramm) und können separat oder gemeinsam durch ein drittes, übergreifendes Diagramm ausgeführt werden. In beiden Fällen werden durch die Verwendung von .global. die Werte einmal an der Kommandozeile überschrieben und gelten sauber für alle Sub-Charts.

Da der Ziel-Namespace-Wert bei diesem Ansatz manchmal eine teilweise Ableitung von ReleaseName ist und manchmal halbfest ist, verlassen wir uns ziemlich darauf, dass ReleaseName global ist, sodass sich das System beschweren würde, wenn wir versuchen, einen Stack mit demselben globalen ReleaseName zu erstellen.

Einer der Vorteile von Namespaces und deren Verwendung besteht darin, dass darin enthaltene Objektnamen (einschließlich DNS-Namen) lokal sind und sich nicht von Namespace zu Namespace ändern müssen. Insbesondere im obigen @ dvdotsenko- Beispiel sollte REDIS_SERVER_HOSTNAME gleich sein (zB nur redis ) und nicht mit globalisierten Werten injiziert werden müssen. Der Grund ist die Vermeidung von Wiederholungen.

Vom Standpunkt der Einfachheit aus (und abgesehen von einigen natürlich komplexen Fällen, wie Bereitstellungen mit mehreren Namespaces und Objekten ohne Namespace) ist der Idealfall, dass der Namespace Ihren Stack "zusammenfügt" und genau eine Instanz Ihrer Anwendung enthält.

Dadurch können Namen innerhalb des Stapels lokal, einfach und vor allem fest sein, da sie Namensraum-relativ sind.

Ein möglicher Ansatz besteht darin, dass helm den einfachen Fall mehr oder weniger unterstützt, wie es heute der Fall ist (wobei es vermieden wird, Objekten einen Namensraum voranzustellen); Dies führt zu vernünftigen, sicheren Best-Practice-Standards, die für die meisten Anwendungen sofort einsatzbereit sind. Es kann auch über einen erweiterten Namespace-Modus verfügen, der mehr Freiheit (auf Kosten der Komplexität) ermöglicht, um die von @dvdotsenko und @bcorijn beschriebenen Anwendungsfälle zu berücksichtigen .

Meine 0,02 $

Ich muss @pnickolov zustimmen , das ist ein großer Blocker für uns. In unserem Anwendungsfall haben wir über 150 Umgebungen und mehrere Cluster, die Varianten desselben Anwendungsstapels ausführen müssen. Namespaces lösen dieses Problem und ermöglichen die Trennung von Umgebungen und eine einfache Konfiguration, insbesondere in Bezug auf die Diensterkennung.

Ohne eine einfache Möglichkeit, Service-Endpunkte in Geschwisterdiagrammen zu konfigurieren... Rein über Werte...

Das finde ich auch verwirrend. Wie @technosophos schreibt :

Ein Release ist nicht an einen Namensraum gebunden. (Deshalb kann ein Release selbst eine Namespace-Definition enthalten). Tatsächlich sollte es möglich sein (obwohl ich nicht sagen kann, dass ich es persönlich versucht habe), ein einzelnes Diagramm bereitzustellen, das mehrere Objekte in mehreren Namespaces erstellt.

Ich habe Mühe, das genau zu verstehen. Ich habe mir die Dokumentation und mehrere Probleme hier zu GH angesehen und bin immer noch verwirrt:

• Einerseits kann ich helm install --namespace , um den Namespace anzugeben, auf den ich abzielen möchte
• Andererseits kann mein Diagramm beliebige Namespaces in seinen Metadatenobjekten angeben.

Also meine Fragen:

• Wenn der durch helm install --namespace angegebene Namespace nicht existiert, erstellt Helm ihn dann? Setzt es dann diesen Namespace für alle Ressourcen, die es aus der Chrt erstellt?
• Wenn eine Ressourcenvorlage in ihren Metadaten einen Namespace angibt, überschreibt helm ihn dann?

Diese Fragen haben mich zögern lassen, überhaupt mit --namespace , es ist so unklar. Wenn mir jemand helfen kann, das zu verstehen, wäre ich sehr dankbar. Danke schön!

Wenn der von helm install --namespace angegebene Namespace nicht existiert, erstellt Helm ihn?

Ja. Wenn der Namespace noch nicht existiert, erstellt --namespace den angegebenen Namespace für das Diagramm.

Wenn eine Ressourcenvorlage in ihren Metadaten einen Namespace angibt, überschreibt helm ihn dann?

Nein. Wenn Sie in --namespace denselben Namespace sowie die Namespace-Ressource im Diagramm angeben, kommt es zu einem Konflikt, da der Namespace zuerst von Tiller installiert wird und dann bork, wenn das Diagramm versucht, dies zu tun Installieren Sie denselben Namespace erneut.

Für weiteren Kontext besteht die Idee von helm darin, alle Ressourcen in dem von helm install --namespace bereitgestellten Namespace zu installieren. Benutzer, die den Namespace im Diagramm "hartkodieren", möchten normalerweise ein Diagramm in mehreren Namespaces installieren.

Dies ist ein wenig abseits von dem, was OP vorschlägt, aber Sie können gerne ein neues Ticket eröffnen oder sich uns auf Slack anschließen, wenn Sie weitere Fragen haben! :)

Ich bin mir nicht sicher, ob ich in diese Diskussion einsteigen möchte 😄 Seien Sie bitte freundlich 🙏

Der Parameter helm --namespace ist wirklich --default-namespace

Das Lesen des Stack und der dazugehörigen Informationen scheint viel Verwirrung bezüglich der Option --namespace da die Leute (ziemlicherweise) davon ausgehen, dass es wie kubectl --namespace sie gewöhnt sind, was die Aktivität effektiv auf diesen Namensraum beschränkt (durch die Nebenwirkung eines Parsing-Fehlers, nicht wirklich Sicherheit). Dies ist bei helm nicht der Fall, da tiller ein Clusterdienst ist, der über den gesamten Cluster arbeitet. Die Option wäre besser --default-namespace , dh. Dies ist der Namespace, zu dem Ihre Ressourcen gehen, wenn sie keinen bestimmten Namespace angeben.

Multi-Namespace-Releases werden ebenfalls benötigt

Ich verlasse mich bereits auf Diagramme, die verschiedene Komponenten jedes Releases in mehreren Namespaces bereitstellen, und freue mich auf die erweiterte Unterstützung in helm 3.0. 👍 🎉

Multi-Tenant mit Helm- und Namespace-Einschränkungen ist bereits möglich

Ich sehe auch den Anwendungsfall, bei dem die Leute mehrinstanzenfähige Installationen mit eingeschränktem Namespace wünschen. IMHO das Scoping oder die Beschränkung von Releases auf Namespaces ist nicht etwas, mit dem sich helm / tiller befassen sollte, das ist die Aufgabe von RBAC. Dafür gibt es mindestens zwei Modelle, eines davon ist derzeit möglich:

1. Stellen Sie einen Namespace pro Namespace tiller mit einem Dienstkonto und RBAC bereit, der nur Operationen in diesem Namespace zulässt. Das funktioniert jetzt und ich sehe Leute, die es benutzen. Ideal für Multi-Tenant-Cluster.
2. Damit tiller den Identitätswechsel von k8s-Benutzern unterstützt und somit jede Version als helm Benutzer bereitstellt. Dies wird für zukünftige helm -Versionen diskutiert und scheint einige Herausforderungen bei der Implementierung zu haben. Aber dies würde es einem Cluster-Dienst tiller ermöglichen, RBAC-Namespace-Einschränkungen durchzusetzen und gleichzeitig mehrere Namespace-übergreifende Releases zu unterstützen.

Gleichnamige Ressourcen für unterschiedliche Releases in unterschiedlichen Namespaces sind bereits möglich

Für Leute, die das gleiche Diagramm in verschiedenen Namespaces installieren möchten, aber mit den gleichen Ressourcennamen (zB redis). Das ist durchaus möglich, das hängt davon ab, wie Sie Ihre Diagrammvorlagen schreiben. Sie müssen Ressourcennamen nicht mit dem Releasenamen voranstellen, das ist nur eine Vorgabe/Konvention, der viele Diagramme folgen. Neuere Diagramme haben bereits den .fullnameOverride , mit dem Sie das Präfix des Release-Namens löschen können. Sie können Ihre redis als redis mit jedem einzelnen helm install wenn Sie möchten.

Wir befinden uns in einer ähnlichen Situation wie @gmile und wollten wissen, was die beste Vorgehensweise dafür ist. Unsere Kernanwendung ingestion-service hat eine Abhängigkeit von kafka die wiederum eine Abhängigkeit von zookeeper . Aber wir wollen alle drei in ihren eigenen Namespaces, aber wollen sie mit einem einzigen Helm install . Wir wollten kafka in die requirements.yaml von ingestion-service hinzufügen. Aber kafka in einem eigenen Namespace zu bekommen, sieht mit helm nicht einfach aus, also haben wir uns dafür entschieden, aus requirements.yaml entfernen und unterschiedliche helm install für beide Bereitstellungen zu verwenden .

Nur eine FYI, dass dies zur Kenntnis genommen wird und Teil des Helm-3-Vorschlags ist, der unter Abschnitt 3: State Management aufgeführt ist . Rückmeldung willkommen!

Das sind fantastische Neuigkeiten @bacongobbler 😄🎉

@bacongobbler Möchte Helm 3 die Angabe separater Namespaces für abhängige Diagramme in Requirements.yaml wie in @prat0318 beschrieben unterstützen?

Aus dem Vorschlagsdokument (lesen Sie es! :smile:):

$ helm install -n foo bar --namespace=dynamite
# installs release, releaseVersion, and un-namespaced charts into dynamite namespace.

Wenn eine Ressource wie bei Helm 2 explizit ihren eigenen Namespace deklariert (zB mit metadata.namespace=something), dann installiert Helm sie in diesem Namespace. Da sich die Besitzerreferenzen jedoch nicht über Namespaces erstrecken, wird jede solche Ressource im Grunde nicht verwaltet.

@bacongobbler Ich habe es gelesen, aber ich sehe immer noch nicht, dass es es unterstützt. Ich meine nicht hartcodierte metadata.namespace in Diagrammen, die ich kontrolliere, das wurde immer unterstützt. Was ich meine, ist die Angabe des Namespace für ein Diagramm eines Drittanbieters, das ich nicht bearbeiten kann. Zum Beispiel hänge ich in meiner Requirements.yaml von stable/kubernetes-dashboard ab und möchte, dass es im kube-system installiert wird, aber mein Diagramm soll in den Entwicklungs-Namespace gehen.

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

Es scheint, dass genau diese Funktionsanforderung von helmfile erfüllt werden

@gmile Ich bin mir zu 99% sicher, dass die helmfile-Betreuer dieses spezielle Problem in helmfile nicht behoben haben. Wenn Sie zwei Releases mit dem Namen vault mit unterschiedlichen Namespaces in Ihrer helmfile.yaml deklarieren und helmfile sync ausführen, schlägt dies fehl, weil der Releasename vault vom ersten Release beansprucht wurde.

Haftungsausschluss: Ich habe dies nicht mit helmfile getestet, daher würde mir gerne gesagt werden, dass ich falsch liege. 😄

Für den Fall, dass der letzte Kommentar übersehen wurde, werden wir dies in Helm 3 mit den Änderungen an der Handhabung von Helms Veröffentlichungen ansprechen . :)

@steven-sheehy Dieses spezielle Problem könnte wahrscheinlich über das Sandboxing-Modell behoben werden, indem das Subchart erweitert wird, um es auf einen bestimmten Namespace als den definierten bereitzustellen.

/Remove-Lifecycle-Stale

Verwandte: https://discuss.kubernetes.io/t/timeline-for-helm-3/2776

In Helm 3 implementiert. Das Ändern des Namespace-Kontexts bezieht sich auf eine ganz andere Instanz.

><> ./bin/helm version
version.BuildInfo{Version:"v3.0+unreleased", GitCommit:"5eb48f4471ac3aa9a3c87a07ee6f9e5bbc60a0e1", GitTreeState:"clean"}
><> ./bin/helm list --all-namespaces
NAME            REVISION    UPDATED                                 STATUS      CHART               NAMESPACE
chartmuseum     1           2019-02-08 08:56:29.566393188 -0800 PST deployed    chartmuseum-1.9.0   default  
chartmuseum     1           2019-02-08 09:14:01.978866327 -0800 PST deployed    chartmuseum-1.9.0   foo

Tolle Neuigkeiten @bacongobbler

Wäre es angesichts dieser Änderung sinnvoll, die Namespace-Spalte in die erste Spalte der Ausgabe von list . Damit die ersten beiden Spalten das Release eindeutig identifizieren?

Die Standardsortierung könnte nach Namespace und Release sein, so dass Releases im gleichen Namespace gruppiert werden, zB wären alle kube-system Releases zusammen.

Sicher.

im Moment benutze ich nur

helm install --name <namespace>-<name> ...

Ja, die derzeitige Arbeitsweise stinkt zwar, aber Sie brauchen nur global eindeutige Namen zu verwalten, und es gibt keinen Grund, warum Sie nicht einfach einen zusammengesetzten Schlüssel für den Namen der Version erstellen können.

Okay, es hört sich so an, als gäbe es 3 grundlegende Szenarien (mit Potenzial für verschiedene Permutationen, die sich jeweils mischen):

1. Diagramm mit einem einzelnen Namespace.
2. Ressource, die nicht namespacefähig ist.
3. Diagramm mit mehreren Namensräumen.

Wäre dies ein vernünftiger Ansatz, um die verschiedenen Szenarien anzugehen:

1. injizieren/überschreiben Sie den Namespace, wenn er mit dem --namespace Flag bereitgestellt wird.
2. wie 1, aber ignorieren Sie den Namespace für die Ressourcen, die keinen Namespace haben.
3. Exit mit dem Hinweis "kann einen Multi-Namespace nicht überschreiben" oder ähnliches.

Abgesehen davon: Ich benutze keine Pinne, bevorzuge helm template , bin mir also nicht sicher, wie sehr das die Herausforderungen ändert.

@technosophos

Ich versuche zu verstehen, wie Helm v2 mit Namespaces interagiert und wie sich v3 unterscheiden wird, und einer Ihrer alten Kommentare in diesem Thread verwirrt mich:

Lassen Sie mich zunächst den Hauptpunkt wiederholen: Helm-Diagramme arbeiten auf globaler Ebene, nicht auf Namespace-Ebene. Ihre Namen sind daher weltweit einzigartig.

....

Bei Elementen ohne Namensraum würden die Dinge sehr kompliziert. Wir hätten Namespace-Releases, die Dinge ohne Namespace verwalten, die sich wiederum auf andere Namespaces auswirken könnten. Sehen Sie sich an, wie RBACs und TPRs funktionieren. Dies sind keine Dinge, die Helm einfach nicht unterstützen kann, und das "Fälschen" eines Namespace würde mehr Probleme verursachen, als es wert ist, insbesondere bei RBACs.

Es hört sich so an, als ob Releases, die von Helm v3 bereitgestellt werden, tatsächlich einen Namensraum haben; Ist das korrekt? Wissen Sie, wie das RBAC-Problem gelöst wurde? Die einzige Lösung, die mir einfällt, um das von Ihnen angesprochene Problem zu vermeiden, besteht darin, dass Helm v3-Diagramme das Ändern von RBAC-Objekten nicht unterstützen RBAC-Objekte oder nicht.

Alles, was wir wirklich brauchen, ist, dass wir den Namespace-Parameter verwenden können und
name-Parameter als zusammengesetzter Schlüssel, um eine Version zu identifizieren, anstatt sie anzubringen
einen Namensraum auf einen Namen.

Ich habe den Vorschlag für Helm v3 nicht gelesen, aber das Vernünftige ist
Übernehmen Sie das Selektormuster, das k8s bereits verwendet, und es ist nicht erforderlich
unterstützen alle spezifischen Felder.

Am Di, 25.06.2019, 11:01 schrieb BatmanAoD [email protected] :

@technosophos https://github.com/technosophos

Ich versuche zu verstehen, wie Helm v2 mit Namespaces interagiert und wie v3
wird anders sein, und einer Ihrer alten Kommentare in diesem Thread verwirrt mich:

Lassen Sie mich zunächst den Hauptpunkt wiederholen: Helm-Diagramme arbeiten auf einem globalen
Ebene, nicht auf Namespace-Ebene. Ihre Namen sind also weltweit einzigartig....

Bei Elementen ohne Namensraum würden die Dinge sehr kompliziert. Wir hätten
Namespaced-Releases, die nicht-namespaced Dinge verwalten, die wiederum könnten
Auswirkungen auf andere Namespaces. Sehen Sie sich an, wie RBACs und TPRs funktionieren.
Dies sind keine Dinge, die Helm einfach nicht unterstützen kann, und
Das "Fälschen" eines Namensraums würde mehr Probleme verursachen, als er wert ist, insbesondere
mit RBACs.

Es hört sich so an, als ob Releases, die von Helm v3 bereitgestellt werden, tatsächlich einen Namensraum haben;
Ist das korrekt? Wissen Sie, wie das RBAC-Problem gelöst wurde? Das einzige
Ich kann mir eine Lösung vorstellen, die das Problem, auf das Sie hingewiesen haben, vermeiden würde
Helm v3-Diagramme unterstützen das Ändern von RBAC-Objekten nicht, aber ich habe es nicht gefunden
alles in den verschiedenen Blog-Posts und dergleichen über v3, das angibt, ob v3
Diagramme unterstützen die Verwaltung von RBAC-Objekten oder nicht.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTPDN5WW2ZLOORFI
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

@BatmanAoD @gyndick In Helm v3 werden Diagramme im Benutzerkontext installiert. Dies bedeutet, dass es in diesem Benutzernamensraum installiert wird und den RBAC des Benutzers verwendet. Release-Namen sind ebenfalls auf Namespace-Basis.

Sie können es mit dem Alpha.1-Release ausprobieren: https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 oder aus dem dev-v3 Zweig bauen.

Ich werde Helm v3 nicht verwenden. Jedes Operationsteam hat andere
Einschränkungen und Vorgehensweisen. Bedienwerkzeuge sollten einfach sein,
Einzweck-Dienstprogramme, dh kompatibel mit der Unix-Philosophie.

Meine Skripte, Logik usw. leben außerhalb meines Paketmanagers.

TLDR;

Der wichtigste Aspekt der Kompatibilität mit der Unix-Philosophie ist der
Möglichkeit, Fluchtluken zwischen den Stufen bereitzustellen.

Mit einem langen, automatisierten Workflow, der sich um die Logistik von
Von der Wiege bis zur Bahre ist genial, bis es bricht. Wenn Benutzern die
Fähigkeit, jeden Schritt des erforderlichen Automatisierungsflusses manuell durchzuführen
wird zur Büchse der Pandora.

Die für v3 vorgeschlagene Komplexität wird viele, viele Fehler und Schlimmes einladen
Design von Menschen, die nicht über 25 Jahre Erfahrung verfügen.

Die zusätzliche Komplexität wird die Dinge nur erschweren, da ausnahmslos
Betriebswerkzeuge, die nur zu eigenen Entwicklungsumgebungen werden
Triage verlangsamen.

Das perfekte Beispiel ist, wenn jemand in eine riesige, schreckliche kodifiziert
geschriebenes Skript. Es kommt zu einem Ausfall und Teile des Skripts müssen ausgeführt werden.
andere Teile müssen unbedingt vermieden werden, aber diese Teile sind integraler Bestandteil von
die Hauptlogik. Was zum Teufel machst du dann? Sitze da hektisch und versuche es
Code umzugestalten, den Sie nicht wirklich gut debuggen können.

Denken Sie an all die Tools, die in ein Ökosystem einfließen, um es zu unterstützen
Entwicklung und Betrieb von Software in einer bestimmten Sprache. Du bist nicht
wird das für helm noch einige Zeit zur Verfügung stellen können.

Behalten Sie also die Verantwortung für die Verwaltung der Migration zwischen den Versionen von
Software mit den Leuten, die die Software entwickeln, die bereitgestellt wird.

Ein Paketmanager sollte einfach und leicht sein mit nur wenigen
Verantwortlichkeiten.

1. Liefere Artefakte aus
2. Artefakte entfernen
3. Führen Sie die in den Artefakten bereitgestellten Skripts aus
4. Behalten Sie die Artefakte im Auge, die es geliefert zu haben glaubt
5. Am wichtigsten ist KISS

Alles andere verlangt nach Schmerzen. Ehrlich gesagt wäre Helm v2 fast perfekt
wenn es nur behoben wurde, wie es die Veröffentlichungen verfolgte.

Am Mi, 26. Juni 2019, 01:31 Martin Hickey [email protected]
schrieb:

@BatmanAoD https://github.com/BatmanAoD @gyndick In Helm v3 sind Diagramme
im Benutzerkontext installiert. Dies bedeutet, dass es in diesem Benutzer installiert ist
Namespace und verwendet den RBAC des Benutzers. Release-Namen sind auf a
auch Namensraumbasis.

Sie können es mit der Alpha.1-Version ausprobieren:
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 oder Build von
der dev-v3-Zweig.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTP5WW2ZLOOR7
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

@hickeyma Danke für die Antwort! Ich frage mich eigentlich nicht so sehr, wie Helms Operationen zugriffskontrolliert sein werden (obwohl dies ein verwandtes Problem ist), sondern ob Helm selbst noch in der Lage sein wird, globale Operationen wie das Erstellen von ClusterRoles in v3.

@BatmanAoD Das sollte funktionieren, da es sich um clusterbezogene Ressourcen handelt. Es könnte sich lohnen, es bei Gelegenheit auszuprobieren.