안녕하세요. 배포 방법에 대해 좀 더 자세히 설명해 주시겠습니까? 혹시 helm upgrade --install 를 사용하고 계십니까? 그렇다면 배포가 중단되었을 때 배포 상태는 어떻게됩니까 ( helm ls )-아마도 Failed 일까요?

이 경우 helm delete --purge <deployment> 가 트릭을 수행해야합니다.

안녕하세요, 정보를 놓쳐서 죄송합니다.
예, helm upgrade --install
예, 배포는 Failed 영원히 유지됩니다.
안타깝게도 helm delete --purge <deployment> 은 (는) 여기에서 전혀 옵션이 아닙니다. 그 때문에 프로덕션 서비스를 삭제할 수 없습니다. :)

문제는 3 회 연속 실패 후 helm이 회복 할 수없는 이유입니다.

릴리스를 삭제하지 않고 정렬하는 유일한 방법은 --force

--force 무엇에? ~ helm upgrade --install ?
그렇다면 위의 문제가 실제로 예상되는 기능이며 모든 배포에 --force 를 사용해야 함을 의미합니다. -그렇다면 깨진 릴리스를 강제로 배포한다는 의미입니까?

예, 물론 helm upgrade --install :)
예, 모든 배포에 --force 를 사용해야합니다.

--force 이 (가) 손상된 릴리스도 강제로 배포한다는 의미입니까? -포드가 끊어지고 항상 다시 시작되면 이전 포드를 삭제하고 새 포드를 예약합니까?
--force force resource update through delete/recreate if needed
delete 조건은 무엇입니까? 정확히 어떻게 작동하는지 자세히 설명해 주시겠습니까? 이러한 중요한 플래그에 대해서는 설명이 너무 짧습니다. 내부적으로 수천 가지 작업을 수행 할 것으로 예상합니다.

BTW 나는 정말로 삭제 된 생산 서비스로 끝나고 싶지 않으므로 --force 플래그는 나에게 옵션이 아닙니다.

정말 문제가 아니라고 생각하십니까?
오류 메시지도 잘못되었습니다.
app-name has no deployed releases
배포 된 릴리스 가 .
상태에 있지만,이 상태에서 Failed 와 조타도 :( 그것을 해결하기 위해 시도하지 않습니다 - 내 말을 고정하여 단지 대신 매우 시작 포기의, 배포 해보세요

https://github.com/helm/helm/issues/3208 참조

더 이상 동의 할 수 없습니다. 우리 생산에도 동일한 오류가 발생합니다. 따라서 차트를 삭제하는 것은 선택 사항이 아니며 강제로 설치하는 것은 위험 해 보입니다. 이 오류는 Helm 3에도 여전히 존재합니다. 따라서 수정 또는 더 안전한 해결 방법을 포함하는 것이 좋습니다.

storage.go : 136에서 "status": "deployed"를 제거하여 해결할 수 있습니다.

참조 : https://github.com/helm/helm/pull/6933/commits/638229c3d3646e78d0fd5157309f8aeadfd01af1

시간이 있으면 Pull Request를 수정하겠습니다.

제자리에있는 코드는 원래 정확했습니다. 현재 상태에 관계없이 의도하지 않은 결과를 초래할 수있는 상태에 관계없이 Helm이 업그레이드 할 최신 릴리스를 찾는 쿼리 결과에서 status: deployed 제거합니다. 일시적으로 문제를 우회하지만 앞으로 더 큰 문제를 야기합니다.

이 버그를 발견했을 때 helm history 의 출력을 제공 할 수 있다면 도움이 될 것입니다. 릴리스 원장에 "배포 됨"상태의 릴리스가없는 경우 종료 방법을 결정하는 것이 더 유용합니다.

새 클러스터에 처음 배포 할 때이 문제가 발생합니다. --force 도 사용해야합니까?

--purge 옵션을 사용하지 않고 이전 릴리스를 삭제할 때이 문제가 발생했습니다.

helm delete --purge <release-name>

Helm 버전

Client: &version.Version{SemVer:"v2.15.X"}
Server: &version.Version{SemVer:"v2.15.X"}

이 문제도 발생합니다.

뿡 빵뀨
나는 이것을 helm3로 쳤다. 이것이 발생하면 기록은 완전히 비어 있지만 시도 1 이후로 깨진 k8s 리소스가 있습니다.

번식은 정말 쉬워 보입니다.

1. helm upgrade --install "오류로 종료되는 컨테이너가있는 포드가있는 것"
2. 컨테이너가 종료 된 원인 (예 : 컨테이너 내부의 실행 파일에 대해 잘못된 인수가있는 값)을 수정하고 다시 시도하십시오.
   -> 오류 : UPGRADE FAILED : "foo"에 배포 된 릴리스가 없습니다.

--atomic 플래그는 내 (CI / CD) 시나리오에서 앞으로 나아갈 수 있습니다. 처음 실패한 릴리스를 전혀 발생하지 않은 것처럼 완전히 정리하기 때문에 다음 시도에서이 문제가 발생하지 않습니다.

여기서도 마찬가지입니다. delete 또는 --force 수 없습니다. 특히 영구 볼륨이있는 경우 특히 그라 파나 대시 보드를 모두 잃어 버렸습니다. 다시 :)

업데이트 : 내 경우 btw는 다음과 같은 이유로 릴리스가 실패합니다.

Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

그라 파나 값을 변경하지 않아도

@ alex88 helm history 의 출력을 제공 할 수 있습니까? 다른 사람들이이 사건을 어떻게 공격하는지 알아야 근본 원인을 파악하고 해결책을 찾을 수 있습니다.

@bacongobbler 나는 몇 번 영구 볼륨을 잃어 버렸기 때문에 helm을 사용하는 것에 대해 정말로 신중하기 때문에 이것이 수정 된 것을보고 싶었습니다 (아마도 내 잘못입니다)

REVISION    UPDATED                     STATUS  CHART           APP VERSION DESCRIPTION
4           Wed Dec  4 02:45:59 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
5           Mon Dec  9 12:27:22 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
6           Mon Dec  9 12:33:54 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
7           Mon Dec  9 12:36:02 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
8           Mon Dec  9 13:06:55 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
9           Mon Dec  9 13:38:19 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
10          Mon Dec  9 13:38:51 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
11          Mon Dec  9 13:41:30 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
12          Mon Dec  9 13:56:01 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims
13          Mon Dec  9 15:15:05 2019    failed  grafana-4.1.0   6.5.0       Upgrade "grafana" failed: cannot patch "grafana" with kind PersistentVolumeClaim: PersistentVolumeClaim "grafana" is invalid: spec: Forbidden: is immutable after creation except resources.requests for bound claims

기본적으로 일부 환경 변수를 변경하기 위해 업그레이드를 여러 번 시도했으며 배포 오류가 발생하는 동안 환경 변수가 어쨌든 변경되었으므로 계속 오류를 무시했습니다.

모든 릴리스가 실패한 상태가 된 방법은 무엇입니까? 릴리스 1, 2, 3은 어디에 있습니까?

모든 릴리스가 실패한 상태가 된 방법은 무엇입니까? 릴리스 1, 2, 3은 어디에 있습니까?

환경 변수를 변경하고 (여러 번 변경해야 함) 매번 업그레이드를 실행하면 환경 변수가 변경되었지만 영구 볼륨 오류를 수정하는 방법을 알지 못했습니다.

업데이트 : btw I 'm using

version.BuildInfo{Version:"v3.0.0", GitCommit:"e29ce2a54e96cd02ccfce88bee4f58bb6e2a28b6", GitTreeState:"clean", GoVersion:"go1.13.4"}

이전 릴리스와 관련하여 아마도 helm은 그중 10 개만 유지합니다.

Helm3 : istio를 업그레이드하는 동안 비슷한 문제가 발생하여 릴리스가 실패했습니다. 이제 템플릿의 작은 오류가 수정 되었는데도 다시 배포 할 수 없습니다. istio-ingress 서비스와 관련된 ELB도 삭제되므로 프로덕션 릴리스를 삭제할 수 없습니다.

초기 릴리스가 실패한 상태로 끝날 때 논리를 변경하기위한 향후 작업이 있습니까?

다운 타임이 허용되지 않으면 어떻게해야합니까?

% helm upgrade prometheus-thanos --namespace metrics -f values.yaml . 
Error: UPGRADE FAILED: "prometheus-thanos" has no deployed releases
% helm install --atomic prometheus-thanos --namespace metrics -f values.yaml .                                                                                                               
Error: cannot re-use a name that is still in use
% helm version
version.BuildInfo{Version:"v3.0.1", GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa", GitTreeState:"clean", GoVersion:"go1.13.4"}

다운 타임이 허용되지 않으면 어떻게해야합니까?

지금은 helm을 사용하여 템플릿을 생성하고 수동으로 로컬에 저장하고 적용합니다.

--atomic 플래그는 내 (CI / CD) 시나리오에서 앞으로 나아갈 수 있습니다. 처음 실패한 릴리스를 전혀 발생하지 않은 것처럼 완전히 정리하기 때문에 다음 시도에서이 문제가 발생하지 않습니다.

@ henrikb123 위는 항상 --atomic 플래그를 사용한 경우 에만 작동 --atomic 플래그와 함께 동일한 명령을 실행합니다. 깨질 것입니다. 참고로 최신 Helm 버전-> 3.0.2를 사용하고 있습니다.

@ alex88 helm 기록의 출력을 제공 할 수 있습니까? 다른 사람들이이 사건을 어떻게 공격하는지 알아야 근본 원인을 파악하고 해결책을 찾을 수 있습니다.

@bacongobbler 문제를 시뮬레이션하기 위해 @ henrikb123이 여기 에서 말한대로하지 않는 이유는 무엇입니까? @ henrikb123이 지적한 것처럼 역사는 완전히 비어 있습니다. 저도 확인할 수 있습니다. 제발보세요 :

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Release "teleport" does not exist. Installing it now.
Error: Secret "teleport-secrets" is invalid: metadata.labels: Invalid value: "helm.sh/chart:teleport-1.0.0app.kubernetes.io/managed-by": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName',  or 'my.name',  or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')

$ helm history teleport
Error: release: not found

$ helm upgrade --install --cleanup-on-fail --reset-values --force --namespace teleport --values values.test.yaml teleport ./
Error: UPGRADE FAILED: "teleport" has no deployed releases

나는 또한 Istio와 함께 이것을 만났습니다.

1.4.3에 Istio 문제가 있습니다. 여기서 Kubernetes API 서버에 도달 할 수없는 경우 설치 실행 작업 중 하나가 실패합니다. 그런 다음 작업을 남겨두고 Helm 명령을 다시 실행하려고하면 작업이 이미 존재하기 때문에 실패합니다. 작업을 삭제하고, 수정하고, 업그레이드를 다시 실행하려고했지만 성공하지 못했습니다. 이제 막혔습니다.

(그것에 대한 질문이 있었기 때문에 이것이 완전히 실패한 릴리스 상태로 들어갈 수있는 방법입니다.)

REVISION    UPDATED                     STATUS  CHART       APP VERSION DESCRIPTION                                                                                                                                                                                                         
10          Tue Jan 14 09:17:00 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
11          Tue Jan 14 09:22:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
12          Tue Jan 14 09:23:10 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
13          Tue Jan 14 09:25:58 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
14          Tue Jan 14 09:35:21 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
15          Tue Jan 14 09:38:08 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition 
16          Tue Jan 14 14:02:47 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
17          Tue Jan 14 14:19:44 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition
18          Tue Jan 14 14:33:36 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: warning: Hook post-upgrade istio/charts/security/templates/create-custom-resources-job.yaml failed: jobs.batch "istio-security-post-install-1.4.3" already exists
19          Tue Jan 14 14:36:59 2020    failed  istio-1.4.3 1.4.3       Upgrade "istio" failed: post-upgrade hooks failed: timed out waiting for the condition

이것은 Helm 3.0.2입니다.

IMO 이것은 최대한 빨리 수정해야하는 중요한 문제입니다. 버전 2부터 동일한 문제에 대해 열려있는 다른 많은 유사한 문제를 보았고 지금까지 수정되지 않은 것 같습니다.

이 문제를 시뮬레이션하기 위해 @ henrikb123 이 자신의 의견에서 말한대로 개발자에게 요청합니다. 그것을 시뮬레이션하는 매우 간단한 방법입니다. 모든 Helm 버전 (2.xx 및 3.xx)으로 테스트 할 수 있습니다. 나는 그들 모두에서 일어날 것이라고 거의 확신합니다.

아마도 --atomic 은 (명령 줄 인수가 아닌) 어려운 요구 사항이어야합니다. --cleanup-on-fail 처럼 상당히 중복됩니다. 차이점은 --cleanup-on-fail 가 --atomic 처럼이 문제를 해결하지 않았다는 것입니다.

우리는 또한 생산 과정에서이 문제를 만났으며 가동 중지 시간은 옵션이 아닙니다. 다음과 같은 명령을 사용하여 대신 STATUS: DEPLOYED 레이블을 갖도록 최신 FAILED 구성 맵을 패치하여 해결 방법을 찾았습니다.

kubectl -n kube-system patch configmap app-name.v123 --type=merge -p '{"metadata":{"labels":{"STATUS":"DEPLOYED"}}}'

우리의 경우 마지막 FAILED 개정이 실제로 kubernetes에 의해 성공적으로 배포되었다고 확신했습니다.

우리는 어떻게이 상태에 들어갔습니까?

기본적으로 Kubernetes는 helm 시간이 초과 된 후에도 여전히 수정을하고 있었기 때문에 개발 팀은 FAILED 업그레이드를 무시했습니다.

특히 Helm 2를 사용하고 있으며 tiller-deploy 배포에 TILLER_HISTORY_MAX=20 설정했습니다. 시간이 지남에 따라 더 오래 걸리는 모든 RollingUpdate 업그레이드에 helm upgrade --wait --timeout 1080 를 사용했습니다. 그런 다음 helm 업그레이드가 시간 초과되기 시작했지만 Kubernetes가 여전히 성공적으로 수정을하고 있었기 때문에 아무도 놀라지 않았습니다. 20 개의 업그레이드 시간이 초과 된 후 (오늘), 대신 app-name has no deployed releases 이 (가) 표시되어 더 이상 배포 할 수 없기 때문에 우리는 놀랐습니다.

패치가 작동하는 이유는 무엇입니까?

우리는 Helm이 아마도 다음과 유사한 요청을 사용하여 configmap을 요청하고 있다는 것을 깨달았 기 때문에 configmap의 STATUS 레이블을 패치해야한다는 것을 알아 냈습니다.

kubectl -n kube-system get configmap -l NAME=app-name,STATUS=DEPLOYED

configmap yaml을보고 다음 레이블을 발견했을 때 단서가 발견되었습니다.

$ kubectl -n kube-system describe configmap app-name.v123
Name:         app-name.v123
Namespace:    kube-system
Labels:       MODIFIED_AT=1579154404
              NAME=app-name
              OWNER=TILLER
              STATUS=FAILED
              VERSION=123
Annotations:  <none>
Data
====
release:
----
H4sIAAAAAAAC...snipped...

그리고 이것은 https://github.com/helm/helm/issues/5595#issuecomment -552743196과 일치합니다.

@bacongobbler 실패한 상태가되는 방법을 궁금해하는 대신 실패하지 않아야하는 실패한 설치 업그레이드에 대한 귀중한 수정 사항을 고려해야합니다.

그러나 실제로, 귀하의 우려에 답하기 위해 시간 초과는 릴리스 실패의 좋은 이유입니다. 릴리스도 중단되며 업그레이드하고 시간 초과로 실행될 때 롤백 할 수 없습니다.

따라서 클레임에 의해 동적으로 생성 된 볼륨이 있습니다. 차트를 삭제하여 청구를 삭제하면 볼륨 도 영구적으로 삭제됩니다 . 그것은 당신이 그것을 좋아하는 방식이 아닙니다. 나와 다른 많은 개발자들은 몇 달 동안 갇혀 있으며이 문제를 해결하려고 노력하고 있습니다.

쿼리에서 status: deployed 를 제거하는 것이 마음에 들지 않았습니다. 그렇다면 상태가 배포되었거나 실패했는지 여부에 관계없이 실제로 최신 릴리스를 표시 하는 새 레이블을 추가하는 것은 어떻습니까? 그것은 실제로 의미가 있습니다. 이것이 여러분이 원하는 것이기 때문에 업그레이드 할 최신 릴리스를 얻고 자합니다. 그리고 아무것도 없으면 실패한 릴리스를 대신 확인해야합니다. 또는 최신 레이블을 직접 표시하는 새 레이블을 사용하십시오.

_ 이에 대한 여러분의 의견을 듣고 기쁩니다 ._

완벽한 코디 @AmazingTurtle.

이 문제가 이미 언급되었는지 확실하지 않지만 차트의 첫 번째 설치가 어떤 이유로 든 실패하는 경우에도이 문제가 발생합니다 (특히 차트에서 반복해야 할 수있는 처음 차트 사용자에게 매우 일반적인 경우). 실행을위한 구성).

이 경우 CLI 사용자를위한 유일한 해결 방법은 비밀 드라이버를 사용하는 경우 릴리스 추적 비밀을 삭제하는 것뿐 아니라 마지막 릴리스에서 생성 된 모든 리소스를 삭제하는 것입니다 (Helm의 리소스 소유권 검사 실행을 방지하기 위해).

이 문제가 발생할 때이 문제를 처리하기 위해 내부적으로 작성한 도구의 실제 함수입니다.

package foo

import (
    "helm.sh/helm/v3/pkg/action"
    "helm.sh/helm/v3/pkg/release"
    "helm.sh/helm/v3/pkg/storage/driver"
)

// DangerouslyApplyRelease allows installing or upgrading any release from a failed state,
// but does not enforce Helm's standard resource ownership checks.
func DangerouslyApplyRelease(cfg *action.Configuration, rel *release.Release) error {
    // Forcibly mark the last release as successful and increment the version
    rel.Info = &release.Info{
        Status: release.StatusDeployed,
    }
    rel.Version++

    var err error

    // Attempt to create the release
    err = cfg.Releases.Create(rel)

    // If release already exists, update it
    if err == driver.ErrReleaseExists {
        err = cfg.Releases.Update(rel)
    }

    return err
}

@jlegrone helm delete --purge (v2) 또는 helm uninstall (v3) 사용도 모두 실패한 릴리스이므로 작동합니까?

@jlegrone 이 지적한 것은 사실입니다.
@hickeyma 귀하의 제안은 작동 할 수있는 해결 방법입니다. 하지만 확실한 해결책이 필요합니다.

지난 2 년간 유해한 버그이며 helm은 고치지 않을 것입니다.
helm delete 은 대부분의 프로덕션 케이스에서 허용되지 않습니다.
helm3에서는 암호화되어 있으므로 kubectl edit secret sh.helm.release.... 을 (를) 사용할 수 없습니다.
helm rollback <latest-successful> 은 올바른 해결 방법 일뿐입니다.

따라서 기본적으로 HISTORY_MAX = 10이 있고 작동하도록 10 번 시도했다면 완전히 잃어버린 것입니다 ...

설치와 업그레이드에 대한 논리가있는 경우 sh.helm.release ..... v * 비밀을 삭제할 수 없습니다.

투구는 죽거나 고쳐야합니다

해결 방법을 찾았습니다.
helm3은 비밀에 레이블을 설정합니다.
kubectl get secrets --show-labels | grep sh.helm.release.v1

....
sh.helm.release.v1.helm-must-die.v34                 helm.sh/release.v1                    1         13h       modifiedAt=1580326073,name=helm-must-die,owner=helm,status=failed,version=34
sh.helm.release.v1.helm-must-die.v35                 helm.sh/release.v1                    1         13h       modifiedAt=1580326228,name=helm-must-die,owner=helm,status=failed,version=35
sh.helm.release.v1.helm-must-die.v36                 helm.sh/release.v1                    1         1h        modifiedAt=1580370043,name=helm-must-die,owner=helm,status=failed,version=36
...

최신 kubectl edit secret sh.helm.release.v1.helm-must-die.v36 하고 레이블 status = deployed를 설정하십시오.
이전 릴리스 (v35)의 경우 레이블 status = superseded를 설정합니다.

다음 helm upgrade --install ... 작동합니다

@ kosta709 모든 CAPS 레이블이있는 kube-system 네임 스페이스에 릴리스를 ConfigMaps로 저장하는 Helm2에 대한 내 발견과 유사하게, Helm3은 이제 레이블이 모두 소문자 인 애플리케이션의 네임 스페이스에 릴리스를 Secrets로 저장합니다.

따라서 Helm3의 경우 약간 다른 kubectl patch 명령을 사용할 수 있습니다.

kubectl -n app-namespace patch secret app-name.v123 --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

이러한 해결 방법에 대해 논의 할 필요가 없었 으면합니다. 제품에서이 문제를 해결하는 것이 최우선 과제입니다. 이것이 얼마나 나쁜지에 대한 알림 (해결 방법 무시) :

릴리스가 처음 배포 될 때 실패했거나 충분한 릴리스가 마지막 성공을 기록에서 교체하지 못한 경우 수동 개입없이 릴리스를 수정할 수 없습니다.

연속 배포 파이프 라인에서 Helm을 사용하는 것이 일반적인 패턴이거나 적어도 원하는 패턴 일 수 있으므로 이는 작동하지 않습니다.

나는 완전히 동의하지만 최소한 해결 방법을 명확하게 문서화하고 싶었습니다.이 상태에 들어가면 릴리스를 포기하고 중단하는 것 외에 다른 옵션이없는 것처럼 느껴지기 때문입니다.

중단을 방지하기위한 패치와 함께 helm --wait 사용을 중단하고 대신 자체 폴링 로직에 의존하여 릴리스가 성공했는지 여부를 알 수 있습니다. 더 많은 작업이지만 이제는 더 많은 가시성을 확보하여 릴리스가 예상보다 오래 걸릴 때 도움이되며 제한 시간보다 일찍 오류를 감지 할 수 있습니다.

이것은 이전 버전의 helm에서 문제가되지 않았으며 배포에 실패하지 않았으며 kubectl은 실행중인 서비스를 표시하고 모든 것이 작동합니다.

이제 단순히 helm upgrade -f app.yaml --namespace prometheus prometheus prometheus 실행하려고하는데 Error: UPGRADE FAILED: "prometheus" has no deployed releases 오류가 발생하지만 이것이 제품에 포함되어 있으므로 해결 방법을 시도 할 수 없습니다.

@zrsm 지금하고있는 것은 helm을 사용하여 yaml 파일을 생성하고 kubectl diff / dry-run을 사용하여 수동으로 적용하기 전에 변경 사항을 미리 보는 것입니다.

@zrsm 지금하고있는 것은 helm을 사용하여 yaml 파일을 생성하고 kubectl diff / dry-run을 사용하여 수동으로 적용하기 전에 변경 사항을 미리 보는 것입니다.

답장을 보내 주셔서 2.15.1로 다운 그레이드했지만 비슷한 문제가 발생했지만 ~ / .helm 삭제와 같은 작업을 시도한 다음 kubectl에서 틸러 서비스 계정을 다시 초기화 한 후 kubernetes에 차트를 적용 할 수있었습니다. . 오늘 나중에 helm 3로 이것을 테스트하고 수정 사항으로 답장 할 것입니다. 이것이 문제 일 수도 있다고 생각합니다.

안녕하세요, 그래서 이것을 테스트했습니다 ... 이전 ~ / .helm /을 삭제 한 후 다음 명령을 수행하는 것처럼 보입니다.이 문제를 해결했습니다 ...

helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's<strong i="6">@apiVersion</strong>: extensions/v1beta1<strong i="7">@apiVersion</strong>: apps/v1@' | kubectl apply -f -

새 helm 버전을 설치하고 서비스 계정 항목이 위치하지 않으면 (내 노트북을 지우고 언젠가 복원) 이런 일이 발생하고 이것이 수정이라고 생각합니다. 나는 그것이 당신에게도 효과가 있기를 바랍니다.

이 버그는 Helm 3에서 진행 중입니다. 계획된 수정이 있습니까?

또한 시간 초과로 인해 새 클러스터 및 새 배포에서이 문제가 발생합니다. 이 문제를 해결하기 위해 클러스터에 수동으로 연결하는 것을 좋아하지 않지만 지금은 이것이 유일한 옵션이라고 생각합니다.

이 문제가 최대한 빨리 해결되도록 할 수 있습니까?

이 문제는 너무 답답해서 helm 사용을 중단해야하는 이유입니다.

나는 동의한다. 이것은 나를 미치게 만든다. 나는 그것을 고치기 위해 노력할 것입니다. 행운을 빌어 요.

나는 동의한다. 이것은 나를 미치게 만든다. 나는 그것을 고치기 위해 노력할 것입니다. 행운을 빌어 요.

감사합니다. 행운을 빕니다!

PR # 7653을 보도록 여러분 중 몇 명에게도 괜찮습니다.

나는 이것이 위에서 설명한 문제를 해결할 것이라고 믿습니다.

메인테이너의 반응없이 아직 열려 있다는 것을 믿을 수 없습니다.

cc @bacongobbler @mattfarina

helm delete --purge (v2) 또는 helm uninstall (v3)도 모두 실패한 릴리스이므로 작동합니까?

@hickeyma 항상 아닙니다; 이는 helm 릴리스 메타 데이터 손상의 결과 일 수도 있으므로 경우에 따라 제거하면로드중인 리소스가 삭제 될 수 있습니다.

때로는 릴리스가 실패하지 않았지만 시간 초과 및 helm이 실패한 것으로 레이블을 지정하고 다음에 배포 된 릴리스가없는 것으로 표시되지만 앱이 실제로 완전히 작동하는 경우 여러 번 발생하여 릴리스를 변경해야했습니다. deployed 1에 라벨을 지정합니다. 항상 helm delete --purge (v2) or helm uninstall (v3) 할 수있는 것은 아닙니다.

@rimusz 릴리스 레이블을 어떻게 변경합니까?

@dudicoco helm v3 최신 릴리스 비밀을 수동으로 편집하여이를 자동화하고 kubectl patch

매력처럼 작동하는 https://github.com/k14s/kapp 로 이동했습니다.

@rimusz 그게 내가 생각한 것입니다, 감사합니다.

또한 # 7668의 helm 2에 대한 수정 사항을 백 포팅했지만 # 7653에 대한 피드백을 기다리고 있습니다.

여기에 같은 문제,

--wait 배포 된 릴리스가 시간 초과되었으며 마지막으로 실행 중입니다. 여전히 실패로 표시됩니다.
따라서 이후 배포도 실패합니다.

이는 릴리스 상태가 신뢰할 수있는 정보가 아님을 의미합니다.

우리는 생산에서 많은 서비스를 위해 회사에서 k8s를 사용합니다.
한 달에 몇 번 동안 다른 응용 프로그램에 대한 helm과 동일한 문제가 있습니다 ( " * 에는 배포 된 릴리스가 없습니다.").
우리는 다른 버전의 helm (2.7에서 3.0.3까지)을 사용했습니다.
문제가 해결되지 않았습니다.
이로 인해 사용자 (클러스터에 응용 프로그램을 배포하는 개발자)에게 많은 불편 함이 생깁니다.
매번 공격 할 때마다 최신 릴리스 비밀 (배포 상태) 만 패치합니다.
마지막 릴리스 상태를 무시하고 새 릴리스를 설치하는 동작을 추가 할 계획이 있습니까?

--history-max 을 10 (기본값)으로 설정하면 첫 번째 릴리스가 성공했습니다.
그런 다음 다음 10 개 릴리스가 실패했습니다.
Error: UPGRADE FAILED: timed out waiting for the condition (시뮬레이트되었으므로 예상 됨).
그 후 다음 (11 번째 실패) 릴리스가 실패했습니다.
Error: UPGRADE FAILED: "app" has no deployed releases (그게 문제입니다!)

Helm이 가장 최근의 10 개 (상태에 관계없이) 외에 기록에서 가장 최근의 성공적인 릴리스를 항상 보존 할 수 있습니까?

나는 아이디어를 좋아한다. 저장 기능을 수정해야하지만 할 수 있다고 생각합니다.

https://github.com/helm/helm/pull/4978 이 Helm 2 용으로 병합되었습니다. 아마도 Helm 3으로 이식되지 않았을 수 있습니다. 누군가 시간이 있고이를 이식하고 싶다면 부담없이 사용해주세요.

나는 이것을 # 7806으로 Helm 3에 이식하려고 시도했으며 최대한 빨리 병합되는 것을보고 싶습니다. 감사합니다, @ultimateboy!

_first_ 설치에 실패한 릴리스, 즉 이전에 성공한 릴리스가없는 릴리스는 어떻습니까?
helm 릴리스의 멱등 적 배포에 upgrade --install 를 사용하고 있으며 첫 번째 릴리스가 실패하면 upgrade --install 의 모든 후속 호출이 "배포 된 릴리스 없음"오류 (이 문제)와 함께 실패합니다.

"첫 번째 릴리스 실패"시나리오는 일반적으로 수동으로 실행하거나 모니터링하기 때문에 (그리고 바로 그 자리에서 수정 사항을 적용 할 수 있기 때문에) 관리가 더 용이합니다. 코드를 수정 한 후에도 복구되지 않습니다.

물론 여전히 수정되어야합니다.

이 버그뿐만 아니라 마지막으로 성공한 릴리스를 보존하는 것도 가치가 있습니다. 예 : 값 파일 등의 디버깅 문제

@peterholak "첫 번째 릴리스 실패"시나리오는 때때로 CI / CD로도 수행됩니다. 예를 들어, 클러스터에 대한 액세스가 제한되어 있고 "관리"를 어떻게해야합니까?

이 문제는 대부분의 사람들이 프로덕션에서 helm을 사용한다는 점에서 우선 순위가 높은 문제 여야합니다. --atomic helm 설치를 실행할 수 있지만 배포하기 전에 실패 이유를 검사하려면 어떻게해야합니까? 설치가 실패하기 전에 시간 제한으로 인해 시간이 제한되고 되돌아갑니다. 성공적으로 업그레이드 할 수 있다면 실패를 검사 할 때 시간을 낭비하지 않아도됩니다.

또한 helm 릴리스의 멱등 적 배포를 위해 upgrade --install을 사용하고 있습니다. 이것이 자동화 된 ci / cd 파이프 라인이 작동하는 방식이기 때문입니다. 우리는 배포 파이프 라인을 우회하기 때문에 helm을 수동으로 조작 할 계획은 없습니다.

자동화 된 배포 파이프 라인에서 첫 번째 배포는 거의 항상 실패합니다. 후속 배포는 첫 번째 시도와 다르게 트리거되지 않아야합니다.

이 문제의 우선 순위를 상당히 높이십시오.

경험이 너무 나쁘고 프로덕션 중이기 때문에 전체 릴리스를 단순히 삭제할 수 없습니다! 서버 다운 타임이 발생합니다! 결국이 문제를 어떻게 다룰 수 있을까요?

또한 누군가 질문 / 지원 레이블을 제거 할 수 있습니까? 이 문제는 누락 된 문서에 관한 것이 아니라 자동화 된 배포 파이프 라인에서의 사용을 지원하지 않는 Helm의 현재 동작에 관한 것입니다.

# 7806 PR이 마스터에 병합되었습니다. 3.2에서 출시 될 예정입니다. 이에 따라이 문제를 종료합니다.

큰! 이것은 Helm과 관련된 대부분의 문제를 해결합니다.

첫 번째 릴리스가 실패하면 현재 동작은 무엇입니까 (아직 배포 된 릴리스가 없음)?

있었다 https://github.com/helm/helm/issues/3353 에 의해 해결 된 https://github.com/helm/helm/pull/3597 만하면 --force 사용됩니다.

--force 은 Helm 3 (https://github.com/helm/helm/issues/6378)에서 문제를 해결하기위한 제안 (https://github.com/helm/helm/ issues / 7082), 그리고 언급 된이 스레드의 다른 코멘트처럼 --force 를 사용하는 것이 항상 적합한 것은 아닙니다. 따라서 전체 상황은 여전히 ​​다소 불분명합니다.

@technosophos 수정 주셔서 감사합니다. 호기심, 언제 3.2. 릴리스를 설치할 수 있습니까? 기존에 실패한 릴리스에서 app-name has no deployed releases 오류가 계속 발생합니다. 그리고 그것은 CI / CD 파이프 라인의 일종의 차단제입니다.

@peterholak #

3.2는 4 월 16 일 공개 개발 회의에서 논의됩니다. 지금 바로 마무리 할 수있는 것처럼 보이는 항목으로 분류했습니다. 그런 다음 베타 릴리스 프로세스를 시작합니다 (관리자가 내일 전화에 모두 동의한다고 가정).

다음 명령으로 언급 된 문제를 해결하기 위해 AKS 해결에서 동일한 문제에 직면했습니다.

helm version : 3.1.2
명령을 사용하여 k8s 클러스터에서 패키지를 삭제합니다.
helm delete <release-name>

배포주기를 실행하여 문제를 해결합니다.

3.2.0 버전에는 여전히 문제가 있습니다.

@deimosfr 릴리스 3.2.1에 포함될 # 7653에서 수정되었습니다. 아직 릴리스되지 않았지만 마스터를 구축하려는 경우 수정할 수 있습니다.

나는 3.2.1이고 이것은 여전히 ​​일어나고 있습니다.

이 오류가 발생할 수있는 이유는 여전히 있습니다. 3.2.1은 단순히 오류를 제거하지 않았습니다. 원인 중 일부를 제거했습니다. 그래도 문제가 해결되지 않으면 문제가 해결되지 않은 것입니다.

@yinzara 문제가없는 새 클러스터에 대한 원래 설명에서 "경로 b"라는 고전적인 경우가 있습니다. Helm v2가 제대로 작동하는 다른 클러스터에서도이 오류를 재현 할 수 있습니다. 우리는 물론 고전적인 "이것은 다른 것에 의해 발생합니다. 새로운 문제를여십시오"댄스를 할 수 있지만, 그것이 실제로 해결되지 않았다는 것을 단순히 인식하면 더 빠를 것이라고 생각합니다.

helm list 의 결과는 무엇입니까? 이전에 실패한 릴리스의 "상태"는 무엇입니까? Helm 2에는이 문제가 있으며 전혀 수정되지 않았으므로 여전히 문제가 생각하는 것과 다르다고 생각합니다.

버전 3.2.1에서 계속 발생합니다.

초기 배포가 3 번 실패하면 모든 것이 중단됩니다 ... 차트를 삭제하지 않고 좋은 차트를 배포하면 수정할 방법이 없습니다.

세부:

helm history t3-mac -n t3                                                                                                                                                                 REVISION        UPDATED                         STATUS          CHART           APP VERSION     DESCRIPTION
1               Fri May 22 18:55:11 2020        failed          t3-mac-2.13.0   2.13.0          Release "t3-mac" failed: timed out waiting for the condition
2               Fri May 22 19:33:44 2020        failed          t3-mac-2.13.0   2.13.0          Upgrade "t3-mac" failed: timed out waiting for the condition
3               Fri May 22 19:57:51 2020        pending-upgrade t3-mac-2.13.0   2.13.0          Preparing upgrade

helm.exe upgrade --namespace t3b --install --force --wait t3b-mac t3b-mac-2.13.0.tgz
2020-05-22T18:14:01.7103689Z Error: UPGRADE FAILED: "t3b-mac" has no deployed releases

배포 된 차트에서 동일한 문제가 발생하고 포드가 정상적으로 실행되고 있습니다.

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

하지만 업그레이드 할 수 없습니다.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm      default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

내 쪽에서도 일어 났는지 확인합니다

@zodraz helm 상태는 오류의 원인을 보여줍니다. 최신 릴리스는 실패한 것으로 표시되지 않고 "설치 대기 중"으로 표시됩니다. 이는 마지막 업그레이드를 관리하던 프로세스가 완료되기 전에 (즉, 오류가 발생하거나 성공하기 전에) 인위적으로 종료되었음을 의미합니다.

업그레이드를 허용하기 위해 보류중인 설치 상태를 유효한 오류 상태로 포함하지 않기로 결정한 것은 프로젝트 관리자의 결정이었습니다. (즉 이것은 설계된대로 작동합니다)

헬멧 업그레이드가 완료되기 전에 취소되는 이유를 확인하는 것이 좋습니다. 피할 수있는 상황이어야합니다.

배포 된 차트에서 동일한 문제가 발생하고 포드가 정상적으로 실행되고 있습니다.

vm-victoria-metrics-single-server-0                    1/1     Running     0          2d18h

하지만 업그레이드 할 수 없습니다.

$ helm version
version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.0", GitCommit:"9e991415386e4cf155a24b1da15becaa390438d8", GitTreeState:"clean", BuildDate:"2020-03-26T06:16:15Z", GoVersion:"go1.14", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.8", GitCommit:"ec6eb119b81be488b030e849b9e64fda4caaf33c", GitTreeState:"clean", BuildDate:"2020-03-12T20:52:22Z", GoVersion:"go1.13.8", Compiler:"gc", Platform:"linux/amd64"}


ismail ~ $ helm list
NAME  NAMESPACE   REVISION    UPDATED                                 STATUS      CHART                                   APP VERSION    
vm    default     1           2020-05-23 16:20:35.243505 +0300 +03    deployed    victoria-metrics-single-0.5.3           1.35.6         

$ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases


ismail ~ $ helm upgrade --install vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Release "vm" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists. Unable to continue with install: existing resource conflict: namespace: , name: vm-victoria-metrics-single, existing_kind: policy/v1beta1, Kind=PodSecurityPolicy, new_kind: policy/v1beta1, Kind=PodSecurityPolicy

나는 당신의 문제가 나에게 상당히 당혹 스럽다고 말할 것입니다. 나는 당신이 가진 로그 출력을 감안할 때 어떻게 일어날 수 있었는지 볼 수 없습니다. 3.2.1의 수정 릴리스는 실패한 릴리스가 없으므로 상황에 도움이되지 않습니다. helm 릴리스 정보를 포함하는 Kubernetes에서 일부 비밀이 제거 된 것 같습니다. 가능한 경우 릴리스를 완전히 제거하고 다시 설치하는 것이 좋습니다.

안녕하세요 @yinzara ,

문제는 취소하지 않았다는 것입니다. 제가 세 번째로 시작 (그리고 오류가 발생하여 실패하도록 배포에 오류가 발생했기 때문에)이 "손상된 상태"에 도달 한 세 번째 시간을 이해합니다. .

이 상태는 복구 할 수 없습니다. 따라서이를 수정하는 유일한 방법은 차트를 삭제하는 것입니다 ... 원자 플래그를 사용하여 항상 롤백하고이 "손상된 상태"에 도달하지 않도록 방지하는 제 해결 방법입니다.

나는 메인테이너의 결정을 이해한다 ... 그러나 이것은 혼란을 야기하고, 전혀 가능한 해결책이 없다 (차트를 삭제하지 않는다면) 그리고 글쎄, 내가 말했듯이 3 개의 오류가 발생했을 때이 상태에 도달했다 ... 취소하지 않고 .. .

어쨌든 교훈은 원자 플래그를 통해 롤백하고 배웠습니다.

안녕하세요 @yinzara

실패한 이유를 찾았습니다.

잘못된 매개 변수를 -selfScrapeInterval=10 했습니다. server.extraArgs.selfScrapeInterval = 10이어야합니다.

따라서 매개 변수의 - 문제입니다.
이 유형의 변수 오류에 대해 helm 오류가 의미가 없었을 수도 있습니다.

하나 실패 :

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "-selfScrapeInterval=10" 
Error: UPGRADE FAILED: "vm" has no deployed releases

성공:

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "server.extraArgs.selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:35:15 2020
NAMESPACE: default
STATUS: deployed
REVISION: 3
TEST SUITE: None
NOTES:
TBD

이것은 또한 작동합니다 :

ismail sf $ helm upgrade vm vm/victoria-metrics-single --set "selfScrapeInterval=10" 
Release "vm" has been upgraded. Happy Helming!
NAME: vm
LAST DEPLOYED: Tue May 26 22:37:43 2020
NAMESPACE: default
STATUS: deployed
REVISION: 4
TEST SUITE: None
NOTES:
TBD

나는 같은 문제가 있습니다 : '(그리고 나는 데이터를 잃을 것이고 그것을 할 수 없기 때문에 퍼지를 사용할 수 없습니다.

우리는 중요한 워크로드를 배포 할 때 helm 릴리스를 버려야합니다. 심지어 istio의 istioctl이 이러한 이유로 helm을 버립니다 (내 생각에). 투구 템플릿을 사용합니다 kubctl -f- 이 문제를 방지하기 위해이 과정에서 삭제 된 리소스에 대해 기억해야하는 문제가 발생합니다.

@GloriaPG 더 많은 정보를 공유 할 수 있습니까? 같은 문제가 어떻게 발생합니까? @yinzara 가 스레드에서 앞서 언급했듯이 # 7652로 해결되지 않는 경우가 발생할 수 있습니다. 그러나 그 결론에 도달하기 전에 도움이 될 더 많은 정보가 필요합니다.

안녕하세요 @bacongobbler

--install 및 --force 플래그와 함께 helm upgrade 사용합니다.

helm upgrade --install ${PROJECT_NAME} ${CHART_NAME} \
   --namespace $NAMESPACE_NAME \
   --values ${SECRETS} \
   --values ${CONFIG_VALUES} \
   --force \
   --wait \
   --timeout ${MAX_WAIT_SECONDS} || rollback

불행히도 릴리스가 실패한 상태 인 경우 :

$ helm list
NAME                    NAMESPACE   REVISION    UPDATED                                 STATUS      CHART           APP VERSION
PROJECT_NAME                CHART_NAME      136         2020-07-09 14:13:09.192381483 +0000 UTC failed      CHART_NAME-0.1.0

결과 :

Error: UPGRADE FAILED: "PROJECT_NAME" has no deployed releases
Error: failed to replace object: Deployment.apps "PROJECT_NAME" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{"app":"PROJECT_NAME"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

어떻게 해결할 수 있습니까? 보인다 --force 와 --install 플래그가 작동하지 않습니다

이것이 프로덕션 환경이므로 릴리스를 제거하고 처음부터 만들 수는 없습니다.

제안 해 주셔서 감사합니다

https://github.com/kubernetes/client-go/issues/508 과 관련된 오류 인 것 같습니다.
배포에서 선택기를 변경할 수 없습니다. 배포를 취소하고 다시 배포해야합니다.

@yinzara 재미있는 점은 배포에서 선택기를 변경하지 않고 모든 것이 9/10 릴리스에서 작동한다는 것입니다. 배포 중 하나에서 sth가 잘못되어 릴리스가 실패한 상태이고 어떤 식 으로든 복구 할 수 없습니다. 배포 자체가 작동하고 Pod가 실행 중이지만 더 이상 수정할 수 없습니다.

릴리스가 실패한 상태가 된 후 더 이상 helm을 사용하여 변경할 수 없다는 것은 다소 반 직관적입니다. --force 플래그를 사용하면 전체 배포를 교체하거나 변경 사항을 적용 할 수 있지만 기존 릴리스를 수정하고 작업 할 방법을 찾을 수 없습니다.

네, 안타깝게도 이것은 실제로 조타 문제가 아닌 것 같습니다. 릴리스에 대해 뭔가 실패했으며 Kubernetes에서 잘못된 상태입니다. 선택기가 엉망이거나 예상 한 것과 다를 가능성이 높지만 "app-name"에 대해 표시되는 오류는 배포 된 릴리스가 없습니다.

이전 버전으로 롤백을 시도했습니다. 릴리스는 현재 deployed 상태입니다. 불행히도 아무것도 변경되지 않으므로 불행히도 삭제하고 다시 배포하는 것이 유일한 방법이라고 생각합니다.

따라서 이것에 대한 나의 특별한 문제는 재현하기 쉽습니다.

helm3 ( --atomic 및 --cleanup-on-fail )으로 무언가 배포를 시작하고 리소스 생성을 시작한 후 프로세스를 ctrl + c합니다. 롤백 된 항목이없고 리소스가 여전히 존재하며 이후에 install --upgrade 실행을 시도하면 "배포 된 릴리스가 없습니다"오류가 발생합니다.

이 ctrl + c는 빌드가 이미 실행중인 동안 누군가가 CI 시스템의 브랜치에 새 커밋을 푸시 할 때 본질적으로 발생하는 것입니다. helm 업그레이드가 취소되고 완전히 중단 된 상태가됩니다.

이 시점 이후에 문제를 해결할 수있는 방법이 있습니까? 이 스레드의 다른 많은 사람들과 마찬가지로 삭제는 옵션이 아닙니다.

편집 : 일단 이것이 깨지면 helm ls 는 릴리스를 표시하지 않고 helm history 는 설치 보류 상태로 표시합니다.

사실-신경 쓰지 마세요. 이로 인해 영향을받는 사람들을 위해 한 가지 해결책이 있습니다. kubernetes에서 수동으로 기록 레코드를 삭제하는 것입니다. 비밀로 저장됩니다. 문제가되는 pending-install 상태 항목을 삭제하면 upgrade --install 다시 성공적으로 실행할 수 있습니다!

@AirbornePorcine- 설치 보류 항목을 삭제하기 위해 kubernetes에서 필요한 변경 사항에 대해 자세히 설명해 주시겠습니까?

@ tarunnarang0201 Helm은 배포 한 것과 동일한 네임 스페이스에서 각 배포에 대한 kubernetes 비밀을 생성합니다. 'helm.sh/release.v1'유형이고 'sh.helm.release.v1.release'와 같은 이름이 표시됩니다. -name.v1 '. 가장 최근의 비밀을 삭제하기 만하면됩니다 (예제에서 'v1'접미사를 보면 배포 할 때마다 증가합니다).

@AirbornePorcine 감사합니다!

@AirbornePorcine @ tarunnarang0201 @ ninja- 상태 레이블을 패치 할 수도 있습니다. 특히 이전에 배포 된 릴리스가없는 경우 특히 그렇습니다.

Helm 3의 경우 https://github.com/helm/helm/issues/5595#issuecomment -580449247에서 내 의견을

Helm 2에 대한 자세한 내용과 지침은 https://github.com/helm/helm/issues/5595#issuecomment -575024277에서 내 의견을

이 대화는 너무 깁니다. 각 댓글에는 하나의 해결책이 있습니다. .... 결론은 무엇입니까?
이전 Helm 2.12를 사용해 왔으며 문제가 없었지만 이제 v3.2.4에서는 이전에 실패한 배포가이 오류와 함께 실패합니다.

우리는 Terraform과 최신 helm 공급자를 사용하고 있습니다. 따라서 --force 또는 --replace 사용해야합니다.

@xbmono 대화가 길기 때문에

• 당신의 석방이이 상태가 될 수있는 많은 이유가 있습니다.
• 이것은 Helm 2에서도 가능했으며 Helm 3에서 작동하는 솔루션이 다릅니다.
• 이 문제의 사용자가 거기에 도달하기 위해 취한 경로가 다릅니다.
• 수행하려는 작업과 PVC 손실 및 다양한 가능한 다운 타임 조합의 위험을 감수 할 의사가 있는지 여부에 따라 다양한 옵션이 있습니다.

"배포 된 릴리스가 없습니다"오류가 발생하는 경우 install --replace 또는 upgrade --install --force 이 (가) 스스로 도움이 될지 잘 모르겠습니다.

현명한 제안은 아마도 주어질 수 있습니다

• 사람들이 무슨 일이 일어 났는지 볼 수 있도록 릴리스에 helm history 를 제공하면
• 실패의 원래 이유 / 그 곳에 도달하기 위해 수행 한 작업을 공유하는 경우-원래 문제가 해결되었다고 느끼는지 여부

가능한 옵션에 대한 요약

• 기존 k8s 리소스 또는 다운 타임에 신경 쓰지 않는다면 helm uninstall && helm install 가 옵션 일 수 있습니다.
• 차트 설치가 처음 실패한 경우 릴리스 비밀 메타 데이터를 삭제 하고 helm install 다시 삭제할 수 있습니다. --atomic 등을 사용했는지 여부에 따라 실패로 인해 잔해가 남는 경우 k8s 리소스를 수동으로 정리해야 할 수도 있습니다.
• --wait ed 설치를 중단하고 helm history 에 마지막 릴리스가 pending-install 이 표시 되면 최신 릴리스 비밀 메타 데이터를 삭제 하거나 릴리스 상태를 패치 할 수 있습니다.
• 시나리오의 일부 다른 조합에서, 그것도 할 수있을 수 있습니다 릴리스 상태를 패치 이후의 경우 하나 또는 그 이상의 릴리스 비밀의 볼 upgrade 진행할 수 있습니다, 그러나 내 지식, 이러한 경우의 대부분은 해결되었다 # 7653에 의해 (역사상 어딘가에 deployed 릴리스가 있는지 확인하기 위해) 그래서 이것이 지금 유용하다면 놀랄 것입니다.

이것은 닫힌 문제이기 때문에 어쨌든 더 구체적인 다른 티켓에서 디버그하고 문서화하는 것이 좋은 근본 원인이 있다고 생각합니다.

@chadlwilson 응답

helm history 는 행을 반환하지 않습니다!

Error: release: not found

그러나 helm list 는 실패한 배포를 반환합니다.

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

우리는 Terraform을 사용하고 있으며 Jenkins에서 매시간 자동으로 환경을 배포합니다. terraform을 사용하면 helm upgrade 사용할 수 없습니다. helm 공급자가 수행하는 작업입니다.

테라 폼 코드에서 force_update 을 true 설정했습니다. 운이없고 replace 를 true 으로 설정했습니다.

resource "helm_release" "productStack" {
  name = "${var.namespace}"
  namespace = "${var.namespace}"
  chart = "${var.product_stack}"
  force_update = true//"${var.helm_force_update}"
  max_history = 10
  replace = true

  wait = true
  timeout = "${var.timeout_in_seconds}"

}

그래서 나는 그것이 wait=true 와 관련이 있는지 궁금합니다. 따라서 이전 배포가 실패한 이유는 클러스터가 도커 저장소와 통신 할 수 없어 timeout 도달하고 상태가 failed 되었지만 문제를 해결하고 pods 성공적으로 다시 시작되었습니다. 이제 분명히 helm delete 작동하지만 매번이 작업을 수행하면 관리자 나 개발자가 기뻐할 것입니다.

helm v2를 사용하면 배포가 실패하고 개발자가이를 수정하면 다음 배포에서 실패한 배포를 업그레이드합니다.

M:\>helm3 list -n cluster171
NAME            NAMESPACE       REVISION        UPDATED                                 STATUS  CHART                           APP VERSION
cluster171      cluster171      1               2020-09-01 04:45:26.108606381 +0000 UTC failed    mychart-prod-0.2.0-alpha.10    1.0

helm history 실패 (오타? 놓친 네임 스페이스? 잘못된 투구 버전?) 이상한 보이지만, 그것의 개정 주어진 1 에서 list 당신은 제 일을하려고하는 것보다 새 차트를 설치할 때와 처음 설치가 실패했습니다. 차단을 해제하려는 경우 위와 같이 릴리스 비밀 메타 데이터를 삭제하거나 상태를 패치하고 다시 시도 할 수 있습니다. 이는 Helm 또는 Helm Terraform Provider의 관점에서 메타 데이터가 잘못된 상태에 있음을 나타낼 수 있지만 어떻게 거기에 도달했는지는 아닙니다.

어쨌든, # 7653이 병합 된 이후로 Helm 3.2.1 실패한 최초 배포에 비해 upgrade 을 수행하는 데 문제가 없습니다. 공급자가 실제로 사용중인 특정 Helm 버전을 다시 확인하고 싶습니까? Helm Terraform 공급자가 install 실패 후 릴리스 상태를 파악하는 방식과 관련이있을 수도 있습니다. 나는 그 공급자에 대한 경험이 없으며 개인적으로 Helm을 TF와 같은 다른 선언적 추상화로 래핑하는 것을 선호하지 않습니다. 왜냐하면 문제가 발생할 때 훨씬 더 불투명하다는 것을 발견하기 때문입니다.하지만 당신은 더 깊이 파고 들고 싶을 수도 있습니다. .

어쨌든 위에서 말했듯이 처음 배포에 실패한 후 오류가 has no deployed releases 이면 replace 도 force 도 생각하지 않습니다. 다른 개입없이 상황을 되살리는 데 도움이 될 가능성이 높으며 51 명의 참가자가있는이 오래된 비공개 티켓을 앞뒤로 이동하는 것이 모든 관련자에게 그렇게 생산적이지 않은 것처럼 보이기 때문에 더 디버그하고 다른 곳에서 대화를 나누는 것이 가장 좋습니다.

오타가 없었습니다. 또한 이는 최초 배포 여부와 관계없이 발생합니다.

앞서 언급했듯이 Jenkins에서 배포를 기다린 다음 배포 실패 여부를 알리기 위해 --wait 옵션을 사용하고 있습니다.

시간 초과에 도달하고 배포가 성공하지 못한 경우 helm 는 배포를 failed 로 표시했으며 해당 릴리스를 수동으로 삭제하는 것 외에 복구 할 방법이 없습니다. 무섭기 때문에 릴리스를 자동으로 삭제하고 싶지도 않습니다.

따라서 --wait 옵션을 제거하면 helm 는 배포를 successful 로 표시합니다.

해결 방법 :

이제 다른 해결책을 찾았습니다. 동일한 문제가 있고 자동화가 이전에 작동했던 것처럼 잘 작동하기를 원하는 사람들을 위해 다음은 내 해결 방법입니다.

• helm 배포에서 --wait 옵션 제거
• 이 명령을 사용하여 배포 할 네임 스페이스에 대한 배포 목록을 검색합니다. kubectl get deployments -n ${namespace} -o jsonpath='{range .items[*].metadata}{.name}{","}{end}'
• split 를 사용하여 위의 쉼표로 구분 된 목록을 배열로 바꿀 수 있습니다.
• 그런 다음 여러 명령을 병렬로 실행할 수 있습니다 (Jenkins를 사용하므로 쉽게 수행 할 수 있음). kubectl rollout status deployment ${deploymentName} --watch=true --timeout=${timeout} -n ${namespace}
• timeout 이후에 예를 들어 7m 7 분을 의미하고 배포가 여전히 성공하지 못한 경우 명령이 오류와 함께 종료됩니다.
• 문제 해결됨.

사실-신경 쓰지 마세요. 이로 인해 영향을받는 사람들을 위해 한 가지 해결책이 있습니다. kubernetes에서 수동으로 기록 레코드를 삭제하는 것입니다. 비밀로 저장됩니다. 문제가되는 pending-install 상태 항목을 삭제하면 upgrade --install 다시 성공적으로 실행할 수 있습니다!

또는 이것은 나를 위해 일했습니다.

helm uninstall {{release name}} -n {{namespace}}

kubectl -n $namespace delete secret -lstatus=pending-upgrade 고정
지금 다시 조타하십시오.

왜 이것이 닫혔는지 잘 모르겠습니다. 방금 새로운 Helm 3.3.4를 사용했습니다. 초기 설치가 실패하면 두 번째 helm upgrade --install --force가 여전히 동일한 오류를 표시합니다. 이러한 모든 해결 방법은 작동하지만 수동 으로 이루어집니다. 100 % 자동 CI / CD를 원할 때 도움이되지 않습니다. 100 % 자동 CI / CD를 사용하면 수동으로 정리를 수행하지 않고도 수정 사항을 푸시하여 다른 배포를 트리거 할 수 있습니다.

누구든지 이것이 첫 번째 릴리스이므로 자동으로 삭제하는 것이 안전해야한다는 플래그를 추가하는 것을 생각한 적이 있습니까? 아니면 "--force-delete-on-failure"와 같은 것을 추가 하시겠습니까? 문제를 무시하는 것은 도움이되지 않습니다.

@ nick4fake AFIK PR # 7653에 의해 닫혔습니다. @yinzara 는 더 자세한 정보를 제공 할 수 있습니다.

업그레이드 보류중인 릴리스를 덮어 쓰는 것을 허용하지 않기로 한 유지 관리자의 결정이었습니다. 그러나 모든 해결 방법이 CI / CD 파이프 라인에서 작동하지 않는 해결 방법이라는 귀하의 진술은 사실이 아닙니다. helm 업그레이드를 실행하기 전에 마지막으로 제안 된 해결 방법을 빌드 단계로 추가 할 수 있습니다 (또한 CI / CD pipieline에서 --force를 사용하지 않음). 실패의 원인을 디버그 할 수 있도록하는 것이 아니라 다음 릴리스를 설치하기 직전에 릴리스를 삭제한다는 점을 제외하고는 제안한 것과 동일한 효과가 있습니다.

또한 업그레이드 명령을 실행하기 전에 자동화 된 빌드에서 다음을 사용하여 "보류중인"릴리스를 제거했습니다 (NS_NAME 환경 변수를 배포 할 네임 스페이스로 설정해야 함).
```bash

! / usr / bin / env bash

RELEASES = $ (helm list --namespace $ NS_NAME --pending --output json | jq -r '. [] | select (.status == "pending-install") | .name')
만약 [[ ! -z "$ RELEASES"]]; 그때
helm delete --namespace $ NS_NAME $ RELEASES
fi

@yinzara 스 니펫에 감사드립니다.이 스레드를 찾는 분들에게 매우 도움이됩니다.

내 요점은 여전히 ​​유효합니다. 단순히 릴리스를 삭제하는 것은 안전하지 않습니다. 단일 리소스가 실패하는 경우 Helm 강제 업그레이드 릴리스를 수행 할 수없는 이유는 무엇입니까? 릴리스를 새 버전으로 교체하는 것이 전체 삭제보다 더 나은 해결책으로 보입니다. Helm의 핵심 기본 사항 (상태를 관리하는 방법과 같은)을 이해하지 못할 수 있으므로 불가능할 수 있지만 첫 번째 설치가 실패 할 경우 사용자가 수동으로 개입하도록하는 것이 더 좋은 이유를 여전히 이해하지 못합니다.

이 토론 스레드를 확인하면 사람들이 여전히 문제에 직면 해 있습니다. 이 스레드에 대한 링크와 수행 할 작업에 대한 몇 가지 제안과 함께 Helm 오류 메시지에 추가 정보를 추가하는 것에 대해 어떻게 생각하십니까?

@ nick4fake "실패"와 "설치 대기 중"이 섞여 있다고 생각합니다.

라이브러리 관리자는 실패한 릴리스에 대해 귀하와 동의하므로 내 PR을 수락했습니다.

"실패한"릴리스는 업그레이드 할 수 있습니다. 그것이 제 PR이 한 일입니다. 리소스 중 하나가 실패하여 릴리스가 실패하면 해당 릴리스를 업그레이드 할 수 있습니다 (예 : upgrade --install도 작동 함). 그러면 "app-name"에 배포 된 릴리스 없음 오류가 표시되지 않습니다.

"설치 대기 중"릴리스에 대해 이야기하고 있습니다. 유지 관리자는 보류중인 설치 릴리스 (강제 또는 기타)를 업그레이드하는 것이 안전하다고 생각하지 않습니다. 아직 진행 중이거나 자동으로 해결할 수 없다고 생각하는 부분적으로 완료된 상태 일 수 있기 때문입니다. 내 PR은 원래이 상태를 허용했고 관리자는이를 제거하도록 요청했습니다.

이 상태에서 릴리스를 찾은 경우 배포 구성을 재고 할 수 있습니다. 제대로 구성된 CI / CD 파이프 라인에서는 이런 일이 발생해서는 안됩니다. 실패하거나 성공해야합니다. "보류 중"은 설치가 아직 처리되는 동안 취소되었음을 의미합니다.

나는 유지 관리자가 아니므로 귀하의 제안에 대한 내 의견은 관련이 없지만 실제로 오류 또는 메시지로 인쇄 된 Github 문제에 대한 코드베이스의 언급을 찾지 못하므로 허용하지 않을 것이라고 확신하지만 당신은 PR을 작성하고 참조하십시오 :-)

즉, 귀하의 요점이 여전히 유효하다는 귀하의 진술에 동의하지 않습니다. 내 제안은 보류중인 릴리스를 제거 할 수 있지만 @abdennour 제안은 보류중인 설치 릴리스를 설명하는 비밀을 삭제하는 것입니다. 이렇게하면 릴리스에서 리소스를 삭제하지 않고 릴리스를 업그레이드 할 수 있습니다.

이 스레드에 대한 링크와 수행 할 작업에 대한 몇 가지 제안과 함께 Helm 오류 메시지에 추가 정보를 추가하는 것에 대해 어떻게 생각하십니까?

이것에 +1. 이 스레드를 찾고 pending-install 릴리스가 무엇인지 이해하려면 여전히 Google을 검색해야합니다. 그러면이 오류 메시지에 대한 추론을 시작할 수 있습니다.

나는 helm upgrade 문제가 있었고 그것이 나를 여기로 이끌었습니다. -n <namespace> 추가하여 해결되었습니다. 어쩌면 그것은 누군가를 도울 것입니다.

Helm3의 경우 패치를 통해 해결할 수 있음
kubectl -n <namespace> patch secret <release-name>.<version> --type=merge -p '{"metadata":{"labels":{"status":"deployed"}}}'

release-name 및 version - kubectl get secrets -n <namespace> | grep helm 에서 볼 수 있음