Kubernetes 리드·아키텍트 성능 최적화 면접

먼저 kubectl 명령어 응답 시간과 API Server 메트릭(apiserver_request_duration_seconds)을 확인하여 API Server 병목을 진단합니다. etcd의 디스크 I/O 지연(etcd_disk_backend_commit_duration_seconds)과 리더 선출 상태를 점검하고, Scheduler의 스케줄링 큐 대기 시간(scheduler_pending_pods, scheduler_scheduling_duration_seconds)을 분석합니다. Control Plane 노드의 CPU/메모리 사용률과 네트워크 지연을 확인하며, API Server의 rate limiting 설정과 audit logging 부하도 검토합니다. 대규모 클러스터에서는 etcd 데이터베이스 크기와 compaction 상태, API Server의 watch connection 수도 중요한 지표입니다. 마지막으로 kubelet 로그에서 이미지 pull 시간과 CNI 플러그인 초기화 시간을 확인하여 데이터 플레인 문제도 배제합니다.

먼저 Vertical Pod Autoscaler의 권장 사항과 실제 리소스 사용률(container_memory_working_set_bytes, container_cpu_usage_seconds_total)을 분석하여 과다 프로비저닝된 워크로드를 식별합니다. Prometheus와 Kubecost를 활용해 네임스페이스/팀별 비용을 가시화하고, 리소스 효율성이 낮은 상위 20% 워크로드를 우선 타겟팅합니다. Spot/Preemptible 인스턴스 활용을 위해 워크로드를 stateless/stateful, critical/non-critical로 분류하고, Pod Disruption Budget과 함께 적용합니다. 클러스터 오토스케일러 설정을 최적화하고, 노드 bin-packing 효율을 높이기 위해 다양한 인스턴스 타입을 혼합 사용합니다. 장기적으로는 멀티 클러스터 전략으로 개발/스테이징 환경을 축소하고, 야간/주말에 자동 스케일 다운하는 정책을 적용하며, Reserved Instance 구매 전략을 수립합니다.

먼저 Service Mesh의 프록시 메트릭(envoy_cluster_upstream_rq_time, response_latency_ms_bucket)을 확인하여 사이드카 오버헤드와 서비스별 응답 시간을 분석합니다. Jaeger나 Zipkin 같은 분산 트레이싱으로 엔드투엔드 요청 경로를 추적하여 지연이 발생하는 특정 구간을 식별합니다. CNI 플러그인(Calico, Cilium)의 네트워크 정책 평가 오버헤드와 iptables 규칙 수를 점검하고, 노드 간 네트워크 대역폭과 패킷 드롭을 확인합니다. Service Mesh 설정에서 circuit breaker, retry policy, timeout 값을 검토하여 연쇄 장애를 방지하고, 필요시 gRPC나 HTTP/2 keep-alive 설정을 최적화합니다. 성능 개선을 위해 locality-aware routing으로 같은 AZ 내 통신을 우선하고, 핫 패스에는 sidecar를 우회하는 헤드리스 서비스를 고려합니다.

먼저 fio나 dd 같은 도구로 PV의 실제 IOPS와 처리량을 측정하고, 클라우드 프로바이더의 볼륨 메트릭(EBS IOPS, Disk throughput)과 비교합니다. Pod의 I/O 패턴(순차/랜덤, 읽기/쓰기 비율)을 프로파일링하여 워크로드 특성에 맞는 스토리지 클래스를 선택합니다. 데이터베이스에는 provisioned IOPS SSD(io2), 로그 수집에는 throughput optimized HDD(st1)처럼 용도별로 차등 적용합니다. Local PV를 활용하여 네트워크 오버헤드를 제거하거나, CSI 드라이버의 볼륨 확장 기능으로 용량과 성능을 동적 조정합니다. 애플리케이션 레벨에서는 write-ahead log 최적화, 배치 쓰기, 메모리 캐싱을 적용하고, 읽기 부하가 높으면 ReadWriteMany 볼륨과 읽기 전용 레플리카를 활용합니다.

HPA는 CPU/메모리 메트릭과 커스텀 메트릭(Prometheus Adapter로 RPS, 큐 길이)을 기반으로 Pod 수를 조정하며, stabilization window를 설정하여 급격한 스케일링을 방지합니다. 이벤트 전 미리 minReplicas를 상향 조정하여 초기 부하에 대응하고, targetAverageUtilization은 70% 수준으로 설정하여 버퍼를 확보합니다. VPA는 장기 실행 서비스의 리소스 요청을 자동 조정하되, HPA와 동시 사용 시 충돌을 피하기 위해 updateMode를 Initial이나 Off로 설정합니다. Cluster Autoscaler는 pending pod 발생 시 노드를 추가하며, expander 전략을 priority로 설정하여 Spot 인스턴스를 우선 사용하고, scale-down-delay를 충분히 두어(10분) 불필요한 노드 재생성을 방지합니다. 사전에 Cluster Autoscaler의 max-node-provision-time을 단축하기 위해 노드 이미지를 미리 준비하고, Pod Disruption Budget으로 안정성을 보장합니다.

StatefulSet으로 Redis Cluster를 구성하여 샤딩과 복제를 통해 처리량과 가용성을 확보하고, Anti-Affinity 규칙으로 Pod를 다른 노드에 분산 배치합니다. 캐시 적중률을 높이기 위해 핫 데이터를 식별하고 TTL을 워크로드 특성에 맞게 차등 설정하며, 캐시 워밍 전략으로 배포 직후 미스율 급증을 방지합니다. Redis Sentinel이나 Operator를 활용하여 자동 장애 조치를 구성하고, 읽기 부하가 높으면 읽기 전용 레플리카를 추가합니다. 네트워크 지연을 줄이기 위해 애플리케이션과 캐시를 같은 네임스페이스나 노드에 배치하고, 연결 풀링과 파이프라이닝을 적용합니다. 메트릭(hit rate, eviction count, latency)을 모니터링하여 메모리 부족 시 maxmemory-policy를 조정하거나 스케일 아웃하며, 캐시 무효화 전략을 명확히 정의합니다.

API Server를 다중 인스턴스로 수평 확장하고 로드밸런서로 분산하며, 각 인스턴스의 rate limiting(--max-requests-inflight, --max-mutating-requests-inflight)을 조정하여 과부하를 방지합니다. etcd 클러스터를 전용 고성능 SSD 볼륨에 배치하고, 정기적인 compaction과 defragmentation으로 데이터베이스 크기를 관리하며, snapshot을 외부 스토리지에 백업합니다. API Server의 watch connection 수를 줄이기 위해 informer의 resync period를 늘리고, 불필요한 리소스 감시를 제거합니다. Audit logging을 최소화하거나 비동기로 외부 시스템에 전송하여 I/O 부하를 줄이고, API priority and fairness 기능으로 중요한 요청에 우선순위를 부여합니다. 장기적으로는 멀티 클러스터 아키텍처로 워크로드를 분산하거나, API Server를 shard하여 특정 네임스페이스나 리소스 타입별로 전담 인스�ン스를 운영하는 전략도 고려합니다.