[Kubernetes] 쿠버네티스란? 기본 특징 쉽게 정리 (파드, 클러스터, 노드)

 

🟢 쿠버네티스를 이해하기 위해서는 먼저 도커와 컨테이너에 대한 개념 이해하고 있어야 한다.

 

도커와 쿠버네티스는 수어지교(水魚之交)이다

아래 이미지를 보면 Kubernetes 에 대해서 쉽게 이해할 수 있다.

 

 

 

Container + Orchestration (컨테이너 오케스트레이션)

수 많은 연주자들이 지휘에 맞춰 연주하는 것이 "오케스트라"라고 한다.
Kubernets 는 지휘자이며  Docker Container 가 연주자인 형태가 컨테이너 오케스트레이션이다.

쿠버네티스의 이미지

 

 

 

Kubernetes 간단히 개념 정리

• 쿠버네티스 (Kubernetes, K8s) 라고 적는다.
• 오픈 소스 (Open Source) 시스템이다.
• 컨테이너 오케스트레이션 (Container Orchestration) 이라고 불린다.
• 과거 구글에 의해 설계되었고 현재 리눅스 재단에 의해 관리되고 있다.

™ 참고)

• Kubernete 라는 단어의 실제 뜻은 그리스어로  ‘조정', ‘통제' 이다
• 구글에서 처음 만들기 시작할 때 프로젝트명이 ‘Project 7' 이었다. 그래서 로고가 7개로 구성된 방향타이다.
• 약자로 'K8s' 라고 하며 이유는 ‘k’와 ‘s’사이에 8개 글자가 있기 때문이다

 

 

 

☸ Kubernetes는 컨테이너화된 애플리케이션을 쉽게 관리하기 위한 오픈소스 플랫폼이다.

대량의 컨테이너는 쿠버네티스가 관리한다.

 

 

 쿠버네티스가 필요하게 된 이유

 

1. 컨테이너화의 증가
   • 컨테이너를 사용한 어플리케이션이 증가하였다
     • (개발하는데 컨테이너가 편리하기 때문에)
   • 컨테이너를 관리 할 수 있는 플랫폼에 대한 필요성 증가 📈
2. 클라우드의 증가
   • 과거에는 On Premise 환경에서 직접 서버를 관리했다. (기본적으로 클라우드보다 어렵다)
   • On Premise의 문제점
     • 확장성 (Scalability) 제한적이다
       (예시: 만약 사용량이 증가하면 직접 물리적 서버를 사와서 설치까지 해야한다)
     • 배포 관리 방법이 기본적으로 어려웠다.
       (예시: 모든 물리적 서버에 소프트웨어같은거 설치 똑같이 해줘야 한다)
   • 클라우드가 보편화되면서, 어플리케이션을 클라우드에서 더 유연하게 분산되고 확장되어야 하는 필요성 증가
     • 클라우드에서는 배포/확장 관리 해주는 플랫폼만 있다면 더 유연하게 확장될 수 있기 때문에...
   • 배포/확장 할 수 있는 플랫폼에 대한 필요성 증가 📈

 

 

 🦾 쿠버네티스의 특징

자동 배포, 확장 (오케스트레이션)

• Auto Scaling
  • 트레픽 양에 따라 각 서비스의 리소스를 자동으로 변경하는 기능.
  • 수직 오토 스케일링 (Vertical Pod Autoscaler - VPA):
    리소스의 크기를 동적으로 조절하여 트래픽의 증가 또는 감소에 대응한다.
    리소스의 성능을 높이는 것 이다. 
  • 수평 오토 스케일링 (Horizontal Pod Autoscaler - HPA):
    리소스의 수를 동적으로 조절하여 트래픽의 증가 또는 감소에 대응한다.
    리소스의 갯수를 늘리는 것 이다.
• Auto Healing 
  • 서비스에 장애나 이상 상태에 대응하여 자동으로 복구하는 기능.
  • 서버(노드) 와 컨테이너를 주기적으로 체크하고, 문제가 발생하면 해당 상태를 복구하려고 한다.
  • Node Auto Healing:
    노드(물리적 서버) 중 하나에 문제가 생기면, 클러스터는 해당 노드를 자동으로 감지하고 대체 노드를 만들어서 애플리케이션의 중단 없이 계속 실행될 수 있도록 한다.
    
  • Pod Auto Healing:
    Pod(컨테이너)가 이상 상태에 빠졌을 때 해당 Pod을 다시 시작하거나 대체 Pod을 생성하여 서비스를 유지한다.
    

 

 

 

쿠버네티스를 이해하기 위한 전문 용어

🎨 쿠버네티스의 구성요소 

쿠버네티스 구성요소: https://kubernetes.io/ko/docs/concepts/overview/components/

 

 

kubectl

쿠버네티스의 명령줄 툴

kubectl를 사용하여 쿠버네티스의 상태를 확인하거나 원하는 상태로 변하게 명령어를 입력할 수 있다.

 

쿠버네티스 명령어 기본 구조

kubectl [COMMAND] [TYPE] [NAME] [flags]

◊ 구체적인 내용: https://kubernetes.io/ko/docs/reference/kubectl/

 

 

노드 (Node)  ≈  컴퓨터

쿠버네티스의 노드는 컨테이너를 실행하는 물리 서버 또는 가상 머신이다.

→ 어렵지않다. 노드는 그냥 컨테이너가 돌아가는 💻컴퓨터인 셈이다. (EC2 인스턴스)

 

클러스터 (Cluster)

쿠버네티스의 클러스터는 컨테이너를 실행하는 노드의 집합이다.

여러 컴퓨터를 묶어서 하나의 시스템처럼 동작하도록 한다.

→ 어렵지않다. 클러스터는 그냥 💻컴퓨터의 집합

 

 

 

 

 

클러스터 구성요소

쿠버네티스 클러스터는 컨트롤 플레인(마스터 노드)과 컴퓨팅 머신(워커 노드) 두 개의 부분으로 구분할 수 있다. 

1. 👨‍💼 마스터 노드 (Master Node) : 관리자 역할의 노드
   

   • 클러스터의 중앙 관리 노드이다.

     • 클러스터의 구성을 관리한다.
     • 클러스터의 워커 노드를 관리한다.
     • 클러스터 내 애플리케이션을 배포하고 관리한다.
2. 👷‍♂️ 워커 노드 (Worker Node) : 실제 실행 역할의 노드

   • 클러스터에서 실제 애플리케이션을 실행하는 시스템입니다

     • 클러스터의 애플리케이션을 실행합니다.
     • 클러스터의 네트워킹을 관리합니다.
     • 클러스터의 스토리지를 관리합니다.

마스터 노드가 죽으면 클러스터를 관리할 노드가 없기에 이상적으로는 3개 이상의 마스터 노드를 사용하는 것이 권장된다.

워커 노드는 배포되는 애플리케이션의 크기와 요구사항에 따라 다르지만 이상적으로는 수십 개에서 수백 개의 워커 노드를 갖는 클러스터가 일반적이다.

 

 

네임스페이스 (Namespace)

네임스페이스(Namespace)란, 클러스터 내의 논리적인 분리 단위이다.

(물리적으로 분리하는건 아니다.)

 

😵 네임스페이스가 필요한 이유

규모가 큰 시스템의 클러스터를 분리하고 싶을 때 네임스페이스를 사용하면 좋다.

   → 동일한 클러스터에서 여러 팀이나 프로젝트가 서로 간섭 없이 독립적으로 동작할 수 있다.

 

각 네임스페이스는 독립된 가상 클러스터처럼 작동하며, 같은 이름의 리소스도 서로 다른 네임스페이스에서 격리되어 사용된다.

 

👩‍🏫 사용 예시) Dev, QA, Default의 네임스페이스로 클러스터를 분리.

 

출처:https://www.appvia.io/blog/best-practices-for-kubernetes-namespaces

 

 

파드 (Pod)

 

파드(Pod)는 본래 🐳🐳🐳 고래의 떼를 일컫는 용어이다 

도커의 로고에 쓰인 고래의 이미지를 따서 이런 명칭이 붙었다.

 

 

Pod는 쿠버네티스에서 컨테이너를 실행하는 가장 기본 단위이다. (컨테이너를 배포하려면 Pod을 생성해야 한다.)

→ 어렵지않다.  Pod는 그냥 컨테이너의 집합이다.

 

⭐ Pod 특징

• (당연하지만) Pod는 하나 이상의 Container 로 구성된다.
  • 웬만한 어플리케이션은 하나 이상의 container를 동시에 실행해야 된다.
  • (Ex. 웹 서버 컨테이너와 데이터베이스 container →  2개의 컨테이너를 포함하는 Pod)
• 네트워크 공유: Pod에 포함된 모든 Container는 동일한 하나의 IP 주소를 갖는다.
  
  • Pod의 Container가 서로 통신하기 위해. 
  • Pod는 Node IP와 별개로 고유 IP를 할당 받는다
  • 서로 localhost 로 통신 가능
• Volume 공유: Pod의 Container들은 Volume 을 공유하여 사용하는 것이 가능하다.
  • Volume이란,  Container가 삭제되어도 독립적으로 남아 있는 데이터를 의미한다.

 

👩‍🏫 사용 예시) Nginx와 MySQL를 사용하는 Pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx-mysql-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80   # Nginx가 사용하는 포트

  - name: mysql-container
    image: mysql:latest
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "your-root-password"  # MySQL root 비밀번호 설정
    ports:
    - containerPort: 3306  # MySQL이 사용하는 포트

 

 

컨트롤 플레인 (Control Plane)

쿠버네티스의 노드를 제어하는 프로세스들이 모여있는 곳이다.

클러스터의 상태를 모니터링하고, 애플리케이션을 배포하고, 노드를 관리하는 데 사용되는 컴포넌트 세트입니다.

 

컨트롤 플레인 구성 요소

1. kube-apiserver (API 서버)
2. etcd (분산 저장소)
3. kube-controller-manager (컨트롤러 관리자)
4. kube-scheduler (스케줄러)

Control Plane Flow

 

위의 그래프를 보면 쉽게 컨트롤 플레인의 흐름을 이해 할 수 있다.

 

🔷 kube-apiserver (API 서버):

• kube-apiserver를 아주 쉽게 비유하면 "중앙 통제실"이다.
  
  • 중앙 통제자로서 조직 내에서 의사소통을 중앙에서 관리하고, 중요한 결정을 하는 역할을 한다. 
• 클러스터와 상호 작용하는 모든 구성 요소(kubectl, etcd, scheduler, ...etc)는 kube-apiserver를 통해 통신한다. 
• kube-apiserver는 이름 그대로 API 웹 서버이다.
  • RESTful 서버로 동작한다.
  • API 엔드포인트 제공한다 → HTTP나 HTTPS를 통해 개발자는 서버에 접근해서 작업 할 수 있다
  • 기본적으로 HTTP나 HTTPS로 통신한다.

 

🔷 etcd (분산 저장소): 

• etcd를 쉽게 비유하면 "클러스터의 저장소"이다
• 클러스터에서 사용되는 모든 데이터가 etcd에 key-value 형태로 저장된다.
  • (Ex. 클러스터에 어떤 노드가 몇 개나 있는지와 같은 정보가 etcd에 저장된다)
  • Cluster에 문제가 생겼더라도 etcd에 문제없이 백업되어있다면 Cluster를 복구하는것이 가능하다.
  • etcd의 데이터가 유실되어버리면 Cluster가 사용하는 모든 리소스(ex.컨테이너)들을 활용할 수 없게 된다.

분산형 key-value 저장: 

etcd는 여러 노드에 걸쳐 분산되어 작동하며, 데이터의 일관성과 안정성을 보장하기 위해 Raft 분산 합의 알고리즘을 사용한다. 이를 통해 클러스터 내의 모든 노드가 동일한 상태를 유지할 수 있다.

 

API 서버와의 통신:
API 서버는 etcd와 통신하여 클러스터의 상태를 읽거나 쓸 수 있다.
이를 통해 클러스터의 상태 변화에 대한 모니터링 및 제어가 가능하다.

 

참고자료

https://etcd.io/

 

🔷 kube-scheduler (스케줄러): 

• kube-scheduler를 아주 쉽게 비유하면 "창고 관리자"이다.
  • 여러 종류의 물건(파드)들이 창고로 들어오는데 각각은 특정 크기와 무게를 가지고 있다.
  •  kube-scheduler는 창고 관리자로서, 새로운 물건(파드)이 창고에 들어올 때 이 물건을 어느 섹션에 어떻게 배치할지 결정한다.
• 마스터 노드에 위치해있다.
• Pod를 어떤 워커 노드에 배치할지 결정하는 역할을 한다.
• kube-scheduler는 다양한 정책과 알고리즘(리소스 요구, 제약 조건, 사용자 정의 정책 등)을 사용하여 최적의 노드를 찾아내 Pod를 배치한다.
• 예약 및 선점: 
  노드의 리소스를 예약하고, 특정 파드가 특정 노드에서만 실행되도록 선점(Preemption) 기능을 지원한다.
• 플러그인 아키텍처:
  플러그인 아키텍처를 통해 사용자는 커스텀 스케줄링 로직을 구현하고 적용할 수 있다.

 

 

🔷 kube-controller-manager (컨트롤 매니저): 

• kube-controller-manager를 아주 쉽게 비유하면 클러스터의 "경비원"이다.
  • 경비원은 건물을 안전하게 유지하기 위해 다양한 작업을 수행한다. (출입 통제, 비상 상황 대응, 정기적인 점검 및 유지보수 등)
• kube-controller-manager의 역할은 클러스터의 상태를 지속적으로 모니터링하고, 개발자가 지정한 상태로 유지하기 위해 다양한 작업을 수행합니다
• kube-controller-manager에는 다양한 컨트롤러가 있다
  • Node Controller: 
    노드 컨트롤러는 클러스터 내 노드의 상태를 감시하고, 노드가 다운되거나 사용 불가능한 경우 해당 노드를 대체할 새로운 노드를 생성합니다.
    
    Replication Controller / ReplicaSet Controller: 
    Replication Controller와 ReplicaSet Controller는 파드의 복제를 관리하고 유지합니다. 원하는 파드의 복제 수를 유지하고, 파드의 배포 및 업데이트를 처리합니다.
    
    Endpoint Controller: 
    서비스와 파드 간의 연결을 관리하는 역할을 합니다. 새로운 파드가 생성되거나 제거될 때 Endpoint Controller는 해당 서비스의 엔드포인트를 업데이트하여 연결을 유지합니다.
    
    Service Account & Token Controller: 
    Service Account 및 Token Controller는 각 네임스페이스에 대한 기본 서비스 계정과 관련된 인증 토큰을 생성 및 갱신합니다.
    
    Namespace Controller: 
    네임스페이스를 생성하고 삭제하며, 각 네임스페이스에 대한 정책을 관리합니다.
    
    Service Controller: 
    서비스의 수명 주기를 관리하고, 사용자가 지정한 서비스의 유형 및 엔드포인트를 유지합니다.
    
    Volume Controller: 
    볼륨 컨트롤러는 파드의 볼륨을 관리하고, 볼륨을 생성하거나 삭제하며, 파드와 볼륨 간의 연결을 관리합니다.
    
    DaemonSet Controller: 
    DaemonSet을 관리하며, 클러스터의 모든 노드에 특정 파드를 실행하는 역할을 합니다.
    
    Job Controller: 
    Job을 관리하고 완료된 작업을 청소하는 역할을 합니다.