
랙스페이스 매니지드 쿠버네티스(MPK)
랙스페이스 매니지드 플랫폼 포 쿠버네티스(MPK)는 플랫폼9에 의해 구동되며, 클러스터 배치, 모니터링, 사고 대응, 업그레이드 등을 위한 통합 제어 평면을 제공한다.
MPK는 랙스페이스 베어 메탈, AKS, EKS 등 세 가지 환경을 지원한다. 고유한 장점으로는 수명 종료 후 120일 이내에 쿠버네티스 업그레이드를 보장하는 SLA와 전용 지원이 있다. 쿠버네티스 인증 엔지니어의 포드가 각 고객을 지원한다.
쿠버네티스 호환성이 매우 높은 MPK는 프로메테우스, 플루엔트드, 헬름, 이스티오와 같은 CNCF 지원 도구를 통합한다. 그러나 MPK에는 네이티브 컨테이너 레지스트리, IAM, 스토리지가 부족하기 때문에 퍼블릭 클라우드 또는 자체 솔루션이 필요하다.
AWS와 애저의 쿠버네티스 서비스를 관리하기 위한 직접적인 지원과 중앙집중식 플랫폼을 원하는 랙스페이스의 베어메탈 호스팅을 사용하는 팀에게 MPK는 확실한 선택이다.
랜처
수세의 랜처(Rancher)는 온프레미스와 클라우드를 위한 서비스형 쿠버네티스 솔루션이다. 랜처는 랜처 쿠버네티스 엔진(RKE), K3s, AKS, EKS, GKE를 포함한 여러 쿠버네티스 플랫폼 상의 클러스터를 관리할 수 있다.
몇몇 개발자들은 랜처의 통합 웹 UI가 사용하기 쉽다고 평가한다. API와 CLI도 제공한다. 자체 깃옵스 슬라이스를 통해 테라폼(Terraform)도 지원한다. 오쓰(OAuth)나 다른 로그인 옵션을 포함한 안전한 관리 제어 기능도 있다. 대규모 사용자 기반과 슬랙 그룹이 있어서 커뮤니티나 지원을 찾기 쉽다.
단 수세가 최근 몇 년 동안 가격을 올렸다. 일부 엔지니어들은 롱혼이라는 기본 스토리지 솔루션의 성능과 확장성 문제를 지적하며 백업 스토리지로 다른 대안을 추천한다. 랜처는 K3k라는 쿠버네티스 안의 쿠버네티스도 지원한다. 더 큰 환경에서 격리된 K3s 클러스터를 돌릴 수 있다.
전체적으로 랜처는 오픈시프트와 비슷하다. 근데 덜 독단적이고 더 모듈화되어 있다. 멀티 테넌트 접근 방식도 다르다. 공급업체 제약 없는 멀티 클라우드, 멀티 클러스터 관리가 필요하면 랜처가 좋은 선택이다. 포테이너(Portainer)도 비슷한 대안이다.
레드햇 오픈시프트 쿠버네티스 엔진
레드햇 오픈시프트는 개발자 도구 체인으로 쿠버네티스를 간소화한다. 클러스터 관리를 쉽게 해주는 하이브리드 클라우드 플랫폼이다. 가시성, 네트워킹, 보안, 깃옵스가 내장되어 있다. 독립형 쿠버네티스보다 업그레이드나 패치가 편하다. 클라우드 전용 서비스와 달리 온-프레미스, 데이터 센터, 클라우드 어디서든 실행할 수 있는 이식성이 있다.
오픈시프트 쿠버네티스 엔진은 오픈시프트의 간소화된 버전이다. 상위 PaaS 레이어 없이 관리형 쿠버네티스 환경을 제공한다. 컨테이너와 가상 머신을 같이 돌릴 수 있다.
단점은 오픈시프트가 AKS 같은 다른 서비스보다 훨씬 독단적이라는 점이다. 자체 oc CLI를 kubectl보다 선호한다. 일부 헬름 차트나 오퍼레이터는 보안 모델이 엄격해서 조정이 필요할 수 있다.
오픈시프트는 온프레미스 배포나 VM과 컨테이너를 관리하는 하이브리드 팀, 레드햇 고객에게 잘 맞는다. 내장 보안과 자동화가 있는 휴대용 엔터프라이즈급 쿠버네티스를 찾으면 오픈시프트가 강력한 선택지다.
스케일웨이 쿠버네티스 캡슐
유럽 연합에 기반을 둔 클라우드 제공업체인 스케일웨이(Scaleway)는 오토스케일링과 복원력에 중점을 둔 관리형 쿠버네티스 서비스인 쿠버네티스 캡슐(Kubernetes Kapsule)을 제공한다. 멀티 클라우드 배포를 위한 코스모스(Kosmos)도 있다.
캡슐은 세련된 UX, 좋은 고객 지원, API, CLI, 테라폼으로 유연하게 클러스터를 관리할 수 있다. 노드 사용량만큼만 비용을 낸다. 개인 클러스터나 실험용으로 저렴하다. 애플리케이션 라이브러리에 일반 추가 기능용 사전 구성 이미지도 포함되어 있다. CNCF 인증도 받았다. 표준 쿠버네티스 API를 따른다.
단점은 지원 지역이 프랑스, 네덜란드, 폴란드 정도로 한정돼 있다는 점이다. 글로벌 서비스로는 부족하다. 고급 로드 밸런싱이나 DNS 같은 기능이 없다는 점도 아쉽다. 프로비저닝이 느리다. 중단이나 안정성 문제도 보고된다.
기능과 지역이 제한적이어서 유럽 데이터 규제를 지켜야 하는 부수적인 프로젝트나 유럽 스타트업에 적합하다.
VM웨어 탄주 쿠버네티스 그리드(TKG)
VM웨어의 탄주 쿠버네티스 그리드(TKG)는 네트워킹, 인증, 모니터링, 로깅, 인그레스 제어를 간소화하는 쿠버네티스 플랫폼이다. 오픈소스를 일부 기반으로 한다. 클러스터 API로 여러 클러스터를 관리한다. 성능이 좋다. CLI와 UI 옵션도 제공한다.
단 TKG는 이제 멀티 클라우드가 아니다. v2.5 이후로 AWS와 Azure 워크로드 지원을 끊었다. 지금은 거의 v스피어에만 집중한다. 독립적인 쿠버네티스 컨트롤 플레인으로는 적절하지 않다. 클라우드 전반에 걸쳐 관리하려면 EKS, AKS, GKE 같은 네이티브 서비스와 탄주 미션 콘트롤(TMC)이 필요하다.
문제는 탄주의 복잡한 브랜딩과 문서화다. VM웨어 직원들도 SKU 설명하기 힘들다. 브로드컴이 VM웨어를 인수하면서 가격도 많이 올랐다. 몇몇 탄주 패키지 지원도 중단됐다. 장기적인 생존 가능성에 의문이 제기되고 있다..
v스피어와 가상 머신에 깊이 투자했다면, 또 비용 부담을 감내할 만하고 멀티 클라우드가 필요 없으면 TKG가 괜찮은 선택이다. 아니면 더 유연하고 미래 지향적인 대안이 낫다.
이 밖의 플랫폼들
그 외에도 수많은 관리형 쿠버네티스 플랫폼이 있다. 헤츠너(Hetzner)나 스펙트로 클라우드(Spectro Cloud) 같은 니치 클라우드와 함께 계속해서 등장한다. 비슷한 완전한 기능을 갖춘 쿠버네티스 관리형 플랫폼으로는 OVHCloud 매니지드 쿠버네티스와 시보(Civo) 쿠버네티스가 있다.
텐센트 쿠버네티스 엔진(TKE)과 화웨이 클라우드 컨테이너 엔진(CCE)는 아시아 태평양 지역 사람들에게 또 다른 옵션이다.
대기업들도 쿠버네티스 관리의 간소화된 버전을 제공한다. 예를 들어, AKS 오토매틱과 EKS 오토 모드는 클러스터 배포와 운영을 자동화하기 위한 원활한 개발자 경험을 제공한다. 구글 클라우드 안토스는 하이브리드 멀티 클라우드 솔루션으로 부상했다.
다른 많은 솔루션은 틈새 시장인 쿠버네티스 관리 기능에 특화되어 있다. 예를 들어, 포테이너(Portainer), 라파이(Rafay), 옴니(Omni), 리쿼(Liquo), 쿠베 클러스터스(Kube Clusters) 같은 관리 서비스는 멀티 클러스터, 멀티 클라우드 관리를 위한 범용 제어에 중점을 둔다.
엣지나 소형 컨테이너 배포의 경우, 슬림 옵션으로 MicroK8s, K3s, K0s가 있다. 벌처 쿠버네티스 엔진은 관리가 더 용이한 환경을 제공한다. 개발자들이 선호하는 쿠베스프레이(Kubespray)는 슬림 구성으로 쿠버네티스 클러스터를 배포하기 위한 오픈소스 도구 세트를 제공한다.
작업별 적합한 도구
플러그 앤 플레이 방식의 쿠버네티스 서비스는 클러스터 관리의 많은 번거로움을 덜어준다. 하지만 규모에 따라 다르다. 여러 클러스터를 동시에 실행하지 않으면 관리형 서비스가 필요 없을 수도 있다. 소규모 배포의 경우, 도커 컴포즈(Docker Compose)나 노마드(Nomad) 같은 더 간단한 컨테이너 런타임을 선택할 수 있다. 다른 사람들은 헤로쿠(Heroku), 플라이.io(Fly.io), 클라우드 런(Cloud Run) 같은 서비스형 플랫폼(Platform-as-a-Service)을 선택할 만하다.
필요에 따라 특정 도구만 필요할 수도 있다. 예를 들어, 카펜터(Karpenter)는 클러스터 노드의 자동 확장 전용으로 널리 사용되는 오픈소스 도구다. 데브트론(Devtron)같은 대시보드나 앱타큐브(Aptakube), 옥탄트(Octant) 같은 UI만 필요할 수도 있다.
인프라 수준에서 더 세밀한 제어가 필요할 거라 예상하고 여력이 있으면 구매보다 구축이 더 나을 수도 있다. 적절한 기술적 역량이 있으면 궁극적인 제어를 위해 내장된 kubeadm을 유지하고 쿠버네티스를 직접 호스팅하는 걸 고려할 만하다.
관리형 쿠버네티스 서비스를 평가하려면 두 가지 주요 요소에 집중해야 한다. 수석 컨설턴트 마이클 레반은 자동화된 서비스가 인프라 관리를 제거할 수 있지만, 특정 타사 도구와 잘 통합되지 않을 수도 있다고 지적했다. 그는 “클라우드에서처럼, 얼마나 많은 권한을 포기할 건지에 따라 결정된다”라고 말했다.
dl-ciokorea@foundryco.com