Kubernetes v1.34가 Snapshottable API server cache를 Beta 졸업시켜 거의 모든 읽기 요청을 캐시에서 직접 처리 가능하게 전환

Context

Kubernetes API 서버는 리스트 요청으로 인한 높은 메모리 사용량과 etcd 데이터 저장소의 과부하가 오랫동안 안정성과 성능 예측 불가능의 주요 원인이었다. 특히 과거의 resourceVersion에 대한 LIST 요청(페이지네이션)은 반드시 etcd를 직접 쿼리해야 했으며, 이는 API 서버의 메모리 압력을 불가예측적으로 증가시켰다.

Technical Solution

• v1.31 Consistent reads from cache (Beta): watch cache가 최신 데이터의 강한 일관성을 보장하여 필터링된 컬렉션(예: 특정 노드에 바인딩된 Pod 리스트)을 etcd 대신 캐시에서 처리
• v1.33 Streaming encoder (Beta): 다중 기가바이트 응답을 메모리에 버퍼링하지 않고 한 항목씩 스트리밍 전송하여 메모리 스파이크 방지
• v1.34 Snapshottable cache (Beta): 각 업데이트마다 캐시의 지정 시점 스냅샷을 생성하되, 객체 복제 대신 포인터만 저장하는 lazy copy 방식으로 구현
• 과거 resourceVersion에 대한 LIST 요청 처리: API 서버가 해당 스냅샷을 찾아 메모리에서 직접 응답 제공하여 etcd 우회

Impact

Article에는 정량적 성능 수치(퍼센티지, 레이턴시 감소량, 비용 절감)가 명시되지 않음.

Key Takeaway

멀티 릴리스에 걸친 점진적 기능 추가(일관성 읽기 → 스트리밍 전송 → 스냅샷)를 통해 읽기 작업의 리소스 비용을 거의 완전히 예측 가능하게 만들 수 있으며, 이는 데이터 저장소 부하 감소와 제어 평면 안정성 향상으로 이어진다.