Kubernetes 주니어 테스트 · 코드품질 기술면접
새 면접Q. Kubernetes YAML 매니페스트 파일의 유효성을 배포 전에 검증하는 방법에는 어떤 것들이 있나요? 최소 3가지 방법을 설명해주세요.
kubectl 명령어의 dry-run 옵션과 전용 검증 도구들을 생각해보세요.
첫째, kubectl apply --dry-run=client 명령어로 클라이언트 측에서 기본 문법과 구조를 검증할 수 있습니다. 둘째, kubectl apply --dry-run=server 명령어로 서버 측에서 실제 API 검증과 admission controller 확인까지 수행할 수 있습니다. 셋째, kubeval이나 kube-score 같은 정적 분석 도구를 사용하여 베스트 프랙티스 준수 여부를 검증할 수 있습니다. 넷째, Helm의 경우 helm lint 명령어로 차트의 문법과 구조를 검증할 수 있습니다. 이러한 검증 단계들을 CI/CD 파이프라인에 통합하면 배포 전 오류를 사전에 방지할 수 있습니다.
- • kubectl dry-run 옵션을 활용한 client/server 측 검증
- • kubeval, kube-score 등 정적 분석 도구 활용
- • CI/CD 파이프라인에 검증 단계 통합
프로덕션 배포 전 잘못된 매니페스트로 인한 서비스 장애를 예방하기 위해 필수적으로 사용됩니다.
CI/CD 파이프라인에서 이러한 검증 단계들을 어떤 순서로 배치하는 것이 효율적일까요?
Q. Kubernetes 환경에서 애플리케이션의 통합 테스트를 수행할 때, 로컬 개발 환경에서 실제 클러스터와 유사한 환경을 구성하는 방법과 각각의 장단점을 설명해주세요.
minikube, kind, k3s 등 로컬 Kubernetes 환경 도구들의 특징을 비교해보세요.
로컬 Kubernetes 테스트 환경으로는 minikube, kind, k3s가 주로 사용됩니다. minikube는 가장 성숙한 도구로 다양한 드라이버를 지원하지만 리소스 사용량이 많고 시작 시간이 깁니다. kind(Kubernetes in Docker)는 Docker 컨테이너 내에서 클러스터를 실행하여 빠른 시작과 멀티노드 구성이 쉽지만, Docker 의존성이 있습니다. k3s는 경량화된 Kubernetes로 리소스 사용량이 적고 빠르지만 일부 기능이 제한적입니다. CI/CD 환경에서는 빠른 시작 시간과 격리성 때문에 kind가 선호되며, 로컬 개발에서는 minikube나 k3s가 많이 사용됩니다.
- • minikube, kind, k3s의 특징과 차이점 이해
- • 각 도구의 리소스 사용량, 시작 시간, 기능 범위 비교
- • 용도에 따른 적절한 도구 선택
프로덕션 배포 전에 실제 클러스터 환경과 유사한 조건에서 애플리케이션을 테스트하여 환경 차이로 인한 문제를 사전에 발견합니다.
GitHub Actions나 GitLab CI에서 Kubernetes 통합 테스트를 구성한다면 어떤 도구를 선택하시겠습니까?
Q. 팀에서 작성한 Helm Chart의 코드 품질을 리뷰할 때 중점적으로 확인해야 할 항목들은 무엇인가요? 최소 4가지 이상 설명해주세요.
values.yaml 구조, 템플릿 문법, 보안, 그리고 베스트 프랙티스 관점에서 생각해보세요.
첫째, values.yaml의 구조가 명확하고 기본값이 적절하게 설정되어 있는지 확인해야 합니다. 둘째, 템플릿에서 하드코딩된 값 대신 변수를 사용하고 있는지, 그리고 required 함수로 필수 값을 검증하는지 확인합니다. 셋째, 민감한 정보가 values.yaml에 평문으로 노출되지 않고 Secret으로 관리되는지 점검합니다. 넷째, 리소스 limits와 requests가 적절히 설정되어 있는지 확인합니다. 다섯째, labels와 annotations가 일관성 있게 적용되어 있는지, 그리고 selector가 올바르게 매칭되는지 검증합니다. 여섯째, helm lint와 helm template 명령어로 문법 오류와 렌더링 결과를 확인합니다.
- • values.yaml 구조와 기본값의 적절성
- • 템플릿 변수 사용과 필수 값 검증
- • 보안 요소(Secret, 민감정보) 관리
- • 리소스 설정과 labels/selector 일관성
여러 환경(dev, staging, prod)에 일관되게 배포 가능한 고품질 Helm Chart를 유지하기 위해 코드 리뷰 시 필수적으로 확인합니다.
Helm Chart의 버전 관리 전략과 backward compatibility를 어떻게 유지하시겠습니까?
Q. 기존에 단일 Deployment로 관리되던 애플리케이션을 여러 마이크로서비스로 분리하는 리팩토링 작업을 진행한다고 가정합니다. 이 과정에서 Kubernetes 리소스를 안전하게 리팩토링하기 위한 단계별 접근 방법을 설명해주세요.
무중단 배포와 점진적 전환, 그리고 롤백 가능성을 고려해보세요.
첫째, 기존 Deployment를 유지한 채로 새로운 마이크로서비스 Deployment를 별도로 배포합니다. 둘째, Service 리소스를 활용하여 트래픽 라우팅을 점진적으로 전환할 수 있도록 준비합니다. 셋째, Ingress나 Service Mesh를 사용하여 카나리 배포나 블루-그린 배포 방식으로 트래픽을 일부만 새 서비스로 전환합니다. 넷째, 모니터링과 로깅을 통해 새 서비스의 안정성을 검증하고 문제 발생 시 즉시 롤백할 수 있도록 준비합니다. 다섯째, 충분한 검증 후 트래픽을 완전히 전환하고 기존 Deployment를 제거합니다. 각 단계마다 YAML 매니페스트를 버전 관리하여 언제든 이전 상태로 복구 가능하도록 합니다.
- • 기존 리소스 유지하며 새 리소스 병행 배포
- • 점진적 트래픽 전환 (카나리/블루-그린)
- • 모니터링과 롤백 전략 수립
- • 매니페스트 버전 관리
모놀리식 애플리케이션을 마이크로서비스로 전환하거나 아키텍처 개선 시 서비스 중단 없이 안전하게 전환하기 위해 사용됩니다.
리팩토링 중 데이터베이스 스키마 변경이 필요하다면 어떻게 접근하시겠습니까?
Q. Kubernetes에 배포된 애플리케이션의 end-to-end 테스트를 자동화하려고 합니다. 테스트 환경 구성부터 실행, 정리까지의 전체 워크플로우를 설계하고, 각 단계에서 고려해야 할 사항들을 설명해주세요.
테스트 격리, 리소스 정리, 테스트 데이터 관리, 그리고 CI/CD 통합 관점에서 접근해보세요.
첫째, 테스트 전용 네임스페이스를 동적으로 생성하여 테스트 간 격리를 보장하고, 네임스페이스 이름에 타임스탬프나 UUID를 포함시켜 병렬 실행을 지원합니다. 둘째, Helm이나 Kustomize를 사용하여 테스트용 애플리케이션과 의존성(데이터베이스, 캐시 등)을 배포하고, initContainer로 테스트 데이터를 주입합니다. 셋째, kubectl wait 명령어로 모든 Pod가 Ready 상태가 될 때까지 대기한 후 테스트를 실행합니다. 넷째, 테스트 스크립트에서 Service나 Ingress를 통해 애플리케이션에 접근하여 시나리오를 검증합니다. 다섯째, 테스트 완료 후 성공/실패 여부와 관계없이 반드시 네임스페이스를 삭제하여 리소스를 정리합니다(trap 명령어 활용). 여섯째, 테스트 결과와 로그를 수집하여 CI/CD 시스템에 리포팅하고, 실패 시 디버깅을 위한 아티팩트를 보존합니다.
- • 네임스페이스 기반 테스트 격리와 병렬 실행 지원
- • 의존성 배포와 초기화 대기 메커니즘
- • 테스트 후 리소스 정리 자동화
- • CI/CD 통합과 결과 리포팅
CI/CD 파이프라인에서 프로덕션 배포 전 자동화된 end-to-end 테스트로 전체 시스템의 동작을 검증하여 품질을 보장합니다.
테스트 실행 시간이 너무 길어진다면 어떤 최적화 방법을 적용할 수 있을까요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!