우리도 있다! 매니지드 쿠버네티스 플랫폼 14종

쿠버네티스는 매우 강력하지만 매우 복잡하기도 하다. 이 때문에 많은 조직들이 자체 호스팅 솔루션을 버리고 관리형 쿠버네티스 플랫폼으로 이동하고 있다. 2021년 데이터독의 보고서에 따르면, 쿠버네티스 사용자의 거의 90%가 클라우드 관리형 서비스를 이용하고 있다.

주요 클라우드 하이퍼스케일러들 모두 자체 관리형 쿠버네티스 플랫폼을 보유하고 있습니다. 각각 아마존 엘락스틱쿠버네티스 서비스(EKS), 애저 쿠버네티스 서비스(AKS), 구글 쿠버네티스 엔진(GKE)이다. 그러나 이들은 시작일 뿐이다. 관리형 쿠버네티스 서비스는 여러 기성 기술 회사와 신생 스타트업 다수가 제공 중이다. 클라우드 네이티브 컴퓨팅 재단(CNCF)가 인증한 벤더가 100곳이 넘을 정도다.

실제로 주요 3사를 제외한 대안형 관리형 쿠버네티스 플랫폼에 대한 관심도 증가하고 있다. 많은 플랫폼이 엣지, 온프레미스 또는 소규모 컨테이너 배포와 같은 고유한 환경에 특화되어 있다. 일부 서비스는 대규모 클라우드 업체보다 훨씬 저렴한 비용으로 관리형 인프라를 제공한다.

기존의 대형 업체들이 정체 상태에 빠진 채 가격을 인상하는 동안, 신생 업체들이 빠르게 혁신하고 있다. 특히 여러 퍼블릭 클라우드 또는 프라이빗 클라우드에서 클러스터를 관리하는 독립적인 레이어에 중점을 둔 솔루션이 풍부하다. 주목할 만한 관리형 쿠버네티스 플랫폼들을 살펴본다.

알리바바 컨테이너 서비스 포 쿠버네티스 (ACK)

알리바바 클라우드 콘테이너 서비스 포 쿠버네티스(ACK)는 클러스터 관리와 컨테이너화된 애플리케이션 배포를 간소화하기 위한 다양한 추가 기능을 제공한다. 이를 통해 알리바바 클라우드 인프라에서 높은 확장성을 구현한다.

주요 특징으로는 안전한 네트워킹을 위한 네이티브 VPC과 더불어 GPU 가속 인스턴스에 대한 인스턴트 액세스가 있다. 이를 통해 개발자는 여러 지리적 영역에 걸쳐 쉽게 배포할 수 있으며, 내장 카나리아 및 블루-그린 배포 전략을 사용하여 릴리스를 테스트할 수 있다. ACK는 쿠버네티스 규격에 부합하며 전문적인 지원 서비스를 포함한다.

ACK는 VPC 네트워킹을 우선시하며, 실리엄(Cilium)과 같은 현대적인 eBPF 기반 CNI에 대한 기본 지원 측면에서는 다소 부족하다(플러그인을 제공하긴 하지만). 또한 로깅, 저장, RBAC(역할 기반 액세스 제어)에 대해 알리바바 클라우드 서비스에 의존한다. 알리바바 클라우드 사용자에게는 좋지만, 오픈 스 유연성을 추구하는 사람들에게는 감점 요인이다.

아시아 태평양 지역에서 사업을 운영하거나 이미 알리바바 클라우드와 관련이 있는 경우, ACK는 확실한 고려 대상이다.

D2iQ 쿠버네티스 플랫폼(DKP)

현재 뉴타닉스가 소유하고 있는 D2iQ 쿠버네티스 플랫폼(DKP)은 메조스피어(Mesosphere)에서 진화한 서비스다. 메조스피어는 컨테이너 전쟁에서 그다지 좋은 성적을 거두지 못한 오케스트레이터인 아파치 메조스(Apache Mesos ; 현재는 사라짐)와 함께 제공됐던 바 있다. 쿠버네티스로 전환한 후, DKP는 클라우드 전반에 걸친 클러스터 관리를 위한 자동화 기능을 도입했다.

DKP의 컨트롤 플레인은 클러스터 전반에 걸친 가시성을 중앙집중화하여 문제 해결과 근본 원인 분석을 지원한다. 또 선언적 API와 표준 kubectl 명령에 부응하는 CNCF 준수성을 갖췄다. DKP는 또한 NSA/CISA 지침을 충족하고 에어갭 배포를 지원한다.

대부분의 사용자들은 DKP가 생산 등급 클러스터 관리를 위한 강력하고 신뢰할 수 있는 플랫폼이며, 데이터베이스 프로비저닝, CI/CD, 백업, 취약성 스캐닝, 모니터링을 단순화한다고 평가한다. 그러나 일부 사용자들은 문서화가 부족하고, 지원이 느리고, 초기 설정에 대한 학습 곡선이 가파르다고 말하기도 한다. 이 밖에 영업 사원들이 제품에 대한 지식이 부족하다는 지적도 있다.

DKP는 다양한 배포 환경에서 여러 클러스터를 실행하는 더 간단한 방법을 찾고 있는 강력한 깃옵스(GitOps) 문화를 가진 크로스 클라우드 조직에 적합한 선택이다.

디지털오션 쿠버네티스(DOKS)

디지털오션 쿠버네티스(DOKS)는 UI, API, CLI를 통해 액세스할 수 있는 완전 관리형 제어 평면을 갖춘 관리형 쿠버네티스 플랫폼이다. 이 플랫폼은 스냅슈터(SnapShooter)를 이용해 자동화된 고가용성, 자동 확장, 백업을 제공함으 인프라 관리를 추상화한다.

사용자들은 직관적인 웹 인터페이스, 간소화된 CLI, 쉬운 온보딩을 높이 평가한다. 몇 가지 명령어로만 업데이트가 이뤄지며, 네이티브 로드 밸런서와 볼륨이 원활하게 통합된다. 노드당 비용은 하이퍼스케일러보다 낮은 경향을 보인다. GPU 워크로드는 수동으로 배포되는 엔비디아 지원 드롭릿을 통해 지원된다.

공개적으로 노출된 etcd와 같은 초기 보안 문제는 해결됐다. 그러나 DOKS는 분산 스토리지를 위한 내장형 NFS(Network File System) 지원이 부족하다. 이에 대해 일부 플랫폼은 네이티브 옵션을 제공하기도 한다. 이 밖에 가상 사설 클라우드(VPC) 네트워킹을 사용할 수 있지만, AWS나 GCP보다 유연성이 떨어진다.

DOKS는 계속해서 개선되고 있으며, API, 워커 노드 또는 로그 처리와 같은 소규모 쿠버네티스 워크로드에 적합한 선택이다.

IBM 클라우드 쿠버네티스 서비스(IKS)

IBM 클라우드 쿠버네티스 서비스(IKS)는 IBM 클라우드에 컨테이너화된 애플리케이션을 배치하기 위한 관리형 쿠버네티스 플랫폼이다. 고급 스케줄링, 치유, 모니터링, 사용자 친화적인 배치 도구를 제공한다.

사용자들은 IKS의 핵심 장점으로 작업량 확장성과 높은 가용성을 꼽는다. 또한, IKS의 리소스 격리 기능은 규제가 엄격한 환경에서 유용하다. CNCF 인증을 받은 IKS는 예측 가능한 쿠버네티스 API 동작, 네이티브 컨테이너 레지스트리, 그리고 왓슨을 포함한 다른 IBM 서비스와의 통합을 제공한다.

멀티 클라우드에 초점을 맞춘 플랫폼과 달리, IKS는 IBM 클라우드 전용 서비스다. 즉 독립적인 컨테이너 오케스트레이션에서의 역할이 제한적이다. IBM 클라우드에 대해 개발자들은 높은 비용, 문제 해결의 어려움, 문서화의 부족 등을 지적하곤 한다. IKS에 대해서는 호불호가 엇갈리는 경향을 보인다.

이미 IBM 클라우드를 사용하고 있고 IBM 서비스와의 긴밀한 통합이 필요한 경우, IKS가 좋은 선택일 수 있다. IBM 클라우드에 대한 엇갈린 의견에도 불구하고, 여러 리뷰에서는 IKS가 역할을 잘 수행한다고 평가하곤 한다.

쿠버매틱 쿠버네티스 플랫폼

쿠버매틱 쿠버네티스 플랫폼(Kubermatic Kubernetes Platform ; KKP)은 낮은 대역폭이나 낮은 처리 능력과 같은 엣지 제약 조건에 최적화된 관리형 쿠버네티스 배포판이다. 이 플랫폼은 이식성이 뛰어나다. 하이브리드 멀티 클라우드, 데이터 센터, 멀티 테넌트 환경을 지원한다.

KKP에는 스케일링, 치유, 프로비저닝, 업데이트, 백업 등을 위한 자동화 기능이 내장되어 있다. CNCF 인증을 받았기 때문에 쿠버네티스 네이티브 명령어를 따르며, 자체 관리형 오픈소스 커뮤니티 버전은 아파치 라이선스 2.0에 따라 제공된다.

KKP의 컨테이너 네트워크 인터페이스(CNI) 지원은 원래 커낼(Canal)로 제한되어 있었지만, 지금은 실리엄 등의 다른 것들도 지원한다. KKP는 주요 관리형 쿠버네티스 서비스에 비해 사용자 기반이 작지만, 상당한 업스트림 쿠버네티스 기여자다.

KKP 클러스터는 관리형 플랫폼으로서는 무난하다. 엣지에서 컨테이너에 대한 높은 수준의 커스터마이제이션을 제공하는 쿠버네티스 네이티브 관리형 플랫폼을 원한다면, KKP가 좋은 옵션이다.

리노드 쿠버네티스 엔진 (LKE)

아카마이의 리노드 쿠버네티스 엔진(LKE)은 쿠버네티스 클러스터를 유지 관리하지 않고도 컨테이너화된 애플리케이션을 배포할 수 있게 하는 관리형 플랫폼이다. 이 플랫폼은 완전한 관리형 제어 플레인과 클러스터 프로비저닝을 위한 프로그래밍 방식을 특징으로 한다.

사용자들은 LKE의 사용 편의성, 고품질 고객 지원, 투명한 가격 정책(작업자 노드에 대해서만 비용을 지불하고, 인바운드 전송은 무료)을 호평한다. LKE는 99.99%의 가동 시간을 보장하고, 여러 가지 쿠버네티스 버전을 지원하며, 신속한 애드온 도구를 가능하게 한다.

그러나 LKE에는 주요 플랫폼에서 볼 수 있는 몇 가지 고급 기능이 없다. 특히, 개인 컨테이너 레지스트리를 제공하지 않으며, 대시보드가 관리되기는 하지만 사용자가 배포 구성을 처리해야 한다. (참고로 아카마이 앱 플랫폼의 기능성은 우수하지만 아직 베타 버전이다.) GPU 워크로드에 대해서는 추가 제품 구독이 필요하다.

스왑닐 바르티야가 TFiR.io에 쓴 글에 따르면, LKE는 일반적인 클라우드 사용자를 위해 설계된 서비스로, 소규모 팀과 대기업 모두를 대상으로 한다. 그러나, 그 단순성 때문에 많은 사람들이 이 서비스를 소규모 업체의 것으로 간주한다. 엘리엇 그래버트는 LKE를 “스타트업에 가장 적합한” 서비스라고 설명한 바 있다.

미란티스 쿠버네티스 엔진(MKE)

미란티스 쿠버네티스 엔진(MKE)은 이전의 도커 엔터프라이즈다. 베어 메탈, 퍼블릭 클라우드, 그리고 그 사이의 모든 곳에서 구동되는 쿠버네티스 기반 컨테이너 오케스트레이션 플랫폼이다. 오픈소스를 기반으로 구축된 이 플랫폼에는 네트워킹을 위한 캘리코(Calico)와 컨테이너와 VM을 모두 관리하는 쿠베버트(KubeVirt)가 포함되어 있다.

CNCF 인증을 받은 MKE는 웹 UI, CLI 또는 API를 통해 유연한 액세스를 제공한다. 사용자들은 사용의 용이성, 강력한 보안 제어, 무제한 작업자 노드, 컨테이너 이미지를 위한 내부 트러스티드 레지스트리를 높이 평가한다.

그러나 일부 사람들은 미란티스의 오픈소스 약속을 의심한다. 인기 있는 쿠버네티스 대시보드인 렌즈(Lens)를 사유화하고 무료 도커 관련 도구를 제품화한 이력 때문이다. 여러 리뷰에서는 고객 지원 문제와 불투명한 문서화도 언급하고 있다.

완전한 유연성보다 단순성을 중요하게 생각하는 도커 생태계 내의 사람들에게 MKE는 여전히 확실한 선택이다.

오라클 쿠버네티스 엔진(OKE)

오라클 쿠버네티스 엔진(OKE)은 오라클 클라우드 인프라스트럭처(OCI)를 기반으로 구축된 쿠버네티스 관리 플랫폼이다. 유지보수, 패치, 수리를 자동화하는 것 외에도 OKE는 자동 확장 및 효율적인 자원 활용을 지원한다.

OKE는 확장성이 준수하다. 서비스 메시, 클러스터 자동 확장, 메트릭, 인그레스 컨트롤러, 로드 밸런싱 등과 같은 영역에 여러 클러스터 애드온을 제공하여 오라클 생태계와 연계된 조직에 적합하다. 오라클은 일반적으로 엔터프라이즈 사용자를 대상으로 하지만, 일부 인디 개발자들도 자체 호스팅 프로젝트를 위해 OCI의 올웨이즈 프리 티어를 이용하고 있다.

일부 오라클 클라우드 사용자들은 무료 계정에서 계정이 갑자기 폐쇄되는 문제를 보고하고 있다. OCI 사용자 인터페이스 사용 시의 불편한 경험을 보고하는 목소리도 있다. 닥크테이프 테크놀로지스의 공동 설립자이자 CEO인 아놀드 갈로비치는 “오라클 클라우드 콘솔 인터페이스는 큰 퇴보다”라고 표현하기도 했다.

그러나 넉넉한 무료 계정을 제공하는 기업 중심의 쿠버네티스 관리 계층을 찾고 있다면, OKE가 적합하다.

플랫폼9 매니지드 쿠버네티스

플랫폼9 매니지드 쿠버네티스(PMK)는 배포, 모니터링, 치유, 업그레이드와 같은 클러스터 운영을 자동화하는 완전 관리형 쿠버네티스 서비스다. 클라우드에 구애받지 않는 PMK는 온-프레미스, 엣지, 퍼블릭 클라우드에서 실행된다.

사용자들은 PMK를 통해 성공적으로 확장할 수 있었다고 보고한다. 여기에는 멀티 클러스터 관리, 멀티 테넌시, 세분화된 RBAC 정책이 포함된다. 플랫폼9의 ‘Always On Assurance’가 고가용성을 보장한다. 경쟁사보다 업스트림 쿠버네티스에 더 가까운 PMK는 견고한 개발자 경험을 제공한다.

그러나 PMK에는 내장된 개인 레지스트리가 없고, CNI 지원이 제한적이다(플러그인을 통해 사용자 정의할 수 있음). 클라우드 호스팅 제어 평면은 엄격한 온-프레미스 규정 준수 요구 사항에 적합하지 않을 수 있다. 사용자들이 비용 절감을 보고하고 있지만, 정확한 가격 세부 사항은 불투명하다.

프라이빗 클라우드 쿠버네티스를 찾는 기업에게 PMK는 레드햇 오픈시프트, 또는 VM웨어 탄주의 강력한 대안이다.

랙스페이스 매니지드 쿠버네티스(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을 유지하고 쿠버네티스를 직접 호스팅하는 걸 고려할 만하다.

관리형 쿠버네티스 서비스를 평가하려면 두 가지 주요 요소에 집중해야 한다. 수석 컨설턴트 마이클 레반은 자동화된 서비스가 인프라 관리를 제거할 수 있지만, 특정 타사 도구와 잘 통합되지 않을 수도 있다고 지적했다. 그는 “클라우드에서처럼, 얼마나 많은 권한을 포기할 건지에 따라 결정된다”라고 말했다.
[email protected]