작성한 질문수 23

0

1. CPU는 사용률이 적은 시점엔 꼭 두 배가 필요한 건 아니지만 Memory의 경우 현재 사용률과는 별개로 App에서 점유하고 있는 부분이 있기 때문에 대체로 교체시 두배가 사용됩니다. 그리고 Blue Green 배포시 새 Pod가 먼저 생긴 후에 기존 Pod가 죽기 때문에 여유 자원이 꼭 필요하고요.

2. 배포시 Green Pod가 성공적으로 생성 되어야, 기존 Blue Pod가 삭제 됩니다. Green Pod에 에러가 생기면 기존 Blue Pod는 계속 서비스 중인 상태로 남아 있어요. rolling도 마찬가지고요. 그리고 만약 yaml 파일에 문법 오류가 있는 상태에서 배포를 하면 에러기 때문에 업그레이드가 시작되지 않고요. 실습 한번 해보시면 더 쉽게 이해가 될 거예요.

    

0

안녕하세요, 인프런 AI 인턴입니다. 소니소니님께서 Blue-Green 배포 및 애플리케이션 기동 중 발생하는 문제들에 대해 질문을 주셨습니다. 이와 관련하여 유사한 내용이 담긴 링크와 함께 몇 가지 참고할만한 자료를 제공해드리겠습니다.

1. Blue-Green 배포에서의 리소스 사용 문제:

   • Blue-Green 배포의 주요 단점 중 하나는 리소스 사용이 증가할 수 있다는 점입니다. 일반적으로, 두 가지 버전의 어플리케이션이 동시에 실행되기 때문에 전체적으로 CPU와 메모리 사용량이 커질 수 있습니다. 특히, 새로운 버전을 실행하기 전까지 두 버전을 유지해야 하기 때문에 메모리의 사용이 증가합니다.
     
   • 이 문제는 리소스 관리가 중요한 이유 중 하나입니다. 워커 노드에는 항상 여유분의 리소스를 준비해야 하기 때문입니다. 이에 대한 자세한 논의는 블루그린 배포시엔 다플로이먼트를 이용하지 않는 이유 를 참고하시면 도움이 될 것입니다.
     

2. 애플리케이션 기동 중 문제:

   • 새로운 버전에 문제가 발생할 경우, Blue-Green 배포에서는 Green 버전의 pod가 완전히 정상적으로 기동되지 않았다면 트래픽을 전환하지 않는 방식을 사용하게 됩니다. Kubernetes에서는 헬스체크(Health Check)를 사용하여 Pod의 상태를 감시할 수 있으며, 헬스체크를 통과하지 못할 경우 업데이트를 보류할 수 있습니다.
     
   • 따라서, Blue-Green이나 Rolling 배포 전략에서는 Pod의 헬스체크를 확인하도록 설정하는 것이 중요합니다. 이러한 설정은 주로 readinessProbe와 livenessProbe 설정을 통해 가능합니다.
     

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.