Kubernetes 제대로 아는 DevOps 엔지니어를 구분하는 8가지 질문과 답변

안녕하세요. 인포그랩 DevOps 엔지니어 Toma입니다. Kubernetes(K8s)는 DevOps 엔지니어가 명확하게 설명하고 능숙하게 다뤄야 할 핵심 기술입니다. 컨테이너 기반 마이크로서비스가 보편화된 오늘날, DevOps 엔지니어는 단순 개발을 넘어 운영·확장·자동화까지 포괄하는 K8s 역량을 갖춰야 합니다.

특히 면접, 자격증(CKA·CKAD·CKS) 시험, 고객 대응 상황에서 K8s 개념을 제대로 설명하면, DevOps 엔지니어로서 전문성을 입증할 수 있습니다. 단순 암기가 아니라 K8s 설계 원리와 실무 활용법을 이해하고 논리적으로 전달하는 능력이 필요합니다.

이 글에서는 면접과 실무에서 자주 등장하는 K8s 핵심 질문 8가지와 모범 답변을 정리했습니다. 질문 의도·체크 포인트·요약 답변·상세 설명까지 체계적으로 살펴보겠습니다.

1. K8s란 무엇인가요?

질문 의도

• 지원자가 K8s를 단순 배포 도구로만 보는지, 혹은 분산 시스템 플랫폼으로 이해하는지 구분하기 위한 질문입니다. 핵심 개념을 비즈니스 가치와 연결해 설명하는지, 선언적 모델과 자동화 메커니즘을 이해하는지 확인합니다.

체크 포인트

• “트래픽 급증 → 수동 스케일링 한계 → K8s 도입 후 자동 확장으로 운영 부담 감소”처럼 문제 - 해결 구조 사례를 준비하세요. 추상적 정의보다 실무 경험이 더 설득력 있습니다.

요약 답변

• K8s는 컨테이너 애플리케이션을 다중 노드 클러스터에서 배포·확장·복구하는 오케스트레이션 플랫폼입니다. 사용자가 선언적으로 원하는 상태를 정의하면, Scheduler가 Pod를 노드에 배치하고, Controller들이 Control Loop를 통해 실제 상태를 원하는 상태로 지속적으로 수렴합니다.

상세 설명

• 자동화: Deployment Controller는 롤링 업데이트·롤백을 처리하고, ReplicaSet Controller는 Pod 개수를 유지합니다. 노드 장애 시 Node Controller가 해당 노드를 Unknown으로 표시하고 Pod를 제거하면, ReplicaSet이 새 Pod를 생성하고 Scheduler가 정상 노드에 배치합니다. Pod가 Crash되면 kubelet이 restartPolicy에 따라 자동 재시작합니다.
• 선언적 구성: YAML에 replicas:3처럼 원하는 상태만 정의하면, Controller들이 Watch → Compare → Reconcile 패턴으로 상태를 자동 조정합니다. 같은 설정을 여러 번 적용해도 결과가 동일한 멱등성이 보장돼 운영 복잡도가 낮아집니다.
• 확장성과 생태계: CRD로 리소스 타입을 확장하고 Operator 패턴으로 복잡한 Stateful 애플리케이션을 자동화합니다. Helm(패키지 관리), ArgoCD/Flux(GitOps), Prometheus(모니터링), Terraform/Jenkins(외부 통합) 등과 표준 API로 연동됩니다.

2. 호스트, 컨테이너, K8s 배포 차이는 무엇인가요?

질문 의도

• 호스트(베어메탈/VM), 컨테이너(Docker), K8s 배포 방식의 차이를 통해 각 접근법의 트레이드오프(복잡도 vs 자동화, 유연성 vs 관리 부담)를 이해하는지 확인합니다. 특히 “왜 K8s가 필요한가?”를 설명할 수 있는지, 도입 초기 복잡도를 어떻게 관리했는지가 핵심입니다.

체크 포인트

• “수동 배포로 장애 발생 → Docker로 환경을 통일했으나 다중 서버 관리 어려움 → K8s 도입 후 롤링 업데이트로 무중단 배포 달성”처럼 진화 과정을 경험 기반으로 설명하세요. K8s 도입 초기에는 러닝커브와 인프라 복잡도 증가를 인정하되, 자동화 이점이 이를 상쇄한다는 점을 강조합니다.

요약 답변

• 호스트 배포는 환경 의존성이 커서 재현성이 낮고 수동 작업이 많습니다. 컨테이너는 이식성과 격리성이 높아 동일 이미지를 어디서나 실행할 수 있지만, 다중 서버 환경에서는 오케스트레이션이 필요합니다. K8s는 다중 노드 클러스터에서 선언적 배포, 자동 스케일링, 롤링 업데이트, 장애 복구를 제공해 운영을 자동화합니다.

상세 설명

방식	장점	단점	적합한 상황
호스트 배포	단순함, 직접 제어	환경 의존성, 수동 배포, 재현 어려움	소규모, 레거시 시스템
컨테이너	이식성, 격리성, 빠른 시작	다중 서버 관리 복잡, 네트워킹/스토리지 수동	개발·테스트 환경
K8s	선언적 관리, 자동 스케일링, 자가 복구, 롤링 업데이트	높은 초기 복잡도, 러닝커브	대규모, 마이크로서비스

3. K8s 도입의 실무 이점은 무엇인가요?

질문 의도

• K8s의 기술적 특징을 비즈니스 가치로 전환할 수 있는지 확인합니다. 단순히 기능을 나열하는 게 아니라, “이 기능으로 무엇이 개선됐는가”를 정량적 지표(배포 시간, 장애 복구 시간, 가용성, 비용)로 설명하는 게 핵심입니다.

체크 포인트

• “수동 배포 30분 → K8s 롤링 업데이트 5분으로 단축”, “장애 복구 10분 → 셀프힐링 30초 자동 복구”, “트래픽 급증 시 HPA로 자동 대응, 인프라 비용 30% 절감”처럼 도입 전과 후를 정량적 지표로 준비하세요. 기술을 결과와 연결하는 능력이 중요합니다.

요약 답변

• K8s 도입 후 배포 자동화로 배포 시간이 크게 단축되고, 셀프힐링으로 장애 복구가 자동화되며, HPA로 트래픽 변화에 자동 대응해 인프라 효율이 향상됩니다. 롤링 업데이트로 무중단 배포가 가능하고, 선언적 구성으로 인프라 변경 이력 관리와 재현성이 보장됩니다.

상세 설명

• 배포 자동화: 수동 배포는 환경별 스크립트 관리와 수작업으로 평균 30분 이상 소요됩니다. K8s는 kubectl apply 한 번으로 배포가 완료되고 YAML로 버전 관리돼 5분 이내에 완료됩니다. 배포 빈도가 증가하고 휴먼 에러가 감소합니다.
• 장애 자동 복구: 기존에는 모니터링 알람 수신 후 수동으로 확인하고 재시작하는 데 평균 10분이 소요됐습니다. K8s는 Pod Crash 시 kubelet이 restartPolicy에 따라 30초 이내 자동 재시작하고, 노드 장애 시 다른 노드에 자동 재배치합니다. MTTR(평균 복구 시간)이 95% 단축되고 야간 장애 대응 부담이 줄어듭니다.
• 리소스 효율: 피크 트래픽 대비 고정 용량을 유지하면 평소 유휴 리소스가 많습니다. HPA는 트래픽에 따라 Pod를 자동 확장·축소해 인프라 비용을 30% 절감하면서도 피크 대응력을 높입니다.
• 무중단 배포: 기존 배포는 서비스 중단이 필요해 야간작업으로 제한됐습니다. K8s 롤링 업데이트는 점진적 배포로 다운타임 없이 배포하고, readinessProbe로 안정성을 확보합니다. 배포 시간 제약이 사라지고 배포 빈도가 증가합니다.

4. K8s 아키텍처의 구성요소는 무엇인가요?

질문 의도

• K8s의 Control Plane과 Worker Node 컴포넌트의 역할과 책임 경계를 이해하는지 확인합니다. 특히 각 컴포넌트 장애 시 어떤 증상이 나타나는지 연결해 설명할 수 있는지가 핵심입니다. “API Server가 다운되면?”, “kubelet에 응답이 없으면?” 같은 장애 상황을 이해해야 합니다.

체크 포인트

• “API Server 장애 → 모든 kubectl 명령 실패, 새로운 Pod 생성 불가”, “kubelet 장애 → 해당 노드의 Pod 상태 업데이트 중단, NotReady 상태” 같은 컴포넌트별 장애 증상을 준비하세요. HA 구성 시 Control Plane은 다중화(3개 또는 5개 홀수), etcd는 쿼럼 유지가 중요합니다.

요약 답변

• K8s는 Control Plane과 Worker Node로 구성됩니다. Control Plane의 API Server는 모든 요청의 진입점이며, etcd는 클러스터 상태를 저장하고, Scheduler는 Pod를 노드에 배치하며, Controller Manager는 다양한 Controller를 실행해 원하는 상태를 유지합니다. Worker Node의 kubelet은 Pod를 실행하고 상태를 보고하며, kube-proxy는 Service 규칙 기반 네트워크 라우팅을 담당하고, 컨테이너 런타임은 실제 컨테이너를 실행합니다.

상세 설명

Control Plane 컴포넌트

• API Server: 모든 REST 요청의 진입점으로 인증·인가·검증을 수행하고, etcd와의 유일한 인터페이스 역할을 합니다. kubectl, Scheduler, Controller가 모두 API Server를 통해 통신합니다. 장애 시 모든 클러스터 제어가 불가능하지만, 실행 중인 Pod는 계속 동작합니다.
• etcd: 분산 key-value 저장소로 클러스터의 모든 상태 정보(Desired State, Actual State)를 저장합니다. Raft 합의 알고리즘으로 데이터 일관성을 보장하며, 쿼럼(과반수)이 필요합니다. 장애 시 클러스터 상태 읽기·쓰기가 불가능해 새로운 변경이 중단됩니다.
• Scheduler: Pending 상태의 Pod를 탐지하고 리소스·어피니티·Taint/Toleration을 고려해 최적의 노드를 선택합니다. 선택 결과(binding)를 API Server에 전달합니다. 장애 시 새 Pod가 Pending 상태로 멈추지만, 실행 중인 Pod는 영향이 없습니다.
• Controller Manager: Deployment, ReplicaSet, Node 등 다양한 Controller를 실행하는 단일 프로세스입니다. 각 Controller는 Watch → Compare → Reconcile 패턴으로 원하는 상태를 유지합니다. 장애 시 자동 복구·스케일링이 중단되지만, 실행 중인 Pod는 계속 동작합니다.

Worker Node 컴포넌트

• kubelet: 각 노드에서 실행되며 API Server로부터 Pod 명세를 받아 컨테이너 런타임에 실행을 요청하고, Pod 상태를 주기적으로 API Server에 보고합니다. 장애 시 해당 노드가 NotReady 상태가 되고 새 Pod 배치가 중단됩니다.
• kube‑proxy: 각 노드에서 Service 규칙을 iptables 또는 ipvs로 구현해 트래픽을 Pod로 라우팅합니다. 장애 시 해당 노드에서 Service를 통한 통신이 실패하지만, Pod IP 직접 통신은 가능합니다.
• 컨테이너 런타임: 실제 컨테이너를 실행하는 소프트웨어로 containerd, CRI-O 등이 있습니다. CRI(Container Runtime Interface)를 통해 kubelet과 통신합니다. 장애 시 해당 노드의 모든 컨테이너가 중단됩니다.

5. Pod는 어떻게 작동하나요?

질문 의도

• Pod 생성 과정을 통해 Kubernetes Control Plane 컴포넌트 간 상호작용을 이해하는지 확인하는 질문입니다. 특히 “kubectl apply 이후 어떤 일이 일어나나요?”를 설명할 수 있는지, kubelet과 컨테이너 런타임(containerd/CRI-O)의 역할을 이해하는지가 핵심입니다.

체크 포인트

• “Pod가 Pending 상태에서 멈춤 → kubectl describe로 Events 확인 → 스케줄 실패 원인 파악 → 노드 리소스 부족 해결”처럼 문제 - 원인 - 조치 흐름을 사례 기반으로 설명하세요. kubectl describe → kubectl get events → kubelet 로그 순으로 추적하는 루틴이 중요합니다.

요약 답변

• kubectl apply로 요청하면 API Server가 리소스를 검증하고 etcd에 저장합니다. Scheduler가 적절한 노드를 선택해 API Server에 스케줄링 결과를 기록하면, API Server가 이를 etcd에 반영합니다. 해당 노드의 kubelet이 변경사항을 탐지하고, 컨테이너 런타임을 호출해 컨테이너를 실행합니다. Pod가 프로브를 통과하면 Ready 상태가 되고, kubelet이 상태를 API Server에 주기적으로 보고합니다.

상세 설명

Pod 생성 흐름

1. 요청: kubectl apply가 YAML을 API Server로 전송합니다.
2. 검증, 저장: API Server가 요청을 검증하고 Desired State를 etcd에 저장합니다.
3. 스케줄링: Scheduler가 리소스·어피니티·Taint/Toleration을 고려해 노드를 선택하고 스케줄링 결과를 API Server에 전달합니다.
4. 실행: 선택된 노드의 kubelet이 API 변경을 Watch로 감지하고 컨테이너 런타임에 컨테이너 생성을 요청합니다.
5. 헬스 체크: Liveness/Readiness Probe를 통해 컨테이너 상태를 검사합니다.
6. 상태 보고: kubelet이 Pod 상태(Running, Ready 등)를 API Server에 지속적으로 보고하고, 이는 etcd에 저장됩니다.

트러블슈팅 포인트

• Pending: Scheduler가 노드를 찾지 못함(리소스 부족, Taint/Toleration 불일치 등)
• ImagePullBackOff: 이미지 레지스트리 접근 실패 또는 이미지 없음
• CrashLoopBackOff: 컨테이너 반복 실패(애플리케이션 오류, 잘못된 설정 등)

6. K8s의 주요 리소스는 무엇인가요?

질문 의도

• K8s의 핵심 리소스(Pod, Deployment, Service)와 보조 리소스(ConfigMap, Secret, PVC)의 역할과 책임 경계를 이해하는지 확인합니다. 특히 “Deployment와 ReplicaSet 관계”, “ConfigMap vs Secret 선택 기준”, “PVC 바인딩 실패 원인”을 명확히 설명하는 게 핵심입니다.

체크 포인트

• “PVC가 Pending 상태로 멈춤 → kubectl describe pvc로 이벤트 확인 → StorageClass가 없거나 용량이 부족한 걸 발견 → StorageClass 생성 또는 용량 조정으로 해결”처럼 리소스별 트러블슈팅 경험을 준비하세요. 실제 운영에서 겪은 문제와 해결 과정을 구체적으로 설명하는 게 중요합니다.

요약 답변

• Pod는 컨테이너를 실행하는 최소 단위이고, Deployment는 Pod를 선언적으로 관리하며 롤링 업데이트와 롤백을 지원합니다. Service는 Pod 집합에 안정적인 엔드포인트를 제공합니다. ConfigMap은 평문 설정을, Secret은 민감 정보를 저장하며, PVC는 영구 스토리지를 요청하고, StorageClass가 실제 볼륨을 프로비저닝합니다.

상세 설명

핵심 워크로드 리소스

• Pod: 1개 이상의 컨테이너를 묶은 최소 실행 단위로, 같은 네트워크 네임스페이스와 볼륨을 공유합니다. IP와 수명이 일시적이므로 직접 사용하기보다 Deployment로 관리합니다.
• Deployment: ReplicaSet을 관리하며 선언적 업데이트를 제공합니다. 새 버전 배포 시 ReplicaSet을 생성하고 점진적으로 전환하며, 롤백 시 이전 ReplicaSet을 재활성화합니다.
• Service: label selector로 Pod를 선택해 안정적인 ClusterIP를 제공하고, Endpoints 객체가 실제 Pod IP 목록을 유지합니다.

설정, 보안 리소스

• ConfigMap: 평문 설정 데이터(환경 변수, 설정 파일)를 저장합니다. env, envFrom, volumeMount로 Pod에 주입 가능합니다.
• Secret: base64로 인코딩된 민감 정보(비밀번호, API 키, 인증서)를 저장합니다. 암호화는 etcd 수준에서 별도 설정(EncryptionConfiguration)이 필요합니다.

스토리지 리소스

• PVC(PersistentVolumeClaim): 스토리지 요청 명세(용량, 접근 모드)를 정의합니다.
• StorageClass: 동적 프로비저닝 정책(AWS EBS, GCP Persistent Disk 등)을 정의하며, PVC가 StorageClass를 참조하면 PV가 자동으로 생성됩니다.

7. Service, Ingress, kube‑proxy는 어떻게 동작하나요?

질문 의도

• K8s 네트워킹의 핵심인 Service(L4)와 Ingress(L7)의 역할 차이를 이해하고, kube-proxy가 어떻게 트래픽을 라우팅하는지 설명하는 역량을 확인합니다. 특히 “NodePort와 LoadBalancer 차이”, “Ingress가 동작하지 않을 때 점검 순서”를 명확히 답변하는 게 핵심입니다.

체크 포인트

• “Service를 생성했으나 접근 불가 → kubectl get endpoints로 Pod IP 확인 → 비어 있으면 selector 불일치”, “Ingress를 설정했으나 404 오류 발생 → Ingress Controller 로그 확인 → Service 이름 오타 발견” 같은 트러블슈팅 순서를 준비하세요. svc 정의 → Endpoints → Controller 로그 순으로 점검합니다.

요약 답변

• Service는 Pod 집합에 안정적인 엔드포인트(ClusterIP)를 제공하고, NodePort로 노드 포트를 통해, LoadBalancer로 클라우드 LB를 통해 외부 노출이 가능합니다. Ingress는 HTTP/HTTPS 트래픽을 경로·호스트 기반으로 여러 Service에 라우팅하며, Ingress Controller가 실제 구현을 담당합니다. kube‑proxy는 각 노드에서 Service 규칙을 iptables 또는 ipvs로 구현해 트래픽을 Pod로 전달합니다.

상세 설명

• Service 타입: ClusterIP는 클러스터 내부에서만 접근 가능한 가상 IP를 제공합니다(기본값). NodePort는 각 노드의 30000-32767 포트로 외부에 노출하며, LoadBalancer는 클라우드 제공자의 LB를 자동 프로비저닝합니다. Service는 selector로 Pod를 선택하고, Endpoints 객체가 실제 Pod IP 목록을 유지합니다.
• Ingress와 Ingress Controller: Ingress는 HTTP/HTTPS 라우팅 규칙을 정의하는 리소스이고, Ingress Controller(nginx-ingress, traefik 등)가 실제 구현체입니다. 경로 기반(/api → api-service), 호스트 기반(api.example.com → api-service) 라우팅과 TLS 종료를 지원합니다. 단일 진입점으로 여러 Service를 노출해 비용을 절감합니다.
• kube‑proxy 동작: 각 노드에서 실행되며 Service 규칙을 감시해 iptables(기본) 또는 ipvs 규칙으로 구현합니다. iptables 모드는 규칙 기반 순차 처리, ipvs 모드는 해시 테이블 기반으로 대규모 환경에서 더 효율적입니다. kube-proxy 장애 시 해당 노드에서 Service 통신이 실패하지만, Pod IP 직접 통신은 가능합니다.

8. 오토스케일링 HPA·VPA·CA 차이는 무엇인가요?

질문 의도

• Kubernetes의 3가지 오토스케일링 메커니즘(HPA, VPA, CA)을 통해 애플리케이션(Pod)·리소스 요청(Resource Request)·인프라(Node) 레벨 스케일링을 각각 이해하는지 확인합니다. 각 방식의 동작 원리와 트레이드오프(성능 vs 비용, 자동화 vs 중단)를 파악하는 게 핵심입니다.

체크 포인트

• “트래픽 급증 → HPA로 Pod 증가 → 노드 리소스 부족으로 Pending→ CA가 노드 추가 → Pod 정상 배치” 같은 HPA + CA 조합 시나리오를 설명하세요. VPA는 리소스 요청을 자동 조정할 때 Pod 재시작이 발생하므로 프로덕션에서 주의가 필요합니다.

요약 답변

• HPA: CPU·메모리·커스텀 메트릭을 기준으로 Pod 개수를 자동 조절(Pod 스케일 아웃/인)합니다.
• VPA: 과거 리소스 사용량 통계를 기반으로 Pod의 CPU/메모리 requests를 추천하거나 자동 조정하는데, 자동 적용 시 Pod 재시작이 필요합니다.
• CA: 스케줄 실패(Pending)가 발생하면 노드를 자동 추가, 유휴 노드는 제거해 클러스터 크기를 자동 관리합니다.

상세 설명

항목	대상	기준	동작	주의 사항
HPA	Pod 개수	CPU·메모리·커스텀 메트릭	Pod 스케일 아웃/인	메트릭 정확도, 쿨다운, 요청/리밋 설정 중요
VPA	Pod 리소스 요청 (CPU/메모리)	과거 사용량 통계	Request 추천 또는 자동 적용	재시작 필요, HPA와 VPA를 CPU/메모리 메트릭에 동시 사용 비권장 (충돌 발생). 단, VPA는 Off/Initial 모드로, HPA는 커스텀 메트릭으로 분리 사용 가능
CA	노드 수	스케줄 실패(Pending), 유휴 노드	노드 자동 추가·제거	클라우드 API 연동 필요, 스케일다운 지연 존재

자주 나오는 운영/트러블슈팅 Q&A

체크 루틴

문제 발생 시 아래 흐름에 따라 진단하는 습관이 중요합니다.

• 문제 발생 → 정보 수집 → 원인 분석 → 조치 → 검증

자주 묻는 질문·점검 루틴

1. 노드 NotReady 시 어떻게 진단하나요?
   • kubectl get nodes로 NotReady 노드를 식별합니다.
   • kubectl describe node <노드명>으로 이벤트와 상태를 확인합니다.
   • 해당 노드의 kubelet 로그, 시스템 리소스(CPU/메모리/디스크/네트워크)를 점검합니다.
     • 주요 원인: kubelet 프로세스 비정상, 네트워크 단절, 디스크/메모리 부족, 인증서 만료 등
     • NotReady 지속 시 해당 노드로 Pod 스케줄링이 차단되고, 5분 후 기존 Pod는 축출됩니다.
2. CrashLoopBackOff는 어떻게 디버깅하나요?
   • kubectl get pod, kubectl describe pod <이름>으로 이벤트와 상태를 확인합니다.
   • kubectl logs <이름>으로 컨테이너 로그를 분석합니다.
   • 이벤트/로그에서 OOMKilled, 이미지 Pull 오류, PVC 마운트 실패 여부를 확인합니다.
     • 환경 변수/ConfigMap/Secret 오류, readiness/liveness probe 실패도 점검합니다.
3. Ingress가 동작하지 않을 때 어떻게 디버깅하나요?
   • Ingress 리소스 정의(kubectl get ingress)와 경로/호스트 규칙을 확인합니다.
   • Ingress Controller(예: nginx-ingress) Pod와 로그(kubectl logs)를 점검합니다.
   • 연결된 Service/Endpoints 상태를 확인하고, 오타·포트·타겟 일치 여부를 점검합니다.
   • DNS 레코드, 외부 포트포워딩/Firewall 설정을 포함한 네트워크 경로를 점검합니다.

맺음말

지금까지 면접과 실무에서 자주 등장하는 K8s 핵심 질문 8가지와 모범 답변을 정리했습니다. 답변에 경험을 한 줄 붙여 보세요. 필요 시 로그와 메트릭을 근거로 덧붙여도 충분합니다. 다음 체크 포인트를 기억하세요.

• 답변은 “정의 → 왜 지금 필요한가? → 어떻게 운영되는가? → 문제가 발생하면 어떻게 복구하는가?” 흐름으로 짧게 구성
• 용어 표기는 문서와 일관되게 사용(K8s, Control Plane, Worker Node 등).
• 예시에 수치나 결과를 한 줄이라도 포함해 설득력 확보

완벽한 GitLab 구축부터 성공적인 DevOps 도입까지! 인포그랩과 DevOps 라이프사이클을 함께하세요.