Helm: `helm upgrade --install`은 첫 번째 설치가 실패하면 설치 / 업그레이드를 수행하지 않습니다.

이것은 https://github.com/kubernetes/helm/pull/3097의 디자인에 의해 의도 된 것입니다

• https://github.com/kubernetes/helm/issues/2257
• https://github.com/kubernetes/helm/issues/2341
• https://github.com/kubernetes/helm/issues/2346
• https://github.com/kubernetes/helm/issues/2437
• https://github.com/kubernetes/helm/issues/3068

초기 릴리스가 실패한 상태가되면 helm delete --purge foo 를 통해 릴리스를 제거하고 다시 시도하는 것이 좋습니다. 성공적인 초기 릴리스 후에는 이후의 실패한 릴리스는 무시되고 helm은 마지막으로 알려진 성공한 릴리스와 비교를 수행합니다.

이제 성공적인 릴리스가 배포되지 않은 경우 diff를 수행 하지 않는 것이 중요 할 수 있습니다. 사용자가 helm install 를 처음 실행했을 때와 비교할 수있는 "현재"릴리스가 없다는 점에서 경험은 동일합니다. 그래도 특정 엣지 케이스에 대해 약간 걱정할 것입니다. @adamreese 이것에 대한 의견이 있습니까?

제안 된 수정 사항은 자동화 된 시스템에서 완전히 유지할 수없는 것 같습니다. helm을 호출하는 모든 것이 "첫 번째 릴리스가 실패하면 삭제하고 다시 시도"에 대해 알아야하는 것은 아닙니다. 첫째, 내 도구의 대부분은 설치인지 업그레이드인지 인식하지 못하거나 처음인지 100 번인지 거의 항상 helm upgrade --install 입니다.

나는 또한이 사건에 대해 구체적으로 묻는 원본 PR https://github.com/kubernetes/helm/pull/3097#discussion_r151808599 에 대해 언급했다고 말하고 싶습니다.

이 경우에는 이전 동작이 더 낫습니다.
@chancez에 동의합니다. 이것은 일반적인 경우에 upgrade --install 비멱 등성을 만듭니다.

뿡 빵뀨
릴리스가 실패하고 실패한 후크로 인해 파편을 남기는 것이 걱정된다면 차트의 디자인 문제라고 말하고 싶습니다. (후크는 멱등적일 때 더 잘 작동합니다.)
사용자는 helm을 중심으로 오류 처리 및 비멱 등성 동작을 자유롭게 구축 할 수 있습니다.

우리가 염려하는 다른 엣지 케이스는 무엇입니까?
# 3097이 많은 것을 처리하는 것 같습니다 👍

적어도 몇 가지 인수 조합에 대해 실패한 릴리스에 대해서도 helm upgrade -i 멱 등성을 만들 수 있다면 내 로컬 개발이 훨씬 더 원활해질 것입니다. 내 사용 사례는 로컬 개발 환경을 시작하기 위해 시작하려는 많은 릴리스의 스크립트가있는 경우입니다.

이는 helm install 에 대한 --replace 플래그와 유사 할 수 있습니다. --replace 는 helm upgrade 에서 누락 된 helm install 두 플래그 중 하나이고 다른 하나는 --name-template 입니다.

명확하게 말하자면, 이것은 고치는 것이 좋습니다. 우리 손이 다른 일로 가득 차있는 동안 누군가 그것에 균열을 갖고 싶어?

안녕하세요,
이 문제를 해결해야하는 PR https://github.com/kubernetes/helm/pull/3437 을 만들었습니다.

우리가 필요로하는 이유는 확실하지 않다 install 및 upgrade 명령을, 난 단지 이제까지 사용 upgrade --install 명령을하고 있습니다 많은 사람들이 같은처럼 보인다. upgrade --install 를 수행하고 실패한 실행으로 넘어 가지 않는 명령 하나만 필요합니다. 우리가 이름을 바꿀 수 있습니다 upgrade --install 에 deploy , 그것은 진정 나무 등 확인하고 다른 두 도랑?

(저는 2.8.0에서이 문제 동작을 새로운 변종으로 고심하고 있습니다. 2.7.2에서 업그레이드 한 이후 설치가 실패하면 delete --purge , 그리고 upgrade --install it , 여전히 Error: UPGRADE FAILED: "xyz" has no deployed releases 오류가 발생할 수 있습니다. --purge 은 (는) 2.8.0에서 완전히 효과적이지 않고 틸러에는 list --all 표시되지 않는 일부 멈춤 상태가있는 것 같습니다. 그런 다음 install 로 돌아가서 경운기를 다시 평소에 upgrade --install 할 수있는 주로 되돌립니다.)

@whereisaaron에 동의합니다. kubectl apply 처럼 작동하는 deploy 명령을 사용하면 좋을 것입니다. 일부 쉘 스크립트 광기에 존재하는 릴리스를 확인할 필요가 없기 때문에 Helm의 자동화도 훨씬 쉬워집니다. :)

아마도 해결책은 helm이 자동으로 helm delete --purge 실행하도록하는 것입니다.
다음과 같은 것 :
1) 사용자가 helm upgrade --install
2) 첫 번째 릴리스 실패
3) 사용자가 차트를 변경하고 다시 실행 helm upgrade --install
4) Helm이 명령 실행을 시도합니다.
5) 실패하고 실패한 상태의 이전 릴리스가 정확히 하나 있습니다.
6) Helm이 자동으로 helm delete --purge
6) 제거 후 Helm은 helm upgrade --install 자동으로 재 시도하고 그 결과를 표시합니다.

아마도이 동작은 다른 시나리오에 대해 이미 유사한 동작이있는 --force 플래그를 통해 트리거 될 수 있습니다.

좋은 생각,하지만 난 우리가 이제까지 사용자가 명시 적으로 해당 데이터를 제거 요청하지 않고 릴리스 원장을 삭제해야합니다 생각하지 않습니다. Helm 운영자는 이전에 실패한 릴리스에서 서비스를 업그레이드하지 못한 이유를 알아 보거나 원장에서 해당 데이터를 수집하여 실패를 추론하려고합니다.

스레드의 앞부분에서 문제에 대한 해결책을 설명하는

@rchernobelskiy도 나에게 발생합니다. 당신이 설명하는 그대로.

새 앱을 배포 할 때 하루에 한 번이 문제가 발생합니다.
고통입니다!

@gmanolache 이런 이유로 우리는 여전히 2.7.0을 지배하고 있습니다.
--force 플래그를 사용하여 업그레이드하는 것이 안전한지 확실하지 않습니다 .

다운 그레이드해야하는 경우 다음과 같은 좋은 방법이 있습니다. 2.7.0으로 다운 그레이드

이 유용하게 들리는 '조임 장부'진단 정보는 무엇이며 어떻게 얻을 수 있습니까? :미소:

아래 내용이 변덕스러워 보일까 걱정됩니다. 배포에 실패했을 때 진단 정보를 얻을 수있는 방법에 대한 안내에 대한 안내입니다. 뭔가 놓친 것 같아서요. 실패한 상태가 운영자에게 유용하다고 생각되는 것 같습니까? 나는 다시 조타 매뉴얼 사이트를 탐색했다. 유용한 진단 정보를 추출하기 위해 실패한 상태에서 'helm get manifest'와 같은 것이 작동합니까?

배포가 실패했을 때 내 사용자 경험은 유용한 정보가 없다는 것입니다. Helm은 'helm status'가 아무것도 표시하지 않도록 부분적으로 생성 / 남은 리소스를 모두 소유하지 않습니다. 할 수있는 일은 '롤백'또는 '삭제 --purge'입니다 ( '삭제'만 할 수 없거나 CI '업그레이드-설치'가 계속 실패합니다). 실패한 상태는 우리 모두가 CI 배포에 열망하는 '업그레이드-설치'의 멱 등성을 깨는 역할을하는 것 같습니다.

CI 상황에 대해 '--auto-rollback'옵션을 갖는 것이 합리적일까요 (예 : 'upgrade --install --auto-rollback'). 나는 보통 실패한 상태를 다루기 위해 침대에서 일어나야하는 롤백을 선호한다 😆 😴 💤

이 유용하게 들리는 '조임 장부'진단 정보는 무엇이며 어떻게 얻을 수 있습니까? 😄

helm help history

감사합니다 @bacongobbler. 좋아, 나는 목록이 원장의 의미임을 이해합니다. 원장이 아직 있다면 helm get manifest --revision 123 를 사용하여 배포 된 것이 실패한 것을 볼 수 있습니까? 그것은 확실히 보존하는데 유용합니다. 그리고 우리가 rollback 이라면 그 정보를 잃지 않습니다.

History prints historical revisions for a given release.

A default maximum of 256 revisions will be returned. Setting '--max'
configures the maximum length of the revision list returned.

The historical release set is printed as a formatted table, e.g:

    $ helm history angry-bird --max=4
    REVISION   UPDATED                      STATUS           CHART        DESCRIPTION
    1           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Initial install
    2           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Upgraded successfully
    3           Mon Oct 3 10:15:13 2016     SUPERSEDED      alpine-0.1.0  Rolled back to 2
    4           Mon Oct 3 10:15:13 2016     DEPLOYED        alpine-0.1.0  Upgraded successfully

helm upgrade --install --auto-rollback 있는 경우 실패한 배포 모두 롤백이 원장에 기록되고 운영자가 사용할 수 있습니다. 그리고 그것은 CI 배포가 'helm upgrade --install'이 작동을 중지하는 다루기 힘든 '실패'상태가되는 것을 방지하는 데 큰 도움이됩니다. 실패한 CI 배포는 일반적으로 개발자가 배포 시스템에 오타 / 실수를 주입하는 것입니다. '--auto-rollback'을 사용하면 배포 서버 로그에 보관 된 helm 명령 오류 메시지를 검사하고 수정 된 값을 수정하고 배포 할 수 있습니다.

'--auto-rollback'옵션이 없어도 wrapper automate를 사용하여 helm update --install 가 'FAILED'오류를 반환 할 때마다 helm rollback 를 실행할 수 있습니다. 그리고 초기 설치 위치를 감지하고 그 경우에는 helm delete --purge 대신 사용할 수 있습니다.

즉, CI 'helm upgrade --install'의 결과가 항상 다음 CI 'helm upgrade --install'이 항상 가능한 상태가되도록 래퍼 스크립트를 만들 수 있습니다. 실패한 시도에 대한 원장 정보를 유지하는 동안 (적어도 초기 설치가 작동 한 릴리스의 경우).

helm deploy =

• helm upgrade --install
• 실패하면
  
  
  
  • 개정 = 1 인 경우
  
  
  • 그 다음 helm delete --purge
  
  
  • 그 외 helm rollback
  
  

@whereisaaron 우아 할 것입니다 👍

같은 이외의 최신 작업 버전 얻을 수있는 쉬운 방법이 helm history ${name} | tail -2 | head -1 | awk '{print $1}' 에 의해 사용되는, helm rollback ?

안녕하십니까,

Helm 2.12.2를 사용하고 있으며 첫 번째 배포가 실패하면 helm이 실패한다는 문제가 여전히 있습니다. 이것은 아마도 회귀입니까?

회귀인지 확실하지 않지만 실제로 "고정"되지는 않았습니다.

@ RickS-C137 실패한 릴리스를 '삭제'한 다음 '설치-교체'하는 helm upgrade --install --force 를 사용하여이 문제를 해결해야한다고 생각합니다.

여전히 사용하려는 Jenkins Pipeline에서이 문제를 해결하려고합니다.
내 애플리케이션의 새 이미지를 배포하려고하는데 배포가 이미 존재하는지 여부에 상관없이 신경 쓸 수 없습니다.
현재 배포를 대체하거나 존재하지 않는 경우 설치하는 명령 하나를 실행하고 싶습니다.
나는 helm install --replace 시도했다. 나는 종종 Error: a released named xyz is in use, cannot re-use a name that is still in use 얻는다. 이것은 분명히 내 파이프 라인을 죽이고 빌드가 실패한다.

@bacongobbler https://github.com/helm/helm/issues/3353#issuecomment -385222233에 대해 어떻게 생각하십니까?

초기 릴리스가 실패 할 경우 초기 릴리스를 파괴하고 다시 생성하면 다운 타임이나 데이터 손실이 어떻게 발생하는지 알 수 없습니다.

우리 빌드에서 이것을 구현했습니다.

if helm history --max 1 "$name" 2>/dev/null | grep FAILED | cut -f1 | grep -q 1; then
    helm delete --purge "$name"
fi

helm upgrade --install --wait "$release" chart/

현재 helm을 사용하면 현재 상태를 검사하지 않고 사용할 helm 명령 + 옵션 조합을 알 수 없습니다. 그리고 주어진 helm 명령의 경우 현재 상태에 따라 달라지기 때문에 무엇을 얻을지 알 수 없습니다. 그것은 선언적 희망 상태의 꿈이 아닙니다 ☁️ 💤 😄

helm 3에서는 잠재적으로 install / upgrade / --replace / --upgrade / --force 멱 등성 helm deploy 대체 할 수 있습니다 helm deploy . 위와 유사한 알고리즘을 사용할 수 있습니다. helm deploy 가 실패하면 롤백 (revision> 1)하거나 deletes + purges (revision = 1)하여 상태를 이전 상태로 유지합니다. 실패한 매니페스트는 helm history/get 를 통해 계속 사용할 수 있습니다. 조사를 위해 배포를 실패한 상태로 보존하려는 사람들을위한 '-롤백 없음'옵션도있을 수 있습니다.

helm upgrade --install --force 의 옵션이 점점 가까워지고 있습니다. 단, 롤백 및 업그레이드가 아니라 실패한 릴리스 (수정 버전> 1의 경우에도)를

지금 당장은 기능 목록 이 부분적으로 helm 하지만이 문제를 완화하는 helmsman 와 같은 래퍼 스크립트 또는 메타 도구를 사용할 수 있습니다.

• 멱 등성 : 원하는 상태 파일이 변경되지 않는 한 Helmsman을 여러 번 실행하여 동일한 결과를 얻을 수 있습니다. _ [... 현재 상태에 관계없이] _
• 실패에서 계속 : 특정 차트 배포 실패로 인한 부분 배포의 경우 먼저 부분 성공을 롤백 할 필요없이 helm 차트를 수정하고 Helmsman을 다시 실행합니다.

원하는 상태를 달성하거나 상태를 변경하지 않은 상태로 두는 멱 등성 helm 배포로 모두 교체합니다.

돌이켜 보면 이것은 놀랍도록 분명한 디자인 목표입니다.

안녕하세요,
우리의 경우 초기 릴리스는 실제로 실패하지 않았습니다. 설치 시간 초과가 경과했을 때 응용 프로그램이 완전히 작동하지 않았거나 수정 된 다른 이상한 문제 때문입니다. 어쨌든 응용 프로그램은 완벽하게 실행되고 있으므로 삭제해야하는 것은 우리에게 문제가 될 것입니다 (또한 제거 될 일부 영구 저장소가 연결되어 있습니다 !!).

초기 릴리스가 '명백하게 실패'했지만 실제로는 괜찮은 경우 차트를 배포하는 해결 방법이 있습니까?

그렇다면 upgrade --force 이 너무 강력하다는 결론이 나옵니다. 즉, delete + replace + retry_upgrade가 업그레이드 실패에 대한 올바른 해결책이 아닐 때가 있습니다.

install & upgrade 를 deploy 명령으로 병합하는 아이디어를 추적하는 별도의 문제가 있습니까?

내가 @dcow에 대해 아는 것은 아닙니다. helm upgrade --install 명령에 대한 사용 사례는 무엇입니까?

https://github.com/helm/helm/issues/3353#issuecomment -362497951

설치 및 업그레이드 명령이 필요한 이유를 잘 모르겠습니다. 저는 upgrade --install 명령 만 사용하며 많은 사람들이 동일한 작업을 수행하는 것 같습니다. 업그레이드 --install을 수행하고 실패한 실행으로 넘어 가지 않는 명령 하나만 필요합니다. upgrade --install의 이름을 변경하여 배포하고 진정으로 멱 등성을 유지하고 나머지 두 개는 버릴 수 있습니까?
...

과

https://github.com/helm/helm/issues/3353#issuecomment -469109854

현재 helm을 사용하면 현재 상태를 검사하지 않고 사용할 helm 명령 + 옵션 조합을 알 수 없습니다. 그리고 주어진 helm 명령의 경우 현재 상태에 따라 달라지기 때문에 무엇을 얻을지 알 수 없습니다. 그건 정말 선언적 희망 상태가 아니야 꿈 구름 zzz smile

helm 3에서는 잠재적으로 설치 / 업그레이드 / --replace / --upgrade / --force를 사용하지 않고 원하는 상태를 달성하거나 상태를 변경하지 않는 멱 등성 helm 배포로 모두 대체 할 수 있습니다.
...

나는 일반적으로 helm이 kubectl apply 처럼 작동해야한다는 데 동의하고 클러스터 상태에 따라 다른 유형의 명령을 실행하는 대신 원하는 현실을 달성하려고합니다. 존재하는 경우 전용 문제에 대한 지원을 추가하거나 적어도 deploy 이 현재 구현되지 않았고 우리는 3.2를 운영하고 있기 때문에 해결 방법이 무엇인지 파악하려고했습니다.

@dcow 좋아, 당신은 당신의 제안에 문제를 만들고 싶습니까?

@hickeyma 완료 https://github.com/helm/helm/issues/8415!