Helm: 업그레이드 실패 : 이름이 ""인 리소스가 없습니다.

번들 종속성이있는 차트가있는 비슷한 문제가 발생합니다. 새 종속성을 추가하고 helm upgrade 하면 결과는 설명 된 것과 동일합니다. 리소스가 제대로 생성되었지만 helm은 오류를 반환합니다.

따라서 이것이 설치된 경우 : helm install -n my-release

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/

그런 다음 새 차트가 종속성으로 추가됩니다.

my-thing/
  Chart.yml
  charts/
    depended-upon-thing/
    new-dependency/

릴리스가 다음으로 업그레이드되면 helm upgrade my-release my-thing helm이 다음 오류를 생성합니다.

Error: UPGRADE FAILED: No resource with the name new-dependency found.

@devth 마스터에서이 문제를 재현 할 수 없습니다. 여전히이 문제가 발생합니까? 실행중인 조타기 / 경운기의 버전은 무엇입니까?

감사!

@elementalvoid 또한 마스터에서 새로운 종속성 오류를 재현 할 수 없었습니다. 여전히이 문제가 발생합니까? 실행중인 조타기 / 경운기의 버전은 무엇입니까?

감사합니다.

그 당시 나는 알파 4에있었습니다. 알파 5와 @devth 의 예제를 사용해서도 문제를 재현 할 수 없었습니다.

좋구나. 지금은 닫겠습니다. 이러한 문제 중 하나가 다시 표시되면 문제를 제기하십시오.

다시 한 번 감사드립니다.

@michelleN 감사합니다! 이번 주에 마스터 재현을 시도 할 시간이 없어서 미안합니다. 곧 업그레이드를 기대합니다!

hostPath 배포 / 볼륨 사양을 PVC로 이동할 때도 마찬가지입니다.
버그는 업그레이드 매니페스트가 새로운 매니페스트에 의존하는 것 같습니다 (이전 매니페스트에서 "누락"?).
버전 : 2.7.2

이상하게도 버전 2.7.2에서 새 역할로 차트를 업그레이드하려는 동일한 동작이 표시됩니다. Tiller는 실제로 역할을 생성 했음에도 불구하고 역할을 찾을 수없고 배포에 실패한다고 불평합니다.

내 상황은 새 리소스가 있고 새 리소스와 함께 새 버전의 helm 차트를 배포 한 것입니다. 그 배포는 실패했습니다. 글쎄, 새로운 객체는 kubernetes에서 생성되었습니다. yaml을 수정하고 차트에서 업그레이드를 다시 실행했는데 리소스를 찾을 수 없다는 오류 메시지가 나타납니다. kubernetes로 이동하여 실패한 배포로 생성 된 새 리소스 (내 경우에는 역할 및 역할 바인딩)를 제거해야했습니다. 그 후 현재 개체가 있는지 확인하기위한 helm 검사가 실패하고 (https://github.com/kubernetes/helm/blob/7432bdd716c4bc34ad95a85a761c7cee50a74ca3/pkg/kube/client.go#L257) 실패하고 리소스가 생성됩니다. 다시. 버그처럼 보입니다. 실패한 차트에 대한 새로운 리소스를 고려해야하는 곳은 어디입니까?

업그레이드하는 동안 유사한 오류가 발생합니다.

$ helm upgrade --install bunny ./app --namespace=staging --reuse-values --debug
[debug] Created tunnel using local port: '53859'

[debug] SERVER: "127.0.0.1:53859"

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

Configmap이 생성되었습니다.

$ k get configmap
NAME                 DATA      AGE
bunny-proxy-config   1         7m

내 configmap :

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ template "proxy.fullname" . }}-config
  labels:
    app: {{ template "proxy.name" . }}
    chart: {{ template "proxy.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
data:
  asd: qwe

우리는 같은 문제가 있습니다.

전체 릴리스를 삭제 한 다음 다시 설치했습니다. 현재는 작동하는 것 같습니다.

$ helm del --purge bunny

나는 또한이 문제가 있습니다.

클라이언트 : & version.Version {SemVer : "v2.8.0", GitCommit : "14af25f1de6832228539259b821949d20069a222", GitTreeState : "clean"}
서버 : & version.Version {SemVer : "v2.8.0", GitCommit : "14af25f1de6832228539259b821949d20069a222", GitTreeState : "clean"}

이것은 helm 사용시 자주 발생하며 전체 --purge 합니다. 그것은 해결책이 아닙니다.

CI / CD를 사용하는 경우 적용되지 않습니다.
업그레이드가 실패하고 롤링 업데이트 전략을 사용하면 어떻게됩니까? 아직 작동중인 릴리스를 삭제해야합니까?

배포 문제 또는 이와 유사한 문제가 있지만 비밀 / cm이 생성되었지만 Helm이 추적을 잃고 많은 작업을 거부하는 경우에도 동일한 문제가 나타납니다.

나는 그것이 깨지지 않은 릴리스에서도 발생하는 것을 보았지만 (즉, 통과 한 것으로 보임) 아직 그 원인을 파악하지 못했습니다.

기존 helm 배포에 리소스를 추가 할 때도이 문제 (서버 v2.8.2)를 재현 할 수 있습니다. 새 리소스를 추가해야 할 때마다 배포를 삭제하고 다시 배포해야하는 것은 프로덕션에서 큰 문제가 될 것입니다.

우리의 경우 차트에 configmap을 추가했는데 차트가 다음으로 업그레이드되지 않습니다.

오류 : 업그레이드 실패 : 이름이 "인 리소스가 없습니다."발견

참고 : 2.7.2를 사용하고 있습니다.

helm이 변경된 사항을 결정할 때 이전 릴리스에서 새 configmap 리소스를 찾고 찾지 못하기 때문에 이런 일이 발생한다고 생각합니다. 이 오류가 발생한 코드는 https://github.com/kubernetes/helm/blob/master/pkg/kube/client.go#L276 -L280을 참조

실패한 업그레이드에 대한 틸러 로그 :

[tiller] 2018/05/03 19:09:14 preparing update for staging-collector
[storage] 2018/05/03 19:09:14 getting deployed release from "staging-collector" history
[tiller] 2018/05/03 19:10:39 getting history for release staging-collector
[storage] 2018/05/03 19:10:39 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:41 preparing update for staging-collector
[storage] 2018/05/03 19:10:41 getting deployed release from "staging-collector" history
[storage] 2018/05/03 19:10:42 getting last revision of "staging-collector"
[storage] 2018/05/03 19:10:42 getting release history for "staging-collector"
[tiller] 2018/05/03 19:10:44 rendering collector chart using values
[tiller] 2018/05/03 19:10:44 creating updated release for staging-collector
[storage] 2018/05/03 19:10:44 creating release "staging-collector.v858"
[tiller] 2018/05/03 19:10:44 performing update for staging-collector
[tiller] 2018/05/03 19:10:44 executing 0 pre-upgrade hooks for staging-collector
[tiller] 2018/05/03 19:10:44 hooks complete for pre-upgrade staging-collector
[kube] 2018/05/03 19:10:44 building resources from updated manifest
[kube] 2018/05/03 19:10:44 checking 3 resources for changes
[tiller] 2018/05/03 19:10:44 warning: Upgrade "staging-collector" failed: no resource with the name "collector-config" found 
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v857"
[storage] 2018/05/03 19:10:44 updating release "staging-collector.v858" 

이 문제는 배포 된 서비스의 name 레이블을 변경할 때도 발생합니다.

릴리스에서 서비스 이름을 변경하는데 다음으로 업그레이드하지 못합니다.

오류 : 업그레이드 실패 : 이름이 "new-service-name"인 서비스가 없습니다.

이 동작을 수정하기 위해 PR을 만들려고하지만이 문제를 처리하기위한 의도 또는 제안 된 방법을 알고 싶습니다. --force가 우선하도록 허용하는 CLI 플래그도 좋습니다.

중요성에 동의하십시오.

이 문제는 단순히 배포를 삭제할 수없는 경우 이상 할 수 있습니다.

배포 실패로 인해 문제가 발생했습니다.

Helm은 배포 실패 후 정리를 시도하지 않습니다. 즉, 위에서 추가 한 새 ConfigMap과 같은 항목이 생성되지만 '이전'배포에는 참조가 없습니다. 즉, 다음 배포가 발생할 때 helm은 k8s에서 리소스를 찾고 최신 배포 된 개정판 (또는 다른 것)에서 참조 될 것으로 예상합니다. 변화가 있습니다. 해당 릴리스에 없으므로 리소스를 찾을 수 없으며 실패합니다.

이는 배포 실패로 인해 k8s를 상태에 놓으면 helm이 제대로 추적하지 않으므로 차트를 개발할 때 주로 발생합니다. 이것이 일어나고 있음을 알았을 때 k8s에서 ConfigMap을 삭제하고 배포를 다시 시도해야한다는 것을 알았습니다.

@krishicks 예, 이것은 그것을 재현하는 한 가지 방법입니다. 실패한 배포 + 생성되지 않은 리소스 (예 : 잘못된 configmap)도이 문제를 유발할 수 있으며 이는 복구 할 수없는 상태로 이어집니다.

우리는 이것도 치고 있습니다. @krishicks 와 @jaredallard가 언급 한 것과 동일한 문제입니다.

1. 배포에 실패했습니다.
   UPGRADE FAILED: the server was unable to return a response in the time allotted, but may still be processing the request (get configmaps)
2. 다른 릴리스에 대한 후속 변경도 다음과 같은 경고와 함께 실패합니다.
   Error: UPGRADE FAILED: no Service with the name "…" found

첫 번째 문제를 완화하기 위해 helm upgrade --timeout … 플래그를 사용하려고하지만 모든 것을 차단하는 배포 실패는 우리에게 상당한 문제입니다. 또한 helm rollback … 해도이 문제가 해결되지 않았습니다.

으로 helm upgrade … 우리의 사용 사례에 자동으로 실행, --auto-rollback 대한 플래그 helm upgrade 실패한 변경을 되돌립니다있는, 매우 도움이 될 것입니다.

이는 차트에 새 리소스를 추가 할 때 v2.7.2에서 발생합니다.
이것에 대한 수정이 언제 나올지에 대한 견적이 있습니까?

이것은 # 4146으로 수정되어야합니다.

편집 : 아래 참조

그래서 나는 앞으로 나아가는 것이 바람직하지 않은 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

@bacongobbler 항상 작동하지는 않습니다. 삭제가 작동하는 상황이 있고 그 후에도 여전히 작동하지 않는 상황이있었습니다.

리소스를 수동으로 개입 및 삭제하여 쉽게 해결할 수 있습니다.

@bacongobbler 이 리소스는 프로덕션 네임 스페이스의 서비스 또는 배포 개체 일 수 있으며, 이로 인해 서비스 보장이 크게 중단 될 수 있습니다.

네, 알아요. 나는 단지 버그의 동작을 설명하고 관찰하는 것이므로 다른 사람들이 무엇이 관련되어 있는지 알 수 있습니다. :)

다른 클러스터에서이 문제를 두 번 실행하십시오. configmaps와 함께 매번. 리소스를 삭제해도 문제가 해결되지 않았으므로 전체 릴리스를 제거해야했습니다.

여기도 마찬가지입니다. Configmaps뿐만 아니라 ServiceAccount에 하나가 있습니다.

여기 PVC. :)

기본적으로 모든 종류의 우선 순위가 지정된 객체는이 버그의 영향을받습니다.

이 문제를 해결하도록 지정된 사람이 있습니까? 이미 이것에 대한 PR이 있습니까? 무엇을 도와 드릴까요?

나는이 문제에 빠져 들기 쉬운 상황이기 때문에 한 번 이상 물렸다. 그러나 분명히 빠져 나올 수있는 쉬운 방법은 없다. 제 경우에 "좋은"부분은 릴리스에 오류가 있어도 리소스가 업데이트된다는 것입니다 (그게 저를 행복하게하거나 걱정하게 만드는지 확실하지 않음).

helm은 사용자가 잘못된 상태로 들어가는 것을 금지하거나 올바르게 처리해야한다고 생각합니다.
모든 것을 삭제하는 것 외에 실제 수정 사항이 있습니까 (프로덕션 이외의 용도로만 실행 가능)?

다른 사람이 리소스를 삭제해도 문제가 해결되지 않는 다른 경우를 확인할 수 있다면 특정 문제를 해결

@Draiken 아니, 우리는 문제에 대한 여러 해결책을 시도했지만 그들 중 어느 것도 합리적으로 보이지 않습니다.

a) 의도 한대로 업그레이드를 수행하지 않거나
b) 새로운 버그 소개

여기 에 이러한 솔루션과 작동하지 않는 이유에 대해 썼습니다. 대체 솔루션을 찾을 수 있다면 기꺼이 살펴 보겠습니다.

사용자가이 잘못된 상태로 들어가는 것을 막을 수는 없습니다. 우리는 해결책을 살펴 보았지만 모두 다른 문제를 소개합니다. 설치가 일관되지 않은 상태에 있으면 수동 개입없이 "수정"하기가 어렵습니다. 😢

나를 위해 일한 해결 방법은 실패가 발생하기 직전에 helm rollback ... 를 수행하는 것입니다. 그런 다음 차트가 helm install -n new-test-release . 로 새 릴리스에서 작동하는지 확인합니다.

모든 것이 작동하면 테스트 릴리스를 정리하고 이전 릴리스에 대해 helm upgrade ... 를 실행합니다. 그리고 모든 것이 작동했습니다. 이것은 성가신 해결 방법이지만 작동하는 것 같습니다.

이것이 도움이되는지 모르겠지만 테스트 및 프로덕션 클러스터 모두에서이 문제가 발생했습니다.

helm 파일에 대한 변경 사항은 매우 간단합니다.
관련 서비스와 poddisruptionbudget이 포함 된 기존 배포 1 개가 있었지만 변경되지 않았습니다.
자체 서비스와 poddisruptionbudget이있는 두 번째 배포를 추가했습니다.
차트 버전 번호를 올렸습니다.

helm을 실행할 때 처음으로이 오류가 발생했습니다.

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: Deployment.apps "blah-blah" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"app":"blah-blah", "chart":"blah-3", "name":"blah", "release":"project"}: `selector` does not match template `labels`

helm을 다시 실행할 때이 오류가 계속해서 발생합니다.

KUBECONFIG=**** helm upgrade --kube-context=mycluster -f helm/project/mycluster.yaml project ./helm/project --install --wait --timeout 1200

Error: UPGRADE FAILED: no Service with the name "blah-blah" found

물론 키 차트는 내가 모든 것을 삭제하고 재배치했을 때 테스트에서 작동했습니다. 그것은 실제로 찌르는 옵션이 아닙니다.

@veqryn 나는 이것을 많이

편집 : 누군가가 그것을 시도하는 데 관심이 있다면 공개 도커 리포지토리에 푸시하고 사용 방법에 대한 빠른 스 니펫을 포함 할 수 있습니다.

@jaredallard 우리는 관심이 있습니다. 감사!

관리자가 권장하지 않을 수도 있다는 것을 알고 있지만 아무것도없는 것보다 낫습니다.

@jaredallard 자체적으로 작동하지 않기 때문에 패치를 권장 할 수 없습니다 (참조 : https://github.com/helm/helm/pull/4223#issuecomment-397413568). 오류를 우회하지만 리소스를 업그레이드하지 않으므로 패치는 사용자가 원래 의도 한 작업을 수행하지 않습니다. 하나의 문제를 해결하지만 사용자가 수행하려는 원래 문제인 리소스 업그레이드를 수정하지 않고 다른 문제를 소개합니다.

그러나 이것은 흥미 롭습니다.

이 문제가 발생할 때마다 기본적으로 # 4146의 빌드를 사용한 다음 메인 라인으로 다시 바꿉니다.

내가이 권리를 읽고 있다면, 당신은 해결 방법을 찾았다 고 제안하는 것입니다.

a) 오류 우회
b) 원래 의도 한대로 리소스를 업그레이드 할 수 있습니다.

2 helm upgrade s : 하나는 패치가 있고 다른 하나는없는? 그러면 근본 원인을 더 잘 식별하고이 오류를 수정하는 방법을 알 수 있습니다.

@bacongobbler 나는 이것이 행동인지 100 % 확인하기 위해 이것을 다시 방문해야 할 것입니다. 이 댓글을 업데이트하거나 내가 있으면 다른 글을 게시하겠습니다.

관리자가 권장하지 않을 수도 있다는 것을 알고 있지만 아무것도없는 것보다 낫습니다.

또한 명확히하기 위해 나는 그늘을 던지려고하지 않는다! 지금 뒤돌아 보면 조금 엉뚱한 말이네요 미안 해요

나는 왜 내 조타가 처음으로 실패했는지에 대해 아직도 혼란스러워한다.
두 번째로 적용하려고 할 때까지 no X with the name Y 오류가 발생하지 않았습니다.

@veqryn 위에서 링크 한 문제에서이 문제가 처음에 어떻게 나타나는지에 대해 썼습니다. 댓글을 읽어주세요. 불분명 한 경우 문제를 더 자세히 설명하도록 기꺼이 도와 드리겠습니다.

게으른 사용자 : https://github.com/helm/helm/pull/4223#issuecomment -397413568

나는 실제로 그것을 읽었으며 서비스 이름을 변경했기 때문에 문제가 발생했다는 것을 이해했습니다.

그러나 어떤 시점에서도 내 서비스 나 리소스의 이름이 변경되지 않았습니다.

그리고 귀하의 의견을 다시 읽고 승무원과 이야기 한 후 오류의 원인을 파악했습니다.
나는 내 helm Chart의 버전을 부딪쳤다.
이 차트 버전은 내 배포 및 서비스에서 레이블로 참조되었습니다.
Kube / helm은 레이블이 변경 될 때 그것을 좋아하지 않으며 이것이 원래 오류의 원인입니다.

나에게 해결책은 helm을 사용하여 마지막으로 성공한 배포로 되 돌린 다음 차트 버전 변경을 되돌려 차트 버전이 동일하게 유지되어 성공했습니다.

이 (추악한) 수정이 나를 위해 작동합니다.

1. 오류가 발생합니다.

helm upgrade az-test-2-prom ./prometheus --namespace monitor --set cluster_name="az-test-2" -f values.yaml
Error: UPGRADE FAILED: no ConfigMap with the name "az-test-2-prom-prometheus-grafana-config" found

1. 마지막 배포 된 수정본 찾기

export TEMPLATE='{{range .items}}{{.metadata.name}}{{"\t"}}{{.metadata.labels.STATUS}}{{"\n"}}{{end}}'
kubectl -nkube-system get cm -l 'OWNER=TILLER' -ogo-template="$TEMPLATE"

az-test-2-prom.v1   SUPERSEDED
az-test-2-prom.v10  SUPERSEDED
az-test-2-prom.v11  SUPERSEDED
az-test-2-prom.v12  SUPERSEDED
az-test-2-prom.v13  SUPERSEDED
az-test-2-prom.v14  SUPERSEDED
az-test-2-prom.v15  SUPERSEDED
az-test-2-prom.v16  SUPERSEDED
az-test-2-prom.v17  DEPLOYED
az-test-2-prom.v18  FAILED
az-test-2-prom.v19  FAILED
az-test-2-prom.v2   SUPERSEDED
az-test-2-prom.v20  FAILED
az-test-2-prom.v21  FAILED
az-test-2-prom.v22  FAILED
az-test-2-prom.v23  FAILED
az-test-2-prom.v24  FAILED
az-test-2-prom.v25  FAILED
az-test-2-prom.v26  FAILED
az-test-2-prom.v27  FAILED
az-test-2-prom.v28  FAILED
az-test-2-prom.v29  FAILED
az-test-2-prom.v3   SUPERSEDED
az-test-2-prom.v30  FAILED
az-test-2-prom.v4   SUPERSEDED
az-test-2-prom.v5   FAILED
az-test-2-prom.v6   SUPERSEDED
az-test-2-prom.v7   SUPERSEDED
az-test-2-prom.v8   SUPERSEDED
az-test-2-prom.v9   FAILED



md5-b918cb6c3ed3b232fefddaf5da41f0e1



for ii in {17..30}
> do
>   kubectl -nkube-system delete cm az-test-2-prom.v${ii}
> done



md5-be6e03beb82adf195ed45c22b159a8de



kubectl -nkube-system patch cm az-test-2-prom.v16 -p '{"metadata": {"labels": {"STATUS": "DEPLOYED"}}}'

** 4. (중요) 마지막 배포 (v16) 이후에 추가 된 기존 새 리소스를 모두 찾아 삭제합니다 (예 :
kubectl -nmonitor delete cm az-test-2-prom-prometheus-grafana-config
kubectl -nmonitor delect svc ...

helm upgrade ... 하고 Happy Helming보기

@ kosta709가 말했듯이, 마지막으로 배포 된 릴리스로

Helm은 명령 결과가 안정적이지 않은 경우 일부 자동 워크 플로 (CI / CD)에서 버릴 수있는 훌륭한 소프트웨어입니다.

이 잘 알려진 (그리고 약간 성가신) 문제를 해결하기 위해 알려진 솔루션이 결국 실행될 수있는 옵션이 있습니까? 감사.

그래서 최근에는이 문제에 대해 스스로 작업 할 수있을만큼 자주이 문제를 해결했습니다. 우선, 해결 방법을 만들었습니다 (
https://github.com/Nopik/helm/commit/afe6451cc2c6295e71ea2213ccce654ec3f5b686) 기본적으로 Tiller가 이전 매니페스트에서 가져온 리소스 대신 기존 리소스를 시작점으로 가져옵니다. 하드 코딩 된 동작이 포함되어 있기 때문에 핵심 개발자가 병합을 원하지 않을 것이라고 생각하지만 나에게는 매력처럼 작동합니다.

이 버그가 나를 물었을 때 적어도 한 번은 이미 20 개 이상의 성공적인 릴리스 버전에 존재했던 리소스를 포함하여 많은 (> 40) 리소스를 삭제해야했기 때문에 동일한 동작 아래에 두 개의 버그가 숨겨져있을 수 있습니다. 그러나 99 %의 경우 새로 생성 된 (그러나 helm에 알려지지 않은) 리소스 만 삭제하면됩니다.

그래서 나는 그것을 올바른 방법으로 해결하는 방법에 대해 생각했습니다. 나는 그것을 아래에 설명하고있다. 핵심 개발자는 여기에서 나를 수정하고 나와 동의하면 무게를 측정 해주세요. 그렇다면 나는이 노력을 이끌고 PR을 제공하여 문제를 해결할 것입니다.

일반적으로 helm은 '패치'모드에서 작동하는 것 같습니다. 사용자가 어떻게 든 리소스를 수정하고 새 릴리스 버전이 다른 매개 변수를 변경하면 helm은 2 개 개정 사이에 패치를 계산하여 적용합니다. 사용자 변경 사항을 그대로 유지하려고합니다.

슬프게도 이전 매니페스트에서 가져온 리소스 버전, 새 매니페스트에서 다른 버전, 현재 살아있는 리소스에서 다른 버전을 가져 왔기 때문에 3 방향 병합 문제가 발생합니다. 그리고 helm은 갈등이 발생할 때 해결하는 데 분명히 좋지 않습니다.

적절한 방법은 더 나은 기본값을 선택하거나 (기본적으로 내 브랜치를 병합하면 먼 길을) 사용자에게 플래그를 제공하는 것입니다. 예 :

• --ignore-old-manifest=never (기본값, 현재 동작)
• --ignore-old-manifest=create-only (이 경우에 적용, 이전 매니페스트에 리소스 개념이 없지만 리소스가 이미 존재하는 경우,이를 새 기반으로 사용하고 필요한 경우 패치 만 적용 할 수 있음)-새 항목으로 권장합니다. 기본. 그러면 helm이 수동으로 생성 된 리소스의 소유권을 가져 오기 시작할 수도 있습니다.
• --ignore-old-manifest=always -완전성을 위해, 아마도 꼭 필요한 것은 아닙니다. 항상 현재 리소스와 최신 매니페스트 사이에 패치를 생성하여 기본적으로 모든 사용자 수정 사항을 제거합니다.

물론 반전 된 논리를 사용하도록 플래그 이름을 바꿀 수 있습니다 : --use-current-resources=never(currently default)/create-only/always 또는 이와 유사한 것.

나중에이 플래그는 다음과 같은 리소스 주석에서 가져올 수 있습니다.

annotations:
  helm.io/ignore-old-manifest: always

리소스별로이 전략을 인식하고 적용 할 수있는 관리자 그래도 helm devs가 거기에 가고 싶은지 확실하지 않습니다.)

그래서이 제안에 대해 어떻게 생각하십니까?

Helm 개발자가 3 방향 병합 패치를 고려중인 문제 # 3805도 참조하십시오.

여기에도 같은 문제가 있습니다.
Google 클라우드 빌드로 CD / CI 환경을 설정하려고합니다.
Error: UPGRADE FAILED: no Deployment with the name "baobab-sidekiq" found

재미있는 점은 배포가 존재한다는 것입니다.

kc get deployments
NAME             DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
baobab           3         3         3            2           2d
baobab-ermis     1         1         1            1           23h
baobab-sidekiq   1         1         1            1           23h

이것이 제가 만든 첫 번째 차트이며 helm 가 CI / CD 환경에서 복잡한 응용 프로그램을 배포하는 복잡성을 처리하는 솔루션이 될 것으로 기대했습니다.

helm의 의도가 CI / CD 파이프 라인에서 작업 할 수 있도록하는 것입니까?

감사

Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

helm 0.8.0을 helm 1.0.0으로 업그레이드하려고 시도하고 있습니다.

helm version --tls Client: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"} Server: &version.Version{SemVer:"v2.9.1", GitCommit:"20adb27c7c5868466912eebdf6664e7390ebe710", GitTreeState:"clean"}

차트의 요구 사항을 업그레이드 할 때도이 문제가 발생했습니다. Istio도이 버그에 부딪 히고 설치 문서 는 helm template 합니다. 이 문제에 대한 해결 방법입니까?

https://github.com/helm/helm/issues/3805 에서 최근 토론을 확인

이것도 가지고 있지만 최신 helm 2.10에서 여전히 발생합니다.

이 문제를 심각하게 고려할 때입니다. 이제 2 년이 지났고 많은 사람들이 똑같은 문제를보고합니다.이 문제는 프로덕션에서 helm을 사용할 수 없게 만들고 배포가 helm에 의존 할 때 큰 고통입니다.

많은 GitHub 스타와 함께 큰 책임이 따릅니다.

@ brendan-rius이 문제를 해결하거나 아이디어를 생각하기 위해 코드를 제공 할 수 있습니다. 일부 포인터는 # 3805 및 # 4146을 참조하십시오.

특히 @ brendan-rius, # 3805에는이 버그를 둘러싼 최신 토론이 있습니다. 나는 우리가 반대하는 것에 대한 아이디어를 얻기 위해 그 스레드에 읽기를 적극 제안합니다.

3 방향 병합 전략보다이 문제와 더 관련이 있기 때문에 여기에 내 의견을 다시 게시합니다.

Helm 2.yz의 새 배포에 3 방향 병합이 불가능한 경우 # 1193은 언제 수정 되나요? 이 버그는 Helm 2.0에 대한 명확한 해결 계획없이 거의 2 년 동안 열려 있습니다.

이 시점에서 우리는 어떻게 진행해야할지 고민하고 있습니다. 우리는 몇 주 동안 버그에 대해 논의했으며 제안 된 솔루션 중 어떤 것도 새로운 버그를 도입하거나 틸러의 업그레이드 동작을 크게 변경함으로써 모든 경우에 작동하지 않을 것입니다.

예를 들어, @michelleN 과 저는 이번 주 초에 브레인 스토밍을했고 두 가지 가능한 해결책을 생각했는데 둘 다 특히 환상적이지 않았습니다.

1. 업그레이드가 실패하면이 릴리스 중에 생성 된 리소스를 자동으로 롤백하고 삭제합니다.

업그레이드 실패 후 클러스터가 알 수없는 상태에있을 수 있으므로 Helm이 깨끗한 방식으로 진행할 수 없어 잠재적으로 애플리케이션 다운 타임이 발생할 수 있으므로 이는 매우 위험 합니다.

1. 업그레이드하는 동안 새 리소스를 생성하고 이미 존재하는 것으로 확인되면 해당 변경 사항을 기존 리소스에 적용하거나 삭제 / 다시 생성합니다.

Helm이 다른 패키지 또는 kubectl create 통해 설치된 객체를 삭제할 수 있으므로 이는 매우 위험 합니다.

지금까지 가장 안전한 옵션은 충돌이 발생하는 경우 사용자에게 수동으로 개입하도록 요청하는 것이 었는데, 아래에서 설명하겠습니다.

누군가 제안 / 피드백 / 대안 제안이있는 경우 귀하의 의견을 듣고 싶습니다.

@bacongobbler , 3 방향 병합 기능에 대한 지원이 계획되지 않은 경우 대안 또는 해결 방법이 필요합니다. 그렇지 않으면 # 1193은 심각하게 고통스러운 보커입니다.

문제와 해결 방법을 다시 반복하려면 :

새 리소스를 설치하는 업그레이드가 실패하면 릴리스가 FAILED 상태가되고 업그레이드 프로세스가 중지됩니다. 다음에 helm upgrade 를 호출하면 Helm은 마지막 배포 된 릴리스와 비교를 수행합니다. 마지막 DEPLOYED 릴리스에서는이 개체가 존재하지 않았으므로 새 리소스를 만들려고하지만 이미 존재하기 때문에 실패합니다. @arturictus가 지적했듯이 오류 메시지는 완전히 오해의 소지가 있습니다.

오류가 "찾을 수 없음"으로보고하는 리소스를 수동으로 개입하고 삭제하여 쉽게 해결할 수 있습니다. https://github.com/helm/helm/pull/4223#issuecomment -397413568에서 시연 한 예제에 따라 :

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
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

즉, FAILED 릴리스 중에 생성 된 리소스를 삭제하면 문제가 해결됩니다.

@bacongobbler 먼저, 지난 몇 주 동안이 문제를 자세히 살펴 보셔서 감사합니다. 문제를 일으키는 Istio 0.8.0에서 Istio 1.0.0 업그레이드로의 문제가 정확히 무엇인지 또는 문제 설명과 완전히 일치

Helm에 대한 이전 경험이 많은 Istio 운영자 커뮤니티와 대화하면서 일부 운영자는 Helm의 관리되지 않는 리소스가 나쁜 소식이며 종종 업그레이드 실패로 이어진다 고 말했습니다. Istio 차트 구현에 Helm 2.yz 업그레이드와 호환되지 않는 결함이있는 경우 이러한 비 호환성을 수정하는 것이 좋을 것입니다. 따라서 향후 업그레이드 실패가 발생하지 않습니다.

우리는 0.8.0에서 1.0.0 업그레이드로 1 회 적중 할 의향이 있습니다. 업그레이드가 지속적으로 결함이있는 경우-그것은 다른 문제입니다.

Istio에서 bisect를 실행했습니다. 업그레이드가 7 월 27 일 (Istio 1.0.0 릴리스 3 일 전)까지 작동했기 때문에이 커밋이 문제가 있음을 발견했습니다 : https://github.com/istio/istio/commit/301612af08128b15069d27ff6d03cdb87420e15b

이 PR은 기본적으로 설치 후 작업에서 개체 등록을 제거했습니다. 확실하지는 않지만 Istio 1.0.0에 이르는 3 일 동안 설치 후 작업의 모든 인스턴스를 제거했습니다.

업그레이드와 관련된 Istio의 특정 Helm 차트에 대한 조언을 제공 할 수 있습니까? 설치 후 작업에서 개체 등록을 유지하면 업그레이드 문제가 영구적으로 해결됩니까?

Helm에 대한 최근 경험을 가진 사람들이 일반화 된 솔루션을 찾을 수 없었기 때문에 (문제를 살펴 보지 않았기 때문에)이 문제를 해결하기위한 강력한 조언이나 제안을 실제로 제공 할 수 없습니다. 더 잘할 수있을 것 같지 않습니다.

건배
-스티브

오류를 더 잘 반영하도록 제목을 업데이트했습니다.

우리는 또한이 문제의 영향을받습니다. GKE 10.6에서 최신 Helm 2.10을 사용합니다.
언제 수정 될 것으로 예상 할 수 있습니까?
문제에 대한 합리적인 해결 방법이 있습니까? --purge 옵션으로 전체 배포를 제거하는 것은 매우 좋지 않습니다.

저의 마지막 댓글에 부담없이 들려주세요. 여기서 가장 잘 진행하는 방법에 대한 피드백이 정말 필요합니다.

이 스레드에서 해결 방법이 여러 번 반복되었습니다. https://github.com/helm/helm/issues/1193#issuecomment -419555433을

이 문제를 해결하기위한 helm 자동 롤백 기능 ( 옵션 1 )이 마음에 듭니다. 마지막 DEPLOYED Helm 릴리스가 작동 중이고 클러스터가 양호한 상태이므로 안전하게 되돌릴 수 있음을 알고 있습니다. 일부 사용 사례에서 위험한 경우 플래그를 통해 helm 업그레이드를 선택할 수 있습니다.

업그레이드 실패 후 클러스터가 알 수없는 상태에있을 수 있으므로 Helm이 깨끗한 방식으로 진행할 수 없어 잠재적으로 애플리케이션 다운 타임이 발생할 수 있으므로 이는 매우 위험합니다.

많은 helm 사용자가 CD 또는 CM 도구를 통해 자동화 된 방식으로 helm을 사용하고 있으며 helm 릴리스를 FAILED 상태로 두는 것이 더 위험하다고 생각합니다. 실패한 릴리스의 이러한 불완전한 리소스는 다른 리소스에 예기치 않게 영향을 미치고 자체적으로 다운 타임을 유발할 수 있습니다. 예를 들어 포드 사양에 누락 된 이미지 버전이 포함되어 어떤 식 으로든 프로덕션으로 전환 된 경우 워크로드는 작동하지 않는 ImagePullBackOff 상태가됩니다. 우리 회사의 경우 UI를 통해 스스로 업그레이드 할 수있는 온 프레미스 고객이 있고 실패 할 경우 디버깅을 위해 시스템에 액세스해야하기 때문에 더 나쁩니다.

이 문제를 해결할 수 있다는 사실을 무시하더라도 자동 롤백은 유용한 기능이 될 것이며 Helm 릴리스가 본질적으로 더 많은 트랜잭션이되도록하는 데 도움이 될 것입니다. Helm은 최선의 배포에서 안정성과 성공적인 배포의 우선 순위를 지정하는 데 사용됩니다.

@bacongobbler 는 새로운 배포에 다음 접근 방식을 사용할 수 있습니다.

• 플래그 추가- -three-way-merge
• 해당 플래그가 helm install (새 배포)에서만 사용되도록 허용
• 이 플래그가 활성화되면 업그레이드는 항상 3 방향 병합을 사용합니다.
• 기존 배포는 마이그레이션 경로없이 멈출 수 있습니다.이 시점에서 사람들이 사용하는 표준 해결 방법은 helm delete --purge 뒤에 helm reinstall 붙는 것이므로 처음 나타나는 것처럼 만족스럽지 않을 수 있습니다.

이것이 실제로 문제를 해결할까요?

일부 개인은이 Helm 제한을 해결하기 위해 운영자 구현을 고려하고 있습니다. 그것은 심각한 수치입니다. https://github.com/istio/istio/issues/8841#issue -361871147 참조

건배
-스티브

@bacongobbler 의 이전 댓글로

1. 업그레이드하는 동안 새 리소스를 생성하고 이미 존재하는 것으로 확인되면 해당 변경 사항을 기존 리소스에 적용하거나 삭제 / 다시 생성합니다.
   Helm은 사용자가 원하지 않는 다른 패키지 또는 kubectl create를 통해 설치된 객체를 삭제할 수 있으므로 매우 위험합니다.

새로운 행동을 옵트 인 (opt-in)하여이 위험을 완화 할 수 있는지 궁금합니다. 주어진 네임 스페이스 내에서 저는 일반적으로 helm을 독점적으로 사용하며 이것이 많은 경우에 해당한다고 생각합니다. Helm 설치 / 업그레이드에 기존 릴리스의 일부가 아닌 지정된 네임 스페이스의 모든 항목을 삭제 / 덮어 쓰는 것이 좋다는 플래그를 지정할 수 있다면 도움이 될까요?

"다른 패키지를 통해"라고 말씀 하셨기 때문에 Helm이 릴리스 수행의 일부로 다른 릴리스를 조사하지 않아도되므로 제 제안은 네임 스페이스 당 단일 릴리스 모델을 제외하고는 작동하지 않을 것입니다. 이 반대에 대해 대답하려면 다음과 같이 말합니다. 네임 스페이스에서 여러 패키지를 관리하고이 동작을 계속 얻으려면 원하는 차트 종속성을 지정하는 것이 유일한 목적인 우산 형 차트를 만듭니다. 그런 다음 해당 우산 차트를 배포 할 때 새 플래그 ( "--exclusive"?)를 사용합니다.

분명히 이것이 모든 사용 사례의 문제를 해결하지는 않지만 아마도 충분한 해결 방법 일 것입니다.

@bacongobbler 나는 여기에서 멀리 떨어져있을 수 있습니다. 업그레이드에서 비슷한 문제에 직면하고 있습니다. 이 문제를 해결하는 것이 얼마나 어려운지 판단 해보면 좀 더 근본적인 것을 재고 할 필요가 있는지 궁금합니다. 복잡성의 일부는 Helm이 kubernetes 인 실제 소스와는 별도로 알려진 구성의 자체 버전을 유지하기 때문인 것으로 보입니다. Helm이 기록 및 롤백 목적으로 이전에 배포 된 helm 차트의 복사본 만 보관하고 업그레이드 중에 전혀 사용하지 않은 경우 시스템이 더 안정적일까요? 대신 Helm은 kubectl 자체에서 진실을 얻은 다음 항상 수행 할 2-way diff가 있습니까?

helm 차트에 리소스 X가 있어야한다고 표시되고 kubectl에 기존 리소스 X가 표시되는 경우 :

• 기존 리소스가 Helm에 의해 제어되는 것으로 태그가 지정된 경우 Helm은 필요한 업그레이드를 수행합니다.
• 기존 리소스가 Helm에 의해 제어되는 것으로 태그가 지정 되지 않은 경우 Helm이 실패하고 깨끗한 오류 메시지가 표시됩니다 (또는 일부 명령 줄 플래그를 사용하여 업그레이드를 강제하고 Helm이 기존 리소스 X의 소유권을 갖도록 할 수 있음).

helm 차트에 리소스 X가 있어야한다고 말하고 kubectl에 따른 리소스가없는 경우 Helm이 생성합니다.

kubectl이이 helm 차트에 의해 제어되는 것으로 태그 지정된 리소스 Y가 있고이 helm 차트에 리소스 Y가 없다고보고하는 경우 helm은 리소스를 삭제합니다.

이 helm 차트에 의해 제어되는 것으로 태그가 지정되지 않은 모든 리소스는 업그레이드를 수행 할 때 항상 helm에 의해 무시됩니다. 단, helm 차트에 리소스 X가 필요하다고 표시되고 X가 존재하지만 태그가 지정되지 않은 위에서 언급 한 경우는 예외입니다.

어떤 이유로 helm 차트의 롤아웃이 발생하고 실패하고 리소스의 절반 만 롤아웃 된 경우 롤백 중에 Helm은 이전에 성공한 배포의 저장된 구성 파일을 사용하고 정확히 동일한 알고리즘을 실행합니다. 일부 helm 명령 줄 플래그와 관련하여 손상된 상태로 남을 수 있습니다. 사용자가 다시 업그레이드를 시도하는 경우 kubernetes가 마지막으로 알려진 성공적인 배포가 아닌 진실의 소스로 사용되기 때문에 여전히 새 helm 차트와 시스템의 기존 상태 간의 단순한 양방향 차이 여야합니다.

우리도이 문제를보고 있습니다. 재현 단계 :

1. helm install 배포를 성공적으로 설치 한 차트
2. 기존 배포 외에 사용자 지정 리소스를 포함하도록 차트 업데이트
3. 배포 실패를 모방하도록 배포 podspec의 이미지 변경
4. helm install 새 차트. 이로 인해 우리가 의도적으로 실패하도록 설정 한 배포의 롤링 업데이트가 발생합니다.
5. Helm 설치가 실패해야합니다. 그러나 사용자 지정 리소스는 k8s etcd에 남아 있어야합니다. ( kubectl 사용하여 확인)
6. (이 시점에서 투구는 불량 상태입니다)
7. 차트 수정-배포 podspec에 goot 이미지를 넣습니다.
8. helm install 우리는 이것이 작동 할 것으로 기대하지만 그렇지 않습니다. "이름이 ___ 인 자원 없음"을보고합니다. 이름은 사용자 지정 리소스의 이름입니다.
9. 복구 : kubectl 사용하여 잔여 사용자 지정 리소스를 삭제합니다. 이제 helm install 가 작동합니다.

차트에 새로 도입 된 사용자 지정 리소스로 helm install 에 대한 첫 번째 시도는이 상태가되지 않아야합니다.

@ rbair23 우리는 이전에 시도했지만 작동하지 않았습니다. kubectl apply를 수정하고 로직을 클라이언트에서 서버로 이동하여 선언적 객체 관리 상태 를

# 3275가 그것의 중복으로 닫 혔기 때문에 : 우리는 # 3275와 비슷한 상황이 있습니다.

이미 실행중인 작업 my-long-running-job 있습니다. 릴리스를 업그레이드하려는 경우 :

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: no Job with the name "my-long-running-job" found

작업이 존재합니다.

>kubectl -n=my-environment get jobs
NAME                                DESIRED   SUCCESSFUL   AGE
my-long-running-job                 1         0            16m

해당 작업 삭제 :

>kubectl -n=my-environment delete job my-long-running-job
job.batch "my-long-running-job" deleted

이러한 장애를 해결합니다.

>helm upgrade --install my-release --namespace my-environment my-chart --timeout 60
Error: UPGRADE FAILED: timed out waiting for the condition

최소한 no Job with the name "my-long-running-job" found 메시지는 오해의 소지가 있지만 작업도 업데이트 될 것으로 예상했습니다.

v2.9.1 (현재 출시 된 안정 버전)에서 여전히이 내용이 표시됩니다.

업그레이드를 취소하는 것이 "매우 위험"하다는 데 동의하지 않습니다. 그렇게하는 것이 올바른 해결책이라고 생각합니다.

Kubernetes는 선언적입니다. 업그레이드를 시도하기 전의 클러스터 상태를 스냅 샷합니다.
도중에 오류가 발생하면 스냅 샷으로 롤백하십시오.
이 작업을 수행 할 때 클러스터를 잘못된 상태로 남겨 둘 스크립트 후크가있는 사람은 자신의 잘못입니다. (아마도 롤백 후크로 해결할 수 있습니다)

물론 업그레이드가 사전에 진행되고 가능한 한 많이 파일을 제출하지 않았다면 좋을 것입니다.
값 또는 --set 인수로 생성 된 종속성 차트의 오류는 예를 들어 변경을 시도하기 전에 확인할 수 있어야합니다. 버전 번호를 올리는 것을 잊는 것과 같은 것도 작동하지 않을 때 변경하지 않도록 미리 실행될 수 있습니다.

안녕하세요,

다음과 같은 문제가있었습니다.

클라이언트 : v2.10.0 + g9ad53aa
서버 : v2.10.0 + g9ad53aa

Helm이 릴리스를 업그레이드하는 유일한 방법은 serviceAccount, configMap 및 서비스를 삭제하는 것입니다.

안녕하세요,

버전 2.11.0에서 @dilumr가 설명한 것과 동일한 문제가 있습니다.

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Error: UPGRADE FAILED: no ConfigMap with the name "xxx" found

v2.9.1에서 이것을 실행했습니다.

내가 실행하고 있던 차트 업그레이드는 많은 변경 사항이있는 개인 차트에서 몇 가지 주요 버전을 뛰어 넘고 있었기 때문에 정확히 무엇이 오류를 유발했는지 확실하지 않지만 배포가 원래 FAILED 상태로 끝난 이유는 확실하지 않습니다. 나는 --wait 플래그를 가지고 있었고 시간이 초과되었습니다.

helm list 중복 된 FAILED 배포가 여러 개 있었지만 마지막으로 작업 한 배포는 DEPLOYED 입니다. 새 배포를 만들면 No resource with the name x found .

실행하여 해결할 수 있던 helm rollback 에 있던 마지막 버전에 DEPLOYED 에 상태 helm list . 업그레이드 후 오류없이 실행할 수있었습니다.

https://github.com/helm/helm/pull/4871을 확인

다른 사람과 마찬가지로이 오류는 마지막 배포가 실패하고 해당 배포의 새 자산이 설치된 상태로 남아있을 때 가장 자주 발생하는 것 같습니다 (항상 잘 모르겠습니다).

실패한 Helm 배포에서 구성 요소를 제거하는 것이 얼마나 까다 롭거나 바람직하지 않은지 이해합니다. 그러나 이러한 상황에 이상적인 Helm 동작은 무엇입니까?

첫째, Helm이 네임 스페이스 및 기타 리소스를 (재) 설치하려는 경우 이미 존재하는 경우 괜찮을 것이라고 생각합니다. Kubernetes는 "구성을 올바르게 만들고 kube가 세상을 구성과 일치시키는 방법을 알아 내도록합니다."
둘째, Helm은 전부 아니면 전무해야한다고 생각합니다. 배포가 실패하면 클러스터는 배포가 시작되기 전의 상태 여야합니다.
둘 다 네임 스페이스 X를 생성하려는 릴리스가 두 개 있으면 참조 계산 문제가 있습니다. 네임 스페이스 X를 만들려는 릴리스가 있지만 이미 존재하는 경우 출처 문제가 있습니다. 그러나 helm은 개체에 대한 주석을 사용하여이를 기록하고 올바른 작업을 수행 할 수 있습니다.

최신 helm 2.12.0 및 kubernetes 1.10.11에서도이 문제를 겪고 있습니다. @aguilarm이 제안한대로 최신 버전으로

나는 매우 유사한 환경을 가진 2 개의 클러스터를 가지고 있으며, 2 개는 총 노드 수인 2 개 사이에 주된 차이가 있습니다. 한 경우에는 helm delete --purge 다음에 새로운 helm install 작동했지만 다른 경우에는 작동하지 않았으며이를 최신 템플릿 변경 사항에 적용하는 방법을 아직 알아 내지 못했습니다.

이것에 대한 ETA가 있습니까?

helm rollback 로이 문제를 해결하고 가장 최근 개정판 (실패한 개정판)을 지정했습니다.

오늘도 같은 문제가 있었는데
Error: UPGRADE FAILED: no Service with the name "xxx-api" found
kubectl get svc -n stage | grep xxx-api
xxx-api ClusterIP 172.20.149.229 <none> 8300/TCP 19h
helm rollback 일했습니다.

우리는 헬름 업그레이드를하는 동안 꽤 정기적으로 이것을 경험하고 있습니다. 이것은 단지 실패한 것이 아니라 성공적인 배포 후에 발생합니다. 1) 사용할 수없고 2) 처음부터 완전히 복구하는 데 너무 오래 걸리는 사소한 구성 요소가 포함 된 프로덕션 시스템이므로 delete --purge를 실행할 수 없습니다.

위에 게시 한 진단 및 해결 방법을 참조하십시오. 그것이 당신에게 효과가 있는지 알려주십시오.

@bacongobbler 응답

@ajcann에 +1하고
나는 똑같은 상황에 있습니다.
CICD는 자동화되어 있으며 낮은 환경을 위해 슬랙 봇이 배포하는 경우가 많습니다.
실패하면 수동으로 helm 롤백을 수행하고 다시 배포해야합니다.
이 문제는 전혀 일관성이 없지만 자주 발생합니다.
저에게는 지금까지 차트 / 리소스를 두 번째 배포하는 동안에 만 발생합니다.
자원은 항상 존재합니다.

우리는 같은 문제를 관찰합니다. 다음 중 하나의 템플릿이있는 경우 발생합니다.

• {{if $condition -}} 문
• 또는 {{ range $index, $value := $array-}}

@jkroepke 는 PR # 5143이 이에 대한 좋은 해결 방법을 제공한다고 나에게 지적했습니다. --atomic 플래그가 다음 부 버전에서 릴리스되면 오류가있을 때이를 사용하여 자동으로 제거하거나 롤백 할 수 있습니다.

@bacongobbler 당신이 이것에 대한 대부분의 앞뒤로 관련되어 --atomic 플래그로 충분합니까?

@distorhead 가 https://github.com/helm/helm/pull/4871 에서 제기 한 우려 사항도 해결되는지 살펴보고 싶을 수도 있습니다 --atomic 플래그를 사용 한다고 가정 하면 --atomic 문제를 해결할 수 있습니다.

이 특정 주에 들어갔을 때 문제를 해결하기 위해 제안 된 해결책이 없다고 생각하지만 제가 틀릴 수 있습니다. 이 문제에 대한 완화 전략이

• 클러스터의 라이브 상태를 수동으로 살펴 보고 해결 방법에 따라 수정합니다.
• Helm 2.13.0으로 업그레이드하고 앞으로 helm upgrade --atomic

그러면 닫아도 안전하다고 생각합니다.

Helm 2.13.0이 그리 멀지 않았 으면합니다.
이 버그는 릴리스에서 오류가 발생한 경우 CI를 중단합니다.

Atomic은 문제를 해결하지 못합니다.

예제 차트 : https://github.com/distorhead/ex-helm-upgrade-failure

1. 마스터를 확인하고 배포를 실행하십시오.

git clone https://github.com/distorhead/ex-helm-upgrade-failure
cd ex-helm-upgrade-failure
helm upgrade --atomic --install --namespace myns myrelease .

차트에는 myserver1 및 myserver2 두 가지 배포가 포함됩니다.

Release "myrelease" does not exist. Installing it now.
NAME:   myrelease
LAST DEPLOYED: Tue Feb  5 23:48:57 2019
NAMESPACE: myns
STATUS: DEPLOYED

RESOURCES:
==> v1beta1/Deployment
NAME       READY  UP-TO-DATE  AVAILABLE  AGE
myserver1  1/1    1           1          5s
myserver2  1/1    1           1          5s

1. 브레이킹 체인지. 차트에서 myserver1 배포를 삭제하고 사용자 오류로 myserver2 배포를 수정합니다 (예 : 이미지 필드 삭제).

git checkout break-atomic
git diff master

diff --git a/templates/deploy.yaml b/templates/deploy.yaml
index 198516e..64be153 100644
--- a/templates/deploy.yaml
+++ b/templates/deploy.yaml
@@ -1,21 +1,5 @@
 apiVersion: apps/v1beta1
 kind: Deployment
-metadata:
-  name: myserver1
-spec:
-  replicas: 1
-  template:
-    metadata:
-      labels:
-        service: myserver1
-    spec:
-      containers:
-      - name: main
-        command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04
----
-apiVersion: apps/v1beta1
-kind: Deployment
 metadata:
   name: myserver2
 spec:
@@ -28,4 +12,3 @@ spec:
       containers:
       - name: main
         command: ["/bin/bash", "-c", "while true ; do date ; sleep 1 ; done"]
-        image: ubuntu:16.04

1. 배포 실행 :

git checkout break-atomic
helm upgrade --atomic --install --namespace myns myrelease .

친구에게 다시 인사하십시오.

UPGRADE FAILED
ROLLING BACK
Error: Deployment.apps "myserver2" is invalid: spec.template.spec.containers[0].image: Required value
Error: no Deployment with the name "myserver1" found

트윗 담아 가기

@distorhead 이 시나리오에서 예상했던 동작은 무엇입니까?

롤백에 대해서는 약간 어색하지만 어쨌든.

롤백을 사용하고 싶지만 몇 가지 이유로 --atomic 에서와 같이 배포 직후 롤백이 발생하는 것을 원하지 않는 사람들을 위해. 예를 들어 사용자가 실패 후 잘못된 클러스터 상태를 수동으로 검사 할 수있는 방법이없고 --wait 플래그로 인해 helm이 배포중인 리소스의 실패에 대한 정보를 기록하지 않기 때문입니다. 그런 다음 몇 가지 방법이 있습니다. 업그레이드 전 다음 실행시 롤백 (추가 정보 https://github.com/helm/helm/issues/3149#issuecomment-462271103)

문제와 해결 방법을 다시 반복하려면 :

새 리소스를 설치하는 업그레이드가 실패하면 릴리스가 FAILED 상태가되고 업그레이드 프로세스가 중지됩니다. 다음에 helm upgrade 를 호출하면 Helm은 마지막 배포 된 릴리스와 비교를 수행합니다. 마지막 DEPLOYED 릴리스에서는이 개체가 존재하지 않았으므로 새 리소스를 만들려고하지만 이미 존재하기 때문에 실패합니다. @arturictus가 지적했듯이 오류 메시지는 완전히 오해의 소지가 있습니다.

오류가 "찾을 수 없음"으로보고하는 리소스를 수동으로 개입하고 삭제하여 쉽게 해결할 수 있습니다. # 4223 (주석) 에서 시연 한 예에 따라 :

><> helm fetch --untar https://github.com/helm/helm/files/2103643/foo-0.1.0.tar.gz
><> helm install ./foo/
...
><> vim foo/templates/service.yaml                    # change the service name from "foo" to "foo-bar"
><> kubectl create -f foo/templates/service.yaml      # create the service
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

즉, FAILED 릴리스 중에 생성 된 리소스를 삭제하면 문제가 해결됩니다.

이 해결 방법을 @bacongobbler에 모아 주셔서 감사합니다. 본질적으로 프로세스 로서도 마찬가지입니다. 여기에서 한 가지 고통스러운 문제는 복잡한 업그레이드 중에 많은 새로운 리소스 (때로는 몇 가지 종속성 수준이 깊음)가이 상태에있을 수 있다는 것입니다. 모든 관련 리소스에 대한 "검색"업그레이드를 반복적으로 실패해야하는 상황으로 이어지는 자동 방식으로 이러한 상태를 완전히 열거하는 방법을 아직 찾지 못했습니다. 예를 들어 최근에 새로 추가 된 종속성 자체가 postgresql 차트에 대한 종속성을 가졌습니다. 이 문제를 해결하려면 비밀, 구성 맵, 서비스, 배포 및 PVC를 삭제해야했습니다. 각각은 먼 길을 찾았습니다.

마지막 릴리스에서 생성 된 템플릿을 열거하는 helm diff 와 유사한 플러그인을 작성할 수 있습니다. Helm에서 직접 pkg/kube 소비 할 수도 있습니다. client.Update 에는 Tiller에서 두 릴리스를 가져오고 비교 순서를 반대로하여 재사용 할 수있는 helm의 리소스 추적 / 삭제 를 위해 작성된 일부 비즈니스 로직이 있습니다. target.Difference(original) 는 이전 릴리스 이후에 도입 된 모든 리소스의 결과를 제공합니다.

@bacongobbler 릴리스 A의 일부로 배포 된 애플리케이션 (예 : 여러 애플리케이션으로 구성된 더 큰 릴리스)을 다운 타임없이 릴리스 A에서 자체 릴리스로 분리 (또는 그 반대)하는 데 권장하는 솔루션은 무엇입니까? (리소스를 삭제하는 해결 방법으로 인해 다운 타임이 발생할 수 있습니다.) ... 다른 릴리스를 통해 리소스를 업데이트하려고하면이 Github 문제에 설명 된 오류가 발생합니다.

이 새 차트가 설치된 것처럼 들리며 성공적으로 배포되기 전에 이전 차트를 대체합니다. 실패한 업그레이드 --install과 동일합니다. 차트가 잘못되면 설치하지 않았습니다.
오류시 이전 상태로 롤백하거나 성공시 경운기 차트를 업데이트하십시오.

이것은 내가이 문제를 복구하기 위해 사용하는 프로세스입니다 (지금까지는 아무런 사고없이 매번 작동했지만 어쨌든 조심하십시오).

1. helm list 하고 영향을받는 차트의 최신 버전을 찾습니다.

   NAME        REVISION UPDATED                  STATUS  CHART              NAMESPACE
   fetlife-web 381      Thu Mar 15 19:46:00 2018 FAILED  fetlife-web-0.1.0  default
   

2. 거기에서 DEPLOYED 상태의 최신 버전을 찾으십시오.
   kubectl -n kube-system edit cm fetlife-web.v381 kubectl -n kube-system edit cm fetlife-web.v380 kubectl -n kube-system edit cm fetlife-web.v379 kubectl -n kube-system edit cm fetlife-web.v378
3. 마지막 배포 된 개정판을 찾으면 상태를 DEPLOYED 에서 SUPERSEDED 하고 파일을 저장합니다.
4. helm upgrade 다시 시도하십시오. 성공하면 완료입니다!
5. 다음과 같은 업그레이드 오류가 발생하는 경우 :
   Error: UPGRADE FAILED: "fetlife-web" has no deployed releases
   마지막 버전의 상태를 FAILED 에서 DEPLOYED
kubectl -n kube-system edit cm fetlife-web.v381
6. helm upgrade 다시 시도하십시오. 다시 실패하면 테이블을 뒤집습니다 ...

트윗 담아 가기
이 문제에 대한 오류 메시지를 개선하기 어렵게 만드는 것이 있습니까?

나는 오류 메시지에 "자원이 helm에 의해 생성되지 않았고 수동 개입이 필요하기 때문에 충돌이 있습니다"라고 표시되어야하며 "찾을 수 없음"이 아니라고 생각합니다. 오류에 대한이 작은 변화 만이 사용자 경험을 개선 할 수 있습니다.

@selslack 오류 메시지를 개선하는 데 매우 유리합니다 👍

@michelleN 오류 텍스트를 변경하기 위해 PR을 준비했습니다 : # 5460.

이 문제가 발생하여 해결 방법을 잘 모르겠습니다.

@reneklacan에 나열된 모든 단계를 여기에서 https://github.com/helm/helm/issues/1193#issuecomment -470208910

불행히도 작동하지 않았습니다. 문제를 해결하는 유일한 방법은 오류 메시지를 생성하는 리소스를 삭제 한 다음 helm upgrade 다시 삭제하는 것입니다.

그러나 다음 helm 업그레이드는 동일한 오류와 함께 실패하고 리소스를 다시 삭제하고 다시 업그레이드해야합니다. 이것은 지속 가능하거나 좋지 않습니다.

CI 프로세스의 일부로 helm을 사용하여 배포하는 두 가지 환경 인 QA와 프로덕션 환경이 있습니다.

QA 환경에서 동일한 문제가 발생하여 helm delete --purge 를 사용한 다음 helm upgrade -문제를 영구적으로 해결했습니다.

그러나 프로덕션 환경에서는이 작업을 수행 할 수 없습니다. 그냥 지우고 다시 업그레이드 할 수 없기 때문에 현재는 각 배포 전에 리소스를 삭제하고 있습니다. 나는 그것이 수입 자원이 아니기 때문에 운이 좋다.

@zacharyw 현재 어떤 오류가 발생합니까? No resource with the name ... 또는 "fetlife-web" has no deployed releases ?

이 문제를 디버깅하는 데 도움이되는 추가 정보를 공유 할 수 있습니까?

kubectl -n kube-system describe cm -l NAME=YOUR_RELEASE_NAME | grep -A1 STATUS= 출력 ( YOUR_RELEASE_NAME 대체)

관련이없는 데이터 (rene (at) klacan (dot) sk)로이 문제를 스팸하고 싶지 않다면 더 많은 정보가 담긴 이메일을 보내주세요.

가능한 진단 및 해결 방법은 https://github.com/helm/helm/issues/1193#issuecomment -419555433, @zacharyw를 참조

@reneklacan no resource with the name ... 오류입니다. 우리의 경우에는 인 그레스를 추가했지만 작동하는 것처럼 보였지만 인 그레스가 이미 존재하더라도이 오류와 함께 후속 업그레이드가 실패하기 시작했습니다.

가장 최근 릴리스의 상태 (문제를 일으키는 수신을 삭제하고 helm 업그레이드를 다시 생성하도록 허용 한 후)는 DEPLOYED .

STATUS=DEPLOYED
VERSION=197

그러나 다시 업그레이드를 시도하면 실패합니다.

@bacongobbler 내가 오해하지 않는 한 이미 해당 주석에서 해결 방법을 수행하고 있다고 생각합니다. 리소스를 삭제하고 다시 만들 수 있습니다. 문제는 매번이 작업을 수행해야한다는 것입니다.

에 @reneklacan https://github.com/helm/helm/issues/1193#issuecomment -470208910 내 생명을 구 했어요.

Helm이 이런 식으로 실패한 것은 실망입니다. 거의 모든 환경에서 항목을 삭제하는 것은 이상적이지 않습니다.

이런 종류의 오류가 나타날 때 helm이 자체 데이터베이스를 업데이트 한 다음 다시 시도하면 좋을 것입니다.

--cleanup-on-fail 플래그를 활성화하면이 오류 케이스가 사라져야한다고 생각합니다. # 4871 및 # 5143을 통해 해결 된대로 종료됩니다.

해당 플래그없이 추가 문제가 발생하면 새 문제를 다시여십시오. 감사!

helm 릴리스 또는 실행중인 배포를 삭제하지 않고 문제를 처리하는 방법에 대한 의견을 추가하려고하여 문제가 종결되었습니다.

그래서 다음 단계로 문제를 재현했습니다.

1. 서비스 템플릿을 사용하여 test-chart-failure 차트를 설치합니다.
2. 서비스 포트에 문자열 (예 : "test")이있는 서비스 템플릿이있는 하위 차트를 추가합니다.
3. 차트를 업그레이드하십시오. Service in version "v1" cannot be handled as a Service: v1.Service.Spec: v1.ServiceSpec.Ports: []v1.ServicePort: v1.ServicePort.Port: readUint32: unexpected character: ... 오류와 함께 실패합니다.

http://centosquestions.com/helm-how-to-delete-bad-deployment 에서 제안을 적용하여 helm delete 를 실행하지 않고 포트를 번호로 수정 한 후 업그레이드 할 수있었습니다.

1. helm history test-chart-failure 실패한 개정판을 찾았습니다.
2. kubectl delete cm -n kube-system test-chart-failure.v2 특정 개정의 구성 맵을 삭제했습니다.
3. 수정 된 차트로 helm upgrade 실행