인프런 워밍업 - 데브옵스 발자국 2주차
Application 기능으로 k8s 이해 - Probe
애플리케이션이 “정상적으로 살아있는지” 또는 “요청 받을 준비가 되었는지”를 판단하기 위한 기능이다. Kubernetes는 이를 통해 비정상 Pod를 재시작하거나, 로드밸런서 대상에서 제외할 수 있다.
livenessProbe: 컨테이너가 죽었는지 확인. 실패 시 재시작됨.
readinessProbe: 트래픽을 받을 준비가 되었는지 확인. 실패 시 Service 연결에서 제외됨.
startupProbe: 애플리케이션이 느릴 경우, 시작을 충분히 기다려주는 용도.
readinessProbe:
httpGet:
path: /redinessprobe
port: 8080Application 기능으로 k8s 이해 - Configmap, Secret
애플리케이션 설정 값을 코드와 분리하여 외부에서 주입할 수 있게 해주는 Kubernetes 리소스.
ConfigMap: 일반적인 설정값, 파일 내용 등을 담을 수 있음.
Secret: base64 인코딩된 민감 정보 저장용. (실제 보안 기능은 별도 필요)
envFrom:
- configMapRef:
name: app-config✔ ConfigMap을 volumeMount로 마운트해 설정 파일로도 사용하고,
✔ Secret은 database 접속 정보 등을 안전하게 주입하는 데 사용했다.
실습 중에는 base64 인코딩/디코딩을 직접 해보며 Secret이 평문 저장이 아님을 확인함.
Application 기능으로 k8s 이해 - PV/PVC, Deployment, Service, HPA
✅ PV & PVC
PersistentVolume(PV): 클러스터의 실제 스토리지 정보를 정의.
PersistentVolumeClaim(PVC): Pod가 요청하는 스토리지 사용량, 접근 모드 등을 정의.
Pod가 재시작되어도 데이터를 유지할 수 있는 구조 실습 진행.
volumeMounts:
- name: app-data
mountPath: /data
volumes:
- name: app-data
persistentVolumeClaim:
claimName: data-pvc
✅ Deployment
애플리케이션 배포와 업데이트를 자동으로 관리하는 컨트롤러
replicas, rollingUpdate, revisionHistoryLimit 등 다양한 옵션 사용
✅ Service
내부 Pod들을 묶고, 클러스터 내외에서 접근할 수 있는 정적 접근 포인트를 제공
ClusterIP, NodePort, LoadBalancer 등을 실습
✅ HPA (HorizontalPodAutoscaler)
CPU 또는 Memory 사용률에 따라 자동으로 Pod 개수 조절
실습 중에는 metrics-server 설치 여부와 cpu.requests 설정이 없으면 작동하지 않음을 경험
Component 동작으로 k8s 이해
🔸 1. 전체 개요 – kubectl에서 시작되는 Kubernetes 전체 흐름
Kubernetes는 사용자가 작성한 YAML 파일을 kubectl CLI를 통해 kube-apiserver에 전달하는 것으로 시작된다.
kubectl apply -f로 명령을 실행하면 → kube-apiserver는 해당 요청을 받아 etcd에 저장
etcd: 모든 Kubernetes 리소스 상태를 저장하는 Key-Value DB
이후 kube-controller-manager와 kube-scheduler가 이 정보를 읽고, 실행 환경을 조율한다
kubelet은 각 노드에서 API 서버로부터 Pod 생성 요청을 받아, 실제 container runtime(예: containerd)을 통해 컨테이너를 실행시킨다
kube-proxy는 네트워크 통신을 관리하며, 서비스 IP/포트로 들어오는 요청을 올바른 Pod로 전달
모든 구성 요소는 kube-apiserver를 중심으로 유기적으로 연결되어 있으며, 명령 흐름은 “CLI → API 서버 → etcd → 컨트롤러/스케줄러 → 노드”로 이어진다.
🔸 2. Pod 생성 및 Probe 동작 과정
Pod 생성은 다음과 같은 과정을 통해 진행된다:
사용자가 Deployment 또는 직접 Pod를 생성하면 kube-apiserver로 요청됨
kube-controller-manager는 ReplicaSet, Pod 등의 리소스를 실제로 생성
kube-scheduler는 생성된 Pod를 실행시킬 적절한 노드를 선택
선택된 노드의 kubelet은 API 서버로부터 명령을 받아 container runtime에 컨테이너 생성 요청
생성된 컨테이너에 대해 probe(liveness, readiness 등)를 주기적으로 확인하여 정상 상태 여부를 판단
이 과정을 통해 쿠버네티스는 단순히 Pod를 띄우는 것이 아니라, 자동 감시 및 자가 치유(Self-Healing) 기능까지 포함한 전체 생명주기 관리가 가능해진다.
🔸 3. Service 동작 과정
Service는 클러스터 내 Pod 집합에 대한 안정적인 접근 경로를 제공한다.
사용자가 Service 객체를 생성하면 → kube-apiserver를 통해 etcd에 저장
kube-proxy는 각 노드에서 이를 감지하고 iptables 또는 IPVS를 업데이트하여 네트워크 라우팅 설정
외부 사용자 또는 클러스터 내에서 http://service-name:PORT 으로 요청 시,
해당 요청은 iptables를 통해 올바른 Pod로 전달됨
NodePort 타입이면, 외부 IP와 매핑된 포트를 통해 클러스터 외부에서도 접근 가능
즉, 사용자는 Pod IP를 몰라도 Service 이름만으로 항상 안정적으로 API를 호출할 수 있다.
🔸 4. Secret 동작 과정
Secret은 민감한 정보를 쿠버네티스에 저장하고 노출 없이 Pod에 전달하기 위한 리소스이다.
Secret은 etcd에 저장되며, base64 인코딩 상태로 관리됨
Pod는 volume 형태로 Secret을 마운트받아, 컨테이너 내 특정 경로에 파일로 저장
마운트된 파일은 메모리상에 저장되며, kubelet이 주기적으로 Secret의 변경사항을 감지하여 자동으로 업데이트
실습에서는 PostgreSQL 접속 정보를 secret으로 관리하고, /usr/src/myapp/datasource 경로에 마운트하여 애플리케이션에서 사용했다.
🔸 5. HPA(Horizontal Pod Autoscaler) 동작 과정
HPA는 CPU/Memory 사용량에 따라 자동으로 Pod 개수를 조절하는 리소스이다.
metrics-server가 각 노드의 kubelet으로부터 주기적으로 (10초 간격) CPU/메모리 사용량을 수집
kube-controller-manager는 15초 간격으로 HPA 설정을 확인하고, metrics 값을 비교
목표치를 초과하거나 미달하면, 스케일링 명령을 API 서버를 통해 전달
Deployment의 replicas 수가 변경되고, 새로운 Pod가 생성되거나 삭제됨
실습 중에는 metrics-server가 없거나 Pod readiness가 실패하면 HPA가 작동하지 않는 상황도 경험했다. 이를 통해 HPA가 여러 컴포넌트와 밀접하게 연동된다는 점을 체감할 수 있었다.
