<p>helm upgrade --install이 더 이상 작동하지 않습니다.</p>

나는 같은 문제가 발생하고 있다고 생각했지만 방금 오래된 삭제(제거되지는 않음), 릴리스가 있는 것으로 나타났습니다. helm list -a 를 확인하고 릴리스가 있는 경우 helm delete --purge releasename 을 실행하십시오. helm upgrade -i 는 2.7.2에서 성공적으로 작동합니다.

이는 상태가 좋지 않은 릴리스 업그레이드와 관련된 문제를 수정하는 데 따른 부작용입니다. https://github.com/kubernetes/helm/pull/3097 은 이 문제를 해결한 PR이었습니다. 여기에 우리가 포착하지 못한 극단적인 경우가 있습니까?

@tcolgate가 언급한 대로 helm list -a 를 확인하고 , 이를 재현하는 방법도 설명하면 포착되지 않은 경우인지 버그인지 판별하는 데 도움이 될 것입니다.

또한 중복 릴리스 이름과 함께 동일한 문제가 있습니다.

$>helm ls -a|grep ingress
nginx-ingress               9           Thu Nov 30 11:33:06 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               11          Thu Nov 30 11:37:58 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               12          Thu Nov 30 11:38:50 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               8           Thu Nov 30 11:31:27 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
nginx-ingress               10          Thu Nov 30 11:33:53 2017    FAILED      nginx-ingress-0.8.2         kube-ingress
$>helm diff nginx-ingress ./nginx-ingress
Error: "nginx-ingress" has no deployed releases

업그레이드할 때 어떤 메시지가 표시되었습니까?

위의 diff와 동일한 오류이지만 설치에서는 이미 설치되었다고 표시됩니다.

FAILED 상태로 끝난 이전 업그레이드 시도를 의미합니다. 모든 릴리스가 실패한 상태에 있는 상황에 어떻게 들어가는지 알고 싶습니다.

오, 중복 릴리스 이름 배포? 잘 모르겠지만 꽤 자주 받습니다. 때로는 모두 DEPLOYED 상태이고 때로는 FAILED와 DEPLOYED가 혼합되어 있습니다. 우리는 모든 PR 병합을 지속적으로 업데이트하는 CI/CD Jenkins 서버를 사용하므로 하루에 여러 번 helm upgrade 작업을 수행하며 일반적으로 새 컨테이너 태그만 있습니다. 일반적으로 복제는 배포된 항목을 볼 때 성가신 일입니다. 이것은 처음으로 어려운 문제가 발생했으며 일반적으로 이 경우처럼 인그레스 컨트롤러를 업그레이드하지 않습니다.

비슷한 결과가 나온 것 같습니다. 내 릴리스 목록에 몇 가지 중복 항목이 있습니다.

$ helm ls
NAME                      REVISION    UPDATED                     STATUS      CHART                           NAMESPACE
.....
front-prod                180         Tue Dec  5 17:28:22 2017    DEPLOYED    front-1                         prod
front-prod                90          Wed Sep 13 14:36:06 2017    DEPLOYED    front-1                         prod 
...

그들 모두는 DEPLOYED 상태에 있는 것처럼 보이지만, 내가 그 버그를 여러 번 쳤기 때문에 이전 업그레이드가 어느 시점에서 실패했을 수도 있습니다. 나는 여전히 K8S 1.7을 사용 중이므로 아직 helm 2.7로 업데이트하지 않았습니다.

동일한 문제, FAILED 배포를 통해 업그레이드할 수 없음

2.7.2를 사용하여 여기에서도 동일합니다. 릴리스의 첫 번째 시도가 실패했습니다. 그런 다음 업그레이드 --install을 시도했을 때 "오류: UPGRADE FAILED: "${RELEASE}"에 배포된 릴리스가 없습니다"라는 오류가 발생했습니다.

2.7.2와 동일한 문제, helm upgrade --install 실패:

Error: UPGRADE FAILED: "APPNAME" has no deployed releases

릴리스가 helm del --purge APPNAME 로 완전히 제거되면 후속 upgrade --install 가 정상적으로 작동합니다.

같은 문제가 발생했습니다. 해결 방법에 대한 일부 스크립팅 없이 자동화된 멱등 배포에 대한 옵션을 남기지 않는 #3134 와 결합됩니다.

@winjer 는 --purge로 삭제를 시도했고 오류가 변경되었지만 작동하지 않았습니다.
/ # 키 업그레이드 foo /charts/foo/ -i --wait
오류: 업그레이드 실패: "foo"에 배포된 릴리스가 없습니다.
/ # helm delete --purge foo
릴리스 "foo"가 삭제됨
/ # 키 업그레이드 foo /charts/foo/ -i --wait
릴리스 "foo"가 존재하지 않습니다. 지금 설치 중입니다.
오류: foo 릴리스 실패: deployment.extensions "foo-foo-some-service-name"이 이미 존재합니다.

@prein helm에 의해 "소유자"가 아니지만 클러스터에 이미 존재하는 서비스가 있기 때문입니다. 당신이 겪고 있는 행동이 나에게 맞는 것 같습니다. helm은 이전에 소유하지 않은 API 개체의 "소유권을 가져"야 하므로 배포에 성공할 수 없습니다.

새 매니페스트가 실제로 정확하고 클러스터의 다른 리소스에 만족하지 않는 경우 FAILED 릴리스를 업그레이드할 수 있는 것이 합리적입니다.

content 라는 릴리스에서도 이 동작을 보고 있습니다.

helm upgrade --install --wait --timeout 300 -f ./helm/env/staging.yaml --set image.tag=xxx --namespace=content content ./helm/content
Error: UPGRADE FAILED: no resource with the name "content-content" found
helm list | grep content
content                         60          Mon Dec 25 06:02:38 2017    DEPLOYED    content-0.1.0                   content           
content                         12          Tue Oct 10 00:02:24 2017    DEPLOYED    content-0.1.0                   content           
content                         37          Tue Dec 12 00:42:42 2017    DEPLOYED    content-0.1.0                   content           
content                         4           Sun Oct  8 05:58:44 2017    DEPLOYED    k8s-0.1.0                       content           
content                         1           Sat Oct  7 22:29:24 2017    DEPLOYED    k8s-0.1.0                       content           
content                         61          Mon Jan  1 06:39:21 2018    FAILED      content-0.1.0                   content           
content                         62          Mon Jan  1 06:50:41 2018    FAILED      content-0.1.0                   content           
content                         63          Tue Jan  2 17:05:22 2018    FAILED      content-0.1.0                   content           

계속 배포하려면 이 항목을 삭제해야 합니다. 이 문제를 디버깅하는 데 도움이 될 수 있는 작업이 있으면 알려주세요.
(중복에 관한 문제이므로 문제의 이름을 바꿔야 한다고 생각합니다.)
( 2.7.2 도 실행합니다)

실제로 내 클러스터에 또 다른 중복 릴리스가 있습니다. 디버그를 돕기 위해 실행할 명령이 있다면? 알려 줘요!

방금 틸러 2.7.2로 업그레이드했는데 같은 현상이 나타납니다. helm delete RELEASE_NAME 다음에 helm upgrade RELEASE_NAME . 가 Error: UPGRADE FAILED: "RELEASE_NAME" has no deployed releases 와 함께 실패합니다. upgrade 는 삭제된(하지만 제거되지 않은) 릴리스를 복원하기 위한 의도된 방법입니다. 맞습니까?

삭제된 버전으로 롤백하여 릴리스를 복원할 수 있는 것 같습니다.

v2.7.2 에서 동일한 문제가 표시되면 이전에 성공적으로 배포된 릴리스가 없으면 실패합니다.

또한 이 문제의 두 가지 잠재적인 버전이 표시됩니다.

CI에서:

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: "api-feature-persistent-data" has no deployed releases

내 로컬 컴퓨터에서:

(내 OSX bash와 gcloud/kubectl 컨테이너 모두에서)

+ helm upgrade --install --wait api-feature-persistent-data . --values -
+ cat
WARNING: Namespace doesn't match with previous. Release will be deployed to default
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
2018/01/25 00:19:07 warning: destination for annotations is a table. Ignoring non-table value <nil>
Error: UPGRADE FAILED: no PersistentVolumeClaim with the name "api-feature-persistent-data-db" found

경고는 차트에 대해 정상입니다.
오류가 흥미로운 이유는 하위 차트 중 하나에 pvc.yaml 가 있기 때문입니다.

helm del --purge <release> 는 문제를 완화합니다.
이것은 CI 파이프라인을 업그레이드하기 어렵게 만듭니다.

@adamreese 이 문제의 최종 해결 방법은 무엇입니까? 우리는 2.8을 사용 중이며 helm list 변경으로 이전 FAILED 릴리스를 업그레이드할 수 없습니다.

특히 다음과 같은 유형의 문제가 발생합니다.

• 릴리스 배포, 확인
• upgrade --install --wait , 하지만 작은 버그가 있고 --wait 가 성공하지 못할 수 있습니다(예: 활성도 프로브가 해결하지 못함).
• 차트 수정 후 upgrade --install --wait xxx has no deployed releases 실패

여기서 삭제/제거는 바람직하지 않거나 허용되지 않습니다. 릴리스에는 올라가지 않을 한 리소스의 영향을 받지 않는 여러 리소스(포드, 로드 밸런서)가 있을 수 있습니다. 이전 Helm 버전에서는 upgrade --install 를 사용하여 모든 리소스를 제거할 필요 없이 전체 릴리스를 중단시킨 변경 사항만 패치할 수 있었습니다.

Helm은 여기에서 항상 관련된 모든 리소스의 소유자입니다. --wait 가 모든 리소스가 양호한 상태가 될 때까지 기다리지 못했기 때문에 리소스는 FAILED 로만 표시됩니다. 포드가 시작하기에 너무 느리거나 많은 유사한 경우에 동일한 일이 발생할 것이라고 가정합니다.

@peay 는 후속 논의를 위해 #3353을 참조하십시오.

덕분에 해결되었습니다. 사실 처음부터 성공적인 출시가 없었을 때만 성공했다는 것을 깨달았습니다. 이 경우 제거가 좋은 해결 방법입니다.

이것은 설치에 실패한 경우에도 계속 발생합니다.
삭제하고 다시 시도해야 합니다.

UPGRADE FAILED: "API" has no deployed releases
그런 다음 수동으로 제거해야 합니다.
helm delete --purge API
그리고 그것은 작동합니다.

helm 2.9부터는 helm upgrade --install --force 도 수행할 수 있으므로 제거할 필요가 없습니다. 이전 릴리스의 경우:

helm delete API
helm install --replace --name API ./mychart

@bacongobbler 이 동작에 대해 여전히 혼란스럽습니다.
시간 되실 때 https://github.com/kubernetes/helm/pull/3597#issuecomment -382843932에 답변해 주시겠습니까?

작업해 주셔서 감사합니다.

확신하는. 저는 현재 AFK이지만 오늘 저녁 늦게 답변할 수 있습니다. 혼란을 충분히 이해하고 가능한 한 최선을 다해 귀하의 질문에 답변하겠습니다. KubeCon EU를 위해 다른 것들을 준비하는 사무실에서 정신이 없습니다. :)

이 문제를 해킹하거나 문서를 개선하는 데 도움이 될 수 있습니다.
꼭 만나요 :+1:

@bacongobbler 는 이 주소를 #3353으로 지정하고 #4004의 일부로 작성한 코드를 무효화합니까?

제 경우에는 helm upgrade --install --force 가 delete --purge 를 실행한 후 설치했습니다.

이것이 예상된 행동입니까? 이것 때문에 거의 2달의 일을 잃었습니다. 때 않았다 force 의미로 시작 delete ?

^ kubecon의 사람들과 몇 가지 대화를 나누었고 이 동작 변경으로 인해 꽤 많은 팀이 v2.7.0에 고정되어 있음을 발견했습니다.

upgrade install 는 --force 가 의미하는 바가 무엇이든 간에 절대 파괴적이어서는 안 된다는 데 동의합니다.

@bacongobbler님 , CPH에 있을 때 만나지 못해서 죄송합니다.
실패한 릴리스를 업그레이드할 수 없도록 동작을 변경하는 근거에 대한 문서가 있습니까?
예전 행동이 지금보다 훨씬 더 바람직한 것 같습니다.

변경해야 하는 이유에 대한 배경 컨텍스트는 https://github.com/kubernetes/helm/issues/3353 의 두 번째 의견을

앞으로의 제안 경로가 무엇인지 정말 궁금합니다. #3353에서 설명한 문제로 인해 #3097을 취소할 수 없으므로 커뮤니티에서 이 문제를 해결하기 위한 올바른 경로가 무엇이라고 생각하는지 듣고 싶습니다. 우리는 #3597을 철회할 수 있지만 helm upgrade --install 문제를 해결하기 위한 좋은 해결책이 없다고 들었습니다. :실망한:

우리가 Helm 3에 대한 적용 로직을 재작업하는 중이라는 것을 알고 있지만 이는 아직 갈 길이 멉니다.

@bacongobbler 를 연결해 주셔서 감사합니다 :)
귀하의 제안은 합리적인 접근 방식처럼 들립니다.

성공적인 릴리스가 배포되지 않은 경우 diff를 수행하지 않는 것이 중요할 수 있습니다. 비교할 "현재" 릴리스가 없다는 점에서 사용자가 처음으로 helm install을 실행한 것과 같은 경험이 될 것입니다. 하지만 특정 엣지 케이스에 대해서는 약간 걱정이 됩니다. @adamreese 이것에 대해 어떤 의견이 있습니까?

이렇게 하면 유일한 실패 사례(비교할 사항 없음)가 처리되므로 #3597을 취소할 수 있습니다.
이것은 upgrade --install 다시 비파괴적으로 만들고 kubectl apply 와 더 유사하게 만듭니다.

직관적으로 이것이 내가 upgrade --force 를 수행할 것으로 기대하는 것입니다. diff-and-patch 작업을 수행하지 않고 현재 있는 것을 무시하고 완전한 템플릿을 적용하기만 하면 됩니다. 이것이 가능하지 않은 기술적 이유를 생각할 수는 없지만 Helm의 내부 작동 방식에 대해서도 잘 모릅니다.
여전히 위험한 작업일 수 있지만 --force 플래그를 사용하는 사람은 일반적으로 강제 업데이트를 통해 특정 위험을 예상합니다. 나는 이것이 잠재적 가동 중지 시간과 함께 배포를 삭제하고 다시 만들 것으로 기대하지 않는다고 주장합니다.

토론을 읽었지만 여전히 멱등원 upgrade --install 명령(또는 명령 시퀀스)을 사용하는 방법이 명확하지 않습니다.

현재 안정 버전을 사용하여 자동화된 스크립트에서 이를 어떻게 달성할 수 있습니까? 이전 시도가 실패하더라도 delete --purge 를 사용하지 않고 비대화식으로 배포할 수 있어야 합니다.

향후 계획에 관해서는 원래 upgrade --install 에서 예상했던 동작입니다.

• 이전 설치가 없는 경우 설치
• 이전에 성공한 설치 업그레이드
• 이전에 실패한 설치 교체
• 설치가 실패하면 가능한 경우 가동 중지 시간 없이 이전 리소스가 제자리에 있어야 합니다.
• 파괴적인 작업 없음(예 delete --purge 위에서 언급한 자동

내 개인적인 의견으로는 이 동작에 대해 추가 플래그가 필요하지 않습니다. 이것이 패키지 관리자가 일반적으로 행동하는 방식입니다. 요구 사항을 잘못 이해하지 않는 한 예를 들어 --force 플래그가 필요하지 않다고 생각합니다.

이에 대한 업데이트가 있었습니까? 실패할 경우 제거를 실행하지 않고 기존 설치에서 업그레이드를 안정적으로 실행하는 적절한 방법은 무엇입니까?

@MythicManiac FWIW:
이 동작 때문에 우리 팀은 여전히 ​​v2.7.0에 고정되어 있습니다.
이 버전에서 helm upgrade --install 를 사용해야 하는 경우 리소스 업그레이드 및 삭제에 문제가 없는 것 같습니다.

우리에게도 이 문제가 있습니다. helm has no deployed releases 때문에 K8s 서비스 및 관련 AWS ELB를 삭제해야 하는 것은 매우 성가신 일입니다. 패키지 관리자는 훌륭하지만 이 문제는 좋지 않은 프로덕션 다운타임으로 이어집니다.

매우 해킹된 해결 방법으로 원본 배포의 문제가 다음과 같은 경우
해결 가능(예: 기존 서비스), 원본으로 롤백 수행
실패한 릴리스가 작동할 수 있습니다.

2018년 10월 5일 금요일 18:13 Eugene Glotov, 알림 @github.com 작성:

우리에게도 이 문제가 있습니다. K8을 삭제해야 하는 것은 매우 성가시다.
helm에 배포된 릴리스가 없기 때문에 서비스 및 관련 AWS ELB. 그만큼
패키지 관리자는 훌륭하지만 이 문제로 인해 생산 중단 시간이 발생하여
좋지 않다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/helm/helm/issues/3208#issuecomment-427436187 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/AAEo8_pISzHFAuOz6Lsv5EjrFaEo_HkYks5uh5M7gaJpZM4Qtexz
.

@tcolgate님 , 감사합니다! 해결 방법으로 다른 문제(https://github.com/helm/helm/issues/2426#issuecomment-427388715)를 수정했으며 다음 주에 기존 리소스에 새 차트를 배포할 때 기존 ELB에 대해 테스트하려고 합니다. .

원래 실패한 릴리스로 롤백하면 작동할 수 있습니다.

@tcolgate , 방금 테스트

$ helm upgrade --wait --timeout 900 --install myproject charts/myproject/myproject-1.1.1.tgz
14:53:18 Release "myproject" does not exist. Installing it now.
14:53:18 Error: release myproject failed: deployments.apps "myproject" already exists

$ helm list
NAME            REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
myproject       1           Mon Oct  8 11:53:18 2018    FAILED      myproject-1.1.1                 default

$ helm rollback myproject 1
Error: "myproject" has no deployed releases

Helm이 기존 리소스에 차트를 배포할 수 없는 경우 helm delete 인해 이러한 리소스가 정확히 삭제되는 이유는 무엇입니까?

thomastaylor312 @, 우리는이 문제 ~뿐만 아니라 직면 https://github.com/helm/helm/issues/2426~를 (최대 : 나는 2426에 대한 실제 근본 원인을 찾을 수 없음) 투구 2.11.0와 함께. 그들이 다시 열려야 한다고 생각합니까?

Error: UPGRADE FAILED: "xxx-service" has no deployed releases 후에 이 스레드를 찾았습니다.
그것은 조타 장치에서 볼 수 있었지만 ls -a.

잘못된 --set 값으로 인해 문제인지 확인하기로 결정했고 --debug --dry-run --force 실제로 여전히 실행 중인 포드를 삭제했습니다 ... 내 예상은 테스트 실행 작업이 절대 수정되지 않는다는 것입니다. 클러스터 리소스.

그래도 작동했고 나중에 서비스를 다시 배포할 수 있었지만 가동 중지 시간이 발생했습니다.

내 예상은 테스트 실행 작업이 클러스터 리소스를 수정하지 않을 것이라는 것이었습니다.

이것은 공정한 기대입니다. 우리는 그런 일이... 일어나지 않도록 해야 합니다.

https://github.com/helm/helm/pull/4402 에서 패치되었다고 생각하지만 누군가 확인하면 좋을 것입니다. 미안합니다!

2.11.0으로 업그레이드한 후에도 동일한 문제

크로스 포스트:
https://github.com/reactiveops/reckoner/issues/48#issuecomment -453411283

이게 왜 닫혀있나요? 지금 이것을 처리할 적절한 방법이 있습니까?

@gerbsen , 비파괴적인 Helm의 현재 버전에서는 이 문제를
우리는 여전히 내 조직의 모든 것에 Helm 2.7.0을 사용합니다. 다른 버그가 있는 아주 오래된 버전이지만 이 문제는 없습니다.

방금 helm upgrade --install --force 가 delete --purge 하고 나에게 알리지 않고 내 pvc/pv를 파괴하도록 했습니다(재활용에 대해). 릴리스가 여러 번 실패하여 kubernetes에서 실행 중인 상태였지만 helm은 실행 중인 릴리스가 없다고 생각했습니다. 전혀 좋지 않은 시간.

@notque 모든 grafana 대시보드를 두 번 잃은 후 모든 종류의 업그레이드를 수행하기 전에 백업을 시작했습니다. 이러한 종류의 위험이 있으면 helm 사용의 모든 이점이 제거됩니다.

도움을 구하는 사람들을 위해 helm을 v.2.15.2로 업그레이드한 후 문제가 사라졌습니다.

2.16.0 에서 이 문제가 계속 표시됩니다.

왜 여전히 닫혀 있습니까? 2.16.1은 여전히 ​​영향을받습니다.

@nick4fake https://github.com/helm/helm/issues/5595 의 복제본이라고 생각합니다.