엑기스 | All about Kubernetes

　

　

　

 최근 쿠버네티스(Kubernetes)에 대한 관심이 뜨겁습니다. 아래의 차트를 통해 알 수 있듯이 해외 뿐 아니라 국내에서도 쿠버네티스에 대한 관심이 꾸준하게 증가하고 있습니다.

　

                     <쿠버네티스에 대한 관심도 변화(해외)>                                          <쿠버네티스에 대한 관심도 변화(국내)>

　

 특히, 2018년도에 AWS가 Kubernetes를 지원하는 EKS 서비스를 발표하면서 퍼블릭 클라우드 시장에는 Google GCP의 GKE, Microsoft Azure의 AKS, Amazon AWS의 EKS를 통해 공식적으로 모든 퍼블릭 클라우드에서 쿠버네티스를 이용할 수 있게 되었습니다. 과연 쿠버네티스가 무엇이길래 전 세계적으로 관심이 증가하고, 또, 퍼블릭 클라우드 업체들이 앞 다투어 쿠버네티스 서비스를 지원하는 것일까요?

　

　

　

1. Kubernetes?

 Kubernetes(k8s)란, 2014년 구글에서 공개한 이후 CNCF(Cloud Native Computing Foundation)가 주도하고 있는 오픈소스로서, 컨테이너화 된 애플리케이션을 자동으로 배포, 스케일링 해주는 컨테이너 오케스트레이션(Container Orchestration) 툴입니다. 

　

 쿠버네티스에서 이야기하는 컨테이너는 격리된 공간에서 프로세스가 동작하는 기술을 말합니다. 즉, 애플리케이션 외에 Linux 등의 환경적인 요소들을 하나의 컨테이너로 묶음으로써 다양한 유저환경에서도 애플리케이션이 안정적으로 실행될 수 있게 해주는 기술입니다. 

　

 쿠버네티스는 하나의 Master Node와 여러 대의 Worker노드로 하나의 클러스터를 구성합니다. 그리고 이러한 쿠버네티스 환경에서 수백, 수천 개의 컨테이너들을 자동으로 배포, 스케일링하면서 서비스들을 안정적으로 운영할 수 있게 해주는 역할을 합니다.

<Kubernetes의 Master Node와 Worker Node의 단순 구조도>

　

　

　

2. 쿠버네티스를 좀 더 구체적으로 들여다보기

 쿠버네티스의 기본 기능은 정말 많지만 기능을 설명하기 보다는 Container Orchestration 관점에서 Status management, Scheduling, Rollout/Rollback 이라는 세 가지의 특징을 살펴보고자 합니다. 

　

1) Status management

 먼저 Status management는 노드가 죽거나 컨테이너 응답이 없을 경우 자동으로 복구하는 것을 의미합니다. 예를 들면, 쿠버네티스에서 컨테이너를 관리하는 단위를 Pod라고 하는데, 쿠버네티스는 Pod가 죽게 되면 컨테이너에서 실행 중이던 서비스가 중단되게 됩니다. 따라서, 운영중인 Pod의 장애가 전체 서비스에 영향을 미치는 것을 막고자 쿠버네티스는 ReplicaSet이라는 개념을 통해 Pod의 복사본들을 두어 실행 중인 Pod에 장애가 발생하더라도 즉시 다른 Pod로 대체하여 서비스의 상태를 유지하게 합니다.

　

2) Scheduling

 클러스터의 여러 노드 중 조건에 맞는 노드를 찾아 컨테이너에 배치합니다. 만일, 3대의 Worker Node가 각각 10MB, 100MB, 1GB의 메모리를 가지고 있고, 실행하고자 하는 컨테이너가 500MB의 메모리를 필요로 한다면, 쿠버네티스는 컨테이너를 실행할 수 있는 1GB의 메모리를 가진 노드에 자동으로 배포하여 컨테이너 실행에 장애가 발생하지 않도록 합니다.

　

3) Automatic RollOut and RollBack

 쿠버네티스는 버전 관리를 쉽게 할 수 있게 합니다. 기존의 단일(Monolithic) 서버 환경에서는 서비스에 업데이트가 일어나는 경우 서버 운영자가 운영 중인 서비스를 내리고 다시 버전업 된 서비스를 올리는 동안 유저들이 서비스를 이용할 수 없는 다운 타임이 발생하게 됩니다. 하지만, 쿠버네티스 환경에서 서비스를 운영하게 된다면 Deployment라는 개념을 이용하여 rolling update가 이루어지고, rolling update를 통해 운영 중인 서비스를 중단하지 않고도 서비스의 업데이트가 이루어질 수 있습니다. 물론, 업데이트한 서비스에 문제가 발생한 경우에는 Deployment에 저장되어 있던 이전 버전의 서비스로 다운 타임 없이 복구 시킬 수도 있습니다.

　

　

　

3. Kubernetes는 만병통치약?

 이렇게 완벽한 서비스를 해줄 것 같은 쿠버네티스에도 맹점이 존재합니다. 

　

 첫 번째는 클러스터를 구성하는 노드들의 상태를 서버 운영자가 실시간으로 확인하기 힘들다는 점입니다. 쿠버네티스에 올라가는 모든 서비스는 여러 개의 worker node로 분산되어 실행됩니다. 하지만 하나의 worker node에 장애가 발생한 경우 서버 운영자가 직접 쿠버네티스에 접속하여 노드의 상태를 확인하기 전까지는 노드의 상태를 파악하기가 쉽지 않습니다. 

　

 두 번째는 쿠버네티스에서 운영되는 서비스는 Micro Service로 운영되기 때문에 서비스가 느려지거나 장애가 발생한 경우 연결된 여러 개의 서비스 중에 어떠한 서비스에 문제가 생겼는지 파악하기가 어렵습니다. 만일 많은 사용자들이 동시에 DB에 접근하여 데이터를 입력하는 경우 운영 중인 DB에는 부하가 걸리게 되고 이는 서비스의 속도에 영향을 미치게 됩니다. 하지만 쿠버네티스에서는 모니터링 서비스를 따로 지원하지 않기 때문에 어떤 서비스에서 어떤 문제가 발생했는지 알기 어렵습니다.

　

 마지막으로는 하나의 서비스가 쿠버네티스 상에서 실행되는 경우 서비스의 원활한 운영을 위해 장애 예측 및 장애 분석을 위한 툴이 필요하다는 점입니다. 만일, 특정 장애가 특정 시간에 주기적으로 발생하는 경우 지속적으로 원활한 서비스 제공하기 위해 장애를 분석할 수 있는 도구가 필요합니다.

　

<쿠버네티스 상에서의 모니터링 솔루션, InterMax Cloud>

 위와 같은 문제들을 사전에 방지하고 장애를 빠르게 파악하여 고객에게 원활한 서비스를 제공하기 위해서는 Kubernetes Monitoring System이 필요합니다. 특히, InterMax Cloud는 운영 중인 쿠버네티스 서비스를 시각화하여 CPU, Network 등의 운영 중인 시스템 상태를 파악할 수 있게 하고, 장애가 발생한 지점을 빠르게 파악할 수 있게 도와줍니다. 또한, 희소 로그 분석, Anomaly Score 분석 등 다양한 관점에서의 강력한 분석 기능을 통해 서버 운영자가 장애를 예측하고, 대응할 수 있도록 도와줍니다. 이런 강력한 기능들이 있는 InterMax Cloud. 쿠버네티스를 통해 서비스를 운영 중인 기업이라면 한 번쯤 도입을 고려해 봐야 하지 않을까요?

제품 보러가기

기고 | Cloud개발팀 윤영민

편집 | 사업기획팀 박예영