[DevOps/Kubernetes] 쿠버네티스의 서버 구성의 개요 및 kubectl 설치

Kubernetes는 여러 개의 호스트를 하나로 묶어 docker를 이용하기 위한 오케스트레이션 툴이다.

분산 환경에서 '마치 한 대의 컴퓨터' 처럼 투과적으로 컨테이너에 액세스할 수 있다. 더욱이 시스템 이용자로부터 오는 부하의 급증에 대해서도 유연하게 스케일하는 장치나 여러 개의 컨테이너를 효율적으로 통합 관리하는 장치도 있다. 쿠버네티스의 주요 기능은 다음과 같다.

• 여러 서버들에서의 컨테이너 관리
• 컨테이너 간 네트워크 관리
• 컨테이너의 부하분산
• 컨테이너의 감시
• 무정지로 업데이트

---

Kubernetes의 서버 구성

Kubernetes의 전체 이미지는 다음과 같은데, 분산된 서버들이 협력하면서 각각의 처리를 수행한다.

이러한 덩어리를 "Kubernetes Cluster" 라고 한다.

Kubernetes의 서버 구성

마스터 서버 (Kubernetes Master)

Kubernetes 클러스터 안의 컨테이너를 조작하기 위한 서버이다. kubectl 명령을 사용하여 클러스터를 구성하거나 리소스를 조작할 때는 마스터 서버가 커맨드로부터 리퀘스트를 받아 처리를 수행한다. 여러 대로 구성된 kubernetes 클러스터 안에 있는 노드의 리소스 사용 상황을 확인하고, 컨테이너를 시작할 노드를 자동으로 선택한다.

kubernetes가 오케스트레이션 툴이라 불리는 이유도 이 마스터 서버가 여러 대로 분산 구성된 노드를 모아서 관리함으로써 이용자가 봤을 때는 마치 한 대의 서버인 것처럼 행동할 수 있기 때문이다.

백엔드 데이터베이스 (etcd)

etcd라 부르는 분산 키 밸류 스토어(KVS)를 사용하여 클러스터의 구성 정보를 관리한다. 여기에는 클러스터를 구축하기 위한 설정 정보가 들어 있다. 시스템 구성에 따라서는 백엔드 데이터베이스를 마스터 서버 상에 구축하는 경우도 있다. 또한 마스터 서버와 마찬가지로 다중화를 검토할 필요가 있다.

노드 (Node)

실제로 docker 컨테이너를 작동시키는 서버이다. 노드를 여러 개 마련하여 클러스터를 구성한다. 노드의 관리는 마스터 서버가 한다. 노드를 몇 대 마련할지는 시스템의 규모나 부하에 따라 달라진다. 클라우드에서는 가상 머신의 인스턴스가 노드가 된다.

---

애플리케이션 구성 관리 (Pod, ReplicaSet, Deployment)

Kubernetes는 애플리케이션 실행 환경의 오케스트레이션을 유연하게 수행하기 위해 다양한 추상화를 하고 있다. 아래의 내용은 kubernetes를 사용하여 docker 컨테이너를 다루기 위해 이해해 두어야 할 기본적인 개념에 대한 설명이다.

Pod (포드)

쿠버네티스에서는 여러 개의 컨테이너를 모아서 'Pod'로 관리한다. 이 Pod 안에는 예를 들면 애플리케이션 서버용 docker 컨테이너와 프록시 서버용 컨테이너 등 관련된 것을 Pod로 모은다.

그리고 쿠버네티스에서는 Pod가 애플리케이션의 전개 단위가 되며, Pod 단위로 컨테이너 작성/시작/정지/삭제와 같은 조작을 수행한다. 따라서 웹 프론트 서버와 데이터베이스 서버와 같이 역할이 다른 기능을 하나의 Pod에 저장하면 안된다.

Kubernetes의 Pod 개념

Pod는 반드시 동일한 노드 상에 동시에 전개된다는 특징이 있다. 이것은 Pod 안의 여러 컨테이너가 가상 NIC (프라이빗 IP)를 공유하는 구성을 취하기 때문에 컨테이너끼리 localhost 경유로 통신을 할 수 있다. 또한 공유 디렉토리를 통하여 로그 정보를 주고받을 수도 있으며, 노드 안에는 여러 개의 Pod가 배치된다.

ReplicaSet (리플리카 셋)

ReplicaSet은 Kubernetes 클러스터 상에서 미리 지정된 Pod를 작성하여 실행시켜 두는 장치이다. 간단히 말하자면 '클러스터 상에 정해진 수의 Pod를 반드시 실행시켜 둔다는 것' 이다.

ReplicaSet은 실행중 Pod를 감시하여 장애와 같은 이유로 정지된 경우에 해당 Pod를 삭제하고, 새로운 Pod를 실행시킨다. 즉, Pod가 필요한 수만큼 실행시킨 상태를 클라우드 안에 항상 만들어 두는 역할을 한다. 클라우드 안에 Pod를 얼마나 실행시켜 둘지를 '리플리카 수' 라고 한다.

예를 들어 5대의 노드에서 7개의 Pod를 실행시킨 상태를 ReplicaSet으로 구성한다고 해보자. 만일 어떤 이유로 Pod가 이상 종료된 경우는 새로운 Pod를 실행시켜 클러스터 전체에서 항상 7개의 Pod가 실행된 상태를 유지한다.

ReplicaSet은 지정한 수만큼의 Pod를 항상 실행시켜 두는 장치

또한 Pod의 수를 동적으로 변경하여 오토스케일을 구현할 수도 있다. ReplicaSet을 사용하면 애플리케이션 개발자는 전개한 Pod가 어떤 상태인지를 신경 쓸 필요 없이 항상 지정한 개수만큼 Pod가 실행된 상태를 kubernetes가 유지해 준다.

Deployment (디플로이먼트, 전개)

Deployment는 Pod와 ReplicaSet을 모은 것으로, ReplicaSet의 이력을 관리하는 것이다. 

Deployment는 ReplicaSet의 템플릿을 가지고 거기서 Pod의 구성을 정의하여 해당 템플릿을 따르는 ReplicaSet을 만든다. 이력을 관리할 수 있기 때문에 예를 들어 Pod 안의 컨테이너의 버전업을 하고 싶을 때는 시스템을 정지시키지 않고 롤링 업데이트를 할 수 있거나 이력을 바탕으로 하나 이전 세대로 되돌릴 수가 있다 (롤백).

정의된 리플리카의 수를 유지하는 역할을 갖고 있는 것이 ReplicaSet이고, ReplicaSet의 작성이나 갱신을 정의하는 것이 Deployment라고 생각하면 이해가 쉽다. 

ReplicaSet의 내용을 템플릿으로 지정하고 이력도 관리할 수 있다.

그 외에도 노드별로 감시 에이전트와 같은 특정 Pod를 반드시 배치하고 싶을 때에 이용하는 'DaemonSet' 이나 웹 서버와 같은 상주 서비스가 아니라 수치연산 처리와 같이 프로그램의 시작부터 종료까지로 완료되는 프로그램을 Pod에서 실행시키는 'Jobs' 등이 있다. 게다가 'CronJob'을 사용하면 Linux의 cron과 같이 Pod를 실행시킬 타이밍도 지정할 수 있다.

---

네트워크 관리 (Service)

Kubernetes 클러스터 안에서 실행되는 Pod에 대해 외부로부터 액세스할 때는 서비스를 정의한다. 서비스는 Kubernetes 네트워크를 관리하는 것으로, 몇 가지 종류가 있다. 그중 하나인 Load Balancer는 Service에 대응하는 IP 주소 + port 번호에 액세스하면 여러 Pod에 대해 레이어 4 레벨의 부하분산이 일어난다.

서비스에 의해 할당되는 IP 주소에는 Cluster IP와 Externel IP가 있다. Cluster IP는 클러스터 안의 Pod끼리 통신을 하기 위한 Private IP 주소이다. 클러스터 안의 Pod에서 Cluster IP로 보내는 패킷은 나중에 설명할 노드 상의 Proxy 데몬이 받아 수진 Pod로 전송된다. 

한편 Externel IP는 외부 클라이언트가 연결하기 위한 퍼블릭 IP 주소이다. Pod를 새로 실행하면 기존 서비스의 IP 주소와 포트 번호는 환경변수로 참조할 수 있다.

Ingress를 사용한 네트워크 제어

Kubernetes에는 서비스 외에도 'Ingress' 라는 Pod에 대한 통신을 제어하는 기능이 있다. Ingress는 서비스와 연결되어 통신 내용을 프록시한다. Ingress는 Kubernetes가 작동하는 환경에 따라 내용이 다른데, GCP의 경우는 HTTP Load Balancer를 사용한다. 이것을 사용하면 레이어 7에서 작동하기 때문에 리퀘스트 URL별 분류나 버추얼 호스트 기능 등 보다 세세한 네트워크 제어를 할 수 있다.

---

Label을 사용한 리소스 식별

Kubernetes에서는 리소스를 식별하기 위해 내부에서 자동으로 랜덤한 이름이 부여된다. 하지만 이것으로는 리소스를 적절히 관리하기 힘들기 때문에 알기 쉬운 Label을 붙여서 관리할 수 있다. 

Label은 리소스를 식별하기 위한 Key-Value 형으로 된 임의의 문자열로, 이 Label을 식별자로 하여 리소스를 일괄적으로 처리할 수 있다. 예를 들어 버전이 다른 Pod에 각각 'app:v1.0' 과 'app:v2.0' 이라는 Label을 설정한다. 그리고 서비스 정의에서 Selector를 'app:v1.0' 으로 지정하면 'app:v1.0' 이라는 Label이 붙은 Pod로만 리퀘스트가 전송되도록 할 수 있다. Label이 붙은 리소스를 참조하려면 selector로 지정한다.

Label은 하나의 리소스에 여러 개 설정할 수 있으므로 Pod의 역할별로 임의의 이름을 붙이거나 관련 있는 Pod 별로 모아서 유연하게 관리하고 싶을 때 임의의 Label을 설정한다. 또한 Label은 Kubernetes의 정의 파일인 매니페스트 파일을 참조할 때도 사용된다.

대규모 웹 시스템에서는 수많은 Pod나 버전이 다른 Pod를 관리해야 한다. Label을 사용하여 논리적인 그룹핑을 함으로써 운용 부담을 줄일 수 있다.

---

kubectl 설치

Kubernetes 설치 방법은 아래의 공식 사이트에서 확인하기 바란다. 해당 사이트에서 제공하는 설치법을 그대로 적용하면 된다.

kubernetes.io/ko/docs/tasks/tools/install-kubectl/

kubectl 설치 및 설정