컨테이너를 다루는 표준 아키텍처, 쿠버네티스
그룹과 각 노드(Host)를 등록해줍니다.
각 노드를 더블클릭해서 SSH 접속합니다.
노드들에 접속 한 후 kubectl get nodes
로 정상적으로 접속되었는지 확인합니다.
이제 SSH 연결 문제가 해결되었으니 다시 오브젝트 얘기로 돌아가봅시다!
쿠버네티스의 모든 포스팅은 포스팅 순서대로 차례대로 진행해주셔서 막힘없이 실습할 수 있습니다. 저번 포스팅에서 설치, 세팅해둔 설정 등이 이어서 쓰입니다.
하루만에 모든 실습을 진행하기 힘들기 때문에, 중간에 실습을 중단하고 나중에 다시 쿠버네티스를 실행한다면 VirtualBox에서 각 노드들을 헤드리스로 시작해주시고, SSH 클라이언트(Terminus 등)에서 다시 터미널에 접속해주시면 됩니다 :)
지금까지 파드를 안정적으로 사용하는 방법을 배우며 파드를 관리하는 여러 기능이 포함된 '디플로이먼트 오브젝트'를 사용해 봤습니다!(앞선 포스팅을 참고하세요)
디플로이먼트 외에도 용도에 따라 사용할 수 있는 다양한 오브젝트가 이미 정의돼 있습니다.
예를 들면 데몬셋, 컨피그맵, PV/PVC, 스테이트풀셋 등이 있습니다.
쿠버네티스의 발전에 따라 사용되는 오브젝트는 계속 변하겠지만, 현존하는 다양한 오브젝트를 알아둔다면 쿠버네티스를 활용하고 추가로 개발되는 오브젝트에도 쉽게 적응할 수 있을겁니다!
kubectl get pods -n metallb-system -o wide
를 실행해 현재 MetalLB의 스피커가 각 노드에 분포돼 있는 상태를 확인합니다.
워커 노드를 1개 늘립니다. 호스트 컴퓨터의 깃 클론or압축해제한 디텍토리 경로/_Book_k8sInfra-main/ch3/3.1.3
경로로 이동해 Vagrantfile의 5번쨰 줄에 있는 N 인자의 값을 3에서 4로 수정하면 됩니다.
호스트 컴퓨터의 명령 창에서 깃 클론or압축해제한 디텍토리 경로/_Book_k8sInfra-main/ch3/3.1.3
으로 이동해서 vagrant up w4-k8s
를 실행합니다. 새로운 워커 노드를 추가하는 명령입니다.
vagrant up w4-k8s
w4-k8s 노드 추가가 완료되면 m-k8s(마스터 노드)에서 변화를 확인합니다.
kubectl get pods -n metallb-system -o wide -w
-w
옵션은 watch의 약자로 오브젝트 상태에 변화가 감지되면 해당 변화를 출력합니다. 리눅스에서 tail -f
와 비슷한 역할입니다.Ctrl+C
로 명령을 중지하고 나옵니다. (데몬셋인 speaker-f4kfs가 2m35s 전에 새로 생성되었으며 NODE w4-k8s에 할당된 것을 볼 수 있습니다.)자동으로 추가된 노드에 설치된 speaker가 데몬셋이 맞는지 확인합니다.
kubectl get pods speaker-f4kfs -o yaml -n metallb-system
추가된 워커 노드에서 데몬셋이 정삭적으로 설치되고 작동하는 것을 확인해봤습니다 :)
ConfigMap은 이름 그대로 설정(config)를 목적으로 사용하는 오브젝트입니다. MetalLB를 구성할 때 이미 컨피그맵을 사용해봤죠?
그런데 인그레스에서는 설정을 위해 오브젝트를 인그레스로 선언했는데, 왜 MetalLB에서는 컨피그맵을 사용했을까요?
명확하게 규정하기는 어렵지만, 인그레스는 오브젝트가 인그레스로 지정돼 있지만, MetalLB는 프로젝트 타입으로 정해진 오브젝트가 없어서 범용 설정으로 사용되는 컨피그맵을 지정했습니다.
컨피그맵으로 작성된 MetalLB의 IP 설정을 변경해봅시다!
테스트용 디플로이먼트를 cfgmap이라는 이름으로 생성합니다.
kubectl create deployment cfgmap --image=sysnet4admin/echo-hname
cfgmap을 로드밸런서(MetalLB)를 통해 노출하고 이름은 cfgmap-svc로 지정합니다.
kubectl expose deployment cfgmap --type=LoadBalancer --name=cfgmap-svc --port=80
생성된 서비스의 EXTERNAL-IP를 확인합니다.
kubectl get services
192.168.1.11
이군요!사전에 구성돼 있는 컨피그맵의 기존 IP(192.168.1.11~192.168.1.13)를 sed 명령을 사용해 192.168.1.21~192.168.1.23으로 변경해봅시다.
cat ~/_Book_k8sInfra/ch3/3.4.2/metallb-l2config.yaml | grep 192.
sed -i 's/11/21/;s/13/23/' ~/_Book_k8sInfra/ch3/3.4.2/metallb-l2config.yaml
cat ~/_Book_k8sInfra/ch3/3.4.2/metallb-l2config.yaml | grep 192.
컨피그맵의 설정 파일(metallb-l2config.yaml)에 apply를 실행해 변경된 설정을 적용합니다!
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.2/metallb-l2config.yaml
MetalLB와 관련된 모든 파드를 삭제합니다. 삭제하고 나면 kubelet에서 해당 파드를 자동으로 모두 다시 생성합니다. --all
은 파드를 모두 삭제하는 옵션입니다.
kubectl delete pods --all -n metallb-system
새로 생성된 MetalLB의 파드들을 확인합니다.
kubectl get pods -n metallb-system
기존에 노출한 MetalLB 서비스(cfgmap-svc)를 삭제(delete)하고 동일한 이름으로 다시 생성해 새로운 컨피그맵을 적용한 서비스가 올라오게 합니다.
kubectl delete service cfgmap-svc
kubectl expose deployment cfgmap --type=LoadBalancer --name=cfgmap-svc --port=80
변경한 설정이 적용돼 새로운 MetalLB 서비스의 IP와 port가 바뀌었는지 확인합니다.
kubectl get services
호스트 브라우저에서 192.168.1.21로 접속해 파드의 이름이 화면에 표시되는지 확인합니다.
파드 이름이 표시되므로 설정 변경이 성공한 것으로 확인됩니다. 다음 테스트를 위해 생성한 디플로이먼트와 서비스를 삭제합니다.
kubectl delete deployment cfgmap
kubectl delete service cfgmap-svc
이제 파드가 언제라도 생성되고 지워진다는 것을 충분히 경험해봤습니다.
그런데 때때로 파드에서 생성한 내용을 기록하고 보관하거나 모든 파드가 동일한 설정 값을 유지하고 관리하기 위해, 공유된 볼륨으로부터 공통된 설정을 가지고 올 수 있도록 설계해야 할 때도 있습니다.
쿠버네티스는 이런 경우를 위해 다음과 같은 목적으로 다양한 형태의 볼륨을 제공합니다!
다양한 쿠버네티스 볼륨 스토리지 중에서 PV와 PVC를 알아봅시다.
PV와 PVC의 관계를 이해한다면 다른 볼륨 스토리지도 쉽게 이해할 수 있습니다!
쿠버네티스는 필요할 때 PVC(PersistentVolumeClaim, 지속적으로 사용 가능한 볼륨 요청)를 요청해 사용합니다.
PVC를 사용하려면 PV(PersistentVolume, 지속적으로 사용 가능한 볼륨)로 볼륨을 선언해야 합니다.
간단하게 PV는 볼륨을 사용할 수 있게 준비하는 단계이고, PVC는 준비된 볼륨에서 일정 공간을 할당받는 것입니다.
비유하면 PV는 관리자가 피자를 굽는 것이고, PVC는 사용자가 원하는 만큼 피자를 접시에 담아 가져오는 것입니다.
그러면 가장 구현하기 쉬운 NFS 볼륨 타입으로 PV와 PVC를 생성하고 파드에 마운트해 보면서 실제로 어떻게 작동하는지 확인해봅시다!
PV로 선언할 볼륨을 만들기 위해 NFS 서버를 마스터 노드에 구성합니다.
/nfs_shared
로 생성하고, 해당 디렉토리를 NFS로 받아들일 IP 영역은 192.168.1.0/24로 정합니다./etc/exports
에 기록합니다. 옵션에서 rw
는 읽기/쓰기, sync
는 쓰기작업 동기화, no_root_squash
는 root 계정 사용을 의미합니다.mkdir /nfs_shared
echo '/nfs_shared 192.168.1.0/24(rw,sync,no_root_squash)' >> /etc/exports
해당 내용을 시스템에 적용해 NFS 서버를 활성화하고 다음에 시작할 때도 자동으로 적용되도록 합니다.
systemctl enable --now nfs
다음 경로에 있는 오브젝트 스펙을 실행해 PV를 생성합니다.
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/nfs-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv
spec:
# storage는 실제로 사용하는 용량을 제한하는 것이 아니라 쓸 수 있는 양을 레이블로 붙이는 것과 같습니다. 이는 현재 스토리지가 단순히 NFS로 설정돼서 그렇습니다. 용량을 제한하는 방법은 아래서 자세히 설명합니다.
capacity:
storage: 100Mi
# PV를 어떤 방식으로 사용할지 정의하는 부분입니다. ReadWriteMany는 여러 개의 노드가 읽고 쓸 수 있도록 마운트하는 옵션입니다. 이외에도 ReadWriteOnce(하나의 노드에서만 볼륨을 읽고 쓸 수 있게 마운트)와 ReadOnlyMany(여러 개의 노드가 읽기만 하도록 마운트) 옵션이 있습니다.
accessModes:
- ReadWriteMany
# PV가 제거됐을 때 작동하는 방법을 정의하는 것으로, 여기서는 유지는 Retain을 사용합니다. 이 외에도 Delete(삭제), Recycle(재활용, Deprecated) 옵션이 있습니다.
persistentVolumeReclaimPolicy: Retain
# NFS 서버의 연결 위치에 대한 설정입니다.
nfs:
server: 192.168.1.10
path: /nfs_shared
실행된 PV의 상태가 Avaliable(사용 가능)임을 확인합니다.
kubectl get pv
다음 경로에서 오브젝트 스펙을 실행해 PVC를 생성합니다.
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 10Mi
생성된 PVC를 kubectl get pvc
로 확인합니다. 여기서 두 가지를 살펴봐야 합니다.
PV의 상태도 Bound로 바뀌었음을 확인합니다.
kubectl get pv
생성한 PVC를 볼륨으로 사용하는 디플로이먼트 오브젝트 스펙을 배포합니다.
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-pvc-deploy
spec:
replicas: 4
selector:
matchLabels:
app: nfs-pvc-deploy
template:
metadata:
labels:
app: nfs-pvc-deploy
spec:
# audit-trail 이미지를 가지고 옵니다. 해당 컨테이너 이미지는 요청을 처리할 때마다 접속 정보를 로그로 기록합니다.
containers:
- name: audit-trail
image: sysnet4admin/audit-trail
# 볼륨이 마운트될 위치(/audit)을 지정합니다.
volumeMounts:
- name: nfs-vol
mountPath: /audit
# PVC로 생성된 볼륨을 마운트하기 위해서 nfs-pvc라는 이름을 사용합니다.
volumes:
- name: nfs-vol
persistentVolumeClaim:
claimName: nfs-pvc
생성된 파드를 확인합니다.
kubectl get pods
생성한 파드 중 하나에 exec로 접속합니다.
kubectl exec -it nfs-pvc-deploy-5fd9876c46-cxblc -- /bin/bash
df -h
를 실행해 PVC의 마운트 상태를 확인합니다.
m-k8s 세션을 더블클릭하여 한번 더 connect하고(m-k8s(1)이 만들어집니다) audit-trail
컨테이너의 기능을 테스트합니다. 외부에서 파드(nfs-pv-deploy)에 접속할 수 있도록 expose로 로드밸런서 서비스를 생성합니다.
kubectl expose deployment nfs-pvc-deploy --type=LoadBalancer --name=nfs-pvc-deploy-svc --port=80
생성한 로드밸런서 서비스의 IP를 확인합니다.
kubectl get services
호스트 브라우저를 엽니다. 192.168.1.21에 접속해 파드 이름과 IP가 표시되는지 확인합니다.
exec를 통해 접속한 파드에서 ls /audit 명령을 실행해 접속 기록 파일이 남았는지 확인합니다. cat으로 해당 파일의 내용도 함께 확인합니다.
ls /audit
cat /audit/audit_nfs-pvc-deploy-5fd9876c46-nhrnm.log
마스터 노드(m-k8s(1))에서 scale 명령으로 파드를 4개에서 8개로 증가시킵니다.
kubectl scale deployment nfs-pvc-deploy --replicas=8
생성된 파드를 확인합니다.
kubectl get pods
최근에 증가한 4개의 파드 중 1개를 선택해 exec로 접속하고 기록된 audit 로그가 동일한지 확인합니다.(동일합니다)
kubectl exec -it nfs-pvc-deploy-5fd9876c46-bf6pb -- /bin/bash
cat /audit/audit_nfs-pvc-deploy-5fd9876c46-nhrnm.log
아까와 다른 브라우저창에서 192.168.1.21로 접속해 다른 파드 이름과 IP가 표시되는지 확인합니다.
exec로 접속한 파드(최근 접속 파드)에서 ls /audit
을 실행해 새로 추가된 audit 로그를 확인합니다. 그리고 cat으로 기록된 내용도 함께 확인합니다.
ls /audit
cat /audit/audit_nfs-pvc-deploy-5fd9876c46-bf6pb.log
기존에 접속한 파드에서도 동일한 로그가 audit에 기록돼 있는지 확인합니다.
ls /audit
사용자가 관리자와 동일한 단일 시스템이라면 PV와 PVC를 사용할 필요가 없습니다. 따라서 단순히 볼륨을 마운트하는지 확인하고 넘어가겠습니다.
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/nfs-ip.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-ip
spec:
replicas: 4
selector:
matchLabels:
app: nfs-ip
template:
metadata:
labels:
app: nfs-ip
spec:
containers:
- name: audit-trail
image: sysnet4admin/audit-trail
volumeMounts:
- name: nfs-vol
mountPath: /audit
# PV/PVC를 거치지않고 바로 NFS 서버로 접속하기
volumes:
- name: nfs-vol
nfs:
server: 192.168.1.10
path: /nfs_shared
새로 배포된 파드를 확인하고 그중 하나에 exec로 접속합니다.
kubectl get pods
kubectl exec -it nfs-ip-7789f445b7-4wzvc -- /bin/bash
접속한 파드에서 ls /audit
을 실행해 동일한 NFS 볼륨을 바라보고 있음을 확인합니다.
ls /audit
다음 진행을 위해 설치한 PV와 PVC를 제외한 나머지인 파드와 서비스를 삭제합니다.
exit
kubectl delete deployment nfs-pvc-deploy
kubectl delete deployment nfs-ip
kubectl delete service nfs-pvc-deploy-svc
실제로 PV와 PVC를 구성해서 PV와 PVC를 구성하는 주체가 관리자와 사용자로 나뉜다는 것을 확인했습니다.
또한 관리자/사용자가 나뉘어 있지 않다면 굳이 PV와 PVC를 통하지 않고 바로 파드에 공유가 가능한 NFS 볼륨을 마운트할 수 있음을 확인했습니다!
볼륨 용량을 제한하는 방법은 크게 두 가지가 있습니다.
첫 번째는 PVC로 PV에 요청되는 용량을 제한하는 것이고,
두 번째는 스토리지 리소스에 대한 사용량을 제한하는 것입니다.
먼저 PVC로 PV에 요청되는 용량을 제한하는 방법을 살펴봅시다!
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/limits-pvc.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: storagelimits
spec:
# 용량 제한하기
limits:
- type: PersistentVolumeClaim
max:
storage: 5Mi
min:
storage: 1Mi
kubectl delete pv nfs-pv
kubectl delete pvc nfs-pvc
PV와 PVC를 새로 생성하고 PVC가 최대 용량 제한(5Mi)에 걸려 수행되지 못하는지 확인합니다.
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/nfs-pv.yaml
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc.yaml
용량 제한 설정을 삭제합니다
kubectl delete limitranges storagelimits
이제 두 번째 방법인 스토리지 리소스에 대한 총 용량을 제한하는 방법도 살펴보겠습니다.
총 누적 사용량을 제한하기 위해 다음 오브젝트 스펙을 적용합니다.
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/quota-pvc.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: storagequota
spec:
hard:
persistentvolumeclaims: "5"
requests.storage: "25Mi"
지금까지 배운 내용을 활용해 PV를 3개(100Mi)의 상태를 만들고 오프젝트 스펙을 적용합니다(과제 : 스스로 작성해보세요).
kubectl delete pv nfs-pv
kubectl get pv
그런 다음 PVC 3개(10Mi)를 요청해 25Mi 제한으로 더 이상 PVC가 수행되지 못하는지 확인합니다.
cp ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc.yaml ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc1.yaml
cp ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc.yaml ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc2.yaml
vim ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc1.yaml
vim ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc2.yaml
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc.yaml
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc1.yaml
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.3/nfs-pvc2.yaml
PVC를 생성하기 위해 설정한 리소스 제한을 삭제합니다.
kubectl delete resourcequotas storagequota
과도하게 생성한 PV(nfs-pv1, nfs-pv2)와 PVC(nfs-pvc1)을 삭제합니다. 이때 Bound(PV와 PVC가 연결된 대상)의 상대를 잘 보고 삭제해야 합니다. Bound는 기본적으로 생성된 시간에 맞춰 연결됩니다.
kubectl get pvc
명령을 실행하면 Bound된 볼륨이 nfs-pv1, nfs-pv2로 잡혀있는게 보이시죠? 우리가 원하는 바가 아닙니다. 그래서 두 pvc를 모두 삭제해야겠습니다.kubectl delete pvc nfs-pvc
kubectl delete pvc nfs-pvc1
kubectl get pv
kubectl delete pv nfs-pv1
kubectl delete pv nfs-pv2
지금까지는 파드가 replicas에 선언된 만큼 무작위로 생성될 뿐이었습니다.
그런데 파드가 만들어지는 이름가 순서를 예측해야 할 때가 있습니다.
이전 실습에서 직접 오브젝트 스펙을 작성해보신 분이라면 PV 오브젝트 스펙 파일에 단순히 replicas를 넣는다고 작동하지 않는다는 점을 깨달으셨을 겁니다.
스테이트풀셋은 주로 레디스(Redis), 주키퍼(Zookeeper), 카산드라(Cassandra), 몽고DB(MongoDB) 등의 마스터-슬레이브 구조 시스템에서 필요합니다.
PV와 PVC도 1:1도 마스터-슬레이브 구조를 갖습니다.(아직 제 개념이 확실하지 않아 추후에 자세한 내용을 알게되거나, 해당 내용이 틀리면 수정하도록 하겠습니다.)
스테이트풀셋은 volumeClaimTemplates 기능을 사용해 PVC를 자동으로 생성할 수 있고, 각 파드가 순서대로 생성되기 때문에 고정된 이름, 볼륨, 설정 등을 가질 수 있습니다.
그래서 StatefulSet(이전 상태를 기억하는 세트)이라는 이름을 사용합니다.
다만, 효율성 면에서 좋은 구조가 아니므로 요구 사항에 맞게 적절히 사용하는 것이 좋습니다!
스테이트풀셋을 직접 만들어 보면서 생성 과정을 살펴보고 어떤 형태의 고정 값을 가지는지 알아보겠습니다.
참고로 스테이트풀셋은 디플로이먼트와 형제나 다름없는 구조라 디플로이먼트에서 오브젝트 종류를 변경하면 바로 실습할 수 있습니다.
PV와 PVC는 앞에서 이미 생성했으므로 바로 스테이프풀셋의 오브젝트 스펙을 적용합니다.
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.4/nfs-pvc-sts.yaml
serviceName
이 추가된 것 이외에는 앞의 nfs-pvc-deployment.yaml
코드와 동일합니다.apiVersion: apps/v1
kind: StatefulSet
metadata:
name: nfs-pvc-sts
spec:
replicas: 4
# statefulset을 추가합니다
serviceName: sts-svc-domain #statefulset need it
selector:
matchLabels:
app: nfs-pvc-sts
template:
metadata:
labels:
app: nfs-pvc-sts
spec:
containers:
- name: audit-trail
image: sysnet4admin/audit-trail
volumeMounts:
- name: nfs-vol # same name of volumes's name
mountPath: /audit
volumes:
- name: nfs-vol
persistentVolumeClaim:
claimName: nfs-pvc
파드가 생성되는지 확인합니다. 다음과 같이 순서대로 하나씩 생성하는 것을 볼 수 있습니다.
kubectl get pods -w
생성한 스테이트풀셋에 expose를 실행합니다. 그런데 에러가 발생합니다. 이는 expose 명령이 스테이트풀셋을 지원하지 않기 때문입니다. 해결하려면 파일로 로드밸런서 서비스를 작성, 실행해야 합니다.
expose
명령으로 서비스를 생성할 수 있는 오브젝트는 디플로이먼트, 파드, 레플리카셋, 레플리케이션 컨트롤러입니다.kubectl expose statefulset nfs-pvc-sys --type=LoadBalancer --name=nfs-pvc-sts-svc --port=80
다음의 오브젝트 스펙을 적용해 스테이트풀셋을 노출하기 위한 서비스를 생성하고, 생성한 로드밸런서 서비스를 확인합니다.
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.4/nfs-pvc-sts-svc.yaml
kubectl get services
apiVersion: v1
kind: Service
metadata:
name: nfs-pvc-sts-svc
spec:
selector:
app: nfs-pvc-sts
ports:
- port: 80
type: LoadBalancer
호스트 브라우저를 열고 192.168.1.21에 접속해 파드 이름과 IP가 표시되는지 확인합니다.
exec로 파드에 접속한 후에 ls -l /audit
로 새로 접속한 파드의 정보가 추가됐는지 확인합니다. 정보를 확인하고 나면 exit
로 빠져나옵니다.
kubectl exec -it nfs-pvc-sts-0 -- /bin/bash
ls -l /audit
apiVersion: v1
kind: Service
metadata:
name: sts-svc-domain
spec:
selector:
app: nfs-pvc-sts
ports:
- port: 80
# 아까의 type: LoadBalancer에서 clusterIP: None으로 바뀜
clusterIP: None
kubectl apply -f ~/_Book_k8sInfra/ch3/3.4.4/sts-svc-domain.yaml
kubectl get services
kubectl run net --image=sysnet4admin/net-tools --restart=Never --rm -it -- nslookup nfs-pvc-sts-0.sts-svc-domain
kubectl delete services sts-svc-domain
kubectl delete statefulset nfs-pvc-sts
kubectl get pods -w
클라우드 스토리지와 오브젝트 형태의 스토리지는 동적으로 PVC 요청을 받아서 처리할 수 있도록 구현돼 있습니다.
이때 오브젝트는 kind: StorageClass
를 사용하고 PV와 PVC가 오브젝트를 호출하는 구조입니다.
메타데이터로 지정한 standard로 호출이 들어오면 동적으로 스토리지를 제공합니다.
apiVersion: storage.k8s.io/v1
# 이렇게 선언합니다.
kind: StorageClass
# standard로 호출이 들어오면 처리합니다.
metadata:
name: standard
provisioner: kubernetes.io/gce-pd
parameters:
type: pd-standard
replication-type: none
dynamic-pvc.yaml
을 적용해 PVC를 100GI만큼 요청합니다. 동적으로 설정된 PV는 PVC의 요청에 따라 생성됩니다.(동적으로!!)
kubectl apply -f https://raw.githubusercontent.com/sysnet4admin/_Book_k8sInfra/main/ch3/3.4.4/dynamic-pvc.yaml
코드는 다음과 같이 거의 비슷하지만, 제공자에 따라 storageClassName
을 작성해야 합니다. 여기서는 번거로움을 피하기 위해 공란으로 둡니다. 공란으로 두면 기본값(standard)를 사용합니다.
오브젝트 스펙은 다음과 같습니다.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: dynamic-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
# storageClassName: <default 사용>
클라우드 업체별로 storageClassName 기본값은 다음과 같습니다.
제공 업체 | 기본 StorageClass 이름 | 기본 프로비저너 |
---|---|---|
Amazon Web Services | gp2 | aws-ebs |
Microsoft Azure | standard | azure-disk |
Google Cloud Platform | standard | gce-pd |
OpenStack | standard | cinder |
VMware vSphere | thin | vsphere-volume |
생성된 PVC와 PVC 요청에 따라 생성된 PV를 함께 확인합니다.
kubectl get pvc
kubectl get pv
해당 PVC를 사용할 파드들을 생성합니다.
kubectl apply -f https://raw.githubusercontent.com/sysnet4admin/_Book_k8sInfra/main/ch3/3.4.4/dynamic-pvc-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: dynamic-pvc-deploy
spec:
replicas: 3
selector:
matchLabels:
app: dynamic-pvc-deploy
template:
metadata:
labels:
app: dynamic-pvc-deploy
spec:
containers:
- name: audit-trail
image: sysnet4admin/audit-trail
volumeMounts:
- name: dynamic-vol # same name of volumes's name
mountPath: /audit
volumes:
- name: dynamic-vol
persistentVolumeClaim:
claimName: dynamic-pvc
배포된 파드를 확인합니다.
kubectl get pods
배포된 파드 중 1개에 exec로 접속해 df -h
로 마운트된 볼륨을 확인합니다. 그런 다음 /audit
에 설정한 것과 같이 100Gi(98G) 용량이 마운트 된 것을 확인할 수 있습니다.
지금까지 쿠버네티스의 전반적인 개념을 배우고 직접 실습하며 어떻게 사용되는지 확인해봤습니다.
한번에 알아야 할 것들이 매우 많은 기술이기 때문에 전체를 여러 번 반복해서 실습하길 권장합니다.
조금씩 응용을 곁들이면 더 오랫동안 기억하기 수월합니다.
다음 포스팅부터는 쿠버네티스에서 내려받아 이용만 했단 컨테이너 도커를 알아보고, 직접 애플리케이션을 빌드하여 이를 도커 이미지로 만들어 보겠습니다.
그리고 만들어진 도커 이미지를 사설 컨테이너 저장소인 레지스트리에 넣고 쿠버네티스에서 저장된 이미지를 직접 불러오는 방법을 실습하며 쿠버네티스와의 관계를 확실히 정립해보겠습니다!
본 게시물은 "컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 - 조훈,심근우,문성주 지음(2021)" 기반으로 작성되었습니다.