쿠버네티스(Kubernetes)

• 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화하는 오픈소스 컨테이너 오케스트레이션 플랫폼
• 2014년 구글에 의해 오픈소스로 공개
• 현재는 클라우드 네이티브 컴퓨팅 재단(CNCF)에서 관리하고 있음

• 쿠버네티스 안에서 여러 도커를 관리, 조율할 수 있게 해주는 툴이라고 생각하면 됨.

특징

1. 자동화된 컨테이너 관리

• 쿠버네티스는 컨테이너의 배포, 스케일링, 롤아웃, 롤백을 자동화

2. 서비스 디스커버리와 로드 밸런싱

• DNS 이름이나 자체 IP주소를 사용하여 컨테이너를 노출하고, 트래픽을 분산

3. 스토리지 오케스트레이션

• 로컬 저장소나 퍼블릭 클라우드 제공자의 저장소 시스템을 자동으로 마운트

4. 자동 복구(Self-healing)

• 실패한 컨테이너를 재시작하고, 노드가 죽었을 때 컨테이너를 교채 및 재스케줄링

5. 선언적 구성

• 시스템의 원하는 상태를 선언적으로 기술하고, 현재 상태를 원하는 상태로 변경

• 워크 노드(서버) > Pod > Container 순으로

쿠버네티스의 주요 배포판

1. 바닐라 쿠버네티스(Vanilla Kubernetes)

• CNCF에서 관리하는 공식 쿠버네티스 배포판
• 이는 기본적인 쿠버네티스 구성 요소와 기능을 포함
• 다른 배포판의 기준이 됨

2. Red Hat OpenShift

• 엔터프라이즈급 쿠버네티스 배포판
• 유료 버전
• 추가 기능이 내장되어 있거나 쉽게 추가 가능
• CI/CD 파이프라인, 연산자, Helm 차트 등 다양한 도구 제공
• RHEL(Red Hat Enterprise Linux)기반 운영

3. Rancher

• 다양한 환경(온프레미스, 클라우드)에서 배포 가능
• 멀티 클러스터 관리에 강점
• RKE(Rancher Kubernetes Engine)을 사용한 쉬운 클러스터 구축

4. Amazon EKS(Elastic Kubernetes Service)

• Amazon Web Services에서 제공하는 관리형 쿠버네티스 서비스
• AWS 인프라와 긴밀하게 통합되어 있음

5. Google GKE(Google Kubernetes Engine)

• GCP에서 제공하는 관리형 쿠버네티스 서비스
• 구글의 쿠버네티스 전문성을 활용 가능

6. Microsoft AKS(Azure Kubernetes Service)

• Azure 에서 제공하는 관리형 쿠버네티스 서비스
• Azure 클라우드 서비스와 통합되어 있음

7. DigitalOcean Kubernetes

• Digital Ocean에서 제공하는 관리형 쿠버네티스 서비스
• 간단한 배포와 관리가 특징

MiniKube(미니쿠베)

특징

1. 단일 노드 클러스터

• 미니쿠베는 단일 노드 쿠버네티스 클러스터를 생성하여 로컬 머신에서 쿠버네티스를 실행할 수 있음

2. 경량화

• 가벼운 쿠버네티스 구현체로, 개발 및 테스트 목적으로 설계

3. 크로스 플랫폼

• 리눅스, 맥OS, 윈도우 등 다양한 운영 체제에서 사용 가능

4. 주요 쿠버네티스 기능 지원

• DNS, NodePorts, ConfigMaps, Secrets, 대시보드, 인그레스 등 중요한 쿠버네티스 기능을 지원

• 즉, 하나의 노드와 노드를 관리하는 마스터가 각각 하나만 있는게 주요 특징

요약

• 쿠버네티스는 컨테이너를 유연하고 효과적으로 운영할 수 있게 제공되고 있음
• 쿠버네티스는 그 자체가 하나의 클라우드라고 말할 수 있을 정도로 많은 기능을 제공하고 있음

YAML

• 데이터 직렬화에 쓰이는 포맷/양식 중 하나

데이터 직렬화란?

• 서비스 간에 Data를 전송할 때 쓰이는 포맷으로 변환하는 작업
• 예) 쿠버네티스 마스터에게 요청을 보낼 때 사용
• 다른 데이터 직렬화 포맷으로는 XML, JSON 등이 존재

• 파일 포맷(.yaml, .yml)
• 즉, 키(apiVersion), 값(v1)이런 식으로구성되어 있음
• 계층화도 indent를 통해서 가능

# 예시
apiVersion: v1
kind: Pod
metadata:
 name: example
spec:
 containers:
 - name: busybox
 image: busybox:1.25

Pod

• 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위
• 쿠버네티스는 Pod 단위로 스케줄링, 로드 밸런싱, 스케일링 등의 관리 작업을 수행
• 쿠버네티스에 어떤 애플리케이션을 배포하고 싶다면 최소 Pod로 구성
• Pod는 Container를 감싸고 있는 단위로 하나의 Pod는 한 개의 Container 혹은 여러 개의 Container로 이루어져 있을 수 있음
• Pod 내부의 여러 Container는 자원을 공유

# pod를만드는 yaml 파일 예시
apiVersion: v1 # kubernetes resource 의 API Version
kind: Pod # kubernetes resource name
metadata: # 메타데이터 : name, namespace, labels, annotations 등을 포함
name: counter
spec: # 메인 파트 : resource 의 desired state 를 명시
containers:
 - name: count # container 의 이름
image: busybox # container 의 image
 args: [/bin/sh, -c, 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done’]
# 해당 image 의 entrypoint 의 args 로 입력하고 싶은 부분

Deployment

• Deployment는 Pod와 Replicaset에 대한 관리를 제공하는 단위
• 관리라는 의미는 Self-healing, Scaling, Rollout(무중단 업데이트) 같은 기능을 포함

apiVersion: apps/v1 # kubernetes resource 의 API Version
kind: Deployment # kubernetes resource name
metadata: # 메타데이터 : name, namespace, labels, annotations 등을 포함
name: nginx-deployment
 labels:
 app: nginx
spec: # 메인 파트 : resource 의 desired state 를 명시
replicas: 3 # 동일한 template 의 pod 을 3 개 복제본으로 생성합니다.
 selector:
 matchLabels:
 app: nginx
 template: # Pod 의 template 을 의미합니다.
 metadata:
 labels:
 app: nginx
 spec:
 containers:
 - name: nginx # container 의 이름
image: nginx:1.14.2 # container 의 image
 ports:
 - containerPort: 80 # container 의 내부 Port

Service

• Service는 쿠버네티스에 배포한 애플리케이션(Pod)을 외부에서 접근하기 쉽게 추상화한 리소스
• Pod는 IP를 할당받고 생성되지만, 언제든지 죽었다가 다시 살아날 수 있으며, 그 과정에서 IP는 항상 재할당 받음. 즉, 고정된 IP로 원하는 Pod에 접근할 수 없음
• 따라서 클러스터 외부 혹은 내부에서 Pod에 접근할 때는, Pod의 IP가 아닌 Service를 통해서 접근하는 방식을 거침
• Service는 고정된 IP를 가지며, Service는 하나 혹은 여러 개의 Pod와 매칭

apiVersion: v1
kind: Service
metadata:
 name: my-nginx
 labels:
 run: my-nginx
spec:
 type: NodePort # Service 의 Type 을 명시하는 부분입니다. 자세한 설명은 추후 말씀드리겠습니다.
 ports:
 - port: 80
 protocol: TCP
 selector: # 아래 label 을 가진 Pod 을 매핑하는 부분입니다.
 app: nginx 

PVC

• Persistent Volume(PV), Persistent Volume Claim(PVC)는 Stateless한 Pod이 영구적으로데이터를 보존하고 싶은 경우 사용하는 리소스
• 도커에 익숙하다면 docker run의 -v 옵션인 도커 볼륨과 유사한 역할을 한다고 이해 가능
• PV는 관리자가 생성한 실제 저장 공간의 정보를 담고 있고, PVC는 사용자가 요청한 저장 공간의 스펙에 대한 정보를 담고 있는 리소스
• Pod 내부에서 작성한 데이터는 기본적으로 언제든지 사라질 수 있기에, 보존하고 싶은 데이터가 있다면 Pod에 PVC를 mount 해서 사용해야 함

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: myclaim
spec: # pvc 의 정보를 입력하는 파트입니다.
 accessModes:
 - ReadWriteMany # ReadWriteOnce, ReadWriteMany 옵션을 선택할 수 있습니다.
 volumeMode: Filesystem
 resources:
 requests:
 storage: 10Mi # storage 용량을 설정합니다.
 storageClassName: standard # 방금 전에 확인한 storageclass 의 name 을 입력합니다.

요약

• Deployment는 Pod를 운영하고 관리하는 단위
• Service를 잘 셋팅하지 않으면 외부에 서비스를 노출할 수 없음
• 실제로 쿠버네티스를 운영하다 보면 훨씬 더 많은 문제와 옵션을 만나게 됨