[CKA 준비] - Core Concepts - 2

Yaml in Kubernets

apiVersion:
kind:
metadata:
spec

Kind	Version
Pod	v1
Service	v1
ReplicSet	apps/v1
Deployment	apps/v1

Pod yaml 구조

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
    - name: nginx-container
      image: nginx

 

Pod 관련 명령어

# Pod 목록 보기
kubectl get pods
kubectl get pods -o wide

# Pod 상세 보기
kubectl describe pod <pod-name>

# Pod YAML 초안 만들기
kubectl run <pod-name> --image=<image-name> --dry-run=client -o yaml > filename.yaml

# YAML로 Pod 생성
kubectl create -f filename.yaml

# YAML 수정 후 반영
vim filename.yaml
kubectl apply -f filename.yaml

# Pod 삭제
kubectl delete pod <pod-name>

# 로그 확인
kubectl logs <pod-name>

# Pod 내부 접속
kubectl exec -it <pod-name> -- /bin/sh

 

Replication Controller / ReplicaSet 

1. 컨트롤러란?

컨트롤러는 Kubernetes에서 객체 상태를 계속 감시하고, 원하는 상태가 유지되도록 조치하는 구성요소이다.

즉, Kubernetes는 그냥 한 번 생성하고 끝나는 것이 아니라,

계속 상태를 확인하면서 부족하거나 문제가 생기면 자동으로 맞춰주는 방식으로 동작한다.

 

2. 왜 여러 Pod가 필요한가?

예를 들어 애플리케이션이 Pod 1개에서만 실행 중이라고 가정

이 경우 그 Pod가 죽으면:

• 애플리케이션이 중단되고
• 사용자는 접속할 수 없게 됨

그래서 같은 애플리케이션 Pod를 여러 개 유지하면:

• 하나가 실패해도
• 나머지 Pod가 계속 서비스할 수 있음

 

3. Replication Controller / ReplicaSet 의 역할

“지정한 개수만큼 Pod가 항상 실행되도록 유지한다.”

예를 들어 replicas를 3으로 설정하면:

• 정상일 때는 Pod 3개 유지
• 1개가 죽으면 새로 만들어서 다시 3개 유지

즉, Pod 개수를 자동으로 맞춰주는 관리자

 

Pod 가 1개여도 의미가 있다. 

Pod 하나가 죽으면 새 Pod를 자동으로 다시 만들어주기 때문 -> 단일 Pod의 자동 복구 목적으로도 사용 가능

 

4. 차이점

Replication Controller

• 예전 방식
• 오래된 기술

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
  labels:
    app: myapp
    type: frontend
spec:
  replicas: 3
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx

selector를 생략 가능

• replicas : 몇 개의 Pod를 유지할 것인가?
• template: Replica 가 새 Pod를 만들어야 할 때 사용할 Pod 설계도
  • Pod 템플릿을 이용해 나중에 Pod가 죽으면 새 Pod를 생성함

 

ReplicaSet

• 더 최신 방식
• 현재 권장 방식

즉, 지금은 ReplicaSet을 사용하는 것이 일반적

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-rs
  labels:
    app: myapp
    type: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx

selector 가 필수

• selector: 어떤 Pod 들을 내가 관리 대상으로 볼 것인가?
  • label = Pod에 붙인 표식 (옷에 있는 라벨이랑 똑같음)
  • selector = 그 표식을 보고 대상을 고르는 조건
  • Pod에 라벨링을 하고, selector 에서 해당 라벨을 보고 내가 원하는 것만 다시 재생성하는 구조

ReplicaSet = apps/v1 + selector 필수

---

Deployment

실제 운영 환경에서는 애플리케이션을 Pod 1개만 띄워서 끝내는 경우가 거의 없음.

예를 들어 웹 서버를 운영한다고 하면:
- 인스턴스가 여러 개 있어야 함
- 새 버전이 나오면 서비스 중단 없이 업데이트하고 싶음
- 업데이트하다가 문제 생기면 이전 버전으로 되돌리고 싶음
- 여러 변경 사항을 한 번에 반영하고 싶음

-> 이런 운영상의 요구를 해결하는 객체가 Deployment

기능

1. 여러 인스턴스 운영

웹 서버를 실제 서비스에 배포할 때는 보통 여러 개의 인스턴스를 실행해야 함.
그래야 부하 분산도 되고, 일부 인스턴스에 문제가 생겨도 서비스가 계속 가능함.

 

2) Rolling Update

새 버전 이미지가 나오면 기존 인스턴스를 새 버전으로 바꿔야 함.
그런데 모든 인스턴스를 한 번에 바꾸면 서비스 영향이 클 수 있음.

그래서 보통은:

• 하나 업데이트
• 정상 확인
• 다음 것 업데이트

이런 식으로 순차적으로 교체함

 

3) Rollback

업데이트 후 문제가 생길 수 있음.
이 경우 최근 변경을 취소하고 이전 상태로 되돌릴 수 있어야 함.

 

4) Pause / Resume

운영 중에는 한 번에 여러 가지를 바꾸고 싶을 수 있음.

• 이미지 버전 변경
• replicas 변경
• 리소스 설정 변경

이걸 하나씩 즉시 반영하는 대신,

• 잠시 배포를 멈추고
• 필요한 변경을 모아서 적용한 다음
• 다시 배포를 진행

하는 방식이 필요함.

 

Pod, ReplicaSet, Deployment 관계

Pod	ReplicaSet	Deployment
애플리케이션 하나의 실행 단위 컨테이너는 Pod 안에서 실행	같은 Pod 를 여러 개 유지하는 역할을 함 원하는 개수의 Pod 가 계속 유지하도록 관리	ReplicaSet 보다 한 단계 위에 있는 상위 객체 ReplciaSet을 관리하면서 운영에 필요한 기능까지 제공함

                Deployment
                    │
                    │ (관리 / 업데이트 전략)
                    ▼
               ReplicaSet
                    │
                    │ (Pod 개수 유지)
                    ▼
        ┌───────┬───────┬───────┬───────┐
        │  Pod  │  Pod  │  Pod  │  Pod  │
        └───────┴───────┴───────┴───────┘

Deployment → ReplicaSet → Pod

Deployment 가 하는 일

• 여러 Pod를 유지하게 함
• 새 버전으로 무중단 업데이트 가능하게 함
• 문제 생기면 롤백 가능하게 함
• 변경을 pause/resume 하며 제어 가능하게 함

즉 ReplicaSet이 “Pod 개수 유지”에 초점이 있다면,
Deployment는 그 위에서 배포 전략까지 관리하는 객체

 

Deployment Yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: nginx
          image: nginx

ReplicaSet YAML과 거의 같고,
kind만 Deployment로 바꾸면 됨.

 

Deployment 생성 후

Deployment가 ReplicaSet을 만들고, ReplicaSet이 Pod를 만드는 구조

 

1. Deployment 생성
2. ReplicaSet 자동 생성
   1. Deployment가 ReplicaSet을 자동으로 만듦.
   2. 확인 명령: kubectl get rs
3. Pod 생성
   1. ReplicaSet이 실제 Pod들을 생성함.
   2. 확인 명령: kubectl get pods

하나의 Deployment를 만들었더니
그 아래에 ReplicaSet이 생기고, 그 아래에 Pod들이 생긴다.
Deployment는 ReplcaSet보다 상위객체이므로 
ReplicaSet을 직접 쓰기보다는 운영에서는 Deployment을 더 많이 사용함

 

---

!! 실습 명령어 정리

NGINX Pod 생성

kubectl run nginx --image=nginx

 

 

 

Pod YAML Manifest 생성 (실제 생성하지 않음)

kubectl run nginx --image=nginx --dry-run=client -o yaml

 

옵션 설명

• -o yaml → YAML 형식으로 출력
• --dry-run=client → 실제로 리소스를 생성하지 않음

 

Deployment 생성

kubectl create deployment --image=nginx nginx

 

 

Deployment YAML 파일 생성 (실제 생성하지 않음)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

 

 

Deployment YAML 생성 후 파일로 저장

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

 

 

YAML 파일 수정 후 Deployment 생성

예를 들어 replicas 수를 추가로 수정한 뒤

kubectl create -f nginx-deployment.yaml

 

 

Kubernetes 1.19 이상에서 replicas 옵션 사용

Kubernetes 1.19 이상에서는 --replicas 옵션을 직접 사용할 수 있음.

예: replicas 4개 Deployment 생성 YAML 만들기

kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml