Kubernetes 미드레벨 프레임워크 면접
새 면접Q. Kubernetes Pod의 Init Container와 Sidecar Container의 차이점과 각각의 사용 사례를 설명해주세요. 특히 Init Container가 실패했을 때와 Sidecar Container가 실패했을 때 Pod의 상태는 어떻게 달라지나요?
두 컨테이너의 실행 시점과 생명주기, 그리고 메인 컨테이너와의 관계를 생각해보세요.
Init Container는 메인 컨테이너 실행 전에 순차적으로 실행되며 초기화 작업(DB 마이그레이션, 설정 파일 준비 등)을 수행합니다. Sidecar Container는 메인 컨테이너와 함께 병렬로 실행되며 보조 기능(로그 수집, 프록시 등)을 담당합니다. Init Container가 실패하면 Pod는 Init:Error 또는 Init:CrashLoopBackOff 상태가 되어 메인 컨테이너가 시작되지 않습니다. 반면 Sidecar Container가 실패하면 Pod의 Ready 상태에 영향을 주지만 메인 컨테이너는 계속 실행될 수 있습니다. Init Container는 완료 후 종료되지만 Sidecar는 Pod 생명주기 동안 계속 실행됩니다.
- • Init Container는 순차 실행되며 메인 컨테이너 시작 전 초기화 담당
- • Sidecar Container는 병렬 실행되며 메인 컨테이너와 함께 동작
- • Init Container 실패 시 Pod가 시작되지 않으며, Sidecar 실패는 Ready 상태에 영향
마이크로서비스에서 서비스 메시(Istio, Linkerd)의 Envoy 프록시를 Sidecar로 주입하거나, DB 마이그레이션을 Init Container로 처리할 때 사용됩니다.
Kubernetes 1.28부터 도입된 Sidecar Container의 restartPolicy를 활용하면 기존 Sidecar 패턴과 어떤 차이가 있나요?
Q. Kubernetes의 Service 타입 중 ClusterIP, NodePort, LoadBalancer의 차이점을 설명하고, 각각 어떤 상황에서 사용해야 하는지 설명해주세요. 또한 externalTrafficPolicy 설정이 무엇이며 어떤 영향을 주나요?
각 Service 타입의 접근 범위와 네트워크 홉 수, 그리고 클라이언트 IP 보존 여부를 고려해보세요.
ClusterIP는 클러스터 내부에서만 접근 가능한 가상 IP를 제공하며 내부 서비스 간 통신에 사용합니다. NodePort는 모든 노드의 특정 포트를 열어 외부에서 접근 가능하게 하며 개발/테스트 환경에 적합합니다. LoadBalancer는 클라우드 프로바이더의 로드밸런서를 프로비저닝하여 외부 트래픽을 분산하며 프로덕션 환경의 외부 노출에 사용됩니다. externalTrafficPolicy를 Local로 설정하면 트래픽이 해당 노드의 Pod로만 라우팅되어 클라이언트 IP가 보존되고 네트워크 홉이 줄어들지만, Pod가 없는 노드는 트래픽을 받지 못해 불균형이 발생할 수 있습니다. Cluster(기본값)는 모든 노드로 트래픽을 분산하지만 SNAT로 인해 클라이언트 IP가 손실됩니다.
- • ClusterIP는 내부 전용, NodePort는 노드 포트 노출, LoadBalancer는 클라우드 LB 사용
- • externalTrafficPolicy Local은 클라이언트 IP 보존과 홉 감소를 제공
- • Local 설정 시 Pod 분포에 따른 트래픽 불균형 발생 가능
웹 애플리케이션을 외부에 노출할 때 LoadBalancer와 Ingress를 조합하여 사용하며, 로깅이나 보안을 위해 클라이언트 IP 보존이 필요한 경우 externalTrafficPolicy를 설정합니다.
Ingress를 사용할 때와 LoadBalancer Service를 직접 사용할 때의 비용 및 관리 측면에서의 차이는 무엇인가요?
Q. Kubernetes에서 Pod의 CPU requests와 limits 설정 시 throttling이 발생하는 원리를 설명하고, CPU limits를 설정하지 않는 것이 권장되는 경우와 그 이유를 설명해주세요.
CFS(Completely Fair Scheduler)의 동작 방식과 CPU 사용량이 burst할 때의 영향을 생각해보세요.
Kubernetes는 Linux CFS를 사용하여 CPU를 관리하며, CPU limits는 cfs_quota와 cfs_period로 구현됩니다. Pod가 설정된 quota를 초과하면 period가 끝날 때까지 throttling되어 대기하게 됩니다. CPU는 압축 가능한(compressible) 리소스이므로 limits 없이도 requests만으로 스케줄링이 가능하며, 유휴 CPU를 활용할 수 있습니다. 특히 레이턴시에 민감한 애플리케이션이나 버스트 트래픽을 처리하는 서비스는 CPU limits로 인한 불필요한 throttling이 성능 저하를 유발할 수 있어 limits를 설정하지 않는 것이 권장됩니다. 대신 requests를 적절히 설정하여 QoS를 Burstable로 유지하고, LimitRange나 ResourceQuota로 클러스터 레벨에서 제어하는 것이 좋습니다.
- • CPU limits는 CFS quota로 구현되며 초과 시 throttling 발생
- • CPU는 압축 가능한 리소스로 limits 없이도 requests만으로 관리 가능
- • 레이턴시 민감 애플리케이션은 limits 제거로 throttling 회피 권장
고성능 API 서버나 실시간 데이터 처리 서비스에서 CPU throttling으로 인한 레이턴시 증가 문제를 해결할 때 CPU limits 제거를 고려합니다.
Memory limits와 CPU limits의 동작이 다른 이유는 무엇이며, Memory limits를 초과하면 어떤 일이 발생하나요?
Q. Kubernetes의 Node Affinity, Pod Affinity, Pod Anti-Affinity의 차이점을 설명하고, requiredDuringSchedulingIgnoredDuringExecution과 preferredDuringSchedulingIgnoredDuringExecution의 차이는 무엇인가요?
각 Affinity가 대상으로 하는 것과 스케줄링 시 강제성의 차이를 생각해보세요.
Node Affinity는 Pod를 특정 노드 레이블 조건에 맞는 노드에 스케줄링하며, 하드웨어 요구사항이나 지역 제약을 표현합니다. Pod Affinity는 특정 Pod가 실행 중인 노드와 같은 위치에 Pod를 배치하여 통신 레이턴시를 줄이거나 데이터 지역성을 확보합니다. Pod Anti-Affinity는 특정 Pod와 다른 노드에 배치하여 고가용성을 확보하거나 리소스 경합을 방지합니다. requiredDuringScheduling은 조건을 만족하지 않으면 Pod가 스케줄링되지 않는 하드 제약이고, preferredDuringScheduling은 가능하면 조건을 만족하려 하지만 불가능해도 스케줄링되는 소프트 제약입니다. IgnoredDuringExecution은 실행 중인 Pod에는 적용되지 않는다는 의미입니다.
- • Node Affinity는 노드 선택, Pod Affinity는 Pod 간 근접 배치, Anti-Affinity는 분산 배치
- • required는 하드 제약으로 필수 조건, preferred는 소프트 제약으로 선호 조건
- • IgnoredDuringExecution은 실행 중인 Pod에는 재평가하지 않음
멀티 AZ 환경에서 데이터베이스 Primary와 Replica를 다른 AZ에 배치하거나, 캐시 서버와 애플리케이션 서버를 같은 노드에 배치하여 네트워크 레이턴시를 최소화할 때 사용합니다.
topologyKey의 역할은 무엇이며, kubernetes.io/hostname과 topology.kubernetes.io/zone을 사용할 때의 차이는 무엇인가요?
Q. Kubernetes의 ServiceAccount, Role, RoleBinding, ClusterRole, ClusterRoleBinding의 관계를 설명하고, 네임스페이스 범위의 권한과 클러스터 범위의 권한을 구분하는 기준을 설명해주세요.
RBAC의 주체, 권한, 바인딩 개념과 리소스의 네임스페이스 속성을 생각해보세요.
ServiceAccount는 Pod가 Kubernetes API에 접근할 때 사용하는 인증 주체입니다. Role은 특정 네임스페이스 내에서 리소스에 대한 권한 집합을 정의하고, ClusterRole은 클러스터 전체 또는 네임스페이스를 넘나드는 권한을 정의합니다. RoleBinding은 Role을 ServiceAccount나 User에게 특정 네임스페이스 내에서 부여하고, ClusterRoleBinding은 ClusterRole을 클러스터 전체에 부여합니다. Node, PersistentVolume, Namespace 같은 클러스터 스코프 리소스는 ClusterRole로만 관리할 수 있습니다. RoleBinding으로 ClusterRole을 바인딩하면 해당 네임스페이스 내에서만 권한이 적용되는 패턴도 가능합니다.
- • ServiceAccount는 인증 주체, Role/ClusterRole은 권한 정의, Binding은 연결
- • Role/RoleBinding은 네임스페이스 범위, ClusterRole/ClusterRoleBinding은 클러스터 범위
- • 클러스터 스코프 리소스는 ClusterRole로만 관리 가능
마이크로서비스에서 각 애플리케이션이 필요한 최소 권한만 갖도록 ServiceAccount와 Role을 분리 설정하여 보안을 강화합니다.
Pod Security Admission과 RBAC의 차이점은 무엇이며, 어떻게 조합하여 사용해야 하나요?
Q. Kubernetes에서 ConfigMap과 Secret을 Volume으로 마운트했을 때와 환경변수로 주입했을 때의 차이점을 설명하고, ConfigMap 업데이트 시 각각의 경우 애플리케이션에 어떻게 반영되는지 설명해주세요.
Volume 마운트 시 kubelet의 동기화 동작과 환경변수의 프로세스 생명주기를 고려해보세요.
Volume으로 마운트하면 ConfigMap이 파일 시스템에 디렉토리 형태로 노출되고, 환경변수로 주입하면 프로세스의 환경변수로 설정됩니다. Volume 마운트의 경우 ConfigMap이 업데이트되면 kubelet이 주기적으로(기본 60초) 동기화하여 마운트된 파일 내용이 자동으로 갱신되지만, 애플리케이션이 파일 변경을 감지하고 리로드하는 로직이 필요합니다. 환경변수는 프로세스 시작 시점에 고정되므로 ConfigMap이 업데이트되어도 Pod를 재시작하기 전까지 반영되지 않습니다. Secret도 동일한 방식으로 동작하며, 민감 정보는 Volume 마운트 시 tmpfs에 저장되어 디스크에 기록되지 않습니다.
- • Volume 마운트는 파일로 노출되고 업데이트 시 자동 동기화됨
- • 환경변수는 프로세스 시작 시 고정되어 업데이트 반영 안 됨
- • Volume 마운트도 애플리케이션의 리로드 로직 필요
설정 파일이 자주 변경되는 애플리케이션은 Volume 마운트와 파일 감시를 통해 무중단 설정 변경을 구현하고, 환경변수는 배포 시점에 고정되는 값에 사용합니다.
immutable ConfigMap/Secret을 사용하면 어떤 이점이 있으며, 어떤 상황에서 사용해야 하나요?
Q. Kubernetes Deployment의 RollingUpdate 전략에서 maxSurge와 maxUnavailable 설정이 배포 속도와 리소스 사용량에 미치는 영향을 설명하고, Blue-Green 배포와 Canary 배포를 Kubernetes에서 구현하는 방법을 설명해주세요.
RollingUpdate의 파라미터가 동시에 생성/삭제되는 Pod 수를 어떻게 제어하는지, 그리고 Service 라우팅을 어떻게 활용하는지 생각해보세요.
maxSurge는 desired replica 수를 초과하여 생성할 수 있는 Pod 수를 정의하고, maxUnavailable은 업데이트 중 사용 불가능한 Pod 수를 정의합니다. maxSurge를 크게 설정하면 새 버전 Pod가 빠르게 생성되어 배포 속도가 빠르지만 일시적으로 리소스 사용량이 증가합니다. maxUnavailable을 크게 설정하면 기존 Pod를 빠르게 종료하여 리소스를 절약하지만 가용 Pod 수가 줄어들어 트래픽 처리 능력이 감소합니다. Blue-Green 배포는 새 버전을 별도 Deployment로 배포하고 Service selector를 전환하여 즉시 전환합니다. Canary 배포는 새 버전 Deployment를 소수 replica로 생성하고 Service가 양쪽을 모두 라우팅하도록 하여 점진적으로 트래픽을 이동시키며, Istio나 Argo Rollouts 같은 도구로 트래픽 비율을 정밀하게 제어할 수 있습니다.
- • maxSurge는 추가 Pod 수, maxUnavailable은 사용 불가 Pod 수 제어
- • Blue-Green은 Service selector 전환으로 즉시 전환
- • Canary는 새 버전을 소수 배포하고 점진적으로 트래픽 증가
프로덕션 배포 시 리소스 여유가 있다면 maxSurge를 높여 빠른 배포를 하고, 리소스가 제한적이면 maxUnavailable을 조절하여 안정적으로 배포합니다.
Recreate 전략은 언제 사용해야 하며, RollingUpdate와 비교했을 때의 장단점은 무엇인가요?
Q. Kubernetes의 Liveness Probe, Readiness Probe, Startup Probe의 차이점과 각각의 용도를 설명하고, 잘못 설정했을 때 발생할 수 있는 문제를 설명해주세요.
각 Probe가 실패했을 때 kubelet이 취하는 조치와 Service 엔드포인트 관리를 생각해보세요.
Liveness Probe는 컨테이너가 살아있는지 확인하며 실패 시 kubelet이 컨테이너를 재시작합니다. Readiness Probe는 컨테이너가 트래픽을 받을 준비가 되었는지 확인하며 실패 시 Service의 엔드포인트에서 제외되지만 재시작하지 않습니다. Startup Probe는 초기 시작이 느린 애플리케이션을 위해 시작 완료를 확인하며, 성공 전까지 Liveness/Readiness Probe가 실행되지 않습니다. Liveness Probe를 너무 공격적으로 설정하면 일시적인 부하로 인해 정상 Pod가 반복적으로 재시작되는 CrashLoopBackOff가 발생할 수 있습니다. Readiness Probe가 없으면 초기화되지 않은 Pod로 트래픽이 전달되어 에러가 발생하고, Startup Probe 없이 시작이 느린 애플리케이션은 Liveness Probe 타임아웃으로 계속 재시작될 수 있습니다.
- • Liveness는 재시작 판단, Readiness는 트래픽 수신 준비 판단, Startup은 초기 시작 완료 판단
- • Liveness 실패 시 재시작, Readiness 실패 시 엔드포인트 제외
- • 잘못된 설정은 불필요한 재시작이나 트래픽 에러 유발
Spring Boot 애플리케이션에서 시작 시간이 긴 경우 Startup Probe로 초기화를 보호하고, Readiness Probe로 의존성 연결 상태를 확인하여 안정적인 트래픽 라우팅을 구현합니다.
Probe의 httpGet, tcpSocket, exec 방식 중 어떤 것을 선택해야 하며, 각각의 장단점은 무엇인가요?
Q. Kubernetes의 StorageClass에서 volumeBindingMode의 Immediate와 WaitForFirstConsumer의 차이를 설명하고, 멀티 AZ 환경에서 WaitForFirstConsumer를 사용해야 하는 이유를 설명해주세요.
PV 프로비저닝 시점과 Pod 스케줄링 시점의 관계, 그리고 AZ 간 볼륨 제약을 생각해보세요.
Immediate 모드는 PVC가 생성되는 즉시 PV를 프로비저닝하고 바인딩합니다. WaitForFirstConsumer 모드는 해당 PVC를 사용하는 Pod가 스케줄링될 때까지 PV 프로비저닝을 지연시킵니다. 멀티 AZ 환경에서 Immediate 모드를 사용하면 PV가 특정 AZ에 먼저 생성되고, 나중에 Pod가 다른 AZ에 스케줄링되면 AZ 제약으로 인해 볼륨을 마운트할 수 없어 Pod가 Pending 상태가 됩니다. WaitForFirstConsumer를 사용하면 스케줄러가 Pod의 다른 제약조건(Affinity, 리소스 등)을 고려하여 노드를 선택한 후, 해당 노드와 같은 AZ에 PV를 프로비저닝하므로 볼륨 위치 불일치 문제를 방지할 수 있습니다. AWS EBS나 GCP Persistent Disk 같은 지역 제약이 있는 스토리지에서 특히 중요합니다.
- • Immediate는 PVC 생성 즉시 프로비저닝, WaitForFirstConsumer는 Pod 스케줄링 시점에 프로비저닝
- • 멀티 AZ 환경에서 Immediate는 AZ 불일치로 마운트 실패 가능
- • WaitForFirstConsumer는 Pod 위치를 고려하여 같은 AZ에 볼륨 생성
AWS EKS에서 여러 AZ에 걸쳐 클러스터를 구성할 때 EBS 볼륨 사용 시 WaitForFirstConsumer를 설정하여 Pod와 볼륨이 같은 AZ에 위치하도록 보장합니다.
allowedTopologies를 StorageClass에 설정하면 어떤 효과가 있으며, volumeBindingMode와 어떻게 함께 작동하나요?
Q. Kubernetes의 Deployment, StatefulSet, DaemonSet, Job, CronJob의 차이점과 각각의 사용 사례를 설명해주세요. 특히 StatefulSet과 Deployment의 근본적인 차이는 무엇인가요?
각 워크로드가 관리하는 Pod의 정체성과 생명주기, 그리고 실행 패턴을 생각해보세요.
Deployment는 상태가 없는(stateless) 애플리케이션을 관리하며 Pod가 교체 가능하고 순서 없이 스케일링됩니다. StatefulSet은 상태가 있는(stateful) 애플리케이션을 위해 각 Pod에 안정적인 네트워크 ID와 영구 스토리지를 제공하며 순서대로 생성/삭제됩니다. DaemonSet은 모든 노드(또는 선택된 노드)에 Pod를 하나씩 실행하여 로깅, 모니터링 에이전트 배포에 사용됩니다. Job은 일회성 작업을 실행하고 완료 시 종료되며, CronJob은 스케줄에 따라 주기적으로 Job을 생성합니다. StatefulSet과 Deployment의 근본적 차이는 Pod의 정체성 관리로, StatefulSet은 Pod 이름에 순서 인덱스를 부여하고(web-0, web-1) Headless Service와 함께 안정적인 DNS를 제공하여 각 Pod를 개별적으로 식별할 수 있습니다.
- • Deployment는 stateless, StatefulSet은 stateful 애플리케이션 관리
- • DaemonSet은 노드당 하나, Job은 일회성, CronJob은 주기적 실행
- • StatefulSet은 안정적인 네트워크 ID와 순서 보장 제공
Kafka, Elasticsearch 같은 클러스터형 상태 저장 애플리케이션은 StatefulSet으로, 웹 서버나 API 서버는 Deployment로, 데이터 백업 작업은 CronJob으로 배포합니다.
StatefulSet에서 Parallel Pod Management 정책을 사용하면 어떤 변화가 있으며, 언제 사용해야 하나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!