쿠버네티스 기초학습

May 15, 2021 5 분 소요

쿠버네티스 클러스터 오케스트레이션 시스템의 기초를 소개하는 가이드입니다.

이 가이드는 Learn Kubernetes Basics를 요약한 내용입니다.
자세한 내용은 원문은 참고해주세요.
편의를 위해 애플리케이션 을 앱 이라고로 줄였습니다.

오늘날의 웹서비스에 대해서, 앱은 24/7 가용해야하고,
개발자는 새로운 버전의 앱을 자주 배포하기를 바랍니다.

소프트웨어를 컨테이너로 패키지하면 앱 다운타임 없이 릴리스 및 업데이트를 할 수 있습니다.
쿠버네티스는 이렇게 컨테이너화된 앱을 원하는 언제든 어디에든 구동시킬 수 있고,
그 앱이 작동하는데 필요한 자원과 도구를 찾아 줍니다.
쿠버네티스는 구글의 컨테이너 오케스트레이션에 대한 경험으로 설계되고 커뮤니티로부터
나온 아이디어가 결합된 운영 레벨의 오픈 소스 플랫폼입니다.

모듈.1: 클러스터 생성하기

쿠버네티스는 단일 유닛으로 동작하도록 연결된 고가용성 컴퓨터 클러스터를 조정합니다.
쿠버네티스 배포 모델을 활용하려면 앱을 개별 호스트에 독립적인 방식으로 패키징해야
하기 때문에 컨테이너화가 필요합니다.
쿠버네티스는 효율적인 방식으로 클러스터에서 앱 컨테이너를 분산시키고 스케줄링하는
작업을 자동화합니다.

쿠버네티스 클러스터는 두 개의 자원으로 구성됩니다.

컨트롤 플레인은 클러스터를 조율합니다.
노드는 앱을 실행하는 워커(Worker)입니다.

클러스터 다이어그램

컨트롤 플레인은 클러스터를 관리합니다.
노드는 쿠버네티스 클러스터에서 워커 머신 역할을하는 VM 또는 물리적 컴퓨터입니다.
노드는 쿠버네티스 API를 사용하여 컨트롤 플레인과 통신합니다.

모듈.2: 앱 배포하기

쿠버네티스 클러스터가 실행되면, 컨테이너화된 앱을 배포할 수 있습니다.
배포하기 위해서, 쿠버네티스 디플로이먼트(Deployment) 설정을 만들어야 합니다.
디플로이먼트는 앱의 인스턴스를 어떻게 생성하고 업데이트해야 하는 지 지시합니다.
디플로이먼트가 만들어지면, 컨트롤 플레인이 디플로이먼트에 포함된 앱 인스턴스가
클러스터의 개별 노드에서 실행되도록 스케줄링합니다.

앱 인스턴스가 생성되면, 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를 모니터링합니다.
인스턴스를 실행 중인 노드가 다운되거나 삭제되면, 디플로이먼트 컨트롤러가 인스턴스를
클러스터 내의 다른 노드의 인스턴스로 교체합니다.
이것은 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing) 메커니즘입니다.

앱을 배포하기

Translation results Kubectl 이라는 쿠버네티스 CLI를 통해 디플로이먼트를 생성하고 관리할 수 있습니다.
Kubectl 은 클러스터와 상호 작용하기 위해 쿠버네티스 API를 사용합니다.

모듈.3: 앱 살펴보기

쿠버네티스 파드

쿠버네티스는 앱 인스턴스를 호스팅하기 위해 파드를 만들었습니다.
파드는 하나 이상의 앱 컨테이너(도커와 같은)와 해당 컨테이너에 대한
일부 공유 리소스의 그룹을 나타내는 쿠버네티스의 추상적 개념입니다.
이 리소스에는 다음이 포함됩니다:

볼륨과 같은 공유 스토리지
클러스터 IP 주소와 같은 네트워킹
컨테이너 이미지 버전 또는 사용할 특정 포트와 같은
각 컨테이너가 실행방법에 대한 정보

파드는 애플리케이션 별 ‘논리적 호스트’를 모델링하며 비교적 밀접하게 결합된
여러 앱 컨테이너들을 포함할 수 있습니다.
예를 들어 파드에는 Node.js 앱 컨테이너와 Node.js 웹 서버에서 게시할 데이터를 제공하는
다른 컨테이너가 모두 포함될 수 있습니다.
파드 내의 컨테이너는 IP 주소, 그리고 포트 스페이스를 공유하고 항상 함께 위치(co-located)하고
함께 스케쥴링(co-scheduled) 되고 동일 노드 상의 공유 컨텍스트에서 실행됩니다.

파드는 쿠버네티스 플랫폼의 최소 단위(atomic unit)입니다.
우리가 쿠버네티스에서 디플로이먼트를 생성할 때, 그 디플로이먼트는 컨테이너가 포함된 파드를
만듭니다.(컨테이너를 직접 만드는 것과 반대로)
각 파드는 예약된 노드에 연결되며 종료(재시작 정책에 따라) 또는 삭제될 때까지 남아 있습니다.
노드 장애가 발생하면 클러스터의 다른 사용 가능한 노드에 동일한 파드가 예약됩니다.

노드

파드는 언제나 노드 상에서 동작합니다.
노드는 쿠버네티스의 워커 머신이며 클러스터에 따라 가상 또는 물리 머신일 수 있습니다.
각 노드는 마스터가 관리합니다. 하나의 노드에는 여러 개의 파드가 있을 수 있고,
마스터는 클러스터의 노드에서 파드 예약을 자동으로 처리합니다.

모든 쿠버네티스 노드는 최소한 다음 기능을 실행합니다.

Kubelet 은, 마스터와 노드 간 통신을 담당하는 프로세스이며,
한 머신에서 동작하는 파드와 컨테이너를 관리합니다.
컨테이너 런타임(도커와 같은) 은 레지스트리에서 컨테이너 이미지를 가져오고
컨테이너를 언패킹(Unpacking)하고 앱을 실행합니다.

`kubectl` 로 문제해결하기

가장 보편적인 운용 업무는 다음 kubectl 명령어를 이용하여 처리할 수 있다:

kubectl get - 자원을 나열한다
kubectl describe - 자원에 대해 상세한 정보를 보여준다.
kubectl logs - 파드 내 컨테이너의 로그들을 출력한다
kubectl exec - 파드 내 컨테이너에 대한 명령을 실행한다.

모듈.4: 앱 노출하기

쿠버네티스 파드들은 영원하지 않습니다. 실제로 파드는 생명주기(lifecycle)가 있습니다.
워커 노드가 죽으면, 노드 상에서 동작하는 파드들도 종료됩니다.
그 다음 레플리카셋(ReplicaSet)은 앱 실행을 유지하기 위해 새 파드를 생성하여 클러스터를
원하는 상태로 동적으로 되돌릴 수 있습니다.

쿠버네티스에서 서비스는 하나의 논리적인 파드 집합과 그 파드들에 접근하는
정책을 정의하는 추상적 개념입니다.
서비스는 종속된 파드들 사이를 느슨한 결합을 가능하게 합니다.
서비스는 다른 쿠버네티스 객체들과 같이 YAML(보다 선호) 또는 JSON을 이용하여 정의됩니다.
서비스가 대상으로 하는 파드 집합은 보통 LabelSelector 에 의해 결정됩니다.

각 파드에는 고유의 IP가 있지만, 그 IP들은 서비스없이 클러스터 외부로 노출되지 않습니다.
서비스를 통해 앱이 트래픽을 수신할 수 있습니다.
ServiceSpec에서 타입을 지정하여 서비스를 다양한 방식들로 노출시킬 수 있습니다:

ClusterIP (기본값) - 클러스터의 내부 IP로 서비스를 노출합니다.
이 타입을 사용하면 클러스터 내에서만 서비스에 연결할 수 있습니다.
NodePort - NAT를 사용하여 클러스터에서 선택한 각 노드의 동일한 포트에 서비스를 노출합니다.
<NodeIP>:<NodePort> 를 사용하여 클러스터 외부에서 서비스에 접근할 수 있도록 합니다.
ClusterIP의 상위 집합입니다.
LoadBalancer - 현재 클라우드(지원되는 경우)에 외부 로드밸런서를 생성하고
고정된 외부 IP를 서비스에 할당합니다. NodePort의 상위 집합입니다.
ExternalName - 값과 함께 CNAME 레코드를 반환하여 서비스를 externalName 필드의 콘텐츠에 매핑합니다.
어떤 종류의 프록시도 설정되지 않습니다.
이 타입에는 v1.7 이상의 kube-dns 또는 CoreDNS 버전 0.0.8 이상이 필요합니다.

다양한 타입의 서비스에 대한 자세한 정보는 소스 IP 사용하기 에서 찾을 수 있습니다.
또한 서비스와 앱 연결을 참고하세요.

서비스와 레이블

서비스는 파드 집합을 통해 트래픽을 라우팅합니다.
서비스는 앱에 영향을 주지 않고 쿠버네티스에서 파드가 죽고 복제할 수 있도록 하는 추상화입니다.
종속 파드(예, 앱의 프런트엔드 및 백엔드 구성요소) 간의 검색 및 라우팅은 서비스에서 처리합니다.

서비스는 쿠버네티스의 객체들에 대해 논리 연산을 허용해주는 기본 그룹핑 단위인,
레이블과 셀렉터를 이용하여 파드 그룹을 매치시킵니다.
레이블은 오브젝트들에 붙여진 키/밸류 값으로 다양한 방식으로 이용할 수 있습니다:

개발, 테스트, 그리고 상용환경에 대한 객체들의 지정
임베디드된 버전 태그들
태그들을 이용하는 객체들에 대한 분류

레이블은 생성 시 또는 나중에 객체에 붙일 수 있습니다.
언제든지 수정할 수도 있습니다.

모듈.5: 앱 스케일링하기

이전 모듈에서 디플로이먼트는 앱 실행을 위해 하나의 파드만 생성했습니다.
트래픽이 증가하면 사용자 요구에 맞게 앱을 확장해야 합니다.

스케일링은 디플로이먼트에서 레플리카 수를 변경하여 수행됩니다.

스케일링 개요

디플로이먼트를 확장(Scaling out)하면 새 파드가 생성되고
사용 가능한 리소스가 있는 노드에 예약됩니다.
확장하면 파드 수가 원하는만큼의 새 상태로 늘어납니다.
쿠버네티스는 파드의 자동 확장도 지원하지만 이 가이드의 범위를 벗어납니다.
0으로 확장할 수도 있으며, 이 경우 지정된 디플로이먼트의 모든 파드를 종료합니다.

모듈.6: 앱 업데이트하기

업데이트하기

롤링 업데이트를 사용하면 파드 인스턴스를 새 인스턴스로 점진적으로 업데이트하여
다운타임없이 디플로이먼트 업데이트를 수행할 수 있습니다.
새 파드는 사용 가능한 리소스가 있는 노드에서 예약됩니다.

이전 모듈에서는 여러 인스턴스를 실행하도록 앱을 확장했습니다.
이는 앱 가용성에 영향을 주지 않고 업데이트를 수행하기 위한 요구 사항입니다.
기본적으로 업데이트 중에 사용할 수 없는 최대 파드 수와 만들 수 있는 새 파드의 최대 수는 1입니다.
두 옵션 모두 숫자 또는 (파드의)백분율로 설정할 수 있습니다.
쿠버네티스에서 업데이트는 버전이 지정되고 모든 배포 업데이트를 이전의 (안정된) 버전으로 되돌릴 수 있습니다.

롤링 업데이트

앱 확장과 마찬가지로 디플로이먼트가 공개적으로 노출되면 서비스는 업데이트 중에
사용 가능한 파드에만 트래픽을 부하 분산합니다.
사용 가능한 파드는 앱 사용자가 사용할 수 있는 인스턴스입니다.

지속적 업데이트를 통해 다음 작업을 수행 할 수 있습니다:

한 환경에서 다른 환경으로 앱 승격(컨테이너 이미지 업데이트를 통해)
이전 버전으로 롤백
다운 타임없이 애플리케이션의 지속적인 통합 및 지속적인 제공

참고자료

Twitter Facebook LinkedIn

cppis

쿠버네티스 기초학습