🎯 Kubernetes에 대해 정리합니다.

📗 Today I Learned

마이크로서비스 아키텍처(MSA; Microservice Architecture)

출처: gabia

하나의 애플리케이션을 여러 개의 작은 서비스로 나누어 개발 및 운영하는 아키텍처 스타일입니다.

• 각 서비스는 자체적으로 배포 및 확장이 가능합니다.

• 서비스 간 통신은 보통 API를 통해 이루어집니다.

• 하나의 서비스에 장애가 발생하더라도, 다른 서비스는 영향을 받지 않고 동작할 수 있습니다.

• 개발과 유지보수, 배포가 유연하고 효율적입니다.

마이크로서비스 아키텍처는 각각의 서비스가 독립적으로 실행되어야 하므로, 컨테이너 모델과 매우 잘 어울립니다.

• 컨테이너는 서비스를 격리된 단위로 실행할 수 있도록 도와줍니다.

• 어디서나 동일한 환경에서 동작하기 때문에, 일관성과 이식성이 뛰어납니다.

• 따라서 마이크로서비스 아키텍처를 구현할 때는 컨테이너 기반의 운영 환경이 매우 효과적입니다.

Monolithic vs MSA

• 모놀리식 아키텍처 (Monolithic Architecture)

  • 모든 기능이 하나의 큰 애플리케이션 안에 통합되어 있으며, 하나의 덩어리로서 동작합니다.

  • 배포나 유지보수가 어렵고, 하나의 문제가 전체 시스템에 영향을 줄 수 있습니다.

• 마이크로서비스 아키텍처 (MSA)

  • 애플리케이션을 기능 단위로 나누어 각각의 서비스를 독립적으로 개발하고 배포할 수 있도록 구성합니다.

  • 각 서비스는 특정한 기능을 담당하며, 서로 연결되어 전체 애플리케이션을 구성합니다.

🔁 배포 구조의 변화 요약
출처: https://fullstackdeeplearning.com/

1. Traditional Deployment

• 하나의 서버에 모든 걸 올리는 구조
• 모놀리식 아키텍처에 해당하며, 확장성과 유연성이 부족함

2. Virtualized Deployment

• 가상 머신을 이용해 격리성을 확보
• 하지만 각 VM이 무거워 자원 낭비가 큼

3. Container Deployment

• 컨테이너 기술로 가볍고 빠른 실행 가능
• 마이크로서비스를 각 컨테이너로 분리하여 실행하는 데 적합

4. Kubernetes Deployment

• 컨테이너가 많아지면서 여러 대의 서버에 분산되어 실행, 이를 자동으로 관리하고 조율하는 도구가 필요해짐
• Kubernetes는 마이크로서비스 환경에서 컨테이너를 효율적으로 배치, 실행, 복구, 확장할 수 있도록 도와줌
• ✨ 컨테이너가 있기 때문에 각 서버(노드)마다 Docker와 같은 컨테이너 런타임이 설치되어 있어야 하며, Kubernetes는 이러한 Docker 환경들을 여러 개의 워커 노드(실제로 실행하는 서버)로 묶어 하나의 클러스터로 구성됨

👉 마이크로서비스는 개별적으로 실행되는 컨테이너가 많아지기 때문에, 이를 통합적으로 관리해줄 수 있는 '컨테이너 오케스트레이션 도구'가 꼭 필요합니다. 그 중 가장 대표적인 도구가 바로 Kubernetes입니다.

---

Kubernetes

출처: wikimedia

Kubernetes (줄여서 k8s)는 컨테이너 오케스트레이션 솔루션, 즉 컨테이너들을 지휘하고 조율하는 도구입니다.

• 수많은 컨테이너를 자동으로 배포하고, 실행 중인 컨테이너의 상태를 지속적으로 관리하며, 트래픽이나 부하 상황에 따라 컨테이너 수를 자동으로 확장하거나 축소하는 등의 복잡한 작업을 자동화해줍니다.

특징

• Docker 컨테이너들과 함께 사용하기 적합합니다.

• 클러스터 내에서 여러 컨테이너를 실행하고 관리할 수 있어 CI/CD 파이프라인에서도 유용하게 쓰입니다.

• 각 컨테이너는 Pod라는 k8s 오브젝트 단위로 실행됩니다.

---

Kubernetes Cluster

클러스터(Cluster)는 여러 대의 컴퓨터(서버)를 하나처럼 묶어서 동작하게 만든 시스템 단위로 Kubernetes에서는 컨테이너를 관리하는 서버들의 집합을 클러스터라고 합니다.
출처: Kubernetes

구성 요소

Kubernetes 클러스터는 크게 두 부분으로 나뉘어 있습니다.

1️⃣ 마스터 노드 (컨트롤 플레인)

• API Server (api)

  • kubectl 등 외부에서 오는 요청을 받아들이는 클러스터의 입구입니다.

  • 모든 명령은 이곳을 통해 클러스터 내부 컴포넌트로 전달됩니다.

    🤔 kubectl는 무엇일까?

    사용자가 클러스터를 조작하기 위해 사용하는 CLI 도구입니다.

• etcd

  • 클러스터의 상태를 저장하는 Key-Value 저장소입니다.

  • 어떤 Pod가 어디에 있는지, 노드 상태 등 모든 정보가 여기에 기록됩니다.

    🤔 Pod는 무엇일까?

    Pod는 하나 이상의 컨테이너를 감싸고 있는 논리적인 단위로, 같은 네트워크 공간(IP)과 스토리지를 공유합니다.

    Pod는 워커 노드(Node) 안에서 실행됩니다. kubelet이 Pod를 실행시키는 역할을 하는 컨트롤러이기 때문에, Pod는 kubelet 밑에서 실제로 돌아가고 있는 실행 유닛입니다.

    ---

    🧪 왜 그냥 컨테이너가 아니라 Pod일까?

    Kubernetes는 Docker 컨테이너만 직접 다루지 않기 때문에 여러 컨테이너를 하나의 논리적 단위인 Pod으로 묶어 클러스터 내에서 효율적으로 배포하고 운영합니다.

• Controller Manager (c-m)

  • 클러스터의 실제 상태가 선언한 상태와 다르면, 이를 자동으로 조정해줍니다.

• Cloud Controller Manager (c-c-m)

  • AWS, GCP 등 클라우드 인프라와 통신하는 역할입니다.

• Scheduler (sched)

  • 새로 생성될 Pod가 어느 노드에 배치될지 결정하는 컴포넌트입니다.

2️⃣ (워커) 노드

• 컨테이너 런타임(CRI; Container Runtime Interface)

  • Pod 내부의 컨테이너를 실제로 실행시키는 프로그램입니다.

• kubelet

  • Pod의 구성 내용을 받아 CRI에 전달하고 컨테이너들의 동작 상태를 모니터링합니다.

• kube-proxy (k-proxy)

  • 서비스 간 통신을 위해 네트워크 트래픽을 올바른 Pod로 라우팅합니다.

---

k8s가 제공하는 기능

• 컨테이너 밸런싱

  • Pod의 부하 균등화를 자동으로 수행합니다. 몇 개의 응용을 복제할지 설정만 하면, Kubernetes가 알아서 적절하게 분산 배치합니다.

• 트래픽 로드 밸런싱

  • 동일한 응용의 복제본(Pod)이 여러 개일 경우, 외부 또는 내부에서 들어오는 요청을 자동으로 분산시켜 서비스의 안정성을 유지합니다.

• 동적 수평 스케일링

  • 트래픽이나 자원 사용량에 따라 Pod 수를 자동으로 확장하거나 축소합니다. 이를 통해 시스템 자원을 효율적으로 활용할 수 있습니다.

• 오류 복구

  • Pod나 노드에 장애가 발생했을 경우, Kubernetes는 이를 감지하고 자동으로 새로운 Pod 를 생성하여 복구합니다.

• 롤링 업데이트

  • 서비스를 중단하지 않고 점진적으로 새 버전을 배포할 수 있습니다. 문제가 생기면 빠르게 이전 버전으로 되돌릴 수 있는 롤백 기능도 제공합니다.

• 스토리지 오케스트레이션

  • 다양한 스토리지 시스템과 연동하여 Pod에 필요한 볼륨을 자동으로 연결해줍니다.

• 서비스 디스커버리

  • Pod의 IP는 동적으로 바뀌기 때문에, 자체 DNS를 이용해 안정적인 접속 주소를 제공합니다.

---

Pod의 생명 주기

1. 사용자가 kubectl을 통해 API 서버에 Pod 생성을 요청합니다.

2. API 서버는 요청을 받아 etcd에 상태를 기록하고, 클러스터 상태를 최신으로 유지하려고 합니다.

3. 컨트롤러 매니저가 Pod를 생성하고, 그 정보를 API 서버에 전달합니다. (아직 어떤 노드에 실행될지는 정해지지 않음)

4. 스케줄러가 Pod를 실행할 적절한 워커 노드를 선택합니다.

5. 해당 노드의 kubelet이 컨테이너 런타임(CRI)에 요청하여 Pod를 생성하고 실행합니다.

💡 Kubernetes는 절차형이 아니라 선언형 구조를 따릅니다. 원하는 상태를 선언하면, 현재 상태와 비교하여 이를 지속적으로 맞추기 위해 동작합니다.

---

⚙️ 관계 구조

Node
 ├── Pod A
 │    ├── Container 1
 │    └── Container 2
 ├── Pod B
 │    └── Container 3
 └── Pod C
      └── Container 4

---

k8s 리소스 흐름도

출처: 개인블로그 https://blog.taehun.dev/from-zero-to-hero-mlops-tools-3-1

• Namespace

  • k8s 클러스터에서 사용되는 리소스를 그룹별로 분리하여 관리할 수 있게 해주는 논리적 공간입니다.

• Deployment

  • Pod의 선언, 배포, 업데이트, 복제 등을 자동화하기 위한 컨트롤러입니다.

  • 내부적으로 ReplicaSet을 이용해 Pod 수를 관리하며, 버전 변경 시 롤링 업데이트를 지원합니다.

• ReplicaSet

  • 특정 수의 Pod를 항상 유지해주는 컨트롤러입니다.

  • 예를 들어 3개의 Pod가 설정되어 있을 때, 하나가 죽으면 자동으로 새로 생성합니다.

• Pod
  • 하나 이상의 컨테이너로 구성된 가장 작은 실행 단위입니다. 고유한 IP를 갖고 있으며, 언제든지 종료될 수 있는 성질을 가집니다.

• Volume

  • Pod가 생성될 떄 Pod에 마운트되는 저장 공간으로, 컨테이너 간 데이터 공유 등에 사용됩니다.

• Service

  • 여러 Pod 앞에 있는 네트워크 접근 지점입니다.

  • Pod는 IP가 바뀔 수 있기 때문에, 안정적인 접근을 위해 고정된 엔드포인트를 제공합니다.

  • 서비스의 다른 형태들

    • ClusterIP
      • 클러스터 내부에서만 접근 가능한 기본 타입입니다. 외부에서는 접근할 수 없고, 내부 서비스 간 통신에 사용됩니다.
        
    • NodePort
      • 각 노드의 포트를 열어 외부에서도 접근 가능하게 해줍니다.
        
    • LoadBalancer
      • 클라우드 환경에서 외부에 공인 IP를 노출해주는 타입입니다.
        출처: 개인블로그

    • ExternalName

      • 외부 DNS 이름을 내부 서비스 이름으로 매핑할 수 있도록 해줍니다.

• Ingress

  • 외부 사용자의 HTTP/HTTPS 요청을 Service로 라우팅해주는 역할을 합니다.

  • 외부에서 하나의 IP로 여러 서비스에 접근할 수 있도록 하기 위한 진입 지점입니다.
    출처: geeksforgeeks

---

k8s 인프라 구축

• 로컬 환경 구축

  • kubeadm, Docker Desktop 등을 통해 간단히 테스트용 클러스터를 구성할 수 있습니다.

• 퍼블릭 클라우드 서비스

  • Amazon AWS EKS (Elastic Kubernetes Services)

  • GCP GKE (Google Kubernetes Engine)

  • Microsoft AKS (Azuer Kubernetes Service)

• 온프레미스 설치형 솔루션

  • SUSE Rancher

  • RedHat OpenShift

---

실습

실습 준비

• ⚙️ Docker Desktop > Settings > Kubernetes > Enable Kubernetes ✅ 토글을 활성화합니다.

• kubectl get nodes 명령어 실행 → 노드가 잘 등록되었는지 확인합니다.

Pod → Deployment → Service 절차형 구조 실습

쿠버네티스에서 Pod를 직접 실행해보고, Deployment를 통해 관리하며, Service로 외부에 노출하는 전체 흐름을 실습합니다.

1️⃣ 전체 네임스페이스에서 Pod 조회

kubectl get pods --all-namespaces

• 모든 네임스페이스에 있는 Pod 목록을 보여줍니다.

2️⃣ 개별 Pod 생성

kubectl run nginx-pod --image=nginx

• nginx 이미지를 사용해서 nginx-pod라는 단일 Pod를 실행합니다.

💡 이 명령어는 Deployment 없이 단일 Pod만 직접 실행합니다. 실무보다는 실습이나 테스트용으로 자주 사용됩니다.

3️⃣ Deployment 생성

kubectl create deployment dpy-nginx --image=nginx
kubectl get deployment -o wide

• nginx 이미지를 기반으로 dpy-nginx라는 Deployment를 생성합니다.

• -o wide 옵션은 IP, 노드 등 추가 정보까지 같이 보여줍니다.
  
  

4️⃣ Replica 개수 조절

kubectl scale deployment dpy-nginx --replicas=3
kubectl get pods -o wide

• dpy-nginx Deployment를 Pod 3개로 확장하였습니다.

• get pods로 확인하면 3개의 동일한 Pod가 생긴 걸 볼 수 있습니다.
  

5️⃣ 단일 Pod에 Service 노출

kubectl expose pod nginx-pod --type=NodePort --name=pod-svc --port=80
kubectl get svc

• type=NodePort : 외부에서 접근 가능한 고정 포트를 만들어줍니다.

• kubectl get svc로 서비스 IP 및 포트 확인합니다.
  

6️⃣ 외부에서 접속 (curl)

curl localhost:30425

• 생성된 NodePort로 접속을 시도합니다.

7️⃣ Deployment에도 Service 노출

kubectl expose deployment dpy-nginx --type=NodePort --name=dpy-svc --port=80
kubectl get services

• Deployment 전체를 외부에 노출합니다.

• 여러 Pod 중 하나에게 라우팅해주는 로드 밸런싱 역할을 합니다.

8️⃣ 외부에서 접속 (curl)

curl localhost:30760

• 생성된 NodePort로 접속을 시도합니다.

💡 dpy-nginx Deployment에 연결된 3개의 Pod 중 하나로 자동으로 요청을 분산(로드 밸런싱) 합니다.

9️⃣ 서비스 삭제

kubectl delete service pod-svc dpy-svc

• 앞서 만든 pod-svc와 dpy-svc를 삭제합니다.

---

지금까지는 kubectl 명령어를 통해 직접 리소스를 생성하고 관리해봤습니다.

하지만 실무 환경이나 복잡한 서비스에서는 이런 방식으로 하나하나 입력하는 것이 비효율적이고, 변경 추적도 어렵습니다.

그래서 Kubernetes에서는 매니페스트 파일을 통해 리소스를 선언적(Declarative)으로 관리하는 방식을 더 많이 사용합니다.

---

매니페스트

오브젝트(Pod, Deployment, Service 등)에 대한 설정을 파일로 기록한 것입니다.

• YAML (Yet Another Markup Language 또는 YAML Ain't Markup Language) 형식으로 작성됩니다.

• 오브젝트가 어떤 상태로 존재해야 하는지(=의도한 상태, desired state)를 기술합니다. 이 설정 부분을 오브젝트 스펙(spec)이라고 부릅니다.

• 오브젝트를 생성, 수정, 삭제할 수 있으며 동일한 매니페스트를 반복 적용하거나 다른 매니페스트 파일을 통해 상태를 바꾸는 것도 가능합니다.

• 복잡한 리소스를 명령어로 일일이 입력하기보다, 파일로 관리하면 자동화와 유지보수에 훨씬 유리합니다.

매니페스트 적용 명령어

kubectl apply -f <매니페스트 파일>

🤔 kubectl create -f를 사용하지 않는 이유는 뭘까?

kubectl apply는 단순히 리소스를 생성하는 데 그치지 않고, 이미 존재하는 리소스를 업데이트하거나 변경된 내용만 반영하는 기능까지 포함하고 있기 때문입니다.

kubectl create는 오브젝트를 한 번만 생성하는 명령어로, 이미 동일한 리소스가 존재하면 에러가 발생합니다.

매니페스트 파일 예시

• deployment.yaml

apiVersion: app/v1
kind: Deployment

metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector: 
    matchLabels:
      app: nginx
  template:
    metadata:
    labels:
      app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        ports:
        - containerPort: 80

• service.yaml

apiVersion: v1
kind: Service

metadata:
  name: nginx-service
spec:
  type: NodePort
  selector: 
      app: nginx
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30000

---

로드밸런싱 실습

Flask 앱을 컨테이너로 구성하고 Kubernetes에 배포한 뒤, NodePort 서비스를 통해 외부에서 들어오는 요청을 여러 개의 파드에 자동 분산(로드밸런싱)하는 과정을 실습합니다.

🤔 로드밸런싱이란?

로드밸런싱이란 많은 요청이 들어올 때, 한 곳에 몰리지 않도록 여러 서버(Pod)로 번갈아가며 나눠주는 기술입니다.
출처: medium

---

🤔 왜 필요한 걸까?

1. 트래픽 분산
사용자가 많아질수록 한 서버가 감당하기 힘들기 때문에 나누게 됩니다.

2. 고가용성 (High Availability)
하나의 파드가 죽더라도 나머지가 살아서 응답이 가능하게 됩니다.

3. 스케일링 유연성
특정 기능(예: 결제)만 트래픽 많으면 그 파드만 늘리면 되는 장점이 있습니다.

1️⃣ Flask 애플리케이션 구성

• app.py

from flask import Flask
import socket

app = Flask(__name__)

hostname = socket.gethostname()
ipv4 = socket.gethostbyname(hostname)

message = f'<p>Hostname: {hostname}</p><p>IPv4 Address: {ipv4}</p>\n'

@app.route('/')
def root():
  return message

• requirements.txt

Flask

2️⃣ Nginx로 프록시 설정

• site.conf

server {
  listen 80;
  server_name localhost;
  access_log /var/log/nginx/access.log main;'
  location / {
    proxy_pass http://127.0.0.1:5000;
  }
}

• start.sh

service nginx start
/flaskapp/venv/bin/flask --app app run --host 0.0.0.0

3️⃣ Dockerfile 구성

• Dockerfile

FROM nginx:latest

RUN apt update
RUN apt install -y python3-full
RUN apt install -y procps

WORKDIR /flaskapp
RUN python3 -m venv /flaskapp/venv
COPY requirements.txt requirements.txt
RUN /flaskapp/venv/bin/pip install -r requirements.txt

COPY app.py app.py
COPY site.conf /etc/nginx/sites-available/flaskapp.conf
RUN ln -s /etc/nginx/sites-available/flaskapp.conf /etc/nginx/conf.d
RUN mv /etc/nginx/conf.d/default.conf /etc/nginx/conf.d/default.conf.bak

COPY start.sh start.sh
RUN chmod 777 start.sh

ENTRYPOINT ["/flaskapp/start.sh"]

• deployment.yaml

apiVersion: apps/v1
kind: Deployment

metadata:
  name: dpy-hname
  labels:
    app: hostname
spec:
  replicas: 3
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
        - name: hname
          image: 계정이름/hostname:latest
          ports:
            - containerPort: 80

• service.yaml

apiVersion: v1
kind: Service

metadata:
    name: svc-hname
spec:
    type: NodePort
    selector:
        app: hostname
    ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30000

🤔 왜 NodePort를 사용할까?

Flask 앱은 k8s Pod 내부에서 실행되기 때문에 클러스터 내부에서만 접근이 가능합니다.

그러므로 curl이나 외부 브라우저의 요청을 보내려면 내부로 트래픽을 받아주는 NodePort 타입의 Service를 사용해 노드의 특정 포트를 개방하고, 그 포트로 들어온 요청을 내부 Pod로 라우팅할 수 있도록 구성하는 것입니다.

4️⃣ DockerHub 업로드

• deployment.yaml 에서 작성한 image를 가져오기 위해서 DockerHub에 업로드합니다.

docker build -t hostname:latest .

docker tag hostname:latest 계정이름/hostname:latest
docker push 계정이름/hostname:latest

5️⃣ Kubernetes에 배포

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

kubectl get pods -o wide

6️⃣ curl로 테스트

• 여러 번 요청하면 다른 파드에서 응답하는 것을 알 수 있습니다.

curl localhost:30000
curl localhost:30000
curl localhost:30000
curl localhost:30000
curl localhost:30000

흐름 요약

[ 사용자 (curl or 브라우저) ]
           ↓
  http://localhost:30000
           ↓
[ Kubernetes NodePort 서비스 (30000) ]
           ↓
[ 여러 파드 중 하나 선택 (로드밸런싱) ]
           ↓
[ Nginx (80) → Flask (5000) ]
           ↓
[ HTML 응답: Hostname & IP 출력 ]

---

배포된 소프트웨어 업데이트와 복구 실습

쿠버네티스에서 수동으로 소프트웨어를 업데이트하고, 필요하면 되돌릴 수 있게 연습하는 실습입니다.

- kubectl rollout undo deployment <디플로이먼트 이름> 

- kubectl rollout undo deployment <디플로이먼트 이름> --to-revision=<리비전 번호> : 특정 시점으로 돌리는 거

• rollout.yaml

apiVersion: apps/v1
kind: Deployment

metadata:
  name: dpy-nginx
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.17.0
        ports:
        - containerPort: 80

• service.yaml

apiVersion: v1
kind: Service

metadata:
    name: svc-nginx
spec:
    type: NodePort
    selector:
      app: nginx
    ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30000

1️⃣ 초기 배포 (nginx:1.17.0)

kubectl apply -f rollout.yaml

• rollout.yaml 파일을 적용해서 Deployment 리소스를 생성합니다.

kubectl apply -f rollout.yaml --record

• --record 옵션을 주면, 명령 실행 이력이 revision에 남겨져 무엇을 했는지 추적할 수 있습니다.

kubectl rollout status deployment dpy-nginx

• 배포가 정상적으로 진행 중인지, 롤아웃 상태를 확인합니다.

kubectl rollout history deployment dpy-nginx

• 지금까지의 배포 이력을 조회합니다.

2️⃣ nginx 버전 다운그레이드 (1.16.0)

kubectl delete deployment dpy-nginx

• 배포를 삭제하고 초기화합니다.

# rollout.yaml 파일에서 nginx:1.16.0 으로 이미지 버전 수정
kubectl apply -f rollout.yaml

• nginx 버전 1.16.0으로 배포합니다.

3️⃣ 수동 업데이트 (버전 업그레이드)

kubectl set image deployment dpy-nginx nginx=nginx:1.17.0

• set image 명령으로 실시간으로 배포 중인 Deployment의 이미지를 업데이트합니다.

kubectl annotate deployment dpy-nginx kubernetes.io/change-cause="설명"

• 변경사항에 대해 설명을 주석(annotation)으로 추가합니다.

kubectl rollout history deployment dpy-nginx

• 다시 배포 이력을 확인하면, 방금 변경한 내용이 revision 2로 남아 있습니다.

4️⃣ 되돌리기

kubectl rollout undo deployment dpy-nginx

• 가장 이전 revision으로 되돌리는 기본 rollback 명령어입니다.

kubectl rollout undo deployment dpy-nginx --to-revision=<번호>

• 특정 revision 번호(kubectl rollout history)로 정확히 지정해서 되돌릴 수도 있습니다.

5️⃣ 버전 확인하기

curl -I --silent localhost:30000 | grep Server

• -I : 헤더만 조회합니다. (HTTP 응답 본문은 제외)

• --silent : 진행 상태 출력 숨깁니다.

• grep Server : Server: 가 포함된 줄만 출력합니다.

---

자동 스케일링 실습

쿠버네티스 Horizontal Pod Autoscaler (HPA)를 사용해서 CPU 사용률에 따라 자동으로 Pod 수를 늘렸다 줄이는 동적 스케일링을 실습합니다.

🤔 HPA(Horizontal Pod Autoscaler)란?

클러스터 내 부하량에 따라 Deployment의 Pod 수를 자동으로 조절하는 Kubernetes의 기능입니다. 일반적으로 CPU 및 메모리 사용량을 기준으로 판단하며, metrics-server로부터 리소스 사용량 정보를 전달받아 동일한 기능을 수행하는 Pod의 수를 동적으로 조절합니다.

실습 파일

• metrics.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
rules:
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
rules:
- apiGroups:
  - ""
  resources:
  - nodes/metrics
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --kubelet-insecure-tls
        - --secure-port=4443
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        image: registry.k8s.io/metrics-server/metrics-server:v0.6.4
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /livez
            port: https
            scheme: HTTPS
          periodSeconds: 10
        name: metrics-server
        ports:
        - containerPort: 4443
          name: https
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readyz
            port: https
            scheme: HTTPS
          initialDelaySeconds: 20
          periodSeconds: 10
        resources:
          requests:
            cpu: 100m
            memory: 200Mi
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
        volumeMounts:
        - mountPath: /tmp
          name: tmp-dir
      nodeSelector:
        kubernetes.io/os: linux
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      volumes:
      - emptyDir: {}
        name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  labels:
    k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: metrics-server
    namespace: kube-system
  version: v1beta1
  versionPriority: 100

• php-apache

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
      - name: php-apache
        image: registry.k8s.io/hpa-example
        ports:
        - containerPort: 80
        resources:
          limits:
            cpu: 500m
          requests:
            cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
  - port: 80
  selector:
    run: php-apache

1️⃣ Metrics 서버 설치

 kubectl apply -f metrics.yaml

• HPA는 CPU 사용률 등의 메트릭 정보를 기반으로 스케일링하는 기능이기 때문에 metrics-server가 없으면 HPA CPU 사용률을 읽을 수 없기 때문에 설치를 해줍니다.

kubectl get pods --all-namespaces

• 간단한 웹서버 (php-apache)를 1개의 Pod로 배포합니다.
  

2️⃣ 웹 애플리케이션 배포 (php-apache)

kubectl apply -f php-apache.yaml

• 간단한 웹 서버 응용을 배포(포드 1개)하고 ClusterIP로 클러스터 내부에만 노출

3️⃣ Horizontal Pod Autoscaler 설정

kubectl autoscale deployment php-apache --cpu-percent=50 --min=1 --max=10

• CPU 사용률이 50%를 넘으면 Pod를 자동으로 늘리고,
  낮아지면 줄이는 설정입니다.

• Pod 수는 최소 1개, 최대 10개로 제한됩니다.

4️⃣ 부하 생성 (load generator)

kubectl run -it load-gen --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"

• busybox 컨테이너를 실행해서 php-apache 서비스에 지속적으로 HTTP 요청을 보내는 역할입니다.

• 0.01초 간격으로 계속 요청해서 CPU 사용량을 인위적으로 올리는 목적입니다.

5️⃣ HPA 상태 확인

kubectl get hpa

• 현재 HPA가 감지한 CPU 사용률과 Pod 개수 조절 상태를 확인할 수 있습니다.

---

볼륨 실습

Kubernetes 클러스터에서 PersistentVolume(PV)와 PersistentVolumeClaim(PVC)을 사용해
로컬 저장소를 마운트하고, nginx 웹 서버를 통해 HTML 파일을 서비스하는 과정을 실습합니다.

🤔 볼륨이 중요한 이유는 뭘까?

컨테이너는 재시작하면 내부에 있던 파일이 날아가기 때문에 볼륨은 데이터를 영구 저장하는 방식으로 사용됩니다.

PV (PersistentVolume)

Pod가 사용할 수 있도록 쿠버네티스 클러스터에 미리 등록된 저장 공간입니다.

• Pod는 이 저장소에 직접 접근하지 않고 PVC(PersistentVolumeClaim)를 통해 간접적으로 연결합니다.
• 변화하는 데이터를 기록, 저장하기 위해서 반드시 필요합니다.

PVC (PersistentVolumeClaim)

Pod이 사용할 스토리지를 요청하는 객체입니다.

• pod : node = pvc : pv

• 원하는 저장 용량과 접근 방식을 지정할 수 있습니다.

실습 파일

• pv-volume.yaml

apiVersion: v1
kind: PersistentVolume

metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/c/Users/MSI/Downloads/2-05 (1)/2-05/pv/data"

• pv-claim.yaml

apiVersion: v1
kind: PersistentVolumeClaim

metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

• deployment.yaml

apiVersion: apps/v1
kind: Deployment

metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      volumes:
        - name: task-pv-storage
          persistentVolumeClaim:
            claimName: task-pv-claim
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
          volumeMounts:
            - mountPath: "/run/desktop/mnt/host/c/Users/MSI/pv/data"
---
apiVersion: v1
kind: Service

metadata:
  name: nginx
  labels:
    run: nginx
spec:
  type: NodePort
  selector:
    run: nginx
  ports:
    - port: 80
      nodePort: 30000

1️⃣ 로컬 디렉토리 준비

mkdir data
cd data
cat > index.html
<p>Hello from k8s Storage!</p>

• 로컬 디스크에 data 디렉토리를 만들고, nginx가 서비스할 HTML 파일(index.html)을 직접 생성합니다.

2️⃣ PersistentVolume 생성

kubectl apply -f pv-volume.yaml
kubectl get pv

• pv-volume.yaml을 이용해 로컬 디스크를 Kubernetes의 PV 리소스로 등록합니다.

3️⃣ PersistentVolumeClaim 생성

kubectl apply -f pv-claim.yaml
kubectl get pvc

• PVC는 Pod가 스토리지를 사용하고자 할 때 내는 요청서입니다.

• get pvc로 바인딩 상태를 확인해서 PVC가 PV와 잘 연결되었는지 체크합니다.

  • STATUS가 Bound이면 연결이 된 것입니다.

4️⃣ Deployment & Service 생성

kubectl apply -f deployment.yaml
kubectl get svc

• nginx Deployment를 만들고, 방금 만든 PVC를 nginx Pod에 마운트합니다. 동시에 NodePort 타입의 Service도 만들어서 외부(로컬)에서 접속 가능하게 합니다.

5️⃣ 웹 접속 테스트

curl localhost:30000

• curl로 nginx 서비스에 접속합니다.

6️⃣ Pod 내부 접근 + 파일 생성 실습

kubectl get pods
kubectl exec -it <이름> -- /bin/bash
cd /usr/share/nginx/html
cat > tmp.txt
This file is being created inside a container.
exit

• tmp.txt 파일을 만들어서, 정말로 호스트 디렉토리와 공유되고 있는지 확인하는 과정입니다.

• 나와서 cat tmp.txt 로 확인하거나 로컬 폴더에 파일이 보이면 성공한 것입니다.

---

✏️ 회고

k8s 안에서도 개념이 많은 만큼, 실제 실습과 함께 병행해서 익히면서 이해를 해야하는데 아직은 어려운 것 같다.