Quiz: Three-Way Merge and Carrying Over Values

차트가 replicas: 1 을 선언하고 있습니다. kubectl scale 로 5 로 올린 뒤 차트를 하나도 바꾸지 않고 helm upgrade 하면?

• 5 가 유지된다 — 옛 매니페스트와 새 매니페스트가 같아 패치가 나가지 않는다
• 업그레이드가 충돌을 감지해 실패한다
• 1 로 되돌아간다 — 차트가 선언한 필드는 클러스터 실물과 달라도 선언 쪽으로 맞춘다
• 5 와 1 의 평균인 3 이 된다

같은 상황에서 kubectl label 로 붙인 owner=ops 라벨은 업그레이드 뒤 어떻게 되나요?

• 그대로 남는다 — 어느 매니페스트에도 없는 필드라 패치 대상이 아니다
• 지워진다 — 차트가 metadata.labels 를 선언하고 있으므로 통째로 대체된다
• 지워진다 — 릴리스가 소유하지 않은 필드는 정리 대상이다
• 경고가 나면서 업그레이드가 중단된다

helm upgrade api ./api --set replicas=4 --set logLevel=debug 다음에 helm upgrade api ./api --set replicas=6 을 돌렸습니다. logLevel 은?

• debug 가 유지된다 — 사용자 값은 릴리스에 누적된다
• 차트 기본값으로 돌아간다 — 업그레이드는 이번에 준 값으로 다시 계산한다
• 빈 값이 된다 — 이전 값이 null 로 덮어써진다
• 오류가 난다 — 이전에 준 값을 빠뜨리면 업그레이드가 거절된다

--reuse-values 와 --reset-then-reuse-values 의 차이가 드러나는 상황은?

• 사용자가 이번에 --set 을 하나도 주지 않았을 때
• 릴리스가 실패 상태로 남아 있을 때
• 이전 릴리스에 사용자 값이 하나도 없을 때
• 차트를 올리면서 차트 기본값이 함께 바뀌었을 때

오토스케일러(HPA)가 복제 수를 관리하는 워크로드의 차트를 만들 때 권장되는 방식은?

• 차트에 replicas 를 선언하고 배포마다 현재 값을 --set 으로 맞춰 준다
• 차트에서 replicas 를 선언하지 않고 HPA 에 맡긴다
• 차트에 replicas 를 선언하되 업그레이드마다 --force 를 붙인다
• 차트에 replicas 를 선언하고 업그레이드 전에 HPA 를 잠시 지운다

helm upgrade --force 에 대한 설명으로 옳은 것은?

• 값 이어받기를 강제해 지난번 사용자 값을 모두 유지한다
• 실패한 리비전을 건너뛰고 마지막 성공 리비전 위에 적용한다
• 패치 대신 오브젝트를 교체하므로 해당 오브젝트가 사라졌다 다시 만들어진다
• API 서버 검증을 건너뛰어 스키마가 맞지 않아도 적용한다