[컨테이너 오케스트레이션] 01. 쿠버네티스 주요 개념

# 학습 목표

• 컨테이너 오케스트레이션이 무엇인지 이해할 수 있다.
• 쿠버네티스의 간단한 작동 원리를 이해할 수 있다.
• 쿠버네티스 리소스 명세를 작성할 수 있다.
  • 파드 명세를 작성할 수 있다.
  • 디플로이먼트 명세를 작성할 수 있다.
  • 서비스를 이용해 파드를 노출할 수 있다.
• kubectl 명령어를 사용하여 리소스의 생성, 삭제, 조회를 할 수 있다.
• kubectl 명령어를 사용하여 롤아웃 관련 작업을 진행할 수 있다.
  • 롤링 배포 현황을 확인할 수 있다.
  • 새로운 버전에 문제가 발생했을 때 롤백할 수 있다.

(이하 advanced)

• liveness probe를 이용하여 파드의 health check를 할 수 있다.
• 쿠버네티스가 Stateful한 애플리케이션을 다루는 방법을 이해할 수 있다.
• 쿠버네티스에서 인그레스를 이용한 HTTP 기반 라우팅을 적용할 수 있다.
• helm 패키지 매니저를 사용할 수 있다.

 

---

# 학습 내용

1.  쿠버네티스와 컨테이너 오케스트레이션

쿠버네티스(Kubernetes, k8s)란?

- by google

- 오픈소스로 만들어진 컨테이너 오케스트레이션 도구

- 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링 하는 등의 관리 기능 제공

 > 각기 다른 환경(온프레미스 서버, VM, 클라우드)에 대응 가능
 

무엇을 오케스트레이션할까?

- 컨테이너 오케스트레이션 도구는 수십~수백개의 컨테이너를 관리하고자 할 때 보다 더 잘 관리하기 위한 툴

 

수십~ 수백개의 컨테이너는 어떻게 발생할까?

• 아키텍처 트렌드가 모놀리식에서 마이크로서비스로 전환
• 마이크로서비스로 전환되어 컨테이너 개수 증가
• 확장성을 고려해 스케일링까지 수행할 경우

- 예를 들어, 다섯 개 정도의 마이크로서비스를 운영하는 조직이 회사 내에 세 팀 정도가 존재하고, 최소한 두 개 이상의 레플리카(복제본)를 만든다고 가정하면, 벌써 서른(5 x 3 x 2) 개의 컨테이너가 존재할 것

- Google이 일주일에 수십억 개의 컨테이너들을 운영하게 해 준 원칙들에 따라 디자인되었기 때문에, 쿠버네티스는 운영팀의 규모를 늘리지 않고도 확장될 수 있음

 

언제 사용하지 말아야 할까?

• 여러 Tier(단계)로 나뉘지 않은 모놀리식 아키텍처에서는 적합하지 않음
  • 모놀리식 아키텍처는 먼저 마이크로서비스 분해 전략을 세우는 것이 우선
• 고작 서너 개에 불과한 컨테이너만을 다루려면 적합하지 않음
  • 서너 개의 불과한 컨테이너는 docker-compose로도 충분
• 비교적 단순한 아키텍처에, 스케일링이 필요하지 않은 경우에는 적합하지 않음
  • 이후 트래픽이 증가하거나, 스케일링이 필요한 경우, 서버리스 서비스를 사용하면 다소 저렴한 가격에 관리형 서비스를 이용할 수 있으며, AWS 내에서도 오토 스케일링과 같은 관리형 서비스가 배포 환경에서 제공

 

언제 사용할까? 또 무슨 기능이 있을까?

제공하는 기능

• 마이크로서비스를 컨테이너 방식으로 운영하는 조직이 확장성을 고려해야 할 때
• 무중단 서비스, 즉 고가용성을 제공해야 할 때
• 그 밖에 다양한 기능들: 자가 치유, 배치 실행, 구성 관리, 로드 밸런싱...

→ 특징적인 기능은 AWS와 같은 퍼블릭 클라우드 공급자에서도 비슷하게 제공하나 비용의 문제에서 자유롭지 못하므로 쿠버네티스를 사용

사용하는 이유

• 쿠버네티스를 이용해 온프레미스 상에서 (사설) 클라우드 인프라를 구성,
• 저렴한 클라우드 서비스의 일부분을 도입하여 하이브리드 형태로 구성
• 필요에 따라 쿠버네티스로 구성한 인프라를 통째로 AWS 등에 마이그레이션 (이식성)
  • 주요 퍼블릭 클라우드 공급자들은 관리형 쿠버네티스를 지원합니다. 예) AWS EKS여러 Tier(단계)로 나뉘지 않은 모놀리식 아키텍처에서는 적합하지 않음

 

2. 쿠버네티스 작동 원리와 쿠버네티스 컴포넌트

쿠버네티스 클러스터의 아키텍처

- 쿠버네티스 클러스터는 컨테이너화된 애플리케이션을 실행하는 노드라고 하는 워커 머신의 집합

출처 : https://kubernetes.io/docs/concepts/overview/components/

1. Control Plane 컴포넌트

- 쿠버네티스 클러스터에는 최소 하나이상의 제어판(Control Plane) 컴포넌트 존재

- 관리를 위해 필요한 모든 프로세스들이 존재하며, 제어판 컴포넌트는 클러스터가 잘 작동하도록 지원

- 컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 파드를 구동시키는 것)를 감지하고 반응

- 컨트롤 플레인 컴포넌트는 클러스터 내 어떠한 머신에서든지 동작할 수 있으나 간결성을 위하여, 구성 스크립트는 보통 동일 머신 상에 모든 컨트롤 플레인 컴포넌트를 구동시키고, 사용자 컨테이너는 해당 머신 상에 동작시키지 않음

- 여러 머신에서 실행되는 컨트롤 플레인 설정의 예제를 보려면 kubeadm을 사용하여 고가용성 클러스터 만들기를 확인

- 제어판 컴포넌트 구성 요소

1. API 서버 (kube-apiserver)
   • API 서버는 쿠버네티스 API를 노출하는 쿠버네티스 컨트롤 플레인 컴포넌트
   • API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드와 같음 (클러스터 관리의 입구)
   • 쿠버네티스에서 제공되는 UI, CLI 등에서 클러스터 관리를 위해 명령을 내리면 API가 호출되며 직접 호출도 가능
2. etcd
   • 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소
   • 쿠버네티스 클러스터에서 etcd를 뒷단의 저장소로 사용할 시 데이터 백업은 필수
   • 인프라를 원하는 상태로 만들기 위해서는, 정상 상태에 대한 snapshot 및 관리에 필요한 메타데이터를 저장
3. kube-scheduler (sched)
   • 노드가 배정되지 않은 새로 생성된 파드를 감지하고, 실행할 노드를 선택하는 컨트롤 플레인 컴포넌트.
   • 새로 생성된 컨테이너를 찾아 노드에 할당
   • 스케줄링 결정을 위해서 고려되는 요소는 리소스에 대한 개별 및 총체적 요구 사항, 하드웨어/소프트웨어/정책적 제약, 어피니티(affinity) 및 안티-어피니티(anti-affinity) 명세, 데이터 지역성, 워크로드-간 간섭, 데드라인을 포함
4. kube-controller-manager (c-m)
   • 컨트롤러 프로세스를 실행하는 컨트롤 플레인 컴포넌트로 클러스터에서 무슨 일이 발생하는지를 추적하는 역할
   • 논리적으로, 각 컨트롤러는 분리된 프로세스이지만, 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되고 단일 프로세스 내에서 실행됨
   • 구성
     • 노드 컨트롤러: 노드가 다운되었을 때 통지와 대응에 관한 책임 지님
     • 잡 컨트롤러: 일회성 작업을 나타내는 잡 오브젝트를 감시한 다음, 해당 작업을 완료할 때까지 동작하는 파드를 생성
     • 엔드포인트 컨트롤러: 엔드포인트 오브젝트를 채움 (즉, 서비스와 파드를 연결시킴)
     • 서비스 어카운트 & 토큰 컨트롤러: 새로운 네임스페이스에 대한 기본 계정과 API 접근 토큰을 생성
5. cloud-controller-manager (c-c-m)
   • 클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트
   • 클라우드 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와만 상호 작용하는 컴포넌트를 구분 가능
   • cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행하며 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없음
   • kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적으로 독립적인 여러 컨트롤 루프를 단일 프로세스로 실행하는 단일 바이너리로 결합하고 수평으로 확장(두 개 이상의 복제 실행)해서 성능을 향상시키거나 장애 방지 가능
   • 클라우드 제공 사업자와 의존하는 컨트롤러
     • 노드 컨트롤러: 노드가 응답을 멈춘 후 클라우드 상에서 삭제되었는지 판별하기 위해 클라우드 제공 사업자에게 확인하기 위한 컨트롤러
     • 라우트 컨트롤러: 기본 클라우드 인프라에 경로를 구성하기 위한 컨트롤러
     • 서비스 컨트롤러: 클라우드 제공 사업자 로드밸런서를 생성, 업데이트 그리고 삭제하기 위한 컨트롤러

2. Node 컴포넌트

출처 : https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/

- 워커 노드

- 제어판과 연결되어있음

- 즉, 워커 안에는 한 개 이상의 컨테이너가 존재하며 워커 노드는 실제로 애플리케이션이 실행되고 있는 곳

- 파드는 언제나 노드 상에서 동작하며 하나의 노드는 여러 개의 파드를 가질 수 있음

- 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있고 노드는 컨트롤 플레인에 의해 관리

- 쿠버네티스 컨트롤 플레인은 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리하며 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용 가능한 리소스를 모두 고려

- 쿠버네티스 노드의 동작 방식

• Kubelet은, 쿠버네티스 컨트롤 플레인과 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리
• 컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임 가짐

- 노드 구성 요소

1. kubelet
   • 워커 노드 안에서 돌아가는 프로세스로 다른 노드와 서로 통신하거나, 컨테이너를 실행하는 등의 태스크를 실행
   • 클러스터의 각 노드에서 실행되는 에이전트
   • 파드에서 컨테이너가 확실하게 동작하도록 관리
2. kube-proxy
   • 클러스터의 각 노드에서 실행되는 네트워크 프록시로 쿠버네티스 서비스 개념의 구현부
   • 노드의 네트워크 규칙을 유지/관리하며 이 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 파드로 네트워크 통신을 할 수 있도록 허용
   • 운영체제에 가용한 패킷 필터링 계층이 있는 경우 이를 사용하고, 없는 경우 트래픽 자체를 포워드함
3. 컨테이너 런타임
   • 컨테이너 실행을 담당하는 소프트웨어
   • 쿠버네티스는 containerd, CRI-O와 같은 컨테이너 런타임 및 모든 Kubernetes CRI (컨테이너 런타임 인터페이스) 구현체를 지원
     
     

3. Pod

- 파드(Pod) 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 쿠버네티스 플랫폼 상에서 최소 단위

- 파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유

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

4. 애드온 (addons)

- 애드온은 쿠버네티스 리소스(데몬셋, 디플로이먼트 등)를 이용하여 클러스터 기능을 구현하며 클러스터 단위의 기능을 제공하기 때문에 애드온에 대한 네임스페이스 리소스는 kube-system 네임스페이스에 속함

- 애드온 종류

1. DNS
   • 클러스터 DNS는 구성 환경 내 다른 DNS 서버와 더불어, 쿠버네티스 서비스를 위해 DNS 레코드를 제공해주는 DNS 서버
   • 쿠버네티스에 의해 구동되는 컨테이너는 DNS 검색에서 이 DNS 서버를 자동으로 포함
2. 웹 UI (대시보드)
   • 대시보드는 쿠버네티스 클러스터를 위한 범용의 웹 기반 UI
   • 사용자가 클러스터 자체뿐만 아니라, 클러스터에서 동작하는 애플리케이션에 대한 관리와 문제 해결을 할 수 있도록 지원
3. 컨테이너 리소스 모니터링
   • 컨테이너 리소스 모니터링은 중앙 데이터베이스 내의 컨테이너들에 대한 포괄적인 시계열 매트릭스를 기록하고 그 데이터를 열람하기 위한 UI를 제공
4. 클러스터-레벨 로깅
   • 클러스터-레벨 로깅 메커니즘은 검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장

 

3. 쿠버네티스 설치

minikube 설치

- 공식 문서를 통해 minikube 설치

$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_latest_amd64.deb
$ sudo dpkg -i minikube_latest_amd64.deb

 

minikube 시작하기

Step 1 :  minikube start 명령 실행

- 도커와 같은 가상화 도구가 실행된 상태에서쿠버네티스를 실행할 수 있으므로 사전에 도커 설치 필요

$ minikube start

😄  minikube v1.30.1 on Ubuntu 22.04 (amd64)
✨  Using the docker driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🏃  Updating the running docker "minikube" container ...
🐳  Preparing Kubernetes v1.26.3 on Docker 23.0.2 ...|- ^[| ^[- ^[
🔗  Configuring bridge CNI (Container Networking Interface) ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

 

Step 2 : 정상 작동 확인

 - 잘 작동되는지 확인하려면, kubectl get pods -A 명령을 실행

$ kubectl get pods -A
NAMESPACE     NAME                               READY   STATUS    RESTARTS      AGE
kube-system   coredns-787d4945fb-g4lsj           1/1     Running   2 (74s ago)   11m
kube-system   etcd-minikube                      1/1     Running   3 (78s ago)   12m
kube-system   kube-apiserver-minikube            1/1     Running   2 (76s ago)   12m
kube-system   kube-controller-manager-minikube   0/1     Running   3 (33s ago)   12m
kube-system   kube-proxy-d9qg5                   1/1     Running   3 (79s ago)   11m
kube-system   kube-scheduler-minikube            1/1     Running   2 (79s ago)   12m
kube-system   storage-provisioner                1/1     Running   4 (81s ago)   11m

  > -A 옵션 : 모든 네임스페이스에 존재하는 모든 파드를 조회하는 명령어

- 다음 결과를 통해 앞서 배운 쿠버네티스 작동 원리에서 다뤘던 제어판(Control Plane)의 구성요소가 파드로 존재함을 확인 가능

 

Action Items

Cozserver라는 웹 애플리케이션을 작동시키기
1. 이미지를 바탕으로 디플로이먼트라는 단위를 통해 배포
2. 서비스를 이용해 노출

Step 1 : minikube를 이용해서 클러스터를 생성

$ minikube start

😄  minikube v1.30.1 on Ubuntu 22.04 (amd64)
✨  Using the docker driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🏃  Updating the running docker "minikube" container ...
🐳  Preparing Kubernetes v1.26.3 on Docker 23.0.2 ...|- ^[| ^[- ^[
🔗  Configuring bridge CNI (Container Networking Interface) ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟  Enabled addons: storage-provisioner, default-storageclass
🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Step 2 : cozserver라는 이미지를 사용해 배포 가능한 리소스(디플로이먼트, deployment)를 생성

$ kubectl create deployment hello-minikube --image=sebcontents/cozserver:1.0
deployment.apps/hello-minikube created

Step 3 : 서비스(service)로 노출

$ kubectl expose deployment hello-minikube --type=NodePort --port=8080
service/hello-minikube exposed

 Step 4 : 로컬 클러스터를 호스트 컴퓨터에서 접속할 수 있도록 포트 포워딩

$ kubectl port-forward service/hello-minikube 3333:8080
Forwarding from 127.0.0.1:3333 -> 8080
Forwarding from [::1]:3333 -> 8080

Step 5 : 브라우저를 열어서 http://localhost:3333으로 접속

Step 5 : 클러스터 종료

$ minikube delete --all
🔥  Deleting "minikube" in docker ...
🔥  Removing /home/roheerumi/.minikube/machines/minikube ...
💀  Removed all traces of the "minikube" cluster.
🔥  Successfully deleted all profiles

 

---

# References

https://kubernetes.io/ko/docs/concepts/overview/components/

쿠버네티스 컴포넌트

https://kubernetes.io/ko/docs/concepts/workloads/pods/

파드

https://kubernetes.io/ko/docs/tutorials/kubernetes-basics/explore/explore-intro/

파드와 노드 보기

https://learn.microsoft.com/ko-kr/windows/wsl/install

WSL 설치

https://learn.microsoft.com/ko-kr/windows/wsl/install-manual

이전 버전 WSL의 수동 설치 단계

https://learn.microsoft.com/ko-kr/windows/wsl/tutorials/wsl-containers

WSL에서 Docker 컨테이너 시작

https://wp.openframe.co.kr/?page_id=167&vid=12 

[WSL2] ssh 서비스 자동 실행 하기

https://cla9.tistory.com/92

3. 쿠버네티스 클러스터 구축 - Docker & 쿠버네티스 클러스터 설치