Practice Test / Persistent Volume Claims

Summary

• exec에서 bash셀이 없으면 kubectl exec -it webapp -- /bin/sh 기본 sh쓰자
• .storage class없으면 storageclass없는 pv랑만 바운드됨
• 공식문서 pv는 nfs로 되어있는데 문제는 아닐경우는 hostPath부분만 따로 고치자
• pvc나 pv는 apply나 replace가 안된다. delete후 재생성 하자
• hostPath 타입은 해당 노드에 연결된 path이다. kode kloud는 control plane노드 하나니까 시험시에는 이걸 확인하자
• reclaim policy는 pv가 이제 사용안되면 남아있는 자료를 어떻게 처리할거냐에 관점을 둔거임. retain은 그냥 pv남겨두고 나중에 재사용 하게 할거라는거고 delete는 자료 싹다 지워서 바로 available상태로 전환한다는거임. retain으로 할경우 pv는 released상태로 남음
• pvc삭제시 연결된 pod가 있으면 안지워짐.

export samp="--dry-run=client -o yaml"

export grep="grep -iC 3"

export now="--force --grace-period 0"

$samp, $grep, $now붙은건 이 명령어로 약어만든거니까 주의

---

 

 

# 1

pod가 만들어지고있대.

 

 

# 2

pod에서 /log/app.log라는 경로로 로그를 쌓고있으니 함 봐보래

kubectl exec -it webapp -- /bin/bash

bash 셀이 없는듯?

kubectl exec -it webapp -- /bin/sh

cat /log/app.log

유저들이 뭐 하고있다 이런 로그들이 있음. 별 의미는 없는듯

exit

나오샘

 

 

# 3

 

pod가 삭제되면 로그 볼 수 있냐?

해보지 뭐

kubectl delete pod webapp $now

kubectl get pods

kubectl exec -it webapp -- /bin/sh

애초에 접근조차 안됨

kubectl exec -it webapp -- cat /logs/

뭐 당연한거지

 

 

 

# 4

현재 host의 /var/log/webapp에 로그들이 쌓이게 스토리지를 만들라고 함.

 

Volumes

여기들가면 양식이 있음.

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: example4-container
    image: kodekloud/event-simulator
    volumeMounts:
    - mountPath: /log
      name: example4-volume
  volumes:
  - name: example4-volume
    hostPath:
      path: /var/log/webapp

대충 나한테 맞게 hostpath volume을 만드는 야믈 썼음.

vi 4.yaml

4.yaml파일 만들고, 복붙하고

kubectl apply -f 4.yaml

kubectl get pods

잘 만들어짐.

 

- 검토

kubectl get pods -o wide

현재 webapp pod가 controlplane 노드에서 돌아가고 있음

 

kubectl exec -it webapp -- cat /log/app.logs

cat /var/log/webapp/app.log

 

둘다 똑같음

 

아니면 

kubectl describe pod webapp

hostpath타입 볼륨이 노드랑 잘 mount되어있음

개념 살짝 추가하면 내가 node 검색한이유가 해당 node의 /var/log/webapp경로랑 마운트되는거임!!
현재 kodekloud환경은 controlplane 마스터노드밖에없어서 바로 cat쳤지만 워커노드에 생기면 그 워커꺼를 확인해야함!!

 

 

 

 

# 5

persistent volume을 만들래

Persistent Volumes

요기 공식문서 yaml

이걸 내 식으로 바꾸면

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-log
spec:
  capacity:
    storage: 100Mi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /pv/log
    type: Directory

밑에 hostPath볼륨으로 만들어줬는데, 공식문서는 nfs로 되어있음

주의해서 바꾸고 난 storage class를 헷갈릴까봐 그냥 지웠다.

이런경우 스토리지 클래스 없는 pvc만 바운드된다

 

암튼 5.yaml파일 만들어서 만들자

 

kubectl apply -f 5.yaml

 

 

- 검토

kubectl get pv

 

 

 

# 6

pvc를 만들래

Persistent Volumes

 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim-log-1
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 50Mi

간단하게 하려고 셀렉터, storage클래스 다 지웠음.

6.yaml파일 만들고,

kubectl apply -f 6.yaml

 

- 검토

kubectl get pvc

 

 

# 7

pvc가 무슨상태?

pending상태

 

 

# 8

pv는 무슨상태?

kubectl get pv

avilable상태

 

 

# 9

왜 pvc가 pv랑 bound가 안됐냐는데?

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-log
spec:
  capacity:
    storage: 100Mi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /pv/log
    type: Directory

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim-log-1
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 50Mi

아까 yaml만들때 예상했던건데, accessMode가 안맞음.

 

 

kubectl get pv

kubectl get pvc

pending 상태인 pvc에선 access mode가 안나옴 ㅡㅡ 

 

kode kloud에서만 안되나 해서 로컬 vm 클러스터에서 해봤는데

얘도 안나옴

gpt한테 물어보니 pending상태인 pvc는 안나오는게 맞다고 함

bound되고나서부터 보인다고 함.

직접 찾으라는 소리임 ㅠ

describe에서도 안뜨더라. 그냥 단순히 event에서 적절한 pv가 없다고 하네

참고로 storage class설정했는데 실수했으면 이것때문일수도 있음.

 

 

 

# 10

pvc를 status bound상태 되게하래.

아까 access모드 수정하면 될듯?

 cp 6.yaml 10.yaml

6번에서 pvc만들었으니 복사하고

 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim-log-1
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 50Mi

아까 pv access mode가 rwx였으니 readwritemany로 바꾸면 됨

이걸로 만들어주면 될듯?

 

참고로 pvc는 apply나 replace가 안되더라. 삭제하고 다시만들어줘야함.

kubectl delete pvc claim-log-1

kubectl apply -f 10.yaml

 

 

- 검토

kubectl get pvc

bound됐음

 

 

 

# 11

pvc에서는 50Mi를 요구했는데 생성된 pvc는 얼만큼 쓸수있냐는데?

kubectl get pvc

capacity에 100Mi로 되어있음

지금 있는 pv중에 제일 적절한거 쓴건데 용량만 100Mi짜리 하나있으니 저걸 갖다 쓴거임 

capacity는 조금 유연함

 

 

 

# 12

webapp pod를 pv쓰게 pvc사용해서 연결하라고함.

처음에 hostPath타입이었으니 이번엔 pv타입으로 바꾸라고 함

 

아까 pod 만든 yaml이 4.yaml

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: example4-container
    image: kodekloud/event-simulator
    volumeMounts:
    - mountPath: /log
      name: example4-volume
  volumes:
  - name: example4-volume
    hostPath:
      path: /var/log/webapp

요거였음.

이걸 공식문서

Persistent Volumes

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

얘로 적절히 바꾸라는거임. 

저 volumes를 바꾸면 될듯?

apiVersion: v1
kind: Pod
metadata:
  name: webapp
spec:
  containers:
  - name: example12-container
    image: kodekloud/event-simulator
    volumeMounts:
    - mountPath: /log
      name: example12-volume
  volumes:
  - name: example12-volume
    persistentVolumeClaim:
      claimName: claim-log-1

pod도 삭제하고 다시 만들어야 함

kubectl delete pod webapp $now

kubectl apply -f 12.yaml

 

 

- 검토

kubectl get pods

kubectl describe pod webapp

 

 

 

 

# 13

pv의 reclaim policy는 무슨 상태냐는데

kubectl describe pv pv-log

retain임.

pvc가 삭제되어도 파일 지우지 말라는 정책임

 

 

# 14

pvc가 없어지면 pv는 어떻게 되냐는 거임.

release상태되는데 암튼 뭐 적절한건 삭제는 안되지만 available상태는 아닐거다.

하긴 백업용으로 남겨둔 볼륨이 될거니까.

 

 

 

# 15

pvc를 삭제해보래

kubectl delete pvc 머시기

kubectl get pvc

terminating상태임

연결된 pod가 살아있기 때문

 

 

 

# 17

그럼 연결된 pod webapp을 지워보재

kubectl delete pods webapp $now

 

 

pod랑 pvc는 지워지고 pv는 released상태됨.

 

released상태는 재사용은 가능한데 뭔 작업을 해야 한다고함.

delete으로 reclaimPolicy를 설정하면 이런 상황에서 상태가 available로 변함

ㅇㅇ