2026. 6. 13. 12:16ㆍKubernetes
Ⅰ. Controller (컨트롤러)
| Controller (컨트롤러) |
구분 | 설명 | |
| 개념 | Controller (컨트롤러)는 Kubernetes 클러스터 내 리소스의 현재 상태를 지속적으로 모니터링 | ||
| 사용자가 정의한 원하는 상태 (Desired State)와 일치하도록 자동으로 조정 및 관리하는 핵심 구성 요소 |
|||
| 기본 역할 | 클러스터에서 Pod를 생성, 복제, 삭제, 교체하는 등의 제어 업무 수행 | ||
| 애플리케이션 가용성 유지 및 상태 복구 담당 | |||
| 변경 사항을 감지하여 자동으로 조치 (ex. Pod 재시작, 재배포 등) | |||
| 동작 원리 | 사용자가 YAML 파일로 리소스의 원하는 상태 정의 -> Controller는 etcd에 저장된 현재 상태 (Current State)와 비교 -> 두 상태가 다를 경우, Controller가 자동으로 조정하여 일치시킴 (Reconciliation Loop) |
||
| 특징 | Kuberenets의 자동화 핵심 구성 요소 | ||
| Pod뿐 아니라 Service, Node, Endpoint 등 다양한 리소스에 적용 | |||
| 클러스터 장애 복구 및 무중단 운영의 기반 역할 | |||
| 주요 컨트롤러 종류 |
종류 | 설명 | |
| ReplicaSet Controller | 지정된 수의 Pod가 항상 실행되도록 관리 | ||
| Deployment Controller | Pod 업데이트 수행 | ||
| 롤링 배포 수행 | |||
| 롤백 수행 | |||
| DaemonSet Controller | 모든 노드에서 하나씩 Pod 실행 | ||
| StatefulSet Controller | 순서와 이름을 보장하는 상태 유지형 Pod 관리 | ||
| Job / CronJob Controller | 일회성 또는 주기적 작업 (Pod) 실행 관리 | ||
| 예시 명령어 | 명령어 | 설명 | |
| ex) kubectl get deploy | Deployment Controller 확인 | ||
| ex) kubectl get rs | ReplicaSet 상태 확인 | ||
| ex) kubectl describe daemonset [이름] | DaemonSet 상세 조회 | ||
Ⅰ - Ⅰ. 일반적으로 상태를 유지하지 않아도 되는 Pod를 관리하는 경우 (Stateless)
| 구분 | 설명 | 특징 |
| Replication Controller | Kubernetes 초기부터 존재한 기본 컨트롤러 | 실행할 Pod의 개수 지정 가능 |
| 지정된 개수만큼 Pod 생성 및 유지 | ||
| 지정한 수의 Pod가 항상 실행되도록 관리 | 최신 버전에서는 ReplicaSet으로 대체 | |
| ReplicaSet (RS) | Replication Controller와 유사하지만 Label Selector 기반 집합 연산 지원 |
Selector 연산 (exists, DoesNot Exist, in, notin) 사용 가능 |
| 조건에 따라 필요한 레이블 선택하여 Pod 관리 | ||
| Deployment 내부 구성 요소로 주로 사용 | ||
| Deployment | ReplicaSet을 이용해 Pod를 자동 생성 및 유지 | Rolling Update 및 Rollback 기능 제공 |
| Pod의 컨테이너 이미지 버전 업데이트 가능 | ||
| 버전 관리 기능 제공 | 가장 일반적인 애플리케이션 배포 단위 |
Ⅰ - Ⅱ. 클러스터 전체에 배포가 필요한 Pod (DaemonSet)
| DaemonSet | 구분 | 설명 |
| 개념 | 클러스터 내 모든 노드 (또는 특정 라벨이 지정된 노드)에 1개의 Pod를 배포하고 유지하는 컨트롤러 | |
| 특징 | 노드가 추가될 경우, 자동으로 해당 노드에도 Pod 생성 | |
| 노드가 삭제될 경우, 관련 Pod도 자동 제거 | ||
| 로그 수집, 모니터링, 보안 에이전트 네트워크 플러그인 등 노드 단위 서비스 실행에 활용 | ||
| 일반 Deployment와 달리 Pod 개수가 노드 수에 따라 자동 조정 |
Ⅰ - Ⅲ. 상태 관리가 필요한 Pod (Stateful)
| StatefulSet | 구분 | 설명 |
| 개념 | 순서와 이름이 중요한 상태 유지형 Pod를 관리하는 컨트롤러 | |
| 특징 | 각 Pod에 고유한 이름 (식별자) 부여 (ex. web-0, web-1) | |
| Pod가 재시작되거나 재스케줄되어도 이름과 볼륨 (데이터)이 유지됨 | ||
| 각 Pod는 PersistentVolumeClaim을 통해 고유 스토리지 사용 | ||
| Pod의 생성 / 종료 순서가 보장되어 클러스터 내 순차적 배포 및 업데이트 가능 | ||
| DB, Kafka, Redis 등 상태 기반 애플리케이션 운영 필수 |
Ⅰ - Ⅳ. 배치성 작업을 진행하는 Pod
| Job | 항목 | 설명 |
| 개념 | 한 번만 실행해야 하는 단일 배치성 작업을 관리하는 컨트롤러 | |
| 특징 | 지정된 작업이 성공적으로 완료될 때까지 Pod 실행 유지 | |
| Pod가 실패하면 재시작 가능 (retry) | ||
| 완료 후 Pod는 자동 삭제되지 않음 (기본 정책에 따라 유지) | ||
| 백업, 로그 압축, 데이터 마이그레이션 등 일회성 작업에 적합 | ||
| CronJob | 개념 | Job을 주기적으로 실행하도록 스케줄링하는 컨트롤러 |
| 특징 | Linux의 cron 문법과 동일한 스케줄링 방식 사용 | |
| 지정된 시간과 주기에 따라 Job 자동 생성 | ||
| 지속적이고 반복적인 배치 작업 자동화에 적합 | ||
| ex) 매일 0시마다 백업 작업 실행 |

kubectl get ds –A 명령을 통해 클러스터 전체에서 실행 중인 모든 DaemonSet들의 상태를 한 번에 확인

kubectl describe node master 명령을 통해 Kubernetes 클러스터 안에서 master 노드의 상세 정보 확인
● Controller 간 차이점 비교
| 구분 | Deployment / ReplicaSet | DaemonSet | StatefuSet | Job / CronJob |
| 관리 대상 | 동일한 기능을 수행하는 여러 개의 Pod 복제본 |
각 노드 (Node)마다 1개씩 Pod 배포 |
데이터나 상태 (State)를 가진 Pod |
작업 (Job) 실행용 Pod |
| Pod 이름 규칙 | 무작위로 생성 (ex. nginx-abc12) |
노드별 1개씩 자동 생성 |
순서, 이름 고정 (ex. db-0, db-1) |
실행마다 새 Pod 생성 (ex. job-xyz1) |
| Pod 개수 제어 | 사용자가 지정한 replicas 값으로 제어 |
노드 수에 따라 자동 조정 |
replicas 지정 가능 | Job - 1회성 |
| 순차 생성 및 종료 | CronJob - 스케줄 반복 | |||
| 상태 유지 여부 | 상태 없음 (Stateless) |
상태 없음 | 상태 유지 (PersistentVolume) |
일시적 실행 후 종료 |
| 주요 역할 | 웹 서버, API 서버 등 일반 앱 실행 |
로그 수집기, 모니터링, 네트워크 플러그인 등 노드 에이전트 |
DB, Kafka, Redis 등 상태 기반 앱 |
백업, 데이터 처리, 정기작업 등 |
| Pod 교체 시 동작 | 자동 재생성 (롤링 업데이트 지원) |
노드 삭제 시 Pod 자동 삭제 |
순서, 스토리지 보존 상태로 재생성 |
완료 후 종료 (성공 시 재시작 안 함) |
| PersistentVolume 사용 |
선택적 | 일반적으로 사용 X | 필수 (각 Pod별 고유 PVC) | 필요 시 임시로 사용 가능 |
| 사용 목적 요약 | 무상태 앱의 배포 및 스케일링 |
모든 노드에서 공통 Pod 유지 |
상태 기반 앱의 안정적 운영 |
단기 또는 주기적 작업 실행 |
Ⅱ. Replication Controller (레플리케이션 컨트롤러)
| Replication Controller |
구분 | 설명 |
| 역할 | 지정한 개수의 Pod가 항상 실행되도록 보장 | |
| Pod 부족 시 | 요구한 Pod의 개수가 부족할 경우, 템플릿 이용해 새로운 Pod 자동 생성 | |
| Pod 초과 시 | 요구한 Pod의 개수보다 많을 경우, 가장 최근에 생성된 Pod 자동 삭제 | |
| 자동 복구 기능 | Pod가 삭제, 실패, 종료되어도 지정된 개수 유지 (새 Pod 자동 추가) | |
| 관리 방식 | 직접 생성된 Pod와 달리, Replication Controller가 Pod를 지속적으로 감시하고 상태 자동 조정 |
|
| 주요 목적 | 애플리케이션의 가용성과 안정성 유지 | |
| 항상 동일한 수의 Pod가 실행되도록 관리 |
Ⅱ - Ⅰ. Replication Controller yaml 파일 내용
| 구분 | 설명 |
| Pod 개수 보장 | 지정한 개수 (replicas)만큼 Pod가 실행되도록 보장 |
| Selector 설정 | selector 필드의 레이블 (Label)을 기반으로 관리할 Pod 식별 |
| Pod 템플릿 | Pod 생성 시 사용할 이미지, 포트, 환경 변수, 리소스 설정 정의 |
| 자동 복구 로직 | 지정된 개수보다 Pod가 적을 경우, 템플릿 이용하여 자동 생성 |
| 자동 조정 로직 | 지정된 개수보다 Pod가 많을 경우, 초과된 Pod 자동 삭제 |

cd kube/07/ 명령을 통해 홈 디렉터리에서 /kube/07 디렉터리로 이동
ls 명령을 통해 해당 디렉터리에 있는 목록 확인
cd rc 명령을 통해 /kube/07 디렉터리에서 /kube/07/rc 디렉터리로 이동
kubectl api-resources 명령을 통해 Kubernetes에서 사용할 수 있는 모든 API 리소스 목록 확인

vi nginx-rc.yml 명령을 통해 vi 편집기 사용하여 nginx-rc.yml 파일 생성 및 내용 입력
cat nginx-rc.yml 명령을 통해 nginx-rc.yml 파일의 내용 확인
[ nginx-rc.yml 파일의 내용 ]
apiVersion: v1 명령을 통해 API 버전을 v1로 지정
kind: ReplicationController 명령을 통해 리소스 종류를 RC (Replication Controller)로 지정
-> RC (Replication Controller)는 특정 수의 Pod가 항상 실행되도록 보장하는 역할 수행
metadata: name: nginx-rc 명령을 통해 RC 리소스 이름을 nginx-rc로 지정
spec.replicas: 3 명령을 통해 Pod를 3개 복제하도록 지정
spec.selector: app: webui 명령을 통해 app=webui 라벨을 가진 Pod를 관리하도록 지정
template.metadata.labels: app: webui 명령을 통해 RC가 새로 생성할 Pod에 app=webui 라벨 부여
template.spec.containers.name: nginx-container 명령을 통해 nginx-container로 컨테이너 이름 지정
template.spec.containers.image: nginx: 1.14 명령을 통해 Nginx 1.14 버전의 이미지 사용

# nginx-rc 리소스 생성 (Replication Controller)
kubectl create –f nginx-rc.yml 명령을 통해 nginx-rc 리소스 생성
kubectl describe pod 명령을 통해 클러스터에 존재하는 Pod 중 하나의 상세 상태 확인

kubectl get pods –o wide 명령을 통해 현재 실행 중인 Pod의 상세 정보를 확장된 형식으로 확인

kubectl get rc,pod –o wide 명령을 통해 RC (Replication Controller)와 관리하는 Pod 한 번에 확인

kubectl describe rc nginx-rc 명령을 통해 nginx-rc의 상세 상태 확인

kubectl get pod —show-labels 명령을 통해 현재 클러스터에 존재하는 모든 Pod를 라벨 정보와 함께 확인

# redis 리소스 생성 및 실행 (Pod)
kubectl run redis --image=redis 명령을 통해 Redis 이미지 사용하여 redis 리소스 생성 및 실행
--labels=app=webui 옵션을 통해 Pod에 붙일 라벨 설정
--dry-run=client 옵션을 통해 실제로 Pod를 생성하지 않고, 결과 YAML만 출력
-o yaml 옵션을 통해 출력 형식을 yaml로 지정
> redis.yml 옵션을 통해 출력 결과를 redis.yml 파일로 저장
vi redis.yml 명령을 통해 vi 편집기 사용하여 redis.yml 파일에 내용 입력
cat redis.yml 명령을 통해 redis,yml 파일의 내용 확인
[ redis.yml 파일의 내용 ]
apiVersion: v1 명령을 통해 API 버전을 v1로 지정
kind: Pod 명령을 통해 생성할 리소스의 종료를 Pod로 지정
metadata.labels.app: webui 명령을 통해 새로 생성할 Pod에 app=webui 라벨 부여
metadata.name: redis 명령을 통해 Pod의 이름 redis로 지정
spec.containers.image: redis 명령을 통해 실행할 이미지 Redis로 지정
spec.containers.name: redis 명령을 통해 컨테이너의 이름을 redis로 지정

# nginx-rc 리소스 복제 개수 조정
kubectl scale rc nginx-rc —replicas=2 명령을 통해 리소스의 복제 개수를 2개로 조정
kubectl get pod —show-labels 명령을 통해 복제 개수가 잘 조정되었는지 확인

# nginx-rc 리소스 이미지 버전 수정
kubectl edit rc nginx-rc 명령을 통해 Nginx 이미지를 1.15 버전으로 수정
kubectl describe rc nginx-rc 명령을 통해 Nginx 이미지의 버전이 잘 수정되었는지 확인

kubectl describe pod nginx-rc | grep Image: 명령을 통해 Pod들이 사용하는 이미지 버전이 아직 1.14라는 것 확인
kubectl get pod —show-labels 명령을 통해 nginx-rc가 관리 중인 2개의 Pod 목록 확인
# nginx-rc 리소스 삭제
kubectl delete pod nginx-rc-b57cj 명령을 통해 하나의 Pod 직접 삭제
kubectl get pod —show-labels 명령을 통해 RC의 자동 복구 기능 덕분에 새로운 Pod가 자동으로 생성된 것 확인
kubectl describe pod nginx-rc | grep Image: 명령을 통해 새 Pod의 이미지의 버전이 1.15인 것 확인
# Pod 리소스 삭제
kubectl delete pod —all 명령을 통해 기존에 생성된 Pod 모두 삭제
kubectl get pod —show-labels 명령을 통해 RC의 자동 복구 기능 덕분에 새로운 Pod가 자동으로 생성된 것 확인
kubectl describe pod nginx-rc | grep Image: 명령을 통해 모든 새 Pod의 이미지의 버전이 1.15인 것 확인

# nginx-rc 리소스 이미지 버전 수정
kubectl edit rc nginx-rc 명령을 통해 nginx-rc의 이미지 버전 1.14로 수정
kubectl describe rc 명령을 통해 이미지 버전이 잘 조정되었는지 확인

kubectl describe pod nginx-rc | grep Image: 명령을 통해 nginx 이미지의 버전 정보 확인
# Pod 리소스 삭제
kubectl delete pod —all 명령을 통해 기존에 생성된 Pod 모두 삭제
kubectl get pod —show-labels 명령을 통해 RC의 자동 복구 기능 덕분에 새로운 Pod가 자동으로 생성된 것 확인
kubectl describe pod nginx-rc | grep Image: 명령을 통해 모든 새 Pod의 이미지의 버전이 1.14인 것 확인

kubectl get rc,pod 명령을 통해 RC와 RC가 관리하는 Pod들 한 번에 확인

# nginx-rc.yml 파일과 nginx-rc 리소스 삭제
kubectl delete –f nginx-rc.yml 명령을 통해 nginx-rc.yml 파일에 정의된 리소스 삭제
kubectl get rc,pod 명령을 통해 잘 삭제되었는지 확인
Ⅲ. ReplicaSet (레플리카셋)
| ReplicaSet |
구분 | 설명 | |
| 개념 | Replication Controller에 조건부 Selector 기능이 추가된 컨트롤러 | ||
| 역할 | Pod의 개수를 일정하게 유지 | ||
| 지정된 조건 (레이블)에 맞는 Pod만 제어 | |||
| Selector 연산자 |
'exists', 'DoesNotExist', 'in', 'notin' 등 다양한 연산자 제공 | ||
종류 |
exist or exists | ||
| DoesNotExist or DoesNotExists | |||
| in | |||
| notin | |||
| 특징 |
단순한 레이블 매칭 외에도 세밀한 조건식 지정 가능 | ||
| Deployment의 하위 리소스로 자동 관리 | |||
| 단독으로 사용 가능 | |||
| 일반적으로 Deployment 통해 생성 | |||
Ⅲ - Ⅰ. 연산자 종류
연산자 |
연산자 | 설명 |
| Exist or Exists | Label 키가 존재하는지 검색 | |
| 값은 상관없음 | ||
| DoesNotExist or DoesNotExists | Label 키가 존재하지 않는지 검색 | |
| 값은 상관없음 | ||
| In | Label 키의 값이 지정한 값과 일치하는지 검색 | |
| Notin | Label 키의 값이 지정한 값과 일치하지 않는지 검색 |
Ⅲ - Ⅱ. 예시
| 연산자 예시 | 설명 |
| {key : version, operator : Exists} | Label에 'version'이라는 키가 존재하는 경우 |
| {key : version, operator : DoesNotExists} | Label에 'version'이라는 키가 존재하지 않는 경우 |
| {key : version, operator : In, value : ["2.1"}} | Label에 'version'이라는 키가 존재하고 value가 '2.1'인 경우 |
| {key : version, operator : In, value : ["2.1", "2.2"]} | Label에 'version'이라는 키가 존재하고 value가 '2.1'이거나 '2.2'인 경우 |
| {key : version, operator : Notin, value : ["2.1"]} | Label에 'version'이라는 키가 존재하고 value가 '2.1'이 아닌 경우 |

cd ../rs 명령을 통해 rc 디렉터리에서 rs 디렉터리로 이동
vi nginx-rs.yml 명령을 통해 vi 편집기 사용하여 nginx-rs,yml 파일을 생성하고, 파일 내용 입력
cat nginx-rs.yml 명령을 통해 nginx-rs.yml 파일의 내용 확인
[ nginx-rs.yml 파일의 내용 ]
apiVersion: apps/v1 명령을 통해 API apps/v1 버전 사용하도록 설정
kind: ReplicaSet 명령을 통해 리소스의 종류를 RS로 설정
metadata.name: nginx-rs 명령을 통해 리소스 이름을 nginx-rs로 지정
spec.rplicas: 3 명령을 통해 생성 및 유지할 Pod의 개수를 3으로 지정
spec.selector.marchLabels.app: webui 명령을 통해 app=webui 라벨을 가진 Pod만 RS가 관리
template.metadata.name: nginx-pod 명령을 통해 Pod의 이름을 nginx-pod로 설정
template.metadata.labels.app: webui 명령을 통해 app=webui 라벨 설정
spec.containers.name: nginx-container 명령을 통해 컨테이너 이름을 nginx-container로 지정
spec.containers.image: nginx:1.14 명령을 통해 사용할 Docker 이미지를 Nginx:1.14로 지정

# nginx-rs 리소스 생성 (ReplicaSet)
kubectl create –f nginx-rs.yml 명령을 통해 nginx-rs.yml 파일을 기반으로 nginx-rs 리소스 생성
kubectl get rs,pod –o wide 명령을 통해 RS와 Pod의 상태를 동시에 상세하게 확인
kubectl get pod —show-labels 명령을 통해 Pod들의 라벨 확인
kubectl describe rs nginx-rs 명령을 통해 RS의 세부 정보를 자세히 확인

kubectl describe pod nginx-rs-65kvn 명령을 통해 nginx-rs-65kvn의 상세 정보 확인

# nginx-rs 리소스 삭제
kubectl delete pod nginx-rs-65kvn 명령을 통해 nginx-rs-65kvn 수동 삭제
kubectl get pod —show-labels 명령을 통해 RS 특성 덕분에 삭제된 하나의 Pod를 즉시 재생성된 것 확인

# nginx-rs replicas 수 조정
kubectl edit rs nginx-rs 명령을 통해 replicas 수를 2로 조정
kubectl get pod —show-labels 명령을 통해 replicas 수가 잘 조정되었는지 확인
# nginx-rs replicas 수 조정
kubectl scale rs nginx-rs —replicas 4 명령을 통해 replicas 수를 4로 조정
kubectl get pod —show-labels 명령을 통해 replicas 수가 잘 조정되었는지 확인

kubectl get pod —show-labels 명령을 통해 현재 Pod의 상태 확인
# nginx-rc 리소스 생성 (Replication Controller)
kubectl create –f ../rc/nginx-rc.yml 명령을 통해 rc 디렉터리 안의 nginx-rc.yml 파일 이용해 nginx-rc 리소스 생성
kubectl get rc,pod —show-labels 명령을 통해 RC와 Pod 한 번에 확인
# nginx-rc 리소스와 그와 관련된 것 삭제
kubectl delete rc nginx-rc 명령을 통해 nginx-rc 리소스와 그와 관련된 것 모두 삭제
kubectl get rc,pod —show-labels 명령을 통해 잘 삭제되었는지 확인

# nginx-rs 리소스 생성 (ReplicaSet)
kubectl create –f nginx-rs.yml 명령을 통해 nginx-rs.yml 파일 사용하여 nginx-rs 리소스 생성
kubectl get rs,pod —show-labels 명령을 통해 잘 생성되었는지 확인

# nginx-rs 리소스의 이미지 버전 수정
kubectl edit rs nginx-rs 명령을 통해 nginx-rs의 이미지 버전을 1.15로 변경
kubectl describe rs nginx-rs 명령을 통해 이미지 버전이 잘 변경되었는지 확인

kubectl describe pod | grep Image: 명령을 통해 클러스터 내 Pod들이 사용 중인 이미지 확인
kubectl get pod 명령을 통해 실행 중인 파드 3개 확인
# nginx-rs 리소스와 그와 관련된 것 모두 제
kubectl delete pod nginx-rs-qxmxx 명령을 통해 nginx-rs 리소스와 그와 관련된 것 모두 삭제
kubectl get pod 명령을 통해 삭제되어도 자동 생성된 특성 확인

# Pod 리소스 삭제
kubectl delete pod —all 명령을 통해 생성된 Pod 모두 삭제
kubectl get pod —show-labels 명령을 통해 재생성된 파드의 라벨까지 확인
kubectl describe pod | grep Image: 명령을 통해 사용 중인 이미지 확인

# nginx-rs 리소스의 이미지 버전 수정
kubectl edit rs nginx-rs 명령을 통해 사용하는 이미지의 버전을 1.14로 되돌림
kubectl describe rs nginx-rs 명령을 통해 이미지의 버전이 잘 변경되었는지 확인

kubectl describe pod | grep Image: 명령을 통해 현재 존재하는 Pod의 컨테이너 이미지 버전 확인
# Pod 리소스 삭제
kubectl delete pod —all 명령을 통해 모든 Pod 삭제
kubectl describe pod | grep Image: 명령을 통해 이미지의 버전이 1.15에서 1.14로 잘 변경되었는지 확인
kubectl get rs,pod 명령을 통해 RS와 Pod 한 번에 확인
# nginx-rs 리소스와 그와 관련된 것 삭제
kubectl delete rs nginx-rs 명령을 통해 nginx-rs 리소스와 그와 관련된 것 모두 삭제
kubectl get rs,pod 명령을 통해 잘 삭제되었는지 확인
Ⅳ. Deployment (디플로이먼트)
| Deployment | 구분 | 설명 |
| 개념 | ReplicaSet을 이용하여 Pod 개수 조정하고 유지하는 컨트롤러 | |
| 역할 | Pod의 생성, 업데이트, 삭제, 롤백 등을 자동으로 관리 | |
| 특징 | Pod의 개수뿐 아니라 배포 전략 (RollingUpdate / Recreate) 지원 | |
| 버전 관리 및 자동 복구 기능 제공 | ||
| RS (ReplicaSet)보다 상위 개념으로 RS 내부적으로 제어 | ||
| YAML 설정 변경 시 자동으로 새로운 RS 생성 및 구버전 종료 | ||
| 사용 목적 | 안정적인 애플리케이션 배포 및 무중단 서비스 유지 |
Ⅳ - Ⅰ. Rolling Update & RollBack
| Rolling Update & Rollback |
구분 | 설명 |
| Rolling Update | 기존 Pod를 점진적으로 새 버전으로 교체하여 서비스 중단 없이 업데이트 수행 | |
| Rollback | 문제가 발생할 경우, 이전 버전으로 즉시 복원 가능 | |
| 특징 | kubectl rollout status로 배포 상태 확인 가능 | |
| kubectl rollout undo로 이전 버전 복귀 | ||
| 항상 일부 Pod는 정상 동작하도록 유지 (가용성 확보) | ||
| CI / CD 환경에서 안전한 자동 배포에 활용 | ||
| 장점 | 사용자는 애플리케이션이 항상 운영 가능한 상태라 인식 | |
| 개발자는 배포 리스크 최소화 가능 | ||
| 예시 명령어 | kubectl rollout status deployment/webserver | |
| kubectl rollout undo deployment/webserver |

cd ~/kube/07/deploy 명령을 통해 deploy 디렉터리로 이동
kubectl api-resources 명령을 통해 쿠버네티스 클러스터 내에서 사용 가능한 리소스 타입 목록 확인

vi nginx-deploy.yml 명령을 통해 vi 편집기 사용하여 nginx-deploy.yml 파일 생성 및 내용 입력
cat nginx-deploy.yml 명령을 통해 nginx-deploy.yml 파일 내용 확인
[ nginx-deploy.yml 파일의 내용 ]
apiVersion: apps/v1 명령을 통해 API apps/v1 버전 사용하도록 설정
kind: Deployment 명령을 통해 리소스 종류를 Deployment로 설정
metadata.name: nginx-deploy 명령을 통해 Deployment의 이름을 nginx-deploy로 설정
spec.replicas: 3 명령을 통해 Pod를 3개 복제해서 실행하도록 지정
spec.selector.matchLabels.app: webui 명령을 통해 app=webui 라벨을 가진 Pod를 관리하도록 설정
spec.template.metadata.name: nginx-pod 명령을 통해 Pod의 이름을 nginx-pod로 설정
spec.template.metadata.labels.app: webui 명령을 통해 Pod에 app=webui 라벨 부여
spec.spec.containers.name: nginx-container 명령을 통해 컨테이너 이름을 nginx-container로 지정
spec.spec.containers.image: nginx:1.14 명령을 통해 사용할 Docker 이미지를 Nginx 1.14로 지정

# nginx-deploy 리소스 생성 (Deployment)
kubectl create –f nginx-deploy.yml 명령을 통해 nginx-deploy.yml 파일 이용해 nginx-deploy 리소스 성
kubectl get deploy,rs,pod —show-labels 명령을 통해 Deployment, RS, Pod 리소스를 라벨과 함께 확인

kubectl describe deployments.app nginx-deploy 명령을 통해 nginx-deploy의 세부 구성과 상태 확인

kubectl describe rs nginx-deploy-9cc457697 명령을 통해
Deployment가 자동으로 생성한 RS가 어떤 Pod를 관리하고 있는지 상세히 확인

kubectel get pod —show-labels 명령을 통해 현재 실행 중인 Pod 목록을 라벨과 함께 확인
# nginx-deploy 리소스 삭제
kubectl delete pod nginx-deploy-9cc457697-dttgm 명령을 통해 리소스 삭제
kubectl get pod —show-labels 명령을 통해 특정 Pod를 삭제했지만
RS의 특성 덕분에 Pod 하나가 재생성된 것 확인

kubectl describe deployments.apps 명령을 통해 Deployment의 현재 상태 상세히 확인

# nginx-deploy 리소스와 그와 관련된 것 모두 삭제
kubectl delete deployments.apps nginx-deploy 명령을 통해 nginx-deploy 리소스와 그와 관련된 것 모두 삭제
kubectl get deploy,rs,pod 명령을 통해 Deployment와 그와 관련된 것들이 잘 삭제되었는지 확인

cd ../roll/ 명령을 통해 deploy 디렉터리에서 roll 디렉터리로 이동
vi deploy-test1.yml 명령을 통해 vi 편집기 사용하여 deploy-test1.yml 파일 생성 및 내용 입력
cat deploy-test1.yml 명령을 통해 deploy-test1.yml 파일의 내용 확인
[ deploy-test1.yml 파일의 내용 ]
apiVersion: apps/v1 명령을 통해 API apps/v1 버전 사용하도록 지정
kind: Deployment 명령을 통해 리소스 종류를 Deployment로 설정
metadata.name: nginx-deploy 명령을 통해 Deployment의 이름을 nginx-deploy로 설정
spec.replicas: 3 명령을 통해 Pod를 3개 복제해서 실행하도록 지정
spec.selector.matchLabels.app: webui 명령을 통해 app=webui 라벨을 가진 Pod를 관리하도록 설정
spec.template.metadata.labels.app: webui 명령을 통해 Pod에 app=webui 라벨 부여
spec.spec.containers.name: nginx-container 명령을 통해 컨테이너 이름을 nginx-container로 지정
spec.spec.containers.image: nginx:1.14 명령을 통해 사용할 Docker 이미지를 Nginx 1.14로 지정

# deploy-test1 리소스 생성 (Deployment)
kubectl create -f deploy-test1.yml 명령을 통해 deploy-test1.yml 파일 이용해 deploy-test1 리소스 생성
--record 옵션을 통해 명령을 실행한 내역을 rollout history에 기록하도록 설정
# deploy-test1 리소스 명령 이력 조회
kubectl rollout history deployment nginx-deploy 명령을 통해 롤링 업데이트 이력 (Revision History) 확인
kubectl get deploy,rs,pod —show-labels 명령을 통해 Deployment, RS, Pod를 라벨과 함께 한 번에 확인

kubectl describe pod | grep Image: 명령을 통해 현재 실행 중인 Pod들의 컨테이너 이미지 버전 확인
# nginx-deploy 리소스 이미지 버전 업데이트
kubectl set image deploy nginx-deploy nginx-container=nginx:1.15 명령을 통해
nginx-deploy 템플릿의 컨테이너 이미지를 Nginx:1.14에서 Nginx:1.15로 업데이트
—record 옵션을 통해 이 명령을 Revision History에 기록하도록 설정
# nginx-deploy 리소스 Rollout history 확인
kubectl rollout history deployment nginx-deploy 명령을 통해 Deployment 버전 (Revision) 이력 확인
kubectl describe pod | grep Image: 명령을 통해 이미지가 Nginx 1.15로 잘 변경되었는지 확인

kubectl get pod 명령을 통해 현재 클러스터에서 실행 중인 Pod 목록 조회
# nginx-deploy 리소스 RollingUpdate 상태 모니터링
kubectl rollout status deployment nginx-deploy 명령을 통해
현재 Deployment가 업데이트 중인지, 완료되었는지 실시간으로 모니터링
# nginx-deploy 리소스 이미지 버전 업데이트
kubectl set image deploy nginx-deploy nginx-container=nginx:1.16 명령을 통해
nginx-deploy 템플릿의 컨테이너 이미지를 Nginx:1.15에서 Nginx:1.16으로 업데이트
—record 옵션을 통해 이 명령을 Revision History에 기록하도록 설정
# niginx-deploy 리소스 RollingUpdate 상태 모니터링
kubectl rollout status deployment nginx-deploy 명령을 통해 업데이트 중인 Deployment의 상태 실시간으로 확인
kubectl get pod 명령을 통해 새 Pod의 이름이 모두 새 해시로 바뀐 것 확인

# nginx-deploy 리소스 Revision 확인
kubectl rollout history deployment nginx-deploy 명령을 통해 Deployment 버전 (Revision) 이력 확인
# nginx-deploy 리소스 RollingUpdate 상태 모니터링
kubectl rollout status deployment nginx-deploy 명령을 통해 업데이트 중인 Deployment의 상태 실시간으로 확인
# nginx-deploy 리소스 이미지 버전 업데이트
kubectl set image deploy nginx-deploy nginx-container=nginx:1.17 명령을 통해
nginx-deploy 템플릿의 컨테이너 이미지를 Nginx:1.16에서 Nginx:1.17로 업데이트
—record 옵션을 통해 이 명령을 Revision History에 기록하도록 설정
# nginx-deploy 리소스 RollingUpdate 상태 모니터링
kubectl rollout status deployment nginx-deploy 명령을 통해 업데이트 중인 Deployment의 상태 실시간으로 확인
kubectl describe pod | grep Image: 명령을 통해 Nginx 1.17 이미지로 잘 변경되었는지 확인
# nginx-deploy 리소스 Rollout history 확인
kubectl rollout histroy deployment nginx-deploy 명령을 통해 Deployment 버전 (Revision) 이력 확인

kubectl describe deploy nginx-deploy 명령을 통해 nginx-deploy의 현재 상세 상태 확인

kubectl describe pod | grep Image: 명령을 통해 현재 클러스터 내에서 실행 중인 Pod 컨테이너 이미지 버전 확인
# nginx-deploy 리소스 이미지 버전 업데이트
kubectl set image deploy nginx-deploy nginx-container=nginx:1.18 명령을 통해
nginx-deploy 템플릿의 컨테이너 이미지를 Nginx:1.17에서 Nginx:1.18로 업데이트
—record 옵션을 통해 이 명령을 Revision History에 기록하도록 설정
kubectl describe pod | grep Image: 명령을 통해 이미지 버전이 1.17에서 1.18로 잘 변경되었는지 확인

# nginx-deploy 리소스 Revision 확인
kubectl rollout history deployment nginx-deploy 명령을 통해 Deployment 버전 (Revision) 이력 확인
# Rollback - Nginx:1.18 -> Nginx:1.17
kubectl rollout undo deployment nginx-deploy 명령을 통해 직전 Revision으로 RollBack
kubectl describe pod | grep Image: 명령을 통해 이미지 버전이 1.18에서 1.17로 변경된 것 확인
# Rollback - Nginx:1.17 -> Nginx:1.15
kubectl rollout undo deployment nginx-deploy —to-revision 2 명령을 통해 Revision 2로 RollBack
kubectl describe pod | grep Image: 명령을 통해 이미지 버전이 1.17에서 1.15로 변경된 것 확인
# Rollback - Nginx:1.15 -> Nginx:1.14
kubectl rollout undo deployment nginx-deploy —to-revision 1 명령을 통해 Revision 1로 RollBack
kubectl describe pod | grep Image: 명령을 통해 이미지 버전이 1.15에서 1.14로 변경된 것 확인
# nginx-deploy 리소스와 그와 관련된 모든 것 삭제
kubectl delete deployments.apps nginx-deploy 명령을 통해 nginx-deploy 리소스와 그와 관련된 것 모두 삭제
kubectl get deploy,rs,pod 명령을 통해 Deployment, RS, Pod가 잘 삭제되었는지 확인
Ⅳ - Ⅱ. yaml 파일을 이용한 Deployment Rolling Update 및 RollBack 구성
| yaml 파일을 이용한 Deployment Rolling Update 및 RollBack 구성 |
구분 | 설명 | |
| Rolling Update 설명 | strategy.type : RollingUpdate로 설정하여 무중단 배포 가능 | ||
| 최대 비가용 Pod 개수 제어 |
항목 | 설명 | |
| maxUnavailable | 업데이트 중 동시에 중단 가능한 Pod 수 지정 | ||
| ex) maxUnavailable : 1 -> 항상 1개 이상 Pod 유지 | |||
| 최대 추가 Pod 개수 제어 |
항목 | 설명 | |
| maxSurge | 업데이트 중 동시에 추가 생성 가능한 Pod 수 지정 | ||
| ex) maxSurge : 1 -> 새 버전 Pod 1개 미리 생성 가능 | |||
| 버전 이력 관리 | 항목 | 설명 | |
| revisionHistoryLimit | Rollback을 위해 보존할 이전 버전 수 지정 | ||
| ex) revisionHistoryLimit : 5 | |||
| 자동 RollBack 조건 |
항목 | 설명 | |
| 개념 | 업데이트 실패 시 자동으로 이전 안정 버전으로 복구 가능 | ||
| 명령어 | kubectl rollout undo | ||
| 명령어 예시 | ex) bash kuectl rollout history deployment webserver | ||
| ex) kubectl rollout undo deployment webserver | |||

vi deploy-test2.yml 명령을 통해 vi 편집기 사용하여 deploy-test2.yml 파일 생성 및 내용 입력
cat deploy-test2.yml 명령을 통해 입력한 파일의 내용 확인
[ deploy-test2.yml 파일의 내용 ]
apiVersion: apps/v1 명령을 통해 API apps/v1 버전 사용하도록 설정
kind: Deployment 명령을 통해 리소스 종류를 Deployment로 설정
metadata.name: nginx-deploy 명령을 통해 Deployment의 이름을 nginx-deploy로 설정
metadata.annotations.kubernetes.io/change-cause: version 1.14 명령을 통해
kubectl rollout history 시에 CHANGE-CAUSE 컬럼으로 표시되도록 설정
spec.replicas: 3 명령을 통해 Pod를 3개 복제해서 실행하도록 지정
spec.selector.matchLabels.app: webui 명령을 통해 app=webui 라벨을 가진 Pod를 관리하도록 설정
spec.template.metadata.name: nginx-pod 명령을 통해 Pod에 nginx-pod라는 이름 부여
spec.template.metadata.labels.app: webui 명령을 통해 Pod에 app=webui 라벨 부여
spec.spec.containers.name: nginx-container 명령을 통해 컨테이너 이름을 nginx-container로 지정
spec.spec.containers.image: nginx:1.14 명령을 통해 사용할 Docker 이미지를 Nginx 1.14로 지정

# deploy-test2 리소스 생성 (Deployment)
kubectl create –f deploy-test2.yml 명령을 통해 deploy-test2.yml 파일 이용해 deploy-test2 리소스 생성
kubectl get deploy,rs,pod 명령을 통해 Deployment, RS, Pod 한 번에 확인
kubectl describe pod | grep Image: 명령을 통해 현재 Pod에서 실행 중인 이미지 버전 확인
# nginx-deploy 리소스 Revision 확인
kubectl rollout history deployment nginx-deploy 명령을 통해 Deployment의 배포 이력 확인

vi deploy-test2.yml 명령을 통해 vi 편집기 사용하여 deploy-test2.yml 파일의 내용 수정
cat deploy-test2.yml 명령을 통해 deploy-test2.yml 파일의 변경 내용 확인
[ deploy-test2.yml 파일의 변경 내역 ]
spec.spec.containers.image: nginx:1.15 명령을 통해 Nginx 이미지의 버전을 1.15로 설정

# deploy-test2 리소스 업데이트
kubectl apply –f deploy-test2.yml 명령을 통해 nginx-deploy 설정을 deploy-test2.yml 파일의 내용으로 업데이트
kubectl describe pod | grep Image: 명령을 통해 이미지 버전이 1.14에서 1.15로 변경된 것 확인

# nginx-deploy 리소스 Revision 확인
kubectl rollout history deployment nginx-deploy 명령을 통해 Deployment의 Revision 목록 확인
kubectl describe deployments.apps 명령을 통해 nginx-deploy의 현재 상세 상태 확인

# nginx-deploy 리소스 이미지 버전 수정
kubectl edit deployments.apps nginx-deploy 명령을 통해 Nginx 이미지의 버전을 1.15에서 1.16으로 수정
kubectl describe pod | grep Image: 명령을 통해 이미지 버전이 잘 수정되었는지 확인
# nginx-deploy 리소스 Revision 확인
kubectl rollout history deployment nginx-deploy 명령을 통해 Deployment의 Revision 목록 확인
kubectl describe deployments.apps 명령을 통해 nginx-deploy의 현재 상세 상태 확인

# nginx-deploy 이미지 버전 수정
kubectl edit deployments.apps nginx-deploy 명령을 통해 Nginx 이미지의 버전을 1.16에서 1.15로 수정
kubectl describe pod | grep Image: 명령을 통해 이미지 버전이 잘 수정되었는지 확인
# nginx-deploy 리소스 Revision 확인
kubectl rollout history deployment nginx-deploy 명령을 통해 Deployment의 Revision 목록 확인

vi deploy-test2.yml 명령을 통해 vi 편집기 사용하여 deploy-test2.yml 파일의 내용 수정
cat deploy-test2.yml 명령을 통해 deploy-test2.yml 파일의 변경 내용 확인
[ deploy-test2.yml 파일의 변경 내역 ]
spec.spec.containers.image: nginx:1.14 명령을 통해 Nginx 이미지의 버전을 1.14로 설정

# nginx-deploy 리소스 업데이트
kubectl apply –f deploy-test2.yml 명령을 통해 nginx-deploy 설정을 deploy-test2.yml 파일의 내용으로 업데이트
kubectl describe pod | grep Image: 명령을 통해 이미지 버전이 1.15에서 1.14로 변경된 것 확인
# nginx-deploy 리소스와 그와 관련된 것 모두 삭제
kubectl delete deployments.apps nginx-deploy 명령을 통해 nginx-deploy 리소스와 그와 관련된 것 모두 삭제
kubectl get deploy,rs,pod 명령을 통해 잘 삭제되었는지 확인
Ⅴ. DaemonSet (데몬셋)
| DaemonSet | 구분 | 설명 | |
| 개념 | 클러스터의 모든 노드 (Node) 또는 특정 노드에 1개의 Pod를 자동 배포하고 유지하는 컨트롤러 | ||
| 역할 | 노드 추가 / 삭제 시 자동으로 Pod를 추가 및 삭제하여 클러스터 전체 관리 일관성 유지 | ||
| 주요 특징 | 항목목 | 설명 | |
| Pod 배포 위치 제어 | nodeSelector, affinity, tolerations 설정으로 특정 노드에만 배포 가능 | ||
| RollingUpdate 지원 | 버전 1.6 이상부터 RollingUpdate 방식으로 무중단 업데이트 가능 | ||
| 자동 복구 기능 | 노드 장애나 삭제 시, 해당 노드의 Pod는 자동으로 재배포 됨 | ||
| 스케줄링 제어 | 다른 컨트롤러 (Deployment, ReplicaSet)와 달리, 전체 노드에 균일 배포 중심 |
||
| 리소스 관리 | CPU, Memory 리소스 제한 및 QoS 설정 가능 (시스템 리소스 과다 점유 방지) |
||
| 각 노드에 반드시 1개의 Pod 존재 보장 | |||
| 로그 수집기, 모니터링 에이전트, 네트워크 플러그인 배포에 적합 | |||
| 노드가 추가될 경우, 자동으로 새 노드에도 Pod 배포 | |||
| 노드가 삭제될 경우, 관련 Pod 자동 제거 | |||
| 배포 단위 | 노드 단위 (Node 단위 1 Pod) | ||
| 관리 방식 | Deployment처럼 RollingUpdate 전략 사용 가능 (updateStrategy : RollingUpdate) |
||
| 삭제 시 동작 | DaemonSet 리소스 삭제 시 모든 노드의 Pod도 자동 삭제 | ||
| 활용 예시 | 로그 수집기 (Fluentd, Filebeat) | ||
| 모니터링 (Prometheus Node Exporter) | |||
| 네트워크 플러그인 (Calico, Flannel) | |||

cd ../ds 명령을 통해 roll 디렉터리에서 ds 디렉터리로 이동
kubectl api-resources 명령을 통해 쿠버네티스 클러스터 내에서 사용 가능한 리소스 타입 목록 확인

vi nginx-ds.yml 명령을 통해 vi 편집기 사용하여 nginx-ds.yml 파일 생성 및 내용 입력
cat nginx-ds.yml 명령을 통해 nginx-ds.yml 파일의 내용 확인
[ nginx-ds.yml 파일의 내용 ]
apiVersion: apps/v1 명령을 통해 API apps/v1 버전 사용하도록 지정
kind: DaemonSet 명령을 통해 리소스 종류를 DaemonSet으로 설정
metadata.name: nginx-ds 명령을 통해 Deployment의 이름을 nginx-ds로 설정
spec.selector.matchLabels.app: webui 명령을 통해 app=webui 라벨을 가진 Pod를 관리하도록 설정
spec.template.metadata.name: nginx-pod 명령을 통해 Pod에 nginx-pod라는 이름 부여
spec.template.metadata.labels.app: webui 명령을 통해 Pod에 app=webui 라벨 부여
spec.spec.containers.name: nginx-container 명령을 통해 컨테이너 이름을 nginx-container로 지정
spec.spec.containers.image: nginx:1.14 명령을 통해 사용할 Docker 이미지를 Nginx 1.14로 지정

# nginx-ds 리소스 생성 (DaemonSet)
kubectl create –f nginx-ds.yml 명령을 통해 nginx-ds.yml 파일 이용하여 nginx-ds 리소스 생성
kubectl get ds,pod –o wide 명령을 통해 DaemonSet과 Pod의 상세 정보 확인
kubectl describe ds nginx-ds 명령을 통해 nginx-ds의 현재 상세 상태 확인

kubectl get pod –o wide 명령을 통해 Pod의 상세 정보 확인
# nginx-ds 리소스 제
kubectl delete pod nginx-ds-wr2nm 명령을 통해 특정 Pod 삭제
kubectl get pod –o wide 명령을 통해 Pod가 삭제되어도 자동 재생성되는 것 확인
kubectl describe pod nginx-ds-dbcg1 명령을 통해 특정 Pod의 상세 정보 확인

kubectl describe pod | grep Image: 명령을 통해 사용하고 있는 이미지 버전 확인
# nginx-ds 이미지 Nginx:1.14 -> Nginx:1.15 변경
kubectl edit ds nginx-ds 명령을 통해 이미지의 버전을 1.14에서 1.15로 수정
kubectl describe pod | grep Image: 명령을 통해 이미지의 버전이 1.15로 잘 적용되었는지 확인
# nginx-ds 이미지 Nginx:1.15 -> Nginx:1.14 변경
kubectl edit ds nginx-ds 명령을 통해 이미지 버전을 1.15에서 1.14로 다시 수정
kubectl describe pod | grep Image: 명령을 통해 이미지 버전이 1.14로 다시 적용되었는지 확인

kubectl get ds –A 명령을 통해 모든 네임스페이스의 DaemonSet 목록 확인
kubectl describe ds –n kube-system calico-node 명령을 통해 Calico DS의 상세 설정 확인

kubectl describe ds –n kube-system node-local-dns 명령을 통해
DNS 성능과 안정성을 개선하기 위한 NodeLocalDNS 구성의 상세 설정 확인

kubectl get ds,pod 명령을 통해 현재 실행 중인 Pod와 DaemonSet 상태 확인
# nginx-ds DaemonSet 리소스와 그와 관련된 것 모두 삭제
kubectl delete ds nginx-ds 명령을 통해 nginx-ds와 그와 관련된 것 모두 삭제
kubectl get ds,pod 명령을 통해 잘 삭제되었는지 확인
Ⅵ. StatefulSet (스테이트풀셋)
| StatefulSet | 구분 | 설명 | |
| 개념 | 상태 (State)를 가지는 Pod를 순차적으로 생성, 유지, 삭제하는 컨트롤러 | ||
| 역할 | 각 Pod에 고유한 네트워크 ID와 Persistent Volume (스토리지)를 부여하여 데이터의 일관성과 지속성 보장 |
||
| 특징 | Pod 이름 순차적으로 부여 (ex. db-0, db-1, db-2) | ||
| Pod의 생성 및 삭제 순서 보장 | |||
| Pod가 재시작되어도 고유 스토리지 (PV) 유지 | |||
| 일반 Deployment와 달리, Pod 간 의존성과 순서 고려하여 동작 | |||
| 배포 단위 | Pod 순차 생성 및 삭제 | ||
| 관리 방식 | Deployment처럼 업데이트 가능하지만, 순서 제어를 통해 데이터 무결성 유지 | ||
| 삭제 시 주의점 | Pod 삭제 시에도 Persistent Volume은 유지되어 데이터 손실 방지 가능 | ||
| 주요 동작 방식 | 동작 방식 | 설명 | |
| Pod 네이밍 규칙 | Pod 이름이 StatefulSet 이름 + 인덱스로 자동 부여 (ex. mysql-0, mysql-1) |
||
| Stable Network ID | 각 Pod는 DNS 이름을 통해 고유 네트워크 식별자 가짐 | ||
| Persistent Volume Claim (PVC) |
Pod마다 별도의 PVC 생성해 데이터 독립성 보장 | ||
| 순서 기반 업데이트 | Pod를 하나씩 순서대로 업데이트하여 서비스 중단 최소화 | ||
| 재스케줄링 보장 | 동일 Pod 이름으로 재생성되어 데이터 일관성 유지 | ||
| 활용 예시 | 데이터베이스 (MySQL, PostgreSQL) | ||
| 메시지 큐 (Kafka, RabbitMQ) | |||
| 분산 캐시 시스템 (Redis, Cassandra) | |||

cd ../sts 명령을 통해 ds 디렉터리에서 sts 디렉터리로 이동
kubectl api-resources 명령을 통해 쿠버네티스 클러스터 내에서 사용 가능한 리소스 타입 목록 확인

vi nginx-sts.yml 명령을 통해 vi 편집기 사용하여 nginx-sts.yml 파일 생성 및 내용 입력
cat nginx-sts.yml 명령을 통해 nginx-sts.yml 파일의 내용 확인
[ nginx-sts.yml 파일의 내용 ]
apiVersion: apps/v1 명령을 통해 API apps/v1 버전 사용하도록 설정
kind: StatefulSet 명령을 통해 리소스 종류를 StatefulSet으로 설정
metadata.name: nginx-sts 명령을 통해 StatefulSet의 이름을 nginx-sts로 설정
spec.selector.matchLabels.app: webui 명령을 통해 app=webui 라벨을 가진 Pod를 관리하도록 설정
spec.template.metadata.name: nginx-pod 명령을 통해 Pod에 nginx-pod라는 이름 부여
spec.template.metadata.labels.app: webui 명령을 통해 Pod에 app=webui 라벨 부여
spec.spec.containers.name: nginx-container 명령을 통해 컨테이너 이름을 nginx-container로 지정
spec.spec.containers.image: nginx:1.14 명령을 통해 사용할 Docker 이미지를 Nginx 1.14로 지정

# nginx-sts 리소스 생성 (StatefulSet)
kubectl create –f nginx-sts.yml 명령을 통해 nginx-sts.yml 파일 이용하여 nginx-sts 리소스 생성
kubectl get sts,pod —show-labels 명령을 통해 StatefulSet과 Pod의 목록 확인
kubectl describe sts nginx-sts 명령을 통해 nginx-sts 리소스의 상세 정보 확인

kubectl get pod –o wide 명령을 통해 모든 StatefulSet Pod의 실행 상태 확인
# nginx-sts 리소스 삭제
kubectl delete pod nginx-sts-2 명령을 통해 특정 Pod 수동 삭제
kubectl get pod –o wide 명령을 통해 파드가 자동으로 다시 생성되었고, 이름 동일한 것 확인
# nginx-sts 리소스 삭제
kubectl delete pod nginx-sts-2 명령을 통해 특정 Pod 수동 삭제
kubectl get pod –o wide 명령을 통해 파드가 자동으로 다시 생성되었고, 이름 동일한 것 확인

# nginx-sts 리소스 Pod 수 확장
kubectl scale statefulset nginx-sts —replicas 4 명령을 통해 nginx-sts 리소스의 Pod 수를 3개에서 4개로 확장
kubectl get pod –o wide 명령을 통해 Pod 수가 4개로 확장되었는지 확인
# nginx-sts 리소스 Pod 수 축소
kubectl scale statefulset nginx-sts —replicas 2 명령을 통해 nginx-sts 리소스의 Pod 수를 4개에서 2개로 축소
kubectl get pod –o wide 명령을 통해 Pod 수가 2개로 축소되었는지 확인
kubectl describe pod | grep Image: 명령을 통해 Pod가 사용 중인 이미지의 정보 확인

# nginx-sts 리소스 이미지 버전 수정
kubectl edit statefulsets.apps nginx-sts 명령을 통해 Nginx 이미지 버전을 1.14에서 1.15로 수정
kubectl describe pod | grep Image: 명령을 통해 Pod가 사용 중인 이미지 버전이 1.15로 잘 적용되었는지 확인
# nginx-sts StatefulSet 리소스 이미지 RollBack
kubectl rollout undo sts nginx-sts 명령을 통해 StatefulSet을 이전 Revision으로 RollBack 시킴
kubectl describe pod | grep Image: 명령을 통해 Pod가 사용 중인 이미지 버전이 1.14로 잘 적용되었는지 확인

# nginx-sts 리소스와 그와 관련된 것 모두 삭제
kubectl delete sts nginx-sts 명령을 통해 nginx-sts 리소스와 그와 관련된 것 모두 삭제
kubectl get sts,pod 명령을 통해 잘 삭제되었는지 확인
Ⅶ. Job (잡)
| Job | 구분 | 설명 | |
| 개념 | 일회성 (batch) 작업을 수행하고 작업 완료 후 자동 종료되는 컨트롤러 | ||
| 역할 | 지정된 명령 또는 스크립트를 한 번만 실행하고, 성공 시 종료 (성공 횟수 관리 가능) | ||
| 특징 | Pod 실행이 완료 (성공)될 때까지 재시도 | ||
| 실패 시 자동으로 재시작 정책 (restartPolicy) 적용 | |||
| completions 옵션으로 총 실행 횟수 지정 | |||
| parallelism 옵션으로 동시에 실행할 Pod 수 지정 가능 | |||
| 실행 완료 후 Pod는 종료되지만 Job 리소스는 상태 유지 | |||
| Pod 재시작 정책 |
정책 | 설명 | |
| OnFailure | 실패 시 재시작 | ||
| Never | 실패해도 재시작 안 함 | ||
| 활용 예시 | 데이터 마이그레이션 | ||
| 백업 스크립트 실행 | |||
| 로그 정리 / 일회성 점검 작업 | |||
| 명령어 예시 | ex) bash kubectl create job db-backup --image=mysql:5.7 -- /scripts/backup.sh | ||

cd ../job/ 명령을 통해 sts 디렉터리에서 job 디렉터리로 이동
kubectl api-resources 명령을 통해 쿠버네티스 클러스터 내에서 사용 가능한 리소스 타입 목록 확인

vi job-test.yml 명령을 통해 vi 편집기 사용하여 job-test.yml 파일 생성 및 내용 입력
cat job-test.yml 명령을 통해 job-test.yml 파일의 내용 확인
[ job-test.yml 파일의 내용 ]
apiVersion: batch/v1 명령을 통해 Job 리소스는 batch 작업이기 때문에 batch/v1 버전으로 설정
kind: Job 명령을 통해 리소스 종류를 한 번 실행되고 종료되는 Job 객체로 설정
metadata.name: job-test 명령을 통해 Job 리소스의 이름을 job-test로 지정
spec.template.spec.containers.name: centos-container 명령을 통해 Pod의 이름 지정
spec.template.spec.containers.image: centos:7 명령을 통해 Pod에서 사용할 이미지 지정
spec.template.spec.containers.command: [“bash”] 명령을 통해 컨테이너 실행 시 bash 쉘 실행하도록 지정
spec.template.spec.containers.args: “-c” 명령을 통해 따옴표 안의 문자열을 명령으로 실행하도록함
spec.template.spec.containers.args: “echo ~ ” 명령을 통해 여러 명령을 순서대로 실행하도록 설정
spec.template.spec.restartPolicy: Never 명령을 통해 한 번 실행 후 종료하도록 설정

# job-test 리소스 생성 (Job)
kubectl create –f job-test.yml 명령을 통해 job-test.yml 파일 이용하여 job-test 리소스 생성
kubectl get pod 명령을 통해 리소스가 잘 생성되었는지 확인
kubectl describe jobs.batch job-test 명령을 통해 job-test의 리소스 상세 정보 확인

kubectl get pod –o wide 명령을 통해 Job 리소스가 실행되었다가 완료된 것 확인
kubectl describe jobs.batch job-test 명령을 통해 job-test 리소스의 상세 정보 확인

kubectl logs jbb-test-z2ln9 명령을 통해 특정 Pod의 상세 정보 확인
# job-test 리소스와 그와 관련된 것 모두 삭제
kubectl delete job 명령을 통해 job-test 리소스와 그와 관련된 것 모두 삭제
kubectl get job,pod 명령을 통해 잘 삭제되었는지 확인
Ⅷ. CronJob (크론잡)
| CronJob | 구분 | 설명 |
| 개념 | Job을 일정 주기 (스케줄)에 따라 자동 실행하도록 관리하는 컨트롤러 | |
| 역할 | cron 표현식으로 정의된 시간에 맞춰 Job을 생성하고 실행 | |
| 특징 | 지정된 주기 / 시간마다 Job 자동 실행 | |
| 스케줄은 Linux cron 형식 사용 (ex. "0 3 * * * -> 매일 3시) | ||
| startingDeadlineSeconds로 지연된 Job 실행 허용 시간 설정 가능 | ||
| concurrencyPolicy로 동시 실행 제어 (Allow, Forbid, Replace) | ||
| 과거 Job 로그는 successfulJobHistoryLimi으로 개수 관리 | ||
| 활용 예시 | 매일 새벽 3시 백업 작업 | |
| 매시간 임시 파일 삭제 | ||
| 매주 로그 압축 / 정리 작업 |
Ⅷ - Ⅰ. Cron 시간 및 요일 지정 방법
| Cron 시간 및 요일 지정 방법 | |||
| 분 시 일 월 요일 m h d M W |
|||
| 분 (m, miniute) | 0 ~ 59 | ||
| 시 (h, hours) | 0 ~ 23 | ||
| 일 (d, day) | 1 ~ 31 | ||
| 월 (M, Month) | 1 ~ 12 | ||
| 요일 (W, Week) | 0 : 일요일, 1 : 월요일, 2 : 화요일, 3 : 수요일, 4 : 목요일, 5 : 금요일, 6 : 토요일 | ||
Ⅷ - Ⅱ. 예시
| 형식 | |||
| 분 시 일 월 요일 m h d M W |
|||
| 매월 1일 오전 8시에 job을 실행 | 0 8 1 * * | ||
| 매주 일요일날 새벽 5시에 job을 실행 | 0 5 * * 0 | ||
| 주중 오전 9시 30분에 job을 실행 | 30 9 * * 1 - 5 | ||
| 1분마다 한 번씩 실행 | * * * * * | ||

cd ../cronjob/ 명령을 통해 job 디렉터리에서 cronjob 디렉터리로 이동
vi cronjob-test.yml 명령을 통해 vi 편집기 사용하여 cronjob-test.yml 파일 생성 및 내용 입력
cat cronjob-test.yml 명령을 통해 cronjob-test.yml 파일의 내용 확인
[ cronjob-test.yml 파일의 내용 ]
apiVersion: batch/v1 명령을 통해 Job과 동일하게 Cronjob도 배치 작업 사용하기 때문에 batch/v1 사용하도록 설정
kind: CronJob 명령을 통해 리소스 종류로 Job을 일정 주기로 자동 실행시키는 CronJob으로 설정
metadata.name: cronjob-test 명령을 통해 CronJob 리소스의 이름을 cronjob-test로 지정
spec.schedule: “* * * * *” 명령을 통해 매 1분마다 실행하도록 설정
spec.startingDeadlineSecond: 500 명령을 통해 스케줄이 약간 늦어도 500초 이내라면 실행 허용하도록 설정
spec.concurrencyPolicy: Forbid 명령을 통해 이전 Job이 아직 실행 중이면 새 Job은 실행하지 않도록 설정
spec.jobTemplate.spec.template.spec.container.name: hello 명령을 통해 컨테이너 이름 설정
spec.jobTemplate.spec.template.spec.container.image: busybox 명령을 통해
컨테이너에서 사용할 이미지를 busybox로 설정

# cronjob-test 리소스 생성 (CronJob)
kubectl create –f cronjob-test.yml 명령을 통해 cronjob-test.yml 파일 사용하여 cronjob-test 리소스 생성
kubectl get cronjobs.batch,pod 명령을 통해 리소스가 잘 생성되었는지 확인
kubectl describe cronjobs.batch 명령을 통해 cronjobs.batch의 상세 정보 확인
kubectl get cronjobs.batch,pod 명령을 통해 한 번 실행 후 완료된 것 확인

kubectl logs pod/cronjob-test-29337525-gqkr7 명령을 통해 특정 Pod의 상세 정보 확인
kubectl logs pod/cronjob-test-29337526-fk981 명령을 통해 특정 Pod의 상세 정보 확인
kubectl logs pod/cronjob-test-29337527-wkrsg 명령을 통해 특정 Pod의 상세 정보 확인
# cronjob-test 리소스와 그와 관련된 것 모두 삭제
kubectl delete cronjobs.barch cronjob-test 명령을 통해 cronjob-test 리소스와 그와 관련된 것 모두 삭제
kubectl get cronjobs,pod 명령을 통해 잘 삭제되었는지 확인
'Kubernetes' 카테고리의 다른 글
| Kubernetes Label과 Annotation (0) | 2026.06.13 |
|---|---|
| Kubernetes Ingress (0) | 2026.06.13 |
| Kubernetes Service (0) | 2026.06.13 |
| Minikube (0) | 2026.06.13 |
| Kubernetes 기본 개념 (0) | 2026.06.13 |