• 카테고리

    질문 & 답변
  • 세부 분야

    데브옵스 · 인프라

  • 해결 여부

    미해결

--record 옵션을 대체하는 옵션이 있나요?

22.04.29 09:22 작성 조회수 974

1

kubectl 명령어의   --record 옵션이 deprecated 된다고 나오는데요,

변경 이력(history)을 기록하고 rivision을 확인할 수 있는 방법이 있을까요?
 
찾아보는데 잘 안보이네요.
 
kubectl rollout history deployment deploy-roll
 
다만, 모든 deployment rollout history는 기본적으로 저장된다는데 --record 옵션을 넣지 않아도 history가 저장되는 것이 맞나요?
(제가 테스트를 해봐도 되겠네요.)
 
[업데이트]
--record 옵션없이 하면 CHANGE-CAUSE 가 모두 <none>으로 나오네요.

deployment.apps/deploy-rollout REVISION CHANGE-CAUSE 1 <none> 2 <none> 3 <none>

Rolling Back a Deployment
Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping. By default, all of the Deployment's rollout history is kept in the system so that you can rollback anytime you want (you can change that by modifying revision history limit).
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/

 
 
 
 
 

답변 2

·

답변을 작성해보세요.

3

안녕하세요 

해당 부분을 좀 정확하게 정해지면 정리하려고 생각했던 부분이긴 합니다. 

우선 답변부터 드릴께요. 

 

1. 자동 저장 

> 네 됩니다. 얘기하신 결과와 동일한 형태로요. 

[root@m-k8s ~]# kubectl rollout history deployment/nginx-deployment

deployment.apps/nginx-deployment 

REVISION  CHANGE-CAUSE

1         <none>

2         <none>

3         <none>

 

2. CHANGE-CAUGE가 None으로 나오는 이유 

--record를 쓰지 않는 경우 다음과 같은 방식으로 CHANGE-CAUSE를 표시합니다. 

CHANGE-CAUSE is copied from the Deployment annotation kubernetes.io/change-cause to its revisions upon creation. You can specify theCHANGE-CAUSE message by:

  • Annotating the Deployment with kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"

즉 annotation으로 기입해서 관리하라는거죠...

어쨌든 주석이기 때문에 revision을 통해서 예전 버전으로 복귀가 가능합니다. 

 

3. --record 관련 

현재 문서에는 deprected 표시도 사라졌네요...완전히 빼는거 기정 사실화 한거 같네요. 

이 부분이 계속 물음표에 가까웠던 것은 이 이슈때문인데요. (https://github.com/kubernetes/kubernetes/issues/40422)

 

여기 내용을 읽어보시면

1 ) 대안을 달라파가 대세이나...

 2) 일부에서 꼭 있어야 하는건 아니다..그냥 표시만 해주는거잖나 라는 파도 있습니다. 

그렇지만, deprecated는 결정되었고 annotation으로 진행하는 것으로 결론 난 것으로 보여집니다. 

(issue가 closed 되고 ...확실히 명령어가 사라지면 그때 한번 강의로 정리할 계획이긴 합니다.)

 

해당 진행이 Merge된 부분이 아래와 같이 확인됩니다. https://github.com/kubernetes/kubernetes/pull/102873

따라서 annotation이 다소 불편함이 있긴 하지만... 필요시에 사용하고 평소에는 잘 만든 내용으로 잘 배포하고 관리하는게 좋을 것 같습니다. 틀린게 있다면 사실 바로 확인 가능하니까요. 

저도 굳이 꼭 있어야 하나? 라는 생각이 있습니다. 

배포 후에 자동 확인되도록 스크립트를 짜서 CI/CD 돌리는 게 맞는거 같아서요. 

다만 강의에는 가능한 유용한 기능들을 소개하고 각자 스타일에 맞게 사용해야 하기 때문에 다루었습니다. 

실제로는 실무에서 history를 사용하는 경우는 거의 없습니다. 

 

여러가지로 많이 살펴 보시고 고민하시는 것이 쿠버네티스 학습에 매우 큰 도움이 되실꺼고, 많은 것을 얻으실 수 있으실꺼 같네요. :) 

감사합니다. 

조훈 드림. 

 

 

2

+로 위의 같은 내용들을 자유롭게 토론하고 의사를 개진해서 (또는 직접 개발하고 PR) 변경하는 방식으로 쿠버네티스는 발전되어 갑니다. 

쏭쏭님의 프로필

쏭쏭

질문자

2022.05.06

@조훈(Hoon Jo)

rollout 할 이미지에  --annotation 으로 annotation을 추가하여 rolloout을 하면  history에 annotation 정보가 보이는 내용 확인했습니다.

강사님 적극적으로 의견 개진하시면서 k8s 변화에 적극 동참하고 계시네요

 

확인 감사합니다.