[Kubernetes] Kubernetes 개념

0. 개요

쿠버네티스를 이해하기전 서버 시장의 상황..

수 년 전만 하더라도 대부분의 소프트웨어 어플리케이션은 하나의 프로세스 또는 몇 개의 서버에 분산되어 프로세스로 실행되는 거대한 모놀리스(Monolithic) 형태가 주를 이루었습니다. 이러한 레거시 시스템은 여전히 많이 펴져 있습니다. 엔지니어들은 장애가 발생하면 이를 수리하거나 정상적인 서버로 migration 등의 작업을 진행했었죠. 작업은 장애 원인과 인프라의 복잡도에 따라 오래 걸리거나 어려운 경우가 많았습니다.

그래서 모놀리스 레거시 시스템은 점차 사용자 및 운영자 관점에서 상황에따라서 편한 클라우드화 되며 선발대 기업들은 IaaS, PaaS, SaaS 등으로 클라우드 서비스를 세분화 했습니다.
오늘은 PaaS 시장의 주요 기술인 Kubernetes(이하 K8s)에 대해서 이야기하려 합니다.

1. 쿠버네티스와 컨테이너 런타임 엔진

쿠버네티스를 이해하기 전에 컨테이너를 먼저 이해하여야 합니다. 컨테이너는 OS, 어플리케이션 등의 파일을 하나의 런타임 환경으로 묶는 기술입니다. 생성된 컨테이너는 호스트 운영 체제의 커널을 공유하며 어플리케이션을 위한 격리된 환경을 제공합니다. 이를 이용하여 개발자는 자신의 어플리케이션을 구동하기 위하여 실행 환경, 의존성 등을 패키징(Container images)하고 이 이미지를 실행하여 격리된 프로세스로 실행합니다. 다시 말해서 컨테이너란 이미지화 되어있는 어플리케이션 프로세스를 격리하는 기술입니다. 이를 위해 필요한것이 컨테이너 런타임 엔진 이고 런타임 엔진에 대표적으로 Docker engin, CRI-O, conatinerd 등이 있습니다.
컨테이너 기술을 이용하면 컴퓨팅 리소스를 가상화 방식보다 더 작게 나눌 수 있습니다. 추상화된 리소스를 할당하는것이 아닌, 표면상으로는 OS 에서 작동하는 프로세스기 때문이죠.

 

출처 : https://www.redhat.com/ko/topics/containers/whats-a-linux-container

Linux 컨테이너(LXC, 리눅스 콘테이너)란? 개념, 종류, 사용법

 

 

운영자 입장에서는 이렇게 잘게 나눈 컨테이너를 효과적으로 관리하기 위한 새로운 가이드라인이 필요했습니다.

podman run -it --name ubuntu-dev ubuntu:latest
podman delete ubuntu-dev
podman exec ubuntu-dev /bin/bash ls

매번 이런 명령어를 치면서 인프라를 관리 할 수 없으니까요.

따라서 많은 Orchestration(구성, 조율, 관리)하기 위한 프로그램이 많이 나왔습니다. 새로운 시장이니 만큼 역사를 찾아보면 치열했지만, 그중에서 컨테이너 시장의 de facto(사실상, 공식, 표준) 가 된 Kubernetes(K8s, 쿠버네티스)를 소개합니다.

---

1.1 Kubernetes 란?

1.1.1 Kubernetes의 역사

오랜 시간 동안 구글은 보그(Borg 이후 Omega로 바뀐 시스템)라는 내부 시스템을 개발해 개발자와 관리자가 수천 개의 서비스를 관리하는데 사용했습니다. 개발자와 관리자를 위한 시스템인 만큼 개발과 관리의 단순화, 인프라 활용률을 중요시하게 생각했죠. 구글은 10년간 보그와 오메가를 비밀로 유지하다가 2014년에 그동안의 노하우를 기반으로 하는 쿠버네티스를 출시 했습니다.

1.1.2 쿠버네티스의 핵심 역할

개발자의 편의성
개발자가 인프라 서비스를 구현하지 않아도 됩니다. 관리자가 사전에 만들어둔 정책으로 리소스 분배, 스케일링, 복구, 다중화, 네트워크 등을 쿠버네티스는 자동적으로 수행합니다. 따라서 개발자는 어플리케이션의 실제 기능을 구현하는데 온전히 집중할 수 있습니다.

관리자의 리소스 컨트롤
관리자는 쿠버네티스로 구성한 클러스터 어디에서 어플리케이션이 실행되고 있는지 고민하지 않아도 됩니다. 쿠버네티스는 노드 상황을 자동적으로 파악해 어플리케이션의 재배치등이나 장애복구를 진행하기 때문입니다. 리소스의 수동 스케줄링보다 더 빠르고 정확합니다.

---

2 쿠버네티스 클러스터의 구성

쿠버네티스의 설명은 간략하게 했으니, 하드웨어 수준에서 쿠버네티스 클러스터가 어떻게 구성되는지 알 필요가 있습니다. 쿠버네티스는 기본적으로 마스터노드, 워커노드로 구성됩니다.

• 마스터 노드 : 쿠버네티스 시스템을 제어하고 관리하는 컨트롤러 플레인을 실행하는 노드입니다.
• 워커 노드 : 마스터 노드를 통해서 배포되는 Pod를 실행하는 노드입니다.

[!NOTE] Pod(파드) 란?
쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위 입니다. 파드는 한개 이상의 컨테이너를 보유하여 작동합니다.

 

위 사진은 가장 기본적인 쿠버네티스 구성이다. API서버는 CM(컨트롤매니저), kubelet 등의 명령을 받은 다음 etcd에 변동사항을 저장하고 Worker Node의 kubelet에 명령을 전달합니다. kubelet은 컨테이너 런타임을 동작시켜 Pod를 관리합니다. 노드별로 자세하게 어떻게 동작하는지 알아보겠습니다.

2.1 Control Plane

컨트롤 플레인 컴포넌트는 쿠버네티스 클러스터의 전반적인 결정을 수행하고 클러스터 이벤트를 감지하고 반응합니다. 컨트롤 플레인의 컴포넌트들은 어떤 노드에서도 Pod 형태로 구동될 수 있습니다. 구성 요소와 기능은 아래와 같습니다.

2.1.1 kubernetes API server

쿠버네티스 시스템 구성 요소는 오직 API 서버하고만 통신합니다. 서로 직접 통신하지는 않습니다. API 를 통해서 각 노드에 오브젝트(ex. Pod)를 조작할 수 있습니다. 기본적으로 K8s 사용자는 kubectl 을 이용하여 K8s 환경을 조작합니다. 노드간 API server 가 특별한 일을 하는것은 아닙니다. API 서버는 kubernetes 환경을 위해 배포된 컨트롤러 매니저가 리소스를 etcd 에 저장하고 타 리소스의 변경 사항을 클라이언트에 통보하는것 외에 다른 일을 하지 않습니다.

2.1.2 Scheduler

Pod 가 생성될 때 노드에 할당되지 않은 상태에서 만들어진 Pod 를 감시하고, Pod가 배치될 적절한 노드를 탐색하여 배치합니다. 기본적으로 기본 Scheduler인 kube-scheduler 의 룰을 따르되 필요 따라 관리자가 scheduler 를 새로이 만들고 설계할 수 있습니다. (참고 : https://kubernetes.io/ko/docs/concepts/scheduling-eviction/kube-scheduler/)

2.1.3 etcd

모든 오브젝트(Pod, Replicas, Service, Secret 등) 는 API 서버가 다시 시작되거나 실패하더라도 유지하기 위해 매니페스트가 영구적으로 저장될 필요가 있습니다. 이를 위해 쿠버네티스는 빠르고, 분산되어 저장되며, 키-값 구조의 저장소를 제공하는 etcd 를 사용합니다. 쿠버네티스 API 서버만이 etcd와 직접적으로 통신하는 유일한 구성 요소 입니다. 다른 구성 요소는 API 서버로 간접적으로 데이터에 접근합니다. 이를통해 *"낙관적 잠금 시스템(Optimistic Concurrency Contro)"* 뿐만 아니라 유효성 검사를 하는 등의 이점을 얻습니다. 쿠버네티스가 클러스터 상태와 메타데이터를 저장하는 유일한 장소가 etcd 라는 것은 매우 중요한 정보입니다.

2.1.4 control manager

시스템을 관리자가 원하는 모습으로 구성되도록 하는 컨트롤러의 집합입니다. 각 컨트롤러는 관리자의 의도대로 수정할 수 있습니다. 종류는 아래와 같습니다.
- Replication Manager, Replicaset
- DaemonSet (데몬셋), Job Controller (잡컨트롤러)
- Deployment Controller (디플로이먼트 컨트롤러)
- Statefulset Contorller (스테이트풀셋 컨트롤러)
- Node Controler (노드 컨트롤러)
- Endpoint Controler (엔드포인트 컨트롤러)
- Namespaced Controler (네임스페이스 컨트롤러)
- PhysicalVolumeControler (이하 PVC, 피지컬볼륨 컨트롤러)
- 그 외
허나 컨트롤 플레인은 쿠버네티스 시스템 운영의 한 부분만을 처리하기 때문에 쿠버네티스 클러스터 안에서 어떤 일이 벌어지는지 이해하기 위해서는 Kubelet과 쿠버네티스 서비스 프록시의 기능을 이해해야 합니다.

2.2 Worker node

쿠버네티스 컨트롤 플레인 일부로써 마스터 노드에서 실행되는 다른 컨트롤러와 달리, Kubelet과 서비스 프록시는 실제 파드 실행되고있는 워커 노드에서 실행됩니다. 또 타 구성요소는 Pod로 실행이 가능하지만 kubelet 과 서비스 프록시는 데몬으로만 실행이 가능합니다.

2.2.1 Worker nodekubelet

워커 노드에서 실행하는 모든 것을 담당하는 구성 요소입니다. 실행 중인 노드를 노드 리소스로 만들어서 API 서버에 등록한뒤 지속적으로 모니터링하여 노드에 파드가 스케줄링되면, 파드의 컨테이너를 실행합니다(이때 지정된 컨테이너 런타임을 사용한다). 이후 컨테이너의 상태, 이벤트, 리소스 사용량을 API 서버로 보냅니다.

2.2.1 쿠버네티스 서비스 프록시

모든 워커 노드는 클라이언트가 쿠버네티스 API 로 정의한 서비스에 연결 할 수 있도록 해주는 kube-proxy도 같이 실행합니다. kube-proxy는 서비스의 IP와 포트로 들어온 서비스를 지원하는 파드 중 하나와 연결시켜줍니다. 서비스가 둘 이상의 파드에서 지원되는 경우 프록시는 파드 간에 로드 밸런싱을 수행합니다.