Helm: 범위 지정은 네임스페이스에 이름을 릴리스합니다.

내가 당신을 이해하는지 잘 모르겠습니다. 릴리스 이름이 하나만 있는 상태에서 여러 네임스페이스에 배포하고 싶습니까?

@21stio 맞습니다. Kubernetes 문서에서:

Kubernetes는 동일한 물리적 클러스터에서 지원하는 여러 가상 클러스터를 지원합니다. 이러한 가상 클러스터를 네임스페이스라고 합니다.

그리고

네임스페이스는 이름의 범위를 제공합니다. 리소스 이름은 네임스페이스 내에서 고유해야 하지만 네임스페이스 간에는 고유해야 합니다.

개인적으로 나는 helm이 이 네임스페이스 개념을 존중하지 않는 이유를 생각할 수 없습니다.

나는 동의한다. 내 모든 네임스페이스는 ${site}-${environment} 이지만 내 릴리스는 ${site}-${environment}-${description} 입니다. site 는 internal 또는 www 이고 environment 는 dev , staging 또는 team-a , team-b 및 description 는 nginx , migrations , cache 등과 같을 수 있습니다.

그러나 ${site}-${environment} 는 매우 중복됩니다.

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

내가 끝내는 것이지만 포드가 redis-1234567890.. 또는 proxy-9876543210.. 것을 선호합니다.

내 차트 템플릿에서 내 릴리스 이름을 사용하므로 모든 서비스 및 포드 이름에 이 추가 항목이 모두 포함됩니다. 이미 템플릿에 네임스페이스를 전달했으므로 원하는 경우 이름에 이를 쉽게 포함할 수 있지만 지금은 기본 helm 스캐폴딩을 사용하여 모든 리소스 이름의 일부입니다.

K8의 네임스페이스는 이미 우리를 위한 네임스페이스입니다. 네임스페이스가 충돌을 방지하는 데 도움이 되도록 설계되었을 때 내 모든 것에 네임스페이스를 접두사로 붙여야 하는 것을 정말 싫어합니다.

명시 적으로 네임 스페이스와 관련된 helm 차트가있는 서비스 및 기타 k8s 기본 유형과 동일한 작업을 수행 할 수 있다면 정말 좋을 것입니다.

예를 들어 다음을 수행할 수 있기를 바랍니다.

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

@Janpot @bcorijn 위에서 만든 가정은 Helm 차트가 네임스페이스 내부에 캡슐화된 개체에서만 작동한다는 것입니다. Helm을 이러한 리소스 종류로만 제한하고 싶지는 않습니다.

네임스페이스가 지정되지 않은 타사 리소스는 어떻습니까? 또는 "네임스페이스"가 위치가 아니라 정책 속성인 RBAC(https://kubernetes.io/docs/admin/authorization/)?

다른 곳에서 여러 번 말했지만 우리의 궁극적인 목표는 동일한 차트에서 여러 네임스페이스에 리소스를 배포할 수 있도록 하는 것입니다. (사용 사례: 앱에 컨트롤 플레인과 데이터 플레인이 있으며 보안 경계를 만들기 위해 각각 별도의 네임스페이스에 배포하려는 경우)

릴리스를 네임스페이스에 바인딩하면 다음 기능을 잃게 됩니다.

1. 네임스페이스 직접 관리
2. RBAC 및 서비스 계정 관리
3. TPR(및 기타 네임스페이스가 없는 개체) 관리
4. 결국 다중 네임스페이스 차트를 지원합니다.

이렇게 하면 이름 지정 문제가 조금 더 어려워지지만 Helm이 훨씬 더 광범위한 Kubernetes 리소스에서 작동할 수 있다는 점을 이해합니다.

네임스페이스 및 비 네임스페이스 릴리스를 모두 지원할 수 있습니까?

@technosophos 요약하자면 두 가지 주요 동인이 있습니다.
1) 네임스페이스가 지정되지 않은 리소스 관리
2) 네임스페이스에 걸쳐 차트를 설치할 수 있도록 하는 향후 계획

귀하의 요점은 알지만 현재 구현을 고수해야 하는 이유인지 확실하지 않습니다. 이러한 문제를 해결하기 위해 약간 강제해야 한다는 인상을 받았기 때문입니다.

다중 네임스페이스 차트가 제대로 작동하려면 네임스페이스에 릴리스를 넣는 현재 개념이 작동하지 않기 때문에 네임스페이스 시스템에 대한 상당한 점검이 필요할 것입니다. _EDIT: 릴리스가 실제로 네임스페이스가 지정된 경우 다중 네임스페이스 차트는 네임스페이스가 다른 두 릴리스를 포함하는 우산 차트일 수 있다는 사실을 깨달았습니다._

네임스페이스가 아닌 리소스를 관리하기 위해 개인적 경험이 없어서 판단하기가 조금 어렵습니다. 하지만 이것이 Helm이 지금 당장은 완벽하지 않은 작업 방식을 강요하고 있다고 생각합니다. 하지만 그냥 무시?
경험이 없기 때문에 누락된 것일 수 있지만 이름의 범위를 지정하지 않고 네임스페이스를 무시하면 최종 결과가 동일합니다. 릴리스 이름과 선택기가 다음과 같은지 확인하는 사용자에게 더 많은 책임이 있습니다 이러한 자원을 다룰 때 정확하고 고유합니다. (동의하는 것은 상당한 책임입니다)

따라서 릴리스의 범위를 지정하는 것은 올바른 방법이 아니지만 Helm에서 처리되고 앞으로 처리될 방식을 다시 한 번 살펴보는 것이 가치가 있습니까? @Janpot이 언급한 대로 두 가지 옵션을 모두 사용하면 "전역" 릴리스와 네임스페이스 릴리스가 모두 작동할 수 있습니까?
내 _매우 개인적인_ 의견은 @kylebyerly-hp, @chancez 및 내가 위에서 설명한 방식으로 배포하는 것이 이러한 작동 방식을 방해하는 두 가지 사용 사례보다 훨씬 더 일반적이라는 것입니다.

먼저 요점을 다시 반복하겠습니다. Helm 차트는 네임스페이스 수준이 아니라 전역 수준에서 작동합니다. 따라서 그들의 이름은 전 세계적으로 고유합니다.

다중 네임스페이스 차트의 경우 수정해야 하는 것은 Tiller의 네임스페이스 쿼리 기능입니다. (지금 실제로 다중 네임스페이스 차트를 _install_할 수 있습니다. Tiller가 안정적으로 쿼리할 수 없기 때문에 안정적으로 업그레이드하거나 삭제할 수 없습니다.)

네임스페이스가 없는 항목의 경우 상황이 매우 복잡해집니다. 다른 네임스페이스에 영향을 줄 수 있는 네임스페이스가 없는 항목을 관리하는 네임스페이스 릴리스가 있을 것입니다. RBAC와 TPR이 어떻게 작동하는지 살펴보십시오. 이것은 Helm이 단순히 지원하지 않기로 결정할 수 있는 것이 아니며 네임스페이스를 "위조"하면 특히 RBAC에서 가치보다 더 많은 문제가 발생할 수 있습니다.

아직 릴리스 이름을 네임스페이스로 지정해야 하는 타당한 이유를 보지 못했습니다. 귀하의 초기 불만은 Kubernetes의 모든 (중요한) 항목이 네임스페이스로 범위가 지정된다는 오해를 기반으로 합니다. 그러나 TPR 및 RBAC와 같은 중요한 것은 그렇지 않습니다. 다른 불만의 대부분은 그들이 사용하는 _ad hoc_ 명명 체계가 Helm에서 "예쁘지 않다"는 사실에 대한 것입니다. 릴리스를 "이름 공간에서"로 잘못 표현하는 거대한 호환성 파괴 변경을 만들어 이를 해결하는 것은 잘못된 접근 방식처럼 보입니다.

@technosophos

이제 실제로 다중 네임스페이스 차트를 설치할 수 있습니다.

어떻게? 구성에서 네임스페이스에 대한 개념을 어디에 넣어야 합니까?

다중 네임스페이스 릴리스를 공식적으로 지원할 계획입니까?

Helm 3.0까지는 다중 네임스페이스 릴리스를 완전히 지원할 계획이 없습니다. 그렇게 하면 이전 버전과의 호환성이 깨지고 Helm/Tiller의 Kubernetes 코드 대부분에 대한 주요 리팩터링이 필요하기 때문입니다.

불행히도 helm을 사용하여 여러 네임스페이스를 배포 및 관리할 수 없다는 것은 문제입니다.

우리의 계획은 모든 앱(예: 더 작은 차트)을 종속성으로 포함하는 우산형 차트를 만드는 것이었습니다. 우리의 모든 앱은 자체 네임스페이스에 있습니다. 이것은 의도적으로 설계된 것입니다(미래에는 네임스페이스당 RBAC를 갖기를 원합니다). 우산형 차트를 사용하면 단 하나의 values.yml 만 주어지면 서로 다른 마이크로서비스의 전체 클러스터를 한 번에 설치 및 업그레이드할 수 있으므로 정말 편리합니다.

@technosophos , 감사합니다. 위의 지원은 적어도 Helm 3.0까지는 곧 도착하지 않을 것이라는 사실에 주목했습니다.

여러 네임스페이스를 지원하기 위해 Helm/Tiller에서 정확히 무엇을 리팩토링해야 하는지에 대한 일반적인 아이디어가 있습니까? 아니면 3.0이 너무 먼가요?

--name-template 하고 단순하지만 임의의 이름을 생성하도록 하여 name 를 UUID에 더 가깝게 취급했습니다. 나는 네임스페이스 자체를 존중하는 것보다 이것을 선호한다고 말할 수는 없지만 두 가지 점을 모두 볼 수 있으며 우리에게는 이것이 최소한의 오버헤드로 충분할 것입니다.

예: 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 연결하기 위해 앱에서 redis(uvtiwh)의 이름을 어떻게 찾을 수 있습니까?

클러스터에서 사용하려고 고려 중인 패턴은 다음과 같습니다.

• 클러스터 관리자가 사용할 kube-system Tiller 인스턴스 1개
• 네임스페이스당 하나의 Tiller 인스턴스(RBAC 권한이 더 제한되어 해당 네임스페이스를 소유한 개발자 팀에서 사용할 수 있음)

"Helm 릴리스 이름은 전 세계적으로 고유합니다" 디자인 원칙은 우리와 같은 소프트 다중 테넌트 배포의 골칫거리이므로 권장되는 접근 방식에 대해 더 듣고 싶습니다!

Helm이 이름과 네임스페이스를 기반으로 릴리스를 식별하는 개념을 준수하지 않는다는 사실을 알고 매우 실망했습니다. 내 생각에 이것은 리소스가 해당 네임스페이스 내에서 고유한 Kubernetes의 설계 원칙을 따르지 않습니다(일부 글로벌 리소스 제외).

이 스레드에서 다른 포스터가 언급했듯이 우리는 서로 다른 애플리케이션 그룹에 대해 여러 환경 접미사 네임스페이스를 가지고 있습니다. 3~4개의 환경에 각각 수백 개의 서로 다른 배포가 있습니다. 다른 네임스페이스 내에서 동일한 이름을 가진 서비스를 참조할 수 있도록 네임스페이스 내의 고유한 DNS 이름에 크게 의존합니다. 예를 들어 redis 서비스는 a-test 및 a-prod 네임스페이스 모두에서 tcp://redis 를 통해 액세스할 수 있습니다

이를 helm 3의 논의 포인트로 삼고 있습니다. 이에 대한 수요가 많은 것으로 보입니다.

반대 포인트:

거의 모든 차트 트리는 지속성 / API / Level7 ALB(+static) 라인을 따라 분할된 여러 네임스페이스에 아티팩트를 배포합니다. 투구 릴리스 이름이 세계적이라는 사실이 독립 포인트 사랑에서.

helm 에 --namespace 옵션이 있음을 발견했습니다. 기본 계층은 빨강/파랑 배치된 상위 계층에서 재사용될 수 있는 다중 계층 응용 프로그램의 조립 관점에서 거의 쓸모가 없습니다. {{ .Release.Name }} 파생 문자열을 아티팩트의 이름에 주입하는 대신 각 배포에 대해 새 네임스페이스를 만듭니다. 이를 통해 연결 구성( same_service_name.some_product_release20171102a.svc.cluster.local > same_service_name.some_product_release20171105c.svc.cluster.local )을 통해 결정적으로 형성된 서비스 URL을 전파할 수 있습니다.

자동 생성된 릴리스 이름은 어쨌든 gobbledygook이기 때문에 helm list 뒤에 있는 내용에 충실하지 않습니다 --name / 빌드 버전( "appname-v20171103xyz" ) 차트 어딘가에 --name-template 값을 정의하고 차트 이름 + 날짜/시간 파생 또는 명시적 빌드 ID 값을 사용하도록 하고 싶습니다.

예시

기본 지속성 계층

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

다음과 같이 다른 네임스페이스에서 사용됩니다.

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"

위의 2개 템플릿은 2개의 개별 차트(지속성 차트 및 API 차트)의 일부이며 세 번째 포괄적인 차트를 통해 개별적으로 또는 공동으로 실행할 수 있습니다. 두 경우 모두 .global. 를 사용하기 때문에 값이 명령줄에서 한 번 재정의되고 모든 하위 차트에 깔끔하게 적용됩니다.

이 접근 방식을 사용하면 대상 네임스페이스 값이 때때로 ReleaseName의 부분 파생물이고 때로는 반고정되기 때문에 우리는 ReleaseName이 전역이 되도록 거의 의존하므로 동일한 전역 ReleaseName으로 스택을 생성하려고 하면 시스템이 불평할 것입니다.

네임스페이스를 갖고 사용하는 이점 중 하나는 그 안에 있는 개체 이름(DNS 이름 포함)이 로컬이며 네임스페이스에서 네임스페이스로 변경할 필요가 없다는 것입니다. 특히 위의 @dvdotsenko 예에서 redis ) 글로벌화된 값을 주입할 필요가 없습니다. 그 이유는 반복을 피하기 때문입니다.

단순성 관점에서(그리고 다중 네임스페이스 배포 및 네임스페이스가 없는 객체와 같은 일부 자연적으로 복잡한 경우는 제외하고) 이상적인 경우는 네임스페이스가 스택을 "어셈블"하고 애플리케이션의 정확히 하나의 인스턴스를 포함하는 것입니다.

이를 통해 스택 내의 이름이 지역적이고 단순하며 가장 중요하게는 이름 공간에 상대적이기 때문에 고정될 수 있습니다.

가능한 접근 방식은 helm이 오늘날과 같이 간단한 경우를 지원하는 것입니다(객체에 네임스페이스 접두사를 사용하는 것을 피하면서). 이렇게 하면 대부분의 용도에서 즉시 사용할 수 있는 합리적이고 안전한 모범 사례 기본값이 생성됩니다. 또한 @dvdotsenko 및 @bcorijn이 설명하는 사용 사례를 허용하기 위해 더 많은 자유(복잡성을 희생하면서)를 허용하는 고급 네임스페이스 모드를 가질 수 있습니다.

내 $.02

@pnickolov 에 동의해야 합니다. 이것은 우리에게 주요 방해 요소입니다. 우리의 사용 사례에는 동일한 애플리케이션 스택의 변형을 실행해야 하는 150개 이상의 환경과 여러 클러스터가 있습니다. 네임스페이스는 특히 서비스 검색과 관련하여 환경을 분리하고 구성을 단순하게 하여 이 문제를 해결합니다.

형제 차트에서 서비스 끝점을 쉽게 구성할 수 있는 방법 없이는... 순전히 값을 통해...

이것도 헷갈립니다. @technosophos 는 다음과 같이

릴리스는 네임스페이스에 바인딩되지 않습니다. (이것이 릴리스 자체에 네임스페이스 정의가 포함될 수 있는 이유입니다). 사실, (개인적으로 시도했다고 말할 수는 없지만) 여러 네임스페이스에 여러 개체를 생성하는 단일 차트를 배포하는 것이 가능해야 합니다.

나는 이것을 정확히 이해하기 위해 고군분투하고 있다. 나는 문서를 보았고 여기 GH에 대한 몇 가지 문제를 보았지만 여전히 혼란 스럽습니다.

• 한편으로 helm install --namespace 를 사용하여 대상으로 지정하려는 네임스페이스를 지정할 수 있습니다.
• 반면에 내 차트는 메타데이터 개체 내에서 원하는 네임스페이스를 지정할 수 있습니다.

그래서, 내 질문 :

• helm install --namespace 지정된 네임스페이스가 존재하지 않으면 Helm에서 생성합니까? 그런 다음 chrt에서 생성하는 모든 리소스에 해당 네임스페이스를 설정합니까?
• 리소스 템플릿이 메타데이터에 네임스페이스를 지정하는 경우 helm이 이를 덮어쓰나요?

이러한 질문으로 인해 --namespace 하는 것조차 주저하게 되었습니다. 너무 명확하지 않습니다. 누군가가 나를 이해하도록 도울 수 있다면 정말 감사하겠습니다. 감사합니다!

f helm install --namespace 로 지정된 네임스페이스가 존재하지 않는 경우 Helm에서 생성합니까?

예. 네임스페이스가 아직 존재하지 않는 경우 --namespace 는 차트에 대해 지정된 네임스페이스를 생성합니다.

리소스 템플릿이 메타데이터에 네임스페이스를 지정하는 경우 helm이 이를 덮어쓰나요?

아니오. --namespace 에 동일한 네임스페이스를 제공하고 차트의 네임스페이스 리소스를 제공하는 경우, 네임스페이스가 먼저 tiler에 의해 설치되고 차트가 시도할 때 중단되므로 충돌이 발생합니다. 동일한 네임스페이스를 다시 설치하십시오.

추가 컨텍스트에서 helm에 대한 아이디어는 helm install --namespace 제공하는 네임스페이스에 모든 리소스를 설치하는 것입니다. 차트에서 네임스페이스를 "하드코딩"하는 사용자는 일반적으로 여러 네임스페이스에 차트를 설치하기를 원합니다.

이것은 OP가 제안하는 것과는 조금 다르지만, 추가 질문이 있는 경우 언제든지 새 티켓을 열거나 Slack에 가입하세요! :)

이 토론에 끼어들고 싶은지 잘 모르겠습니다 😄 친절하게 대해주세요 🙏

helm --namespace 매개변수는 실제로 --default-namespace입니다.

스택과 관련된 내용을 읽으면 --namespace 옵션 주위에 많은 혼란이 나타납니다. 왜냐하면 사람들은 (상당히 합리적으로) kubectl --namespace 과 비슷하다고 가정하여 해당 네임스페이스에 대한 활동을 효과적으로 제한하기 때문입니다. 실제로 보안이 아니라 구문 분석 오류의 부작용). tiller 는 전체 클러스터에서 작동하는 클러스터 서비스이므로 helm 의 경우는 그렇지 않습니다. 이 옵션은 --default-namespace 라는 이름이 더 좋았을 것입니다. 특정 네임스페이스를 지정하지 않으면 리소스가 이동하는 네임스페이스입니다.

다중 네임스페이스 릴리스도 필요합니다.

저는 이미 각 릴리스의 서로 다른 구성 요소를 여러 네임스페이스에 배포하는 차트에 의존하고 있으며 helm 3.0에서 향상된 지원을 기대하고 있습니다. 👍 🎉

helm 및 네임스페이스 제한이 있는 다중 테넌트가 이미 가능합니다.

또한 사람들이 다중 테넌트, 네임스페이스 제한 설치를 원하는 사용 사례도 봅니다. IMHO의 범위를 지정하거나 네임스페이스로 릴리스를 제한하는 것은 helm / tiller 가 아닌 강제 적용, 즉 RBAC의 작업입니다. 이를 달성하기 위한 최소 두 가지 모델이 있으며, 하나는 현재 가능합니다.

1. 해당 네임스페이스에서만 작업을 허용하는 RBAC 및 서비스 계정을 사용하여 네임스페이스당 tiller 을 배포합니다. 이것은 지금 작동하고 나는 그것을 사용하는 사람들을 봅니다. 다중 테넌트 클러스터에 이상적입니다.
2. tiller 가 k8s 사용자 가장 을 지원 를 helm 사용자로 배포합니다. 이것은 향후 helm 버전에 대해 논의 중이며 몇 가지 구현 문제가 있는 것으로 보입니다. 그러나 이렇게 하면 클러스터 서비스 tiller 에서 RBAC 네임스페이스 제한을 적용하는 동시에 다중 네임스페이스 확장 릴리스를 계속 지원합니다.

다른 네임스페이스의 다른 릴리스에 대해 동일한 이름의 리소스가 이미 가능합니다.

동일한 차트를 다른 네임스페이스에 설치하지만 동일한 리소스 이름(예: redis)을 사용하려는 사람들을 위한 것입니다. 그것은 전적으로 가능하며 차트 템플릿을 작성하는 방법에 달려 있습니다. 리소스 이름에 릴리스 이름을 접두사로 붙일 필요가 없습니다. 이는 많은 차트가 따르는 기본/관례일 뿐입니다. 최근 차트에는 릴리스 이름 접두사를 제거할 수 있는 .fullnameOverride 값 이 이미 있습니다. 원하는 경우 helm install 마다 redis 로 redis 를 배포할 수 있습니다.

우리는 @gmile 과 비슷한 상황에 있으며 ingestion-service 는 kafka 대한 종속성을 가지며, zookeeper 에 대한 종속성을 갖습니다. 그러나 우리는 세 가지 모두를 자체 네임스페이스에 포함하기를 원하지만 단일 키 install 통해 관리하기를 원합니다. kafka 의 requirements.yaml 에 ingestion-service kafka 를 추가할 계획이었습니다. 그러나 점점 kafka 자신의 네임 스페이스가 없습니다와 간단 보인다 않습니다 helm 우리가에서 제거 된에 들어갑니다 무엇 때문에 requirements.yaml 다른 가진 helm install 모두 배포 .

참고로 이것은 섹션 3: 상태 관리에 나열된 Helm 3 제안의 일부입니다. 피드백 환영합니다!

환상적인 소식입니다 @bacongobbler 😄🎉

@bacongobbler Helm 3은 @prat0318에서 설명한 대로 requirements.yaml에서 종속 차트에 대해 별도의 네임스페이스 지정을 지원

제안 문서에서 (읽어보세요! :스마일:):

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

Helm 2와 마찬가지로 리소스가 명시적으로 자체 네임스페이스를 선언하면(예: metadata.namespace=something), Helm은 이를 해당 네임스페이스에 설치합니다. 그러나 소유자 참조는 네임스페이스를 유지하지 않으므로 이러한 리소스는 기본적으로 관리되지 않습니다.

@bacongobbler 읽었지만 여전히 지원하지 않습니다. 내가 제어하는 ​​차트의 하드코딩된 메타데이터.네임스페이스를 의미하는 것은 아니며 항상 지원되었습니다. 내 말은 내가 편집할 수 없는 타사 차트의 네임스페이스를 지정한다는 것입니다. 예를 들어, 내 requirements.yaml에서 나는 stable/kubernetes-dashboard에 의존하고 그것을 kube-system에 설치하기를 원하지만 내 차트는 개발 네임스페이스로 이동해야 합니다.

90일 동안 사용하지 않으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

이 문제를 지금 종료하는 것이 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

바로 이 기능 요청이 helmfile 에 의해 수행될 수 있는 것으로

@gmile helmfile 관리자가 helmfile에서 이 특정 문제를 수정하지 않았다고 99% 확신합니다. helmfile.yaml에서 서로 다른 네임스페이스가 있는 vault 라는 두 릴리스를 선언하고 helmfile sync 실행하면 첫 번째 릴리스에서 릴리스 이름 vault 을 요구했기 때문에 실패합니다.

면책 조항: helmfile을 사용하여 이것을 테스트하지 않았으므로 내가 틀렸다는 말을 듣고 싶습니다. 😄

마지막 설명이 누락된 경우를 대비하여 Helm이 릴리스를 처리하는 방식을 변경하여 Helm 3에서 이 문제를 해결하고 있습니다. :)

@steven-sheehy 그 특정 문제는 정의된 것보다 특정 네임스페이스에 배포하도록 하위 차트를 확장하여 샌드박싱 모델 을 통해 수정될 수 있습니다.

/remove-lifecycle 부실

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

Helm 3에서 구현됨. 네임스페이스 컨텍스트를 변경하면 완전히 다른 인스턴스를 참조합니다.

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

좋은 소식 @bacongobbler

이 변경 사항이 주어지면 네임스페이스 열이 list 출력의 첫 번째 열로 이동하는 것이 합리적입니까? 처음 두 열이 릴리스를 고유하게 식별하도록 하시겠습니까?

기본 정렬은 네임스페이스 및 릴리스를 기준으로 할 수 있으므로 동일한 네임스페이스의 릴리스가 함께 그룹화됩니다. 예를 들어 모든 kube-system 릴리스가 함께 그룹화됩니다.

확신하는.

지금은 그냥 사용

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

예, 현재 작동 방식은 좋지 않지만 관리할 전역적으로 고유한 이름만 있으면 됩니다. 릴리스 이름에 대한 복합 키를 만들 수 없는 이유는 없습니다.

좋아, 3가지 기본 시나리오가 있는 것처럼 들립니다(각각 다양한 순열이 혼합될 수 있음).

1. 단일 네임스페이스 차트.
2. 네임스페이스가 없는 리소스입니다.
3. 다중 네임스페이스 차트.

이것이 다양한 시나리오를 해결하기 위한 합리적인 접근 방식입니까?

1. --namespace 플래그와 함께 제공될 때 네임스페이스를 주입/재정의합니다.
2. 1과 같지만 네임스페이스가 없는 리소스의 네임스페이스는 무시합니다.
3. "다중 네임스페이스를 재정의할 수 없음" 리소스 또는 이와 유사한 것을 인용하여 종료합니다.

제쳐두고: 나는 경운기를 사용하지 않고 helm template 선호하므로 이것이 도전 과제를 얼마나 변화시키는지 잘 모르겠습니다.

@technosophos

Helm v2가 네임스페이스와 상호 작용하는 방식과 v3이 어떻게 다른지 이해하려고 노력 중이며 이 스레드의 이전 의견 중 하나가 저를 혼란스럽게 합니다.

먼저 요점을 다시 반복하겠습니다. Helm 차트는 네임스페이스 수준이 아니라 전역 수준에서 작동합니다. 따라서 그들의 이름은 전 세계적으로 고유합니다.

....

네임스페이스가 없는 항목의 경우 상황이 매우 복잡해집니다. 다른 네임스페이스에 영향을 줄 수 있는 네임스페이스가 없는 항목을 관리하는 네임스페이스 릴리스가 있을 것입니다. RBAC와 TPR이 어떻게 작동하는지 살펴보십시오. 이것은 Helm이 단순히 지원하지 않기로 결정할 수 있는 것이 아니며 네임스페이스를 "위조"하면 특히 RBAC에서 가치보다 더 많은 문제가 발생할 수 있습니다.

Helm v3에서 배포된 릴리스는 실제로 네임스페이스가 될 것 같습니다. 그 맞습니까? RBAC 문제가 어떻게 해결되었는지 아십니까? 당신이 지적한 문제를 피할 수 있는 유일한 해결책은 Helm v3 차트가 RBAC 개체 수정을 지원하지 않는 것입니다. RBAC 개체 여부.

우리가 정말로 필요한 것은 네임스페이스 매개변수를 사용할 수 있고
이름 매개변수를 부착하는 대신 릴리스를 식별하는 복합 키로 사용
이름에 대한 네임스페이스.

나는 helm v3에 대한 제안을 읽지 않았지만 해야 할 현명한 일은
k8이 이미 사용하고 있는 선택기 패턴을 채택할 필요가 없습니다.
특정 필드를 지원합니다.

2019년 6월 25일 화요일 오전 11:01 BatmanAoD [email protected]이 작성했습니다.

@technosophos https://github.com/technosophos

Helm v2가 네임스페이스와 상호 작용하는 방식과 v3가 어떻게 상호 작용하는지 이해하려고 합니다.
다를 것이며 이 스레드의 이전 의견 중 하나가 저를 혼란스럽게 합니다.

먼저 요점을 다시 반복하겠습니다. Helm 차트는 전역에서 작동합니다.
네임스페이스 수준이 아니라 수준입니다. 그래서 그들의 이름은 전 세계적으로 고유합니다....

네임스페이스가 없는 항목의 경우 상황이 매우 복잡해집니다. 우리는
네임스페이스가 지정되지 않은 항목을 관리하는 네임스페이스 릴리스
다른 네임스페이스에 영향을 줍니다. RBAC와 TPR이 어떻게 작동하는지 살펴보십시오.
이것은 Helm이 지원하지 않기로 결정할 수 있는 사항이 아닙니다.
네임스페이스를 "위조"하면 가치보다 더 많은 문제가 발생합니다. 특히
RBAC와 함께.

Helm v3에서 배포된 릴리스는 실제로 네임스페이스가 될 것 같습니다.
그 맞습니까? RBAC 문제가 어떻게 해결되었는지 아십니까? 유일한
당신이 지적한 문제를 피할 수 있다고 생각할 수있는 해결책
Helm v3 차트는 RBAC 개체 수정을 지원하지 않지만 찾지 못했습니다.
v3 여부를 나타내는 v3에 대한 다양한 블로그 게시물 및 기타
차트는 RBAC 개체 관리를 지원하거나 지원하지 않습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREXHFSKFSB7FXQ5VPTP4JMP3A5CNFSM4DCII7X2YY3PNVWWK5WSFIZM52HS4DFVEXG43VMVBW63LNMVXHJGODY
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AACFHRH2JPXPKMX23WVQLCDP4JMP3ANCNFSM4DCII7XQ
.

@BatmanAoD @gyndick Helm v3에서 차트는 사용자 컨텍스트에 설치됩니다. 이는 해당 사용자 네임스페이스에 설치되고 사용자의 RBAC를 사용함을 의미합니다. 릴리스 이름도 네임스페이스 기반입니다.

Alpha.1 릴리스( https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1) 에서 사용해 보거나 dev-v3 분기에서 빌드할 수 있습니다.

나는 helm v3를 사용하지 않을 것입니다. 모든 운영 팀은 다른
제약과 일을 하는 방법. 운영 도구는 단순해야 하며,
단일 목적 유틸리티, 즉 Unix 철학과 호환됩니다.

내 스크립팅, 논리 등은 패키지 관리자 외부에 있습니다.

TLDR;

Unix 철학과 호환되는 가장 중요한 측면은
계단 사이에 탈출구를 제공하는 능력.

물류를 관리하는 길고 자동화된 워크플로를 보유하고 있습니다.
요람에서 무덤까지, 부서질 때까지 굉장합니다. 사용자에게 제공되지 않는 경우
필요한 흐름의 모든 단계를 수동으로 수행하는 기능, 자동화
판도라의 상자가 된다.

v3에 대해 제안된 복잡성은 많은 실수와 나쁜
25년 경력의 혜택이 없는 사람들의 디자인.

추가된 복잡성은 항상 일을 더 어렵게 만들 뿐입니다.
자체 개발 환경이 되는 운영 도구
분류를 늦추십시오.

완벽한 예는 누군가가 하나의 거대하고 끔찍하게 성문화되었을 때입니다.
작성된 스크립트. 중단이 발생하고 스크립트의 일부를 실행해야 합니다.
다른 부분은 엄격하게 피해야 하지만 이러한 부분은
주요 논리. 그럼 도대체 어떻게 하는 겁니까? 미친 듯이 노력하면서 거기에 앉아
디버깅에 좋은 방법이 없는 코드를 리팩토링합니다.

지원하기 위해 생태계에 들어가는 모든 도구에 대해 생각해 보십시오.
특정 언어로 소프트웨어 개발 및 운영. 넌 아니야
꽤 오랫동안 키를 제공할 수 있을 것입니다.

따라서 버전 간의 마이그레이션을 관리하는 방법에 대한 책임을 유지하십시오.
배포되는 소프트웨어를 개발하는 사람들과 소프트웨어.

패키지 관리자는 몇 가지만 사용하여 간단하고 가벼워야 합니다.
책임.

1. 아티팩트 전달
2. 아티팩트 제거
3. 아티팩트에 제공된 스크립트 실행
4. 전달했다고 생각하는 아티팩트를 추적합니다.
5. 가장 중요한 것은 키스

다른 모든 것은 고통을 요구합니다. 솔직히 helm v2는 거의 완벽에 가깝습니다.
릴리스를 추적하는 방법을 수정했다면.

2019년 6월 26일 수요일 오전 1시 31분 Martin Hickey [email protected]
썼다:

@BatmanAoD https://github.com/BatmanAoD @gyndick Helm v3에서 차트는
사용자 컨텍스트에 설치됩니다. 이것은 해당 사용자에 설치되었음을 의미합니다.
네임스페이스를 사용하고 사용자의 RBAC를 사용합니다. 릴리스 이름은
네임스페이스 기반도.

Alpha.1 릴리스에서 시도해 볼 수 있습니다.
https://github.com/helm/helm/releases/tag/v3.0.0-alpha.1 또는 빌드
dev-v3 분기.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/helm/helm/issues/2060?email_source=notifications&email_token=AACFHREUTX77SJCPWZLQKATP4MSNRA5CNFSM4DCII7X2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LDNMVXHJK
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AACFHRCAQLWUYHH6RJSUYF3P4MSNRANCNFSM4DCII7XQ
.

@hickeyma 답변 감사합니다! Helm 자체가 v3에서 ClusterRoles 생성과 같은 전역 작업을 계속 수행할 수 있는지 여부와 같이 Helm의 작업이 액세스 제어되는 방식에 대해 그다지 궁금하지 않습니다(관련 문제이지만).

@BatmanAoD 클러스터 범위 리소스이므로 작동해야 합니다. 기회가 된다면 시도해 볼 가치가 있을 것입니다.