KR_K8s_Core

쿠버네티스 핵심 개념 (Q1-Q10)

핵심 개념 (1~10번)

Q1. Kubernetes의 주요 구성요소와 Pod 생성 전체 흐름을 설명하세요.

• Control Plane(kube-apiserver, etcd, kube-scheduler, kube-controller-manager)과 Node 컴포넌트(kubelet, kube-proxy, Container Runtime, CoreDNS)로 구성된다.

Pod 생성 흐름:

• kubectl 요청 →
• kube-apiserver가 etcd에 저장 →
• kube-controller-manager가 Pod 리소스 생성 →
• kube-scheduler가 적합한 노드 선택 →
• 해당 노드의 kubelet이 CRI 데몬 호출 →
• 컨테이너 생성 →
• kubelet이 상태를 kube-apiserver에 업데이트 →
• etcd에 최종 상태 저장된다.

Q2. RBAC과 API Group의 관계를 설명하고, ServiceAccount의 동작 원리는?

• RBAC은 API Group(Core Group, Named Group)별로 세밀한 권한 제어를 제공한다.
• Role은 특정 API Group의 리소스에 대한 verbs(get, list, create 등)를 정의하고, RoleBinding으로 ServiceAccount에 할당한다.
• ServiceAccount는 Pod가 API 서버와 통신하기 위한 인증 자격증명으로, Token(JWT), ca.crt(CA 인증서), Namespace를 포함하며, K8s 1.24 이후 자동 토큰 생성이 비활성화되어 명시적 생성이 필요하다.

Q3. Secret 관리 시 보안 강화 방법과 External Secrets Operator의 역할은?

• Secret은 base64 인코딩(암호화 아님)되므로 etcd 암호화 활성화, RBAC 권한 최소화, 필요시에만 Pod 마운트가 필수다.
• External Secrets Operator는 AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager 등 외부 시크릿 저장소와 연동하여 K8s Secret을 동기화하며, 중앙 집중식 관리와 자동 로테이션을 지원한다.

Q4. Service의 ExternalTrafficPolicy와 InternalTrafficPolicy의 차이와 사용 시나리오는?

• ExternalTrafficPolicy는 외부 트래픽 라우팅을 제어한다. Cluster(기본값)는 모든 노드로 분산하지만 소스 IP가 손실되고, Local은 Pod 있는 노드로만 라우팅하여 소스 IP를 유지하지만 불균형이 발생한다.
• InternalTrafficPolicy(K8s 1.22+)는 클러스터 내부 트래픽에 동일한 정책을 적용하며, Local 설정 시 같은 노드 내 Pod로만 트래픽을 보내 네트워크 홉을 줄인다.

Q5. PV Reclaim Policy와 Storage Class의 Volume Binding Mode를 설명하세요.

• Reclaim Policy 는 PVC 삭제 후 PV 처리 방식이다.
• Retain (수동 정리, 데이터 보존), Delete(자동 삭제, 동적 프로비저닝 기본값), Recycle(Deprecated, 기본 삭제 후 재사용).
• Volume Binding Mode 는 Immediate(PVC 생성 즉시 바인딩)와 WaitForFirstConsumer(Pod 스케줄링 후 바인딩, 토폴로지 제약 고려)가 있다.
• WaitForFirstConsumer 는 멀티 AZ 환경에서 Pod와 같은 AZ에 볼륨을 생성하여 성능을 최적화한다.

Q6. HPA의 메트릭 타입과 스케일링 알고리즘을 설명하세요.

• HPA는 Resource Metrics(CPU/Memory), Custom Metrics(Prometheus 등), External Metrics(외부 시스템)을 지원한다.

스케일링 알고리즘:

• desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)].

• stabilizationWindowSeconds로 플래핑 방지, behavior 설정으로 scale up/down 속도 제어, 여러 메트릭 사용 시 가장 큰 replica 수를 선택한다.

• KEDA(Kubernetes Event-Driven Autoscaling)는 이벤트 기반 0→N 스케일링을 지원한다.

Q7. Liveness, Readiness, Startup Probe의 최적 설정 전략은?

• Startup Probe는 느린 시작 애플리케이션용으로 initialDelaySeconds를 길게 설정하며, 성공 전까지 Liveness 비활성화한다.
• Liveness Probe는 애플리케이션 데드락 감지용으로 failureThreshold를 3 이상으로 설정하여 오탐을 방지한다.
• Readiness Probe는 트래픽 수신 준비 확인용으로 즉시 실패 처리(failureThreshold=1)하여 불량 Pod으로 트래픽이 가지 않도록 한다.
• 모든 Probe는 timeoutSeconds를 애플리케이션 응답 시간보다 길게 설정한다.

Q8. Node Affinity의 requiredDuringSchedulingIgnoredDuringExecution vs preferredDuringSchedulingIgnoredDuringExecution의 실무 활용은?

• required는 하드 제약으로 조건 불만족 시 Pod가 Pending 상태로 남는다. GPU 노드, 특정 인스턴스 타입, 규제 준수가 필요한 경우 사용한다.
• preferred는 소프트 제약으로 조건 불만족 시에도 다른 노드에 스케줄되며, weight로 우선순위를 정한다.
• 비용 최적화(Spot 인스턴스 선호), 성능 최적화(SSD 노드 선호), 지역 선호도에 사용한다.
• Pod Anti-Affinity와 함께 사용하여 고가용성을 보장한다.

Q9. Deployment의 RollingUpdate 전략에서 maxUnavailable과 maxSurge의 최적값은?

maxUnavailable은 업데이트 중 사용 불가한 Pod 비율이고, maxSurge는 초과 생성 가능한 Pod 비율이다. 기본값(25%, 25%)은 일반적 상황에 적합하다.

빠른 배포: maxSurge=100%, maxUnavailable=0 (리소스 2배 필요, 무중단). 리소스 제약: maxSurge=0, maxUnavailable=1 (느리지만 추가 리소스 불필요).

• Blue-Green 유사: maxSurge=100%, maxUnavailable=0 후 완료되면 이전 버전 종료.
• Canary: replica 수 조정과 progressDeadlineSeconds로 문제 감지 시 롤백한다.

Q10. Graceful Shutdown에서 preStop Hook과 terminationGracePeriodSeconds의 관계는?

Pod 종료 흐름:

• ① preStop Hook 실행(블로킹) →
• ② SIGTERM 전송 →
• ③ terminationGracePeriodSeconds(기본 30초) 대기 →
• ④ 시간 초과 시 SIGKILL 강제 종료. preStop Hook은 로드밸런서 등록 해제, 진행 중 요청 완료 대기, 연결 정리 등에 사용한다.

preStop 실행 시간도 terminationGracePeriodSeconds에 포함되므로, 전체 정리 시간을 고려하여 60초 이상으로 설정한다. sleep을 추가하여 Endpoint 업데이트 전파 시간을 확보한다.

💡 용어 설명:

• 핵심 개념 질문들(Q1-Q10)에서 사용된 용어들(Control Plane, etcd, RBAC, ServiceAccount, API Group, Secret, ExternalTrafficPolicy, PV/PVC, StorageClass, HPA, VPA, Probe, Node Affinity, RollingUpdate, Graceful Shutdown 등)에 대한
• 상세한 설명은 문서 상단의 주요 용어 통합 정리 각 섹션을 참고하세요.

• ← KR_쿠버네티스.md로 돌아가기