운영 환경에서 반복되는 YAML 문법 오류, etcd 기반의 높은 자원 요구량, Helm 사용 시 발생하는 템플릿 충돌과 패키징의 복잡성은 대표적인 예입니다. 이로 인해 실무자들은 “쿠버네티스가 강력하긴 하나, 진입장벽도 높고 유지보수에 부담이 크다”는 인식을 갖게 되었습니다.
YAML을 넘어서는 선언형 언어의 필요 HCL 도입 논의
HCL은 타입이 명확하고 유효성 검사가 내장되어 있어 오류 발생 가능성을 낮춰줍니다. 또한 반복문, 조건문, 함수 사용이 가능해 선언형 구성을 더 유연하게 표현할 수 있습니다. 향후 쿠버네티스 2.0에서는 YAML을 보완하거나 대체할 언어로 HCL 혹은 이에 상응하는 새로운 DSL이 등장할 가능성이 있습니다.
etcd 중심 구조에서 플러그형 저장소로
현재 쿠버네티스는 상태 정보를 etcd에 저장합니다. 이는 신뢰성과 일관성 측면에서는 장점이지만, 경량 환경이나 에지 디바이스에서는 지나치게 무거운 구성이라는 비판도 존재합니다. 이에 대한 해결책으로 SQLite 기반의 k8s-dqlite나 다양한 DB를 지원하는 Kine 같은 플러그형 스토리지가 부상하고 있습니다.
이러한 저장소 유연화는 소형 클러스터나 테스트 환경에서 쿠버네티스를 보다 효율적으로 운영할 수 있는 기반을 제공합니다. 특히 다중 저장소 백엔드를 선택할 수 있는 구조는 인프라 설계의 자유도를 높여주고, 장애 대응 시 리스크 분산에도 기여할 수 있습니다.
Helm의 다음 단계, 선언형 패키징 도구 'KubePkg'
Helm은 쿠버네티스에서 가장 많이 쓰이는 패키지 매니저이지만, 템플릿 언어의 복잡성과 배포 불안정성은 지속적인 문제였습니다. 이를 해결하기 위해 'KubePkg'라는 새로운 형태의 패키징 도구가 제안되고 있습니다. 이 도구는 쿠버네티스 리소스를 직접적인 형태로 패키징하며, 상태 기반의 배포 관리, 정책 기반 업그레이드, 스키마 기반 검증 등의 기능을 내장할 예정입니다.
결과적으로 Helm의 동작 방식에서 벗어나 쿠버네이티브한 방식으로 운영 안정성과 배포 일관성을 확보할 수 있게 될 것입니다.
IPv6 기본화: 네트워크 아키텍처의 리셋
클러스터 간 통신, 퍼블릭 클라우드 연동, IP 고갈 문제 등 다양한 이유로 IPv6 채택은 점차 필수로 변하고 있습니다. 현재 쿠버네티스는 IPv6를 지원하지만 기본 설정은 여전히 IPv4 중심입니다. 이를 IPv6 중심으로 전환하면 NAT 제거, 보안성 향상(IPSec 내장), 주소 공간 확대 등 여러 면에서 운영 효율이 높아집니다.
특히 멀티클러스터 환경이나 대규모 클라우드 인프라에서는 IPv6 전환이 더 이상 선택이 아닌 필수 요소로 자리 잡을 가능성이 큽니다.
플랫폼의 미래는 '기본값'이 결정한다
기술 선택에서 “필요한 사람만 쓰면 된다”는 논리가 자주 인용되지만, 실상은 플랫폼이 제공하는 기본 설정이 생태계를 좌우합니다. 쿠버네티스 2.0에서 HCL, 플러그형 저장소, KubePkg, IPv6 등이 기본값으로 채택된다면, 사용자들도 자연스럽게 그 방향을 따를 수밖에 없습니다. 즉, 플랫폼이 방향성을 명확히 제시해야만 진정한 변화가 일어납니다.
정리하며: 쿠버네티스 2.0은 새로운 시작점
쿠버네티스 2.0은 단순한 업그레이드가 아닙니다. 이는 구성 언어, 저장 구조, 배포 방식, 네트워크 설정 등 운영 전반의 철학을 새롭게 정의하려는 시도입니다. 다소 급진적인 변화처럼 보일 수 있지만, 복잡성과 운영 비용을 줄이고 미래의 인프라에 맞춘 구조로 진화하기 위한 필연적인 단계라 할 수 있습니다.
앞으로의 10년을 대비하려면 이제는 새로운 쿠버네티스를 준비해야 할 시점입니다.
댓글 쓰기