일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- PostgreSQL
- docker
- AWS
- Packet
- ip
- kubernetes
- Vision
- grafana
- helm
- Spring
- kubeadm
- airflow
- java
- Operating System
- aws s3
- jvm
- log
- zookeeper
- MAC address
- Kafka
- Trino
- EC2
- OS
- JavaScript
- CSV
- kubectl
- Python
- CVAT
- Network
- tcp
- Today
- Total
JUST WRITE
PV 얼마나 남았나?!?! 본문
PV 얼마나 남았나?!?!
요즘 시스템 Monitoring을 할 때 Prometheus와 Grafana 조합을 많이 사용합니다.
Prometheus에서 Monitoring이 필요한 metric정보를 저장하고,
Grafana에서 Prometheus Metric을 보기 좋게 Dashboard로 제공합니다.
Kubernetes Cluster 환경에서도 Prometheus와 Grafana를 구축할 수 있습니다.
각각 Helm Chart를 제공합니다.
저도 근무지에서 Kubernetes 환경에서 Prometheus와 Grafana를 구축해서 사용 중에 있습니다.
문득 Prometheus가 데이터를 얼마나 저장하는지 궁금하였습니다.
Prometheus는 metric 정보를 저장하는 time-series database입니다.
Kubernetes에서는 PV를 통해 metric 정보를 mount 해서 저장하고 있습니다.
이번 포스팅에서는 PV에 어떻게 저장되고 얼마나 저장되는지 확인하는 방법을 정리해 보았습니다.
기본적인 PV, PVC 사용
먼저 Kubernetes PV, PVC에 대해서 잠깐 짚고 넘어가려 합니다.
Kubernetes에서는 PV(Persistent Volume)을 사용해서 데이터를 따로 저장합니다.
PV를 통해 Container의 데이터를 mount 해서 영구적으로 데이터를 보존할 수 있습니다.
StorageClass를 통해서 생성하거나 PVC(PersistentVolumeClaim)를 통해 생성을 요청합니다.
기본적으로 사용하는 방법은 아래와 같습니다.
- PV 생성
- PV의 StorageClass를 요청하는 PVC 생성
apiVersion: v1
kind: PersistentVolume
metadata:
name: task-pv-volume
labels:
type: local
spec:
storageClassName: manual
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
hostPath:
path: "/mnt/data"
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: task-pv-claim
spec:
storageClassName: manual
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 3Gi
- PVC를 사용하는 Pod 생성
apiVersion: v1
kind: Pod
metadata:
name: task-pv-pod
spec:
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: task-pv-claim
containers:
- name: task-pv-container
image: nginx
ports:
- containerPort: 80
name: "http-server"
volumeMounts:
- mountPath: "/usr/share/nginx/html"
name: task-pv-storage
Pod이 PVC를 통해 PV를 사용할 수 있게끔 Cluster에 요청합니다.
Pod의 '/usr/share/nginx/html' path의 데이터가 생성한 PV 쪽에 보관됩니다.
Prometheus의 데이터 저장
Prometheus는 time-series database입니다.
기본적으로 local path에 데이터와 metadata, index 파일을 저장합니다.
./data
├── 01BKGV7JBM69T2G1BGBGM6KB12
│ └── meta.json
├── 01BKGTZQ1SYQJTR4PB43C8PD98
│ ├── chunks
│ │ └── 000001
│ ├── tombstones
│ ├── index
│ └── meta.json
├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K
│ └── meta.json
├── 01BKGV7JC0RY8A6MACW02A2PJD
│ ├── chunks
│ │ └── 000001
│ ├── tombstones
│ ├── index
│ └── meta.json
├── chunks_head
│ └── 000001
└── wal
├── 000000002
└── checkpoint.00000001
└── 00000000
Prometheus의 기본 설정은 아래와 같습니다.
- --storage.tsdb.path : /data
- --storage.tsdb.retention.time : 15d
보통 15일 정도 데이터를 저장합니다.
Prometheus PV
Kuberetes Cluster에 구축한 Prometheus는 PV에 metric 데이터를 저장합니다.
아래는 helm으로 구축한 Prometheus, Grafana에서 PVC, PV정보입니다.
# pvc list check(prometheus, grafana)
$ kubectl get pvc -n monitoring
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
grafana Bound pvc-23e2107b-0670-4304-b685-f91f7ec2555c 10Gi RWO rook-ceph-block 150d
prometheus-server Bound pvc-60996709-57df-4935-8530-bbcd01302240 128Gi RWO rook-ceph-block 156d
# check prometheus pvc
$ kubectl describe pvc -n monitoring prometheus-server
Name: prometheus-server
Namespace: monitoring
StorageClass: rook-ceph-block
Status: Bound
Volume: pvc-60996709-57df-4935-8530-bbcd01302240
Labels: app=prometheus
app.kubernetes.io/managed-by=Helm
chart=prometheus-19.3.3
component=server
heritage=Helm
release=prometheus
Annotations: meta.helm.sh/release-name: prometheus
meta.helm.sh/release-namespace: monitoring
pv.kubernetes.io/bind-completed: yes
pv.kubernetes.io/bound-by-controller: yes
volume.beta.kubernetes.io/storage-provisioner: rook-ceph.rbd.csi.ceph.com
Finalizers: [kubernetes.io/pvc-protection]
Capacity: 128Gi
Access Modes: RWO
VolumeMode: Filesystem
Used By: prometheus-server-58d9dff57-p6w4q
Events: <none>
# check pv
$ kubectl describe pv pvc-60996709-57df-4935-8530-bbcd01302240
Name: pvc-60996709-57df-4935-8530-bbcd01302240
Labels: <none>
Annotations: pv.kubernetes.io/provisioned-by: rook-ceph.rbd.csi.ceph.com
Finalizers: [kubernetes.io/pv-protection]
StorageClass: rook-ceph-block
Status: Bound
Claim: monitoring/prometheus-server
Reclaim Policy: Delete
Access Modes: RWO
VolumeMode: Filesystem
Capacity: 128Gi
Node Affinity: <none>
Message:
Source:
Type: CSI (a Container Storage Interface (CSI) volume source)
Driver: rook-ceph.rbd.csi.ceph.com
FSType: ext4
VolumeHandle: 0001-0009-rook-ceph-0000000000000002-3539efa1-a0ff-11ed-bfaa-a22be79496b1
ReadOnly: false
VolumeAttributes: clusterID=rook-ceph
imageFeatures=layering
imageFormat=2
imageName=csi-vol-3539efa1-a0ff-11ed-bfaa-a22be79496b1
journalPool=replicapool
pool=replicapool
storage.kubernetes.io/csiProvisionerIdentity=1674694455798-8081-rook-ceph.rbd.csi.ceph.com
Events: <none
다만 해당 정보에서는 capacity가 128Gi인 것은 확인할 수 있지만,
현재 해당 PV에 얼마나 데이터가 저장되어 있는지 알 수가 없습니다.
확인을 하려면 container에 직접 들어가서 df 명령어를 통해 확인해야 했습니다.
$ kubectl exec -it -n monitoring pod/prometheus-server-****-**** --container prometheus-server -- sh
# Pod내 container 안
$ cd /data
$ du -h -d 1
553.7M ./01H423RRD8FWCX80QFZJHA3PJN
60.0M ./chunks_head
557.7M ./01H4FMBJ2KYQHPJDGR10MQXZ5W
544.2M ./01H3PGZGVWY6Y60NYX8X2JHWFD
544.2M ./01H3RES2M7KN4J3YBK1QZMVY8A
84.8M ./01H4MJ8VX2S6F5FT71SGBAMHFH
560.3M ./01H3GQJXB6H206J73WV1EN0Y36
555.1M ./01H47X5CFRHKZFZY2S962JC319
203.1M ./01H4MS4S94Q5TN4A0MWD4NR7CV
163.2M ./wal
540.9M ./01H3MK5ZMRFCA4ADR2REQVM22J
539.9M ./01H3TCJK91CPRVE68RF3BAE8GM
549.8M ./01H405Z795YJRR5XNA3511CN75
16.0K ./lost+found
552.5M ./01H4BRRE7M3RRVYYF1EM******
544.4M ./01H3Y85NY3XEKDVBBK4XJGNX4F
581.9M ./01H4KFYMGMPGB6S07DKG******
547.3M ./01H49TYXH20KGGVE9JG504R7H2
85.2M ./01H4MS4K4WY0P5VZF5SH******
552.3M ./01H3JNCDXH9XRM7STANETKZVRD
552.2M ./01H4DPJ028NMCPCBJB9T******
552.5M ./01H441J9F3X1C6VYHMEFTTK100
577.0M ./01H4HJ52YSF7C6TT7EEY******
561.7M ./01H3ESSDRT8S0T1X0Y7V2CRQPH
207.1M ./01H4M4HKAAHKGPXWV0R7FVRKGM
546.1M ./01H3WAC4PS1CRBPWA6SNHTC66G
84.3M ./01H4N00ACWQ4DZ9TNRR0******
553.9M ./01H45ZBV7CYHB9ZH41C9******
11.7G .
매번 이렇게 들어가서 확인하는 것은 번거롭다고 생각하였습니다.
그러던 중 저와 같은 고민을 한 사람을 발견하였습니다.
kubectl-df-pv
감사하게도 kube-apiserver를 활용해서 command를 통해 PV의 용량을 확인할 수 있습니다.
아래 Github Project에서 확인할 수 있습니다.
Github에서 손쉽게 Download 해서 설치할 수 있습니다.
# df-pv install
$ wget https://github.com/yashbhutwala/kubectl-df-pv/releases/download/v0.3.0/kubectl-df-pv_v0.3.0_linux_amd64.tar.gz
$ tar xzf kubectl-df-pv_v0.3.0_linux_amd64.tar.gz
$ mv df-pv ~/.local/bin
$ sourc ~/.profile
$ df-pv --help
df-pv emulates Unix style df for persistent volumes w/ ability to filter by namespace
It autoconverts all "sizes" to IEC values (see: https://en.wikipedia.org/wiki/Binary_prefix and https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#meaning-of-memory)
It colors the values based on "severity" [red: > 75% (too high); yellow: < 25% (too low); green: >= 25 and <= 75 (OK)]
Usage:
df-pv [flags]
Flags:
--as string Username to impersonate for the operation
--as-group stringArray Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
--cache-dir string Default cache directory (default "/home/manager/.kube/cache")
--certificate-authority string Path to a cert file for the certificate authority
--client-certificate string Path to a client certificate file for TLS
--client-key string Path to a client key file for TLS
--cluster string The name of the kubeconfig cluster to use
--context string The name of the kubeconfig context to use
-d, --disable-color boolean flag for disabling colored output
-h, --help help for df-pv
--insecure-skip-tls-verify If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
--kubeconfig string Path to the kubeconfig file to use for CLI requests.
-n, --namespace string If present, the namespace scope for this CLI request
--request-timeout string The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
-s, --server string The address and port of the Kubernetes API server
--tls-server-name string Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used
--token string Bearer token for authentication to the API server
--user string The name of the kubeconfig user to use
-v, --verbosity string log level; one of [info, debug, trace, warn, error, fatal, panic] (default "info")
manager@spc-k8sm01:~/workspace/tmp$ ./df-pv -n monitoring
PV NAME PVC NAME NAMESPACE NODE NAME POD NAME VOLUME MOUNT NAME SIZE USED AVAILABLE %USED IUSED IFREE %IUSED
pvc-60996709-57df-4935-8530-bbcd01302240 prometheus-server monitoring spc-k8sw07 prometheus-server-58d9dff57-p6w4q storage-volume 125Gi 11Gi 114Gi 9.02 167 8388441 0.00
namespace argument로 해당 PV가 얼마나 사용되고 있는지 알 수 있습니다.
$ df-pv -n monitoring
PV NAME PVC NAME NAMESPACE NODE NAME POD NAME VOLUME MOUNT NAME SIZE USED AVAILABLE %USED IUSED IFREE %IUSED
pvc-60996709-57df-4935-8530-******** prometheus-server monitoring k8sworker1 prometheus-server-58d9dff57-**** storage-volume 125Gi 11Gi 114Gi 9.02 167 8388441 0.00
정리
먼저 해당 df-pv를 공개해 준 Yash Bhutwala님께 감사드립니다.
df-pv를 통해 손쉽게 Kuberetes Cluster내 PV의 용량을 확인할 수 있었습니다.
기회가 된다면 Prometheus와 Grafana를 Kubernetes Cluster에 구축하는 것을 정리하겠습니다.
[참고사이트]
'MLOps > Kubernetes' 카테고리의 다른 글
Helm도 git처럼 diff가 가능하다고?! - Helm Plugin 설치 (0) | 2023.07.19 |
---|---|
포트 번호 쓰기도 귀찮네(1) (0) | 2023.07.11 |
[Error Reporting] Worker Node join 에러 - CNI 이슈 (0) | 2023.06.26 |
손쉽게 동적으로 Persistent Volume 생성하기 (0) | 2023.06.15 |
[Ingress] ArgoCD UI 헷갈리지 않고 쉽게 접근하기 (0) | 2023.06.04 |