Helm을 사용하여 Kubernetes 리소스를 관리하기 시작했으며 kubectl edit. 우리는 Helm이 실행될 때마다 배포된 리소스를 정리하여 알려진 양호한 상태로 되돌리길 원합니다.
helm upgrade내 ConfigMap을 덮어쓰지 않는 것을 확인했습니다 . 대신 배포된 ConfigMap과 Helm 템플릿 간의 속성을 병합하여 템플릿 기반 ConfigMap의 일부와 직접 편집한 ConfigMap의 일부를 제공합니다. Helm ConfigMap 템플릿에 변경 사항이 없으면 Helm은 다음을 수행합니다.~ 아니다배포된 ConfigMap의 일부를 알려진 양호한 상태로 다시 재설정합니다.
전체 Kubernetes 리소스를 항상 Helm 템플릿 버전으로 재설정하도록 Helm에 지시하려면 어떻게 해야 하나요?
답변1
이것은 Helm의 디자인 목표가 아니며 앞으로도 그럴 것입니다. Helm에서 생성되지 않은 객체를 조작하거나 Helm의 "통제" 하에 있는 객체에 대한 대역 외 변경 사항을 무시하는 것은 Helm의 권한에 속하지 않습니다. 이는 Helm이 매니페스트를 변경할 수 있는 다른 시스템과 호환되도록 하는 기능입니다. Helm을 안전하게 사용할 수 있게 해줍니다. Puppet이나 SaltStack과 같은 구성 관리 시스템이 아니라 YAML 렌더링 시스템이라는 점을 기억하세요. 구성을 "강제"하지 않습니다.
설명하는 동작을 수행하려면 Helm을 사용하여 객체를 다시 생성하기 전에 문제의 객체를 삭제할 수 있습니다. 잠재적으로 Kubernetes 네임스페이스를 사용하여 각 차트에 고유한 네임스페이스를 제공하고 차트 설치 전에 "하드 리셋"의 형태로 네임스페이스를 삭제하여 이를 안정적으로 수행할 수 있습니다.
또는 매니페스트 편집에 익숙한 사용자가 kubectl그렇게 하지 못하도록 하고 대신 해당 변경 사항을 차트나 값으로 푸시하도록 지시합니다. 변경 사항이 필요한 경우 변경 사항을 삭제하는 것은 합리적이지 않은 것 같습니다. 이것이 바로 Helm이 처음에 매니페스트에서 3방향 병합 작업을 수행하는 이유입니다. 단일 오케스트레이션 지점에서 구성을 유지하려는 욕구는 이해하지만 단일 오케스트레이션 지점을 사용하지 않고 이를 달성할 수 있을 것으로 기대하지는 않습니다.
이 문제는 낮은 수준의 오케스트레이션 방법에 익숙한 팀에 더 높은 수준의 오케스트레이션 방식을 적용할 때 지속적으로 발생하며 개념적으로 Helm에 국한되지 않습니다. Helm은 병합 작업을 수행하여 상황을 우아하게 처리하는 데 능숙하지만 오케스트레이션 방법론의 작동이 엉망이 됩니다(적어도 문제가 발생하거나 단순히 실패하지는 않습니다). 혼란을 일으키지 않거나 혼란을 스크래치 환경으로 제한하고 생산을 위해 Helm 차트에 퍼내는 것부터 시작하십시오.