1. We have deployed a POD. Inspect the POD and wait for it to start running. In the current(default) namespace.
controlplane ~ ➜ k get pods
NAME READY STATUS RESTARTS AGE
webapp 1/1 Running 0 15s
2. The application stores logs at location /log/app.log. View the logs. You can exec in to the container and open the file: kubectl exec webapp -- cat /log/app.log
controlplane ~ ➜ kubectl exec webapp -- cat /log/app.log | head -n 10
[2024-07-28 14:09:56,423] INFO in event-simulator: USER3 is viewing page3
[2024-07-28 14:09:57,424] INFO in event-simulator: USER1 is viewing page1
[2024-07-28 14:09:58,425] INFO in event-simulator: USER3 is viewing page2
[2024-07-28 14:09:59,426] INFO in event-simulator: USER1 is viewing page3
[2024-07-28 14:10:00,427] INFO in event-simulator: USER4 is viewing page2
[2024-07-28 14:10:01,428] WARNING in event-simulator: USER5 Failed to Login as the account is locked due to MANY FAILED ATTEMPTS.
[2024-07-28 14:10:01,428] INFO in event-simulator: USER4 logged out
[2024-07-28 14:10:02,429] INFO in event-simulator: USER4 is viewing page1
[2024-07-28 14:10:03,430] INFO in event-simulator: USER2 is viewing page1
[2024-07-28 14:10:04,431] WARNING in event-simulator: USER7 Order failed as the item is OUT OF STOCK.
3.if the POD was to get deleted now, would you be able to view these logs.
answer : No
POD 안에 저장된 로그는 POD 가 삭제될때 사라진다.
4. Configure a volume to store these logs at /var/log/webapp on the host. Use the spec provided below.
Name: webapp
Image Name: kodekloud/event-simulator
Volume HostPath: /var/log/webapp
Volume Mount: /log
https://kubernetes.io/docs/concepts/storage/volumes/#hostpath-configuration-example
Volumes
On-disk files in a container are ephemeral, which presents some problems for non-trivial applications when running in containers. One problem occurs when a container crashes or is stopped. Container state is not saved so all of the files that were created
kubernetes.io
apiVersion: v1
kind: Pod
metadata:
name: webapp
spec:
containers:
- env:
- name: LOG_HANDLERS
value: file
image: kodekloud/event-simulator
name: event-simulator
volumeMounts:
- mountPath: /log
name: log-volume
volumes:
- name: log-volume
hostPath:
path: /var/log/webapp
type: Directory
5. Create a Persistent Volume with the given specification.
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-log
spec:
persistentVolumeReclaimPolicy: Retain
accessModes:
- ReadWriteMany
capacity:
storage: 100Mi
hostPath:
path: /pv/loghttps://kubernetes.io/docs/concepts/storage/persistent-volumes
Persistent Volumes
This document describes persistent volumes in Kubernetes. Familiarity with volumes, StorageClasses and VolumeAttributesClasses is suggested. Introduction Managing storage is a distinct problem from managing compute instances. The PersistentVolume subsystem
kubernetes.io
6. Let us claim some of that storage for our application. Create a Persistent Volume Claim with the given specification.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: claim-log-1
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 50Mi
PV와 PVC 개요
PersistentVolume (PV)와 PersistentVolumeClaim (PVC)는 Kubernetes에서 스토리지를 관리하기 위해 사용되는 리소스입니다.
PersistentVolume (PV)
• PV는 클러스터 관리자가 제공하는 스토리지 리소스를 나타냅니다.
• PV는 스토리지의 실제 물리적 위치를 정의합니다.
• PV는 수명 주기와 상태를 포함한 스토리지의 세부 사항을 나타냅니다.
• 클러스터 관리자가 미리 프로비저닝하거나 다이나믹하게 프로비저닝할 수 있습니다.
• 스토리지의 유형(예: NFS, iSCSI, 클라우드 제공자 스토리지 등)을 명시할 수 있습니다.
PersistentVolumeClaim (PVC)
• PVC는 사용자가 필요한 스토리지를 요청하기 위해 사용하는 리소스입니다.
• PVC는 사용자가 필요한 스토리지의 크기와 접근 모드를 명시합니다.
• PVC가 생성되면 Kubernetes는 적절한 PV를 찾아 PVC에 바인딩합니다.
• 사용자가 스토리지에 접근할 수 있도록 PV를 PVC에 바인딩하는 과정을 자동으로 처리합니다.
PV와 PVC의 상호작용
1. PV 생성: 클러스터 관리자가 PV를 생성하여 클러스터에 제공되는 스토리지를 정의합니다.
2. PVC 생성: 사용자가 PVC를 생성하여 필요한 스토리지를 요청합니다.
3. 바인딩: Kubernetes는 PVC가 생성되면 PVC의 요구사항에 맞는 PV를 찾아 PVC에 바인딩합니다.
4. 사용: PVC가 바인딩된 후, 사용자는 해당 PVC를 참조하여 애플리케이션이 스토리지에 접근할 수 있도록 합니다.
5. 삭제 및 해제: 사용자가 PVC를 삭제하면, PVC와 바인딩된 PV는 다시 사용 가능한 상태가 되며, PVC의 요청을 충족할 수 있는 다른 사용자가 사용할 수 있게 됩니다.
7. What is the state of the Persistent Volume Claim?
controlplane ~ ➜ k get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
claim-log-1 Pending <unset> 16s
answer : Pending
8. What is the state of the Persistent Volume?
controlplane ~ ➜ k get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
pv-log 100Mi RWX Retain Available <unset> 5m59s
answer : Available
9. Why is the claim not bound to the available Persistent Volume?
pv 와 pvc 의 ACCESS-MODES 가 서로 다르다.
pv : RWX
pvc : RWO
answer : Acess Modes Mismatch
10. Update the Access Mode on the claim to bind it to the PV. Delete and recreate the claim-log-1.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: claim-log-1
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 50Mi
11. You requested for 50Mi, how much capacity is now available to the PVC?
controlplane ~ ➜ k get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
claim-log-1 Bound pv-log 100Mi RWX <unset> 82s
answer : 100Mi
12. Update the webapp pod to use the persistent volume claim as its storage. Replace hostPath configured earlier with the newly created PersistentVolumeClaim.
Configure a Pod to Use a PersistentVolume for Storage
This page shows you how to configure a Pod to use a PersistentVolumeClaim for storage. Here is a summary of the process: You, as cluster administrator, create a PersistentVolume backed by physical storage. You do not associate the volume with any Pod. You,
kubernetes.io
apiVersion: v1
kind: Pod
metadata:
name: webapp
spec:
containers:
- env:
- name: LOG_HANDLERS
value: file
image: kodekloud/event-simulator
name: event-simulator
volumeMounts:
- mountPath: /log
name: log-volume
volumes: - name: log-volume
persistentVolumeClaim:
claimName: claim-log-1
controlplane ~ ➜ k delete po webapp --force
Warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "webapp" force deleted
controlplane ~ ➜ k apply -f webapp.yaml
pod/webapp created
13. What is the Reclaim Policy set on the Persistent Volume pv-log?
controlplane ~ ➜ k get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
pv-log 100Mi RWX Retain Bound default/claim-log-1 <unset> 24m
answer : Retain
14. What would happen to the PV if the PVC was destroyed?
PV에 설정된 persistentVolumeReclaimPolicy에 따라 다릅니다. 각 정책은 다음과 같습니다:
1. Retain (유지):
• PV는 삭제되지 않으며 데이터는 그대로 남아 있습니다.
• PV의 상태는 “Released”(해제됨)로 변경되며, 이는 더 이상 PVC에 바인딩되지 않았지만 데이터를 유지하고 있음을 나타냅니다.
• PV를 삭제하거나 재사용하려면 수동으로 조치가 필요합니다.
2. Recycle (재활용):
• PV의 데이터가 기본적으로 삭제되고 PV는 다시 사용 가능한 상태로 변경됩니다.
• 이 정책은 현재는 더 이상 사용되지 않으며, 최신 Kubernetes 버전에서는 지원되지 않을 수 있습니다.
3. Delete (삭제):
• PV와 그 기저의 스토리지가 삭제됩니다.
• 이는 동적으로 프로비저닝된 스토리지에서 자동으로 정리되는 경우에 유용합니다.
answer : The PV is not deleted but not available
15. Try deleting the PVC and notice what happens. If the command hangs, you can use CTRL + C to get back to the bash prompt OR check the status of the pvc from another terminal
controlplane ~ ✖ k get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS VOLUMEATTRIBUTESCLASS AGE
claim-log-1 Terminating pv-log 100Mi RWX <unset> 8m6s
answer : The PVC is stuck in 'Terminating' state
16. Why is the PVC stuck in Terminating state?
answer: The PVC is being used in pod
17. Let us now delete the webapp Pod. Once deleted, wait for the pod to fully terminate.
18. What is the state of the PVC now?
controlplane ~ ➜ k get pvc
No resources found in default namespace.
19. What is the state of the Persistent Volume now?
controlplane ~ ➜ k get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS VOLUMEATTRIBUTESCLASS REASON AGE
pv-log 100Mi RWX Retain Released default/claim-log-1 <unset> 31manswer : Released
만약 PVC(PersistentVolumeClaim)를 사용하는 중에 PVC를 삭제하면 다음과 같은 일이 발생합니다:
1. PVC 삭제: PVC를 삭제하면 Kubernetes에서 해당 PVC 객체는 제거되지만, PVC가 참조하던 실제 데이터는 삭제되지 않습니다. 대신, PVC가 바인딩되어 있던 PV(PersistentVolume)는 그대로 남아 있게 됩니다.
2. PV 상태 변화: PV의 persistentVolumeReclaimPolicy에 따라 PV의 상태가 결정됩니다. 일반적으로 다음과 같은 경우가 있습니다:
• Retain (유지): PV의 상태가 “Released”로 변경됩니다. 이는 PV가 더 이상 PVC에 바인딩되지 않았음을 나타내지만, 데이터는 여전히 PV에 남아 있습니다. 이를 통해 관리자는 수동으로 데이터를 백업하거나 정리할 수 있습니다.
• Recycle (재활용): 더 이상 사용되지 않는 정책으로, PV의 데이터가 기본적으로 삭제되고 PV는 다시 사용 가능한 상태로 돌아갑니다.
• Delete (삭제): PV와 그 기저의 스토리지가 삭제됩니다. 이는 동적으로 프로비저닝된 스토리지에서 자동으로 정리되는 경우 유용합니다.
3. Pod 동작: PVC를 사용하고 있는 Pod는 PVC가 삭제된 후에도 계속 동작할 수 있지만, PVC가 삭제됨으로 인해 스토리지와의 연결이 끊어질 가능성이 있습니다. 이로 인해 Pod가 스토리지와 상호작용하는 작업에서 오류가 발생할 수 있습니다. 이 경우 Pod가 재시작되거나 다시 스케줄링되면 정상적으로 동작하지 않을 수 있습니다.
'IT 기술 > k8s' 카테고리의 다른 글
| [cka] Explore Environment (0) | 2024.08.07 |
|---|---|
| [cka] Storage Class (0) | 2024.08.06 |
| [cka] Network Policies (0) | 2024.07.28 |
| [cka] Security Contexts (0) | 2024.07.28 |
| [cka] Image Security (0) | 2024.07.28 |
댓글