helm delete release 를 통해 Helm에서 릴리스를 완전히 제거해도 작동하지만 실행 가능한 솔루션은 아닙니다.

Helm이 현재 설치된 것을 덮어 쓸 수없는 이유는 무엇입니까? 우리는 Kubernetes와 함께 선언적인 세상에 살고 있지 않습니까?

방금 똑같은 것을 얻었습니다. 저에게는 새로운 문제인 것 같습니다. 리소스를 삭제하면 문제가 해결됩니다.
v2.7.2 (Kubernetes 1.7.7 포함)
꽤 전에 작동했습니다 ...

이 문제가 발생했습니다. 내가 만든 PersistentVolume 때문이었습니다. 해결하기 위해 PV와 PVC를 삭제했습니다. helm upgrade XXX XXX 실행했는데 제대로 작동했습니다. 아마도 PV가 존재했기 때문에 조사해야 할 것입니다.

나는 그것이 나쁜 pv와 관련이 있다는 느낌을 받았지만 ... 오류는 상당히 오해의 소지가 있습니다!
경운기의 이상한 로그도 ... 동시에 2 버전에서 작업하는 것 같습니다 ...

운이없는 2.7.1로 시도했습니다 ...

[main] 2017/12/21 15:30:48 Tiller v2.7.1 시작 (tls = false)
[메인] 2017/12/21 15:30:48 GRPC 청취 : 44134
[main] 2017/12/21 15:30:48 프로브 청취 : 44135
[main] 2017/12/21 15:30:48 스토리지 드라이버는 ConfigMap입니다
[main] 2017/12/21 15:30:48 출시 당 최대 이력은 0입니다.
[경운] 2017/12/21 15:30:55 xxx 업데이트 준비 중
[저장] 2017/12/21 15:30:55 "xxx"기록에서 배포 된 릴리스 가져 오기
[tiller] 2017/12/21 15:30:56 xxx (v65)에서 새 릴리스로 값을 복사합니다.
[저장] 2017/12/21 15:30:56 "xxx"의 최종 개정을받는 중
[저장] 2017/12/21 15:30:56 "xxx"출시 내역 가져 오기
[경운] 2017/12/21 15:30:59 값을 사용하여 helm-xxx 차트 렌더링
2017/12/21 15:30:59 정보 : 매니페스트 'helm-xxx / templates / scheduler-deploy.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:30:59 정보 : 매니페스트 'helm-xxx / templates / recomposer-deploy.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:31:00 정보 : 매니페스트 'helm-xxx / templates / recomposer-pvc.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:31:00 정보 : 매니페스트 'helm-xxx / templates / scheduler-pvc.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:31:00 정보 : 매니페스트 'helm-xxx / templates / scheduler-secret.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:31:00 정보 : 매니페스트 'helm-xxx / templates / recomposer-secret.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
[경운기] 2017/12/21 15:31:09 xxx 용 업데이트 릴리스 생성
[저장] 2017/12/21 15:31:09 릴리스 "xxx.v80"생성
[경운] 2017/12/21 15:31:09 xxx 업데이트 수행
[경운기] 2017/12/21 15:31:09 xxx에 대해 0 개의 사전 업그레이드 후크 실행
[경운기] 2017/12/21 15:31:09 xxx 사전 업그레이드 후크 완료
[경운] 2017/12/21 15:31:11 xxx 업데이트 준비 중
[저장] 2017/12/21 15:31:11 "xxx"기록에서 배포 된 릴리스 가져 오기
[저장] 2017/12/21 15:31:11 "xxx"의 마지막 개정을받는 중
[저장] 2017/12/21 15:31:11 'xxx'출시 내역 가져 오기
[경운기] 2017/12/21 15:31:18 값을 사용하여 helm-xxx 차트 렌더링
2017/12/21 15:31:18 정보 : 매니페스트 'helm-xxx / templates / scheduler-secret.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:31:18 정보 : 매니페스트 'helm-xxx / templates / scheduler-pvc.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:31:19 정보 : 매니페스트 'helm-xxx / templates / scheduler-deploy.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
[kube] 2017/12/21 15:31:28 업데이트 된 매니페스트에서 리소스 구축
[경운] 2017/12/21 15:31:46 xxx에 대한 업데이트 릴리스 생성
[저장] 2017/12/21 15:31:46 릴리스 "xxx.v81"생성
[경운] 2017/12/21 15:31:47 xxx 업데이트 수행
[경운기] 2017/12/21 15:31:47 xxx에 대해 0 개의 사전 업그레이드 후크 실행
[경운기] 2017/12/21 15:31:47 xxx 사전 업그레이드 후크 완료
[kube] 2017/12/21 15:31:49 7 개의 리소스 변경 확인
[kube] 2017/12/21 15:31:49 비밀 'xxx-helm-xxx-nginx-secret'에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:31:50 비밀 'xxx-application-secret'에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:31:50 Secret "azure-secret"에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:31:51 ConfigMap "xxx-helm-xxx-nginx-config"에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:31:51 ConfigMap "xxx-application-config"에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:31:51 서비스 "xxx-application-svc"에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:31:51 StatefulSet 'xxx-application'에 대한 변경 사항이없는 것 같습니다.
[경운] 2017/12/21 15:31:51 xxx에 대한 업그레이드 후 후크 0 개 실행
[경운] 2017/12/21 15:31:51 업그레이드 후 xxx에 대한 후크 완료
[저장] 2017/12/21 15:31:51 릴리스 'xxx.v65'업데이트
[경운기] 2017/12/21 15:31:51 xxx의 업데이트 된 릴리스 상태 업데이트
[저장] 2017/12/21 15:31:51 릴리스 'xxx.v80'업데이트
[kube] 2017/12/21 15:31:57 업데이트 된 매니페스트에서 리소스 구축
[kube] 2017/12/21 15:32:10 11 개의 리소스 변경 확인
[kube] 2017/12/21 15:32:10 비밀 "xxx-helm-xxx-nginx-secret"에 대한 변경 사항이없는 것 같습니다.
[경운기] 2017/12/21 15:32:10 경고 : "xxx"업그레이드 실패 : 이름이 "xxx-recomposer-secret"인 리소스가 없습니다.
[저장] 2017/12/21 15:32:10 릴리스 "xxx.v65"업데이트
[저장] 2017/12/21 15:32:10 릴리스 "xxx.v81"업데이트

동시에 출시하는 것이 혼란스러워 보입니다 ...

동일한 구성을 두 번 다시 적용했습니다.

[경운] 2017/12/21 15:50:46 xxx 업데이트 준비 중
[저장] 2017/12/21 15:50:46 "xxx"기록에서 배포 된 릴리스 가져 오기
[저장] 2017/12/21 15:50:46 "xxx"의 마지막 개정을 가져 오는 중
[저장] 2017/12/21 15:50:46 'xxx'출시 내역 가져 오기
[경운기] 2017/12/21 15:50:50 값을 사용하여 helm-xxx 차트 렌더링
2017/12/21 15:50:50 정보 : 매니페스트 'helm-xxx / templates / scheduler-pvc.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:50:50 정보 : 매니페스트 'helm-xxx / templates / recomposer-deploy.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:50:50 정보 : 매니페스트 'helm-xxx / templates / scheduler-secret.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:50:50 정보 : 매니페스트 'helm-xxx / templates / scheduler-deploy.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:50:50 정보 : 매니페스트 'helm-xxx / templates / recomposer-secret.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
2017/12/21 15:50:50 정보 : 매니페스트 'helm-xxx / templates / recomposer-pvc.yaml'이 비어 있습니다. 건너 뛰는 중입니다.
[경운] 2017/12/21 15:50:58 xxx에 대한 업데이트 된 릴리스 생성
[저장] 2017/12/21 15:50:58 릴리스 "xxx.v85"생성
[경운기] 2017/12/21 15:50:59 xxx 업데이트 수행
[경운기] 2017/12/21 15:50:59 xxx에 대한 사전 업그레이드 후크 0 개 실행
[경운기] 2017/12/21 15:50:59 xxx 사전 업그레이드 후크 완료
[kube] 2017/12/21 15:51:13 업데이트 된 매니페스트에서 리소스 구축
[kube] 2017/12/21 15:51:22 7 개의 리소스 변경 확인
[kube] 2017/12/21 15:51:22 비밀 'xxx-helm-xxx-nginx-secret'에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:51:23 비밀 'xxx-application-secret'에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:51:23 Secret "azure-secret"에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:51:23 ConfigMap "xxx-helm-xxx-nginx-config"에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:51:23 ConfigMap "xxx-application-config"에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:51:24 서비스 "xxx-application-svc"에 대한 변경 사항이없는 것 같습니다.
[kube] 2017/12/21 15:51:24 xxx에서 "xxx-recomposer-secret"삭제 중 ...
[kube] 2017/12/21 15:51:24 "xxx-recomposer-secret"삭제 실패, 오류 : "xxx-recomposer-secret"비밀을 찾을 수 없음
[kube] 2017/12/21 15:51:24 xxx에서 "xxx-recomposer-config"삭제 중 ...
[kube] 2017/12/21 15:51:24 "xxx-recomposer-config"삭제 실패, 오류 : configmaps "xxx-recomposer-config"not found
[kube] 2017/12/21 15:51:24 "xxx-recomposer-pv"삭제 중 ...
[kube] 2017/12/21 15:51:24 "xxx-recomposer-pv"삭제 실패, 오류 : 영구 볼륨 "xxx-recomposer-pv"를 찾을 수 없음
[kube] 2017/12/21 15:51:24 xxx에서 "xxx-recomposer-pvc"삭제 중 ...
[kube] 2017/12/21 15:51:24 "xxx-recomposer-pvc"를 삭제하지 못했습니다. 오류 : persistvolumeclaims "xxx-recomposer-pvc"를 찾을 수 없습니다.
[kube] 2017/12/21 15:51:24 xxx에서 "xxx-recomposer"삭제 중 ...
[kube] 2017/12/21 15:51:24 "xxx-recomposer"삭제를 위해 reaper 사용
[kube] 2017/12/21 15:51:24 "xxx-recomposer"삭제 실패, 오류 : deployments.extensions "xxx-recomposer"를 찾을 수 없음
[경운] 2017/12/21 15:51:24 xxx에 대한 업그레이드 후 후크 0 개 실행
[경운] 2017/12/21 15:51:24 업그레이드 후 xxx에 대한 후크 완료
[저장] 2017/12/21 15:51:24 릴리스 'xxx.v68'업데이트
[경운] 2017/12/21 15:51:24 xxx의 업데이트 된 릴리스 상태 업데이트
[저장] 2017/12/21 15:51:24 릴리스 'xxx.v85'업데이트
[저장] 2017/12/21 15:51:25 "xxx"의 마지막 개정을받는 중
[저장] 2017/12/21 15:51:25 'xxx'출시 내역 가져 오기
[kube] 2017/12/21 15:51:38 Get for Secret : "xxx-helm-xxx-nginx-secret"
[kube] 2017/12/21 15:51:39 객체의 관계 포드 가져 오기 : xxx / Secret / xxx-helm-xxx-nginx-secret
[kube] 2017/12/21 15:51:39 비밀 확보 : "xxx-application-secret"
[kube] 2017/12/21 15:51:39 객체의 관계 포드 가져 오기 : xxx / Secret / xxx-application-secret
[kube] 2017/12/21 15:51:39 Get for Secret : "azure-secret"
[kube] 2017/12/21 15:51:39 객체의 관계 포드 가져 오기 : xxx / Secret / azure-secret
[kube] 2017/12/21 15:51:39 ConfigMap 가져 오기 : "xxx-helm-xxx-nginx-config"
[kube] 2017/12/21 15:51:39 개체의 관계 포드 가져 오기 : xxx / ConfigMap / xxx-helm-xxx-nginx-config
[kube] 2017/12/21 15:51:39 ConfigMap 가져 오기 : "xxx-application-config"
[kube] 2017/12/21 15:51:39 객체의 관계 포드 가져 오기 : xxx / ConfigMap / xxx-application-config
[kube] 2017/12/21 15:51:39 서비스 받기 : "xxx-application-svc"
[kube] 2017/12/21 15:51:39 객체의 관계 포드 가져 오기 : xxx / Service / xxx-application-svc
[kube] 2017/12/21 15:51:39 StatefulSet 가져 오기 : "xxx-application"
[kube] 2017/12/21 15:51:39 객체의 관계 포드 가져 오기 : xxx / StatefulSet / xxx-application

# 2941과 관련이있을 수 있습니다.

다른 스레드에서 문제를 해결하는 방법 중 하나는 버그가있는 configmap을 삭제하는 것이 었습니다 ... 현재 나를 위해하는 것 같습니다 ...

그것은 모두 훌륭하고 멋지다. 그때까지는 프로덕션 네임 스페이스에서 중요한 것을 삭제해야 할 때까지. 우연히도 방금 나에게 일어난 일입니다. :씨

이 릴리스의 여러 DEPLOYED 상태가있는 경우 릴리스를 업그레이드 할 때도 문제에 직면했습니다. 해당 configmap을 삭제하여 문제를 해결해야합니다.

같은 문제입니다. 어제는 모든 것이 괜찮 았고 여러 번 업그레이드했습니다. 오늘 방금 service 및 deployment 블록을 --- 구분하여 새 yaml을 추가했는데 업그레이드에 실패했습니다.

흥미로운 점은 helm이 service 을 (를) 만든 다음 불만을 제기했습니다 (배포를하지 않았 음).
service 주석을 달고 deployment 블록으로 업그레이드를 실행했습니다. 그러나 helm은 서비스를 삭제하지 않았습니다.이 서비스는 yaml 파일에서 제거 되었기 때문에 있어야합니다.

업데이트 : 나는 수동으로 service 삭제하고 yaml에서 주석을 제거하고 업그레이드를 실행했습니다. 이번에는 매력처럼 작동했습니다!

이 정확한 오류가 발생했습니다. 이 문제는 @amritb가 본 것과 유사한 여러 API 개체가있는 템플릿과 관련된 것 같습니다. 제 경우에는 다음과 같이 켜고 끌 수있는 여러 API 개체가있는 템플릿이 있습니다.

{{ if .Values.enabled }}
---
...

그것을 자체 템플릿 파일로 나누고 helm이 생성하고 잊어 버린 고아 개체를 정리하면 문제가 해결되었습니다. 릴리스간에 템플릿 당 개체 수가 변경되면 helm이 이전 구성을 가져 오는 방식에 버그가있는 것 같습니다.

다른 데이터 포인트 추가 : @awwithro와 똑같은 문제가있는 것 같습니다. 우리는 jinja 루프를 사용하여 템플릿을 통해 여러 cronjob을 생성하고 있으며, 새로운 업그레이드로 인해이 루프가 추가 cronjob을 채울 때 버그가 발생했습니다. # 2941도 트리거하는 것으로 보이며 (또는 하나의 버그로 인해 다른 버그가 발생할 수 있음) 좀비 구성 맵을 삭제하면 문제가 해결됩니다.

configmap을 사용하지 않고도 여기에 갇혔습니다.

붙어있을 수있는 사람을위한 추가 색상 :
릴리스에 새 하위 차트와 개체를 도입 할 때이 문제가 발생했습니다. 추가되는 모든 객체 유형을 확인하고 이름 충돌을 일으킬 수있는 기존 객체를 삭제하여 해결할 수있었습니다.

이것은 삭제가 지금 당장 해결할 수있는 유일한 방법이라는 다른 사람들의 증거와 일치하는 것 같습니다 😕

또한 이것을 가로 질러 실행 = \

영향을받는 리소스도 삭제해야했습니다. 프로덕션 환경에 좋지 않음 = _ (

비슷한 것 같아요. 문제는 helm upgrade 가 이전 배포의 값을 --reuse-values하지 않는다는 것입니다. 초기 설치와 동일한 값 세트를 명령 줄에 지정하면 helm upgrade 작동합니다. 이것이 도움이된다면 Dunno (또는 다른 사람이 이것을 확인할 수 있음).

@amritb 와 마찬가지로 helm이 처음에 실패한 개체를 수동으로 삭제 한 후 다음 업그레이드 후에 성공했습니다. 나는 # 2941을 경험하지 않았다.

helm 2.8.0 사용하는 것과 동일한 문제. Kubernetes 버전 client=v1.8.6 및 server=v1.8.5-gke.0 .

$ helm upgrade bunny ./app --debug
[debug] Created tunnel using local port: '54274'

[debug] SERVER: "127.0.0.1:54274"

Error: UPGRADE FAILED: no ConfigMap with the name "bunny-proxy-config" found

그러나 configmap은 $ kubectl get configmap 있습니다. configmap을 수동으로 삭제하면 작동하지만 다음에 다시 실패합니다.

다음은 configmap입니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  # namespace: {{ .Release.Namespace }} # I've tried adding and removing it
  labels: # labels are the same as labels from $ kubectl describe configmap bunny-proxy-config
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

릴리스를 삭제하고 다시 설치했습니다. 또한 배포를 위해 api 버전 extensions/v1beta 을 사용하고 있었는데 apiVersion: apps/v1beta2 변경했습니다. 이것이 도움이되었는지 여부를 모르겠습니다.
또한 현재 저는 tiller 로컬에서 실행 중입니다.

지금은 모든 것이 작동하는 것 같습니다.

이것은 재현하기가 정말 쉽습니다. 매니페스트에 오류가 있으면 발생합니다.

resource1과 resource2가있는 것처럼 resource2는 첫 번째에 의존합니다. 릴리스를 업그레이드하면 resource1이 생성되지만 (예 : PV 및 PVC) resource2가 실패합니다. helm은 항상 업그레이드시 문제를보고하므로 resource1 만 삭제하면 도움이됩니다 (이름이있는 PersistentVolume ... 찾을 수 없음).

우리는 같은 문제를 가지고있었습니다 (우리를 얻은 자원은 Secrets였습니다). 새 비밀을 제거하고 다시 배포하면 수정되었습니다.

실패로 인해 helm list , 10 개의 FAILED 및 1 개의 DEPLOYED를 수행하면 이제 11 개의 다른 릴리스가 있습니다. 예상치 못한 일 이죠? 여기 보이는 것과 같은 문제 : https://github.com/kubernetes/helm/issues/2941

이로 인해 정기적 인 프로덕션 배포에 helm을 사용할 수 없게되었습니다. , 우리가 잘못하고 있다는 것이 무엇인지 확실하지 않습니다.

틸러 로그를 추적 한 후 틸러가 동시에 이전 릴리스를 업데이트하려고하는 것을 발견했습니다.

[storage] 2018/02/14 18:25:40 updating release "s2osf.v10"
[storage] 2018/02/14 18:25:40 updating release "s2osf.v44"

s2osf.v10에 대한 이전 구성 맵을 삭제 한 다음 업그레이드가 작동했습니다.

Client: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.7.2", GitCommit:"8478fb4fc723885b155c924d1c8c410b7a9444e6", GitTreeState:"clean"}

@binoculars 와 동일한 문제가

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

UPGRADE FAILED: no Secret with the name "foobar" found 이상한 문제가 발생합니다.
나는 심지어이 비밀을 삭제하려고 시도했지만 대신 일부 configmap에서 오류가 발생했으며 세 번째 실행에서 다시 한 번 이전 비밀에 대해 불평했습니다.

이는 helm 2.7.x에서 2.8.1로 업그레이드 한 후에 트리거되었을 수 있습니다.

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

마지막 수단이 이전 릴리스를 삭제하는 것이라면 내 의견 https://github.com/kubernetes/helm/issues/3513#issuecomment -366918019로 덜 파괴적인 해결 방법이있을 수 있습니다.

기본적으로 로그에서 이전 버전을 찾고 tiller가 배포 된 상태를 저장하는 configmap을 수동으로 편집합니다. DEPLOYED 상태가 afaik 인 두 개의 개정이 있어서는 안됩니다.

이 문제에 대한 새로운 해결책을 찾았습니다.

kubectl -n kube-system edit cm name_of_your_release.v2 , 여기서 v2는 helm list 에서 FAILED로 표시된 최신 개정 번호입니다. 또한 배포 된 릴리스 중 하나를 편집하고 상태를 SUPERSEDED로 변경하여 동시에 두 개의 배포 된 릴리스를 갖지 않도록 할 수 있습니다.

@zuzzas 이것이 내가 언급 한 것입니다. 나를 위해 일했다

@balboah 문제는 DEPLOYED 상태에서 배포가 하나만 있다는 것입니다.하지만 최신 배포가 아닌 경우 (대부분의 시나리오에서 FAILED로 표시됨) 여전히 충돌이 발생합니다. 문제는 대부분의 경우 DEPLOYED 상태에서 두 개 이상의 배포가있는 것과 관련이없는 것 같습니다.

@zuzzas 같은 네임 스페이스에 여러 릴리스가 있습니까, 아니면 하나만 있습니까? 한 번은 동일한 객체를 업데이트하는 두 개의 릴리스에 문제가 발생하면 서로 충돌합니다.

하나뿐이라면 배포 된 버전까지 몇 번의 오류가 발생합니까? 하나만 배포되었는지 어떻게 확인 했습니까?

이 문제는 # 3539를 통해 수정 (진행 중)되었다고 생각합니다. 우리가 틀렸다면 다시 열어주세요. :)

이 작업에 대해 모두 감사합니다!

이 상태의 기존 차트에서는 수정되지 않았습니다. 작업을 다시 수행하려면 DEPLOYED 상태 인 이전 릴리스를 제거해야합니다. @balboah 는 "배포 됨으로 표시된 여러 릴리스"상태에 들어갈 수있는 경우를 막았습니다. :)

흠, Helm 2.8.2에서 여전히이 문제가 발생합니다 (최신 버전은 아니지만 2.9.0으로 시도했는데 동일한 오류가 발생합니다.) 일반적으로 문제가되는 리소스를 수동으로 삭제하면 문제를 해결할 수 있지만 종종 여러 리소스로 이어집니다. 성공적으로 업그레이드하기 전에 모두 삭제해야합니다.

중첩 된 종속성이있는 큰 helm 차트가 있습니다. 그게 될까요?

clusterrolebinding과 동일한 문제가 있습니다. 새 리소스를 내 차트에 추가했는데 upgrade 및 upgrade --install 가 Error: UPGRADE FAILED: no ClusterRoleBinding with the name "test-clusterrolebinding" found 실패합니다.

ClusterRole에서 @ramyala 와 동일한 문제가 발생합니다. ClusterRole이 존재하지만 해당 오류로 인해 RoleBinding 생성이 실패합니다.

Helm 2.9.1 에서 동일한 문제가 발생했습니다.

helm upgrade --install --namespace my-namespace my-stack stack
Error: UPGRADE FAILED: no ConfigMap with the name "my-stack-my-app" found

내 클러스터에서이 ConfigMap을 보는 동안.

하나의 파일에 후크가있는 여러 리소스가있는 경우이 문제가 발생합니다.

+1, 이것은 2.9.1에서 다시 발생합니다. 다시여십시오.

버그로 레이블을 다시 지정합니다. 이 회귀가 발생한 원인은 확실하지 않지만 2.9.1에서이 버그를 재현하는 방법에 대한 단계를 제공 할 수 있다면 가장 감사 할 것입니다.

뿡 빵뀨

헬름 차트에서 새 Ingress를 배포하려고 할 때도이 현상이 나타납니다. 나는 Ingress를 처음 접했지만 모든 예제를 바탕으로 올바른 것처럼 보이며 몇 달 동안 다른 helm / k8s 작업을 해왔습니다.

이미 helm 차트 stable/nginx-ingress 배포 했으므로 컨트롤러가 있습니다. 오류는 내가 만들려는 것을 찾으려고한다는 것을 암시하는 것 같습니다. 실행중인 명령은 다음과 같습니다.

helm upgrade some-existing-release-name -i --set imageTag=$TAG-$BUILD_NUMBER --namespace=default ./deploy/helm 여기서 deploy/helm 에는 내 차트 매니페스트가 포함됩니다.

Error: UPGRADE FAILED: no Ingress with the name "my-ingress" found

yaml :

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  labels:
    app: my-app
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: {{ $.Values.appDomain }}
    http:
      paths:
      - path: /*
        backend:
          serviceName: web-app
          servicePort: 80
      - path: /api/*
        backend:
          serviceName: api
          servicePort: 8080

최신 정보
두 경로에서 /* 를 제거했으며 업그레이드 / 설치를 시도 할 때 더 이상 오류가 발생하지 않습니다. 아마도 그것은 유효한 구문이 아닐 수도 있습니다.

안녕하세요,
내 환경에서 문제를 소개 한 단계는 다음과 같습니다.

1. 키 차트를 배포하고 여러 번 업그레이드했습니다.
2. 차트에 새 CronJob 개체를 만들고 다시 업그레이드했습니다. cron 작업이 성공적으로 생성되었습니다.
3. 다음 모든 업그레이드가 "오류 : 업그레이드 실패 : 이름이"cronjob-name "인 CronJob을 찾을 수 없음"보고 오류와 함께 실패합니다.

이전에 존재하지 않았던 시크릿을 추가 할 때도 문제가 발생합니다. "db-credentials"를 추가해 보았습니다.
비밀 :

Error: UPGRADE FAILED: no Secret with the name "db-credentials" found

잠재적으로 관련이있는 수정 : # 4146

이 오류가 발생한 사람이 해당 PR을 테스트하고이 문제가 해결되는지 확인할 수 있다면 k8s API의 회귀 일 가능성이 있는지 확인하고 해당 수정 사항을 진행할 수 있습니다. 감사!

이것이 항상 재현되는지 100 % 확인할 수는 없지만 다음과 같은 상황에서 발생하는 경향이 있습니다.

1. 새 리소스를 포함하여 Helm 차트를 업그레이드합니다.
2. 해당 업그레이드는 실패하지만 리소스는 실패한 업그레이드의 일부로 생성되었습니다.
3. 모든 후속 업그레이드가 실패합니다.

마지막으로 성공한 배포에 helm rollback 을 수행 한 다음 다시 업그레이드를 시도하면 작동하는 것 같습니다.

의도적으로 유해한 변경 사항이있는 차트를 업그레이드하려고하지 않고 (예 : 변경 불가능한 Job 개체 수정) 수동으로 재현하는 것이 매우 쉽습니다.

1. 차트를 가져와 배포합니다 (하지만 하나의 리소스를 생략하고 서비스라고 가정 해 보겠습니다).
2. 생략 된 리소스를 수동으로 추가하지만 (예 : "kubectl create"사용) 릴리스에 해당하는 이름을 사용합니다.
3. 생략 된 리소스를 차트에 다시 추가 한 다음 업그레이드를 시도합니다. helm은 "UPGRADE FAILED : no이름과 함께녹이다"

단계는 다르지만 근본 원인은 동일하게 보입니다. 가정이 틀린 경우 수정하십시오. 그러나 Helm "외부"(예 : 수동)에 추가되었거나 최신 업그레이드가 실패했기 때문에 마지막 배포 된 릴리스의 개정판에 특정 리소스에 대한 정보가없는 것 같습니다. 어떤 단계에서 (불변 작업을 업그레이드한다고 가정 해 보겠습니다) 동시에 다른 개체를 배포 한 다음 FAILED 개정에 기록합니다 (그러나 DEPLOYED 개정에는 예상되는 트랙이 없습니다. 그렇지 않으면 기록 변경을 의미 함) . 다음 실행시 Tiller의 kube 클라이언트는 클러스터의 리소스를 확인합니다. 즉, 이미 배포되어 기록되어 있어야하며, 최신 DEPLOYED 개정을 확인하고 (FAILED 개정이 전혀 연결되지 않은 것 같습니다) 거기에 나열되지 않습니다. 그래서 오류를보고합니다.

@bacongobbler 사용자 지정 틸러 이미지로 # 4146을 테스트

make bootstrap build docker-build

틸러 이미지를 저장소에 업로드하고 클러스터에 틸러를 다시 설치해야합니다. 강제 재설정으로 빠져 나가 현재 릴리스를 파괴하지 않고 다시 설치할 수있었습니다.

$GO_HOME/src/k8s.io/helm/bin/helm init -i gcr.io/my-repo/tiller:1 --service-account tiller

수정을 테스트 해 주신 @ramyala 에게 감사드립니다! 내일 dev call에서 언급하고 다른 핵심 관리자가 패치와 함께 발생할 수있는 엣지 케이스를 보는지 확인합니다. 합병하지 않으면.

그래서 나는 앞으로 나아가는 것이 바람직하지 않은 PR이되는 # 4146의 몇 가지 버그를 발견했습니다. 마스터, # 4146 및 # 4223 사이의 결과를 여기에보고했습니다 : https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568

@adamreese 와 저는이 특정 오류를 일으키는 근본적인 버그를 식별하고 제안 된 각 PR에 대해 서로 다른 시나리오와 가장자리 사례를 살펴 보았습니다. 다른 사람이 내 결과를 확인하거나 다른 사례를 찾을 수 있다면 대단히 감사하겠습니다!

아, 그리고 제가 언급하지 못한 점 : 클러스터가 일관성이없는 상태에 있기 때문에 오류가 "찾을 수 없음"으로보고하는 리소스를 수동으로 개입하고 삭제하여 쉽게 해결할 수 있습니다. https://github.com/kubernetes/helm/pull/4223#issuecomment -397413568에서 시연 한 예를 따라 :

><> helm fetch --untar https://github.com/kubernetes/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml
><> kubectl create -f foo/templates/service.yaml
service "foo-bar" created
><> helm upgrade $(helm last) ./foo/
Error: UPGRADE FAILED: no Service with the name "foo-bar" found
><> kubectl delete svc foo-bar
service "foo-bar" deleted
><> helm upgrade $(helm last) ./foo/
Release "riotous-echidna" has been upgraded. Happy Helming!
...
><> kubectl get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
foo-bar      ClusterIP   10.104.143.52   <none>        80/TCP    3s
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP   1h

모든 것을 함께 유지하기 위해 두 티켓이 동일하므로 # 1193의 복제본으로 이것을 닫겠습니다. 우리 모두가 하나의 티켓으로 작업 할 수 있도록 모든 결과를보고하십시오. 감사!

경고 :이 정보는 다소 개략적이고 이해할 수 없지만 누군가에게 유용 할 경우를 대비하여 서비스 선택기를 다음과 같이 변경하여이 문제를 해결했습니다.

selector:
    app: {{ template "mything.name" . }}

...에

selector:
    app: mything

이 컨텍스트에서 변수를 사용하는 데 어떤 종류의 문제가 있습니까?

helm delete RELEASE_NAME --purge 사용해보기
다시 설치하십시오.

나도이 문제에 부딪혔다. 내 차트에 배포와 함께 하위 차트를 추가하려고 시도했지만 처음으로 helm upgrade chart chart-1.0.1.tgz 업그레이드했을 때 성공했습니다. 그 후 helm upgrade chart chart-1.0.1.tgz 시도했을 때 Error: UPGRADE FAILED: no Deployment with name "subchart-deployment" found 오류와 함께 실패했습니다.

Client: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.12.0", GitCommit:"d325d2a9c179b33af1a024cdb5a4472b6288016a", GitTreeState:"clean"}

helm tiller 로그는 동일한 오류 만 기록합니다. 누구도 이것을 경험하고 있습니까?

같은 문제입니다. 어제는 모든 것이 괜찮 았고 여러 번 업그레이드했습니다. 오늘 방금 service 및 deployment 블록을 --- 구분하여 새 yaml을 추가했는데 업그레이드에 실패했습니다.

흥미로운 점은 helm이 service 을 (를) 만든 다음 불만을 제기했습니다 (배포를하지 않았 음).
service 주석을 달고 deployment 블록으로 업그레이드를 실행했습니다. 그러나 helm은 서비스를 삭제하지 않았습니다.이 서비스는 yaml 파일에서 제거 되었기 때문에 있어야합니다.

업데이트 : 나는 수동으로 service 삭제하고 yaml에서 주석을 제거하고 업그레이드를 실행했습니다. 이번에는 매력처럼 작동했습니다!

안녕하세요 ， 저도이 문제가 있는데 해결할 수 없습니다.

https://github.com/helm/helm/issues/1193#issuecomment -419555433을 참조

내가 동일한 문제를 목격하고 있으며 원인도 앞서 언급 한대로 확인하는 것뿐입니다.

새 암호를 추가하고 볼륨에서 참조했습니다 (잘못된 구문). 업그레이드에 실패했습니다. 위와 같은 오류로 인해 후속 업그레이드가 실패했습니다.

비밀 목록에 생성 된 것으로 나타났습니다. 수동으로 비밀을 삭제하고 업그레이드가 성공적으로 진행되었습니다.

@thedumbtechguy도 마찬가지입니다. 나는이 문제를 일상적으로 겪는다. Helm이 비밀, 구성 맵, 역할 등을 _all_ 삭제해야한다고 결정할 때 특히 재미 있습니다. 업그레이드는 kubectl delete 대한 인수 목록이 계속 증가하는 두더지 잡기 게임이됩니다. 몇 달 전에이 시시 피 작업에 수건을 던 졌어 야했는데 지금은 너무 늦었어요. 물론 이것과 수십 개의 유사한 문제를 해결할 수 있기를 바랍니다!

나는 1 주일 동안 투구를 사용했고 이미 설명 된 모든 것에 직면했다.
여기 https://medium.com/@7mind_dev/the -problems-with-helm-72a48c50cb45

여기에서 많은 부분을 수정해야합니다.

2019 년 3 월 15 일 금요일 오후 10:49 Tom Davis [email protected] 은 다음과 같이 썼습니다.

동일, @thedumbtechguy https://github.com/thedumbtechguy . 나는
이 문제는 일상적으로. Helm이 필요하다고 결정할 때 특히 재미 있습니다.
비밀, configmap, 역할 등을 모두 삭제하십시오. 업그레이드는
kubectl에 대한 인수 목록이 계속 증가하는 두더지 게임
지우다. 이 sisyphean 작업 달에 수건을 던져야 했어
하지만 지금은 너무 늦었습니다. 물론 이것과 수십 개의 희망
비슷한 문제를 해결할 수 있습니다!

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/helm/helm/issues/3275#issuecomment-473464809 또는 음소거
실
https://github.com/notifications/unsubscribe-auth/AA4XZU4KMQePtZKcir8S5kWulkbYg-8Uks5vXCNggaJpZM4RGz7W
.

Helm v2.10에서도 동일한 경험을했습니다. 이미 차트를 배포하고 차트에 다른 configMap을 추가했습니다. configMap "blah"를 찾을 수 없어 배포에 실패했다고보고했습니다. 나는했다

helm upgrade <NAME> chart --debug --dryrun 

configMap이 실제로 렌더링되고 있는지 확인하려면 그랬습니다. 클러스터에서 configMaps를 확인하고 거기에서 찾았습니다. blah configMap을 삭제하고 업그레이드를 다시 실행하면 작동했습니다.

https://github.com/helm/helm/pull/5460 은 앞으로 오류 메시지를 더 명확하게 설명해야합니다.

공정한 포인트.

$ helm upgrade linting-unicorn testrail                                                                                                                                                                                        
Error: UPGRADE FAILED: no ConfigMap with the name "linting-unicorn-testrail-php-config" found

좋은 일을 담당하는 팀을 유지하십시오.

이것이 다른 사람에게 큰 문제인 경우 https://github.com/helm/helm/pull/4871 이 이러한 문제를 해결해야한다고 지적했습니다.

Helm 팀에서 아직 승인하지 않은 것 같습니다. 또한 자동 삭제 리소스에 대한 우려도있었습니다. 누군가가 소스에서 빌드하고 시도해보고 싶은 경우를 대비하여 언급하십시오.

동일한 문제가 발생하고 유일한 해결 방법은 helm delete --purge release 것 같습니다. 다시 설치하십시오!

나는 같은 문제에 부딪쳤다. @fbcbarbosa 2 주 전에 합병 된 것 같습니다. 다음 릴리즈 2.14.0 의 일부가되기를 바랍니다.

동일한 문제가 발생하고 유일한 해결 방법은 helm delete --purge release 것 같습니다. 다시 설치하십시오!

덜 파괴적인 옵션은 / current / 버전에 helm rollback 를 수행하는 것입니다 (즉, 0 단계). 나는 성공을 보장 할 수 없지만 지금까지 우리에게 그것은 항상 성공적으로 해결되었습니다.

이것이 다음 릴리스에 있을지, 언제 올지에 대한 아이디어가 있습니까?

5460은 2 개월 전에 병합되었으므로 helm 2.14.0에 있어야합니다.

문제를 해결했습니다.

1. "helm upgrade"에 의해 불만이있는 자원을 삭제하십시오. (찾을 수 없음이라고 표시되지만 실제로 찾을 수 있습니다.) 전체 릴리스를 삭제하지 마십시오. 그렇지 않으면 프로덕션에서 완전히 망할 수 있습니다.
2. 투구 업그레이드를 다시 실행하십시오. 이번에는 "Happy Helming"이 나옵니다. :)

우리는 엄브렐러 헬름 차트에 대한 요구 사항이 조건을 기반으로하는 configmap을 추가했을 때 PROD에서이 문제를 만났습니다. 우리에게 해결 방법은

helm rollback <some revision that's acceptable>
helm upgrade <desired version>

우리에게는 현재 개정판 으로의 간단한 롤백이 항상 작동했습니다.

helm ls
helm rollback <NAME> <current REVISION>

@tobypeschel 수정이 어떻게 작동하는지 알고 있습니까?