Helm: La portée libère des noms dans des espaces de noms

Je ne sais pas si je vous comprends. Vous souhaitez déployer sur plusieurs espaces de noms tout en n'ayant qu'un seul nom de version ?

@21stio Exactement. à partir de la documentation Kubernetes :

Kubernetes prend en charge plusieurs clusters virtuels soutenus par le même cluster physique. Ces clusters virtuels sont appelés espaces de noms.

et

Les espaces de noms fournissent une portée pour les noms. Les noms de ressources doivent être uniques au sein d'un espace de noms, mais pas entre les espaces de noms.

Personnellement, je ne vois pas de bonne raison pour laquelle helm ne respecterait pas ce concept d'espaces de noms.

Je suis d'accord. Tous mes espaces de noms sont sous la forme ${site}-${environment} , mais mes versions sont ${site}-${environment}-${description} . Où le site pourrait être internal ou www et environment pourrait être dev , staging , ou team-a , team-b , et description pourraient être quelque chose comme nginx , migrations , cache etc.

Mais le ${site}-${environment} est extrêmement redondant :

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

C'est ce avec quoi je finis, mais je préférerais que les dosettes soient juste redis-1234567890.. ou proxy-9876543210..

J'utilise mon nom de version dans mon modèle de graphique, donc tous mes noms de service et de pod incluent tous ces éléments supplémentaires. Je passe déjà l'espace de noms aux modèles, donc si je le voulais, je pourrais facilement l'inclure dans le nom si je le voulais, mais tel qu'il est maintenant, cela fait partie de tous mes noms de ressources en utilisant l'échafaudage helm par défaut.

Les espaces de noms K8s sont déjà des espaces de noms pour nous, je n'aime vraiment pas avoir à préfixer toutes mes choses avec l'espace de noms lorsque les espaces de noms sont conçus pour aider à éviter les conflits.

Explicitement, ce serait vraiment bien si je pouvais faire les mêmes choses que je peux faire avec les services et autres types natifs de k8s avec des graphiques de barre relatifs à l'espace de noms.

Par exemple, j'aimerais pouvoir faire les choses suivantes :

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

@Janpot @bcorijn L'hypothèse faite ci-dessus est que les graphiques Helm ne fonctionnent qu'avec des objets encapsulés à l'intérieur d'espaces de noms. Nous ne souhaitons pas limiter Helm uniquement à ces types de ressources.

Qu'en est-il des ressources tierces, qui n'ont pas d'espace de noms ? Ou des RBAC, où « namespace » est un attribut de stratégie, pas un emplacement (https://kubernetes.io/docs/admin/authorization/) ?

Je sais que je l'ai dit plusieurs fois ailleurs, mais notre objectif ultime est de permettre de déployer des ressources dans plusieurs espaces de noms à partir du même graphique. (Cas d'utilisation : une application a un plan de contrôle et un plan de données, et vous souhaitez les déployer chacun dans des espaces de noms distincts pour créer des limites de sécurité)

Si nous lions une version à un espace de noms, nous perdons la possibilité de :

1. Gérer directement les espaces de noms
2. Gérer les RBAC et les comptes de service
3. Gérer les TPR (et tout autre objet sans espace de noms)
4. Supporte éventuellement les graphiques multi-espaces de noms.

Je comprends que cela rend le problème de nommage un peu plus difficile pour vous, mais cela permet à Helm de fonctionner sur un éventail beaucoup plus large de ressources Kubernetes.

serait-il possible de prendre en charge les versions avec et sans espace de noms ?

@technosophos donc pour résumer il y a deux moteurs principaux :
1) Gestion des ressources sans espace de noms
2) Plans futurs d'autorisation de l'installation de graphiques dans l'espace de noms

Je comprends votre point, mais je ne sais pas si c'est une raison de s'en tenir à la mise en œuvre actuelle, car j'ai l'impression que vous devez également forcer un peu pour répondre à ces préoccupations ?

Pour que les graphiques multi-espaces de noms fonctionnent correctement/nativement, vous auriez probablement besoin d'une refonte complète du système d'espacement des noms, car le concept actuel de Helm mettant une version dans un espace de noms ne fonctionnera pas ? _EDIT : Je viens de réaliser que si les versions étaient réellement avec un espace de noms, un graphique multi-espaces de noms pourrait simplement être un graphique parapluie contenant deux versions avec un espace de noms différent ?_

Pour gérer les ressources sans espace de noms ; Je n'ai pas d'expérience personnelle avec cela, donc c'est un peu difficile à juger, mais encore une fois, je pense que cela force Helm à une méthode de travail moins que parfaite pour le moment, car une version qui gère les espaces de noms, RBAC ou TPR aura un espace de noms mais l'ignorer ?
Il se peut que je manque quelque chose parce que je n'ai pas d'expérience avec eux, mais la portée des noms et l'ignorance de l'espace de noms n'auraient pas le même résultat final, cela donnerait simplement plus de responsabilité à l'utilisateur de vérifier que ses noms de version et ses sélecteurs sont correct/unique lorsqu'il s'agit de ces ressources. (ce qui je suis d'accord est tout à fait la responsabilité)

Alors peut-être que le simple fait de déterminer la portée des versions n'est pas la voie à suivre, mais jeter un autre regard sur la façon dont elles sont gérées dans Helm et le seront à l'avenir en vaut la peine ? Avoir les deux options comme les mentions @Janpot pourraient fonctionner, les versions "globales" et les versions avec espace de noms ?
Mon opinion _très personnelle_ est également que le déploiement à la manière de @kylebyerly-hp, @chancez et moi-même décrit ci-dessus est beaucoup plus courant que les deux cas d'utilisation qui empêchent cette façon de fonctionner.

Tout d'abord, permettez-moi de réitérer le point principal : les graphiques Helm fonctionnent à un niveau global, et non au niveau de l'espace de noms. Leurs noms sont donc uniques au monde.

Pour les graphiques à plusieurs espaces de noms, ce que nous devons corriger, c'est la capacité de Tiller à interroger tous les espaces de noms. (Vous pouvez en fait _installer_ des graphiques à plusieurs espaces de noms maintenant. Vous ne pouvez tout simplement pas les mettre à niveau ou les supprimer de manière fiable, car Tiller ne peut pas les interroger de manière fiable).

Pour les éléments sans espace de noms, les choses deviendraient très compliquées. Nous aurions des versions avec espace de noms gérant des choses sans espace de noms qui, à leur tour, pourraient avoir un impact sur d'autres espaces de noms. Veuillez jeter un œil au fonctionnement des RBAC et des TPR. Ce ne sont pas des choses que Helm peut simplement décider de ne pas prendre en charge, et "truquer" un espace de noms causerait plus de problèmes qu'il n'en vaut la peine, en particulier avec les RBAC.

Je n'ai toujours pas vu de bonne raison d'espacer un nom de version. Vos plaintes initiales sont basées sur un malentendu selon lequel toutes les choses (importantes) dans Kubernetes sont limitées à un espace de noms. Mais des choses importantes comme les TPR et les RBAC ne le sont pas. La majeure partie des autres plaintes semble porter davantage sur le fait que les schémas de nommage _ad hoc_ qu'ils utilisent ne sont "pas jolis" avec Helm. Contourner cela en créant un ÉNORME changement de rupture de compatibilité qui représente mal les versions comme "dans un espace de noms" semble être la mauvaise approche à adopter.

@technosophos

Vous pouvez réellement installer des graphiques à plusieurs espaces de noms maintenant

Comment? Où la notion d'espaces de noms doit-elle être mise dans la configuration ?

Prévoyez-vous de prendre en charge officiellement les versions multi-espaces de noms ?

Nous ne prévoyons pas de prendre entièrement en charge les versions à espaces de noms multiples jusqu'à Helm 3.0, car cela romprait la compatibilité descendante et nécessiterait une refactorisation majeure d'une grande partie du code Kubernetes de Helm/Tiller.

Malheureusement pour nous, ne pas être en mesure de déployer et de gérer plusieurs espaces de noms à l'aide de helm est un problème.

Notre plan était de créer un graphique parapluie, qui aurait toutes nos applications (par exemple des graphiques plus petits) comme dépendances. Toutes nos applications vivent dans leurs propres espaces de noms, c'était par conception (à l'avenir, nous aimerions avoir RBAC par espace de noms). Avec un tableau général, nous pourrions installer et mettre à niveau tout un cluster de différents microservices à la fois, avec un seul values.yml , ce qui serait vraiment pratique.

@technosophos , merci. Noté sur le fait que le support pour ce qui précède n'arrivera pas bientôt, pas avant Helm 3.0 au moins.

Existe-t-il une idée générale de ce qui doit être remanié exactement dans Helm/Tiller pour prendre en charge plusieurs espaces de noms ? Ou est-ce que 3.0 est trop loin ?

Nous avons eu recours au helm name comme un UUID, en utilisant --name-template et en le laissant générer un nom simple mais aléatoire. Je ne peux pas dire que je préfère cela au respect de l'espace de noms lui-même, mais je vois les deux points et pour nous, cela suffira avec une surcharge minimale.

par exemple 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 comment trouverez-vous le nom de redis (uvtiwh) dans vos applications pour vous y connecter ?

Un modèle que j'envisage d'utiliser dans nos clusters est :

• Une instance Tiller dans kube-system , à utiliser par les administrateurs de cluster
• Une instance Tiller par espace de noms, avec des autorisations RBAC plus limitées, à utiliser par l'équipe de développeurs qui possède cet espace de noms

Le principe de conception « les noms de versions de Helm sont uniques au monde » est un casse-tête pour les déploiements multilocataires souples comme le nôtre, donc je suis intéressé à en savoir plus sur l'approche recommandée !

J'ai été très déçu quand j'ai découvert que Helm n'adhérait pas au concept d'identification des versions en fonction de leur nom et de leur espace de noms. À mon avis, cela ne suit pas les principes de conception de Kubernetes où les ressources sont uniques dans leur espace de noms respectif (à l'exception de certaines ressources globales).

Comme d'autres affiches l'ont commenté dans ce fil, nous avons plusieurs espaces de noms suffixés par environnement pour différents groupes d'applications. Nous avons des centaines de déploiements différents chacun dans trois ou quatre environnements. Nous nous appuyons fortement sur les noms DNS uniques dans les espaces de noms afin que nous puissions faire référence à des services portant le même nom dans différents espaces de noms ; par exemple. notre service redis est accessible via tcp://redis dans les deux espaces a-test noms a-prod , où les deux espaces de noms ont une version déployée de redis.

Cibler cela comme un point de discussion pour la barre 3. Il semble qu'il y ait une énorme demande pour cela.

Point contraire :

La quasi-totalité de nos arborescences graphiques déploient des artefacts sur plusieurs espaces de noms divisés le long des lignes persistance / API / Level7 ALB (+ statique). De ce point de vue, AIMEZ le fait que les noms de version de barre soient globaux.

Présence trouvée de l'option --namespace dans helm semi-inutile du point de vue de l'assemblage d'applications multicouches, où les couches de base peuvent être réutilisées par les couches supérieures déployées en rouge/bleu. Au lieu d'injecter des chaînes dérivées de {{ .Release.Name }} dans les noms des artefacts, nous créons un nouvel espace de noms pour chaque déploiement. Cela nous permet de propager des URL de service formées de manière déterministe via les configurations enchaînées ( same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ).

Étant donné que les noms de version générés automatiquement sont de toute façon un charabia - aucune fidélité à ce qui se cache derrière cette chose dans helm list , nous supprimons en dur --name avec une chaîne dérivée du nom du produit/de la pile et une version croissante de façon monotone / version de build ( "appname-v20171103xyz" ) J'adorerais pouvoir définir la valeur de --name-template quelque part dans le graphique et lui faire simplement utiliser le nom du graphique + la valeur d'ID de build dérivée ou explicite.

Exemple

Couche de persistance de base

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 }}"
...

Consommé à partir d'un autre espace de noms comme ceci :

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"

Les 2 modèles ci-dessus font partie de 2 graphiques distincts (graphique de persistance et graphique API) et peuvent être exécutés séparément ou conjointement via un 3e graphique global. Dans les deux cas, en raison de l'utilisation de .global. les valeurs sont remplacées une fois sur la ligne de commande et s'appliquent proprement à tous les sous-graphiques.

Avec cette approche, étant donné que la valeur de l'espace de noms de destination est parfois un dérivé partiel de ReleaseName et parfois semi-fixe, nous comptons pratiquement sur ReleaseName pour être global afin que le système se plaigne si nous essayons de créer une pile avec le même ReleaseName global.

L'un des avantages d'avoir et d'utiliser des espaces de noms est que les noms d'objets (y compris les noms DNS) qu'ils contiennent sont locaux et n'ont pas à changer d'espace de noms en espace de noms. Plus précisément dans l'exemple @dvdotsenko ci-dessus, le REDIS_SERVER_HOSTNAME devrait être le même (par exemple, juste redis ) et ne devrait pas avoir besoin d'être injecté avec des valeurs globalisées. La raison est d'éviter la répétition.

Du point de vue de la simplicité (et en mettant de côté certains cas naturellement complexes, comme les déploiements d'espaces de noms multiples et les objets sans espace de noms), le cas idéal est que l'espace de noms "assemble" votre pile et contienne exactement une instance de votre application.

Cela permet aux noms au sein de la pile d'être locaux, simples et, surtout, fixes car ils sont relatifs à l'espace de noms.

Une approche possible est que helm prenne en charge le cas simple plus ou moins comme il le fait aujourd'hui (tout en évitant de préfixer les objets avec l'espace de noms) ; cela produira des valeurs par défaut raisonnables et sûres qui fonctionneront immédiatement pour la plupart des utilisations. Il peut également avoir un mode d'espace de noms avancé qui permettra plus de liberté (au détriment de la complexité), pour permettre les cas d'utilisation décrits par @dvdotsenko et @bcorijn .

Mon 0,02 $

Je suis d'accord avec @pnickolov , c'est un bloqueur majeur pour nous. Dans notre cas d'utilisation, nous avons plus de 150 environnements et plusieurs clusters qui doivent exécuter des variantes de la même pile d'applications. Les espaces de noms résolvent ce problème en permettant la séparation des environnements et la simplicité de configuration, notamment en ce qui concerne la découverte de services.

Sans moyen simple de configurer les points de terminaison de service dans des graphiques frères... Purement via des valeurs...

Je trouve cela déroutant aussi. Comme l' écrit @technosophos :

Une version n'est pas liée à un espace de noms. (C'est pourquoi une version elle-même peut contenir une définition d'espace de noms). En fait, il devrait être possible (bien que je ne puisse pas dire que j'ai personnellement essayé) de déployer un seul graphique qui crée plusieurs objets dans plusieurs espaces de noms.

J'ai du mal à comprendre exactement cela. J'ai regardé la documentation et j'ai examiné plusieurs problèmes ici sur GH et je suis toujours confus:

• D'une part, je peux utiliser helm install --namespace pour spécifier l'espace de noms que je souhaite cibler
• D'un autre côté, mon graphique peut spécifier les espaces de noms qu'il souhaite dans ses objets de métadonnées.

Alors mes questions :

• Si l'espace de noms spécifié par helm install --namespace n'existe pas, est-ce que Helm le crée ? Est-ce qu'il définit ensuite cet espace de noms sur toutes les ressources qu'il crée à partir du chrt ?
• Si un modèle de ressource spécifie un espace de noms dans ses métadonnées, helm l'écrase-t-il ?

Ces questions m'ont fait hésiter à jouer avec --namespace , ce n'est pas clair. Si quelqu'un peut m'aider à comprendre, je l'apprécierais vraiment. Merci!

Si l'espace de noms spécifié par helm install --namespace n'existe pas, Helm le crée-t-il ?

Oui. Si l'espace de noms n'existe pas déjà, --namespace crée l'espace de noms spécifié pour le graphique.

Si un modèle de ressource spécifie un espace de noms dans ses métadonnées, helm l'écrase-t-il ?

Non. Si vous fournissez le même espace de noms dans --namespace ainsi que la ressource d'espace de noms dans le graphique, il y aura un conflit car l'espace de noms sera d'abord installé par tiller, puis s'arrêtera lorsque le graphique essaiera de réinstallez à nouveau le même espace de noms.

Pour plus de contexte, l'idée de helm est d'installer toutes les ressources dans l'espace de noms fourni par helm install --namespace . Les utilisateurs qui "codent en dur" l'espace de noms dans le graphique souhaitent généralement installer un graphique dans plusieurs espaces de noms.

C'est un peu hors sujet par rapport à ce que suggère OP, mais n'hésitez pas à ouvrir un nouveau ticket ou à nous rejoindre sur Slack si vous avez d'autres questions ! :)

Je ne suis pas sûr de vouloir me lancer dans cette discussion 😄 Soyez gentil s'il vous plaît

Le paramètre helm --namespace est vraiment --default-namespace

En lisant la pile et connexe, il y a beaucoup de confusion autour de l'option --namespace parce que les gens (assez raisonnablement) supposent que c'est comme kubectl --namespace auquel ils sont habitués, ce qui limite effectivement l'activité à cet espace de noms (par l'effet secondaire d'une erreur d'analyse, pas réellement la sécurité). Ce n'est pas le cas pour helm puisque tiller est un service de cluster qui opère sur l'ensemble du cluster. L'option aurait été mieux nommée --default-namespace , c'est-à-dire. c'est l'espace de noms auquel vos ressources iront si elles ne spécifient pas un espace de noms particulier.

Des versions multi-espaces de noms sont également nécessaires

Je m'appuie déjà sur des graphiques qui déploient différents composants de chaque version dans plusieurs espaces de noms, et j'attends avec impatience une prise en charge améliorée dans helm 3.0. 🎉

Le multi-locataire avec restrictions de barre et d'espace de noms est déjà possible

Je vois également le cas d'utilisation où les gens veulent des installations multi-locataires restreintes à l'espace de noms. À mon humble avis, la portée ou la restriction des versions aux espaces de noms n'est pas quelque chose que helm / tiller devrait se préoccuper de l'application, c'est le travail de RBAC. Il existe au moins deux modèles pour y parvenir, un est possible dès maintenant :

1. Déployez un tiller par espace
2. Pour que tiller prenne en charge l' tant qu'utilisateur helm . Ceci est en cours de discussion pour les futures versions de helm , et semble avoir des problèmes de mise en œuvre. Mais cela permettrait à un service tiller cluster

Des ressources du même nom pour différentes versions dans différents espaces de noms sont déjà possibles

Pour les personnes souhaitant installer le même graphique dans différents espaces de noms mais avec les mêmes noms de ressources (par exemple, redis). C'est tout à fait possible, cela dépend de la façon dont vous écrivez vos modèles de graphiques. Vous n'avez pas besoin de préfixer les noms de ressources avec le nom de la version, c'est juste une convention par défaut que suivent de nombreux graphiques. Les graphiques récents ont déjà la .fullnameOverride qui vous permet de supprimer le préfixe du nom de la version. Vous pouvez déployer vos redis tant que redis avec chaque helm install si vous le souhaitez.

Nous sommes dans une situation similaire à @gmile et nous voulions savoir quelle est la meilleure pratique pour le faire. Notre application principale, ingestion-service a une dépendance sur kafka qui à son tour a une dépendance sur zookeeper . Mais, nous voulons tous les trois dans leurs propres espaces de noms mais voulons gérer via un seul helm install . Nous avions prévu d'ajouter kafka dans le requirements.yaml de ingestion-service . Mais obtenir kafka dans son propre espace de noms n'a pas l'air simple avec helm donc ce que nous avons choisi était de supprimer de requirements.yaml et d'avoir différents helm install pour les deux déploiements .

Juste pour info, cela est noté et fait partie de la proposition Helm 3 répertoriée dans la section 3 : Gestion de l'état . Commentaires bienvenus!

C'est une nouvelle fantastique @bacongobbler 😄🎉

@bacongobbler Helm 3 cherche-t-il à prendre en charge la spécification d'espaces de noms distincts pour les graphiques dépendants dans requirements.yaml comme @prat0318 décrit ?

Extrait du document de proposition (lisez-le ! :smile:):

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

Comme avec Helm 2, si une ressource déclare explicitement son propre espace de noms (par exemple avec metadata.namespace=quelquechose), alors Helm l'installera dans cet espace de noms. Mais puisque les références de propriétaire ne tiennent pas sur les espaces de noms, une telle ressource deviendra fondamentalement non gérée.

@bacongobbler Je l'ai lu, mais je ne le vois toujours pas le soutenir. Je ne parle pas de metadata.namespace codé en dur dans les graphiques que je contrôle, cela a toujours été pris en charge. Ce que je veux dire, c'est spécifier l'espace de noms pour un graphique tiers que je n'ai pas la possibilité de modifier. Par exemple, dans mon requirements.yaml, je dépends de stable/kubernetes-dashboard et je veux qu'il soit installé dans kube-system, mais mon graphique doit aller dans l'espace de noms de développement.

Les problèmes deviennent obsolètes après 90 jours d'inactivité.
Marquez le problème comme récent avec /remove-lifecycle stale .
Les problèmes périmés pourrissent après 30 jours supplémentaires d'inactivité et finissent par se fermer.

Si ce problème peut être résolu en toute sécurité maintenant, veuillez le faire avec /close .

Envoyez vos commentaires à sig-testing, kubernetes/test-infra et/ou fejta .
/cycle de vie périmé

Il semble que cette demande de fonctionnalité puisse être satisfaite par helmfile . À partir de ce qui est dans le fichier readme, il devrait être possible de spécifier différentes versions étendues à leurs propres espaces de noms.

@gmile Je suis sûr à 99% que les responsables de helmfile n'ont pas résolu ce problème particulier dans helmfile. Si vous déclarez deux versions nommées vault avec des espaces de noms différents dans votre fichier helmfile.yaml et exécutez helmfile sync , cela échouera car le nom de version vault été réclamé par la première version.

avis de non-responsabilité : je n'ai pas testé cela en utilisant helmfile, donc j'aimerais qu'on me dise que je me trompe. ??

Juste au cas où le dernier commentaire aurait été manqué, nous abordons cela dans Helm 3 avec les modifications apportées à la façon dont Helm gère les versions . :)

@steven-sheehy ce problème particulier pourrait probablement être résolu via le modèle de sandbox en étendant le sous-tableau pour le déployer dans un espace de noms particulier que ce qui est défini.

/supprimer le cycle de vie périmé

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

Implémenté dans Helm 3. La modification du contexte de l'espace de noms fait référence à une instance complètement différente.

><> ./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

Bonne nouvelle

Compte tenu de ce changement, serait-il logique que la colonne de l'espace de noms soit déplacée vers la première colonne list sortie

Le tri par défaut pourrait être par espace de noms et version, de sorte que les versions dans le même espace de noms soient regroupées, par exemple toutes les versions kube-system seraient ensemble.

Sûr.

pour l'instant j'utilise juste

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

Oui, la façon dont les choses fonctionnent actuellement pue, mais tout ce dont vous avez besoin, ce sont des noms globalement uniques à gérer, et il n'y a aucune raison pour que vous ne puissiez pas simplement créer une clé composée pour le nom de la version.

D'accord, il semble qu'il y ait 3 scénarios fondamentaux (avec un potentiel pour diverses permutations mélangeant chacun) :

1. graphique à espace de noms unique.
2. ressource qui n'est pas espace de noms.
3. graphique multi-espaces de noms.

Serait-ce une approche raisonnable pour aborder les différents scénarios :

1. injecter/redéfinir l'espace de noms lorsqu'il est fourni avec le drapeau --namespace .
2. identique à 1, mais ignore l'espace de noms pour les ressources qui n'ont pas d'espace de noms.
3. exit en citant une ressource "ne peut pas remplacer un multi-espace de noms" ou similaire.

A part : je n'utilise pas la barre franche, préférant helm template donc je ne sais pas à quel point cela change les défis.

@technosophos

J'essaie de comprendre comment Helm v2 interagit avec les espaces de noms et en quoi la v3 sera différente, et l'un de vos anciens commentaires dans ce fil m'embrouille :

Tout d'abord, permettez-moi de réitérer le point principal : les graphiques Helm fonctionnent à un niveau global, et non au niveau de l'espace de noms. Leurs noms sont donc uniques au monde.

....

Pour les éléments sans espace de noms, les choses deviendraient très compliquées. Nous aurions des versions avec espace de noms gérant des choses sans espace de noms qui, à leur tour, pourraient avoir un impact sur d'autres espaces de noms. Veuillez jeter un œil au fonctionnement des RBAC et des TPR. Ce ne sont pas des choses que Helm peut simplement décider de ne pas prendre en charge, et "truquer" un espace de noms causerait plus de problèmes qu'il n'en vaut la peine, en particulier avec les RBAC.

Il semble que les versions déployées à partir de Helm v3 seront en fait avec un espace de noms ; Est-ce exact? Savez-vous comment le problème RBAC a été résolu ? La seule résolution à laquelle je peux penser qui éviterait le problème que vous avez signalé est que les graphiques Helm v3 ne prennent pas en charge la modification des objets RBAC, mais je n'ai rien trouvé dans les différents articles de blog et sur la v3 indiquant si les graphiques v3 prendront en charge la gestion Objets RBAC ou non.

Tout ce dont nous avons vraiment besoin, c'est de pouvoir utiliser le paramètre namespace et
paramètre name comme clé composée pour identifier une version plutôt que d'apposer
un espace de nom sur un nom.

Je n'ai pas lu la proposition pour helm v3, mais la chose sensée à faire est
adoptez le modèle de sélecteur que k8s utilise déjà et il n'est pas nécessaire de
prendre en charge tous les domaines spécifiques.

Le mardi 25 juin 2019, 11 h 01, BatmanAoD [email protected] a écrit :

@technosophos https://github.com/technosophos

J'essaie de comprendre comment Helm v2 interagit avec les espaces de noms et comment v3
sera différent, et l'un de vos anciens commentaires dans ce fil me confond:

Tout d'abord, permettez-moi de réitérer le point principal : les graphiques Helm fonctionnent sur un
niveau, pas au niveau de l'espace de noms. Leurs noms sont donc uniques au monde...

Pour les éléments sans espace de noms, les choses deviendraient très compliquées. nous aurions
versions avec espace de noms gérant des choses sans espace de nom qui, à leur tour, pourraient
impact sur d'autres espaces de noms. Veuillez jeter un œil au fonctionnement des RBAC et des TPR.
Ce ne sont pas des choses que Helm peut simplement décider de ne pas soutenir, et
"faire semblant" d'un espace de noms causerait plus de problèmes qu'il n'en vaut la peine, surtout
avec les RBAC.

Il semble que les versions déployées à partir de Helm v3 seront en fait avec un espace de noms ;
Est-ce exact? Savez-vous comment le problème RBAC a été résolu ? Le seul
résolution à laquelle je peux penser qui éviterait le problème que vous avez signalé est pour
Les graphiques Helm v3 ne prennent pas en charge la modification des objets RBAC, mais je n'ai pas trouvé
quoi que ce soit dans les différents articles de blog et autres sur la v3 indiquant si la v3
les graphiques prendront en charge la gestion des objets RBAC ou non.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX555#HJKTDN5WGO2ZLOOR ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

@BatmanAoD @gyndick Dans Helm v3, les graphiques sont installés dans le contexte de l'utilisateur. Cela signifie qu'il est installé dans cet espace de noms d'utilisateur et qu'il utilisera le RBAC de l'utilisateur. Les noms de version sont également basés sur un espace de noms.

Vous pouvez l'essayer avec la version Alpha.1 : https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 ou compiler à partir de la branche dev-v3 .

Je n'utiliserai pas helm v3. Chaque équipe d'exploitation a des
contraintes et façons de faire. Les outils opérationnels doivent être simples,
utilitaires à usage unique, c'est-à-dire compatibles avec la philosophie Unix.

Mes scripts, ma logique, etc. vivent en dehors de mon gestionnaire de packages.

TLDR ;

L'aspect le plus important de la compatibilité avec la philosophie Unix est la
possibilité de fournir des trappes d'évacuation entre les marches.

Avoir un long flux de travail automatisé qui prend en charge la logistique de
du berceau à la tombe est génial, jusqu'à ce qu'il se brise. Si les utilisateurs ne reçoivent pas le
capacité d'effectuer manuellement chaque étape du flux d'automatisation nécessaire
devient la boîte de Pandore.

La complexité proposée pour la v3 invitera beaucoup d'erreurs et de mauvaises
conception de personnes qui n'ont pas l'avantage de 25 ans d'expérience.

La complexité supplémentaire ne fera que rendre les choses plus difficiles à faire car invariablement,
des outils opérationnels qui deviennent des environnements de développement à eux seuls
ralentir le tri.

L'exemple parfait est quand quelqu'un codifie en un énorme, horriblement
scénario écrit. Une panne se produit et des parties du script doivent être exécutées,
d'autres pièces doivent être strictement évitées, mais ces pièces font partie intégrante de
la logique principale. Que diable faites-vous alors? Asseyez-vous là en essayant frénétiquement
pour refactoriser du code que vous n'avez pas vraiment un bon moyen de déboguer.

Pensez à tous les outils qui entrent dans un écosystème pour soutenir
développer et exploiter des logiciels dans n'importe quelle langue spécifique. Vous n'êtes pas
va pouvoir fournir cela pour la barre pendant un certain temps.

Gardez donc la responsabilité de gérer la migration entre les versions de
logiciel avec les personnes qui développent le logiciel en cours de déploiement.

Un gestionnaire de paquets doit être simple et léger avec seulement quelques
responsabilités.

1. Livrer des artefacts
2. Supprimer les artefacts
3. Exécutez les scripts fournis dans les artefacts
4. Gardez une trace des artefacts qu'il pense avoir livrés
5. Plus important encore, BAISER

Tout le reste demande de la douleur. Franchement, helm v2 serait presque parfait
s'il corrigeait simplement la façon dont il gardait une trace des versions.

Le mercredi 26 juin 2019, 01h31 Martin Hickey [email protected]
a écrit:

@BatmanAoD https://github.com/BatmanAoD @gyndick Dans Helm v3, les graphiques sont
installé dans le contexte de l'utilisateur. Cela signifie qu'il est installé dans cet utilisateur
namespace et utilisera le RBAC de l'utilisateur. Les noms de version sont sur un
base d'espace de noms également.

Vous pouvez l'essayer avec la version Alpha.1 :
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 ou construire à partir de
la branche dev-v3.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOOR ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

@hickeyma Merci pour la réponse ! En fait, je ne me demande pas tellement comment les opérations de Helm seront contrôlées par accès (bien que ce soit un problème connexe) que si Helm lui-même sera toujours en mesure d'effectuer des opérations globales telles que la création de ClusterRoles dans la v3.

@BatmanAoD Cela devrait fonctionner car ce sont des ressources à portée de cluster. Cela vaut peut-être la peine de l'essayer si vous en avez l'occasion.