Kubernetes

Overview

Kubernetes 내용 정리.

Tutorial

쿠버네티스 클러스터

쿠버네티스는 서로 연결되어서 단일 유닛처럼 동작하는 고가용성의 컴퓨터 클러스터를 상호조정한다. 쿠버네티스의 추상화된 개념을 통해 개별 머신에 얽매이지 않고 컨테이너화된 애플리케이션을 클러스터에 배포할 수 있다. 이렇게 새로운 배포 모델을 활용하려면, 애플리케이션을 개별 호스트에 결합되지 않는 방식으로 패키지할 필요가 있다. 즉, 컨테이너화 해야 한다. 컨테이너화 된 애플리케이션은 호스트에 매우 깊에 통합된 패키지로써, 특정 머신에 직접 설치되는 예전의 배포 모델보다 유연하고 가용성이 높다. 쿠버네티스는 애플리케이션 컨테이너를 클러스터에 분산시키고 스케줄링하는 일을 보다 효율적으로 자동화한다. 쿠버네티스는 오픈소스 플랫폼이고 운영 수준의 안정성을 가졌다.

쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다.

• 마스터는 클러스터를 상호조정한다.
• 노드는 애플리케이션을 구동하는 작업자이다.

클러스터 다이어그램

마스터는 클러스터 관리를 담당한다. 마스터는 애플리케이션을 스케쥴링하거나, 애플리케이션의 항상성을 유지하거나, 애플리케이션을 스케일링하고, 새로운 변경사항을 순서대로 반영하는 일과 같은 클러스터 내 모든 활동을 조율한다.

노드는 쿠버네티스 클러스터 내 워커 머신으로써 동작하는 VM 또는 물리적인 컴퓨터이다. 각 노드는 노드를 관리하고 쿠버네티스 마스터와 통신하는 Kubelet 이라는 에이전트를 갖는다. 노드는 컨테이너 운영을 담당하는 Docker 또는 rkt 과 같은 툴도 갖는다. 운영 트래픽을 처리하는 쿠버네티스 클러스터는 최소 세 대의 노드를 가져야 한다.

마스터는 클러스터를 관리하고 노드는 구동되는 애플리케이션을 수용하는 데 사용된다.

애플리케이션을 쿠버네티스에 배포한다는 것은, 마스터에 애플리케이션 컨테이너를 구동하라고 지시하는 것이다. 마스터는 컨테이너를 클러스터의 어느 노드에 구동시킬지를 스케쥴한다. 노드는 마스터가 제공하는 쿠버네티스 API를 통해서 마스터와 통신한다. 최종 사용자도 쿠버네티스 API 를 직접 사용해서 클러스터와 상호작용할 수 있다.

쿠버네티스 클러스터는 물리 및 가상 머신 모두에 설치될 수 있다. 쿠버네티스 개발을 시작하려면 Minikube 를 사용할 수 있다. Minikube 는 로컬 머신에 VM 을 만들고 하나의 노드로 구성된 간단한 클러스터를 배포하는 가벼운 쿠버네티스 구현체이다. Minikube 는 리눅스, 맥, 그리고 윈도우 시스템에서 구동이 가능하다. Minikube CLI는 클러스터에 대해서 시작, 중지, 상태 조회 및 삭제 등의 기본적인 부트스트래핑 기능을 제공한다.

쿠버네티스 디플로이먼트

일단 쿠버네티스 클러스터를 구동시키면, 그 위에 컨테이너화된 애플리케이션을 배포할 수 있다. 그러기 위해서, 쿠버네티스 디플로이먼트 설정을 만들어야 한다. 디플로이먼트는 쿠버네티스가 애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시한다. 디플로이먼트가 만들어지면, 쿠버네티스 마스터가 해당 어플리케이션 인스턴스를 클러스터의 개별 노드에 스케쥴한다.

애플리케이션 인스턴스가 생성되면, 쿠버네티스 디플로이먼트 컨트롤러는 지속적으로 이들 인스턴스를 모니터링한다. 인스턴트를 구동 중인 노드가 다운되거나 삭제되면, 디플로이먼트 컨트롤러가 인스턴스를 교체시켜준다. 이렇게 머신의 장애나 정비에 대응할 수 있는 자동 복구(self-healing)매커니즘을 제공한다.

오케스트레이션 기능이 없던 환경에서는, 설치 스크립트가 애플리케이션을 시작하는데 종종 사용되곤 했지만, 머신의 장애가 발생한 경우 복구를 해주지는 않았다. 쿠버네티스 디플로이먼트는 애플리케이션 인스턴스를 생성해주고 여러 노드에 걸쳐서 지속적으로 인스턴스가 구동되도록 하는 두 가지를 모두 하기 대문에 애플리케이션 관리를 위한 접근법에서 근본적인 차이를 가져다준다.

디플로이먼트는 애플리케이션 인스턴스를 생성하고 업데이트하는 역할을 담당한다.

Kubernetes pod

POD 는 하나 또는 그 이상의 애플리케이션 컨테이너(도커 또는 rkt)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다.

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

POD 는 특유한 '로컬 호스트' 애플리케이션 모형을 만들어, 상대적으로 밀접하게 결합되어진 상이한 애플리케이션 컨테이너들을 수용할 수 있다. 가령, POD 는 node.js 앱과 더불어 node.js 웹 서버에 의해 발행되는 데이터를 공급하는 상이한 컨테이너를 함께 수용할 수 있다. POD 내 컨테이너는 IP 주소, 그리고 포트 스페이스를 공유하고 항상 함께 위치하고 함께 스케쥴링되고 동일 노드 상의 컨텍스트를 공유하면서 동작한다.

POD 는 쿠버네티스 플랫폼 상에서 최소 단위가 된다. 우리가 쿠버네티스에서 배포를 생성할 때, 그 배포는 컨테이너 내부에서 컨테이너와 함께 POD를 생성한다. 각 POD는 스케쥴되어진 노드에게 묶여지게 된다. 그리고 (재구동 정책에 따라) 소멸되거나 삭제되기 전까지 그 노드에 유지된다. 노드에 실패가 발생할 경우, 클러스터 내에 가용한 다른 노드들을 대상으로 스케쥴되어진다.

POD 하나 또는 그 이상의 애플리케이션 컨테이너(도커 또는 rkt 와 같은)들의 그룹이고, 공유 스토리지(볼륨), IP 주소 그리고 그것을 동작시키는 방식데 대한 정보를 포함하고 있다.

Node

POD 는 언제나 노드 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 마스터에 의해 관리된다. 하나의 노드는 여러 개의 POD 를 가질 수 있고, 쿠버네티스 마스터는 클러스터 내 노드를 통해서 POD 에 대한 스케쥴링을 자동으로 처리한다.

모든 쿠버네티스 노드는 최소한 다음과 같이 동작한다.

• kubelet 은 쿠버네티스 마스터와 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 POD 와 컨테이너를 관리한다.
• (Docker, rkt)와 같은 컨테이너 런타임은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다.

만약 컨테이너들이 밀접하게 결합되어 있고, 디스크와 같은 자원을 공유해야 한다면 오직 하나의 단일 POD에 함께 스케쥴되어져야 한다.

See also

• https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-intro/