update kuber doc: stroage
This commit is contained in:
@@ -0,0 +1,58 @@
|
||||
# 📦 Deploying Longhorn with `kubectl`
|
||||
|
||||
This guide walks you through installing **Longhorn**, a cloud-native distributed block storage solution for Kubernetes, using `kubectl`.
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Prerequisites
|
||||
|
||||
* A Kubernetes cluster (v1.21 or newer recommended)
|
||||
* `kubectl` configured and connected to your cluster
|
||||
* Internet access for downloading manifests
|
||||
|
||||
---
|
||||
|
||||
## 🧩 Step 1: Apply Longhorn YAML
|
||||
|
||||
Apply the official Longhorn deployment manifest in the `longhorn-system` namespace:
|
||||
|
||||
```bash
|
||||
kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.9.0/deploy/longhorn.yaml
|
||||
```
|
||||
|
||||
This will create all required resources under the `longhorn-system` namespace.
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Step 2: Monitor Longhorn Pods
|
||||
|
||||
Watch the pods being created to ensure Longhorn is deploying properly:
|
||||
|
||||
```bash
|
||||
kubectl get pods \
|
||||
--namespace longhorn-system \
|
||||
--watch
|
||||
```
|
||||
|
||||
Wait until all pods show a `Running` or `Completed` status.
|
||||
|
||||
---
|
||||
|
||||
## 📦 Step 3: Verify Storage Classes
|
||||
|
||||
Once Longhorn is running, verify that the storage classes have been registered:
|
||||
|
||||
```bash
|
||||
kubectl get storageclasses
|
||||
```
|
||||
|
||||
You should see a storage class named `longhorn`, which can now be used in your PersistentVolumeClaims (PVCs).
|
||||
|
||||
---
|
||||
|
||||
## ✅ Success!
|
||||
|
||||
Longhorn is now successfully deployed and ready to provide persistent block storage for your workloads.
|
||||
|
||||
For more information, visit the [official Longhorn documentation](https://longhorn.io/docs/).
|
||||
|
||||
193
Containerization & Orchestration/Kubernetes/Storage/Pv.md
Normal file
193
Containerization & Orchestration/Kubernetes/Storage/Pv.md
Normal file
@@ -0,0 +1,193 @@
|
||||
# 🌐 Kubernetes Persistent Volumes (PV) Cheat Sheet
|
||||
|
||||
## 📦 What is a Persistent Volume (PV)?
|
||||
|
||||
A **Persistent Volume (PV)** is a piece of storage in a Kubernetes cluster that is either:
|
||||
|
||||
* Pre-provisioned by an administrator, or
|
||||
* Dynamically provisioned using **StorageClasses**.
|
||||
|
||||
It allows data to **persist beyond the lifecycle of individual Pods**.
|
||||
|
||||
---
|
||||
|
||||
## 📁 PV Storage Options
|
||||
|
||||
1. **HostPath**
|
||||
|
||||
* Mounts a file or directory from the host node’s filesystem into your Pod.
|
||||
* Useful only for single-node testing or development.
|
||||
|
||||
2. **Using PV and PVC**
|
||||
|
||||
* **PV (Persistent Volume):** Represents the actual storage resource.
|
||||
* **PVC (Persistent Volume Claim):** A user's request for storage resources and access.
|
||||
|
||||
---
|
||||
|
||||
## 🧱 Kubernetes Storage Layers
|
||||
|
||||
1. **Persistent Volume (PV)** – The actual storage unit.
|
||||
2. **Persistent Volume Claim (PVC)** – A request for that storage.
|
||||
|
||||
---
|
||||
|
||||
## 🔄 PV Lifecycle States
|
||||
|
||||
| State | Description |
|
||||
| ------------ | ------------------------------------------ |
|
||||
| Provisioning | PV is being prepared. |
|
||||
| Binding | PV is bound to a PVC. |
|
||||
| Using | PV is in use by a Pod. |
|
||||
| Releasing | PVC is deleted; PV becomes unbound. |
|
||||
| Reclaiming | Reclaim policy is applied: |
|
||||
| | • `Delete` – Remove the storage. |
|
||||
| | • `Recycle` – Basic scrub (deprecated). |
|
||||
| | • `Retain` – Manual intervention required. |
|
||||
|
||||
---
|
||||
|
||||
## 🔒 PV Access Modes
|
||||
|
||||
| Mode | Description |
|
||||
| ------ | ---------------------------------------------- |
|
||||
| `RWO` | **ReadWriteOnce** – One node can read/write |
|
||||
| `ROX` | **ReadOnlyMany** – Multiple nodes read-only |
|
||||
| `RWX` | **ReadWriteMany** – Multiple nodes read/write |
|
||||
| `RWOP` | **ReadWriteOncePod** – Only one Pod can use it |
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ CLI Commands to Manage PVs
|
||||
|
||||
```bash
|
||||
# List all Persistent Volumes
|
||||
kubectl get pv
|
||||
|
||||
# List all Persistent Volume Claims
|
||||
kubectl get pvc
|
||||
|
||||
# Edit a PVC
|
||||
kubectl edit pvc -n <namespace> <pvc-name>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Example 1: Deployment with `hostPath` Volume
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: app-1
|
||||
namespace: dev
|
||||
labels:
|
||||
app.kubernetes.io/name: nginx
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
volumeMounts:
|
||||
- name: nginx-log
|
||||
mountPath: /var/log/nginx
|
||||
volumes:
|
||||
- name: nginx-log
|
||||
hostPath:
|
||||
path: /root/nginx/logs
|
||||
type: DirectoryOrCreate
|
||||
```
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 📂 Example 2: NFS-backed Persistent Volume
|
||||
|
||||
### 🧩 PersistentVolume Definition
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: pv1
|
||||
spec:
|
||||
capacity:
|
||||
storage: 5Gi
|
||||
volumeMode: Filesystem
|
||||
accessModes:
|
||||
- ReadWriteMany
|
||||
persistentVolumeReclaimPolicy: Retain
|
||||
storageClassName: custom-name
|
||||
mountOptions:
|
||||
- hard
|
||||
- nfsvers=4.1
|
||||
nfs:
|
||||
path: /nfs/data
|
||||
server: 192.168.1.10
|
||||
```
|
||||
|
||||
### 📄 PersistentVolumeClaim
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: pvc1
|
||||
namespace: ns-test
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteMany
|
||||
resources:
|
||||
requests:
|
||||
storage: 1Gi
|
||||
storageClassName: custom-name
|
||||
```
|
||||
|
||||
### 🚀 Deployment Using PVC
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: app-1
|
||||
namespace: dev
|
||||
labels:
|
||||
app.kubernetes.io/name: nginx
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app.kubernetes.io/name: nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app.kubernetes.io/name: nginx
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
volumeMounts:
|
||||
- name: nginx-log
|
||||
mountPath: /var/log/nginx
|
||||
volumes:
|
||||
- name: nginx-log
|
||||
persistentVolumeClaim:
|
||||
claimName: pvc1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📝 Common Mistakes Fixed
|
||||
|
||||
@@ -0,0 +1,64 @@
|
||||
|
||||
## 📦 Pod Volume Lifecycle & `emptyDir` Usage in Kubernetes
|
||||
|
||||
This document describes how volumes work in the context of Kubernetes Pods, focusing on `emptyDir` and its lifecycle behavior.
|
||||
|
||||
---
|
||||
|
||||
### 🔁 Pod Lifecycle & Volumes
|
||||
|
||||
* **Volumes are defined at the Pod level.**
|
||||
They are not tied to a specific container, but can be shared among containers within the same Pod.
|
||||
|
||||
* **Volumes are attached to containers through `volumeMounts`.**
|
||||
This enables containers to access the volume’s filesystem at the specified `mountPath`.
|
||||
|
||||
* **Data in `emptyDir` volumes is ephemeral.**
|
||||
The volume is created when the Pod starts and **deleted when the Pod is removed**, erasing all stored data.
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Visibility Across Pods & Containers
|
||||
|
||||
* A **Pod cannot access another Pod’s volume**, even if it's of type `emptyDir`.
|
||||
For example:
|
||||
|
||||
* Pod A cannot see Pod B’s `emptyDir`.
|
||||
* However, **containers within the same Pod can share and access the same `emptyDir`** volume.
|
||||
|
||||
---
|
||||
|
||||
### 🧪 Example: Pod with `emptyDir` Volume in Memory
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
namespace: ns-test
|
||||
name: pod-tests
|
||||
spec:
|
||||
containers:
|
||||
- name: nginx
|
||||
image: nginx
|
||||
resources:
|
||||
limits:
|
||||
memory: "150Mi"
|
||||
cpu: "500m"
|
||||
volumeMounts:
|
||||
- name: nginx-log
|
||||
mountPath: /var/log/nginx
|
||||
volumes:
|
||||
- name: nginx-log
|
||||
emptyDir:
|
||||
medium: Memory # Uses memory for faster read/write operations
|
||||
sizeLimit: 64Mi # Volume size limited to 64Mi
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🧠 Key Points
|
||||
|
||||
* `emptyDir` is ideal for temporary storage like logs, scratch space, or caches.
|
||||
* Using `medium: Memory` stores data in memory (RAM) instead of disk, offering higher performance.
|
||||
* `sizeLimit` restricts the amount of memory that the `emptyDir` can consume.
|
||||
|
||||
Reference in New Issue
Block a user