Helm: El alcance libera nombres a espacios de nombres

No estoy seguro de entenderte. ¿Desea implementar en varios espacios de nombres mientras solo tiene un nombre de versión?

@ 21stio Exactamente. de los documentos de Kubernetes:

Kubernetes admite varios clústeres virtuales respaldados por el mismo clúster físico. Estos clústeres virtuales se denominan espacios de nombres.

y

Los espacios de nombres proporcionan un ámbito para los nombres. Los nombres de los recursos deben ser únicos dentro de un espacio de nombres, pero no entre espacios de nombres.

Personalmente, no puedo pensar en una buena razón por la que helm no respetaría este concepto de espacios de nombres.

Estoy de acuerdo. Todos mis espacios de nombres tienen el formato ${site}-${environment} , pero mis lanzamientos son ${site}-${environment}-${description} . Donde site podría ser internal o www y environment podría ser dev , staging o team-a , team-b y description podrían ser algo como nginx , migrations , cache etc.

Pero el ${site}-${environment} es extremadamente redundante:

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

Es con lo que termino, pero preferiría que las vainas fueran solo redis-1234567890.. o proxy-9876543210..

Utilizo mi nombre de lanzamiento en mi plantilla de gráfico, por lo que todos mis nombres de servicio y pod incluyen todas estas cosas adicionales. Ya paso el espacio de nombres a las plantillas, así que si quisiera, podría incluirlo fácilmente en el nombre si quisiera, pero tal como está ahora, es parte de todos mis nombres de recursos usando el andamio de timón predeterminado.

Los espacios de nombres de K8 ya son espacios de nombres para nosotros, realmente no me gusta tener que prefijar todas mis cosas con el espacio de nombres cuando los espacios de nombres están diseñados para ayudar a prevenir choques.

Explícitamente, sería muy bueno si pudiera hacer las mismas cosas que puedo hacer con los servicios y otros tipos nativos de k8s con gráficos de helm relacionados con el espacio de nombres.

Por ejemplo, me gustaría poder hacer lo siguiente:

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

@Janpot @bcorijn La suposición anterior es que los gráficos de Helm solo funcionan con objetos que están encapsulados dentro de espacios de nombres. No deseamos limitar a Helm solo a esos tipos de recursos.

¿Qué pasa con los recursos de terceros, que no tienen espacio de nombres? ¿O RBAC, donde "espacio de nombres" es un atributo de política, no una ubicación (https://kubernetes.io/docs/admin/authorization/)?

Sé que lo he dicho varias veces en otro lugar, pero nuestro objetivo final es hacer posible la implementación de recursos en múltiples espacios de nombres desde el mismo gráfico. (Caso de uso: una aplicación tiene un plano de control y un plano de datos, y desea implementarlos cada uno en espacios de nombres separados para crear límites de seguridad)

Si vinculamos una versión a un espacio de nombres, perdemos la capacidad de:

1. Administra directamente los espacios de nombres
2. Administrar cuentas de servicio y RBAC
3. Administrar TPR (y cualquier otro objeto sin espacio de nombres)
4. Admite eventualmente gráficos de múltiples espacios de nombres.

Entiendo que esto hace que el problema de los nombres sea un poco más difícil para usted, pero le permite a Helm operar en una gama mucho más amplia de recursos de Kubernetes.

¿Sería posible admitir versiones con espacio de nombres y sin espacio de nombres?

@technosophos, para resumir, hay dos impulsores principales:
1) Administrar recursos que no tienen espacio de nombres
2) Planes futuros de permitir que los gráficos se instalen en todos los espacios de nombres

Entiendo su punto, pero no estoy seguro de si es una razón para ceñirse a la implementación actual, ya que tengo la impresión de que también necesita forzarlo un poco para abordar estas preocupaciones.

Para que los gráficos de múltiples espacios de nombres funcionen bien / de forma nativa, lo más probable es que necesite una revisión considerable del sistema de espacio de nombres, ya que el concepto actual de que Helm ponga una publicación en un espacio de nombres no funcionará. _EDIT: ¿Acabo de darme cuenta de que si los lanzamientos tuvieran realmente un espacio de nombres, un gráfico de múltiples espacios de nombres podría ser simplemente un gráfico general que contiene dos lanzamientos con un espacio de nombres diferente? _

Para administrar recursos sin espacios de nombres; No tengo experiencia personal con eso, por lo que es un poco difícil de juzgar, pero nuevamente siento que esto está forzando a Helm a una forma menos que perfecta de trabajar en este momento, ya que una versión que administra espacios de nombres, RBAC o TPR tendrá un espacio de nombres. pero simplemente ignóralo?
Es posible que me esté perdiendo algo debido a que no tengo experiencia con ellos, pero no definir el alcance de los nombres e ignorar el espacio de nombres tiene el mismo resultado final, simplemente pondría más responsabilidad en el usuario para verificar que sus nombres de lanzamiento y selectores sean correcto / único cuando se trata de estos recursos. (que estoy de acuerdo es bastante responsabilidad)

Entonces, tal vez solo el alcance de las publicaciones no sea el camino a seguir, pero ¿vale la pena echar otro vistazo a la forma en que se manejan en Helm y se manejarán en el futuro? ¿Tener ambas opciones como las menciones de
Mi opinión _muy personal_ también es que la implementación de la forma @ kylebyerly-hp, @chancez y yo describimos anteriormente es mucho más común que los dos casos de uso que impiden esta forma de trabajar.

Primero, permítanme reiterar el punto principal: los gráficos de Helm operan a nivel global, no a nivel de espacio de nombres. Por tanto, sus nombres son únicos a nivel mundial.

Para gráficos con múltiples espacios de nombres, lo que debemos corregir es la capacidad de Tiller para realizar consultas en espacios de nombres. (En realidad, ahora puede _instalar_ gráficos con múltiples espacios de nombres. Simplemente no puede actualizarlos o eliminarlos de manera confiable, porque Tiller no puede consultarlos de manera confiable).

Para los elementos sin espacios de nombres, las cosas se complicarían mucho. Tendríamos versiones con espacios de nombres que administran cosas sin espacios de nombres que, a su vez, podrían afectar a otros espacios de nombres. Eche un vistazo a cómo funcionan los RBAC y los TPR. Estas no son cosas que Helm simplemente puede decidir no admitir, y "falsificar" un espacio de nombres causaría más problemas de los que vale, especialmente con los RBAC.

Todavía no he visto una buena razón para colocar un espacio de nombres en el nombre de una versión. Sus quejas iniciales se basan en un malentendido de que todas las cosas (importantes) en Kubernetes tienen como alcance un espacio de nombres. Pero cosas importantes como los TPR y los RBAC no lo son. La mayor parte de las otras quejas parecen estar más relacionadas con el hecho de que los esquemas de nomenclatura _ad hoc_ que utilizan "no son bonitos" con Helm. Trabajar en torno a eso mediante la creación de un ENORME cambio que rompa la compatibilidad que represente erróneamente las versiones como "en un espacio de nombres" parece ser el enfoque incorrecto.

@technosophos

De hecho, puede instalar gráficos con múltiples espacios de nombres ahora

¿Cómo? ¿Dónde se debe poner la noción sobre espacios de nombres en la configuración?

¿Planea admitir oficialmente las versiones de varios espacios de nombres?

No planeamos admitir completamente las versiones con múltiples espacios de nombres hasta Helm 3.0 porque hacerlo romperá la compatibilidad con versiones anteriores y requerirá una refactorización importante de gran parte del código de Kubernetes de Helm / Tiller.

Desafortunadamente para nosotros, no poder implementar y administrar múltiples espacios de nombres usando helm es un factor decisivo.

Nuestro plan era crear un gráfico general, que tendría todas nuestras aplicaciones (por ejemplo, gráficos más pequeños) como dependencias. Todas nuestras aplicaciones viven en sus propios espacios de nombres, esto fue por diseño (en el futuro nos gustaría tener RBAC por espacio de nombres). Con un gráfico general, podríamos instalar y actualizar todo el grupo de diferentes microservicios a la vez, con solo un values.yml , lo que sería realmente conveniente.

@technosophos , gracias. Se señaló el hecho de que el soporte para lo anterior no llegará pronto, no hasta Helm 3.0 al menos.

¿Existe una idea general de qué es exactamente lo que se debe refactorizar en Helm / Tiller para admitir múltiples espacios de nombres? ¿O 3.0 está demasiado lejos?

Hemos recurrido a tratar el timón name más como un UUID, usando --name-template y dejando que genere un nombre simple pero aleatorio. No puedo decir que prefiera esto a respetar el espacio de nombres en sí, pero veo ambos puntos y para nosotros esto será suficiente con una sobrecarga mínima.

por ejemplo, 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, ¿cómo encontrarás el nombre de redis (uvtiwh) en tus aplicaciones para conectarte a él?

Un patrón que estoy considerando usar en nuestros clústeres es:

• Una instancia de Tiller en kube-system , para que la utilicen los administradores del clúster
• Una instancia de Tiller por espacio de nombres, con permisos de RBAC más limitados, para ser utilizada por el equipo de desarrolladores que posee ese espacio de nombres

El principio de diseño "Los nombres de las versiones de Helm son únicos a nivel mundial" es un dolor de cabeza para las implementaciones de múltiples inquilinos suaves como la nuestra, por lo que estoy interesado en escuchar más sobre el enfoque recomendado.

Me sentí muy decepcionado cuando descubrí que Helm no se adhiere al concepto de identificar lanzamientos en función de su nombre y espacio de nombres. En mi opinión, esto no sigue los principios de diseño de Kubernetes donde los recursos son únicos dentro de su respectivo espacio de nombres (con la excepción de algunos recursos globales).

Como han comentado otros carteles en este hilo, tenemos varios espacios de nombres con sufijos de entorno para diferentes grupos de aplicaciones. Tenemos cientos de implementaciones diferentes, cada una en tres o cuatro entornos. Dependemos en gran medida de los nombres DNS únicos dentro de los espacios de nombres para que podamos hacer referencia a servicios con el mismo nombre dentro de diferentes espacios de nombres; p.ej. Se puede acceder a nuestro servicio redis a través de tcp: // redis en los espacios a-test nombres a-prod , donde ambos espacios de nombres tienen una versión implementada de redis.

Enfocar esto como un punto de discusión para el timón 3. Parece que hay una gran demanda para esto.

Punto contrario:

Prácticamente todos nuestros árboles de gráficos implementan artefactos en múltiples espacios de nombres divididos a lo largo de líneas de persistencia / API / ALB de nivel 7 (+ estática). Desde ese punto de vista, AMO el hecho de que los nombres de los lanzamientos de timón sean globales.

Se encontró la presencia de la opción --namespace en helm semi-inútil desde el punto de vista del ensamblaje de aplicaciones de múltiples capas, donde las capas base pueden ser reutilizadas por capas superiores desplegadas en rojo / azul. En lugar de inyectar cadenas derivadas de {{ .Release.Name }} en los nombres de los artefactos, creamos un nuevo espacio de nombres para cada implementación. Esto nos permite propagar URL de servicio formadas de forma determinista a través de las configuraciones encadenadas ( same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ).

Dado que los nombres de las versiones generados automáticamente son un galimatías de todos modos, no hay fidelidad en lo que está detrás de esa cosa en helm list , anulamos --name con una cadena derivada del nombre del producto / pila y la versión que aumenta monótonamente / versión de compilación ( "appname-v20171103xyz" ) Me encantaría poder definir el valor de --name-template en algún lugar del gráfico y que use el nombre del gráfico + el valor de ID de compilación explícito o derivado de la fecha.

Ejemplo

Capa base de persistencia

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

Consumido desde otro espacio de nombres como este:

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"

Las 2 plantillas anteriores son partes de 2 gráficos separados (gráfico de persistencia y gráfico de API) y se pueden ejecutar por separado o en conjunto a través de un tercer gráfico general. En ambos casos, debido al uso de .global. los valores se anulan una vez en la línea de comando y se aplican limpiamente a todos los sub-gráficos.

Con este enfoque, dado que el valor del espacio de nombres de destino a veces es una derivación parcial de ReleaseName y, a veces, es semi-fijo, confiamos en que ReleaseName sea global, por lo que el sistema se quejaría si intentamos crear una pila con el mismo ReleaseName global.

Uno de los beneficios de tener y usar espacios de nombres es que los nombres de los objetos (incluidos los nombres DNS) dentro de ellos son locales y no tienen que cambiar de un espacio de nombres a otro. Específicamente en el ejemplo anterior de @dvdotsenko , el REDIS_SERVER_HOSTNAME debería ser el mismo (por ejemplo, solo redis ) y no debería necesitar inyectarse con valores globalizados. La razón es evitar la repetición.

Desde el punto de vista de la simplicidad (y dejando de lado algunos casos naturalmente complejos, como implementaciones de múltiples espacios de nombres y objetos sin espacios de nombres), el caso ideal es que el espacio de nombres "ensamble" su pila y contenga exactamente una instancia de su aplicación.

Esto permite que los nombres dentro de la pila sean locales, simples y, lo más importante, fijos, ya que son relativos al espacio de nombres.

Un posible enfoque es que helm admita el caso simple más o menos como lo hace hoy (evitando prefijar objetos con espacio de nombres); esto producirá valores predeterminados razonables y seguros con las mejores prácticas que funcionarán de inmediato para la mayoría de los usos. También puede tener un modo de espacio de nombres avanzado que permitirá más libertad (a expensas de la complejidad), para permitir los casos de uso que describen @dvdotsenko y @bcorijn .

Mi $ .02

Tengo que estar de acuerdo con @pnickolov , este es un gran bloqueador para nosotros. En nuestro caso de uso, tenemos más de 150 entornos y múltiples clústeres que deben ejecutar variantes de la misma pila de aplicaciones. Los espacios de nombres resuelven este problema permitiendo la separación de entornos y la simplicidad de configuración, particularmente en relación con el descubrimiento de servicios.

Sin una manera fácil de configurar los puntos finales del servicio en gráficos hermanos ... Simplemente a través de valores ...

Encuentro esto confuso también. Como escribe @technosophos :

Un comunicado no está vinculado a un espacio de nombres. (Es por eso que una versión en sí misma puede contener una definición de espacio de nombres). De hecho, debería ser posible (aunque no puedo decir que lo haya intentado personalmente) implementar un solo gráfico que cree múltiples objetos en múltiples espacios de nombres.

Estoy luchando por entender exactamente esto. He mirado la documentación y he mirado varios problemas aquí en GH y todavía estoy confundido:

• Por un lado, puedo usar helm install --namespace para especificar el espacio de nombres al que me gustaría apuntar
• Por otro lado, mi gráfico puede especificar los espacios de nombres que desee dentro de sus objetos de metadatos.

Entonces, mis preguntas:

• Si el espacio de nombres especificado por helm install --namespace no existe, ¿lo crea Helm? ¿Luego establece ese espacio de nombres en todos los recursos que crea a partir del chrt?
• Si una plantilla de recursos especifica un espacio de nombres en sus metadatos, ¿helm lo sobrescribe?

Estas preguntas me han hecho dudar incluso de jugar con --namespace , no está claro. Si alguien puede ayudarme a darle sentido, se lo agradecería mucho. ¡Gracias!

Si el espacio de nombres especificado por helm install --namespace no existe, ¿lo crea Helm?

Si. Si el espacio de nombres aún no existe, --namespace crea el espacio de nombres especificado para el gráfico.

Si una plantilla de recursos especifica un espacio de nombres en sus metadatos, ¿helm lo sobrescribe?

No. Si proporciona el mismo espacio de nombres en --namespace así como el recurso Espacio de nombres en el gráfico, habrá un conflicto ya que el espacio de nombres será instalado primero por tiller, y luego se bloqueará cuando el gráfico intente vuelva a instalar el mismo espacio de nombres.

Para mayor contexto, la idea de helm es instalar todos los recursos en el espacio de nombres proporcionado por helm install --namespace . Los usuarios que están "codificando" el espacio de nombres en el gráfico normalmente quieren instalar un gráfico en varios espacios de nombres.

Esto está un poco fuera de tema de lo que sugiere OP, pero no dude en abrir un nuevo ticket o unirse a nosotros en Slack si tiene más preguntas. :)

No estoy seguro de querer entrar en esta discusión 😄 Sea amable por favor 🙏

El parámetro helm --namespace es realmente --default-namespace

Al leer la pila y lo relacionado, parece haber mucha confusión en torno a la opción --namespace porque la gente (bastante razonablemente) asume que es como kubectl --namespace que están acostumbrados, lo que limita efectivamente la actividad a ese espacio de nombres (por el efecto secundario de un error de análisis, no en realidad seguridad). Ese no es el caso de helm ya que tiller es un servicio de clúster que opera en todo el clúster. La opción habría sido mejor nombrada --default-namespace , es decir. este es el espacio de nombres al que irán sus recursos si no especifican un espacio de nombres en particular.

También se necesitan lanzamientos de múltiples espacios de nombres

Ya confío en gráficos que implementan diferentes componentes de cada versión en múltiples espacios de nombres, y espero con ansias el soporte mejorado en helm 3.0. 👍 🎉

Ya es posible tener varios inquilinos con restricciones de espacio de nombres y timón

También veo el caso de uso en el que la gente quiere instalaciones de múltiples inquilinos y con espacio de nombres restringido. En mi humilde opinión, el alcance o la restricción de lanzamientos a espacios de nombres no es algo que helm / tiller deba preocuparse de hacer cumplir, ese es el trabajo de RBAC. Hay al menos dos modelos para lograr esto, uno es posible ahora mismo:

1. Implemente un espacio de nombres tiller con una cuenta de servicio y un RBAC que solo permita operaciones en ese espacio de nombres. Esto funciona ahora y veo que la gente lo usa. Ideal para clústeres de múltiples inquilinos.
2. Para que tiller admita la suplantación de usuario de k8s , y así implemente cada versión como el usuario helm . Esto se está discutiendo para futuras versiones helm y parece tener algunos desafíos de implementación. Pero esto permitiría a un servicio de clúster tiller hacer cumplir las restricciones de espacio de nombres RBAC, sin dejar de admitir versiones que abarcan varios espacios de nombres.

Los recursos del mismo nombre para diferentes versiones en diferentes espacios de nombres ya son posibles

Para las personas que desean instalar el mismo gráfico en diferentes espacios de nombres pero con los mismos nombres de recursos (por ejemplo, redis). Eso es completamente posible, eso depende de cómo escriba sus plantillas de gráficos. No necesita anteponer los nombres de los recursos con el nombre de la versión, eso es solo una convención predeterminada que siguen muchos gráficos. Los gráficos recientes ya tienen el .fullnameOverride que le permite descartar el prefijo del nombre de la versión. Puede implementar su redis como redis con cada helm install si lo desea.

Estamos en una situación similar a @gmile y queríamos saber cuál es la mejor práctica para hacerlo. Nuestra aplicación principal, ingestion-service tiene una dependencia de kafka que a su vez depende de zookeeper . Pero queremos los tres en sus propios espacios de nombres, pero queremos administrarlos a través de un solo timón install . Estábamos planeando agregar kafka en el requirements.yaml de ingestion-service . Pero obtener kafka en su propio espacio de nombres no parece sencillo con helm así que lo que buscamos fue eliminar de requirements.yaml y tener helm install para ambas implementaciones .

Solo para su información, esto se indica y es parte de la propuesta de Helm 3 enumerada en la Sección 3: Gestión del estado . ¡Comentarios bienvenidos!

Esa es una noticia fantástica @bacongobbler 😄🎉

@bacongobbler ¿Helm 3 busca admitir la especificación de espacios de nombres separados para gráficos dependientes en requirements.yaml como se describe en @ prat0318 ?

Del documento de la propuesta (¡dale una lectura!: Sonríe :):

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

Al igual que con Helm 2, si un recurso declara explícitamente su propio espacio de nombres (por ejemplo, con metadata.namespace = algo), Helm lo instalará en ese espacio de nombres. Pero dado que las referencias del propietario no se mantienen en los espacios de nombres, cualquier recurso de este tipo básicamente dejará de ser administrado.

@bacongobbler Lo leí, pero todavía no veo que lo apoye. No me refiero a metadata.namespace codificado en los gráficos que controlo, eso siempre ha sido compatible. Lo que quiero decir es especificar el espacio de nombres para un gráfico de terceros que no tengo la capacidad de editar. Por ejemplo, en mi requirements.yaml dependo de stable / kubernetes-dashboard y quiero que se instale en kube-system, pero mi gráfico debe ir al espacio de nombres de desarrollo.

Los problemas se vuelven obsoletos después de 90 días de inactividad.
Marque el problema como nuevo con /remove-lifecycle stale .
Los problemas obsoletos se pudren después de 30 días adicionales de inactividad y finalmente se cierran.

Si es seguro cerrar este problema ahora, hágalo con /close .

Envíe sus comentarios a sig-testing, kubernetes / test-infra y / o fejta .
/ ciclo de vida obsoleto

Parece que helmfile puede satisfacer esta misma solicitud de

@gmile Estoy 99% seguro de que los mantenedores de helmfile no han solucionado este problema en particular en helmfile. Si declara dos versiones llamadas vault con diferentes espacios de nombres en su archivo helmfile.yaml y ejecuta helmfile sync , fallará porque la primera versión reclamó el nombre de la versión vault .

descargo de responsabilidad: no he probado esto usando helmfile, así que me encantaría que me dijeran que estoy equivocado. 😄

En caso de que se haya perdido el último comentario, estamos abordando esto en Helm 3 con los cambios en la forma en que Helm maneja las versiones . :)

@ steven-sheehy, ese problema en particular probablemente podría solucionarse a través del modelo de espacio aislado extendiendo el subchart para implementarlo en un espacio de nombres particular que no sea el definido.

/ remove-lifecycle stale

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

Implementado en Helm 3. Cambiar el contexto del espacio de nombres se refiere a una instancia completamente diferente.

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

Buenas noticias

Dado este cambio, ¿tendría sentido que la columna de espacio de nombres se mueva a la primera columna en list salida? ¿De modo que las dos primeras columnas identifiquen de forma única el lanzamiento?

La clasificación predeterminada podría ser por espacio de nombres y lanzamiento, de modo que los lanzamientos en el mismo espacio de nombres se agrupen, por ejemplo, todos los lanzamientos kube-system estarían juntos.

Seguro.

por ahora, solo uso

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

Sí, la forma actual en que funcionan las cosas apesta, pero todo lo que necesita son nombres únicos a nivel mundial para administrar, y no hay ninguna razón por la que no pueda simplemente crear una clave compuesta para el nombre de la versión.

Bien, parece que hay 3 escenarios fundamentales (con potencial para varias permutaciones mezclando cada uno):

1. gráfico de espacio de nombres único.
2. recurso que no tiene espacio de nombres.
3. gráfico de múltiples espacios de nombres.

¿Sería este un enfoque razonable para abordar los diferentes escenarios?

1. inyectar / anular el espacio de nombres cuando se proporciona con la bandera --namespace .
2. igual que 1, pero ignora el espacio de nombres para aquellos recursos que carecen de un espacio de nombres.
3. salir citando "no se puede anular un recurso de múltiples espacios de nombres" o similar.

Aparte: no uso tiller, prefiero helm template así que no estoy seguro de cuánto cambia eso los desafíos.

@technosophos

Estoy tratando de entender cómo Helm v2 interactúa con los espacios de nombres y cómo v3 será diferente, y uno de sus comentarios anteriores en este hilo me confunde:

Primero, permítanme reiterar el punto principal: los gráficos de Helm operan a nivel global, no a nivel de espacio de nombres. Por tanto, sus nombres son únicos a nivel mundial.

....

Para los elementos sin espacios de nombres, las cosas se complicarían mucho. Tendríamos versiones con espacios de nombres que administran cosas sin espacios de nombres que, a su vez, podrían afectar a otros espacios de nombres. Eche un vistazo a cómo funcionan los RBAC y los TPR. Estas no son cosas que Helm simplemente puede decidir no admitir, y "falsificar" un espacio de nombres causaría más problemas de los que vale, especialmente con los RBAC.

Parece que las versiones implementadas desde Helm v3, de hecho, tendrán un espacio de nombres; ¿Es eso correcto? ¿Sabe cómo se ha resuelto el problema de RBAC? La única resolución en la que puedo pensar que evitaría el problema que señaló es que los gráficos de Helm v3 no admitan la modificación de objetos RBAC, pero no he encontrado nada en las diversas publicaciones del blog y sobre v3 que indique si los gráficos v3 admitirán la gestión Objetos RBAC o no.

Todo lo que realmente necesitamos es que podamos usar el parámetro de espacio de nombres y
parámetro de nombre como clave compuesta para identificar una versión en lugar de colocar
un espacio de nombres en un nombre.

No he leído la propuesta de helm v3, pero lo más sensato es
Adopte el patrón selector que k8s ya usa y no hay necesidad de
apoyar cualquier campo específico.

El martes, 25 de junio de 2019 a las 11:01 a.m., BatmanAoD [email protected] escribió:

@technosophos https://github.com/technosophos

Estoy tratando de entender cómo Helm v2 interactúa con los espacios de nombres y cómo v3
será diferente, y uno de sus comentarios anteriores en este hilo me confunde:

Primero, permítanme reiterar el punto principal: los gráficos de Helm operan en un
nivel, no en un nivel de espacio de nombres. Entonces sus nombres son únicos a nivel mundial ...

Para los elementos sin espacios de nombres, las cosas se complicarían mucho. Tendríamos
lanzamientos con espacio de nombres que gestionan cosas sin espacio de nombres que, a su vez, podrían
impactar en otros espacios de nombres. Eche un vistazo a cómo funcionan los RBAC y los TPR.
Estas no son cosas que Helm simplemente pueda decidir no apoyar, y
"Fingir" un espacio de nombres causaría más problemas de los que vale, especialmente
con RBAC.

Parece que las versiones implementadas desde Helm v3, de hecho, tendrán un espacio de nombres;
¿Es eso correcto? ¿Sabe cómo se ha resuelto el problema de RBAC? Lo único
Puedo pensar en una resolución que evitaría el problema que usted señaló es para
Los gráficos de Helm v3 no admiten la modificación de objetos RBAC, pero no he encontrado
cualquier cosa en las diversas publicaciones del blog y sobre v3 que indique si v3
Los gráficos admitirán la gestión de objetos RBAC o no.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMDVBORW63 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

@BatmanAoD @gyndick En Helm v3, los gráficos se instalan en el contexto del usuario. Esto significa que está instalado en ese espacio de nombres de usuario y utilizará el RBAC del usuario. Los nombres de las versiones también se basan en el espacio de nombres.

Puede probarlo con la versión Alpha.1: https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 o compilar desde la rama dev-v3 .

No usaré helm v3. Cada equipo de operaciones tiene diferentes
limitaciones y formas de hacer las cosas. Las herramientas operativas deben ser simples,
Utilidades de propósito único, es decir, compatibles con la filosofía Unix.

Mi scripting, lógica, etc. viven fuera de mi administrador de paquetes.

TLDR;

El aspecto más importante de ser compatible con la filosofía Unix es el
capacidad de proporcionar trampillas de escape entre escalones.

Tener un flujo de trabajo largo y automatizado que se encarga de la logística desde
de la cuna a la tumba es terrible, hasta que se rompe. Si a los usuarios no se les proporciona el
capacidad de realizar manualmente cada paso del flujo de automatización necesaria
se convierte en la caja de Pandora.

La complejidad propuesta para la v3 invitará a muchos, muchos errores y malas
diseño de personas que no cuentan con el beneficio de 25 años de experiencia.

La complejidad adicional solo hará que las cosas sean más difíciles de hacer porque, invariablemente,
herramientas operativas que se convierten en entornos de desarrollo propios únicamente
ralentizar el triaje.

El ejemplo perfecto es cuando alguien codifica en uno masivo, horriblemente
guión escrito. Se produce una interrupción y es necesario ejecutar partes del script,
otras partes deben evitarse estrictamente, sin embargo, esas partes son parte integral de
la lógica principal. ¿Qué diablos haces entonces? Siéntate allí tratando frenéticamente
para refactorizar el código que realmente no tiene una buena forma de depurar.

Piense en todas las herramientas que forman parte de un ecosistema para respaldar
desarrollar y operar software en cualquier idioma específico. Usted no es
Podrá proporcionar eso para el timón durante bastante tiempo.

Por lo tanto, asuma la responsabilidad de cómo administrar la migración entre versiones de
software con las personas que desarrollan el software que se está implementando.

Un administrador de paquetes debe ser simple y liviano con solo unos pocos
responsabilidades.

1. Entrega artefactos
2. Eliminar artefactos
3. Ejecute los scripts proporcionados en los artefactos.
4. Mantenga un registro de los artefactos que cree que entregó
5. Lo más importante, KISS

Cualquier otra cosa es pedir dolor. Francamente, helm v2 sería casi perfecto
si solo arreglaba cómo realizaba un seguimiento de los lanzamientos.

El miércoles 26 de junio de 2019 a la 1:31 a. M. Martin Hickey [email protected]
escribió:

@BatmanAoD https://github.com/BatmanAoD @gyndick En Helm v3, los gráficos son
instalado en el contexto del usuario. Esto significa que está instalado en ese usuario.
espacio de nombres y utilizará el RBAC del usuario. Los nombres de las versiones están en un
base de espacio de nombres también.

Puede probarlo con la versión Alpha.1:
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 o compilar desde
la rama dev-v3.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVODBW63WR7 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

@hickeyma ¡ Gracias por la respuesta! En realidad, no me pregunto tanto cómo se controlarán el acceso a las operaciones de Helm (aunque ese es un problema relacionado) sino si Helm aún podrá realizar operaciones globales como crear ClusterRoles en v3.

@BatmanAoD Eso debería funcionar ya que son recursos de ámbito de clúster. Podría valer la pena probarlo si tienes la oportunidad.