이 페이지에서는 기출 문제 중 PV,PVC에 대한 문제와 이를 활용한 사이드카 패턴 관련 문제를 다룬다.
1. hostPath PV 생성
수동으로 PV를 하나 생성한다. 파드는 기본적으로 stateless로 파드 삭제 시 내부에 파일시스템에 작성되었던 내용들도 모두 삭제된다. 이를 막기 위해 영속성이 필요한 데이터들은 PV와 PVC를 활요해 관리한다. PV는 어떤 스토리지를 사용할 지에 대한 부분이고, PVC는 파드가 어떤 PV를 사용할 지에 대한 정의이다. PV는 다양한 스토리지와 연결하여 사용할 수 있는데, hostPath의 경우 실제 컨테이너가 실행되는 호스트 머신의 파일시스템을 사용한다.
#hostpath.yaml 파일 작성
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "{문제에서주어지는경로}"
#pv 생성
[root@k8s-master ~]$ kubectl create -f hostpath.yaml
2 PV와 PVC 생성하여 nginx파드에 볼륨 마운트
참조 링크:https://kubernetes.io/ko/docs/tasks/configure-pod-container/configure-persistent-volume-storage/
문제에서 주어지는 스펙대로 PV와 PVC를 생성한 후, nginx파드에 마운트하여 실행해야 한다.
1. PV 생성
아래는 일반적인 PV 생성 YAML 파일이다. spec 부분에 storage, accessModes, path 부분을 문제에서 요구하는 대로 수정하여 생성한다.
#pv.yaml 파일 생성
[root@k8s-master ~]$ cat pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
type: local
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
#pv 리소스 생성
[root@k8s-master ~]# kubectl apply -f pv.yaml
persistentvolume/task-pv-volume created
#생성된 리소스 확인
[root@k8s-master ~]# kubectl get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
task-pv-volume 10Gi RWO Retain Available 65s
2.PVC 생성
생성한 PV에 맞게 PVC를 생성한다. storage는 PV의 storage보다 작거나 같아야 한다.
#pvc.yaml 파일 생성
[root@k8s-master ~]$ cat pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
#pvc 리소스 생성
[root@k8s-master ~]$ kubectl apply -f pvc.yaml
persistentvolumeclaim/task-pv-claim created
#생성된 pv,pvc 리소스 확인
[root@k8s-master ~]$ kubectl get pv,pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
persistentvolume/task-pv-volume 10Gi RWO Retain Bound default/task-pv-claim 5m28s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
persistentvolumeclaim/task-pv-claim Bound task-pv-volume 10Gi RWO 6s
PVC 조회 시 위의 출력처럼 Bound가 되어야 한다. Pending으로 계속 유지될 경우 pvc가 요청한 내용에 pv가 일치하지 않은 경우기이 때문에 spec을 다시 확인해보아야 한다.
3. 파드 생성 및 pvc 연결
2번에서 실제 볼륨 역할을 하는 PV와 이 볼륨을 사용하는 요청인 PVC를 생성하였다. 실제 파드 생성시 해당 볼륨을 사용하려면 아래와 같이 파드의 volume부분에 PVC를 등록하면 된다.
#pod.yaml 파일 작성
[root@k8s-master ~]$ cat pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
#파드 생성
[root@k8s-master ~]$ kubectl apply -f pod.yaml
pod/task-pv-pod created
#생성된 파드 조회
[root@k8s-master ~]$ kubectl get po
NAME READY STATUS RESTARTS AGE
task-pv-pod 1/1 Running 0 17s
#파드에 마운트된 볼륨 확인
[root@k8s-master ~]$ kubectl describe po task-pv-pod
...
Mounts:
/usr/share/nginx/html from task-pv-storage (rw)
...
Volumes:
task-pv-storage:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: task-pv-claim
ReadOnly: false
...
3. 스토리지 클래스에 해당하는 PVC 생성
참조 링크:https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/
1번 문제처럼 PV를 별도로 생성하고 관리할 수도 있지만, 스토리지 클래스는 PVC에 맞는 PV를 자동으로 생성(프로비저닝)해준다. 문제에서는 스토리지 클래스가 주어져 있고 해당 스토리지 클래스에서 PV를 생성할 수 있도록 PVC를 작성해야 한다.
#1. 문제에서 주어진 스토리지 클래스 상세 정보 확인
[root@k8s-master ~]$ kubectl descirbe storageclass {스토리지클래스명}
#2. pvc.yaml 생성
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: myclaim
spec:
accessModes:
- {스토리지클래스와동일하게작성}
volumeMode: Filesystem
resources:
requests:
storage: {문제에서요구하는용량}
storageClassName: {문제에서주어진스토리지클래스}
#3. 정상 생성 확인
[root@k8s-master ~]$ kubectl get pv,pvc --all-namespaces
accessModes: 아래 부분에는 스토리지 클래스와 동일한 내용을 적는다. RWO, ROX, RWX 중 하나로 되어 있을 것이다. storage는 문제에서 지정한 만큼 할당하고, storageClassName에 스토리지 클래스 명을 지정한다.
kubectl get pv,pvc --all-namespaces 명령을 통해 정상적으로 PV가 생성되었는지 확인한다. PV가 생성되지 않을 경우 yaml파일의 내용이 스토리지클래스와 일치하지 않은 것이기 때문에 재생성이 필요하다.
4. 멀티 컨테이너 파드 배포2(사이드카 패턴)
참조 링크:
두 개의 컨테이너가 하나의 볼륨을 공유하도록 배포해야 합니다. 클러스터에는 nginx 싱글 컨테이너만 존재합니다. 해당 nginx의 로그 파일이 저장되는 경로에 컨테이너 볼륨을 마운트하고, 해당 볼륨을 log-conainer라는 이름의 새로운 컨테이너에도 마운트합니다. 두 컨테이너가 동일한 볼륨을 공유하게 되고, 따라서 log-container 컨테이너 접근 시 nginx의 로그를 조회할 수 있어야 합니다.
# 기존 nginx 파드 정보 추출
[root@k8s-master ~]$ kubectl get po {파드명} -o yaml > nginx.yaml
# 기존 nginx 파드 삭제
[root@k8s-master ~]$ kubectl delete po {파드명}
#nginx.yaml 파일 수정(volume 및 log-container 추가)
[root@k8s-master ~]$ cat nginx.yaml
apiVersion: v1
kind: Pod
metadata:
name: two-containers
spec:
volumes:
- name: shared-data
emptyDir: {}
containers:
- name: nginx-container
image: nginx
volumeMounts:
- name: shared-data
mountPath: var/log/nginx
- name: log-container
image: centos
command: ["/bin/sh"]
args: ["-c", "while true; do ls log; sleep 5;done"]
volumeMounts:
- name: shared-data
mountPath: log
# 새로운 파드 생성
[root@k8s-master ~]$ kubectl apply -f nginx.yaml
pod/two-containers created
# 파드 확인
[root@k8s-master ~]$ kubectl get po
NAME READY STATUS RESTARTS AGE
two-containers 2/2 Running 0 22s
# log-container에서 nginx의 로그 접근 확인
[root@k8s-master ~]$ kubectl logs two-containers -c log-container
access.log
error.log
새로운 log-container 생성 후 nginx와 같은 볼륨을 마운트시킨다. log-container의 log 경로로 접근해보면 nginx가 생성하는 로그 파일을 조회할 수 있다. 해당 YAML내용은 기억에 의존해 재생성한 YAML파일이기 때문에 실제 문제 내용과는 차이가 있을 수 있다.
CKA 자격증 정보 및 문제 풀이 연관 글
[쿠버네티스] CKA 자격 시험 접수 및 후기 (202105) | 데인트리 라이브러리
[쿠버네티스] CKA 기출 자료_1 [RBAC, Node] | 데인트리 라이브러리
[쿠버네티스] CKA 기출 자료_2 [클러스터 업그레이드, 백업] | 데인트리 라이브러리
[쿠버네티스] CKA 기출 자료_3 [파드, 디플로이먼트] | 데인트리 라이브러리
[쿠버네티스] CKA 기출 자료_4 [PV, PVC] | 데인트리 라이브러리
[쿠버네티스] CKA 기출 자료_5 [네트워킹] | 데인트리 라이브러리
내용에 오류가 있거나 질문이 있으면 댓글로 소통해주세요
언제나 환영합니다
'쿠버네티스 > CKA 자격증' 카테고리의 다른 글
[쿠버네티스] CKA 기출 자료_5 [네트워킹] | 데인트리 라이브러리 (4) | 2021.07.20 |
---|---|
[쿠버네티스] CKA 기출 자료_3 [파드, 디플로이먼트] | 데인트리 라이브러리 (0) | 2021.07.06 |
[쿠버네티스] CKA 기출 자료_2 [클러스터 업그레이드, 백업] | 데인트리 라이브러리 (0) | 2021.06.26 |
[쿠버네티스] CKA 기출 자료_1 [RBAC, Node] | 데인트리 라이브러리 (3) | 2021.06.13 |
[쿠버네티스] CKA 자격 시험 접수 및 후기 (202105) | 데인트리 라이브러리 (2) | 2021.05.23 |
댓글