Rocky Linux 9로 Kubernetes 구축, 1~2년 안에 레거시가 되지 않을까요? 커널 요구사항 기준으로 고민 중입니다

혼자 집에서 Kubernetes 클러스터 구성 관련해서 공부하다가 궁금한 점이 생겨 글 남깁니다.

한국에서는 전통적으로 프로덕션 서버 환경에 RHEL 계열 OS를 많이 사용하다 보니, Kubernetes를 도입할 때도 Rocky Linux 같은 RHEL 호환 배포판을 그대로 가져가는 경우가 많을 것 같다는 생각이 들었습니다.
반면 해외, 특히 대형 클라우드나 글로벌 Kubernetes 환경을 보면 Ubuntu 계열이 사실상 표준처럼 많이 쓰이고 있는 흐름도 보이더라고요.

최근 Linux 서버 시장 자료를 봐도 Ubuntu 계열이 단일 배포판 기준으로 가장 높은 사용 비중을 차지하고 있는 것으로 나오고 있고
(참고: https://commandlinux.com/statistics/linux-server-market-share/)
Rocky Linux는 RHEL 호환 생태계 안에 포함되어 집계되는 구조라 개별 배포판 기준으로는 아직 점유율이 크지 않은 상황으로 보입니다.

공부하면서 가장 궁금해진 부분은 커널 버전과 Kubernetes의 발전 방향이었습니다.

Kubernetes 공식 문서를 보면 점점 더 많은 기능들이 최신 Linux 커널 기능을 전제로 추가되고 있고, 단순히 보안 패치를 백포트하는 방식으로는 따라가기 어려운 영역이 계속 늘어나는 것처럼 보였습니다.
(공식 커널 요구사항: https://kubernetes.io/docs/reference/node/kernel-version-requirements/)

이미 cgroup v1은 유지 관리 모드로 전환되고 cgroup v2 사용이 권장되고 있고, 안정성과 기능 완성도도 Linux 5.8 이상 커널을 기준으로 개선되고 있습니다. runc 역시 5.2 미만 커널은 권장하지 않는 상태이고요.
PSI, recursive read-only mount, pod user namespace, swap 제어 등도 모두 비교적 최신 커널 기능을 전제로 발전하고 있는 흐름으로 보입니다.

이런 내용을 보다 보니 Kubernetes가 더 이상 “구형 엔터프라이즈 커널에 백포트로 맞춰 쓰는 플랫폼”이 아니라, 실제 Linux 커널 발전 속도에 맞춰 같이 진화하는 구조로 가고 있다는 느낌을 받았습니다.

그런데 Rocky Linux 9는 커널 5.14 기반이고, RHEL 계열 특성상 앞으로도 메이저 커널 업그레이드보다는 보안 위주의 백포트 모델을 유지하게 될 것 같은데, 현재 시점에서도 이미 최신 커널 대비 몇 세대 정도 차이가 나는 상태라 향후 Kubernetes 기능 요구 속도를 따라가기 괜찮을지 조금 걱정이 되더라고요.

반대로 Ubuntu 24.04는 6.x 최신 커널 라인을 기반으로 계속 커널 업데이트가 이루어지고 있고, 실제 Kubernetes와 클라우드 네이티브 환경에서도 가장 많이 쓰이는 OS 흐름이라는 점에서 장기적인 호환성과 안정성 측면에서는 더 유리해 보였습니다.

그래서 개인적으로는 Rocky 9가 지금 당장은 Kubernetes 운영이 가능하더라도, 커널 요구사항이 계속 높아지는 상황에서 1~2년 뒤 다시 제약이 생기지는 않을지 궁금해졌고,
처음부터 Ubuntu 24.04 같은 최신 커널 기반 환경으로 가는 게 더 현실적인 선택이 아닐까 하는 생각도 들었습니다.

특히 이게 Cilium 같은 eBPF 네트워킹만의 문제가 아니라 Kubernetes 자체 기능 발전 방향과도 연결된 문제처럼 보여서 더 고민이 됩니다.

혹시 실제 프로덕션에서 Rocky 9 기반으로 Kubernetes를 운영해보신 분들이 계시다면 장기적으로 느끼신 한계나 문제점이 있었는지 궁금합니다.
또는 Ubuntu 계열로 운영하면서 체감하신 안정성이나 운영 편의성 차이도 공유해주시면 감사하겠습니다.

감사합니다.

1 Like

K8s 발전이 매우 빠르긴 하죠.

다만 오픈소스 쿠버네티스를 바로 사용하지 않는 한국의 상황도 고려하실 필요는 있습니다.

엔터프라이즈 급에서는 오픈소스보다 상용을 더 많이 고려하는 편이니까요.

즉, 상용제품의 특성상 공개된 K8s보다 늦게 업데이트 하거나 아예 늦추고 자체 개발한 툴들로 보완하는 경향이니 참고하시면 좋겠네요.

실제로 구글을 제외하고 K8s를 항상 최신버전으로 Production 환경에 적용하는 상용 K8s는 없습니다.

공부를 하신다면 두가지 상황을 다 고려해서 구축 및 테스트 해보시는 것이 더 좋겠네요.

1 Like

답변 감사합니다. 말씀해주신 것처럼 국내 엔터프라이즈 환경에서 상용 Kubernetes를 도입하고, 최신 버전을 바로 프로덕션에 적용하지 않는 경우가 많다는 점은 충분히 공감합니다. 실제로 OpenShift나 Tanzu 같은 상용 배포판들도 업스트림 Kubernetes보다 보수적으로 릴리즈를 가져가는 것이 사실이니까요.

다만 “구글을 제외하고는 항상 최신 버전을 프로덕션에 적용하는 상용 K8s는 없다”는 부분은 조금 일반화된 표현이 아닐까 생각했습니다. 최근 CNCF 설문이나 글로벌 SaaS 기업 사례를 보면, managed Kubernetes(EKS/GKE/AKS 등)를 기반으로 N 또는 N-1 수준을 유지하는 운영 사례도 적지 않기 때문입니다. 전통 엔터프라이즈와 클라우드 네이티브 기업 간의 운영 전략 차이로 보는 것이 더 정확하지 않을까 싶습니다.

또한 커널 측면에서도 최근 Kubernetes 공식 문서에서 cgroup v2, PSI, user namespace 등 비교적 최신 커널 기능을 전제로 한 요구사항이 점점 늘어나고 있는 점을 보면, 단순한 보안 패치 백포트만으로는 장기적으로 한계가 생길 가능성도 있어 보여 이 부분이 특히 궁금했습니다.

좋은 의견 주셔서 감사드리고, 말씀해주신 “두 가지 상황을 모두 고려해 테스트해보라”는 조언은 참고해서 직접 비교해보겠습니다.

1 Like