목차
🦁멋쟁이사자처럼 백엔드 부트캠프 13기 🦁
TIL 회고 - [76]일차
🚀76일차에는 도커와 쿠버네티스에 대해 더 자세히 학습할 수 있었다.
학습 목표 : 쿠버네티스로 포트포워딩이나 PV, PVC 등을 배워 활용할 수 있어야함
학습 과정 : 회고를 통해 작성
커스텀 deployment 만들기
- kubectl create deployment juunb --image=nginx
➡️기본으로 deployment가 하나 만들어지면 pods도 하나 만들어진다.
deployment로 인해서 pods 생성되고, deployment를 생성했을때 사용했던 이미지로 ,컨테이너가 새로 생성되는것 - kubectl delete pods [pod ID]
pods를 삭제해도, deployment에서는 pods를 가지고 있어야하기에 다시 바로 재생성된다. - kubectl get pods 를 해보면 deployment가 존재하는한 계속해서 pods도 존재하는 것을 확인 가능
(=직원 결근 시 바로 본사에서 보충하는 느낌) - kubectl describe deployment juunb
➡️deployment의 상세정보 출력
포트포워딩 Port-Forwarding
- 만든 컨테이너를 외부로 노출시킬 수 있는 방법
- nginx 브라우저로 확인하기 (포트 포워딩 / NodePort)
nginx는 기본적으로 80번 포트에서 동작
# 1) 만약 방금 삭제했다면 다시 생성
kubectl create deployment hello-kubectl --image=nginx
# 2) Pods 이름 확인
kubectl get pods
# 3) 포트 포워딩
kubectl port-forward <파드이름> 31770:80- hello-kubectl 배포를 했다면 그 위에 Service를 추가
- kubectl expose deployment hello-kubectl --type=NodePort --port=80 --target-port=80
➡️kubectl get svc 로 노출된 NodePort 번호(ex. 31000~32767 범위)를 확인
- 31770으로 접속해본 예
- 포트포워딩 후 localhost:80 에 접속해보면 nginx 출력 확인 가능
서비스 추가
- --target-port : nginx포트, 실제로 동작하고 있는 포트
- --port=80 : 쿠버네티스에서 80으로 이 nginx포트에 접속할 것을 의미
- 실제로 외부에 전달되는 포트는 아니고 외부에 전달되는 포트는 NodePort
NodePort는 kubectl get svc로 노출된 NodePort번호 중 사용이 가능 - kubectl get svc : 서비스 목록 출력
- port(s)에 80:30941/TCP
➡️30941이 실제 외부로 연결된 포트를 의미
로컬호스트에 요청할때는 이 포트번호로 접근해야하는 것 - kubernetes / ClusterIP : 쿠버네티스가 동작할때 기본으로 생성(=자동으로 생성)되는 서비스
➡️ClusterIP : 내부에서 사용하는 IP주소로 “사내전화”같은 느낌, 내부에서 사용하는 망이 하나 만들어져있는 것
- NodePort 포트번호는 쿠버네티스가 자동 배정. 정해주는 범위는 (31000~32767) 내
커스텀 이미지
- 커스텀 이미지를 만들어 여기에 커스텀 index.html을 배치가능
- 디렉토리 새로 생성 (k8s-projects)
- 작업할 디렉토리 생성 (custom-nginx)
- 해당 디렉토리에 이미지 생성
Dockerfile
FROM nginx:alpine
COPY ./myindex.html /usr/share/nginx/html/index.html
myindex.html
<h1>커스텀 이미지와 커스텀 index.html</h1>
<h3>쿠버네티스 실습</h3>
- deployment를 생성하는데 custom-nginx 이름으로 생성하고
- 이미지는 커스텀으로 만들어낸 my-nginx:1.0 을 사용
- target-port는 명시하지 않으면 (생략하면) 앞의 port=80 옵션과 같은 포트로 서비스가 만들어진다.
ex. 32341 외부포트로 만들어졌으므로 접근 가능 - NodePort자체가 외부랑 연결이 가능하도록 해주는 서비스
Pod & Deployment
- 쿠버네티스에서 가장 기본이 되는 리소스가 Pod
- Pod을 단독으로 운영하기보다 Deployment라는 상위 개념을 사용해 Pod을 생성하고 관리
- Pod
➡️컨테이너(들)가 실행되는 최소 배포 단위
보통 하나의 Pod 안에 한 개의 컨테이너가 들어감
Pod 단독으로 관리하기에는 불편하기 때문에 Deployment 같은 상위 오브젝트로 Pod을 관리하는 것이 일반적 - 사이드카(Sidecar)
➡️Kubernetes에서 Pod 내부의 주 컨테이너(Main Container)를 보조 하는 역할을 하는 컨테이너를 의미 - Deployment
➡️Pod를 생성하고 운영(배포, 롤링 업데이트, 스케일링 등)을 자동으로 관리하는 쿠버네티스 리소스
Deployment에 원하는 상태(ex. 3개의 Pod 실행)를 정의하면, 쿠버네티스가 Pod이 항상 그 상태를 유지하도록 관리
hello-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-deployment
spec:
replicas: 1
selector:
matchLabels:
app: hello-nginx
template:
metadata:
labels:
app: hello-nginx
spec:
containers:
- name: nginx-container
image: nginx:alpine
ports:
- containerPort: 80
- spec.replicas: 원하는 Pod 개수 (초기값 1)
- spec.template.spec.containers: 실제 컨테이너 정의 image: nginx:alpine 컨테이너 이미지를 사용
ports.containerPort: 컨테이너 내부에서 80포트 사용 (nginx 기본 포트)
- yaml을 적용하기위해 apply 명령어 사용
scale 업 / 다운
- 원하는 POD개수 조정
- Pod 스케일 업/다운 스케일 업: replicas 수를 늘려서 Pod 개수를 늘리는 작업
서비스 Service
- 쿠버네티스에서 Pod(또는 여러 Pod)에게 네트워크 접근을 제공해주는 중요한 리소스
- Pod은 동적으로 생성되고, IP 주소도 언제든 바뀔 수 있다.
- Pod IP를 직접 사용해 접근하면 관리가 어려우므로 Service가 Pod에
고정된 접근 지점(가상 IP, 포트)을 부여하고Load Balancing까지 담당
Service 종류
- ClusterIP (기본값) : 클러스터 내부에서만 접근 가능한 가상 IP를 할당 외부(인터넷)에서는 접근 불가
- NodePort : 각 노드(Worker Node)의 특정 포트를 개방해 외부에서도 접근 가능하게 함
- LoadBalancer :
클라우드 환경에서 자동으로 로드밸런서를 생성 외부(인터넷) IP를 할당받아 외부 트래픽을 분산 처리
ConfigMap & Secret
- 어떤 애플리케이션이든 환경에 따라 달라지는 설정값 (DB연결정보, 외부 API키 등)은
코드나 컨테이너 이미지와는 분리해서 관리하는 것이 바람직 - 쿠버네티스에서는 분리를 위해 ConfigMap과 Secret 리소스를 제공
- ConfigMap : 비민감한 설정 데이터를 관리
➡️쿠버네티스에서 평문(Plain Text) 설정 정보를 저장하는 리소스
여러 Key:Value 형태로 환경변수를 지정하고, Pod에서 이 값을 읽어 쓸 수 있음 - Secret : 비밀번호, 인증토큰 등 민감 데이터를 안전하게 저장
my-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
WELCOME_MESSAGE: "Hello from ConfigMap!"
APP_MODE: "development"
ConfigMap 사용방법
1. 환경변수로 ConfigMap 사용
- Pod 내부의 컨테이너에서 환경변수로 ConfigMap값을 사용할 수 있음
Pod에 대한 YAML (=my-app.yaml)
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
- name: app-container
image: busybox
command:
[
"/bin/sh",
"-c",
"echo $WELCOME_MESSAGE && echo $APP_MODE && sleep 3600",
]
env:
- name: WELCOME_MESSAGE
valueFrom:
configMapKeyRef:
name: my-config
key: WELCOME_MESSAGE
- name: APP_MODE
valueFrom:
configMapKeyRef:
name: my-config
key: APP_MODE
- name: JUUNB_NAME
valueFrom:
configMapKeyRef:
name: my-config
key: JUUNB_NAME
- 설정 적용 후 echo로 각 매개변수의 값들을 출력 가능
Secret
- 민감 정보(비밀번호, 토큰, API 키 등) 를 저장하기 위한 리소스 내부적으로 base64 인코딩되어 보관
윈도우 Powershell 기준
- 암호화하고싶은 문자열을 넣으면 암호화된 문자열을 반환해줌
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("secretpassword"))
my-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
DB_PASSWORD: "c2VjdXJldHBhc3N3b3Jk" # base64 인코딩된 문자열
- data: 인코딩 된 값을 여러개 넣어줄수도 있다.
DB_PASSWORD: “…”
TEST: “…”
MY_NAME: “…” 등등
볼륨 Volume
- 쿠버네티스의 Pod와 컨테이너는 기본적으로 휘발성 스토리지를 사용
- ⚠️ Pod이 재시작되거나 새로 생성·삭제되는 과정에서 컨테이너 내부 데이터가 사라짐
✅이때 볼륨(Volume) 을 사용하면 데이터 영속화(Persistence) 가 가능해지거나,
여러 컨테이너가 공유 스토리지 사용가능
볼륨의 종류
- Ephemeral Volume(일회성 볼륨)
➡️Pod이 죽으면 데이터도 함께 사라지는 일시적 볼륨 (ex. emptyDir, configMap/secret 볼륨 등) - Persistent Volume (PV) + Persistent Volume Claim (PVC)
➡️영구적인 스토리지를 쿠버네티스에 등록(PV)하고,
사용자는 PVC를 통해 그 스토리지를 청구(Claim)해서 Pod에 연결
⭐Pod이 삭제되어도, PVC/PV가 유지되는 한 데이터가 보존됨 - Persistent Volume(PV) : 미리 등록해놓은공간 (준비해놓은공간)
- Persistent Volume Claim (PVC) : 공간을 요청하는 개념
- 파일들을 생성하고, deployment를 내렸다가 다시 올려도 pv, pvc를 삭제하지 않는한
이 데이터들은 남아있다는 것 알 수 있음 - hostPath: Pod가 실행되는 노드의 로컬 파일 시스템의 특정 경로를 PV로 제공
➡️따라서 데이터는 파드가 실행되었던 특정 노드의 해당 경로에 저장 - 데이터 유지 원리:
1) PV 생성: hostPath 타입의 PV를 생성할 때, 특정 노드의 로컬 파일 시스템 경로를 지정
2) PVC 생성: PVC를 생성하고, 이 PVC가 생성된 PV와 바인딩
3) Pods 설정: Deployment의 파드 템플릿에서 PVC를 볼륨으로 마운트하고,
컨테이너 내의 특정 경로에 해당 볼륨을 연결
4) 파일 생성: 파드 내의 컨테이너에서 마운트된 경로에 파일을 생성하면,
실제로는 PV가 가리키는 노드의 로컬 파일 시스템에 파일이 저장
5) Deployment 삭제 및 재생성: Deployment를 삭제하면 해당 파드도 삭제되지만,
PV와 PVC는 기본적으로 삭제되지 않고 유지
➡️다시 Deployment를 생성하면, 쿠버네티스는 기존 PVC를 만족하는 PV를 찾아 다시 파드에 연결하려고 시도
❓쿠버네티스 활용법
- 개발과 운영의 협업 강화 (DevOps):
➡️도커 이미지라는 표준화된 배포 단위를 통해 개발자는 개발 환경과 동일한 환경을 운영팀에 제공할 수 있어
배포 과정에서의 오류를 줄이고 협업 효율성을 높임 - 클라우드 환경과의 통합 용이성: 대부분의 클라우드 플랫폼에서 쿠버네티스 서비스를 제공하며,
도커 컨테이너를 기반으로 애플리케이션을 구축하면 클라우드 환경으로의 이전 및 확장이 용이
- 쿠버네티스 활용 흐름:
1) 도커를 사용하여 웹 서버 애플리케이션과 필요한 환경을 컨테이너 이미지로 만듦
2) 쿠버네티스 Deployment를 설정하여 원하는 웹 서버(Pods)의 개수를 지정
3) 쿠버네티스 서비스 설정을 통해 외부 트래픽을 여러 웹 서버 Pods에 자동으로 분산
4) 만약 웹 서버 파드 중 하나에 문제가 발생하면, 쿠버네티스는 자동으로 새로운 Pods를 생성하여 서비스를 유지
5) 트래픽이 증가하면 Deployment 설정을 변경하여 웹 서버 Pods의 개수를 쉽게 늘릴 수 있음
6) 데이터를 영구적으로 저장해야 한다면 PV와 PVC를 활용하여 웹 서버 Pods가 재시작되거나
다른 노드로 이동하더라도 데이터 손실 없이 서비스를 제공 가능
정리하자면
✅쿠버네티스는 복잡한 분산 시스템을 효율적으로 관리하고, 애플리케이션의 안정성과 확장성을 크게 향상시키는 도구
🚀회고 결과 :
쿠버네티스에 대하여 더 배우면서 포트포워딩과 PV, PVC까지 내부 개념에 대해 공부할 수 있었다.
docker로 이미지를 만들고 run으로 실행하는 과정을 넘어 kubectl 명령어를 활용하여
deployment, pods 등을 생성하는 것까지 연습해볼 수 있었다.
향후 계획 :
- 쿠버네티스에 react 프로젝트 올리는 연습
'Recording > 멋쟁이사자처럼 BE 13기' 카테고리의 다른 글
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_78일차_"Jenkins, Github Actions" (0) | 2025.04.02 |
|---|---|
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_77일차_"빌드 자동화" (0) | 2025.04.01 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_75일차_"프로메테우스 + 그라파나" (0) | 2025.03.27 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_74일차_"Docker 로드밸런싱" (0) | 2025.03.26 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_73일차_"Docker 이미지" (0) | 2025.03.25 |
🦁멋쟁이사자처럼 백엔드 부트캠프 13기 🦁
TIL 회고 - [76]일차
🚀76일차에는 도커와 쿠버네티스에 대해 더 자세히 학습할 수 있었다.
학습 목표 : 쿠버네티스로 포트포워딩이나 PV, PVC 등을 배워 활용할 수 있어야함
학습 과정 : 회고를 통해 작성
커스텀 deployment 만들기
- kubectl create deployment juunb --image=nginx
➡️기본으로 deployment가 하나 만들어지면 pods도 하나 만들어진다.
deployment로 인해서 pods 생성되고, deployment를 생성했을때 사용했던 이미지로 ,컨테이너가 새로 생성되는것 - kubectl delete pods [pod ID]
pods를 삭제해도, deployment에서는 pods를 가지고 있어야하기에 다시 바로 재생성된다. - kubectl get pods 를 해보면 deployment가 존재하는한 계속해서 pods도 존재하는 것을 확인 가능
(=직원 결근 시 바로 본사에서 보충하는 느낌) - kubectl describe deployment juunb
➡️deployment의 상세정보 출력
포트포워딩 Port-Forwarding
- 만든 컨테이너를 외부로 노출시킬 수 있는 방법
- nginx 브라우저로 확인하기 (포트 포워딩 / NodePort)
nginx는 기본적으로 80번 포트에서 동작
# 1) 만약 방금 삭제했다면 다시 생성
kubectl create deployment hello-kubectl --image=nginx
# 2) Pods 이름 확인
kubectl get pods
# 3) 포트 포워딩
kubectl port-forward <파드이름> 31770:80- hello-kubectl 배포를 했다면 그 위에 Service를 추가
- kubectl expose deployment hello-kubectl --type=NodePort --port=80 --target-port=80
➡️kubectl get svc 로 노출된 NodePort 번호(ex. 31000~32767 범위)를 확인
- 31770으로 접속해본 예
- 포트포워딩 후 localhost:80 에 접속해보면 nginx 출력 확인 가능
서비스 추가
- --target-port : nginx포트, 실제로 동작하고 있는 포트
- --port=80 : 쿠버네티스에서 80으로 이 nginx포트에 접속할 것을 의미
- 실제로 외부에 전달되는 포트는 아니고 외부에 전달되는 포트는 NodePort
NodePort는 kubectl get svc로 노출된 NodePort번호 중 사용이 가능 - kubectl get svc : 서비스 목록 출력
- port(s)에 80:30941/TCP
➡️30941이 실제 외부로 연결된 포트를 의미
로컬호스트에 요청할때는 이 포트번호로 접근해야하는 것 - kubernetes / ClusterIP : 쿠버네티스가 동작할때 기본으로 생성(=자동으로 생성)되는 서비스
➡️ClusterIP : 내부에서 사용하는 IP주소로 “사내전화”같은 느낌, 내부에서 사용하는 망이 하나 만들어져있는 것
- NodePort 포트번호는 쿠버네티스가 자동 배정. 정해주는 범위는 (31000~32767) 내
커스텀 이미지
- 커스텀 이미지를 만들어 여기에 커스텀 index.html을 배치가능
- 디렉토리 새로 생성 (k8s-projects)
- 작업할 디렉토리 생성 (custom-nginx)
- 해당 디렉토리에 이미지 생성
Dockerfile
FROM nginx:alpine
COPY ./myindex.html /usr/share/nginx/html/index.html
myindex.html
<h1>커스텀 이미지와 커스텀 index.html</h1>
<h3>쿠버네티스 실습</h3>
- deployment를 생성하는데 custom-nginx 이름으로 생성하고
- 이미지는 커스텀으로 만들어낸 my-nginx:1.0 을 사용
- target-port는 명시하지 않으면 (생략하면) 앞의 port=80 옵션과 같은 포트로 서비스가 만들어진다.
ex. 32341 외부포트로 만들어졌으므로 접근 가능 - NodePort자체가 외부랑 연결이 가능하도록 해주는 서비스
Pod & Deployment
- 쿠버네티스에서 가장 기본이 되는 리소스가 Pod
- Pod을 단독으로 운영하기보다 Deployment라는 상위 개념을 사용해 Pod을 생성하고 관리
- Pod
➡️컨테이너(들)가 실행되는 최소 배포 단위
보통 하나의 Pod 안에 한 개의 컨테이너가 들어감
Pod 단독으로 관리하기에는 불편하기 때문에 Deployment 같은 상위 오브젝트로 Pod을 관리하는 것이 일반적 - 사이드카(Sidecar)
➡️Kubernetes에서 Pod 내부의 주 컨테이너(Main Container)를 보조 하는 역할을 하는 컨테이너를 의미 - Deployment
➡️Pod를 생성하고 운영(배포, 롤링 업데이트, 스케일링 등)을 자동으로 관리하는 쿠버네티스 리소스
Deployment에 원하는 상태(ex. 3개의 Pod 실행)를 정의하면, 쿠버네티스가 Pod이 항상 그 상태를 유지하도록 관리
hello-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: hello-deployment
spec:
replicas: 1
selector:
matchLabels:
app: hello-nginx
template:
metadata:
labels:
app: hello-nginx
spec:
containers:
- name: nginx-container
image: nginx:alpine
ports:
- containerPort: 80
- spec.replicas: 원하는 Pod 개수 (초기값 1)
- spec.template.spec.containers: 실제 컨테이너 정의 image: nginx:alpine 컨테이너 이미지를 사용
ports.containerPort: 컨테이너 내부에서 80포트 사용 (nginx 기본 포트)
- yaml을 적용하기위해 apply 명령어 사용
scale 업 / 다운
- 원하는 POD개수 조정
- Pod 스케일 업/다운 스케일 업: replicas 수를 늘려서 Pod 개수를 늘리는 작업
서비스 Service
- 쿠버네티스에서 Pod(또는 여러 Pod)에게 네트워크 접근을 제공해주는 중요한 리소스
- Pod은 동적으로 생성되고, IP 주소도 언제든 바뀔 수 있다.
- Pod IP를 직접 사용해 접근하면 관리가 어려우므로 Service가 Pod에
고정된 접근 지점(가상 IP, 포트)을 부여하고Load Balancing까지 담당
Service 종류
- ClusterIP (기본값) : 클러스터 내부에서만 접근 가능한 가상 IP를 할당 외부(인터넷)에서는 접근 불가
- NodePort : 각 노드(Worker Node)의 특정 포트를 개방해 외부에서도 접근 가능하게 함
- LoadBalancer :
클라우드 환경에서 자동으로 로드밸런서를 생성 외부(인터넷) IP를 할당받아 외부 트래픽을 분산 처리
ConfigMap & Secret
- 어떤 애플리케이션이든 환경에 따라 달라지는 설정값 (DB연결정보, 외부 API키 등)은
코드나 컨테이너 이미지와는 분리해서 관리하는 것이 바람직 - 쿠버네티스에서는 분리를 위해 ConfigMap과 Secret 리소스를 제공
- ConfigMap : 비민감한 설정 데이터를 관리
➡️쿠버네티스에서 평문(Plain Text) 설정 정보를 저장하는 리소스
여러 Key:Value 형태로 환경변수를 지정하고, Pod에서 이 값을 읽어 쓸 수 있음 - Secret : 비밀번호, 인증토큰 등 민감 데이터를 안전하게 저장
my-configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
WELCOME_MESSAGE: "Hello from ConfigMap!"
APP_MODE: "development"
ConfigMap 사용방법
1. 환경변수로 ConfigMap 사용
- Pod 내부의 컨테이너에서 환경변수로 ConfigMap값을 사용할 수 있음
Pod에 대한 YAML (=my-app.yaml)
apiVersion: v1
kind: Pod
metadata:
name: my-app
spec:
containers:
- name: app-container
image: busybox
command:
[
"/bin/sh",
"-c",
"echo $WELCOME_MESSAGE && echo $APP_MODE && sleep 3600",
]
env:
- name: WELCOME_MESSAGE
valueFrom:
configMapKeyRef:
name: my-config
key: WELCOME_MESSAGE
- name: APP_MODE
valueFrom:
configMapKeyRef:
name: my-config
key: APP_MODE
- name: JUUNB_NAME
valueFrom:
configMapKeyRef:
name: my-config
key: JUUNB_NAME
- 설정 적용 후 echo로 각 매개변수의 값들을 출력 가능
Secret
- 민감 정보(비밀번호, 토큰, API 키 등) 를 저장하기 위한 리소스 내부적으로 base64 인코딩되어 보관
윈도우 Powershell 기준
- 암호화하고싶은 문자열을 넣으면 암호화된 문자열을 반환해줌
[Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("secretpassword"))
my-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
DB_PASSWORD: "c2VjdXJldHBhc3N3b3Jk" # base64 인코딩된 문자열
- data: 인코딩 된 값을 여러개 넣어줄수도 있다.
DB_PASSWORD: “…”
TEST: “…”
MY_NAME: “…” 등등
볼륨 Volume
- 쿠버네티스의 Pod와 컨테이너는 기본적으로 휘발성 스토리지를 사용
- ⚠️ Pod이 재시작되거나 새로 생성·삭제되는 과정에서 컨테이너 내부 데이터가 사라짐
✅이때 볼륨(Volume) 을 사용하면 데이터 영속화(Persistence) 가 가능해지거나,
여러 컨테이너가 공유 스토리지 사용가능
볼륨의 종류
- Ephemeral Volume(일회성 볼륨)
➡️Pod이 죽으면 데이터도 함께 사라지는 일시적 볼륨 (ex. emptyDir, configMap/secret 볼륨 등) - Persistent Volume (PV) + Persistent Volume Claim (PVC)
➡️영구적인 스토리지를 쿠버네티스에 등록(PV)하고,
사용자는 PVC를 통해 그 스토리지를 청구(Claim)해서 Pod에 연결
⭐Pod이 삭제되어도, PVC/PV가 유지되는 한 데이터가 보존됨 - Persistent Volume(PV) : 미리 등록해놓은공간 (준비해놓은공간)
- Persistent Volume Claim (PVC) : 공간을 요청하는 개념
- 파일들을 생성하고, deployment를 내렸다가 다시 올려도 pv, pvc를 삭제하지 않는한
이 데이터들은 남아있다는 것 알 수 있음 - hostPath: Pod가 실행되는 노드의 로컬 파일 시스템의 특정 경로를 PV로 제공
➡️따라서 데이터는 파드가 실행되었던 특정 노드의 해당 경로에 저장 - 데이터 유지 원리:
1) PV 생성: hostPath 타입의 PV를 생성할 때, 특정 노드의 로컬 파일 시스템 경로를 지정
2) PVC 생성: PVC를 생성하고, 이 PVC가 생성된 PV와 바인딩
3) Pods 설정: Deployment의 파드 템플릿에서 PVC를 볼륨으로 마운트하고,
컨테이너 내의 특정 경로에 해당 볼륨을 연결
4) 파일 생성: 파드 내의 컨테이너에서 마운트된 경로에 파일을 생성하면,
실제로는 PV가 가리키는 노드의 로컬 파일 시스템에 파일이 저장
5) Deployment 삭제 및 재생성: Deployment를 삭제하면 해당 파드도 삭제되지만,
PV와 PVC는 기본적으로 삭제되지 않고 유지
➡️다시 Deployment를 생성하면, 쿠버네티스는 기존 PVC를 만족하는 PV를 찾아 다시 파드에 연결하려고 시도
❓쿠버네티스 활용법
- 개발과 운영의 협업 강화 (DevOps):
➡️도커 이미지라는 표준화된 배포 단위를 통해 개발자는 개발 환경과 동일한 환경을 운영팀에 제공할 수 있어
배포 과정에서의 오류를 줄이고 협업 효율성을 높임 - 클라우드 환경과의 통합 용이성: 대부분의 클라우드 플랫폼에서 쿠버네티스 서비스를 제공하며,
도커 컨테이너를 기반으로 애플리케이션을 구축하면 클라우드 환경으로의 이전 및 확장이 용이
- 쿠버네티스 활용 흐름:
1) 도커를 사용하여 웹 서버 애플리케이션과 필요한 환경을 컨테이너 이미지로 만듦
2) 쿠버네티스 Deployment를 설정하여 원하는 웹 서버(Pods)의 개수를 지정
3) 쿠버네티스 서비스 설정을 통해 외부 트래픽을 여러 웹 서버 Pods에 자동으로 분산
4) 만약 웹 서버 파드 중 하나에 문제가 발생하면, 쿠버네티스는 자동으로 새로운 Pods를 생성하여 서비스를 유지
5) 트래픽이 증가하면 Deployment 설정을 변경하여 웹 서버 Pods의 개수를 쉽게 늘릴 수 있음
6) 데이터를 영구적으로 저장해야 한다면 PV와 PVC를 활용하여 웹 서버 Pods가 재시작되거나
다른 노드로 이동하더라도 데이터 손실 없이 서비스를 제공 가능
정리하자면
✅쿠버네티스는 복잡한 분산 시스템을 효율적으로 관리하고, 애플리케이션의 안정성과 확장성을 크게 향상시키는 도구
🚀회고 결과 :
쿠버네티스에 대하여 더 배우면서 포트포워딩과 PV, PVC까지 내부 개념에 대해 공부할 수 있었다.
docker로 이미지를 만들고 run으로 실행하는 과정을 넘어 kubectl 명령어를 활용하여
deployment, pods 등을 생성하는 것까지 연습해볼 수 있었다.
향후 계획 :
- 쿠버네티스에 react 프로젝트 올리는 연습
'Recording > 멋쟁이사자처럼 BE 13기' 카테고리의 다른 글
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_78일차_"Jenkins, Github Actions" (0) | 2025.04.02 |
|---|---|
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_77일차_"빌드 자동화" (0) | 2025.04.01 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_75일차_"프로메테우스 + 그라파나" (0) | 2025.03.27 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_74일차_"Docker 로드밸런싱" (0) | 2025.03.26 |
| [멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_73일차_"Docker 이미지" (0) | 2025.03.25 |
