Kubernetes 리드·아키텍트 트러블슈팅 면접

먼저 문제가 발생하는 노드와 정상 노드의 환경 차이를 비교합니다. uname -a로 커널 버전, crictl version으로 컨테이너 런타임 버전, lscpu로 CPU 아키텍처(amd64/arm64)를 확인합니다. exec format error는 주로 멀티아키텍처 이미지 문제나 잘못된 shebang을 의미하므로 docker manifest inspect로 이미지 매니페스트를 검증합니다. journalctl -u containerd 또는 kubelet 로그에서 런타임 에러를 확인하고, 필요시 strace로 시스템 콜 레벨 디버깅을 수행합니다. seccomp 프로파일이나 AppArmor 정책 차이도 확인하며, 런타임 버전 불일치 시 클러스터 전체의 런타임 표준화 전략을 수립합니다. 재발 방지를 위해 admission webhook으로 이미지 아키텍처 검증과 노드 라벨 기반 스케줄링 정책을 적용합니다.

먼저 CoreDNS 메트릭을 확인하여 요청 레이턴시, 에러율, 캐시 히트율을 분석합니다. kubectl logs로 CoreDNS의 timeout 또는 truncated 응답을 확인하고, 리소스 사용률(CPU/메모리)이 제한에 도달했는지 검증합니다. 노드 레벨에서 conntrack 테이블 고갈 여부를 sysctl net.netfilter.nf_conntrack_count로 확인하고, 필요시 nf_conntrack_max를 증가시킵니다. resolv.conf의 ndots 설정이 5로 높아 불필요한 쿼리가 발생하는지 확인하고, dnsConfig로 ndots를 1-2로 조정합니다. CoreDNS의 HPA 설정과 cache 플러그인 TTL을 최적화하며, NodeLocal DNSCache를 도입하여 DNS 쿼리를 노드 로컬에서 처리하도록 개선합니다. 장기적으로는 DNS 쿼리 패턴을 모니터링하여 불필요한 FQDN 조회를 줄이고, 외부 DNS 의존성을 최소화하는 아키텍처를 설계합니다.

먼저 kubectl describe pod로 정확한 에러 메시지를 확인합니다. 인증 실패인 경우 imagePullSecrets가 올바른 네임스페이스에 존재하는지, Secret 데이터가 base64로 정확히 인코딩되었는지 검증합니다. 문제가 발생하는 노드에서 직접 docker pull 또는 crictl pull로 레지스트리 접근성을 테스트하고, 네트워크 정책이나 방화벽 규칙이 특정 노드만 차단하는지 확인합니다. 레지스트리의 레이트 리미트 또는 동시 연결 제한에 도달했는지 모니터링하며, 대규모 배포 시 이미지 풀 병목을 완화하기 위해 이미지 캐싱 프록시(Harbor, Dragonfly)나 노드별 이미지 사전 배포 전략을 고려합니다. 레지스트리 자체의 스토리지 용량과 성능도 확인하고, 멀티 레지스트리 페일오버 구성을 검토합니다.

먼저 kubectl get networkpolicy --all-namespaces로 적용된 모든 정책을 수집하고, 문제가 발생하는 Pod의 라벨과 일치하는 정책을 필터링합니다. NetworkPolicy는 기본적으로 화이트리스트 방식이므로, Ingress/Egress 규칙이 모두 충족되어야 통신이 허용됩니다. 라벨 셀렉터의 오타나 네임스페이스 불일치를 확인하고, kubectl describe networkpolicy로 정책 상세를 검토합니다. CNI별 진단 도구를 사용하여 실제 적용된 규칙을 확인합니다(Calico는 calicoctl get policy, Cilium은 cilium endpoint list). 패킷 레벨 디버깅을 위해 tcpdump나 Cilium의 Hubble을 사용하여 드롭된 패킷을 추적합니다. 정책 시뮬레이션 도구(Inspektor Gadget, Cilium Policy Editor)로 사전 검증하고, GitOps 기반 정책 관리와 자동화된 정책 테스트를 도입하여 재발을 방지합니다.

kubectl describe pod와 kubectl get events로 정확한 에러 메시지를 확인합니다. VolumeAttachment 오브젝트를 조회하여 볼륨이 노드에 어태치되었는지 상태를 검증하고, kubectl get pv로 PersistentVolume의 상태가 Bound인지 확인합니다. CSI 드라이버의 controller와 node 컴포넌트 로그를 확인하여 프로비저닝 또는 어태치 실패 원인을 파악합니다(kubectl logs -n kube-system). 노드에서 lsblk, mount 명령으로 디바이스가 실제 마운트되었는지, /var/lib/kubelet/pods 아래 볼륨 경로를 확인합니다. 클라우드 프로바이더의 스토리지 백엔드(EBS, Persistent Disk)에서 볼륨 상태와 IOPS 한계, 어태치 제한을 검증합니다. 노드의 IAM 역할이나 서비스 어카운트 권한이 스토리지 조작에 충분한지 확인하고, 필요시 StorageClass 파라미터를 조정하거나 CSI 드라이버를 업그레이드합니다.

먼저 kubectl describe pod로 OOMKilled 이벤트를 확인하고, 종료 직전 메모리 사용량을 Prometheus/Grafana 메트릭에서 조회합니다. 컨테이너 내부에서 메모리 프로파일링 도구(Java는 jmap/jstat, Node.js는 heapdump, Go는 pprof)를 사용하여 힙 메모리 사용 패턴과 누수 여부를 분석합니다. kubectl top pod로 실시간 메모리 사용량을 모니터링하고, VPA의 추천값을 참고하여 실제 필요한 메모리 양을 산정합니다. 메모리 누수가 확인되면 애플리케이션 코드를 수정하고, 누수가 아닌 경우 limit을 단계적으로 증가시키며 테스트합니다. cgroup 메모리 통계(/sys/fs/cgroup/memory)를 확인하여 캐시/버퍼 사용량을 분석하고, 애플리케이션의 메모리 설정(JVM heap size 등)이 컨테이너 limit과 정합성 있게 구성되었는지 검증합니다. 장기적으로는 VerticalPodAutoscaler를 도입하여 자동으로 적절한 리소스를 설정하도록 합니다.

먼저 kubectl get certificate로 Certificate 리소스의 Ready 상태를 확인하고, kubectl describe certificate로 이벤트와 에러 메시지를 조회합니다. CertificateRequest와 Order, Challenge 리소스를 순차적으로 확인하여 ACME 프로토콜의 어느 단계에서 실패했는지 파악합니다. cert-manager의 controller 로그를 확인하여 Let's Encrypt API 호출 실패나 레이트 리미트 도달 여부를 검증합니다. HTTP-01 challenge의 경우 Ingress 규칙이 .well-known/acme-challenge 경로를 올바르게 라우팅하는지, DNS-01 challenge의 경우 DNS 프로바이더 자격증명과 TXT 레코드 생성 권한을 확인합니다. Secret에 저장된 TLS 인증서의 만료일을 확인하고, 갱신 실패 시 ClusterIssuer 설정의 이메일과 ACME 서버 URL이 올바른지 검증합니다. 레이트 리미트 문제는 스테이징 환경으로 테스트하고, 인증서 갱신 주기를 조정하여 해결합니다.

먼저 kubectl describe node로 노드 컨디션(MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable)을 확인하여 리소스 압박 여부를 파악합니다. kubelet 로그(journalctl -u kubelet)에서 API 서버 통신 실패, 인증서 만료, PLEG(Pod Lifecycle Event Generator) 타임아웃 등의 에러를 조회합니다. 노드에 SSH 접속하여 df -h로 디스크 사용률, free -m으로 메모리, top으로 CPU 사용률을 확인하고, 디스크 압박 시 불필요한 컨테이너 이미지와 로그를 정리합니다. 네트워크 파티션 가능성을 확인하기 위해 노드에서 API 서버로 ping과 curl 테스트를 수행하고, iptables 규칙이나 보안 그룹 변경 여부를 점검합니다. kubelet 인증서가 만료되었다면 갱신하고, PLEG 타임아웃은 컨테이너 런타임 응답 지연이 원인이므로 런타임 재시작을 고려합니다. 장기적으로는 노드 모니터링 알람을 강화하고, 디스크 자동 정리 정책과 노드 자동 복구 메커니즘을 구축합니다.

먼저 kubectl get validatingwebhookconfiguration 또는 mutatingwebhookconfiguration으로 Webhook 설정을 확인하고, failurePolicy가 Fail로 설정되어 있어 Webhook 실패 시 모든 요청을 차단하는지 검증합니다. 긴급 복구를 위해 failurePolicy를 Ignore로 변경하거나 Webhook 설정을 삭제하여 클러스터 기능을 우선 복구합니다. Webhook 서비스의 엔드포인트가 정상인지 kubectl get endpoints로 확인하고, Webhook Pod의 로그에서 요청을 받지 못하는지 검증합니다. API 서버에서 Webhook 서비스로의 네트워크 연결을 테스트하고, NetworkPolicy가 kube-system 네임스페이스에서의 접근을 차단하는지 확인합니다. Webhook의 TLS 인증서가 올바르게 설정되었는지, caBundle이 정확한지 검증하고, API 서버 로그에서 TLS handshake 실패를 확인합니다. 재발 방지를 위해 Webhook의 타임아웃을 짧게 설정하고, namespaceSelector로 중요하지 않은 네임스페이스에서 먼저 테스트하며, 모니터링과 알람을 구축합니다.

먼저 kubectl auth can-i create deployments --as=system:serviceaccount:ci:deployer -n target-namespace 명령으로 해당 ServiceAccount의 권한을 직접 테스트합니다. kubectl get rolebinding,clusterrolebinding --all-namespaces로 deployer ServiceAccount에 바인딩된 Role을 찾고, kubectl describe role/clusterrole로 실제 권한 내용을 확인합니다. 최근 변경된 RBAC 리소스를 kubectl get role,rolebinding -o yaml과 Git 이력으로 비교하여 삭제되거나 수정된 권한을 식별합니다. 필요한 최소 권한(deployments, replicasets, pods에 대한 create, update, patch)을 정의하고, 네임스페이스별 Role을 생성하여 RoleBinding으로 연결합니다. ClusterRole을 사용하는 경우 aggregation label을 활용하여 권한을 모듈화하고, 감사 로그를 활성화하여 향후 권한 변경을 추적합니다. 정책 변경 전 테스트 환경에서 검증하고, IaC(Terraform, Helm)로 RBAC 리소스를 관리하여 변경 이력을 명확히 합니다.