Kubernetes 주니어 기술면접
새 면접Q. Kubernetes에서 Service의 타입에는 ClusterIP, NodePort, LoadBalancer가 있습니다. 각 타입의 동작 방식과 사용 시나리오를 설명하고, 실제 프로덕션 환경에서 외부 트래픽을 받는 웹 애플리케이션을 배포할 때 어떤 타입을 선택하는 것이 적절한지 이유와 함께 설명해주세요.
각 Service 타입이 네트워크 접근성과 IP 할당 방식에서 어떤 차이를 가지는지 생각해보세요.
ClusterIP는 클러스터 내부에서만 접근 가능한 기본 타입으로, 마이크로서비스 간 통신에 사용됩니다. NodePort는 모든 노드의 특정 포트를 통해 외부 접근을 허용하며, 포트 범위는 30000-32767입니다. LoadBalancer는 클라우드 제공자의 로드밸런서를 자동으로 프로비저닝하여 외부 IP를 할당받습니다. 프로덕션 웹 애플리케이션의 경우, 클라우드 환경에서는 LoadBalancer 타입을 사용하거나 Ingress 리소스와 ClusterIP를 조합하는 것이 일반적입니다. Ingress를 사용하면 여러 서비스를 단일 진입점으로 관리하고 SSL 종료, 경로 기반 라우팅 등의 고급 기능을 활용할 수 있어 더 효율적입니다.
- • ClusterIP는 내부 통신 전용
- • NodePort는 노드 포트를 통한 외부 접근 제공
- • LoadBalancer는 클라우드 LB 자동 프로비저닝
- • 프로덕션에서는 Ingress + ClusterIP 조합 권장
외부 사용자가 접근하는 API 서버와 내부 데이터베이스 간의 네트워크 구성을 설계할 때 사용됩니다.
Ingress Controller의 역할과 nginx-ingress, traefik 같은 구현체들의 차이점은 무엇인가요?
Q. Kubernetes에서 Pod에 CPU와 메모리 리소스를 할당할 때 requests와 limits의 차이점은 무엇이며, 각각을 어떻게 설정해야 하나요? 또한 requests만 설정하고 limits를 설정하지 않았을 때 발생할 수 있는 문제점을 설명해주세요.
requests는 스케줄링과 관련이 있고, limits는 실행 중 리소스 사용 제한과 관련이 있습니다.
requests는 Pod가 보장받을 최소 리소스 양으로, 스케줄러가 어느 노드에 Pod를 배치할지 결정하는 기준이 됩니다. limits는 Pod가 사용할 수 있는 최대 리소스 양으로, 이를 초과하면 CPU는 throttling되고 메모리는 OOMKilled됩니다. requests는 애플리케이션이 정상 작동하는데 필요한 최소 리소스로 설정하고, limits는 최대 부하 시 사용량을 고려하여 설정합니다. limits를 설정하지 않으면 Pod가 노드의 모든 리소스를 소비하여 다른 Pod에 영향을 줄 수 있으며, 특히 메모리 누수 발생 시 노드 전체가 불안정해질 수 있습니다. 따라서 프로덕션 환경에서는 반드시 둘 다 설정하는 것이 권장됩니다.
- • requests는 스케줄링 기준, limits는 실행 시 제한
- • requests 미만은 보장, limits 초과 시 제한
- • limits 미설정 시 노드 리소스 고갈 위험
- • 둘 다 설정하는 것이 프로덕션 베스트 프랙티스
애플리케이션 성능을 보장하면서도 클러스터 리소스를 효율적으로 활용하기 위한 리소스 할당 계획 수립 시 필수적입니다.
Kubernetes의 QoS 클래스(Guaranteed, Burstable, BestEffort)는 어떻게 결정되며, 리소스 부족 시 어떤 순서로 Pod가 종료되나요?
Q. Kubernetes에서 Pod가 재시작되어도 데이터를 유지해야 하는 상황입니다. Volume, PersistentVolume(PV), PersistentVolumeClaim(PVC)의 개념을 각각 설명하고, 이들이 어떤 관계로 연결되어 동작하는지 설명해주세요.
Volume은 Pod 레벨, PV는 클러스터 레벨 리소스이며, PVC는 사용자의 스토리지 요청입니다.
Volume은 Pod 내 컨테이너들이 공유할 수 있는 디렉토리로, emptyDir 같은 임시 볼륨은 Pod 삭제 시 함께 사라집니다. PersistentVolume은 관리자가 프로비저닝하거나 StorageClass를 통해 동적으로 생성되는 클러스터 레벨의 스토리지 리소스입니다. PersistentVolumeClaim은 사용자가 필요한 스토리지 용량과 접근 모드를 명시하여 PV를 요청하는 리소스입니다. 동작 흐름은 사용자가 PVC를 생성하면 Kubernetes가 조건에 맞는 PV를 바인딩하고, Pod는 PVC를 Volume으로 마운트하여 사용합니다. 이를 통해 Pod가 재시작되거나 다른 노드로 이동해도 동일한 데이터에 접근할 수 있습니다.
- • Volume은 Pod 내 스토리지 추상화
- • PV는 클러스터 레벨의 실제 스토리지 리소스
- • PVC는 사용자의 스토리지 요청
- • PVC-PV 바인딩을 통해 Pod에서 영구 스토리지 사용
데이터베이스나 파일 업로드 서비스처럼 데이터 영속성이 필요한 stateful 애플리케이션을 Kubernetes에 배포할 때 사용됩니다.
ReadWriteOnce, ReadOnlyMany, ReadWriteMany 접근 모드의 차이점과 각각 어떤 상황에서 사용되나요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!