Kubernetes 주니어 테스트·코드품질 기술면접

ConfigMap과 Secret은 최종적으로 환경변수나 볼륨 마운트를 통해 애플리케이션에 전달되므로, 단위 테스트에서는 이러한 인터페이스를 모킹하면 됩니다. 환경변수의 경우 테스트 코드에서 직접 설정하거나 .env 파일을 사용하고, 파일 마운트의 경우 임시 디렉토리에 테스트용 파일을 생성합니다. 설정 로딩 로직을 별도 모듈로 분리하여 의존성 주입 패턴을 적용하면 테스트가 더 용이합니다. 통합 테스트 단계에서는 kind나 minikube 같은 로컬 클러스터에 실제 ConfigMap/Secret을 생성하여 전체 흐름을 검증합니다. 이렇게 단위 테스트와 통합 테스트를 분리하면 빠른 피드백과 실제 환경 검증을 모두 확보할 수 있습니다.

첫 번째 방법은 Kustomize를 사용하여 base와 overlay 구조로 분리하는 것입니다. 공통 리소스 정의를 base에 두고, 환경별 차이만 overlay에서 패치하면 중복을 제거할 수 있습니다. 두 번째는 Helm Chart를 사용하여 values.yaml에 변수를 정의하고 템플릿화하는 방법으로, 복잡한 로직이 필요한 경우 적합합니다. 세 번째는 yq나 jsonnet 같은 YAML 전처리 도구를 사용하여 공통 값을 변수로 추출하고 병합하는 방법입니다. 단순한 중복 제거는 Kustomize가 적합하고, 다양한 환경과 복잡한 조건 분기가 필요하면 Helm이 유리합니다. 리팩토링 후에는 반드시 kubectl diff나 helm diff로 변경사항을 검증해야 합니다.

로컬 환경에서는 먼저 애플리케이션을 Docker 컨테이너로 실행하고, Probe에 정의된 HTTP 엔드포인트에 curl이나 wget으로 직접 요청을 보내 응답 코드와 내용을 확인합니다. exec 타입 Probe의 경우 docker exec 명령으로 컨테이너 내부에서 동일한 명령을 실행해봅니다. CI/CD 파이프라인에서는 테스트 단계에서 컨테이너를 실행하고 자동화된 스크립트로 Probe 엔드포인트를 호출하여 예상 응답을 검증합니다. 또한 kind나 minikube에 실제로 배포하여 kubectl describe pod로 Probe 실패 이벤트를 확인하거나, kubectl get pod의 READY 상태 변화를 모니터링하는 통합 테스트를 수행할 수 있습니다. 의도적으로 Probe를 실패시켜 재시작이나 트래픽 제외가 정상 동작하는지도 확인해야 합니다.