[ Docker && Kubernetes ] - 쿠버네티스를 이용한 컨테이너 오케스트레이션: 쿠버네티스 소개

쿠버네티스



쿠버네티스는 가장 대표적인 컨테이너 오케스트레이션 시스템입니다. 사실상 표준이라고 할 수 있습니다.

 

컨테이너 오케스트레이션 시스템이란?

이는 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하는 기술이라고 할 수 있습니다.

 

기존에 Docker / Docker Compose는 한대의 머신 안에서 컨테이너를 관리하기 위한 도구로 사용했었습니다. 다만 컨테이너 오케스트레이션 시스템에서는 여러대의 머신 -> 클러스터 상에서 컨테이너를 관리하게 됩니다.

 

User라는 서비스가 있다고 해보면 User라는 컨테이너의 Scaling작업, Rollout과 같은 작업을 하기도 합니다. 또한 버전관리와 관련된 Rollback과 관련된 기능을 제공합니다. 그리고 CPU, memory, GPU와 같은 유휴자원같은 것을 관리햐여, 특정 서비스를 배포할 때 사용됩니다. 그리고 컨테이너가 어떤 로드에 스케쥴링 되어야 하는지 관리할 때도 사용됩니다. 그리고 이전에도 말했지만 overlay network를 사용해서 멀티노드 환경에서 가상의 네트워크 영역을 만들어서 서로 떨어진 노드에서 동일 노드에 있는 것 같이 하는 기술입니다. 도커 엔진에도 overlay 네트워크가 있었습니다.

 

또한 이전에도 Docker Compose할 떄 Service Discovery를 알아보았었는데, 어떤 서비스가 다른 서비스와 통신을 할 때 그 서비스의 위치를 자동으로 발견할 수 있는 기능입니다. 이를 위해서는 internal DNS가 필요한데 쿠버네티스상에서는 이를 etcd가 대신해 주고 있습니다. 어떤 서비스가 어떤 컨테이너를 가지고 있고 그 컨테이너의 위치가 어디인지 (IP 주소가 어디인지)를 전부 관리를 하는 것입니다. 그래서 해당 서비스가 재배포가 되거나 스케일링이 되서 서비스가 4대... 20대가 된다고 해봅시다. 이 떄 각각의 서비스의 위치를 파악해서 통신을 원할하게 하는 역할을 할 수 있게 됩니다. 또한 여러 컨테이너로 구성된 서비스의 경우 Load Balancing기능을 사용해서 트레픽을 분산시켜줄 수도 있을겁니다. 

 

그리고 컨테이너가 스스로 죽을 수 있는데, 이 떄 다시 살아나게 할 수 있는 Self Healing기능을 제공하기도 하며, 컨테이너와 그 컨테이너의 설정, 비밀 정보들을 주입할 필요성이 있게 됩니다. 그 떄 Configuration Management를 사용할 수 있습니다. 또한 이를 위한 UI를 제공합니다. 

 

마지막으로 어플리케이션에서 영구적인 저장소가 필요할 때, 외부 저장소를 관리하는 기능도 컨테이너 오케스트레이션 시스템에서 제공하고 있습니다.

 

정리하면 컨테이너 오케스트레이션 시스템은 여러 머신으로 구성된 클러스터 상에서 컨테이너를 효율적으로 관리하는 시스템입니다.

 

왜 쿠버네티스인가?

Planet Scale

행성 스케일이라는 것이 있습니다. 구글에서는 수십억게의 컨테이너를 운영할 정도로 상상할 수 없을 정도의 서비스 운영을 하고 있습니다. 이것을 뒷받힘 하는 기술로 만들어 졌습니다. 그래서 쿠버네티스는 수십억개의 컨테이너를 운영할 수 있다는 원칙을 기반으로 진행됩니다. 

 

Never Outgrow

쿠버네티스는 각각의 리소스들이 다양한 요구사항을 만족할 수 있는 유연함을 가지게 됩니다. 필요한 기능이 없다고 하면 CRD를 통한 기능을 확장을 손쉽게 할 수 있습니다. 또한 테스트용 로컬 규모부터 글로벌 서비스 규모까지 유연하게 크기 조정이 가능합니다.

 

Run Anywhere

또한 쿠버네티스가 리눅스 컨테이너를 기반으로 작동하는 기술이다 보니까, 대부분의 리눅스 환경에서 동작하기 때문에 환경 이동에 제약이 없게 됩니다. 온프레미스 / 퍼블릭 클라우드 / 하이브리드 환경 어디서나 동작 가능하게 됩니다.

 

주의사항

복잡한 클러스터 구성

애초에 쿠버네티스 자체가 여러 컴포넌트로 구성된 분산 시스템입니다. 그래서 각 컴포넌트에 대한 필요가 다 합니다. 그래서 매니지드 클러스터를 고려하면 좋을것 같습니다 ( AWS EKS, GKE, AKS )등을 사용하는 겁니다. 그래서 클러스터 컨트롤러 플래인, 마스터 노드에 대한 관리를 CSP ( Cloud Service Provider )에게 위임하는 것도 좋은 전략이라고 할 수 있을거 같습니다.

 

방대한 학습량

다른 컨테이너 오케스트레이션 시스템보다 다양한 지식을 필요로 합니다. 더 많은 요구 사항을 만족하는 만큼, 익혀야 하는 기능도 많게됩니다.

 

오버 엔지니어링

또한 운영해야 하는 서비스에 적합한가에 대해서도 생각해 보아야 합니다. 진짜 우리의 서비스에서 컨테이너 오케스트레이션 시스템이 필요한가?