[참고]
본 글은 인프런의
<쿠버네티스 어나더 클래스 - Sprint 1, 2 (#실무기초 #설치 #배포 #Jenkins #Helm #ArgoCD)>
강의 내용과 실습을 바탕으로 정리한 기록입니다.
주요 학습 대상 파일 (Object)
- namespace.yaml: 클러스터 내 리소스들을 논리적으로 격리하고 구분하는 자원 공간 정의
- pv.yaml / pvc.yaml: 스토리지 자원(PersistentVolume)과 이를 사용하기 위한 할당 요청(PersistentVolumeClaim) 정의
- configmap.yaml / secret.yaml: 애플리케이션에 전달할 일반 설정값과 보안 데이터(비밀번호, 토큰 등) 관리
- deployment.yaml: 파드(Pod)의 생성, 개수 유지, 업데이트 전략을 관장하는 워크로드 컨트롤러
- service.yaml: 배포된 파드들에 접근할 수 있도록 고정 IP 및 로드밸런싱을 제공하는 네트워크 엔드포인트
- hpa.yaml: 부하량(CPU/메모리 등)에 따라 파드의 개수를 자동으로 조절(Auto Scaling)하는 설정
아키텍처 다이어그램
기존 개념 도식표만으로는 오브젝트 간의 실질적인 연동 방식이 모호해,
HPA, Deployment, Service, PVC 등 실제 설정 파일의 어떤 값들이 서로 연결되어 작동하는지 실제 YAML 코드 구조를 바탕으로 매핑 관계도를 새로 그려보았습니다.
1. HPA ➔ DEPLOYMENT
- HPA의 scaleTargetRef가 Deployment의 이름(api-tester-1231)을 가리키며 부하에 따른 자동 스케일링을 수행합니다.
2. SERVICE ➔ DEPLOYMENT (Pod)
- 노란색 점선(Selector - Labels): Service의 spec.selector 조건과 Deployment의 spec.template.metadata.labels가 매칭되어 Pod로 트래픽을 전달합니다.
3. DEPLOYMENT ➔ CONFIGMAP & SECRET
- Deployment 내부 컨테이너의 envFrom 및 volumeMounts 구성을 통해 ConfigMap(환경변수)과 Secret(보안 데이터) 정보를 파드 내 디렉토리나 환경변수로 할당합니다.
4. DEPLOYMENT ➔ PVC ➔ PV ➔ Master Node (스토리지 연결)
- 파드가 데이터를 영구 저장하기 위해 PVC를 참조합니다.
- 파란색 점선: PVC의 matchLabels와 PV의 labels가 서로 매칭되어 연결됩니다.
- 최종적으로 PV에 정의된 nodeAffinity와 로컬 경로(hostPath/local)를 통해 Master Node의 실제 물리 디렉토리(/root/k8s-local-volume/1231)와 바인딩됩니다.
1. Deployment ➔ ReplicaSet ➔ Pod 계층화
- Deployment: 전체 배포 전략(RollingUpdate)과 파드 개수(replicas: 2)를 선언
- ReplicaSet: Deployment에 의해 자동 생성되며, pod-template-hash 라벨을 통해 파드의 지정된 복제본 수를 실질적으로 유지·관리
- Pod: 가장 기본 단위로 실행되며, 실제 컨테이너(api-tester-1231:v1.0.0) 환경 구축
2. 색상별 Selector & Labels 매칭 완벽 정리
- 노란색 점선 (Deployment ↔ ReplicaSet): scaleTargetRef 및 컨트롤러 단위의 매칭 관계
- 민트색 점선 (ReplicaSet ↔ Service ↔ Pod): part-of, component, name, instance 라벨과 pod-template-hash가 결합되어 Service 트래픽이 정확히 해당 Pod로 라우팅되는 매칭 구조
- 파란색 점선 (PVC ↔ PV): matchLabels를 통한 스토리지 볼륨 매칭 및 Master Node의 실제 로컬 디렉토리(/root/k8s-local-volume/1231) 바인딩
3. Pod 내부 연동 구조
- ConfigMap / Secret: envFrom 및 volumes 설정을 통해 파드 내부의 환경변수 및 파일 형태로 바인딩되어 애플리케이션에 전달
💻 실제 터미널에서 확인하는 계층 구조
작성한 다이어그램처럼 쿠버네티스 내부에서 Deployment ➔ ReplicaSet ➔ Pod 순으로 생성되었는지는 kubectl 명령어로 직접 확인할 수 있습니다.
# 1. Deployment 확인
kubectl get deployment -n anotherclass-123
# NAME READY UP-TO-DATE AVAILABLE
# api-tester-1231 2/2 2 2
# 2. ReplicaSet 확인 (Deployment 이름 뒤에 해시값이 붙음)
kubectl get rs -n anotherclass-123
# NAME DESIRED CURRENT READY
# api-tester-1231-6b45d6f6b5 2 2 2
# 3. Pod 확인 (ReplicaSet 이름 뒤에 무작위 값이 붙음)
kubectl get pod -n anotherclass-123
# NAME READY STATUS RESTARTS
# api-tester-1231-6b45d6f6b5-x8z9q 1/1 Running 0
# api-tester-1231-6b45d6f6b5-m2k4p 1/1 Running 0
✅ 이름 규칙 포인트:
- ReplicaSet 이름: [Deployment 이름]-[Pod Template 해시값] (6b45d6f6b5)
- Pod 이름: [ReplicaSet 이름]-[랜덤 문자열] (x8z9q, m2k4p)
이처럼 Pod 이름만 봐도 해당 파드가 어떤 ReplicaSet과 Deployment에 속해 있는지 역추적할 수 있습니다.
Label 및 Selector 설계 핵심 규칙
쿠버네티스에서 오브젝트 간의 관계를 유연하고 명확하게 연결하려면 라벨(Label) 규칙을 잘 설계하는 것이 무엇보다 중요합니다.
- 권장 Label 구성 5가지 핵심 요소:
- part-of: 전체 프로젝트/시스템명
- component: 해당 앱의 역할 (예: backend-server, database)
- name: 애플리케이션 이름 (예: api-tester)
- instance: 식별 가능한 인스턴스 명칭 (다른 오브젝트들의 이름으로 확장 사용)
- version: 배포 버전 (예: v1.0.0)
- 관리 도구 명시 (managed-by): Helm 등 배포 및 관리 도구 정보를 기록
- Domain Prefix 사용: Label Key에 도메인 형태의 접두어를 사용해 식별성과 네임스페이스 명확화
- Selector-Label 매칭 원칙:
- Service나 Deployment의 selector에 지정된 모든 항목은 대상 Pod의 labels에 100% 모두 존재해야 정상 매칭됨
- 설계 구조에 따라 instance 라벨 하나만으로도 유니크한 1:1 또는 N:1 매핑 구현 가능
쿠버네티스를 처음 공부하면서 단순히 추상적인 개념 도식표만 볼 때는 각 리소스가 따로 노는 것 같았지만, 실제 YAML 코드 기반의 라벨(labels)과 셀렉터(selector) 매칭 구조로 관계도를 직접 그려보니 전체적인 아키텍처 흐름이 한눈에 들어왔습니다.
표준화된 오브젝트 규칙만 잘 지켜서 구성해두면, 아무리 많은 애플리케이션과 솔루션이 추가되어도 운영과 자동화 관리가 왜 압도적으로 편해지는지 확실히 체감할 수 있는 계기가 되었습니다.
