kubernetes : overview

Kubernetes - overview

 

Application 배포의 흐름

전통적인 어플리케이션 구성 환경의 경우 물리 리소스인 하드웨어 위에 미들웨어로서 운영체제를 구축하고 해당 운영체제 위에서 소프트웨어를 배포하여 서비스를 제공하게 된다.
그러나 이러한 기존 방식에서는 수시로 변동되는 서비스 요청에 따라 네트워크, 스토리지 등의 하드웨어 자원을 효율적으로 사용하기가 어렵다.
이에 자원의 효율적 사용을 위하여 가상화 개념이 도입되었다.
인프라 제공자들은 이러한 가상 머신(Virtual Machine)을 사용하여 완전히 격리된 공간을 제공하였고, 이를 통하여 기존 방식의 자원사용의 비효율성을 해결할 수 있었다.
그리고 2013년 초에 도커 컨테이너 서비스가 등장하면서 컨테이너를 통한 배포가 활발해졌다.
컨테이너는 가상머신에 비하여 가볍다는 점을 이용하여 어플리케이션의 개발/배포를 더욱 용이하게 하였고, 인프라와의 종속성을 단절하여 on-premise 환경 이외에의 클라우드 환경에서도 사용할 수 있었다. 가상화 및 컨테이너 기술 자체에 대한 내용은 해당 주제를 참고하도록 한다.

 

Container 배포 방식의 한계

그러나 배포 방식의 변화에 따라 등장하게 된 컨테이너 기술 역시 부족한 부분은 존재한다. 운영 환경에서의 안정성을 그 예로 들어보자.
BM 혹은 VM 위에 도커와 같은 컨테이너 엔진(플랫폼)을 구축한 후에 주요 어플리케이션을 컨테이너로 구동하여 서비스를 제공할 수 있다.
Web, was, db, Queue 등의 마이크로서비스화 되어진 여러 컨테이너가 유기적으로 연계하여 서비스를 제공하는 중에 특정 컨테이너가 예기치 못한 이유로 제거될 경우에는 당연하게도 서비스가 제대로 동작하지 않게 된다. 이러한 문제는 기존의 배포 방식에서도 마찬가지이다.
물론 컨테이너 엔진 자체에 옵션을 설정하여, 특정 컨테이너의 상태를 체크(health check)하고 정상 동작하지 않거나 제거되었을 경우 자동으로 컨테이너를 다시 생성하게 할 수 있다.
그렇다면 해당 BM/VM 자체에 문제가 발생한 경우는 어떨까? 컨테이너 엔진의 하드웨어 역할을 하는 BM/VM 에 장애가 발생한 경우에는 컨테이너의 재시작 옵션과 무관하게 서비스에도 장애가 발생하며 이는 관리자가 해당 BM/VM 을 재구동하여 컨테이너 엔진을 재시작 한 뒤에야 복구가 가능하다.
즉, 컨테이너만을 이용한 배포/운영 방식은 기존의 전통 어플리케이션 구성 방식에 비하여 빠른 빌드/배포/운영의 장점은 가지고 있으나
운영 중 장애복구 상황에 대해서는 기존의 방식과 (심지어 VM의 경우에도) 동일한 문제점을 안고 있는 것이다.

 

Container Orchestration Platform

이에 기존 컨테이너 서비스의 운영 장애처리 뿐 아니라 컨테이너 레벨에서 연계 배포 등을 지원하기 위하여, 여러 개의 BM/VM 클러스터 위에서 컨테이너를 분산 관리해줄 수 있는 플랫폼을 사용하게 된다.
‘컨테이너 오케스트레이션 플랫폼’은 이러한 요구사항으로 등장하게 되었으며, 여기서 다루는 Kubernetes 이외에도 Docker swarm, Apache Mesos 등이 있다.
kubernetes 는 컨테이너에 대한 프레임워크 레벨에서 아래와 같은 기능들을 제공하여, 컨테이너의 운영 배포를 지원한다.

• 네트워킹 : 서로 다른 컨테이너 간의 서비스 식별을 통하여 모듈간 연계성을 높이며, 컨테이너에 많은 트래픽이 유입되는 경우에 대하여 논리적 로드밸런서를 통하여 같은 목적의 여러 컨테이너에 트래픽을 분산 제어 할 수 있다.
• 스토리지 : 컨테이너가 사용하는 스토리지를 제어하여 컨테이너가 여러 클라우드 공급자의 저장소나 로컬 저장소 등을 사용할 수 있도록 관리할 수 있다.
• 장애복구 : 정상 동작하지 않는 컨테이너를 감지하여 제거하고 새로 구동하며, 특정 BM/VM 자체에 문제가 발생했을 경우 해당 장비에 위치한 컨테이너를 상태가 양호한 장비에 재구동하여 장애 발생 시간을 최소화 한다.
• 보안관리 : kubernetes 플랫폼 자체적으로 보안 기능을 지원하여 암호, 토큰 등을 통한 중요 정보의 저장/관리 기능을 지원한다. 이를 통하여 중요 정보를 어플리케이션 레벨이 아닌 컨테이너 레벨에서 관리할 수 있다.
•  

Kubernetes 구성요소

Kubernetes 플랫폼은 여러 대의 장비를 논리적인 클러스터로 묶는다. 클러스터의 구성이 되는 장비를 ‘노드’ 라고 지칭하며 노드가 구성하는 클러스터를 ‘kubernetes 클러스터’ 라고 한다.
이후의 포스팅에서는 kubernetes 라는 표현의 축약어인 k8s 를 표현을 사용하며, 클러스터의 성격을 강조하기 위하여 ‘k8s 플랫폼’ 뿐 아니라 ‘k8s 클러스터’의 표현도 병용한다.

k8s 클러스터에 구성되는 컴포넌트는 ‘컨트롤 플레인 컴포넌트’와 ‘노드 컴포넌트’ 로 구성될 수 있다.

 

컨트롤 플레인 컴포넌트

컨트롤 플레인 컴포넌트는 클러스터의 전반적인 중요 결정을 수행하고 클러스터에 구동되는 ‘Pods(이하 파드. 후술할 컨테이너의 집합)’를 생성/삭제/배치한다.
이 컴포넌트는 어떤 노드에도 구성될 수 있으나, 많은 경우 특정 노드에 중심적으로 설치되어 일명 ‘마스터 노드’ 로서의 역할을 수행한다.
이렇게 특정 노드를 마스터 노드로 지정하여 컨트롤 플레인 컴포넌트를 구동할 경우 마스터 노드가 아닌 일반 노드는, 워커 노드로 분류되어 표현된다.
이러한 마스터/워커 노드의 구분은 강제사항은 아니나 관리를 쉽게 해주며, 추후 클러스터 고가용성 구축을 위하여도 권장된다.

• kube-apiserver : kubernetes API 를 노출하는 컴포넌트로 노드의 kubelet 컴포넌트와 통신하여 노드 및 클러스터를 관리한다.
• kube-scheduler : 노드의 상태를 감지하여, 파드를 배치하는 역할을 수행한다.
• kube-controller-manager : 현재 노드 및 파드의 상태를 감지하여 노드의 장애를 감지하고 파드를 재배치하거나, 노드 위의 파드의 수를 지정된 수로 조정/유지한다.
• etcd : 고가용성 키-값 저장소로 k8s 클러스터 자체의 모든 데이터를 저장한다.

 

노드 컴포넌트

노드 컴포넌트는 파드를 유지시키는 역할을 담당한다. (마스터/워커 노드의 지정과는 별도로 어떤 경우에도) 모든 노드에 설치되어야 한다.

• kubelet : 각 노드에서 구동되는 주요 컴포넌트로, 컨트롤 플레인과 통신하여 컨테이너의 수명주기를 관리한다.
• kube-proxy : 클러스터 상의 노드 및 노드에서 구동되는 파드의 서비스간 연계를 담당한다. 네트워크 규칙도 관리하여 내/외부로 팟이 통신할 수 있도록 한다.
• CRI : Container Runtime Interface로, 노드 위에서의 컨테이너 실행을 담당한다. k8s 에서는 도커 이외에도 containerd, CRI-O 등을 지원한다.

 

Reference

• Kubernetes 공식 문서 : https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/
• Orchestration 에 관한 RedHat 문서 : https://www.redhat.com/ko/topics/containers/what-is-container-orchestration