> For the complete documentation index, see [llms.txt](https://atomoh.gitbook.io/kubernetes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atomoh.gitbook.io/kubernetes/quiz/operations-guide/10-resource-optimization-quiz.md).
# 리소스 최적화 퀴즈
> **관련 문서**: [리소스 최적화](/kubernetes/operations-guide/ops/10-resource-optimization.md)
## 객관식 문제
### 1. Kubernetes QoS 클래스 중 Guaranteed 클래스의 조건은 무엇인가요?
* A) requests만 설정
* B) limits만 설정
* C) requests와 limits가 동일하게 설정
* D) 아무 설정도 하지 않음
정답 보기
**정답: C) requests와 limits가 동일하게 설정**
**설명:** Guaranteed QoS는 CPU와 메모리 모두 requests와 limits가 동일하게 설정된 경우 부여됩니다. 이 클래스의 Pod는 노드 리소스 부족 시 가장 나중에 eviction 대상이 되어 가장 안정적으로 실행됩니다. 중요한 워크로드에 권장됩니다.
### 2. JVM 애플리케이션에서 컨테이너 메모리에 맞게 힙 크기를 자동 조정하는 옵션은 무엇인가요?
* A) -Xmx 고정값 설정
* B) -XX:MaxRAMPercentage
* C) -XX:+UseSerialGC
* D) -Xms 고정값 설정
정답 보기
**정답: B) -XX:MaxRAMPercentage**
**설명:** -XX:MaxRAMPercentage는 JVM이 컨테이너 메모리 limit의 지정된 비율만큼 힙을 할당하도록 합니다. 예: `-XX:MaxRAMPercentage=75.0`은 메모리 limit의 75%를 최대 힙으로 설정합니다. 이를 통해 컨테이너 크기가 변경되어도 자동으로 적절한 힙 크기가 설정됩니다.
### 3. CPU Throttling이 발생하는 주된 원인은 무엇인가요?
* A) 메모리 부족
* B) CPU requests 초과 사용
* C) CPU limits 도달로 인한 CFS 스케줄러 제한
* D) 디스크 I/O 병목
정답 보기
**정답: C) CPU limits 도달로 인한 CFS 스케줄러 제한**
**설명:** CPU Throttling은 컨테이너가 설정된 CPU limit에 도달했을 때 Linux CFS(Completely Fair Scheduler)가 CPU 시간을 제한하여 발생합니다. Throttling이 발생하면 애플리케이션 지연이 증가합니다. limit 증가 또는 limit 제거를 고려할 수 있습니다.
### 4. Go 애플리케이션에서 컨테이너 CPU limit에 맞게 GOMAXPROCS를 자동 설정하는 방법은 무엇인가요?
* A) 환경변수 수동 설정
* B) go.uber.org/automaxprocs 라이브러리 사용
* C) runtime.GOMAXPROCS() 직접 호출
* D) Kubernetes annotation 사용
정답 보기
**정답: B) go.uber.org/automaxprocs 라이브러리 사용**
**설명:** automaxprocs 라이브러리는 import만 하면 자동으로 컨테이너의 CPU limit을 감지하여 GOMAXPROCS를 설정합니다. `import _ "go.uber.org/automaxprocs"`를 추가하면 됩니다. 이를 통해 CPU limit이 1.5인 경우 GOMAXPROCS가 2로 설정되어 적절한 동시성을 유지합니다.
### 5. BestEffort QoS 클래스의 Pod는 언제 가장 먼저 eviction 대상이 되나요?
* A) CPU 사용량이 높을 때
* B) 노드의 메모리가 부족할 때
* C) 디스크가 부족할 때
* D) 네트워크 문제 발생 시
정답 보기
**정답: B) 노드의 메모리가 부족할 때**
**설명:** BestEffort QoS(requests/limits 미설정)의 Pod는 노드에 메모리 압박이 발생하면 가장 먼저 eviction 대상이 됩니다. Guaranteed > Burstable > BestEffort 순서로 보호됩니다. 중요한 워크로드는 최소한 requests를 설정해야 합니다.
### 6. GOMEMLIMIT 환경변수의 역할은 무엇인가요?
* A) 최대 고루틴 수 제한
* B) Go 런타임의 메모리 사용량 제한 힌트 제공
* C) GC 비활성화
* D) 스택 크기 제한
정답 보기
**정답: B) Go 런타임의 메모리 사용량 제한 힌트 제공**
**설명:** GOMEMLIMIT(Go 1.19+)은 Go 런타임에 메모리 사용량 목표를 알려줍니다. GC는 이 limit을 초과하지 않도록 더 적극적으로 수집합니다. 컨테이너 메모리 limit의 80-90% 정도로 설정하면 OOM을 방지하면서 메모리를 효율적으로 사용할 수 있습니다.
### 7. 컨테이너 리소스 설정에서 requests와 limits의 차이점은 무엇인가요?
* A) requests는 최대값, limits는 최소값
* B) requests는 스케줄링 기준, limits는 런타임 제한
* C) 둘은 동일한 역할
* D) requests만 강제 적용됨
정답 보기
**정답: B) requests는 스케줄링 기준, limits는 런타임 제한**
**설명:** requests는 Pod가 스케줄링될 때 노드에 필요한 최소 리소스를 나타냅니다. limits는 Pod가 사용할 수 있는 최대 리소스입니다. 스케줄러는 requests 기준으로 노드를 선택하고, kubelet은 limits를 초과하지 않도록 제한합니다.
### 8. LimitRange 리소스의 주요 용도는 무엇인가요?
* A) 클러스터 전체 리소스 제한
* B) 네임스페이스 내 Pod/Container의 기본 리소스 설정 및 제한
* C) 노드 리소스 관리
* D) 네트워크 대역폭 제한
정답 보기
**정답: B) 네임스페이스 내 Pod/Container의 기본 리소스 설정 및 제한**
**설명:** LimitRange는 네임스페이스 레벨에서 Pod/Container의 기본 requests/limits, 최소/최대 값, request-to-limit 비율 등을 설정합니다. 리소스 설정이 없는 Pod에 기본값을 적용하거나, 너무 큰 리소스 요청을 방지할 수 있습니다.
### 9. ResourceQuota와 LimitRange의 차이점은 무엇인가요?
* A) 동일한 기능
* B) ResourceQuota는 네임스페이스 총량 제한, LimitRange는 개별 Pod/Container 제한
* C) ResourceQuota만 CPU 제한 가능
* D) LimitRange만 메모리 제한 가능
정답 보기
**정답: B) ResourceQuota는 네임스페이스 총량 제한, LimitRange는 개별 Pod/Container 제한**
**설명:** ResourceQuota는 네임스페이스 내 전체 리소스 사용량(총 CPU, 메모리, Pod 수 등)을 제한합니다. LimitRange는 개별 Pod나 Container의 리소스 범위와 기본값을 설정합니다. 둘을 함께 사용하여 효과적인 리소스 거버넌스를 구현합니다.
### 10. 컨테이너에서 CPU limit을 설정하지 않는 전략의 장단점은 무엇인가요?
* A) 장점: 스로틀링 방지, 단점: 노이지 네이버 문제 가능성
* B) 장점: 메모리 절약, 단점: 성능 저하
* C) 장점: 자동 스케일링, 단점: 비용 증가
* D) 장점: 보안 강화, 단점: 복잡성 증가
정답 보기
**정답: A) 장점: 스로틀링 방지, 단점: 노이지 네이버 문제 가능성**
**설명:** CPU limit을 설정하지 않으면 버스트 트래픽 시 스로틀링 없이 CPU를 사용할 수 있습니다. 하지만 다른 Pod에 영향을 줄 수 있는 "노이지 네이버" 문제가 발생할 수 있습니다. requests는 반드시 설정하고, 워크로드 특성에 따라 limit 설정 여부를 결정합니다.