컨테이너와 쿠버네티스 개요

A. 컨테이너란? 

컨테이너는 OS의 커널 위에서 cgroup, namespace, netfilter등과 같은 커널 기능들을 통해 프로세스를 cpu, memory, networking, filesystem의 특정 영역에 격리시켜 다른 공유 영역의 접근을 제한하고 독립적인 공간을 제공하는 기술입니다. 독립된 공간에 애플리케이션과 애플리케이션의 구동에 필요한 바이너리 및 라이브러리를 Docker나 Podman을 통해서 OCI(Open Container Initiative) 표준에 맞게 이미지화할 수 있으며 컨테이너 엔진 위에 배포, 관리 가능합니다

 

좀 더 간단히 말하자면 컨테이너는 애플리케이션을 환경에 구애 받지 않고 별도의 운영 환경을 제공해 주는 기술입니다. 즉, 운영체제에서 실행되는 프로세스를 별도로 격리해 격리된 프로세스에 실행 환결을 별도로 제공해 주어 해당 프로세스는 운영체제 상에서 실행되는 유일한 프로세스인 것처럼 작동합니다. 

 

컨테이너란?

 

컨테이너의 내용을 요약하자면 아래와 같습니다.

• 격리되어 있으며 자체 SW, 바이너리 및 구성을 하는 프로세스
• 로컬 환경, 가상 머신, 클라우드에 국한되지 않고 자유롭게 구성 가능
• OS에 종속적이지 않으며 컨테이너 엔지만 있다면 어디든 배포, 관리 가능

 

B. 컨테이너의 이점

컨테이너의 이점은 정말 많습니다. 그래서 그 중 대표적인 몇 가지만 정리하도록 하겠습니다.

 

1. 이동성

애플리케이션 컨테이너는 호스트 OS에서 추출하여 실행 가능한 소프트웨어 패키지를 생성합니다. 즉, 호스트 OS에 종속되거나 의존하지 않으면서 이동이 가능하게 하고 모든 플랫폼이나 클라우드 전반에서 일관되고 통일되게 실행되도록 합니다. 또한 개발자가 사용하는 OS 통합 방식은 애플리케이션 기능을 방해할 목적으로 추구하는 통합과 같은 불일치는 사용하지 않습니다.

 

2. 경량화

호스트 시스템의 OS 커널을 공유하며 추가 오버헤드의 영향을 받지 않기 때문에 서버의 효율성이 향상되고 서버 및 라이센스 비용은 절감됩니다. 또한 부팅할 OS가 없기 때문에 시작 시간도 빨라집니다.

 

3. 확장성

애플리케이션 컨테이너 기술은 고도의 확장성을 제공합니다. 애플리케이션 컨테이너는 서비스 지향 애플리케이션 설계를 사용하여 리소스를 사용 가능하게 하도록 기존 아키텍처를 재구성함

 

 

C. 쿠버네티스란? 

그렇다면 쿠버네티스란 무엇일까요?  쿠버네티스란 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리해 주는 오픈소스 시스템입니다. 쿠버네티스는 전 세계적으로 가장 대표적인 컨테이너 오케스트레이션 도구이며 오랫동안 구글 내부적으로 사용하던 컨테이너 클러스터 관리 시스템으로부터 출발하여 2013년도부터 쿠버네트 스라는 이름으로 오픈소스 프로젝트로 진행되고 있습니다. 여러 가지 많은 등장 이유가 있겠지만 인프라 환경의 진화가 가장 큰 이유입니다.

 

클라우드 컴퓨팅과 도커를 필두로 컨테이너 기술의 비약적인 발전에 따라 마이크로 서비스된 형태로 개발된 애플리케이션들을 쉽게 리소스들을 격리하고 확장성을 높일 수 있게 되었습니다. 

 

과거	현재
Monolithic	Microservices 들로 작게 나누고 Decoupled(낮은 응집도)
하나의 Release Cycle	서비스 컴포넌트 별로 Release Cycle
고정적인 애플리케이션 서버 집합	클러스터 단위로 확장성 있게 운영

 

하지만 분산된 구조의 대규모 확장성 있는 환경을 운영하는 것은 매우 어려운 일이며 다음과 같은 어려움에 직면하게 된다.

• Microservices들이 많아짐에 따라 운영의 어려움
• 에러 발생 시 디버깅이 어려움
• east-west 통신의 tracking이 어려움
• 어플리케이션의 컨테이너화에 따라 운영의 복잡성이 높아짐
• 빌드, 배포 자동화가 필요
• 컨테이너를 관리하는 신뢰성 있는 머신 클러스터가 필요
• 유연하고 확장 가능한 네트워크, 스토리지가 필요

이러한 어려움을 극복할 수 있도록 도와주는 도구가 쿠버네티스이며 애플리케이션과 인프라스트럭처의 진화의 단계에 중심에서 다양한 기능들을 제공하고 서비스를 효과적으로 운영 관리할 수 있도록 만들어 준다.

 

D. Kubernetes 컨셉

쿠버네티스는 마이크로서비스 혹은 하나의 큰 서버보다는 작지만 많은 서버를 분산 배포하여 운영하는 접근 방식이다. 서버와 클라이언트의 어플리케이션이 많은 에이전트들로 요청에 따른 응답을 할 것을 예상하도록 작성되어 있다. 한 가지 중요한 부분은 클라이언트가 서버 프로세스가 죽거나, 교체되거나, 일시적인 서버의 배포로 이어지는 것을 예상하고 있어야 한다. 또한, 커뮤니케이션은 API 호출 기반으로 유연하게 이루어진다. 구성 정보는 JSON 형태로 ETCD에 저장되어 있으며 커뮤니티에 의해 대부분 YAML로 작성된다. 쿠버네티스 에이전트는 데이터베이스에 저장되기 전에 YAML을 JSON으로 변환시켜 저장한다.

 

Kubernetes 컨셉

Control Plane

• kube-apiserver: API 서버는 REST를 통해 다른 모든 구성 요소가 상호 작용할 수 있도록 제공하는 프런트엔드 영역이며 Pod, Service, replicationcontrollers 등의 API 개체에 대한 데이터의 유효성을 검사하고 적용한다.
• kube-scheduler: 할당된 노드가 없는 새로 생성된 파드를 확인하여 실행할 노드를 선택하는 관리 영역이다.
• kube-controller-manager: 컨트롤러 프로세스를 실행하는 컴포넌트이며 다음과 같은 컨트롤러를 관리한다.
• node controller: 노드가 다운되었을 때 대응과 notice에 관한 책임을 가진다.
• Job controller: Job의 개체를 감시한 다음해당 작업이 완료될 때까지 실행되는 파드를 생성 관리 한다.
• Endpoints controller: 서비스와 파드를 연결시키는 역할을 담당한다.
• Service Account & Token controllers: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성한다.
• cloud-controller-manager: 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트이다. 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결된다.

Worker

• kubelet: 클러스터의 각 노드에서 실행되는 에이전트. Kubelet은 파드에서 컨테이너 관리 운영하는 주체이다.
• kube-proxy: 클러스터에 정의된 서비스의 네트워크 정책을 반영하고 서비스의 Pod에 대한 요청을 포워딩하는 규칙을 관리한다.

E. Kubernetes 장점 및 고려사항

장점

모든 리소스를 Code로 선언 및 관리할 수 있으며 GitOps, CICD 등을 활용하여 애플리케이션 배포를 자동화할 수 있으며 On-prem 및 Cloud 환경 agnostic 하게 컨테이너를 관리 운영 가능하다는 장점이 있다.

고려사항

쿠버네티스의 컨셉에 맞춰 애플리케이션의 변화(Scale out 구조, Microservice 형태)가 필요하며, 다양한 방법으로 개발조직을 쿠버네티스로 on-boarding 하여 사전 검증 필요하다. 또한 인프라 관점에서 쿠버네티스의 리소스들을 고려해서 설계하고 구축을 진행해야 하며 구축 완료 후에도 효과적으로 사용하기 위해 다양한 CNCF 생태계의 쿠버네티스 컴포넌트들을 본인의 환경에 맞게 조합해야 한다. 특히 그 생태계가 매우 방대하므로 Learning Curve 꽤 높고 충분한 시간과 테스트를 거친 후에 프로덕션 워크로드를 배포해야 한다.