K8s Memory Limits & EKS
Referenced by
정의 (Definition)
이 문서는 Amazon EKS에서 Kubernetes 1.31~1.34로 갈 때, 메모리와 직접적으로 연관된 “지원 여부/기본값/운영 영향이 큰 변경점” 을 한 장으로 비교하는 노트이며, 개별 기능의 상세 원리는 각각의 Atomic Note로 위임합니다.
문제가 되는 배경 (Problem Context)
업스트림 Kubernetes에는 메모리 관련 기능이 존재하지만(E.g., MemoryQoS), 관리형 서비스(EKS)에서는 기능 성숙도/지원 정책 때문에 “있다/없다”가 달라집니다. 이 차이를 모르고 설계를 시작하면, 가정이 깨지는 형태로 운영 장애나 무의미한 튜닝을 하게 됩니다.
핵심 메커니즘 (How it Works)
1) EKS에서 중요한 전제
- 알파 기능은 일반적으로 사용이 어렵다: 제어 plane/feature gate 제약으로 인해, 업스트림에 기능이 있어도 EKS에서 바로 쓰기 어렵습니다.
2) 버전별 핵심 변화 요약
| 구분 | 1.31 | 1.32 | 1.33 | 1.34 |
|---|---|---|---|---|
| MemoryQoS | 알파(기본 off), EKS에서 사용 제약 | 동일 | 동일 | 동일 |
| Memory Manager | (업스트림 기준) 베타 범주 | GA로 안정화 | 유지 | 유지 |
| 노드 OS/CGroups | AL2/AL2023 혼재 가능(환경에 따라 cgroup v2) | AL2 마지막 구간 | AL2023/Bottlerocket 중심 | cgroup v2 운영이 표준화 |
주: 세부 릴리스별 지원/기본값은 EKS 릴리스 노트/AMI 선택 정책에 의해 달라질 수 있습니다. 이 표는 “운영상 영향이 큰 방향성”을 요약합니다.
3) 이 노트가 가리키는 상세 Atomic Notes
- MemoryQoS: K8s MemoryQoS
- Kubelet 메모리 관리 관찰/경계: K8s Kubelet 메모리 관리
- Memory Manager: K8s 메모리 매니저
- QoS/축출: K8s QoS 클래스, K8s 파드 축출(Eviction) 정책
불변 조건과 보장 범위 (Invariants & Guarantees)
- 보장: EKS에서 메모리 운영은 결국 request/limit, QoS, eviction, 노드 OS/cgroup 환경의 조합으로 결정됩니다.
- 비보장: 업스트림 기능이 존재한다고 해서 EKS에서 곧바로 사용 가능하다고 보장할 수는 없습니다.
비유 (Analogy)
업스트림 Kubernetes가 “부품 카탈로그”라면, EKS는 “완제품 구성”입니다. 카탈로그에 있는 부품이 완제품에 항상 포함되어 있는 것은 아닙니다.
실무적 함의 (Operational Implications)
- EKS에서 “메모리 request가 커널 보호로 연결되는지” 같은 가정은 반드시 관찰/지원 여부로 검증해야 합니다.
- 버전 업그레이드 시, 기능보다 먼저 “노드 OS/AMI 변화(cgroup v2, 기본 구성)”가 실제 운영 영향이 큰 경우가 많습니다.
주의사항 / 오해 (Pitfalls & Misconceptions)
- MemoryQoS를 전제로 한 설계는 EKS에서는 성립하지 않을 수 있습니다.
- “CPU는 limit 없어도 된다/메모리는 limit이 필요하다” 같은 규칙은 워크로드 SLO와 트레이드오프 안에서만 의미가 있습니다. (관련: K8s CPU와 메모리 Limit 정책)
References
- Kubernetes Docs: Pod QoS: MemoryQoS with cgroup v2
- Kubernetes Docs: Memory Manager