들어가며

Kubernetes와 EKS 운영 경험을 점검하거나 관련 기술 면접을 준비할 때 알아야 할 핵심 개념을 Q&A 형식으로 정리했습니다. Kubernetes 기본 개념부터 워크로드, 네트워크, 스케줄링, EKS 관련 주제와 트러블슈팅까지 다루므로, 각 질문에 막힘없이 답할 수 있는지 확인하는 용도로 활용하시기 바랍니다.

1. Kubernetes 기본 개념

Q. Kubernetes란

컨테이너화된 애플리케이션의 배포, 확장, 복구, 네트워크를 자동화하는 컨테이너 오케스트레이션 플랫폼

Q. 컨테이너가 환경에 상관없이 동일하게 실행되는 원리는

애플리케이션 실행에 필요한 라이브러리와 설정을 컨테이너 이미지에 함께 패키징하고, Linux 커널의 Namespace와 cgroup으로 프로세스와 자원을 격리하기 때문

Q. Namespace와 cgroup의 차이는

  • Namespace: 격리를 담당하며 프로세스가 볼 수 있는 시스템 자원(프로세스 ID, 네트워크, 파일시스템 등)을 분리
  • cgroup: 자원 관리를 담당하며 프로세스 그룹의 CPU, 메모리, I/O 등 자원 사용량을 측정하고 제한

2. 핵심 워크로드

Q. Pod란 무엇이며 컨테이너와 다른 점은

Pod는 Kubernetes에서 컨테이너를 실행하는 최소 배포 단위로, 하나 이상의 컨테이너가 네트워크와 볼륨을 공유하는 실행 환경을 제공. Pod 자체는 언제든 재생성될 수 있는 비영속적 단위

Q. Pod를 직접 생성하지 않고 Deployment를 사용하는 이유는

Pod는 장애나 노드 문제로 쉽게 사라질 수 있음. Deployment는 ReplicaSet을 통해 지정된 수의 Pod와 버전을 항상 유지하고, Rolling Update와 Rollback 같은 배포 전략을 제공하여 안정적인 애플리케이션 관리를 지원

Q. Deployment, StatefulSet, DaemonSet의 차이와 용도는

  • Deployment: Stateless 애플리케이션용. Pod들이 서로 대체 가능하며 Replica 수 유지와 업데이트를 관리
  • StatefulSet: Stateful 애플리케이션용. 각 Pod가 고유한 이름, 순서, 영구 스토리지를 가지며 DB, 메시지 큐 등에 사용
  • DaemonSet: 모든 또는 특정 노드에 Pod를 하나씩 실행. 로그 수집기, 모니터링 에이전트처럼 노드 단위 실행이 필요한 워크로드에 적합

Q. Job과 CronJob의 차이는

  • Job: 특정 작업이 성공적으로 완료될 때까지 Pod를 실행하는 일회성 태스크
  • CronJob: 정해진 스케줄(cron 표현식)에 따라 Job을 반복해서 생성

3. 서비스와 네트워크

Q. Service가 필요한 이유는

Pod IP는 고정되지 않고 재생성 시 변경됨. Service는 여러 Pod 앞에 고정된 IP와 DNS 이름을 제공하여 Pod의 변경과 무관하게 안정적인 접근점을 제공

Q. Service 타입(ClusterIP, NodePort, LoadBalancer)의 차이는

  • ClusterIP: 클러스터 내부에서만 접근 가능한 기본 타입
  • NodePort: 모든 노드의 특정 포트를 외부에 개방하여 Service에 접근
  • LoadBalancer: 클라우드 제공업체의 로드밸런서를 프로비저닝하여 외부 트래픽을 Service로 전달

Q. Ingress란 무엇이며 LoadBalancer 타입 Service와 어떻게 다른가

Ingress는 HTTP/HTTPS 요청을 Host나 Path 기준으로 여러 Service에 라우팅하는 규칙 모음으로 L7 로드밸런싱을 담당. 실제 동작을 위해 Ingress Controller(예: AWS Load Balancer Controller, NGINX)가 필요. 반면 LoadBalancer 타입 Service는 일반적으로 단일 Service를 L4 수준에서 외부에 노출

Q. CNI(Container Network Interface)의 역할은

Pod 네트워크 생성과 IP 주소 할당을 담당하는 표준 인터페이스. Kubernetes 클러스터의 실제 네트워크 구현은 CNI 플러그인(예: EKS의 VPC CNI, Calico)이 담당

Q. Kubernetes 내부에서 Service DNS 주소는 어떤 형식인가

service-name.namespace.svc.cluster.local 형식을 따르며, 같은 네임스페이스 내에서는 service-name만으로 통신 가능. 이는 CoreDNS가 처리

4. 애플리케이션 상태 관리와 Probe

Q. Readiness, Liveness, Startup Probe의 차이점은

  • Readiness Probe: Pod가 트래픽을 받을 준비가 되었는지 확인. 실패 시 Service Endpoint에서 제외되지만 재시작되지는 않음
  • Liveness Probe: 컨테이너가 살아 있지만 응답 불가능한 상태인지 확인. 실패 시 kubelet이 컨테이너를 재시작
  • Startup Probe: 시작 시간이 긴 애플리케이션의 초기 구동이 완료될 때까지 Liveness/Readiness Probe를 비활성화하여 불필요한 재시작 방지

Q. Readiness와 Liveness Probe에 같은 엔드포인트를 사용하면 안 되는 이유는

DB 연결 같은 외부 의존성 문제로 애플리케이션이 일시적으로 트래픽을 처리할 수 없는 상황을 가정. 이 상태를 Liveness Probe가 감지하면, 아직 정상인 애플리케이션 프로세스를 불필요하게 재시작시켜 상황을 악화시킬 수 있음. 외부 의존성 확인은 Readiness Probe에, 프로세스 자체의 생존 여부는 Liveness Probe에 반영하는 것이 바람직

Q. Graceful Shutdown이란 무엇이고 어떻게 구현하나

Pod가 종료 신호(SIGTERM)를 받았을 때, 새로운 요청을 중단하고 진행 중이던 요청과 연결을 모두 처리한 뒤 안전하게 종료하는 과정. 애플리케이션에서 SIGTERM 핸들러를 구현하고, Kubernetes의 terminationGracePeriodSeconds 설정을 통해 충분한 종료 시간을 보장해야 함

5. 리소스 관리와 스케줄링

Q. Resource Request와 Limit의 차이는

  • Request: 스케줄링 시 보장받아야 하는 최소 자원. 스케줄러는 노드의 할당 가능한 자원을 기준으로 Pod를 배치
  • Limit: 컨테이너가 사용할 수 있는 자원의 최댓값

Q. CPU Throttling과 OOMKilled는 왜 발생하나

  • CPU Throttling: 컨테이너가 CPU Limit을 초과하여 CPU 사용이 강제로 제한되는 현상. 노드에 여유 CPU가 있어도 발생 가능
  • OOMKilled: 컨테이너가 메모리 Limit을 초과하여 Linux 커널의 OOM(Out of Memory) Killer에 의해 강제 종료되는 상태

Q. Taint와 Toleration은 언제 사용하는가

Taint는 특정 노드에 Pod가 스케줄링되지 않도록 설정하는 속성. Toleration은 해당 Taint를 ‘용인’하는 Pod만 그 노드에 배치될 수 있도록 허용. GPU 노드나 특정 워크로드 전용 노드를 격리할 때 주로 사용

Q. Pod Anti-Affinity와 Topology Spread Constraints의 용도는

  • Pod Anti-Affinity: 같은 종류의 Pod들이 동일한 노드나 AZ에 함께 배치되는 것을 방지하여 고가용성 확보
  • Topology Spread Constraints: Pod를 여러 노드나 AZ에 최대한 균등하게 분산시켜 특정 장애 도메인에 워크로드가 집중되는 것을 방지

6. 배포와 가용성

Q. Rolling Update는 어떻게 동작하며 maxSurgemaxUnavailable의 역할은

기존 버전의 Pod를 점진적으로 새 버전으로 교체하는 배포 방식으로, 무중단 배포를 지원

  • maxSurge: 업데이트 중 desired replica 수보다 초과하여 생성할 수 있는 Pod의 최대 개수
  • maxUnavailable: 업데이트 중 사용 불가능 상태가 되어도 되는 Pod의 최대 개수

Q. PDB(PodDisruptionBudget)의 역할은

노드 Drain 같은 자발적인 중단(Voluntary Disruption)이 발생할 때, 특정 애플리케이션의 Pod 중 최소 몇 개가 항상 가용한 상태로 유지되어야 하는지를 정의. 노드 장애 같은 비자발적 중단은 막아주지 않음

7. 오토스케일링

Q. HPA(Horizontal Pod Autoscaler)란

CPU 사용률이나 메모리, 커스텀 메트릭을 기준으로 Deployment나 StatefulSet의 Pod Replica 수를 자동으로 조절하는 기능. HPA는 Pod 수만 늘리므로, 노드 자원이 부족하면 새 Pod는 Pending 상태가 됨

Q. Cluster Autoscaler와 Karpenter의 차이점은

  • Cluster Autoscaler: Pending 상태의 Pod가 있을 때, 미리 정의된 노드 그룹(ASG)의 desired capacity를 조절하여 노드를 늘리거나 줄임. 노드 그룹과 인스턴스 타입이 고정적
  • Karpenter: Pending 상태인 Pod의 요구사항(CPU, 메모리, 아키텍처, AZ 등)을 직접 분석하여 가장 적합한 EC2 인스턴스를 즉시 프로비저닝. 노드 그룹에 종속되지 않아 훨씬 유연하고 빠르게 노드를 공급

8. AWS EKS 핵심 개념

Q. EKS에서 AWS 관리 영역과 사용자 관리 영역은

  • AWS 관리 영역: Kubernetes Control Plane(API 서버, etcd 등)의 설치, 확장, 고가용성
  • 사용자 관리 영역: Worker Node(EC2, Fargate), 애플리케이션 배포, IAM 권한, VPC 네트워킹, 클러스터 Add-on 관리

Q. EKS VPC CNI가 Pod 수를 제한하는 이유는

VPC CNI는 Pod에 VPC의 실제 IP를 할당. 각 EC2 인스턴스는 부착 가능한 ENI(Elastic Network Interface) 수와 각 ENI에 할당 가능한 Secondary IP 주소 수가 제한되어 있어, 인스턴스 타입에 따라 실행 가능한 최대 Pod 수가 결정됨

Q. IRSA와 EKS Pod Identity의 목적은

Pod가 Node의 IAM Role을 그대로 상속받는 대신, Kubernetes ServiceAccount에 특정 IAM Role을 매핑하여 Pod 단위로 최소한의 AWS 권한을 부여하는 방식. 보안과 감사 추적에 유리하며, EKS Pod Identity는 IRSA를 더 단순화한 최신 기능

Q. AWS Load Balancer Controller의 역할은

Kubernetes의 Ingress 리소스를 감시하여 AWS ALB를, Service 리소스를 감시하여 NLB를 자동으로 생성하고 관리하는 컨트롤러. Annotation을 통해 로드밸런서의 세부 설정을 제어

9. 트러블슈팅

Q. Pod가 Pending 상태일 때 확인해야 할 것은

kubectl describe pod <pod-name> 명령의 Events 섹션을 확인. 주요 원인은 다음과 같음

  • 클러스터 자원 부족(CPU, 메모리)
  • 스케줄링 제약 조건(Affinity, Taint/Toleration, Node Selector) 불만족
  • PVC 바인딩 실패

Q. CrashLoopBackOff 상태는 무엇을 의미하며 어떻게 디버깅하나

컨테이너가 시작된 직후 반복적으로 비정상 종료되어, Kubernetes가 재시작 간격을 점차 늘리는 상태. kubectl logs <pod-name> --previous로 이전 컨테이너의 로그를 확인하여 애플리케이션 오류, 설정 오류, 의존성 문제 등을 파악해야 함

Q. ImagePullBackOff의 원인은

컨테이너 이미지를 레지스트리에서 가져오지 못하는 상태. 다음을 확인해야 함

  • 이미지 이름 또는 태그 오타
  • Private Registry 접근 권한 부재 (imagePullSecrets)
  • 네트워크 문제 또는 레지스트리 장애
  • ECR 사용 시 Node IAM Role 또는 IRSA 권한 부족

마무리하며

이 문답들은 Kubernetes와 EKS를 운영하는 엔지니어에게 요구되는 기본적인 지식입니다. 단순히 개념을 아는 것을 넘어, 각 요소가 어떻게 상호작용하고 특정 상황에서 어떤 선택을 해야 하는지 설명할 수 있어야 합니다. 실제 장애 경험과 이를 해결하며 얻은 교훈을 함께 정리해두면 더 깊이 있는 역량을 갖추는 데 도움이 될 것입니다.