쿠버네티스(Kubernetes)의 복잡성에 지친 개발자, 새로운 컨테이너 오케스트레이션(Container Orchestration) 도구 개발 시작
by DD
2개월 전
조회수 38
쿠버네티스(Kubernetes)의 높은 복잡성(Complexity)과 학습 난이도(Learning Curve)에 대한 문제 제기
도커 스웜(Docker Swarm)과 해시코프 노마드(HashiCorp Nomad) 등 기존 대안들의 한계점을 분석
컨테이너 오케스트레이션(Container Orchestration)의 불필요한 복잡성(Unnecessary Complexity)을 해결하기 위한 오픈소스(Open Source) 프로젝트 시작
쿠버네티스(Kubernetes) 복잡성 문제의 근본 원인
글쓴이는 쿠버네티스(Kubernetes)가 15개 이상의 추상화(Abstraction) 레이어를 요구하며, 릴리즈(Release)마다 API 변경 사항이 증가하는 점을 문제로 지적한다.
Pod, Deployment, Service, Ingress 등 핵심 개념 학습에 대한 높은 진입 장벽(High Entry Barrier) 존재
CKA(Certified Kubernetes Administrator) 자격증이 시장 상품화될 정도로 복잡성 심화
소규모 기업(Small Company)은 전문 DevOps 엔지니어(DevOps Engineer) 고용의 어려움 겪음
결과적으로 쿠버네티스(Kubernetes)는 강력한 기능을 제공하지만, 과도한 복잡성(Excessive Complexity)으로 인해 사용성이 저해된다.
기존 컨테이너 오케스트레이션(Container Orchestration) 도구의 한계
글쓴이는 도커 스웜(Docker Swarm)의 기능 정체(Functionally Stagnant)와 해시코프 노마드(HashiCorp Nomad)의 생태계 종속성(Ecosystem Dependency)을 단점으로 평가한다.
도커 스웜(Docker Swarm): Docker Inc.의 개발 지원 축소로 인한 생태계 쇠퇴
해시코프 노마드(HashiCorp Nomad): HashiCorp 생태계(Consul, Vault, Terraform) 종속성으로 인한 유연성 부족
HashiCorp의 라이선스 변경(MPL to BSL)으로 인한 오픈소스(Open Source) 프로젝트의 위험성 증가
결론적으로 기존 도구들은 쿠버네티스(Kubernetes)의 대안이 되기에는 기술적, 상업적 리스크(Technical and Commercial Risk)를 안고 있다.
새로운 컨테이너 오케스트레이션(Container Orchestration) 도구 개발의 목표
글쓴이는 쿠버네티스(Kubernetes)의 복잡성을 해결하고, 컨테이너 오케스트레이션(Container Orchestration)의 사용성(Usability)을 개선하는 것을 목표로 한다.
오픈소스(Open Source) 프로젝트로 Apache 2.0 라이선스(Apache 2.0 License) 채택 및 상업적 이윤 추구 X
쿠버네티스(Kubernetes)의 대안 개발을 통해 개발자 경험(Developer Experience) 향상 기대
향후 아키텍처(Architecture) 결정 및 구현 과정 공개를 통해 커뮤니티(Community)와의 소통 계획
결과적으로 글쓴이는 컨테이너 오케스트레이션(Container Orchestration) 분야의 혁신을 목표로, 오픈소스(Open Source) 프로젝트를 시작했다.
