Kubernetes 미드레벨 배포·운영 기술면접
새 면접Q. Kubernetes에서 애플리케이션 배포 시 PreStop Hook과 terminationGracePeriodSeconds를 함께 사용하는 이유를 설명해주세요. 특히 Service의 Endpoint 업데이트 타이밍과 Pod 종료 타이밍 사이의 레이스 컨디션 문제를 어떻게 해결할 수 있나요?
Pod가 종료 신호를 받았을 때 kube-proxy와 엔드포인트 컨트롤러가 즉시 동기화되지 않는 상황을 생각해보세요.
Pod 종료 시 SIGTERM 신호와 Endpoint 제거가 동시에 발생하지만, kube-proxy가 iptables 규칙을 업데이트하는데 지연이 있어 이미 종료 중인 Pod로 트래픽이 전달될 수 있습니다. PreStop Hook에서 sleep 5-10초를 주어 Endpoint 제거가 전파될 시간을 확보하고, terminationGracePeriodSeconds를 충분히 설정하여 진행 중인 요청이 완료될 시간을 보장합니다. 또한 애플리케이션이 SIGTERM을 받으면 새 요청 수락을 중단하고 기존 연결만 처리하도록 구현해야 합니다. 이를 통해 무중단 배포 시 502/503 에러 없이 안전하게 트래픽을 전환할 수 있습니다.
- • Pod 종료와 Endpoint 제거 사이의 레이스 컨디션 이해
- • PreStop Hook에서 sleep을 통한 전파 시간 확보
- • terminationGracePeriodSeconds로 graceful shutdown 시간 보장
- • 애플리케이션 레벨에서의 graceful shutdown 구현 필요성
고가용성이 요구되는 프로덕션 환경에서 배포 시 502 에러 없이 안전하게 트래픽을 전환할 때 사용됩니다.
애플리케이션이 30초 이상 걸리는 장시간 작업을 처리 중일 때는 어떻게 무중단 배포를 구현할 수 있을까요?
Q. Kubernetes 클러스터에서 GitOps 방식으로 ArgoCD를 사용하여 배포 자동화를 구축했습니다. 개발팀이 Git에 푸시하면 Jenkins가 이미지를 빌드하고 레지스트리에 푸시한 후, 매니페스트 저장소의 이미지 태그를 업데이트합니다. 그런데 ArgoCD가 변경을 감지하지 못하거나 동기화가 지연되는 문제가 발생했습니다. 발생 가능한 원인과 해결 방법, 그리고 이미지 태그 전략을 어떻게 개선할 수 있는지 설명해주세요.
ArgoCD의 폴링 주기, Git webhook 설정, 그리고 latest 태그 사용 여부를 점검해보세요.
첫째, ArgoCD의 기본 폴링 주기는 3분이므로 즉각적인 동기화가 필요하면 Git webhook을 설정하여 변경 즉시 감지하도록 해야 합니다. 둘째, 이미지 태그로 latest나 고정 태그를 사용하면 매니페스트가 변경되지 않아 ArgoCD가 변경을 감지하지 못하므로, Git commit SHA나 빌드 번호를 포함한 유니크한 태그를 사용해야 합니다. 셋째, 매니페스트 저장소 업데이트 시 Jenkins가 적절한 권한과 인증으로 커밋하는지 확인해야 합니다. 넷째, ArgoCD Application의 sync policy를 automated로 설정하고 selfHeal과 prune 옵션을 적절히 구성해야 합니다. 이미지 태그는 semantic versioning이나 git-commit-timestamp 조합으로 관리하여 추적성과 롤백 용이성을 확보하는 것이 좋습니다.
- • ArgoCD 폴링 주기와 Git webhook 설정
- • 유니크한 이미지 태그 전략 필요성
- • 매니페스트 저장소 업데이트 권한 및 자동화
- • ArgoCD sync policy 설정
- • 추적 가능하고 롤백 용이한 태그 전략
대규모 마이크로서비스 환경에서 수십 개 서비스의 배포 자동화와 일관성을 유지할 때 사용됩니다.
멀티 클러스터 환경에서 dev, staging, production 클러스터에 순차적으로 배포하는 프로모션 전략을 GitOps로 어떻게 구현할 수 있을까요?
Q. Kubernetes에서 HPA(Horizontal Pod Autoscaler)를 CPU 메트릭 기반으로 설정했는데, 실제 트래픽이 급증할 때 스케일아웃이 너무 느려서 일부 요청이 타임아웃되는 문제가 발생했습니다. HPA의 스케일아웃 지연 원인과 이를 개선하기 위한 방법, 그리고 CPU 외에 커스텀 메트릭을 추가로 사용해야 하는 상황을 설명해주세요.
HPA의 메트릭 수집 주기, 스케일업 정책, 그리고 애플리케이션 특성에 맞는 메트릭 선택을 고려해보세요.
HPA는 기본적으로 15초마다 메트릭을 수집하지만, 스케일업 결정 후 실제 Pod가 Running 상태가 되고 트래픽을 받기까지 애플리케이션 시작 시간이 추가로 소요됩니다. 개선 방법으로는 첫째, behavior 설정으로 scaleUp의 stabilizationWindowSeconds를 줄이고 policies에서 더 공격적인 스케일업 비율을 설정할 수 있습니다. 둘째, Pod의 readinessProbe를 최적화하고 리소스 requests를 적절히 설정하여 스케줄링과 시작 시간을 단축합니다. 셋째, CPU는 후행 지표이므로 RPS(Requests Per Second)나 큐 길이 같은 선행 지표를 커스텀 메트릭으로 추가하여 트래픽 증가를 먼저 감지할 수 있습니다. 특히 I/O 바운드 애플리케이션은 CPU가 낮아도 처리량이 포화될 수 있으므로 애플리케이션 레벨 메트릭이 필수입니다.
- • HPA 메트릭 수집 주기와 Pod 시작 시간의 복합적 지연
- • behavior 설정으로 스케일업 정책 조정
- • readinessProbe와 리소스 설정 최적화
- • 선행 지표로서의 커스텀 메트릭 활용
- • 애플리케이션 특성에 맞는 메트릭 선택
트래픽 변동이 큰 이커머스나 이벤트 기반 서비스에서 빠른 오토스케일링으로 안정적인 응답 시간을 유지할 때 사용됩니다.
KEDA(Kubernetes Event-Driven Autoscaling)를 사용하면 HPA 대비 어떤 이점이 있으며, 어떤 상황에서 KEDA를 선택해야 할까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!