현재 모든 API 및 시스템 개발을 마친 티켓핑 프로젝트를 배포할 준비가 되었다.
다중 컨테이너 환경의 운영 그리고 이번 프로젝트의 가장 큰 목표였던 트래픽에 따른 Auto Scailing을 실현하기 위해서 Kubernetes에 대해 학습하고 이를 AWS에 적용하여 배포를 마쳐보기로 한다.
1. Kubernetes
Kubernetes는 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈 소스 플랫폼로서 컨테이너의 자동 배포, 스케일링과 로드밸런싱, 관리 등을 도와준다.
쿠버네티스는 오픈 소스 프로젝트로서 특정 클라우드 프로바이더에 종속되지 않으며, 어디에서나 사용할 수 있다. 또한 특정 머신에서 실행하는 단순한 소프트웨어가 아니라 개념 및 도구이며, 우리가 선택한 모든 프로바이더에 배포 작업을 할 수 있다.
2. Kubernetes 아키텍처
핵심 컴포넌트
Cluster
마스터, 워커 노드 같은 노드 머신들의 컬렉션 세트Nodes
하나 이상의 포드를 호스팅하고 클러스터와 통신하는 물리 / 가상 머신Master Node
모든 워커노드들에 걸쳐 포드를 관리하는 컨트롤 플레인을 가진 노드Worker Node
포드를 호스팅하는 실제 머신Pods
어플리케이션 컨테이너와 요구 리소스가 결합된 유닛Containers
일반적인 Docker 컨테이너Services
유일성을 갖고, 포드와 컨테이너에 독립적인 IP 주소를 가진 논리적인 포드 집합. 포드를 외부에 노출시켜 특정 IP 주소나 도메인으로 접근할 수 있게 해주는 역할
Kubernetes Cluster
Kubernetes Cluster는 컨테이너를 실행할 하나 이상의 워커 노드, 그리고 그 워커 노드들을 제어할 마스터 노드로 구성되어 있다.
Worker Node
Worker Node는 하나의 컴퓨터 / 머신 / 가상 인스턴스가 될 수 있으며, 마스터 노드에 의해 관리된다. 워커 노드의 내부에는 Pod가 존재하고 각 포드는 하나 이상의 애플리케이션 컨테이너와 이러한 컨테이너에 속한 모든 리소스를 호스팅한다.
이외에도 워커 노드에는 컨테이너를 생성하고 실행할 Docker, 워커 노드와 마스터 노드 간의 통신 장치 Kublet 그리고 들어오고 나가는 트래픽을 처리할 Kube-Proxy가 설치되어 있어야 한다.
Master Node
Master Node는 다음의 요소들로 구성되어 있다.
API Server
워커 노드에서 실행되는 Kublet 서비스에 대한 카운터 포인트인 마스터 노드 머신에서 실행되는 서비스이다.Scheduler
포드를 관찰하고 새 포드가 생성되어야 하는 워커 노드를 선택하는 일을 담당한다.Kube-Controller-Manager
워커 노드 전체를 감시하고 제어하며 적당한 수의 포드가 가동 중에 있는지 확인하는 역할을 한다.Cloud-Controlelr-Manager
Kube-Controller-Manager와 동일한 작업을 수행하지만,
특정 클라우드 프로바이더에게 무엇을 해야하는지 알려준다.
2. Kubernetes의 Object
다음으로 쿠버네티스에서 yml(manifest) 파일이나 명령어를 통해 다루게 될 객체들에 대해 알아보도록 하자.
Deployment
- Pod의 선언적 업데이트를 제공
- 레플리카 수, 롤링 업데이트 전략 등을 정의
- Pod의 스케일링과 버전 관리를 담당
Service
- Pod 집합에 대한 단일 엔드포인트를 제공
- 내부 로드밸런싱과 서비스 디스커버리 기능
- ClusterIP, NodePort, LoadBalancer 등의 타입 존재
ConfigMap
- 설정 데이터를 키-값 쌍으로 저장
- Pod의 환경 변수나 볼륨으로 마운트하여 사용
- 애플리케이션 설정을 코드와 분리하여 관리 가능
Secret
- 비밀번호, API 키 등 민감한 정보를 저장
- Base64로 인코딩되어 저장
- Pod에서 환경 변수나 볼륨으로 사용 가능
PersistentVolume (PV)
- 클러스터의 스토리지 리소스
- 관리자가 프로비저닝하거나 동적으로 프로비저닝
- 데이터의 영속성을 보장
PersistentVolumeClaim (PVC)
- PV를 사용하기 위한 요청
- Pod에서 스토리지를 사용하기 위해 PVC를 정의
- 용량, 접근 모드 등을 지정
StatefulSet
- 상태를 가진 애플리케이션을 위한 워크로드 API
- 순차적인 배포와 스케일링을 보장
- 안정적인 네트워크 식별자와 영구 스토리지를 제공
DaemonSet
- 모든 노드에서 Pod를 실행하도록 보장
- 로그 수집기, 모니터링 에이전트 등에 사용
- 노드가 추가되면 자동으로 Pod 생성
Ingress
- 클러스터 외부에서 내부 서비스로의 HTTP/HTTPS 라우팅 규칙을 정의
- SSL/TLS 종료, 가상 호스팅 등을 지원
- LoadBalancer 타입 Service보다 더 많은 기능 제공
ex) eureka-server.yml
다음은 유레카 서버의 리소스를 정의하기 위한 파일이다.
보다시피 클러스터 내에서 Pod에 대한 네트워크 접근을 제공하는 Service와
Pod의 배포 및 관리를 자동화하는 Deployment로 간단하게 구성되어 있다.
apiVersion: v1
kind: Service
metadata:
name: eureka-server-service
spec:
selector:
app: eureka-server
type: LoadBalancer
ports:
- protocol: TCP
port: 10000
targetPort: 10000
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: eureka-server-deployment
spec:
replicas: 1
selector:
matchLabels:
app: eureka-server
template:
metadata:
labels:
app: eureka-server
spec:
containers:
- name: eureka-server
image: {registry_name}/eureka-server:latest
ports:
- containerPort: 10000각 객체들의 세부 설정을 살펴보자.
Service
selector: app: 특정 레이블을 가진 Pod를 서비스의 대상으로 지정
type: 서비스의 타입
port: 서비스가 외부에 노출되는 포트
targetPort: 실제 Pod 내의 컨테이너 포트
서비스의 type의 경우 다음의 4가지가 존재한다.
Service의 Type
- ClusterIP (기본값): 클러스터 내부에서만 Pod에 접근 가능
- NodePort: 모든 노드의 특정 포트를 통해 서비스에 접근 가능
- LoadBalancer: 클라우드 공급자의 로드밸런서를 자동 프로비저닝
- ExternalName: 외부 서비스를 쿠버네티스 내부에서 접근할 때 사용
Deployment
replicas: 실행할 Pod의 복제본 수
selector: matchLabels: app: Pod를 선택하기 위한 레이블 선택자 정의
template: metadata: labels: app: 템플릿의 레이블 정의
image: 사용할 컨테이너 이미지
containerPort: 컨테이너가 리스닝하는 포트
Reference
