제2편. 왜 그럼 매니지드 쿠버네티스일까요?

작성자 : 클라우드 컨설팅 그룹 한경수, 정예은, 황희, 정준호, 마승우

쿠버네티스는 엔터프라이즈 기업 또는 서비스 사업자가 클라우드로 전환할 때 꼭 필요한 기술입니다.
기업들은 쿠버네티스 환경에서 워크로드의 이동성이 높아지면서 IT 환경에 대한 구분보다는 자사에 맞는 환경과 서비스를 도입하는데 집중하고,
어떻게 업무 프로세스에 적용하여 디지털 혁신을 최적화 할 것인지에 대해 고민하고 있습니다.

이에 클루커스는 효율적인 클라우드 전환을 고려하는 고객분들을 위해,
쿠버네티스 도입부터 성능 테스트를 통한 각 CSP별 매니지드 서비스에 대한 특장점까지 매월 다뤄보고자 합니다.

*클루커스는 CNCF 재단과 리눅스 재단이 인증하는 KCSP(쿠버네티스 전문 서비스 기업)자격을 보유하고 있습니다.

Why Managed Kubernetes인가?

분명 k8s를 사용하기로 마음먹기까지 많은 고민을 했지만, k8s를 사용함에 있어 앞으로도 이것 저것 많은 고민을 해야 합니다.
먼저 k8scluster를 ‘어디에 어떻게 구축할 것인가?’에 대한 고민이 필요합니다.
어디에 k8s를 구축하는 것이 정답인가? 사실 주어진 환경이나 목적에 따라 선택지가 달라질 수 있어서 ‘k8s는 어디에 어떻게 배포하는것이 정답이다.’ 라고 하기는 힘들 것 같습니다.

Kubernetes를 구축하는 방법은 주로 3가지로 요약할 수 있습니다.

자체서버 환경에서 쿠버네티스 설치
클라우드 서버 인프라 위에 쿠버네티스 설치
AKS(Azure), EKS(AWS), GKE(GCP)등의 클라우드의 Managed 쿠버네티스 사용

먼저 자체 서버환경에서 쿠버네티스를 설치할 경우

쿠버네티스와 서버 인프라를 미세하게 설정할 수 있다는 장점이 있습니다.
클라우드에서 지원할 수 없는 기능이 필요하다면 자체 구축을 하는 것을 고려하는 것이 좋습니다. 하지만 이 경우에는 모든 관리를 직접 해야 하기 때문에 운영, 관리가 복잡해집니다.
처음 쿠버네티스를 도입하는 경우에는 사용하기 어려운 방법입니다.

클라우드 서버 인프라위에 직접 설치할 경우

클라우드의 인프라(VM, Network 등) 위에 설치함으로 인프라의 관리를 CSP에 이관합니다.
사용자 입장에서는 쿠버네티스의 설치와 설정을 직접 하기 때문에 Managed 쿠버네티스 보다 자유로운 설정이 가능합니다. 하지만 클라우드 내에서 클러스터를 구축하는 과정과 클러스터와 쿠버네티스를 연결하는 과정이 어려울 수 있습니다.

CSP 제공 Managed 쿠버네티스 사용

설치를 할 필요가 없으며, 인프라와 쿠버네티스를 CSP에서 관리하는 서비스 입니다.
쉽게 사용이 가능하고, 각 클라우드 플랫폼의 종속적인 자체 기능도 활용 가능합니다.
Managed 서비스 도입 전에는 요구사항 분석과, 필요한 기능이 Managed 서비스에서 구축가능한지 확인하는 단계가 필요합니다.

Managed Service의 장점

클러스터를 구성하고 설치하는 데 소요되는 시간을 단축합니다.

클러스터의 컨트롤 플레인이 자동으로 생성됩니다. 따라서 컨트롤 플레인에 직접 액세스 하여 구성 및 관리할 필요가 없으며, 이는 컨트롤 플레인에서 발생되는 문제점들을 방지할 수 있습니다.

컨테이너 기반 애플리케이션 배포 및 관리를 더 간소화합니다. 배포의 복잡성과 핵심 관리 작업의 시간을 줄일 수 있습니다.

명령어 몇 줄로 간편하게 클러스터 버전 업그레이드 및 노드 Scale out이 가능합니다.

MSA(마이크로서비스 아키텍처; MicroService Architecture)를 구현하기 위해 사용합니다.

- MSA는 기존 하나의 덩어리 형태인 모놀리식(Monolithic) 아키텍처를 잘게 썰어 놓은 형태로 재편성한 후, 각각의 작은 아키텍처에 SW를 하나씩 올리는 것을 말합니다. 이렇게 하면 별도의 SW 개발과 운영이 가능합니다.

- 컨테이너 구동 방식이 아키텍처를 잘게 나눠야 하는 MSA에 부합합니다.

보안, 거버넌스, ID 및 액세스를 관리하는 데 용이합니다.

엔터프라이즈 클라우드 기능이 포함된 워크로드 실행에 적합합니다.

Cloud환경을 제공하는 vendor도 다양합니다.

대표적으로 AWS, Azure, GCP, NCP 등이 있는데요. 각 vendor마다 관리형 k8s를 제공하고 있습니다.
여러 Cloud vendor들의 PaaS제품 중 어떤 것을 선택해야 하는가? 무엇을 기준으로 어떻게 선택해야 후회없는 선택을 할 수 있는가?
어떻게 보면 k8s라는것이 infra 위에 또 다른 infra를 구성해야 하는 격이라 이거 자체 만으로 고민거리가 많은데, 이를 제공하는 서비스도 다양하니 그만큼 고민거리가 늘어나는 것은 어쩔 수 없는 것 같습니다.

그런데 어쩌죠~ 지금하고 있는 고민들은 어떠한 환경에 안착할 것인가에 대한 고민들이죠. 환경에 대한 고민이 끝나더라도 k8s를 어떻게 사용할 것인가에 대한 고민거리가 수없이 기다리고 있습니다. -0- 이정도면 k8s는 고민이 아니라 고문인것 같습니다…. ㅜㅜ

눈물을 감추고 본론으로 돌아와서 vendor마다 제공하는 PaaS 형태의 Kubernetes 제품들입니다.
(아래에 언급하는 관리형 K8s외 ARO(Azure Red Hat OpenShift)라는 완전 관리형 서비스도 있지만, ARO는 성격이 다르므로 이번에는 제외하겠습니다.)

AWS : EKS (Elastic Kubernetes Service)

Azure : AKS (Azure Kubernetes Service)

GCP : GKE (Google Kubernetes Engine)

NCP : NKS (Naver Kubernetes Service)

PaaS제품을 선택하는데 있어 이유와 방법이야 여러가지가 있겠지만 기본적으로 생각해 볼 수 있는 것으로 각 vendor의 PaaS형 k8s 제품들의 성능, 특별한 기능, 제약사항이, 비용 등의 내용이 정리된다면 많은 도움이 되리라 생각합니다.

성능 차이가 어느정도 있는지 각 vendor마다 측정을 해보고 비용이나 기타 특이한 기능 등의 차이가 있는지 다음편에서 알아 보도록 하겠습니다.