Kubernetes

이민기·2024년 4월 15일

DevOps

목록 보기

4/4

개요

기존 배포 시대: 초기에 조직은 물리적 서버에서 애플리케이션을 실행했습니다. 물리적 서버에서는 애플리케이션에 대한 리소스 경계를 정의할 방법이 없었으며 이로 인해 리소스 할당 문제가 발생했습니다. 예를 들어, 여러 애플리케이션이 물리적 서버에서 실행되는 경우 한 애플리케이션이 대부분의 리소스를 차지하여 결과적으로 다른 애플리케이션의 성능이 저하되는 경우가 있을 수 있습니다. 이에 대한 해결책은 각 애플리케이션을 서로 다른 물리적 서버에서 실행하는 것입니다. 그러나 리소스 활용도가 낮기 때문에 확장이 불가능했고 조직에서 많은 물리적 서버를 유지하는 데 비용이 많이 들었습니다.(너무 리소스 활용이 안좋음)

가상화 배포 시대: 솔루션으로 가상화가 도입되었습니다. 이를 통해 단일 물리적 서버의 CPU에서 여러 가상 머신(VM)을 실행할 수 있습니다. 가상화를 사용하면 VM 간에 애플리케이션을 격리할 수 있으며, 한 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스할 수 없으므로 보안 수준을 제공합니다.(가상화의 대표적인 장점이다.)

가상화를 사용하면 물리적 서버의 리소스 활용도가 향상되고 애플리케이션을 쉽게 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있으므로 확장성이 향상됩니다. 가상화를 사용하면 일련의 물리적 리소스를 일회용 가상 머신 클러스터로 제공할 수 있습니다.

각 VM은 가상화된 하드웨어 위에 자체 운영 체제를 포함한 모든 구성 요소를 실행하는 완전한 시스템입니다.(VM이 무거움 좀 더 가볍고 확장성을 늘리고 싶음)

컨테이너 배포 시대: 컨테이너는 VM과 유사하지만 애플리케이션 간에 운영 체제(OS)를 공유하기 위한 완화된 격리 속성을 가지고 있습니다. 따라서 컨테이너는 경량으로 간주됩니다. VM과 유사하게 컨테이너에는 자체 파일 시스템, CPU 공유, 메모리, 프로세스 공간 등이 있습니다. 기본 인프라에서 분리되므로 클라우드와 OS 배포판 간에 이식 가능합니다.(Docker가 최초로 Linux Ciontainers라는 제목으로 세상에 알렸다. 하나의 환경, 도커 엔진에서 여러 APP들이 충돌되지 않고 돌아감 기존 여러 VM을 만들어야할 때와 다르고 가볍고 APP간의 충돌도 일어나지 않아서 배포도 훨씬 쉬워짐)

Kubernetes의 등장

도커의 등장으로 컨테이너 기반 배포 방식이 보편화 되고, 많은 서비스들이 도커라이징 되어 이미지로 관리되기 시작했다.

점점 이미지가 많아지면서, 관리해야할 컨테이너와 서버들이 많아지게 되면서, 엔지니어의 일이 많아지게 되었다.

컨테이너를 배포할 서버, 죽은 컨테이너 살리기 등등 잡스러운 일이 많아져 역시나 자동화 시키고 싶은 개발들,,,

컨테이너들 의 관리를 자동화할 도구(컨테이너 오케스트레이션 툴)의 필요성이 대두되었다.

컨테이너를 쉽고 빠르게 배포 및 확장하고, 관리를 자동화 해주는 오픈소스 플랫폼
명칭은 조타수(helmsman)나 조종사(pilot)를 뜻하는 그리스어에서 유래
k8s라는 약자로 불리는데, 이는 k,s 사이의 8글자를 나타내는 약식 표기
단순한 컨테이너 플랫폼이 아닌 마이크로서비스, 클라우드 네이티브 플랫폼을 지향하고 컨테이너로 이루어진 것들을 손쉽게 담고 관리할 수 있는 그릇 역할이다. 서버리스, CI/CD, 머신러닝 등 다양한 기능이 쿠버네티스 플랫폼 위에서 동작한다.

쿠버네티스가 제공하는 기능들

서비스 디스커버리와 로드 밸런싱 - DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출
스토리지 오케스트레이션 - 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재
자동화된 롤아웃과 롤백 - 원하는 상태를 서술하고 현재 상태를 원하는 상태로 설정한 속도에 따라 변경 가능
자동화된 빈 패킹 - 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 제공
자동화된 복구(self-healing) - 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체
시크릿과 구성 관리 - 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리

쿠버네티스 구성요소

용어

노드(node)
- 쿠버네티스 클러스터를 구성하는 요소이며, 컨테이너 실행 환경을 제공하는 컴퓨터이다.
- 리눅스 운영체제를 기반으로 하며, 컨테이너 런타임 엔진의 설치를 필요로 한다.
파드(pod)
- 쿠버네티스에서 배포 가능한 최소단위이다.
- 하나이상의 컨테이너 그룹이며, 컨테이너 간 네트워킹이나 파일 시스템 공유를 지원한다.
- 또한 하나의 파드내에 컨테이너들은 동일한 생명주기를 공유한다.
디플로이먼트(deployment)
- 컨테이너의 배포 및 업데이트를 관리한다.
- 원하는 컨테이너 버전이나 개수 등을 지정한다.
- 롤링 업데이트, 블루/그린 배포 등을 지원한다.
- 배포 전략이나 롤백 정의가 가능하다.
서비스(service)
- 컨테이너 그룹에 대한 추상화 레이어이다.
- 네트워크 트래픽 라우팅 및 로드 밸런싱을 제공한다.
- 서비스 포트 및 셀렉터를 통해 컨테이너를 연결한다.
- 안정적인 서비스 제공을 위한 고가용성을 지원한다.
- 실제로 외부에 보이게 노출시켜주는 역할을 한다.
볼륨(volume)
- 컨테이너의 영구 저장 공간을 제공하며, 데이터 손실을 방지하고, 공유 가능하하다.
- 다양한 유형의 볼륨을 지원한다.(NFS, AWS EBS 등)
클러스터(cluster)
- 여러 노드로 구성된 쿠버네티스 환경이며, 컨테이너 애플리케이션을 실행 및 관리한다.
- 고가용성 및 확장성을 제공하며, 단일 도는 여러 클라우드 환경에서 운영 가능하다.

Kubernetes를 배포하면 클러스터가 생성된다. Kubernetes 클러스터는 Worker mechine set로 구성됩니다. 노드, 컨테이너화된 애플리케이션을 실행합니다. 모든 클러스터에는 하나 이상의 worker node가 있다.

Worker node는 다음을 호스팅한다. Pod이는 애플리케이션 워크로드의 구성 요소이다. 그만큼 제어 평면에서 클러스터는 작업자 노드와 Pod를 관리한다. 프로덕션 환경에서 제어 평면은 일반적으로 여러 컴퓨터에서 실행되고 클러스터는 일반적으로 여러 노드를 실행하여 내결함성과 고가용성을 제공다.

쿠버네티스'제어 평면’(Control plane)의 핵심은 API 서버이다. API 서버는 최종 사용자와 클러스터의 여러 부분, 외부 구성 요소가 서로 통신할 수 있는 HTTP API를 제공한다.

Kubernetes API를 사용하면 Kubernetes에서 API 개체(예: Pod, 네임스페이스, ConfigMap 및 이벤트)의 상태를 쿼리하고 조작할 수 있다.

Workload

쿠버네티스에는 workload라는 오브젝트/컴포넌트/어떤 종류의 구성요소도 존재하지 않는다. 보통 이 단어는 클러스터에서 실행하려는 작업이나 서비스 등을 가리키는 말로 종종 사용된다. (쿠버네티스에서는 "쿠버네티스 상에서 작동되는 애플리케이션"을 의미하며, 클라우드 분야에서는 "어떤 애플리케이션을 실행할 때 필요한 IT 리소스의 집합"이라는 의미로 통용된다. )

워크로드가 단일 컴포넌트든 함께 작동하는 컴포넌트 집합이든 관계없이, 쿠버네티스에서는 워크로드를 일련의 파드 집합 내에서 실행한다. 사용자를 대신하여 파드 집합을 관리하는 워크로드 리소스를 사용할 수 있는데, 이러한 리소스는 지정한 상태와 일치하도록 올바른 수의 올바른 파드 유형이 실행되고 있는지 확인하는 컨트롤러를 구성한다.

Kubernetes API를 사용하여 Pod보다 높은 추상화 수준을 나타내는 워크로드 object를 생성한 다음 정의한 워크로드 개체의 규격에 따라 Kubernetes 제어 평면(control plane)에서 자동으로 Pod 개체를 관리한다.

워크로드 관리를 위한 기본 제공 API는 다음과 같다.

디플로이먼트

파드와 레플리카셋에 대한 선언적인 업데이트를 제공하는 리소스다. 롤링 업데이트(Rolling Update)를 비롯하여 애플리케이션 버전 및 배포 관리에 주로 쓰인다. 레플리카셋이 파드들의 상태 체크와 개수 유지를 담당한다면, 디플로이먼트는 레플리카셋을 포함하는 상위 객체로서 애플리케이션 또는 서비스 단위의 관리를 위해 쓰인다고 보면 된다.

레플리카셋

상용 환경에서 애플리케이션을 오직 하나의 파드로만 운영하는 경우는 거의 없다. 다운 타임 없는 안정적인 서비스를 위해서, 대부분의 경우는 여러 개의 파드를 동시 운영하게 된다. 이때 같은 애플리케이션을 위해 동시 구동되는 파드들의 집합을 레플리카(Replica)라고 한다. 레플리카셋(ReplicaSet)은 레플리카 구성을 갖춘 파드들의 배포 규격을 정의하고 이를 관리하면서, 규격에 정의된 수 만큼의 파드가 언제나 정상 구동될 수 있도록 보장하는 역할을 한다. 만약 어떤 파드가 오류로 인해 정지되면, 동일한 스펙의 새 파드를 즉시 다시 배포시킨다. 쿠버네티스에서 사용되는 중요한 개념 중 하나가 바로 선언적 구성이다. 특정한 동작을 지시하는 것(파드를 3개 만들어라)이 아니라, 특정한 상태의 유지를 선언(3개의 파드를 유지시켜라)하는 것으로 시스템을 구성하는 개념이다. 이 개념의 대표적인 구현체 중 하나가 레플리카셋이다. 파드를 3개 갖고 싶다고 선언했는데 원치 않는 상황으로 인해 파드가 삭제되거나 노드가 고장났다면, 해당 파드를 복제하여 가용한 워커 노드에 다시 채워넣는 방식으로 처음에 선언했던 상태를 계속 유지시킨다.

스테이트풀셋

스테이트풀셋은 애플리케이션의 상태를 저장하고 관리하는데 사용되는 리소스다. 파드 구성과 유지, 스케일링 측면에서 디플로이먼트와 거의 동일한 특성을 가진다. 다른 점이 있다면, 스테이트풀셋은 디플로이먼트와 달리 각 파드의 순서와 고유성을 보장하며 각각에 영구 스토리지(볼륨)를 할당한다는 것이다. 모든 파드가 각각 고유하며 영구적인 식별자를 갖는다. 각각의 파드에는 각각의 영구적인 스토리지(볼륨)가 할당된다. 파드가 삭제되어도 볼륨은 남으며, 그 자리에 새로 생성된 파드는 해당 볼륨을 다시 이어 받는다. 추가적으로 스테이트풀셋에 필요한 헤드리스 서비스(Headless Service)를 함께 만들어줘야 한다.

데몬셋

데몬셋은 모든 노드, 또는 특정 레이블을 가진 노드에 하나씩의 동일한 파드를 구동하게 해주는 리소스다.

해당되는 노드에 오직 하나씩만 배치한다는 점에서 디플로이먼트 또는 스테이트풀셋과 다르며, 따라서 별도의 레플리카 설정을 하지 않는다. 데몬셋이 구동 중인 클러스터에서 노드가 추가되면 해당 노드에도 데몬셋의 파드가 배치되지만, 삭제된 노드에 있던 데몬셋 파드가 다른 노드로 옮겨지지는 않는다.

데몬셋은 주로 워커 노드에 리소스 모니터링용 애플리케이션, 또는 로그 수집기를 배포할 때 쓰인다.

네임스페이스

쿠버네티스는 하나의 동일한 물리 클러스터를 공유하는 가상 클러스터를 지원하는데, 이것을 네임스페이스(Namespace)라고 한다. 클러스터의 자원을 여러 사용자나 용도에 따라 나누는 기능이 필요할 때 쓴다. 네임스페이스는 워크로드 리소스는 아니지만, 하나의 클러스터 안에서 다양한 워크로드 리소스들을 필요에 따라 격리하는 데에 쓰인다.

Why?

실제 프로젝트에서는 개발 단계에 따라 여러 환경(Dev, Staging, Production, etc...)을 동시 운영하게 될 수 있다. 네임스페이스는 별도로 물리적인 호스트 환경의 격리 없이, 이처럼 상호 다른 환경의 특성에 맞게 정책과 리소스량을 정하여 격리된 환경을 만들 수 있는 것이다.

예를 들어, 같은 네임스페이스 안에서 리소스의 명칭은 반드시 고유해야 하지만, 다른 네임스페이스들을 함께 통틀어서 고유할 필요는 없다. 정책(Policy), 리소스 호출 등도 네임스페이스 범위를 기준으로 적용된다.

kubectl get 명령어로 특정 유형의 리소스 목록을 조회할 때, 이 명령은 현재 유효한 네임스페이스의 범위 안에서만 적용된다. 별도로 특정 네임스페이스를 현재 작업 환경으로 지정한 상태가 아니라면, 기본값인 default 네임스페이스에 속한 리소스만 조회된다.

기본으로 주어지는 초기 네임스페이스

default : 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
kube-system : 쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스
kube-public : 모든 사용자(인증되지 않은 사용자 포함)가 읽기 권한으로 접근할 수 있는 네임스페이스다. 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 다만 이 특성은 단지 관례로서 적용되어 있을 뿐, 필수적인 사항은 아니다.
kube-node-lease : 클러스터가 스케일링될 때 노드 하트비트의 성능을 향상시키는 각 노드와 관련된 리스(lease) 오브젝트에 대한 네임스페이스

컨테이너

컨테이너화란 소프트웨어 코드를 라이브러리, 프레임워크 및 기타 종속성과 같은 필수 요소와 함께 패키지에 포함하여 각자의 "컨테이너"로 분리하는 것을 뜻합니다.

이렇게 컨테이너화된 소프트웨어 또는 애플리케이션은 어떤 환경과 인프라에서든 해당 환경이나 인프라의 운영 체제와는 상관없이 이동할 수 있으며 일관성있게 실행됩니다. 즉, 컨테이너는 애플리케이션을 둘러싼 일종의 버블 또는 컴퓨팅 공간으로, 그 주위와 분리해주는 역할을 하는 것입니다. 기본적으로 완전한 기능을 갖춘 이식성이 있는 컴퓨팅 환경입니다.(←핵심 내용)

컨테이너는 하나의 플랫폼 또는 운영 체제에서 코드를 작성하는 방식을 대체합니다. 이러한 방식은 해당 코드가 새로운 환경과 호환되지 않을 경우 애플리케이션의 이동을 어렵게 만드는 원인이었으며 수정이 필요한 버그, 오류, 결함 등이 생겼습니다. 이렇게 되면 시간은 더 많이 소요되고, 생산성은 줄어들며, 사기도 꺾이게 됩니다.

플랫폼과 인프라 전반에서 이동이 가능한 컨테이너로 애플리케이션을 패키징하는 경우 해당 애플리케이션을 어디에서든 사용할 수 있습니다. 실행하는 데 필요한 요소는 이미 패키지 안에 모두 포함되어 있기 때문입니다.

프로세스를 분리하는 아이디어는 수년간 존재했지만, 2013년 Docker가 Docker Engine을 소개하면서 비로소 개발자가 사용하기 쉬운 툴을 갖춘 컨테이너 사용의 기준이 정해졌고 패키징에 대한 범용적 접근 방식이 제시되었습니다. 그러면서 컨테이너 기술 도입이 가속화되었습니다. 오늘날 개발자는 Docker가 개척한 Open Container Initiative 표준을 지원하는 Podman, Buildah, Skopeo같은 다양한 컨테이너화 플랫폼과 툴을 선택할 수 있습니다.

간단한 컨테이너화 예시

FastAPI 서버를 준비했다.

Dockerfile을 작성해준다.(트러블 슈팅이라고 할 것까지는 아니지만, fastapi는 서버 실행을 위한 cmd실행을 dockerfile에 작성해주어야하고, 연습삼아 FastAPI 객체의 이름을 world로 했다가 시간을 너무 잡아 먹었다. 다들 조심하기를,,,,)

빌드를 해준다. 처음 빌드할때 tag 지정 가능

버전과 이름을 지정하지 못해서 해당 IMAGE ID를 선택해서 이름과 tag을 지정해줌

dockerhub에 로그인을 해준다.

dockerhub에서 확인했을 때 이상없이 잘 올라갔다.

docke image를 삭제 (상관은 없음)

docke hub에서 pull을 하여 이미지가 생성되었지만, container는 존재하지 않는다.

docker run -d -p 3000:8080 fastapi-tutorial:latest

분리 모드(-d)의 fastapi-tutorial이미지에서 새 컨테이너를 시작한다. -p 로 포트 매핑을 설정할 수 있다. -p 3000:8080이라고 기술하면 처음 3000 현재 로컬 컴퓨터의 포트이고 콜론(:)다음의 8080은 앱이 컨테이너에서 수신 대기하는 포트다.