change dir name orch,container
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/).
|
||||
|
||||
210
Containerization-Orchestration/Kubernetes/Storage/Pv.md
Normal file
210
Containerization-Orchestration/Kubernetes/Storage/Pv.md
Normal file
@@ -0,0 +1,210 @@
|
||||
# 🌐 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 can be:
|
||||
|
||||
- **Pre-provisioned** by an administrator, or
|
||||
- **Dynamically provisioned** using a **StorageClass**.
|
||||
|
||||
> PVs allow 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 a Pod.
|
||||
- Only suitable for **single-node testing or development** environments.
|
||||
|
||||
### 2. **Persistent Volume (PV) & Persistent Volume Claim (PVC)**
|
||||
- **PV**: Represents the actual physical or virtual storage resource.
|
||||
- **PVC**: A user's request for specific storage resources and access modes.
|
||||
|
||||
---
|
||||
|
||||
## 🧱 Kubernetes Storage Architecture
|
||||
|
||||
1. **Persistent Volume (PV)** – The actual storage unit, managed by the admin or provisioned dynamically.
|
||||
2. **Persistent Volume Claim (PVC)** – A user’s request for a certain amount and type of storage.
|
||||
|
||||
---
|
||||
|
||||
## 🔄 PV Lifecycle Phases
|
||||
|
||||
| **State** | **Description** |
|
||||
|---------------|---------------------------------------------|
|
||||
| Provisioning | PV is being created or initialized. |
|
||||
| Binding | PV is bound to a PVC. |
|
||||
| Using | PV is in use by a Pod. |
|
||||
| Releasing | PVC is deleted; PV becomes unbound. |
|
||||
| Reclaiming | Based on reclaim policy: |
|
||||
| | - `Delete`: Remove the storage. |
|
||||
| | - `Recycle`: Basic scrub (deprecated). |
|
||||
| | - `Retain`: Manual cleanup required. |
|
||||
|
||||
---
|
||||
|
||||
## 🔒 PV Access Modes
|
||||
|
||||
| **Mode** | **Description** |
|
||||
|------------|-------------------------------------------------|
|
||||
| `RWO` | **ReadWriteOnce** – One node can read/write. |
|
||||
| `ROX` | **ReadOnlyMany** – Multiple nodes can read. |
|
||||
| `RWX` | **ReadWriteMany** – Multiple nodes can read/write. |
|
||||
| `RWOP` | **ReadWriteOncePod** – Only one Pod can mount it with read/write access. |
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ CLI Commands to Manage PVs & PVCs
|
||||
|
||||
```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: Deployment with `hostPath` Volume
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: app-1
|
||||
namespace: dev
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
name: nginx
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
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
|
||||
```
|
||||
|
||||
### Valid `hostPath` Types:
|
||||
- `DirectoryOrCreate`
|
||||
- `Directory`
|
||||
- `FileOrCreate`
|
||||
- `File`
|
||||
- `Socket`
|
||||
- `CharDevice`
|
||||
- `BlockDevice`
|
||||
|
||||
---
|
||||
|
||||
## 📄 Example: Static Persistent Volume (PV)
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: pv001
|
||||
spec:
|
||||
capacity:
|
||||
storage: 128Mi
|
||||
accessModes:
|
||||
- ReadWriteMany
|
||||
persistentVolumeReclaimPolicy: Retain
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📄 Example: Persistent Volume Claim (PVC)
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: pvc-2
|
||||
namespace: db
|
||||
spec:
|
||||
accessModes:
|
||||
- ReadWriteOnce
|
||||
resources:
|
||||
requests:
|
||||
storage: 64Mi
|
||||
```
|
||||
|
||||
> ✅ To bind a PVC to a specific PV, add `volumeName: <pv-name>` in the PVC spec:
|
||||
```yaml
|
||||
volumeName: pv001
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🌐 NFS-Based Persistent Volume
|
||||
|
||||
### Persistent Volume (PV)
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolume
|
||||
metadata:
|
||||
name: pv-nfs-2
|
||||
spec:
|
||||
capacity:
|
||||
storage: 128Mi
|
||||
accessModes:
|
||||
- ReadWriteMany
|
||||
persistentVolumeReclaimPolicy: Retain
|
||||
storageClassName: nginx-files
|
||||
mountOptions:
|
||||
- hard
|
||||
- nfsvers=4.2
|
||||
nfs:
|
||||
path: /root/Nginx_Files
|
||||
server: 192.168.6.160
|
||||
```
|
||||
|
||||
### Persistent Volume Claim (PVC)
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: PersistentVolumeClaim
|
||||
metadata:
|
||||
name: pvc-1
|
||||
namespace: db
|
||||
spec:
|
||||
volumeName: pv-nfs-2
|
||||
accessModes:
|
||||
- ReadWriteMany
|
||||
resources:
|
||||
requests:
|
||||
storage: 64Mi
|
||||
storageClassName: nginx-files
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ Static StorageClass for Pre-Provisioned Volumes
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1
|
||||
kind: StorageClass
|
||||
metadata:
|
||||
name: nginx-files
|
||||
provisioner: kubernetes.io/no-provisioner
|
||||
```
|
||||
@@ -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