1. 개념
가. k8s 개념
1) k8s란
•
오픈소스 기반 컨테이너 관리 솔루션입니다. 2024년 현재 업계 표준으로 자리 잡았습니다.
•
Cluster는 쿠버네티스의 배포 단위입니다. 클러스터 내에서 컨테어너화된 애플리케이션이 하나처럼 동작하도록 관리됩니다.
2) Control Plane Component
•
Control Plane Component는 클러스터의 조율자입니다. 애플리케이션의 스케줄링, 항상성 유지, 스케일링, 변경사항 반영 등의 역할 담당합니다.
•
API Server는 Node와 Control Plane과의 통신을 담당합니다.
•
kubectl는 쿠버네티스 CLI입니다. 사용자의 명령은 kubectl을 거쳐서 API Server에 전달됩니다.
•
etcd는 API Server와 데이터를 동기화합니다. 사용자의 명령이 API Server에 전달되면 etcd와 동기화합니다. 클러스터에 장애가 발생해서 주요 데이터가 유실되면 etcd를 토대로 복구합니다.
•
controller manager(c-m)은 클러스터의 목표 상태와 현재 상태를 확인하고 조치합니다. 예를 들어, 설정된 수의 파드 만큼 실행되고 있는지, 서비스와 파드가 제대로 통신하고 있는지 등을 점검합니다.
•
scheduler(sched)는 파드가 새롭게 생성되는 것을 감지하여 특정 노드로 배치(스케줄링)하는 컴포넌트입니다
•
workloads: k8s에서 구동되는 어플리케이션입니다.
•
workload resource는 노드 내 파드에 대한 관리(노드 실패 시 재생성 등)를 자동화합니다. workload resource에 지정된 상태와 파드의 상태가 동일하게 실행되도록 controller manager를 구성합니다. workload resource에는 Deployment, StatefulSet 등이 존재합니다.
•
Deployment: workload resource의 일종으로, 모든 파드가 필요에 따라 상호 교체 가능하도록 controller manager를 구성합니다. 파드의 상호 교체가 가능하므로 Stateless workload에 적용하기 적절합니다.
•
StatefulSet: workload resource의 일종으로, 상태를 지속 추적하는 파드를 동작시키는데 사용됩니다. 파드와 PersistentVolum을 연계하여 데이터를 지속적으로 기록할 수 있습니다. Deployment와 비교하면 전체적인 회복력이 떨어지지만 이를 보완하기 위해 지속 기록 중인 데이터를 다른 파드로 복제하도록 구성할 수 있습니다.
•
Cluster DNS: 파드와 서비스를 위해 DNS Record를 생성하므로, 관리자 입장에서 IP 대신 DNS Name을 이용하여 클러스터 내 서비스, 컨테이너에 접근할 수 있습니다. Cluster DNS는 네임스페이스별로 분리되기 때문에 다른 네임스페이스의 서비스에 DNS 쿼리를 보낼 수 없습니다.
•
Headless Services: 클러스터 IP가 없는 서비스입니다. 노멀 서비스의 경우, IP family를 갖는 것과는 다릅니다.
•
PV(PersistentVolumes): 클러스터의 스토리지로 관리자에 따른 정적 또는 클래스에 따른 동적으로 자원을 할당(provisioning)합니다. 노드와 같은 클러스터 리소스이기 때문에 파드와 별개의 라이프사이클을 갖습니다.
•
PVC(PersistentVolumesClaim): PV에 대한 구체적인 스토리지 리소스 요청입니다. 스토리지 리소스 요청에는 접근 모드(ReadWriteOnce, ReadOnlyMany, ReadWriteMany)와 스토리지의 크기 등이 있습니다. 클러스터의 리소스를 요청한다는 점에서 파드와 일부 비슷합니다. 파드의 경우 노드의 리소스를 요청하지만 PVC는 PV의 리소스를 요청합니다.
•
주요 구성요소 관계 이미지 참고
3) Node Component
•
Node는 클러스터의 물리 또는 가상 머신으로 어플리케이션을 구동하는 작업자입니다.
•
Kubelet은 노드를 관리하고 클러스터 내 컨트롤 플레인과 통신하는 에이전트입니다.
•
container runtime(containerD)은 파드 내 컨테이너의 실행을 실질적으로 담당하는 어플리케이션입니다.
•
kube-proxy는 클러스터 내부에서 네트워크 요청을 전달합니다. kube-proxy는 매번 바뀌는 파드의 IP를 관리하여 고정적으로 파드에 전달될 수 있는 경로를 제공합니다.
4) 파드(pod)
•
하나의 일을 하기 위해 묶여진 컨테이너 그룹입니다. 대부분의 경우 하나의 파드는 하나의 컨테이너로 구성됩니다. 볼륨은 파드에서 지속 관리되어야 하는 데이터를 저장하는 곳입니다.
•
파드의 역할은 컨테이너 관리 및 네트워킹입니다. 파드 내 컨테이너는 IP 주소, 포트 스페이스 공유합니다.
•
파드 이미지 참고
5) 서비스
•
파드 그룹에서 실행중인 애플리케이션을 외부 네트워크에 노출하는 방법입니다. 외부의 요청이 클러스터 내부로 전달되기 위해 서비스에 대한 설정이 필요합니다.
6) 디플로이먼트(deployment)
•
파드를 그룹화하여 복수의 파드를 생성 및 업데이트를 통합적으로 관리하는 방법입니다. 예를 들어, 디플로이먼트에 파드의 상태를 검사(health check)하여 파드의 컨테이너 종료 시 재시작하는 정책을 추가할 수 있습니다.
7) ReplicaSet
•
파드의 가용성을 보장하기 위해 파드의 복제본을 생성하여 파드의 그룹을 유지하는 방법입니다.
8) 인그레스(Ingress)
•
Ingress: 클러스터 내부의 서비스를 향하는 클러스터 외부의 트래픽에 대한 접근을 관리하는 API 오브젝트(k8s 리소스)입니다. HTTP 트래픽에 대해 부하 분산, SSL Termination, 가상 호스팅의 기능을 제공할 수 있습니다.
9) 애드온
•
쿠버네티스의 기능을 확장시켜주는 third party projects입니다.
10) namespace
•
클러스터 내 논리적 분리 단위입니다. 동일한 클러스터 내 다른 네임스페이스의 노드에 장애가 발생하면 모든 네임스페이스의 동일한 노드에도 장애가 발생합니다.
나. k8s 동작
1) 쿠버네티스의 기본 철학
•
선언적 시스템으로 동작하여, 추구하는 상태와 현재 상태를 맞춥니다. 상태를 맞추는 프로세스는 아래와 같습니다.
상태 감시 -> 차이 발견 -> 상태 변경 -> 상태 감시 -> 반복
•
MSA(Micro Services Architecture)에 따라 각각의 요소들에게 주어진 책임에 집중하여 전체가 원할하게 동작하도록 하는 것입니다.
•
위와 같은 철학에 대한 이해를 토대로 파드 배포 시 주요 구성 요소들이 하는 일을 이해할 수 있습니다.
2) 네임스페이스
•
각각의 네임스페이스에서 관리하는 구성요소가 다릅니다. default 네임스페이스 이하에서 nginx 등의 파드가 관리되며, kube-system 네임스페이스 이하에서도 특정 파드가 관리됩니다. 예를 들어, 아래와 같은 명령으로 kube-system 네임스페이스에서 관리되는 파드를 확인할 수 있습니다.
kubectl get pods -n kube-system
3) 배포에 따른 주요 구성요소의 일반 동작
선언적 시스템 적용 O
•
사용자 → API 서버(api) & ETCD(etcd)
: 파드 생성 요청(kubectl create pods)
•
API 서버 & ETCD → 컨트롤 매니저(c-m)
: 파드의 정상 생성 모니터링
: API 서버가 컨트롤 매니저에게 파드 생성 명령 X
•
컨트롤 매니저(c-m) → API 서버 & ETCD
: 컨트롤 매니저는 API 서버 내 파드 생성 관련 상태값 확인에 따라 파드 생성 관련 프로세스 수행
: 파드 생성 관련 프로세스 완료에 따라 API 서버 내 관련 상태값 갱신
•
API 서버 & ETCD → 스케줄러(sched)
: 새로운 파드가 워커 노드에 정상적으로 들어갔는지 모니터링
•
스케줄러(sched) → API 서버 & ETCD
: 스케줄러는 API 서버 내 관련 값을 확인하고 새로운 파드를 워커 노드에 넣도록 스케줄링
•
API 서버 & ETCD → kubelet
: 새로운 파드가 워커 노드에 정상적으로 소속되어 있는지 모니터링
•
kubelet → 컨테이너 런타임
: 파드의 동작 관리
•
컨테이너 런타임 → 파드
: 컨테이너 생성
•
kubelet → API 서버 & ETCD
: 파드 상태정보 전달
•
API 서버 & ETCD → 사용자
: 파드 사용 가능
4) 배포에 따른 주요 구성요소의 예외 동작
선언적 시스템 적용 X
•
API 서버 → etcd
: 클러스터 내 업데이트된 정보(현재 상태값, 상태 목표값) 기록
: etcd에 저장하는 이유는 해당 정보가 휘발되는 것을 방지하기 위함
: 구성정보의 백업
•
etcd → API 서버
: API에 업데이트된 정보 알림
5) StatefulSet 동작
•
SatefulSet이란 워크로드 API 오브젝트 중 하나로, 상태를 지속 관리하는 어플리케이션을 관리하는데 특화되어 있습니다.
•
이하의 공식 튜토리얼에서 PV 관리, 파드 관리, 파드 업데이트, Statefulset의 DNS 정책 등에 대해 실습할 수 있습니다. 실습 시 별도의 네임스페이스를 구성할 것을 권장합니다.
6) Ingress 동작
•
Ingress Node: Ingress Controller가 실행되는 노드입니다.
•
Ingress Controller(ingress-nginx): Ingress 설정에 따라 트래픽을 라우팅하는 소프트웨어입니다. 외부에서 인그레스 노드로 트래픽이 전달되면, 앞의 설정에 따라 내부 서비스로 라우팅합니다.
•
Ingress 기반 LB vs 클러스터 외부 LB: Ingress는 클러스터 내 인그레스 내부로 전달된 트래픽에 대한 L7에서 부하를 분산합니다. 반면 클러스터 외부의 LB는 클러스터에 도달하기 전의 트래픽에 대해 부하를 분산하며 LB 스펙에 따라 L4, L7에서 트래픽을 분산할 수 있습니다.
•
이하의 이미지는 인그레스에 의해 클러스터 내부의 트래픽을 서비스로 라우팅하는 것을 보여줍니다.
2. 튜토리얼
가. 기본 조작
1) 클러스터 정보
•
클러스터 버전 확인
: Client Version 확인은 kubectl version, 반면 Server Version 확인의 경우 마스터 노드의 Kubernetes version
•
클러스터 세부 정보 확인
2) 클러스터 내 구성요소 정보
•
노드 정보 확인: 어플리케이션 호스팅할 수 있는 노드 및 노드의 상태 확인
•
노드 정보 상세 확인: Node의 IP 등의 추가 정보 확인
•
디플로이먼트 확인
•
파드 확인
3) 파드 배포
•
•
kubectl create vs kubectl apply: 두 명령 모두 파드와 디플로이먼트 생성할 수 있습니다. create의 경우 이미지를 인자로 전달하지만, apply의 경우 k8s 설정 파일을 전달합니다.
4) 기타
•
클러스터 이벤트 보기
kubectl get events
•
클러스터 환경설정 보기
kubectl config view
나. minikube 기초
1) minikube 클러스터 생성
•
minikube dashboard
: 대시보드 애드온과 프록시 활성화
: 대시보드에서 쿠버네티스 자원 생성(디플로이먼트, 서비스 등)
2) 디플로이먼트 생성
•
•
디플로이먼트 확인
kubectl get deployments
3) 서비스 생성
•
서비스 생성
kubectl expose deployment hello-node --type=LoadBalancer --port=8080
: -type=LoadBalancer: 클러스터 밖의 서비스로 노출
: hello-node 컨테이너를 쿠버네티스 외부에서 접근할 수 있도로 설정
•
서비스 생성 확인
kubectl get services
•
서비스 접근
minikube service hello-node
4) 애드온 사용
•
지원 가능한 애드온 목록 확인
minikube addons list
•
특정 애드온(metrics-server) 활성화
minikube addons enable metrics-server
•
생성한 파드와 서비스 확인하여 애드온 활성화 여부 확인
kubectl get pod,svc -n kube-system
•
특정 애드온 비활성화
minikube addons disable metrics-server
5) 클러스터 리소스 제거
•
클러스터 내 서비스 및 디플로이먼트 제거
kubectl delete service hello-node
kubectl delete deployment hello-node
Plain Text
복사
•
미니큐브 가상머신 정지
minikube stop
•
미니큐브 가상머신 삭제
minikube delete
3. 기타
가. k8s 서비스 비교
1) Docker Registry 관리형 서비스
Azure | Google | AWS | |
서비스명 | Azure Container Registry | Google Container Registry | Elastic Container Registry |
2) k8s 관리형 서비스
Azure | Google | AWS | |
서비스명 | Azure Kubernetest Service | Google Kubernetes Engine | Elastic Kubernetes Service |
3) PaaS 플랫폼 서비스
•
상대적으로 이용이 쉽기 때문에 k8s 입문자에게 사용 권장
Azure | Google | AWS | |
서비스명 | Azure Web App for Containers | Google AppEngine Flexible | Elastic Beanstalk |
4) Serverless 플랫폼 서비스
Azure | Google | AWS | |
서비스명 | Azure Functions | X | AWS Lambda |
장점 | Docker 통한 운영 지원 | ||
단점 | Docker 지원 X |
나. k8s 배포 종류
1) 관리형 k8s: 사용자가 배포만하면 k8s에서 알아서 관리해주는 형태의 배포
ex) AWS, Azure Con, Google Cloud
2) 설치형 k8s: 배포용 패키지, 설치형 쿠버네틱스 사용을 위해 고도의 전문성이 필요하므로 관리형을 권장함
ex) RANCHER, RED HAT OPENSHIFT
3) 구성형 k8s: 사용자의 필요에 맞게 커스텀하거나 교육용 목적으로 사용됨
ex) kubeadm, kops 등등
Reference
•
쿠버네티스 공식 튜토리얼, 기초 학습, https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/
•
조훈, 쉽게 시작하는 쿠버네티스(v1.20), https://www.inflearn.com/course/쿠버네티스-쉽게시작/dashboard
•
•
이진석, 파이썬/장고 웹서비스 개발 가이드, https://www.inflearn.com/course/파이썬-장고-웹서비스/dashboard