[Kubernetes] 쿠버네티스란?

쿠버네티스란 무엇인지 기본 개념과 전반적인 아키텍처에 대해 살펴 보고 그 장점에 대해 알아보도록 하겠다.

 

쿠버네티스는 여러 서버로 구성된 클러스터 환경에서 컨테이너화된 애플리케이션을 관리하는 플랫폼입니다.
컨테이너의 배포, 확장, 스케줄링을 자동화할 수 있으며, 원래 구글이 개발하여 현재는 CNCF(Cloud Native Computing Foundation)에서 관리하고 있습니다.

 

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

컨테이너 오케스트레이션은 다수의 서버에서 컨테이너 전반적인 라이프사이클을 관리해주는 플랫폼입니다.

구체적인 역할을 다음과 같이 나타낼 수 있습니다.

• 실행 및 배포를 책임진다
• 이중화/가용성을 보장한다
• 수평 확장/축소를 관리한다
• 스케줄링을 담당한다
• 네트워크 설정을 관리한다
• health 상태를 모니터링 한다
• 설정값을 관리한다.

쉽게 말해, 데이터 센터 운영체제라고 볼 수 있습니다.
여러 대의 컴퓨터를 하나의 큰 시스템처럼 다룰 수 있도록 추상화해 주기 때문이죠.

 

쿠버네티스의 기본 개념

쿠버네티스는 일반적인 운영체제가 제공하는 기능(하드웨어 추상화, 자원 관리, 스케줄링 등)을 클러스터 차원에서 제공합니다.
또한 사용자는 kubectl이라는 CLI 도구로 이를 제어하는 구조이지요. (GUI는 아니지만 충분히 강력하다)

 

K8s is Cattle

쿠버네티스를 설명할 때 자주 나오는 비유가 있습니다.
바로 서버를 Pet(애완동물)이 아닌 Cattle(가축)처럼 관리한다는 개념입니다.

 

과거에는 서버 한 대 한 대에 특별한 이름을 붙이고, 문제가 생기면 직접 들어가 고쳐 쓰는 경우가 많았습니다.
마치 애완동물을 돌보듯이 개별 서버를 애지중지 관리한 것이죠.

 

하지만 쿠버네티스에서는 이야기가 다릅니다. 서버는 가축처럼 무리 단위로 관리됩니다.
가축이 한두 마리 줄어들어도 큰 문제가 되지 않듯, 서버 한두 대가 고장 나도 나머지 서버들이 그 일을 대신합니다.
즉, 특정 서버가 죽더라도 서비스 자체는 끊기지 않고 정상적으로 동작합니다.

 

그래서 서버마다 “웹 서버”, “모니터링 서버”처럼 특별한 이름을 붙이지 않습니다.
모두 동일한 워커 노드로 취급되며, 역할은 필요할 때마다 동적으로 할당됩니다.

 

 

Desired State(바라는 상태)

쿠버네티스는 “사용자가 원하는 최종 상태”를 기억하고 현재 상태를 계속 맞추려 합니다. (like 에어컨이 희망 온도)

그래서 사용자의 요청에 따라 현재 상태가 바라는 상태(최종 배포 상태)와 동일해지도록,

사전에 미리 정의된 특정 작업을 수행합니다.
덕분에 컨테이너가 죽더라도 Desired State를 알기 때문에 자가 치유가 가능하게 되지요.

 

Controller(컨트롤러)

Desired State를 유지하기 위해 컨트롤러가 Control-Loop를 돌며 리소스를 모니터링하고 필요한 작업을 수행합니다.
예를 들어 Job 리소스를 만들면, 컨트롤러는 배치 작업을 실행해줍니다.

 

바라는 상태를 선언하면 그 상태로 변경하는 주체를 컨트롤러라고 합니다.

이를 위해 컨트롤러는 control-loop를 돌며 특정 리소스를 지속 모니터링 하며, 사용자가 생성한 리소스 이벤트에 따라 사전에 정의 된 작업을 수행합니다.

예로 Job이라는 리소스를 생성하면 그에 맞는 배치 작업 프로세스를 실행해주지요.

Resource(쿠버네티스 리소스)

쿠버네티스는 모든 것이 리소스로 표현되고 Pod, ReplicaSet, Deployment 등 다양한 리소스가 존재합니다.

(모두 세부 정의와 역할이 다 다르지만 리소스라 표현됩니다.)

가장 기본적인 리소스인 Pod는 하나 이상의 컨테이너를 가지는 최소 실행 단위입니다.

쿠버네티스에서 프로세스(컨테이너)를 실행한다는건 Pod리소스를 생성한다는 것과 같다 봅니다.

(완벽하게 동일하지는 않다고 합니다.)

Declarative Command(선언형 커멘드)

쿠버네티스는 선언형 커멘드를 지양합니다.

이는 직접 시스템의 상태를 바꾸는게 아닌 Desired State를 선언적으로 기술하여 명령을 내리는 방법을 말합니다.

예시로 HTML 문서를 보면 어떤 명령을 수행 해야 할지 정보는 없지만,

무엇을 해야할지 선언은 되어있는 걸 알 수 있습니다.

이와 반대되는게 명령형 커멘드지요. (SQL 쿼리가 예가 되겠다)

 

쿠버네티스는 아래와 같이 YAML형식을 통해 선언형 명령을 내립니다.

//예시
apiVersion: v1
kind: Pod
metadata:
    name: mypod
sepc:
    containers:
    - image: nginx
        nameL nginx

이를 ‘YAML 정의서’라 부릅니다.

 

쿠베에 어떤 명령을 전달할 때, 옵션값을 수정할 때 YAML property를 추가하거나 수정하게 됩니다.

모든 설정값을 외울 필요는 없습니다.
최소 필수값을 채워 리소스를 생성하면,
나머진 알아서 쿠베가 기본값으로 리소스를 생성한다고 합니다.

Namespace(네임스페이스)

쿠버네티스엔 클러스터를 논리적으로 분리하는 네임스페이스 개념이 있습니다.

물리적으로 하나의 쿠버네티스 클러스터 위에 논리적으로 서로 다른 네임스페이스로 나눌 수 있고,

서로 다른 설정(권한,네트워크 정책 등)을 설정할 수 있습니다.

쿠베의 리소스는 네임스페이스 레벨 리소스, 클러스터 레벨 리소스로 나눌 수 있다.
Pod, Deployment, Service와 같이 대부분의 쿠버네티스 리소스가 네임스페이스 안에 포함된다.
Node, PersistentVolume, StorageClass와 같이 네임스페이스 영역과 상관없이 클러스터 레벨에 존재하는 리소스도 있다.

Label&Selector(라벨&셀렉터)

쿠버네티스엔 독특한 질의 체계가 존재하는데,

톡정 리소스 그룹에 명령전달, 정보확인 등을 할 때 라벨링 시스템을 이용합니다.

리소스에 key-value 형식의 태그정보를 붙인 후,

이태깅한 리소스를 찾기 위해 셀렉터를 이용해 특정 key-value를 가진 리소스만 추출할 수 있습니다.

이 메커니즘을 통해 리소스는 느슨한 연결의 유연한 구조를 가지게 됩니다.

서비스 탐색

클러스터내에서 통신하기 위해선 Service Endpoint가 필요합니다.

이를 통해 다른 컨테이너(Pod)와 통신 할 수 있는데요.

이를 위해 끝점의 접속 정보를 알아야 하는게 바로 서비스 탐색입니다.

쿠베는 DNS기반 서비스 탐색을 지원해 새로운 서비스 IP를 찾을 필요 없습니다.

이 기능은 Service리소스를 이용해 제공합니다.

설정관리

설정값 및 민감 정보를 플랫폼 레벨에서 관리할 수 있는 매커니즘을 재공합니다.

서버마다 필요한 설정값을 저장하거나 동기화 문제를 직접 해결 할 필요없이

클러스터에서 재공하는 설정값 관리 기능을 활용할 수 있지요.

ConfigMap또는 Secret이라는 리소스를 이용해 컨테이너의 설정을 관리하게 됩니다.

 

아키텍처

쿠버네티스는 일반적인 클러스터 시스템과 비슷하게 크게 마스터와 워커 노드로 구분됩니다.

 

마스터 노드

• kube-apiserver: 클러스터의 진입점 역할을 하는 API 서버
• etcd: 모든 메타데이터 저장소
• kube-scheduler: 컨테이너를 어느 노드에 배치할지 결정
• kube-controller-manager: Desired State 유지 및 이벤트 처리
• cloud-controller-manager: 클라우드 자원 연동

워커 노드

• kubelet: 마스터 명령에 따라 컨테이너 실행/종료 관리
• kube-proxy: 네트워크 트래픽 라우팅 담당
• Container Runtime: 실제 컨테이너를 실행하는 환경(Docker 등)

장점

마지막으로 위 개념을 통한 쿠버네티스가 가지는 대표적인 장점을 정리해보겠습니다.

• 실행 환경 고립화: 컨테이너 기반으로 어디서든 동일한 실행 환경을 보장한다.
• 리소스 관리: CPU·메모리 자원을 제한하고 효율적으로 분배한다.
• 스케줄링: 워크로드를 적절한 노드에 자동으로 배치한다.
• 프로세스 관리: 컨테이너를 직접 다루지 않고, 클러스터 레벨에서 마스터 API 서버를 통해 애플리케이션을 손쉽게 제어한다.
• 통합 설정 관리: ConfigMap과 Secret으로 환경설정과 보안정보를 분리해 관리한다.
• 손쉬운 장애 대응: 장애가 발생한 파드를 자동으로 복구하고 재배치한다.
• 자동 확장: 트래픽 변화에 따라 파드와 노드를 자동으로 늘리거나 줄인다.
• 하이브리드 클라우드 운영: 다양한 클라우드와 온프레미스 환경에서 동일하게 동작한다.
• 자가치유(Self-Healing): 선언된 상태를 유지하기 위해 끊임없이 리소스를 복구한다.
• 배포 자동화: 관리자가 원하는 상태(Desired State)를 선언하면 쿠버네티스가 적절한 노드에 파드를 자동 배치하고, 롤링 업데이트 및 롤백까지 자동으로 수행한다.

 

지금까지 쿠버네티스의 전반적 개념과 아키텍처, 장점을 정리해보았습니다.

다음 부터는 실제로 쿠버네티스를 사용해보며 체득해보도록 하겠습니다