Helm: O escopo libera nomes para namespaces

Não tenho certeza se entendi você. Você deseja implantar em vários namespaces, tendo apenas um nome de lançamento?

@ 21stio Exatamente. dos documentos do Kubernetes:

O Kubernetes oferece suporte a vários clusters virtuais apoiados pelo mesmo cluster físico. Esses clusters virtuais são chamados de namespaces.

e

Os namespaces fornecem um escopo para nomes. Os nomes dos recursos precisam ser exclusivos em um namespace, mas não entre os namespaces.

Pessoalmente, não consigo pensar em uma boa razão para o helm não respeitar esse conceito de namespaces.

Eu concordo. Todos os meus namespaces estão na forma de ${site}-${environment} , mas minhas liberações são ${site}-${environment}-${description} . Onde site pode ser internal ou www e environment pode ser dev , staging ou team-a , team-b e description podem ser algo como nginx , migrations , cache etc.

Mas o ${site}-${environment} é extremamente 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

É o que eu acabo com, mas eu preferia que os pods fossem apenas redis-1234567890.. ou proxy-9876543210..

Eu uso meu nome de versão em meu modelo de gráfico, então todos os meus nomes de serviço e pod incluem todas essas coisas extras. Já passei o namespace para os modelos, então, se eu quisesse, poderia facilmente incluir isso no nome se eu quisesse, mas do jeito que está agora, faz parte de todos os meus nomes de recursos usando a estrutura de comando padrão.

Os namespaces do K8s já são um namespace para nós, realmente não gosto de ter que prefixar todas as minhas coisas com o namespace quando os namespaces são projetados para ajudar a evitar conflitos.

Explicitamente, seria muito bom se eu pudesse fazer as mesmas coisas que faço com serviços e outros tipos nativos de k8s com gráficos de helm relacionados ao namespace.

Por exemplo, eu gostaria de ser capaz de fazer o seguinte:

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

@Janpot @bcorijn A suposição feita acima é que os gráficos do Helm funcionam apenas com objetos encapsulados dentro de namespaces. Não desejamos confinar Helm apenas a esses tipos de recursos.

E quanto aos recursos de terceiros, que não têm namespaces? Ou RBACs, em que "namespace" é um atributo de política, não um local (https://kubernetes.io/docs/admin/authorization/)?

Sei que já disse isso várias vezes em outro lugar, mas nosso objetivo final é possibilitar a implantação de recursos em vários namespaces a partir do mesmo gráfico. (Caso de uso: um aplicativo tem um plano de controle e um plano de dados, e você deseja implantá-los em namespaces separados para criar limites de segurança)

Se vincularmos uma liberação a um namespace, perdemos a capacidade de:

1. Gerenciar diretamente namespaces
2. Gerenciar RBACs e contas de serviço
3. Gerenciar TPRs (e quaisquer outros objetos sem namespace)
4. Eventualmente, suporte gráficos de vários namespaces.

Eu entendo que isso torna o problema de nomenclatura um pouco mais difícil para você, mas permite que o Helm opere em uma gama muito mais ampla de recursos do Kubernetes.

seria possível oferecer suporte a versões com e sem espaço de nomes?

@technosophos , para resumir, há dois
1) Gerenciar recursos que não têm namespaces
2) Planos futuros para permitir a instalação de gráficos no namespace

Eu entendo seu ponto, mas não tenho certeza se é um motivo para manter a implementação atual, pois tenho a impressão de que você também precisa forçá-la um pouco para resolver essas preocupações.

Para que os gráficos de vários namespaces funcionem bem / nativamente, você provavelmente precisaria de uma grande reformulação no sistema de namespacing, já que o conceito atual de Helm colocar releases em um namespace não funciona? _EDIT: Acabei de perceber que se os lançamentos fossem realmente com namespace, um gráfico com vários namespaces poderia ser apenas um gráfico abrangente contendo dois lançamentos com um namespace diferente? _

Para gerenciar recursos sem espaço de nomes; Não tenho experiência pessoal com isso, então é um pouco difícil de julgar, mas novamente sinto que isso está forçando o Helm a uma forma menos do que perfeita de trabalhar agora, já que um Release que gerencia namespaces, RBAC ou TPRs terão um namespace mas apenas ignorar isso?
Posso estar perdendo algo por não ter experiência com eles, mas não definir o escopo dos nomes e ignorar o namespace ter o mesmo resultado final, apenas colocaria mais responsabilidade sobre o usuário para verificar se seus nomes de lançamento e seletores são correto / exclusivo ao lidar com esses recursos. (o que eu concordo é totalmente responsabilidade)

Portanto, talvez apenas definir o escopo dos lançamentos não seja o caminho a percorrer, mas vale a pena dar uma outra olhada na maneira como eles são tratados no Helm e serão tratados no futuro? Ter ambas as opções como @Janpot menciona pode funcionar, lançamentos "globais" e lançamentos com namespace?
Minha opinião _muito pessoal_ também é que implantar da maneira que @ kylebyerly-hp, @chancez e eu descrevemos acima é muito mais comum do que os dois casos de uso que impedem essa maneira de trabalhar.

Primeiro, deixe-me reiterar o ponto principal: os gráficos do Helm operam em um nível global, não em um nível de namespace. Portanto, seus nomes são globalmente únicos.

Para gráficos com vários namespaces, o que precisamos corrigir é a capacidade de Tiller de consultar entre namespaces. (Você pode realmente _instalar_ gráficos com vários namespaces agora. Você simplesmente não pode atualizá-los ou excluí-los de forma confiável, porque o Tiller não pode consultá-los de forma confiável).

Para itens sem namespace, as coisas ficariam muito complicadas. Teríamos lançamentos com namespaces gerenciando coisas sem namespaces que, por sua vez, poderiam impactar outros namespaces. Por favor, dê uma olhada em como funcionam os RBACs e os TPRs. Não são coisas que o Helm pode simplesmente decidir não suportar, e "falsificar" um namespace causaria mais problemas do que vale a pena, especialmente com RBACs.

Eu ainda não vi um bom motivo para colocar um nome de lançamento no namespace. Suas reclamações iniciais são baseadas em um mal-entendido de que todas as coisas (importantes) no Kubernetes têm como escopo um namespace. Mas coisas importantes como TPRs e RBACs não são. A maior parte das outras reclamações parece ser mais sobre o fato de que os esquemas de nomenclatura _ad hoc_ que eles usam "não são bonitos" com o Helm. Contornar isso criando uma ENORME mudança de compatibilidade que representa erroneamente as versões como "em um namespace" parece a abordagem errada a ser tomada.

@technosophos

Você pode instalar gráficos com vários namespaces agora

Como? Onde a noção sobre namespaces deve ser colocada na configuração?

Você planeja oferecer suporte oficialmente a lançamentos de vários namespaces?

Não planejamos oferecer suporte total a versões com vários espaços de nomes até o Helm 3.0, porque isso quebrará a compatibilidade com versões anteriores e exigirá uma grande refatoração de grande parte do código do Kubernetes do Helm / Tiller.

Infelizmente para nós, não sermos capazes de implantar e gerenciar vários namespaces usando o helm é um problema.

Nosso plano era criar um gráfico guarda-chuva, que teria todos os nossos aplicativos (por exemplo, gráficos menores) como dependências. Todos os nossos aplicativos vivem em seus próprios namespaces, isso foi intencional (no futuro, gostaríamos de ter RBAC por namespace). Com um gráfico abrangente, poderíamos instalar e atualizar o cluster inteiro de microsserviços diferentes de uma vez, com apenas um values.yml , o que seria muito conveniente.

@technosophos , obrigado. Observado no fato de que o suporte para os itens acima não chegará em breve, pelo menos não até o Helm 3.0.

Existe uma ideia geral do que exatamente precisa ser refatorado no Helm / Tiller para oferecer suporte a vários namespaces? Ou o 3.0 está muito longe?

Recorremos a tratar o leme name mais como um UUID, usando --name-template e deixando-o gerar um nome simples, mas aleatório. Não posso dizer que prefiro isso a respeitar o namespace em si, mas vejo os dois pontos e, para nós, isso será suficiente com sobrecarga mínima.

por exemplo, 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 como você encontrará o nome do redis (uvtiwh) em seus aplicativos para se conectar a ele?

Um padrão que estou pensando em usar em nossos clusters é:

• Uma instância do Tiller em kube-system , para ser usado por administradores de cluster
• Uma instância do Tiller por namespace, com permissões RBAC mais limitadas, para ser usado pela equipe de desenvolvedores que possui esse namespace

O princípio de design "Os nomes de lançamento do Helm são globalmente exclusivos" é uma dor de cabeça para implantações soft-multitenant como a nossa, portanto, estou interessado em ouvir mais sobre a abordagem recomendada!

Fiquei muito desapontado quando descobri que o Helm não adere ao conceito de identificação de lançamentos com base em seu nome e namespace. Em minha opinião, isso não segue os princípios de design do Kubernetes, em que os recursos são exclusivos em seus respectivos namespaces (com exceção de alguns recursos globais).

Como outros participantes comentaram neste tópico, temos vários namespaces com sufixo de ambiente para diferentes grupos de aplicativos. Temos centenas de implantações diferentes, cada uma em três ou quatro ambientes. Dependemos muito dos nomes DNS exclusivos dentro de namespaces para que possamos nos referir a serviços com o mesmo nome em diferentes namespaces; por exemplo. nosso serviço redis pode ser acessado por tcp: // redis no namespace a-test e a-prod , onde ambos os namespaces possuem uma versão implementada do redis.

Almejando isso como um ponto de discussão para o leme 3. Parece que há uma grande demanda para isso.

Ponto contrário:

Praticamente todas as nossas árvores de gráfico implantam artefatos em vários namespaces divididos ao longo de linhas de persistência / API / ALB de nível 7 (+ estático). Desse ponto de vista, AMO o fato de que os nomes de versão do leme são globais.

Presença encontrada da opção --namespace em helm semi-inútil do ponto de vista da montagem de aplicativos em várias camadas, onde camadas de base podem ser reutilizadas por camadas superiores implantadas em vermelho / azul. Em vez de injetar strings derivadas de {{ .Release.Name }} nos nomes dos artefatos, criamos um novo namespace para cada implantação. Isso nos permite propagar URLs de serviço formados de forma determinística por meio de configurações encadeadas ( same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local ).

Como os nomes de versão gerados automaticamente são gobbledygook de qualquer maneira - sem fidelidade ao que está por trás daquela coisa em helm list , substituímos --name por uma string derivada do nome do produto / pilha e uma versão monotonicamente crescente / build version ( "appname-v20171103xyz" ) Adoraria ser capaz de definir o valor de --name-template em algum lugar no gráfico e apenas usar o nome do gráfico + datetime derivado ou valor de ID de construção explícito.

Exemplo

Camada de persistência 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 }}"
...

Consumido de outro namespace como:

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"

Os 2 modelos acima são partes de 2 gráficos separados (gráfico de persistência e gráfico de API) e podem ser executados separadamente ou em conjunto por meio de um terceiro gráfico abrangente. Em ambos os casos, devido ao uso de .global. os valores são substituídos uma vez na linha de comando e se aplicam de forma limpa a todos os subgráficos.

Com essa abordagem, como o valor do namespace de destino às vezes é um derivado parcial de ReleaseName e às vezes é semifixo, basicamente contamos com ReleaseName para ser global, de modo que o sistema reclamaria se tentarmos criar uma pilha com o mesmo ReleaseName global.

Um dos benefícios de ter e usar namespaces é que os nomes de objetos (incluindo nomes DNS) dentro deles são locais e não precisam mudar de namespace para namespace. Especificamente no exemplo @dvdotsenko acima, o REDIS_SERVER_HOSTNAME deve ser o mesmo (por exemplo, apenas redis ) e não deve precisar ser injetado com valores globalizados. O motivo é evitar a repetição.

Do ponto de vista da simplicidade (e deixando de lado alguns casos naturalmente complexos, como implementações de vários namespaces e objetos sem namespace), o caso ideal é que o namespace "monte" sua pilha e contenha exatamente uma instância de seu aplicativo.

Isso permite que os nomes na pilha sejam locais, simples e, o mais importante, fixos, pois são relativos ao namespace.

Uma abordagem possível é que o helm suporte o caso simples mais ou menos como faz hoje (enquanto evita prefixar objetos com namespace); isso produzirá um padrão de prática recomendada razoável e seguro que funcionará imediatamente para a maioria dos usos. Ele também pode ter um modo de namespace avançado que permitirá mais liberdade (em detrimento da complexidade), para permitir os casos de uso que @dvdotsenko e @bcorijn descrevem.

Meus $ 0,02

Tenho que concordar com @pnickolov , este é um grande bloqueador para nós. Em nosso caso de uso, temos mais de 150 ambientes e vários clusters que devem executar variantes da mesma pilha de aplicativos. Os namespaces resolvem esse problema permitindo a separação de ambientes e simplicidade de configuração, principalmente em relação à descoberta de serviço.

Sem uma maneira fácil de configurar pontos finais de serviço em gráficos irmãos ... Puramente por meio de valores ...

Eu também acho isso confuso. Como @technosophos escreve :

Uma versão não está vinculada a um namespace. (É por isso que uma versão em si pode conter uma definição de namespace). Na verdade, deveria ser possível (embora eu não possa dizer que tentei pessoalmente) implantar um único gráfico que cria vários objetos em vários namespaces.

Estou lutando para entender exatamente isso. Eu olhei a documentação e vários problemas aqui no GH e ainda estou confuso:

• Por um lado, posso usar helm install --namespace para especificar o namespace que gostaria de segmentar
• Por outro lado, meu gráfico pode especificar quaisquer namespaces que desejar dentro de seus objetos de metadados.

Então, minhas perguntas:

• Se o namespace especificado por helm install --namespace não existir, o Helm o criará? Em seguida, ele define esse namespace em todos os recursos que cria a partir do chrt?
• Se um template de recurso especifica um namespace em seus metadados, o helm o sobrescreve?

Essas perguntas me deixaram hesitante em até mesmo jogar com --namespace , não está claro. Se alguém puder me ajudar a entender isso, eu realmente apreciaria. Obrigada!

Se o namespace especificado por helm install --namespace não existir, o Helm o cria?

sim. Se o namespace ainda não existir, --namespace criará o namespace especificado para o gráfico.

Se um template de recurso especifica um namespace em seus metadados, o helm o sobrescreve?

Não. Se acontecer de você fornecer o mesmo namespace em --namespace , bem como o recurso de namespace no gráfico, haverá um conflito, pois o namespace será instalado primeiro pelo tiller e, em seguida, bork quando o gráfico tentar reinstale o mesmo namespace novamente.

Para mais contexto, a ideia do helm é instalar todos os recursos no namespace fornecido por helm install --namespace . Os usuários que estão "codificando" o namespace no gráfico geralmente desejam instalar um gráfico em vários namespaces.

Isso está um pouco fora do tópico sugerido pelo OP, mas sinta-se à vontade para abrir um novo tíquete ou junte-se a nós no Slack se tiver mais perguntas! :)

Não tenho certeza se quero entrar nesta discussão 😄 Seja gentil, por favor 🙏

O parâmetro helm --namespace é realmente --default-namespace

Lendo a pilha e relacionados, parece haver muita confusão em torno da opção --namespace porque as pessoas (razoavelmente) assumem que é como o kubectl --namespace que estão acostumadas, o que efetivamente limita a atividade a esse namespace (por o efeito colateral de um erro de análise, não realmente segurança). Esse não é o caso de helm pois tiller é um serviço de cluster que opera em todo o cluster. A opção teria sido melhor nomeada --default-namespace , ou seja. este é o namespace para o qual seus recursos irão se não especificarem um determinado namespace.

Versões de vários namespaces também são necessárias

Já conto com gráficos que implantam diferentes componentes de cada versão em vários namespaces e estou ansioso para obter suporte aprimorado no helm 3.0. 👍 🎉

Multi-tenant com restrições de helm e namespace já é possível

Também vejo o caso de uso em que as pessoas desejam instalações multilocatário com restrição de namespace. O escopo IMHO ou restringir liberações para namespaces não é algo que helm / tiller deveria se preocupar em fazer cumprir, esse é o trabalho do RBAC. Existem pelo menos dois modelos para conseguir isso, um é possível agora:

1. Implante um namespace por tiller com uma conta de serviço e RBAC que só permite operações nesse namespace. Isso funciona agora e vejo pessoas usando. Ideal para clusters multilocatários.
2. Por tiller para suportar a personificação do usuário k8s , e assim implantar cada versão como o usuário helm . Isso está sendo discutido para futuras versões de helm e parece ter alguns desafios de implementação. Mas isso permitiria que um serviço de cluster tiller imponha restrições de namespace RBAC, ao mesmo tempo que oferece suporte a lançamentos que abrangem vários namespaces.

Recursos com o mesmo nome para diferentes versões em diferentes namespaces já são possíveis

Para pessoas que desejam instalar o mesmo gráfico em namespaces diferentes, mas com os mesmos nomes de recursos (por exemplo, redis). Isso é perfeitamente possível, dependendo de como você escreve seus modelos de gráfico. Você não precisa prefixar os nomes dos recursos com o nome da versão, que é apenas um padrão / convenção que muitos gráficos seguem. Os gráficos recentes já têm o .fullnameOverride que permite anular o prefixo do nome do lançamento. Você pode implantar seu redis como redis com cada helm install se desejar.

Estamos em uma situação semelhante a @gmile e queríamos saber qual é a melhor prática para fazer isso. Nosso aplicativo principal, ingestion-service , depende de kafka que, por sua vez, depende de zookeeper . Mas, queremos todos os três em seus próprios namespaces, mas queremos gerenciá-los por meio de um único comando install . Estávamos planejando adicionar kafka em requirements.yaml de ingestion-service . Mas obter kafka em seu próprio namespace não parece simples com helm então o que buscamos foi remover de requirements.yaml e ter helm install para ambas as implantações .

Apenas um FYI de que isso é observado e parte da proposta do Leme 3 listada na Seção 3: Gestão do Estado . Feedback seja bem-vindo!

Isso é uma notícia fantástica @bacongobbler 😄🎉

@bacongobbler O Helm 3 está procurando oferecer suporte à especificação de namespaces separados para gráficos dependentes em requirements.yaml como @ prat0318 descrito?

Do documento da proposta (leia!: Sorria :):

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

Como no Helm 2, se um recurso declarar explicitamente seu próprio namespace (por exemplo, com metadata.namespace = something), o Helm o instalará nesse namespace. Mas, uma vez que as referências do proprietário não prevalecem sobre os namespaces, qualquer recurso desse tipo se tornará basicamente não gerenciado.

@bacongobbler Eu li, mas ainda não vejo como apoiando. Não quero dizer metadata.namespace codificado em gráficos que eu controlo, isso sempre foi suportado. O que quero dizer é especificar o namespace para um gráfico de terceiros que não posso editar. Por exemplo, em meu requirements.yaml eu dependo de stable / kubernetes-dashboard e quero que ele seja instalado no kube-system, mas meu gráfico vai para o namespace de desenvolvimento.

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

Parece que essa mesma solicitação de recurso pode ser atendida por helmfile . Pelo que está no readme, deve ser possível especificar diferentes releases com escopo para namespaces próprios.

@gmile Tenho 99% de certeza que os mantenedores do helmfile não corrigiram esse problema específico no helmfile. Se você declarar duas versões chamadas vault com namespaces diferentes em seu helmfile.yaml e executar helmfile sync , ele falhará porque o nome da versão vault foi reivindicado pela primeira versão.

isenção de responsabilidade: Eu não testei isso usando o helmfile, então adoraria saber que estou errado. 😄

Caso o último comentário tenha sido esquecido, estamos tratando disso no Helm 3 com as alterações em como o Helm lida com as versões . :)

@ steven-sheehy esse problema específico provavelmente poderia ser corrigido por meio do modelo de sandboxing estendendo o subchart para implantar em um namespace específico diferente do definido.

/ remove-lifecycle stale

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

Implementado no Helm 3. Alterar o contexto do namespace refere-se a uma instância totalmente 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

Boas notícias,

Dada essa mudança, faria sentido que a coluna do namespace fosse movida para a primeira coluna na saída list . Para que as duas primeiras colunas identifiquem exclusivamente o lançamento?

A classificação padrão pode ser por namespace e release, de forma que releases no mesmo namespace sejam agrupados, por exemplo, todos os kube-system releases estariam juntos.

Certo.

por agora, eu só uso

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

Sim, a maneira como as coisas funcionam atualmente é péssima, mas tudo o que você precisa é de nomes globalmente exclusivos para gerenciar, e não há razão para que você não possa simplesmente criar uma chave composta para o nome do lançamento.

Ok, então parece que existem 3 cenários fundamentais (com potencial para várias permutações misturando cada um):

1. gráfico com namespace único.
2. recurso que não tem espaço para nomes.
3. gráfico com vários namespaces.

Esta seria uma abordagem razoável para abordar os diferentes cenários:

1. injetar / substituir o namespace quando fornecido com o sinalizador --namespace .
2. igual a 1, mas ignore o namespace para os recursos que não possuem um namespace.
3. exit citando o recurso "não pode substituir um multi-namespace" ou similar.

Aparte: eu não uso o leme, preferindo helm template então não tenho certeza de quanto isso muda os desafios.

@technosophos

Estou tentando entender como Helm v2 interage com namespaces e como a v3 será diferente, e um de seus comentários antigos neste tópico me confunde:

Primeiro, deixe-me reiterar o ponto principal: os gráficos do Helm operam em um nível global, não em um nível de namespace. Portanto, seus nomes são globalmente únicos.

....

Para itens sem namespace, as coisas ficariam muito complicadas. Teríamos lançamentos com namespaces gerenciando coisas sem namespaces que, por sua vez, poderiam impactar outros namespaces. Por favor, dê uma olhada em como funcionam os RBACs e os TPRs. Não são coisas que o Helm pode simplesmente decidir não suportar, e "falsificar" um namespace causaria mais problemas do que vale a pena, especialmente com RBACs.

Parece que as versões implantadas do Helm v3 terão, na verdade, um namespace; isso está correto? Você sabe como o problema RBAC foi resolvido? A única resolução que consigo pensar que evitaria o problema que você apontou é que os gráficos do Helm v3 não suportem a modificação de objetos RBAC, mas não encontrei nada nas várias postagens de blog sobre a v3 indicando se os gráficos da v3 suportam o gerenciamento Objetos RBAC ou não.

Tudo o que realmente precisamos é sermos capazes de usar o parâmetro de namespace e
parâmetro de nome como uma chave composta para identificar uma liberação em vez de afixar
um namespace em um nome.

Eu não li a proposta para o helm v3, mas a coisa mais sensata a fazer é
adote o padrão seletor que o k8s já usa e não há necessidade de
suporte quaisquer campos específicos.

Na terça - feira, 25 de junho de 2019, 11:01, BatmanAoD

@technosophos https://github.com/technosophos

Estou tentando entender como o Helm v2 interage com namespaces e como a v3
será diferente, e um de seus comentários antigos neste tópico me confunde:

Primeiro, deixe-me reiterar o ponto principal: os gráficos do Helm operam em uma escala global
nível, não em um nível de namespace. Portanto, seus nomes são globalmente únicos ....

Para itens sem namespace, as coisas ficariam muito complicadas. Teríamos
lançamentos com namespace gerenciando coisas sem namespace que, por sua vez, poderiam
impactar outros namespaces. Por favor, dê uma olhada em como funcionam os RBACs e os TPRs.
Não são coisas que Helm pode simplesmente decidir não apoiar, e
"falsificar" um namespace causaria mais problemas do que vale a pena, especialmente
com RBACs.

Parece que as versões implantadas do Helm v3 terão, na verdade, um namespace;
isso está correto? Você sabe como o problema RBAC foi resolvido? O único
resolução posso pensar que evitaria o problema que você apontou é para
Os gráficos do Helm v3 não são compatíveis com a modificação de objetos RBAC, mas não encontrei
qualquer coisa nas várias postagens do blog e tal sobre a v3, indicando se a v3
os gráficos suportam o gerenciamento de objetos RBAC ou não.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYRCWFI#issuecomment-505555733 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

@BatmanAoD @gyndick No Helm v3, os gráficos são instalados no contexto do usuário. Isso significa que ele está instalado nesse namespace do usuário e usará o RBAC do usuário. Os nomes de lançamento também são baseados em namespaces.

Você pode experimentá-lo com a versão Alpha.1: https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 ou compilar a partir do branch dev-v3 .

Não usarei o helm v3. Cada equipe de operações tem diferentes
restrições e formas de fazer as coisas. As ferramentas operacionais devem ser simples,
utilitários de propósito único, ou seja, compatível com a filosofia Unix.

Meu script, lógica, etc. ficam fora do meu gerenciador de pacotes.

TLDR;

O aspecto mais importante de ser compatível com a filosofia Unix é o
capacidade de fornecer saídas de emergência entre as etapas.

Ter um fluxo de trabalho longo e automatizado que cuida da logística de
Do berço ao túmulo é incrível, até quebrar. Se os usuários não forem fornecidos
capacidade de executar manualmente cada etapa do fluxo de automação necessária
torna-se a caixa de Pandora.

A complexidade proposta para v3 irá convidar muitos, muitos erros e ruins
design de pessoas que não têm o benefício de 25 anos de experiência.

A complexidade adicional só tornará as coisas mais difíceis de fazer porque, invariavelmente,
ferramentas operacionais que se tornam ambientes de desenvolvimento próprios apenas
desacelerar a triagem.

O exemplo perfeito é quando alguém codifica em um enorme, horrivelmente
script escrito. Uma interrupção acontece e partes do script precisam ser executadas,
outras partes precisam ser estritamente evitadas, mas essas partes são essenciais para
a lógica principal. O que diabos você faz então? Sente-se a tentar freneticamente
para refatorar o código que você realmente não tem uma boa maneira de depurar.

Pense em todas as ferramentas que entram em um ecossistema para oferecer suporte
desenvolver e operar software em qualquer idioma específico. Você não é
vai ser capaz de fornecer isso para o leme por algum tempo.

Portanto, mantenha a responsabilidade de como gerenciar a migração entre as versões do
software com as pessoas que desenvolvem o software que está sendo implantado.

Um gerenciador de pacotes deve ser simples e leve, com apenas alguns dos
responsabilidades.

1. Entregar artefatos
2. Remover artefatos
3. Execute os scripts fornecidos nos artefatos
4. Acompanhe os artefatos que ele acha que entregou
5. Mais importante ainda, KISS

Qualquer outra coisa está pedindo dor. Francamente, o helm v2 seria quase perfeito
se apenas consertasse como controlava os lançamentos.

Na quarta-feira, 26 de junho de 2019, 1h31, Martin Hickey [email protected]
escreveu:

@BatmanAoD https://github.com/BatmanAoD @gyndick No Helm v3, os gráficos são
instalado no contexto do usuário. Isso significa que está instalado naquele usuário
namespace e usará o RBAC do usuário. Os nomes de lançamento estão em um
base de namespace também.

Você pode experimentar com a versão Alpha.1:
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 ou compilar a partir de
o branch dev-v3.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYSYR7A#issuecomment-505776380 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

@hickeyma Obrigado pela resposta! Na verdade, não estou me perguntando tanto sobre como as operações do Helm serão controladas por acesso (embora isso seja um problema relacionado), mas se o próprio Helm ainda será capaz de realizar operações globais, como a criação de ClusterRoles na v3.

@BatmanAoD Isso deve funcionar porque são recursos com escopo de cluster. Pode valer a pena experimentar, se você tiver uma chance.